About | GitHub | RSS |

mutable state

Thoughts on software, AI, engineering and the future of work.

Revenge of the Generalist

Uma Thurman as the Bride in Kill Bill, driving at night with a katana beside her

4 mins read

The AI Productivity Debate

There’s a lot of discussion right now about AI enabling companies to do more with fewer people and many orgs are looking at AI primarily through the lens of efficiency: automate tasks, reduce costs, and remove roles. I think they’re looking at it too narrowly and our biggest opportunity with AI is not replacing people. It’s making willing and talented people dramatically more capable. Its real potential is as a force multiplier for creativity, productivity and opportunity discovery.

Beyond Automation

Why not educate and enable every person in the company to use AI effectively, and not just to automate their existing processes, but to rethink how work gets done, prototype new approaches and identify opportunities that weren’t previously practical or even visible. Then the question becomes less about “how many people can AI replace?” and more about “what can our people achieve when AI removes the friction?”

Emergent Product Builder Roles

An emerging example of this shift is the rise of the Product Builder and Forward Deployed roles. Companies such as eToro and Updoc are advertising these roles that blur the traditional boundaries between product management, engineering, delivery, design, and business analysis.

These product builder roles represents a type of AI-enabled role where someone who can identify customer problems, and shape solutions, can use AI tools to rapidly , and continuously iterate without all the traditional handoffs to product or engineers or some other specialist teams.

The Next Generation of Builders

One thing that frustrates me about these emerging roles is the heavy bias towards experienced software engineers. Why?? If AI is making software development increasingly accessible, shouldn’t we be looking beyond traditional engineering backgrounds?

What about technically capable Product Managers, Delivery Managers and Business Analysts? These are people who often spend years working directly with customers, understanding complex problems, navigating commercial constraints and identifying opportunities to create value. They already understand the why and many have the technical foundations to learn the how. So why is the default assumption that we should teach an experienced engineer how to understand customers, business problems and commercial realities, rather than teach a technically capable product or delivery professional how to build?

I’m not suggesting that software engineering is becoming irrelevant or everyone can become an effective engineer overnight. I’m saying that the economics of building software has changed. AI has lowered the barriers to entry, accelerated development and made it possible for technically capable people from other disciplines to contribute in ways that previously needed years of specialist experience. If AI is changing who can build, shouldn’t we also be changing who gets the opportunity to build? So let’s relax those rigid and archaic boundaries between these disciplines and be more flexible in how we deploy talent.

Connecting the Dots

My prediction is a team that previously needed 6 engineers might now need 2-3 highly capable engineers plus people from other disciplines who can now contribute directly to building and experimentation. Senior engineers become increasingly valuable, but their role potentially changes. Rather than being responsible for producing large volumes of code, they become more focused on architecture and tech strategy, tech standards and guardrails and enabling less specialised builders.

Product and delivery people will become more technical. A technically capable PM, BA or Delivery Manager will identify a problem, investigate it, prototype a solution, test it with the biz, iterate, and build a production-ready case. All without having to hand every step over to another discipline.

Teams become capability-based rather than role-based. Instead of the Product Manager owning the problem, or the QA being responsible for quality embedding, we will increasingly have 5-6 AI-augmented problem solvers, with different depths of expertise. Their job won’t be to stay in their discipline but to solve the problem.

20 Years of Becoming T-Shaped

Historically, becoming reasonably competent across product, analysis, design and engineering was extremely difficult and time consuming because each discipline had a substantial learning curve. I know because my career plan has been exactly this. I’ve done my time as an engineer, business analyst, delivery manager, product manager, and engineering manager. AI doesn’t eliminate those learning curves but it does dramatically reduce them and that makes the T-shaped individual much more powerful and I strongly believe that should change the optimal composition of teams.

The Human–AI Advantage

Of course, AI will change the shape of work. Some tasks will disappear and roles will evolve but orgs that simply use AI to reduce headcount miss the bigger opportunity. The real competitive advantage will come from building teams where people and AI work together and where employees can move faster, think bigger, and create more value than ever before. Here endeth the rant.