“Engineering teams that do not evolve to the new tools that AIs give us will either be replaced, or their businesses will flame out.”
Twenty-five years ago, I could have written that same sentence and replaced “AI” with “the Web,” and forty years ago, “the personal computer.”
This is not an article about needing to use Claude or other agentic AI tools; that is something you should be doing already. In this case, I’m talking about a fundamental restructuring of how software gets built and deployed. Startup founders have asked me any number of times, “How should I build an engineering team?” My answer today is very different from whatever I would have said even a few years ago, and the truth is, I don’t know yet if anyone fully knows.
Optimize the flow, not just the code
Every paradigm shift requires leaders to examine the full lifecycle of development rather than one specific part. Code generation is merely one facet, albeit an important facet, of getting a product out the door. Technology leaders should be looking at the end-to-end flow of an organization. Those companies that create flows that are optimized to new technology will always move faster and have a competitive advantage. Most importantly, though, remember that much of our ways of working have come about in the last 15–20 years, which is not a long time, and like coding itself, the processes are due for disruption.
We spent the last decade building ‘Product Trios’ (engineering lead, product manager, designer) and microservices to manage complexity. But those structures were built for human limitations, not agentic speed. In many cases, even those ended up adding more bureaucracy depending on the organization, its value proposition, and the specific structures. In many cases, beautiful Kanban agility devolves into a waterfall.
The agentic disruption
Then enters a disruptive force like AI/agentic coding. It can be quite disorienting for those who have spent the last 15 years in one paradigm.
- What is the role of the engineering lead who has spent years looking over a team’s code when agents can write relatively decent code when correctly used?
- What is the role of the individual developer when anyone can build an application?
- What is the role of the product manager who spends their time describing the work they need to do when agents can dig through tickets and customer data and inform developers what needs to be done?
Are any of these roles even the roles we should be hiring for? How do we improve security in a world where every person can code a company to disaster?
A startup founder will nod their head. Smart founders we see have turned the tables on how traditional development teams work and are quietly dismantling old structures and writing the next scaling book. Companies of all sizes are changing hiring practices, even demanding roles have different skills, like product managers being able to create proofs of concepts. On the other hand, I have heard many established teams find it difficult in practice to see the effectiveness of AI beyond “vibe coding.”
A new blueprint
I don’t have all the answers on how I would build new engineering teams, but here are some points to consider from what I have experienced:
- I would flatten the org structures; designers and product managers who cannot make changes are less valuable, as are those individual contributors who cannot work across silos, code-bases, and teams using new tools.
- Staff need to be trained and experience the ups and downs of managing fleets of agents. Those who excel at those skills will become extremely valuable.
- Set up code repositories, whether old or new, to be read by AIs such as Claude. This includes better structures to ensure proper context.
- Set up shared agentic workflows that anyone in your engineering team can use; you might even be saying, “This repository works with this agentic workflow AI in this way.”
- Developers should go back to first principles. Truly understand how systems scale, why certain patterns are preferable, and what makes secure coding. When you don’t have to write code, you need to know how to get the correct result, otherwise it will be unsecure, hot messes.
- Hire for creativity, business understanding, passion, and the ability to communicate ideas at every level—not just in product management. This is important both for humans and working with agents.
- The flow from customer input through support, analysis and testing of the issue, creation of a code merge request, and having that code tested: All this can be fully automated.
- Small features should be launched in a way that an AI can continue to maintain them. Yes, I mean fully maintain them–I do not mean “no human”, but you don’t need a complex human workflow that takes sprints.
- The idea of “team” should be examined to understand what that means in a world where any AI can make changes to the work of multiple teams to achieve an outcome.
- Every step of the flow should be considered so that outcomes and value can be delivered with verification by defined owners.
Evolve or die
I’ve heard more than one technology leader say, “I don’t think we need X role anymore.” The truth is that we don’t know what roles mean in a world where an AI can, for example, create a full slide deck for you in 5 minutes that you would otherwise spend a couple of hours on.
If you do not start the evolution now, you will pay the price in later years as you re-tool in more painful ways—if you survive long enough to re-tool.
This is the time to examine and start thinking about how your organization is working. The tools are here, or evolving so fast that they will overtake you. The question isn’t whether you should use them, but whether you can dismantle your current identity fast enough to survive them.
