Michael Zazon

Engineering leadership · Take

Input-bound teams and where AI savings actually show up

Whether AI shrinks a team depends on what the work waits on: input-bound teams get cheaper, but engineering backlogs never run out, so cutting engineers is really a roadmap decision.

I think there are two types of jobs. If you want to simplify an organization, there are supply constrained and there are demand constrained jobs inside a business. So input bound and output bound. What is the constraint on a job?

This is the theory of constraints applied to a job description. Goldratt says that the output of a system is limited by its constraint. In other words, before you can evaluate how AI will impact your team, you need to understand what your team’s work is waiting on.

Legal and customer service are input bound. If I deploy a lot of AI, I don’t suddenly get a lot more contracts, right?

This applies within IT too.. access-request queues, change-approval queues, ticket-desk queues, all depend on others submitting work. AI reduces the handling cost per queue item. And since the volume of incoming work doesn’t change as your team gets faster, you can realize savings there too.

But engineering is a different kind of team. If you make your team faster, they won’t finish the backlog sooner.. they’ll just ship more stuff and the backlog will refill anyway.

And so it may be that you have less input bound functions and areas as a proportion of your total employee base and you have more creative output bound functions.

A rule of thumb for this decision.. before you cut an engineer justified by faster tools, ask what’s constraining the team. If they’re output-bound, then the question of headcount becomes a question of roadmap. If a platform team can double their speed, does the business actually want twice as much stuff built? Usually the answer is yes.

I think it’s very easy for people to have very binary takes on these things, right? I find it amusing that if you put an engineer, a designer, and a product manager in a room, they’d all sit there and they’d all say, “Oh, man, it sucks to be you. Your job’s going to go away.” And I’m like, “Ah, that probably is your answer right there.”

If everyone in the room is confident that the vanishing job is someone else’s, I think that means nobody has really looked at what their own work depends on.

I think that’s going to take much longer than people think. We’re big in technology. Next year everything will be like this and it takes 10 years to happen, but it will happen.

This framing came up in a Decoder conversation about enterprise software, and I think the slow timeline gives us time to properly classify things. Which teams are actually waiting on input? Did we check before we let a spreadsheet do that?