AI Productivity Dies with Dependencies

Happy Friday!

Sometimes I feel like there's a topic I just need to rant about, and about a month ago, I wanted to rant about dependencies.

So I did.

Dependencies are Killing Your Productivity

I think the reason why is that I keep seeing folks talk about how the volumes of AI output are crushing processes like code review, while also making things less transparent. I was chatting with a manager who described himself as drowning now that AI exists.

There is a lot to unpack in that, but dependencies are what was on my mind. I've already written about how I think code reviews are a crutch that you need to outgrow. It seems folks are finally coming around to that themselves. In fact, the CTO of ThoughtWorks published a similar opinion this month. Just a cool 5 years after me. Folks looked at me like I was nuts. The same idea is insightful when a CTO says it.

I'm sure you get it.

Dependencies can buy you a lot, but they often cost a lot too. For every step in a dependency chain of work or process, things get stuck waiting for the next work, and there are constant failure modes that often don't get detected until much later. The wild thing is that there are almost never people whose job or responsibility it is to manage how these processes flow or work.

You're probably thinking, "That's not right!"

The most common person folks would think of are project managers or program managers. They don't own these processes and can't really influence how they work. They simply apply pressure on them to push things through faster. In other words, they make do.

For most groups, these dependencies span across many different people, authorities, and needs, and that makes adjusting them very tricky. So they are often unmanaged. Work waits the amount it waits, and fails the amount it fails.

I've met numerous managers who believe they can fix this by being attentive to each step, but that won't work. What happens in each part of a dependency is typically well-understood, and hard to squeeze out any additional benefit, but all the cost of dependencies happen in between, where visibility vanishes.

Engineers are terrible about this, too. They invite dependencies into their code and systems because they solve specific problems. Unfortunately, they rarely manage these dependencies, and they sprawl throughout code and systems, causing wait times and failures too. They also love to split their work by function or specialization, where each split depends on the success of the other.

Every dependency cuts the combinations of desirable outcomes in half. An engineering team that breaks work down by backend, front end, and data will only have 12.5% of the possible outcomes be desirable. Oh, but that's not how it works. That assumes each step is only one step, but it isn't. Each one is actually more like code -> code review -> QA -> done. That turns our 3 into 9 dependencies, which means that of all the outcomes, only 0.195% are desirable.

AI amplifies what is going on; it doesn't fix it. The waits get longer, the failures happen more, and nobody managed it before and doesn't know where to begin now.

Watch the talk. Are dependencies working against you? Let's talk.

Sincerely,

Ryan