Two weeks into a new role running IT for a small team, and the job is exactly what I expected, because I have spent my career in environments built this way. Small IT teams do not have the luxury of a specialist for every domain. One person, or a small handful of people, is expected to be competent across networking, endpoint management, identity and access, cloud infrastructure, phone systems, physical security, vendor contracts, and compliance, all at once, plus whatever breaks on a Tuesday afternoon. The job is not depth in one domain. It is breadth across all of them, with the judgment to know which one deserves depth right now.
That breadth does not get easier with experience. What changes is how deliberately you manage it. The instinct in any small team is to solve every problem as it appears: add whatever tool fixes today’s issue, keep every process that was already running, and figure out the rest later. Do that consistently for a few years and you get an environment that works, technically, but that nobody could fully explain if you asked them to draw it on a whiteboard. That is not a failure of the people who built it. It is what happens when complexity accumulates one reasonable decision at a time and nobody goes back to ask whether the sum of those decisions still makes sense.
Complexity Is Rarely Designed. It Accumulates.
Most of what a new IT leader inherits was never designed as a whole system. It was assembled incrementally, under time pressure, by people solving the problem directly in front of them. Each individual decision was defensible. The approval step existed because of a specific incident years ago. The extra tool got added because migrating off the old one felt riskier than living with two. The manual process stuck around because automating it never made it to the top of anyone’s list. None of that is negligence. It is just how systems grow when nobody is deliberately asking whether they should keep growing that way.
The mistake most new leaders make is treating inherited complexity as fixed. They assume it exists because someone smarter than them decided it needed to. Sometimes that is true. Often it is not. The only way to find out is to ask.
A Framework for Asking the Right Question First
Elon Musk has described a five step process he uses at Tesla and SpaceX for engineering decisions, and it has stuck with me because it puts the steps in an order most organizations get backwards. Question every requirement. Delete any part or process you can. Simplify or optimize what remains. Speed up the cycle time. Automate last, only after the first four steps are done.
The order matters more than the individual steps. Most organizations reach for automation first because it feels like progress. But automating a process that should not exist just makes the waste run faster and quieter. It becomes harder to see, which makes it harder to eventually remove. Speeding up a process before simplifying it locks in the extra steps at a faster pace. Simplifying before questioning the requirement means polishing something that should have been deleted. The sequence exists because each step only makes sense once the step before it has actually been done.
Applied to a small IT team, the first move is not a technology decision at all. It is a question: why does this exist? Why does an approval require three people instead of one? Why does a request take five steps to resolve instead of two? Why do two tools end up doing the same job? In a lot of cases, the honest answer has nothing to do with anyone’s competence. The requirement made sense once, and it simply outlived the reason for it. That is the signal to delete it, not automate around it.
Why This Matters More With a Small Team
In a large organization, unnecessary steps get absorbed. There are enough people that a redundant process is an inconvenience, not a crisis. A small team does not have that cushion. Every step that should not exist is a direct tax on the capacity of people who are already covering more ground than their job title suggests. The margin for waste is much smaller, which means the return on removing it is much bigger.
That is also the real advantage of a small team, if it gets used deliberately. There is no bureaucratic weight protecting a bad process just because it has existed for years. There are fewer stakeholders to convince before questioning something. The size that makes the breadth of the job harder is the same size that makes it possible to move fast on fixing it, as long as the questions come before the changes.
Two weeks is not enough time to have all the answers. It is enough time to start asking the right questions, in the right order, before complexity has a chance to calcify into “how we’ve always done it” again. The instinct when the workload is this broad is to reach for more of everything at once: more tools, more process, more people. None of those instincts are wrong. They are just premature until the questioning happens first. Question what exists, remove what does not need to, simplify what is left, speed it up, and then decide what mix of automation, tooling, and headcount the work actually calls for.
What has your experience been stepping into an environment you did not build? How much of what you inherited turned out to be necessary once you actually asked?
Discussion
Comments are powered by GitHub Issues via utterances. A GitHub account is required to comment.