Exceptional IT just works. Everything else is just work

This article is unusual. There is no “one simple trick,” nothing Steve Jobs said, no savior message to make you feel important. It will only challenge you to accept what we already know.

To avoid confusion:

• What is IT? For this article, IT is strictly an internal organizational function, not a service provider or consultant. The business of IT has little in common with the function of IT.
• What is success? Success is when the IT function is recognized objectively (utility) and subjectively (value) as a value-center, a competitive advantage to be leveraged, an investment to be maximized.
• How? Create capability, eliminate effort… everything else is overhead. Without this principle, our work may be useful and valuable, but we can’t create utility or value.

A Caution: Do not confuse personal success with IT success. IT is a resilient “black box,” and in the absence of peer comparison, organizations often assume any status quo is normal. The visible effects of failure can be hidden long enough for personal advancement, and someone will always take advantage of that.

Ok, on with it

I’ve been up and down the IT ladder and consulting for 37 years. Once in a while you come across an organization that loves their IT–I mean legitimate, gushing, surprisingly well-informed praise. The whole operation is years ahead. The IT team loves a challenge, treating every problem as an excuse to do something innovative. They have big responsibilities and limited resources like everyone else, but they don’t seem burdened. If you ask them, they’ll tell you they aren’t following any particular framework, they’re just doing “what makes sense”. They aren’t even aware how unusual they are.

This isn’t a research paper, but when you look closely, you find that they’ve instinctively adopted principles echoed in Transformational Leadership Theory, Leader-Member Exchange Theory, Self-determination Theory, Lean and similar works. There’s no mystery why they succeed, they just “get it” intuitively and express it by design.

It’s not that “normal” teams lack ideals like “value first”, “KISS”, “iterate with feedback”, etc. But in successful teams, those properties emerge naturally from following deeper principles.

By no means complete, what follows is a summary of observations collected over decades… for your consideration.

The most successful IT teams have colleagues, not customers

I am an ITIL Master. ITIL, like Agile/Scrum, COBIT and others share a fundamental flaw for IT: they are built upon a provider/customer model. This is great, if you are actually a service provider, selling services to actual customers and subject to actual market forces.

Applied internally, however, IT binds itself to transactional thinking, forced to weigh its own interests against other interests of the organization. When governed by artificial economics such as chargebacks, those economics replace strategy. The results are predictable: silos of effort, fragmented funding, priorities wildly misaligned and a growing reluctance to take initiative. Organizations do not win by writing themselves a bunch of checks.

Decades late, but welcome, recent studies favor a “peer collaboration” model for these reasons and more. The people who work in your organization are your colleagues. Executive, salesperson, custodian, rocket scientist, IT… same mission, same bank account. Each brings their unique skills and resources to further the mission so everyone can keep getting paid for their contribution.

Artificial friction is not required to control workload, there is plenty of real, strategic friction to go around. What IT is asked for is often poorly conceived or uninformed, sure, but those are the conversations we want IT to have; they serve to better the organization. “Have you considered changing this process? It looks like if we do X, and you get rid of Y, we get a better outcome.” or “That sounds like a request from another group, maybe there’s a bigger need we can address.” Transactional relationships kill thoughtful engagement. Consultative relationships translate into real utility.

The most successful IT teams adopt a much tighter relationship that sheds the cost and limitation of the provider/customer model. Being part of the team is a success mindset.

The most successful IT teams stay close to ‘the business end’

Whatever your organization’s product is, IT should be near it and understand it, making decisions in context. The value of early, informed advice cannot be overstated. Nevertheless, gravity and safety will pull IT toward the center, waiting to be asked, told or paid to participate. That’s thinking like a cost-center.

Value-centers are involved — it energizes them. They project expertise, anticipate needs and embrace the invisible, thankless task of addressing them in advance. Having strategy and authority at the edge is critical to creating competitive advantages on a business-by-business basis.

That is not an IT-alone approach. Left to metrics, IT will meet the metrics to the exclusion of everything else. Leaving millions on the table to save thousands is shockingly common. The metrics themselves aren’t the problem, measurement is necessary, but so is messaging. If you happen to live in the C-Suite, you already know this, but many forget: We hire smart people to generate an advantage, not just keep the lights on. What we say is heard, but what we measure speaks louder. If the metrics imply that strategic contribution is secondary, the team will stop contributing.

What drives success has never been alignment, it’s convergence. Integrating at a more fundamental level is second nature for some, impossible to imagine for others. In either case, if success is the goal, then support for convergence must come from the center, pushing IT out of the nest and into the fray.

The most successful IT teams strongly favor ‘working leadership’ over ‘professional supervision’

Two things are true:

• First, the task supervision of IT professionals is trivial. Technical teams can self-organize and work competently with minimal oversight. Agile didn’t invent this.

• Second, the volume of systems, processes, dependencies and decisions that require daily awareness and judgment is comically enormous. Monolithic hierarchies — tall or wide — aren’t designed for world-building at speed or scale.

The typical IT team has a massive overhead to manage and, counterintuitively, the more bodies there are, the less likely they’re in the right places to manage it. Past decisions block today’s opportunities, and the decision pipeline has neither the time nor expertise to evaluate them. The backlog fills with half-prioritized work, momentum fades, tech debt accumulates, catch-up work dominates, frustration becomes apathy. Eventually, things tip over, there’s a reset, the org chart changes — and the cycle starts again. Sound familiar?

Consequently, the most successful IT teams adopt and viciously defend a broadly distributed strategic management function. Every position is encouraged to contribute to strategy, but importantly — no one exclusively so. Everyone has a functional role, and functional time is fiercely guarded.

This supports success in multiple ways, but above all, it creates leaders. It bears repeating: for  IT, respect is the currency of the realm. “Authority” is treated to professional courtesy, while “Leaders” are chosen independent of the org chart… usually those whose effort, judgment and principles consistently create utility and value — i.e. they make the work easier.

Meanwhile, surfacing latent management talent requires exposure to consequence. The most successful IT teams are staffed and structured so senior members have the capacity to make critical individual contributions, while junior members are positioned and encouraged to contribute strategically.

Some feel threatened by it but having an entire team of leaders is sublime and self-sustaining. You have a short time to show incoming talent what kind of environment they’re joining and showing them, a team of leaders produces far better results than the alternative.

IT leadership is about design. Designing a system around people is as much a management discipline as it is engineering. Designing details so that users not only accept but prefer the world you’ve built for them is low-key “The Matrix”. Doing it well is an expression of empathetic judgment that has enormous value.

Just to make that point clear: Do you have things that should be well-managed, but aren’t being managed today? Yes. We all do. Do you have enough people who are titled and tasked to manage everything you should be managing? No. None of us do.

It’s simple math, successful IT teams know that everyone needs to row.

The most successful IT teams are compact and cross-functional

IT teams scale poorly. The average “full service” IT department will experience an island of efficiency between 20-100 people, beyond which efficiency falls off a cliff.

I have a theory on that: In a team of 20, everyone must own something. Ownership encourages leadership. When you’re an “owner of one”, you need support, so you’re forced to collaborate. When everyone owns something and everyone collaborates, 20 do the work of 100. Adding people provides breathing room to focus more time on utility and value. Beyond 100, however, traditional organizational thinking takes over, siloing specializations and discouraging ownership outside of “leadership” roles. Territories form and work moves as a series of transactions in a system where strategy and operation are blind to each other. Would-be leaders aren’t challenged to rise, and the respect engine that drives IT breaks down. Without a functioning IT success cycle, 500 also do the work of 100.

However…in truth, this isn’t about the size. A large team can be effective, it’s just difficult to think small at large scales, and more difficult to sell that up the chain. One strategy is to break up a large IT department into a distributed model to better support the business… but not so fast, that doesn’t work either.

Instead, it’s the collaboration part of the equation that plays the biggest role. In a small team, collaboration emerges as a means of survival. In a large team, monolithic or distributed, collaboration must be engineered by design or neither model can be effective.

Cross-functionality replicates the compact, collaborative nature of small teams at speed and scale. It makes expertise portable and empowered to make good decisions without waiting for transaction, permission or translation.

Highly cross-functional teams reduce coordination cost, which is the hidden tax on all large IT teams. Every handoff is a delay; every dependency is a risk multiplier. When teams can internally absorb more classes of work – design, implementation, operation and improvement — the system becomes faster, calmer and more resilient. Teams that blend responsibilities, encourage cross-domain pairing and reward collaboration over territorialism see talent grow instead of stagnate.

The most successful IT teams favor independence, uniquity

Yes, uniquity is a real word. Microsoft’s spellcheck knows this; Google’s spellcheck doesn’t. Vendors fail in big and small ways every day. Total independence is rarely practical today, but last year’s high-profile vendor failures and betrayals should at least caution us against forming critical dependencies without an exit or resilience strategy.

Here’s the point: not everything unique is an advantage, but every advantage is unique.Competitive advantage hinges on choice, differentiation…uniquity. Dependence means your strategy is constrained by someone else’s roadmap, pricing model or failure modes. On top of that, the more you share a foundation with your competition, the less ground you have to compete.

This isn’t a purity test; we all have dependencies. We tell horror stories about that fragile legacy system everyone is afraid to touch. But that risk is entirely in our control. Third-party dependencies are entirely out of our control, yet often tightly coupled to our existence.

A few hyper-commoditized functions like email notwithstanding, successful teams treat vendors as an accelerator, not a foundation. There’s a subtle strategy here. They aren’t desperate to avoid a contract; they just embrace constant probing to see if they can achieve an advantage without dependency. They favor modularity and the ability to move freely, operating reliably when their vendors fail, ensuring the organization’s advantage by being difficult for competitors to copy… all by design. Your uniquity is your organization’s competitive advantage, even when your vendor fails to recognize it as a word (lookin’ at you, Google).

The most successful IT teams lead by design

“Make the right thing the easy thing” is a successful governance mindset.

“The best kind of work is the kind no one has to do” is successful automation mindset

“The best support is the kind no one has to call but wants to… the worst is the kind no one wants to call, but has to” is a successful service mindset.

It is common to assume these are different problems in different domains and fight each fire alone. However, to the most successful IT teams, they’re the same discipline: Design. Design is the most important management job IT does — or doesn’t — do. It is the most powerful tool we have to eliminate effort and gain the space needed to create capability. Good troubleshooting fixes a problem, good design fixes whole classes of problems before they occur. This is a very consistent differentiator: successful teams almost religiously focus on fixing the system over the symptoms. When we don’t have everyone aware of, involved with and thinking about design, we’re not using our resources effectively.

IT is naturally treated like a cost center because it contains the digital ghosts of everything that used to comprise organizational overhead. What used to be typewriters, bankers’ boxes and phones are now computers, servers and subscription sprawl. The medium changed. The perception didn’t.

Every principle described here exists to move work out of the overhead column, by design. Being part of the team eliminates costly imaginary friction. Cross-functionality reduces coordination cost. Staying close to the business converts effort into advantage. Distributed leadership turns management into force multiplication. Independence preserves choice. Good design makes work disappear entirely. Even metrics can be used to inspire instead of corner.

It’s all just good business sense and none of it is new.  Success is a natural end state of structuring IT as a strategic engine rather than a transactional utility.

That is why the most successful IT teams often look underwhelming from the outside. They are calm. They are boring. They are hard to measure with vanity metrics. They quietly enable the rest of the organization to do what the competition can’t and do it faster than the competition can.  They “just work” because that’s their natural state.

There’s no trick. There is only the far more difficult work of accepting that we already know how to do this…and just letting it happen.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?