The org chart lied to you.
Not maliciously. The people are real. The titles are real. The reporting lines exist. But the org you inherited was built to run a company that's a different size, different complexity, and different ambition than the one you're trying to build now.
That's not a people problem. That's a design problem. And most executives never separate the two.
Thirty years of IT transformation. Same pattern every time. The inherited org is optimized for the last crisis, not the next opportunity. Someone got burned by a deployment that went sideways, so they added approval layers. A key person left, so they distributed their responsibilities across three people who each own a third of the context. A vendor relationship went bad, so now everything runs through procurement even when speed matters more than savings.
The org calcifies around its wounds.
I call it the Cog. Lots of activity. Reasonable people. No one's lazy. But the machine doesn't move. Tickets get closed. Incidents get resolved. Releases go out on the schedule they've always gone out on. And the business keeps asking why IT can't keep up.
The Cog manages, the Cog maintains, but it doesn't change. Every month the Cog stays in place is a month of margin, speed, and competitive position you don't get back.
The answer isn't headcount. It's whether the org you have can use what you give it. The org you inherited was never built to go where you need to go.
Three things I look for in the first 60 days. Because an org built to approve yesterday's deployments will not suddenly become capable of governing data, running AI, or executing at the speed the business needs.
One: where does every decision actually go? Not where the org chart says it goes. Where does it actually go?
I walked into a national appliance retailer once - new POS systems, new website, a new ESB processor, Teradata, thirty IT specialists on the payroll. Modern stack. Real investment. And every time I asked a question about the data, or why something was built the way it was, the answer was the same: talk to Jack. Jack had been there thirty-plus years. He'd built and used every system IT had. He had all the answers - and the organization had crippled itself because of it. No one dug in to understand the data. No one did the work to build organizational knowledge into the systems. It was just Jack.
Find the person every ambiguous decision lands on. That's either your most valuable asset or your single point of failure. Usually both. Breaking that model was brutal. If you think it was easy, you don't know Jack.
Two: who's the hidden gem? The person who's been outperforming the system not because it helped them - but in spite of it.
The hidden gem isn't just overlooked. They're often actively contained. Ted was a senior architect with a reputation for being gruff and difficult. What he actually was: the only person in the building willing to say out loud that the ruts were six feet deep. The org was mid-migration from on-prem to SaaS and kept running into the same walls - network constraints, security barriers, operational dead ends. Ted designed a solution that satisfied everyone: the network team, the developers, the business. All of that was hiding behind a guy buried under layers of approval and executive leaders who had a stake in maintaining the status quo. Unleashing him was the biggest needle driver in two years.
Ask who gets things done anyway. Then ask what's in their way.
Three: what would break if your three most tenured people left tomorrow?
If the honest answer is "everything" - you don't have an IT org. You have a knowledge hostage situation. So what should you do?
Shoot the hostage. Take them out of the equation.
That sounds cold. It isn't. It's the only way to break the cycle. I stepped into a supply planning software product - the flagship, the revenue maker - and found that two previous product managers had retired and taken decades of institutional knowledge with them. Developers could read the code and tell you what the software could do. With over 1.4 million configuration permutations, a code search wasn't very helpful. What nobody could tell you was what customers actually did with it every day. That knowledge had lived exclusively in two people's heads. When they left, weeks turned into months. Is this a bug or is it by design? Nobody knew. Questions that would have taken a PM two hours became resource drains that consumed entire sprints.
Hostages are never a good thing. Once you find one, disperse the knowledge. Build it into documentation, into systems, into the team. Capture what the software does for customers - not what it could do in theory. The org that depends on any single person to function isn't an org. It's a liability.
The org you need isn't a headcount add. It's a redesign. And you can't redesign what you haven't honestly diagnosed.
Find your one, your two, and your three. The org you need already exists. It's buried under the one you inherited.