Many leaders assume that assigning a large initiative to a single team or vendor such as “the development team,” “the contractor,” “the offshore group,” “the AI team” that this will be sufficient to guarantee a good outcome. However, complex work never moves as a single unit. It only moves through interdependent components. To this end there are two major principles to keep in mind regarding this concept:
Principle #1 – There is an illusion that delegation equals progress.
Principle #2 – The reality is that delegation without compartmentalization equals chaos.
The core issue at play here is that most of the time when dealing with complex work that work is not being decomposed into the right and appropriate units. Just like a general contractor must break a home remodel into carpentry, electrical, plumbing, inspection, and finishing work, a technical leader must break their software development effort or project into key areas as well. These might include:
- Data acquisition tasks
- Data engineering tasks
- Modeling tasks
- Application and integration tasks
- Testing and validation tasks
- Deployment and monitoring tasks
If this type of compartmentalisation does not exist then a single team might try to be responsible for everything and as a result you can predict that they will be responsible for nothing. Effectively if work is not compartmentalized correctly, bottlenecks are not occasional; you are actually building them into the system. You know this is a problem when you hear that teams are constantly waiting on others, work is piling up behind a single specialist, or you hear the phrase, “we cannot start on X because we are waiting until Y is finished.”
Another symptom that you can watch for is you find yourself in a continuous rework cycle because responsibilities were not clear and no one had ownership of the feature or function being delivered. The real tragedy is that leadership starts to feel that the team is lacking talent, when in actuality they are lacking structure. In essence this is not a failure of any one individual, it is a failure on process architecture.
I have fallen into the above trap more often than I can count. As I look back on my career, I can contribute this failure to three principle flaws in my reasoning.
- Overconfidence in the “One Team Can Do it All” mentality.
- Misunderstanding the nature and the complexity of the build process
- No one was assigned and responsible for Workflow Design.
To use a good analogy, an orchestra needs an orchestrator. If you have everyone assigned to playing music and no one assigned to determine when music will play, you will just get noise. The same is true in complex software builds. If no one is responsible for how tasks move through the system and everyone is responsible for just doing tasks, then the work will simply not flow.
In my experience there is one root cause to teams drowning in dependencies, work being performed by the wrong people, delivery dates slipping and leadership frustration. That is almost always because no one was performing the orchestration function. You may have a VP of engineering, you may have a CTO or a CIO, you may have a Product Manager and a hundred other fancy titles but at the end of it all the following remains absolutely true:
“Delegation without compartmentalization creates structural bottlenecks that no amount of talent can overcome.”
The tendency is to believe that teams are slow, incompatible or understaffed. The problem is actually that teams are being asked to build a house without a blueprint, a schedule, or a general contractor. Once you frame the issue this way, leaders understand immediately why their system keeps stalling. This will not fix itself. Someone needs to take ownership of work decomposition, responsibility assignment, workflow sequencing, and cross team alignment.
If you resolve this you will suddenly start to see your bottlenecks disappear, progress accelerate and outcomes become more predictable.
