As engineering teams grow beyond 10-15 people, a predictable pattern emerges: the same leadership challenges surface repeatedly, regardless of industry or technology stack. Teams that understand this pattern scale smoothly. Teams that don't find themselves repeatedly hitting the same bottlenecks despite adding more engineers. Engineering leadership breaks down into four distinct areas, each requiring different skills and focus: People Management, Project Organization, Developer Experience, and Platform Architecture. Most growing teams try to handle all four areas without dedicated focus, creating predictable problems - unreliable deadlines, frustrated developers fighting their tools, team members leaving for better opportunities, and mounting technical debt. When teams recognize these four leadership areas early and plan for them intentionally, they avoid the common trap of overloading one person with responsibilities that require completely different skill sets. The transformation is remarkable - instead of engineering leaders burning out trying to handle everything, you get focused expertise that multiplies the effectiveness of the entire team.

Traditional war games fall apart when multiple teams try to learn incident response and team dynamics simultaneously. This two-phase approach separates the challenges: homogeneous sessions build incident response skills within existing teams, while heterogeneous sessions focus on cross-team coordination with a shared foundation.

Every AI conversation starts the same way: explaining context you've already explained dozens of times before. By the time you finish setting the stage, you've burned half your thinking time on background instead of solving the actual problem.

I discovered something counterintuitive: the best AI projects don't just store information, they grow themselves. Each conversation becomes the foundation for better conversations. Instead of starting from scratch, you're building on increasingly sophisticated context. Your AI tools should learn and evolve with your work, not force you to start over every conversation.

Time management lives alongside prioritization and communication as the foundational skills for being an effective team leader. Team leads (alongside everyone else in most organizations) have more work than they can handle, so what work should they do and when? The key to these decisions is understanding the three levels of time management.

Busy, busy, busy.

In any company (small companies especially), it’s easy for leaders to get busy. Rushing between planning meetings, standups, retros, and one-on-ones, then trying to squeeze in some dev work as well. The work adds up quickly and you can barely catch your breath.

So with all this work, how do you know that you’re making progress? What if you’re just running in place? Let’s take a step back and evaluate the difference between doing the right work and just good work.

When I was a backend team lead I would sometimes jump in and help during sprints by writing code or diving into operations. Occasionally I would even be the best person for the job because I had domain knowledge for that service or sub-system.

So why do I always prioritize dev work dead last on my list of to-dos?