Untitled

Happy Friday!

I'm sitting here writing this from a local driving range, and I've already sweated through my clothes. I took lessons this spring with my wife, and by the end, I thought I could actually play and enjoy golf. Then we went on a trip for a week, and I have been humbled by how much worse I am after that small break.

That's what practice is for, to turn the outlier that was great into normal.

Anyway, I've been thinking a lot about dependencies, and I'm working on making a video about it. What would you like me to cover in that video? While you think on that, I'm going to share a bit about a common set of team structures that undermine all of its productivity and why it keeps happening.

Let's imagine we have a small-ish engineering group that we could split into 3-4 teams. A big question that comes up is what those teams should have responsibility over? A very common way to answer this is by component. A component would be something like the data, infrastructure, services, front-end, etc. These are components of a whole system. They often correspond to system architecture layers or modules.

The reason this structure is popular is that leaders are taught and believe that having teams develop a deep specialization in that component, the quality of that component will improve, and that their specialization will lead to higher efficiency when working within it. This makes intuitive sense, but there's a hiccup.

These benefits plateau quickly, and without intentional evolution and improvement, these groups only improve in very slight ways over a long period.

The other big thing that happens is that when work arrives, someone has to split that work into the component teams. All of the work is on hold until it is all complete. There is a set of dependencies that exists across the teams. Front-end can't finish until the services are complete, which need the data and infrastructure in turn. The team structure created this dependency chain, and tactics like parallelizing and doing more design do not solve this issue.

What's the big deal anyway? Well, if we simplify things, each team can either be on time or late with their work. Two basic states. This means half of the states are late, and half are on time. Now, if we add one more team, we've doubled the combinations, meaning only 25% of the combination is both being "On time". Adding a 3rd team, we double the combinations, meaning only 12.5% of the combinations are everyone being on time.

Every dependency cuts your possible desirable outcomes in half.

Some of you might say, "Well, those are the outcomes, but not the probability of those things." You're right, they're not! So here's the next layer. Look back at any one team's performance and how often they deliver within the estimated or needed timelines. Now you know the probability to achieve things.

If that sounds boring and mathy, I can tell you that most teams are on time somewhere between 20%-50% of the time.

The math here is not obvious, but now for any "On time" we could roll the dice and say you have a 20-50% chance of actually being on time instead of late. Or we can simplify this further and use these probabilities for the on-time/late. If we were to simulate this, we'd realize that this 12.5% would be a dream come true compared to reality.

Now, you could of course invest a ton in that specialization you desired above to get closer to that 12.5% of on-time. Or you could structure your organization to eliminate dependencies and accept that certain "Inefficiencies" cost less than they sound.

Sincerely,

Ryan