The Shrinking Gap Between Tech and the Business
For a long time, there has been a clear gap between engineering and the business.
Product defines → Engineering delivers
Context gets translated into tickets → tickets into code
This model made sense when execution was expensive. Writing software took time, coordination, and careful planning. The separation between thinking and building was, if not necessary, more natural.
But something has changed.
AI has made execution dramatically cheaper. Spinning up endpoints, wiring flows, even scaffolding entire features is no longer the bottleneck it used to be.
And this change is not limited to engineering.
The same tools that accelerate developers are now available across the business. Operations, product, and commercial teams can explore problems, test ideas, and even build lightweight solutions on their own.
This creates a two-sided shift:
- On one side, engineers are moving closer to the business.
They are no longer limited by the cost of implementation. They can:
- explore domains faster
- understand workflows directly
- validate ideas without long delivery cycles
- challenge assumptions before they become requirements
- On the other side, the business is moving closer to building.
Non-technical teams can now:
- prototype ideas without waiting for engineering
- automate workflows independently
- test hypotheses directly with real data
- iterate on solutions before formalising requirements
The role of the tech team is evolving in the middle of this shift.
It is no longer just about building systems. It is about enabling the organisation to operate in a more "agentic" way.
That means:
- providing guardrails for safe and effective building
- defining patterns and standards that scale
- supporting teams in exploring and validating ideas
- stepping in where complexity requires deeper engineering
- helping teams adopt the "agentic" ways of working that have already transformed engineering productivity
As both sides move closer together, the “translation layer” between product and engineering starts to disappear.
And this has a direct consequence: the backlog begins to lose its relevance.
A backlog assumes that work is a queue of well-defined tasks waiting to be executed. But most of those tasks are approximations of problems. They are guesses, shaped by partial understanding at a specific point in time.
When execution was expensive, this model worked.
Now, execution is cheap, but misunderstanding is not.
It is easy to build, easy to automate, easy to move fast: but it is also easy to go in the wrong direction.
What matters is not how fast you can ship. It is how well you understand what should be done.
This is why context is becoming the most valuable skill, not just in engineering, but across the entire business.
Context is:
- understanding the real user need behind a request
- knowing how a workflow actually behaves in practice
- recognising constraints across systems and teams
- identifying what success looks like before taking action
In this new environment, more people can build.
But that does not reduce the need for engineering. It changes it.
Engineers are no longer just builders. They are enablers, guides, and stewards of systems that others can interact with and extend.
And the differentiator across the organisation is no longer who can execute.
It is who understands the problem.
Instead of working from a backlog, teams operate within a shared problem space.
A problem space is not a list. It is a continuously evolving understanding:
- what is broken
- where the friction is
- what has been tried
- what constraints exist
- what outcomes matter
In this model, work does not start with a ticket. It starts with a conversation.
And increasingly, that conversation is shared across the entire organisation.
Because when everyone can build, misunderstanding becomes the most expensive mistake you can make.
The teams that adapt will not be the ones shipping the most features.
They will be the ones closest to the problem.
