#The new bottlenecks in tech projects

AI is crushing the time needed for the Build part of technical projects. If you know how to leverage its power, you have access to a virtual technical team: front-end, back-end and full-stack developers, DevOps, designers, data engineers, data analysts, you name it.

However, this doesn’t mean that developing a new solution end to end, from the business need to the deployed tool, is now a matter of days. This contraction of build time has exposed other bottlenecks in the organization, and there are usually two: product management upstream, and technical deployment downstream.

These bottlenecks are not actually new. But when the Build phase took weeks, they were hidden behind it. Product decisions were made along the way, often at weekly sync meetings or when a developer came with a question. IT and deployment-related requests followed their course in the background, without any particular sense of urgency. Now that the Build is down to days or even hours, product management and deployment tasks make up a major part of a project’s calendar time.

##Expressing the need

The first complexity is that people need to know what they want. This may seem trivial at first, but it’s harder than it sounds.

• When users already have an existing tool, they often adjust their workflow around its features, and tend to limit their needs to what it already does.
• Specifying incremental versions is a skill of its own: starting with a basic v1 that already solves one pain point, then more features in later versions. It requires decisions and trade-offs. And since people probably fear that later versions will never ship, they tend to squeeze everything into the v1.
• Even for experienced collaborators, as you dive deeper into the problems and the needs, many edge cases and contradictions arise. Not everyone has been trained to think like a Product Manager.

And that’s just for one person. Imagine when you have to align the needs of a full team. One example I have encountered several times: a sales team wants to automate their pitch deck. It turns out that not only are all team members using different tools (PPT, Google Slides, PDFs, emails, etc.), but they also don’t agree on what should be included in the proposal: some like to include many benchmark examples, some like to have a personal client recap, others discard advanced metrics as confusing for the client, etc.

The first reaction is to put everything in the automated deck, since people can delete slides in a few clicks. But then nobody feels like the tool fits their own needs. Another option is to add modularity to the UI before the deck is generated, at the cost of more complexity and maintenance in the long run. At some point, managers have to make a decision about the process: what should be the standard output for the whole team.

The speed of AI also changes the way these decisions are made. You no longer need simple mockups to imagine what a change would do: you can build it almost live, in front of the people who asked for it, and let them react to the actual change. But in the end, someone still has to decide which version should be shipped. Choosing means giving things up.

##Deploying

Once a functional scope has been agreed, comes the time to make the app available to collaborators.

Running it locally is rarely possible, and almost never a good idea: the tool is usually meant to be available to several people, maintenance and updates on local machines would be too complex, and connections to other tools and data would be hard to maintain and debug.

Deploying to an external stack would be relatively fast and easy, but it’s often not possible for security and legal reasons: the company wants to keep control of its data governance.

Deploying on the company stack is the reasonable choice, and it’s also the slowest. Most of the time, the stack is Microsoft or Google, familiar solutions that have been around for decades, so you would expect it to be relatively straightforward. It only takes a few actions from the IT team: opening connections to databases, creating virtual instances to host the tool, granting permissions to deploy updates, creating user groups, etc. And this is often where the project lags the most.

Emails are sent between multiple technical stakeholders, asking for approval. Sync calls take place, decisions are made, but they are usually not implemented right away. Some IT teams are also simply not very familiar with cloud services.

##In the meantime

Deployment is perceived as the last mile of a project, and lagging at this stage is a frustration for business stakeholders: the PoC was approved days or weeks ago, and yet nothing is visible to them. So the afterthoughts start coming in: a few more small features. How can you blame them? They have seen in live demos how fast an AI agent iterates on a PoC. Adding a feature “just takes a few minutes”. How many times have I heard this?

For the AI agent, it probably does. But any additional feature leads to more operational and business questions. And since the tool has not been tested in real conditions yet, many of these requests will turn out to be false good ideas. When a project is stuck too long at the deployment phase, it tends to drift back upstream, into product decisions.

##So what?

It would be an exaggeration to say that “coding was never the hard part”, and that AI has only accelerated a secondary aspect of tech projects. The complexity of features that AI agents can now build is tremendous, and it literally eliminates whole developer teams, and weeks or months of development. This is anything but anecdotal.

But a project is also made of many decisions, small and large, by technical and non-technical stakeholders. When technical execution was the largest bottleneck, slow and expensive, those decisions went mostly unnoticed, and were rarely to blame when a project stalled. Now that AI crushes execution time and cost, it cruelly exposes business and organizational inefficiencies and indecision.

On my side, AI has changed the way I handle these iterations. I can take 10 or 15 successive rounds of changes without getting tired: for minor modifications, the AI agent literally reads the client’s email, applies the changes and redeploys the app, with little or no intervention on my part. The same goes for deployment. With AI as a supernatural DevOps, a relatively complex deployment takes an hour or two.

It is tempting to think that AI only helps with the Build phase, the coding part. That’s the most hyped aspect, but it absolutely doesn’t stop there. Upstream, it shows right away what a feature request implies, and points out the side effects and edge cases nobody had thought of. Downstream, it turns a deployment into a matter of hours.

##Changing how we work

What AI does not speed up is deciding and trusting. It can show five versions of a feature in an afternoon, but someone still has to pick one. It can deploy a tool in an hour, but only once someone has granted it the rights to. These are the new bottlenecks.

Upstream, that means learning to decide what a team needs. Expressing this need clearly, and giving things up for a first version, is a skill. It can be learned, and it will matter more and more now that anyone can get code written.

Downstream, it means setting a frame once, instead of handling every request by email: an environment with dedicated rights and guardrails, where a new tool can go live without a new round of approvals. Once that frame exists, the second tool takes days, not weeks.