As we explore AI driven productivity gains more, it’s useful to break things down at the individual, team and organizational level.
For individuals, AI tools can make people more productive but can also create the appearance of progress that is actually just noise or side quests.
In some cases they make people worse as workers start churning out AI slop when prior to AI tools they produced reasonable or at least passable work.
For software product teams, one role being more productive does not automatically translate to the team being more productive.
Engineers writing 2x - 10x as much code does not translate to 2x - 10x as much revenue or customers. But it does mean 2x - 10x as many bugs. Using AI to do analysis doesn’t help if the output cannot be trusted because it’s frequently incorrect.
So it takes real effort to rework how a team executes so the individual productivity from AI use actually applies to the team
For organizations, it’s hard to reap the benefits of AI productivity gains because current processes are not designed for the pace at which work happens in an AI assisted world.
AI creates many “hurry up and wait” situations where the work happens fast but impact is delayed due to process overhead. It is not unusual for it to be faster to build a feature with AI than to get a meeting for all stakeholders to discuss it.
So even if the individual worker is faster the org throughput is not.
I suspect we will hit a trough of disillusionment as companies struggle with the anecdotes of individual or team level AI productivity gains not resulting in organizational level improvement in results.
The question then becomes what process changes at the organizational level unlock these gains?
@carnage4life I feel like the assumption that a process change *could* address this is unexamined. What if, fundamentally, the ability to code things super fast is just not that important? I feel like there’s a version of Amdahl's law at play here.
That coding is rarely the bottleneck to shipping things of true value is something many people working within software organizations have observed since way before LLMs.
Dare Obasanjo
Jonathan Joelson