More and more people and companies are realizing the potential of agentic engineering or “vibe coding” to write small pieces of software and automations at speed and basically at no cost.
With each new generation of models, criticism on security and quality issues of AI generated code lost ground as the frontier models, though still not perfect, inch closer to an ideal state.
But the speed of delivery did not increase to the same extent - if at all. The reason: Dependencies. Dependencies are the catch-all term for the situation that you depend on someone elses tasks, resources or information to finish your tasks.
Let’s look at a specifc example. We would like to display the invoices of our customer in the customer portal. The feature is on the surface straight forward. Design and specifications are straightforward. You can write a piece of software in a couple of hours, but there are some dependencies:
The invoices are created by our accounting software in another team and we have to clarify how we can access them.
In case invoices are cancelled after they have been issued: How do we get the information?
How can we get the payment status of an invoice?
These are all “information dependencies” to begin with. Knowledge and context we don’t have yet. This requires meetings and research to understand the full context, but after a while discover more dependencies:
Task depedencies: We need an endpoint that provides us invoices and their status.
Resources: This task falls into the domain of a different team, so we require the allocation of their resources to create those endpoints.
So the straightforward feature now requires hours of “alignment” with the other team, negotiation about prioritization and potentially even a bigger discussion on the invoice archiving process.
I have seen this unravel more than once, and I am under the impression that with increasing company size, the likelihood increases that cross-team dependencies and resulting information assymmetries are the bottleneck for implementation. Not the coding part.
In an ideal world AI could have the context, if processes are properly documented. But in most cases, they are either not documented at all or completely outdated. On the deep-dive you might also discover that there is not a single process, but a fragmented case-by-case evaluation differing by actor, country or customer. Software and automations however require some algorithmic logic to be effective, so a small scale feature idea can turn into a full scale change management initiative across departments.
How could it work differently?
Software design as well as organizational design has been propagating to be mindful about creating dependencies. They usually can’t be completely avoided, but they can be managed carefully.
E.g. I am dependent on accounting for invoicing. I can’t make my own invoices in parallel. I could check if it makes sense to be fully responsible for invoice creation, but in that case we would increase the mental load of a team that is already stretched thin, increasing the resource dependency of another business team (accounting and finance) on our team.
The big trade-off is the idea of redundancy vs. efficiency. Sharing components across teams can be efficient until alignment on changes on these components eats up all the gains and then some. Managing what is essentially the same component independently in two teams may feel redundant and inefficient, but can be the right call when you anticipate that needs on the component will diverge in the future and the rate of change will be high.
There a few heuristics that I find to be helpful:
Tech everywhere
Tech everywhere is not just the proposition to automate everything that you can effectively automate, but also that each business domain should in be in charge of their own technology. This keeps the mental load focused on a single business domain and lessen the tension on prioritization conflict.
APIs as contracts
Despite all efforts to align organizations with value streams, you will face the need to transfer information or objects between systems and domains (see invoice example). I know there are proponents for event driven systems, and they have good reasons, but I prefer a straightforward REST-API. Well documented, you can even version it and you can easily check who is still listening. It’s always a huge relief when you are tasked with the integration of another system, and you find a neat swagger documentation that reveals that the objects you need are easily retrieved with all information.
Copy to safe time but stay independent
Don’t introduce a new dependency to safe time. E.g. because another team already established that feature or component. Copy it, but make it a separate instance.
Be sensible though. This is a fine line to walk. Poor judgment on this will leave you with massive change implication, if whatever you copied is logically dependent on other processes or other domains.
Deep domains, small interfaces
The “mistake” happens quite often on an organizational level, where the domains of teams are cut in such a way that they are highly dependent on the on other teams. Ideally we would strive for deep expertise within each domain and specified interfaces. Marketing can be complex in itself (channels, campaigns, creatives … all of that) but eventually delivers a lead (Name and contact info of a prospect). Sales in itself can be very complex but eventually delivers an order. Fullfillment can be very complex in itself but eventually ships the product. If tech teams work with autonomy in each of this teams they only need strong alignment on these interfaces: E.g. what information is needed to place an order, and what “response” does Sales need on their behalf.
Taylor’s dilemma
As companies increase in size, there is unfortunately the dilemma that we push specialization to the extent where we are highly specialized but also highly dependent. There is no longer a person responsible for, lets say “The mobile app”. But multiple teams share different sections of the app, and neither strategy nor other guidelines are part of the teams responsibility. Local optimization within a team will quickly show reduced marginal gains. Significant optimizations on the other hand, will require the involvement of multiple teams and stakeholders with often competing interests. This dilemma is the reason why product managers in corporations are so busy drafting power point slides. I even don’t have an idea how to solve it consistently other than “stay small and strive for empowered teams. The attempt to cut everything according to value streams that are mostly independent works better in theory than in practice.
I would be curious to learn how others have tackled this challenge, and if they did so successfully.