The first real challenge of moving into a lead role isn't the architecture decisions or the 1:1s — it's estimating and distributing work. When you're coding, you have a gut feel for how long things take. When you're responsible for a team, you're estimating work you won't be doing yourself, for people at different skill levels, in codebases they know differently than you do. Your gut is the wrong tool.

I've learned to treat deadlines as hypotheses, not commitments. The first estimate is almost always wrong. What matters is building a feedback loop fast enough to catch it early — short cycles, clear scope, honest conversations before the deadline, not after. The hardest part is creating an environment where someone can say "I'm stuck and this will take longer" without it feeling like failure. That culture doesn't come from a process doc; it comes from how you respond the first few times it happens.

Trade-offs are the core of the role. Almost every technical decision is a negotiation between speed and safety, consistency and pragmatism, what the team can maintain and what the product needs right now. The instinct is to always want the cleanest solution — but clean has a schedule cost, and sometimes the right call is a slightly less elegant one that ships on time and doesn't block six other people. Getting comfortable saying "this is good enough for now, and here's when we revisit it" is more useful than holding out for perfect.

The other shift is learning to step back. Early on, I'd jump in and fix things because I could do it faster. That's a trap. The fastest path in the short term is the slowest path for the team — it keeps people dependent, it bottlenecks the work in you, and it prevents others from growing into ownership. Delegating well means trusting that someone will do it differently than you would, and that different is usually fine. Your job stops being to write the best code and starts being to create the conditions where other people can.

Coming from development helps: I know where complexity hides, I can read a PR at the right level, and I understand when someone is blocked on a real problem versus spinning. But it also creates blind spots. Not everything that feels easy to me is easy for someone earlier in their career. The best adjustment I've made is asking "what would make this clearer?" instead of assuming the gap is effort.

Becoming a tech lead when you were just writing code