Horizontal IT is Why You Can’t Be Agile

Posted on March 21, 2022.
A diagram showing a bar at the top for the parent organization, 5 vertical bars below it representing unique vertical brand silos. Below that is a horizontal bar representing a shared IT service that supports all these vertical simultaneously.
A far too common and outdated model for designing your organization

Software has eaten the world. If your business aspires to scale, respond efficiently to market demands and support emerging consumer consumption patterns in competitive timeframes you’re going to do it with software. To put it bluntly, you’re in the software business. Perhaps there was a time when segregating IT into a separate cost center made sense but in a world where business value is delivered through continuous software this concept doesn’t make sense. In fact, I’d argue the term IT (information technology?) is obsolete as well. 

The people who make the website are the people who make the business

At the dawn of the web the IT department were the people who maintained the mainframes and eventually the “people who made the website”. Today your technology teams are the ones who continuously evolve the value you deliver to market. Their role and influence over your success has fundamentally changed. It’s time to change how the organization is designed to reflect this. 

Article after article advocates for reframing your tech team away from a cost center and towards an integrated part of the business – a profit center. Given the outsized impact their work has on our success it’s high time to rethink what “tech team” means and how to empower these teams to deliver the most value from their efforts. 

Horizontal “IT” is the antithesis of an agile business

Bottling up the entirety of the team that designs, builds, ships and maintains the digital portion of your products and services traps a significant portion of the capability and capacity of that function in an assembly line model reminiscent of manufacturing or a fast-food production line. The diagram above illustrates a model I’ve seen repeatedly across large organizations. It assumes the tech department is a shared service functioning as an internal agency. They work on “projects” that have budgets determined externally. They are presented with fixed requirements and are asked to provide date-locked roadmaps. These deadlines are essential because the teams need to “finish” work for one department and move on to the next department’s order. 

This model throws agility and a customer-centered focus out the window. Instead, the focus is on delivering output, rather than outcomes. The work is considered “done” when the teams have delivered something that does what the client department has required. There is little done to validate whether this was the right set of features to build, the right way to build them or if the customer found them valuable. If a new requirement emerges, the requesting department has to place an “order” with the IT department. The team evaluates and estimates the work and places it somewhere in their prioritized list of work. Most of the time this prioritization rarely reflects the urgency of making the change. Getting “your” work done more quickly devolves into a game of political maneuvering and job-title posturing. 

Technology is not a department

Software is an integrated part of our businesses. In many cases it is, quite literally, the business. Separating technology teams from their colleagues in strategy, marketing, sales etc betrays a fundamental misunderstanding of how businesses thrive today. It indicates an organization that is unwilling to focus on their customers. It threatens the ongoing viability of the business with slow response times, lengthy decision-making processes and teams motivated to deliver output rather than make customers successful. 

Successful, modern businesses integrate their technology folks with the rest of the organization. It’s not uncommon for these types of businesses to seat software engineers, designers, marketers, product managers and subject matter experts together on the same squad. These teams are self-sufficient. They can learn, design, ship, sense, analyze, maintain and optimize their work independently. They can make decisions quickly. They can adjust course based on evidence they collect. They are lean and they are agile. 

Perhaps most importantly, these cross-functional teams build a shared understanding of the problems they’re solving, the people they’re working to help and the definition of success beyond just getting code to market. They’re no longer short-order cooks on a burger assembly line. Instead, they’re curious, collaborative product teams working together to quickly assess needs, determine potential solutions, validate their ideas and deploy consistently better versions of these solutions. This should be the goal of every organization.