Home Newsletter

Don't Imitate Understand - #6

Hello!

In this sixth issue of the "Don't Imitate Understand" newsletter you'll get:

Course News

From Dev → Lead → Architect

A lot of developers are quietly facing a career crossroads right now.

Companies are hiring fewer juniors. The entry-level pipeline has narrowed, but the demand for senior, lead, and architect-level skills is growing.

That means the next advancing in your career isn’t about learning another framework, it’s about learning to coordinate and communicate both with humans and LLMs.

The problem is, most developers aren’t trained for that leap. Courses, tutorials and bootcamps teach us how to code, not how to lead.

We learn syntax, tooling, and frameworks, but not how to run design discussions, evaluate trade-offs, or think in systems.

So when developers are promoted into lead or architect roles, many feel unprepared, like they’re suddenly expected to know a language no one ever taught them.

When they look for jobs, and see lead and architect roles listed, they have no idea how to interview for them.

What's more, the skills that make for a great lead or architect also help guide and guardrail an LLM. In some ways, in the age of AI, developers must have the skills of a lead and an architect in order to guide and check LLM work successfully.

This is a skill gap we have to close. And it starts with how we think about our work.

For years, our industry has celebrated speed and syntax. But those who advance from dev → lead → architect, see code not as the end goal, but as the language for expressing systems, trade-offs, and intent.

What does that look like in practice?

Leads think about communication as architecture

Leads design not just systems of code, but systems of people. They know how to provide clear direction, turning a rough feature idea into something that can be executed and maintained, while at the same time explaining why not just how. The best leads make complex discussions simple. Not simplistic, but simple: that is, understandable enough to actually start working.

Architects think in models, not tickets

They visualize cause and effect across the entire stack, the user’s journey, the data flow, the side effects that ripple through the system when something changes. They know when a technical choice will cause affect the humans involved, whether the developer debugging it, or the user trying to understand it. They use diagrams, whiteboards, and thought experiments as seriously as code reviews.

And the bridge to advancement? Curiosity.

The best developers don’t stop at “it works.” They understand why it works. They study the layers beneath their tools, the frameworks, the runtime, the network, not because it’s on the job description, but because deep understanding compounds over time.

That curiosity becomes confidence. Confidence turns into leadership.

And leadership, in this field, doesn’t just mean managing people (though that's a big, important, tricky part of it), it means being able to see the system clearly enough to guide others through it.

Good Leads and Architects Understand

The AI era will reward those who understand what they’re building, not just those who can write a prompt.

The better you understand the system, both human and technical, the less replaceable you become.

This is the work of moving from developer → lead → architect.

What separates the developers who grow into architects isn’t raw skill, it’s perspective. The willingness to slow down, understand deeply, and see every piece of the system as connected, including the people using and working on the software.

That’s the real path upward and forward in the age of AI.

Links

That's it for this sixth issue!