I prepared for the interview as a software architect.
I reviewed design patterns. Domain, layers, SOLID principles, scalability decisions. I knew the role was called Tech Lead, but in my mind both concepts lived in the same drawer: someone who knows the system's architecture and guides the team from there. That's what I did. That's what I was going to demonstrate.
The problem is they didn't ask me about architecture. They asked me about the team.
How do you handle someone who isn't delivering? How do you push a developer who already masters their area toward something new? What do you do when there's friction between two teammates?
I answered. But my answers had a technical angle the interview wasn't asking for. I talked about structure when they were asking about behavior. I talked about design when they were asking about relationships.
When I walked out, I knew.
The difference between a Software Architect and a Tech Lead isn't about hierarchy — it's about focus.
The architect lives in the system: makes structural decisions, defines the technical rules of the game, ensures the solution holds up over time and growth. They're the one who draws the diagrams the team takes months to fully understand.
The Tech Lead lives in the team: their job isn't to decide the architecture but to make sure every person working within that architecture is doing the best possible version of that work. They are distinct roles. In small teams, one person often carries both — and that's the trap. Because carrying both at once is not the same as knowing when to use which.
I confused them. And I didn't realize it until the interview showed me.
After that meeting, I did something I don't always do: I reconstructed the answers I would have given had I understood then what I understand now.
The most important one was this: a Tech Lead is of service.
Not in the corporate sense of "being available." In the literal sense: their main job is not to produce code — it's to make others produce better code. They share what they know with whoever needs it. They explain how they solved a similar problem. They point people toward what to study. They do pair coding when someone is stuck. They say "here's how I see it" and then ask how the other person sees it.
I've been lucky enough to learn this from several people, each in their own way. But the pattern was always the same: when you came to them with a problem, they didn't solve it for you. They took you to the point where you could solve it yourself. They left you more capable than when you arrived. That's the difference between someone who knows and someone who leads.
There's something that took me a while to accept: that calling toward service wasn't something I built on my own at work. I inherited it.
My mom always had that way of being available without making it a burden. Of helping without keeping score. When I think about why I feel comfortable explaining things, sharing, investing time in making sure someone truly understands something — I recognize that. It's not a skill I practiced; it's something I saw so often it became natural.
In software, that's an asset. In leadership, it may be the hardest asset to teach.
The second thing I would have said in that interview: a Tech Lead is a challenger.
Being of service doesn't mean being comfortable. It means you care about the other person's growth — and growth almost always involves discomfort.
A good tech lead pushes their team beyond what they already master. Not because they want them to struggle, but because they know that staying within familiar territory is a slow form of stagnation. And stagnating in software means falling behind. The people who advance aren't always the most brilliant; they're the ones who keep finding new things that challenge them.
The third and fourth go together: respectful and kind. Not as HR values — as working conditions.
There is nothing more fluid than a team where everyone does what they need to do without friction: no friction with the product, no friction with each other, and above all no friction with themselves. That state doesn't arrive on its own. It requires an environment where people can make mistakes without fear, ask questions without embarrassment, and say "I didn't understand" without that having a cost.
A leader who yells, who humiliates, who hoards knowledge, breaks that flow. And once broken, it's hard to rebuild.
(The lone hacker archetype from the movies — the one who doesn't talk, doesn't share, keeps the knowledge locked away — does exist. And they may have real talent. But a team that depends on that talent without transferring it is fragile. When that person leaves, the team is back to zero. Often it's not even their fault; nobody ever taught them that sharing is also part of the job.)
Four principles. One of which they didn't ask me about in that interview — but I should have articulated anyway:
Helpful · Challenging · Respectful · Kind
They're not the only ones. But they're the ones that, when I look back at teams that truly worked, are always all present. And when I look at teams that didn't, at least one is missing.
I didn't arrive at that interview complete. I almost never do. The distance between who you are and who the role needs you to be is sometimes large, sometimes small — but there's always a distance. What matters is knowing what yours is.
Now I know what mine was.
ArchMindset — software, teams, and what I learned when everything broke.
← All articles