Creating code has become incredibly easy. You ask something to a magical box and the output is code. But engineering has not become easier—creating code has become easier. What you know is not as valuable as it used to be, because you can look up so much more. What matters now is how you behave, how you learn, how you solve problems, and how you navigate your career. Here’s practical advice for software engineers and tech professionals on topics from toxic workplaces and imposter syndrome to systems thinking, leadership, and working with AI.
Navigating Corporate Resistance to New Technology
If you want to innovate inside a big organization, recognize that innovation may not be what the organization needs right now. Large companies often prioritize stability and reliability over experimentation. They have production systems running on proven (sometimes legacy) technologies, and that’s the safe option.
So where do you go if you want to experiment? Find the experimentation departments. Most big organizations have teams responsible for evaluating new tools and technologies. Once they’ve shown results—demonstrated what the new technology offers compared to older approaches—they may be able to roll it out across the organization. Find those people, learn from them, or join them. If you’re in a product team responsible for delivery, you may not get much room for experimentation with new tooling. If you’re not in that department, seek it out.
If the organization simply won’t move—if you’ve talked to people, made the business case, and nothing changes—you have to decide. Is the frustration big enough to look outward? Can you work with newer technologies in hackathon days or personal projects? If not, consider whether a startup culture, where experimentation and risk-taking go hand in hand, might be a better fit.
One angle that often works: cost savings. If you can show that modernizing from legacy infrastructure reduces licensing costs or maintenance burden, you suddenly have a business case. When it comes to money, people listen.
Dealing With Toxic Work Environments
Toxic relationships at work are like toxic friendships—you can only go so far in dealing with toxic behavior. People end friendships for much less than toxicity. If you find yourself in an organization with a toxic culture but the benefits (salary, learning, stability) make you want to stay, find something that works for you outside of work. If your job is your whole life, toxicity will affect you deeply. If you have hobbies, holidays, friends, and family—ways to put your mind outside the work context—you can build up resilience and it won’t matter as much.
But if you care intensely about your career and want to grow as fast as possible, a toxic environment is going to be in the way. It’s very hard to change toxic culture. If the only way to get promoted is to behave in ways that conflict with your values—self-promotion over merit, politics over results—you may be unhappy no matter what you do. In that case, consider removing yourself from the situation.
There’s also the concept of golden handcuffs. If you’re paid so much that finding equivalent pay elsewhere is nearly impossible, you have to make a choice. Do you stay for the financial benefits regardless of the toxicity? Or do you give up the gold and take off the handcuffs? Only you can decide.
Systems Thinking: Don’t Battle Symptoms
Systems thinking means looking at the bigger picture, not just individual components. Instead of fighting symptoms, go to root causes. A simple example: if your team has a routine task—say, manually fixing orders that fail validation every day—ask why those orders are failing. Maybe there’s old data in the system that predates a validation rule. Maybe a one-time cleanup would eliminate the recurring problem entirely.
The best way to start thinking in systems is to ask: Is this problem systematic? Is it repeating? If you’re doing the same fix over and over, you’re battling symptoms. Find the underlying cause, connect with the teams responsible, and fix it at the source. You’ll learn more about how things are interconnected—and you’ll stop wasting time on busywork.
From Engineer to Architect: Hard Skills and Soft Skills
At what point does a strong engineer become a solutions architect? It’s both competency and mindset. Architects can come from different backgrounds—product-minded, security-minded, software-minded—but they all need hard skills (architecture fundamentals, system design, understanding how applications fit together over time) and soft skills (persuading teams, getting buy-in, communicating with non-technical people).
The best architects enable delivery without getting in the way. They design systems that are safe, compliant, and scalable—but also systems where engineers can ship without feeling blocked. That combination of technical depth and organizational influence is what distinguishes a staff-level architect from a senior engineer.
Communicating Technical Decisions to Non-Technical Audiences
The only way to get good at this is to know your audience. “Non-technical” is not specific enough. Are you talking to a CFO? They care about cost, revenue, and operations. A CMO? They want to know how this affects marketing or customer experience. Tailor your message to what each stakeholder cares about.
Before the conversation, get feedback. Ask colleagues in finance or marketing to review your pitch. After the conversation, ask: “Did you understand what I was saying?” That’s direct, but it helps you learn. Experience compounds—the more you do this, the better you’ll get at knowing how much to simplify and how to make it land without losing substance.
Taking on Leadership Responsibilities
Leadership is not just a title. You can show leadership in any position—early career, mid-level, senior. Leaders get people on board, build relationships, and make things run more smoothly. They don’t butt heads; they manage to get things moving.
If you want to grow into leadership, take the initiative. Have conversations with your manager or product lead about your ambitions. Ask to observe stakeholder meetings, or take on a piece of responsibility within a project. Find people in your organization whose leadership style you admire and learn from them. Watch how they interact with others, how they put people at ease, how they delegate.
One principle that stands out: be kind to everyone. It doesn’t matter if it’s a colleague, a client, or someone cleaning the office. Leaders who are genuinely kind to everyone build trust and make people feel that things are going to be okay.
Managing Imposter Syndrome
Imposter syndrome never fully goes away, but you can manage it. Reflect on what triggers the feeling—specific situations, specific people—and give yourself grace. It’s okay to not know things. In tech, where things evolve so quickly, saying “I don’t know” is not weakness; it’s honesty.
When you say “I don’t know,” you take on the responsibility to figure it out. The more you do that, the more you build confidence: “I don’t know yet, but I’m confident we’ll get there—even if it’s not just me, but the team.” That’s valuable. Talk to colleagues you trust about how you’re feeling. Often, they’ll give you perspective and remind you that it’s okay to learn, and that the team is there to help.
Learning and Retaining Knowledge
There’s so much to learn in tech that worrying about forgetting things is natural. A good note-taking system can help—one where you distill, condense, and put information in your own words, and where notes can connect to each other over time. The goal is for your knowledge to compound.
But also recognize that looking up knowledge is now incredibly valuable. You don’t have to memorize everything. What matters more is knowing how to find information, recognizing patterns, and identifying gaps in your knowledge. Spar with people who know more than you—conversations will reveal blind spots you didn’t know you had.
Mindset: Ownership and Resilience
A mindset that helps: no matter what happens, it’s going to be okay. Worst case, you make a mistake, you learn, you move on. If you get fired, you figure out what’s next. There’s always a path forward. This doesn’t mean being reckless—it means not letting fear of failure paralyze you.
Take ownership. Don’t blame other people or tools. Even if you don’t think the fault is yours, taking ownership keeps things in your control. It means you believe you could have acted differently, and that your behavior influences outcomes. Blaming others puts the problem outside your hands—and then you can’t fix it.
Training New Engineers in the Age of AI
If you’re training someone new to software engineering today, don’t focus only on writing code—that’s the part AI can help with. Focus on reading code, understanding code, recognizing patterns, and knowing why things are built a certain way. AI can be a tutor: you can ask questions as they come up, without waiting for a calendar slot with a mentor.
More importantly, teach system design fundamentals. What makes a good software system? How do you start small and expand? When does it make sense to scale? Those are the challenges that remain, even as code generation becomes trivial. Engineers are responsible for engineering—not just typing. The job is orchestrating, reviewing, and making sure the system as a whole works.
AI and the Future of Engineering
Creating code has become incredibly easy. You describe what you want, and a tool produces code. But engineering—designing systems, understanding trade-offs, making decisions under uncertainty—has not become easier. The challenge is the same; the tools are better.
What’s changing is the workflow. Engineers are increasingly orchestrating: planning with AI, executing with AI, reviewing the output, building conventions and skills so the next cycle is faster. Vibe coding is evolving toward vibe engineering—where the system that creates the software also self-reflects, applies conventions, and builds coherent systems, not just isolated features.
The engineers who thrive will be those who understand that their value is in engineering judgment, not in typing speed. They’ll use AI to accelerate, but they’ll still be responsible for the outcomes.
Sustainability: Do What Gives You Energy
If you’re building something—a career, a side project, a podcast, a business—you have to do the things that give you energy. Otherwise, it’s not sustainable. If you chase numbers or growth tactics that drain you, the whole thing crumbles like a house of cards.
That doesn’t mean avoiding hard work. It means being honest about what you enjoy and what you don’t. If something isn’t giving you joy and you’re only doing it for metrics, reconsider. Especially if you don’t have a big team, you have to make decisions about where to focus. Sustainability comes from enjoying the work, not from grinding through things you hate.
Frequently Asked Questions
Q: How do I push for new technology in a company that resists change?
A: Find the teams responsible for experimentation and innovation—most large organizations have them. Make a business case, especially around cost savings. If the organization won’t move despite your efforts, decide whether the frustration is big enough to look elsewhere, or whether you can work with new tech in hackathons or personal projects.
Q: How do I deal with a toxic work environment?
A: Build resilience through hobbies, friends, family, and time away from work. If the toxicity conflicts with your values and blocks your growth, consider whether the benefits (salary, learning) are worth staying. If you have “golden handcuffs,” decide whether to stay for the money or leave for your well-being.
Q: How do I manage imposter syndrome?
A: Reflect on what triggers it, give yourself grace, and accept that it’s okay to not know things. Say “I don’t know” when you don’t—but show confidence that you’ll figure it out. Talk to trusted colleagues for perspective. Imposter syndrome doesn’t fully go away, but you can manage it better over time.
Q: What skills matter most for engineers now that AI can write code?
A: Reading and understanding code, recognizing patterns, system design fundamentals, and engineering judgment. Creating code is easy; engineering—designing systems, making trade-offs, ensuring quality—is still the challenge. Focus on orchestrating, reviewing, and building conventions, not just typing.
