Posts tagged leadership.
Managing AI coding agents, and agents that direct other agents, is structurally the same job as being an engineering manager, a director, a VP, or a CEO. You give high-level direction to autonomous workers, and you operate through systems and outcomes instead of inspecting every artifact.
Your engineering team adopted AI coding tools six months ago. Deployment frequency is up. Lead time is down. PRs are flying through the pipeline. Everyone feels faster.
AI is forcing software development back to first principles. The practices most teams abandoned as overhead, specs, formal verification, architectural review gates, are becoming essential again the moment humans stop reading every line of code.
The distance between what you meant and what the AI produced, and why no refactoring pass can reverse it.
Most AI adoption failures share the same origin story: someone tries the hardest possible task, it fails spectacularly, and they declare they'll "come back next year." This happens constantly because teams lack a mental model for sequencing adoption.
SaaS companies are all AI companies these days. How deep does does that AI integration really go, though?
Everyone has opinions about candidates. That's the problem.
Every small organization has gaps. Maybe you have an engineering lead but no dedicated DevOps team. Maybe your product manager is stretched thin and the tech lead is absorbing PM responsibilities. Maybe a designer role is emerging, but nobody owns it yet.
Every engineering blog paints a picture of clean microservices, continuous deployment, and comprehensive observability. I've been in this industry for over a decade, and I've never experienced this ideal state across the board. I've seen glimmers. Teams that nail one dimension.
Most architecture discussions devolve into abstract debates about microservices, monoliths, and database choices. After years of explaining these concepts to engineers and product leaders, I've found that thinking about software architecture like a physical
Most engineering teams waste weeks solving the wrong problems.
Every sprint plan will go sideways. Every project timeline will hit unexpected problems. This isn't pessimism. It's pattern recognition from years of leading engineering teams through hundreds of delivery cycles.
Engineering teams have always made judgment calls about risk and speed. With AI development tools becoming standard practice, that judgment call has gained a new dimension demanding more careful consideration.
In cycling, the pain doesn't decrease as you get better. You just get faster.
Enterprise customers love asking for on-premises deployments. The contract values look irresistible: 2-5x your standard SaaS pricing, multi-year commitments, and the validation that comes with enterprise logos.
Every engineering leader has lived this nightmare: two days from deadline, the team discovers the core architectural assumption doesn't work, the third-party API is missing critical functionality, or the algorithm can't handle production scale.
Engineering leadership's most expensive monitoring decision isn't choosing the wrong tool. It's falling into the monitoring trap that costs organizations in wasted engineering time and preventable downtime.
As engineering teams grow from 5 to 50+ people, leadership responsibilities naturally expand beyond what any single person can effectively handle. Yet many organizations struggle to identify exactly what types of leadership they need to scale successfully.
Traditional war games work great for single teams. But what happens when you have three subsystem teams, a dedicated SRE group, and multiple stakeholders who all need to respond to incidents together?
Every AI conversation starts the same way: explaining context you've already explained dozens of times before. "I'm working on a product that does X, my team structure is Y, and I need help with Z." By the time you finish setting the stage, you've burned half
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?