The question of how to organize IT in a company comes up frequently, and it’s one of those questions where the answer is never simple or one-size-fits-all. The structure of IT within an organization depends on numerous factors—how the company views technology, what its goals are, and even the personalities involved. Over time, as the business grows and evolves, the structure might need to change as well. To navigate this, let’s break down the key considerations.
Where Should IT Report?
One of the most fundamental decisions in structuring an IT organization is deciding where IT reports within the company. This isn’t just a technical decision; it’s deeply tied to how IT is perceived and valued by the company’s leadership.
If a company sees IT as integral to its future—something that drives innovation, optimizes operations, and creates competitive advantage—then IT will typically report directly to the CEO or President. This reporting line signals that IT is a strategic asset, central to the company’s mission and long-term goals.
On the other hand, in companies where IT is seen primarily as a support function—a department that exists to keep the lights on, manage basic systems, and automate routine tasks—it often reports to the CFO or even an Accounting Manager. In these cases, IT is viewed more as a cost center than a strategic driver. It’s there to ensure the financial systems are running smoothly, not to push the boundaries of what the company can achieve.
The reporting structure can have profound implications for how IT operates. For example, if IT reports to the CFO, the focus may skew heavily towards cost control and efficiency, sometimes at the expense of innovation. A company with this setup might excel at tracking expenses down to the penny, but it might miss out on opportunities to leverage technology to grow revenue or gain a competitive edge.
If you’re in IT and find yourself frustrated with the current reporting structure, it might be a signal that IT’s potential isn’t fully recognized. Changing this perception involves convincing the company’s leadership that IT can do more—much more. But be aware, this often requires a level of experience and strategic thinking that not all IT leaders may possess at the outset. If the current IT leadership is seen as too junior or too narrowly focused, the company might be reluctant to elevate IT to a more central role without first addressing these leadership gaps.
Centralized vs. Decentralized IT
Another major consideration is whether to centralize or decentralize IT operations. This debate is as old as IT itself, and companies often swing between the two approaches as they search for the right balance.
Centralization tends to be favored when the goal is efficiency and standardization. By centralizing IT, a company can achieve economies of scale, streamline purchasing, enforce consistent standards, and reduce redundancy. This is especially important in areas like infrastructure management, where consistency and cost control are paramount.
However, centralization can also lead to rigidity. When IT is too centralized, it can become disconnected from the needs of individual business units. A centralized IT department might be great at managing large-scale systems and setting company-wide standards, but it might struggle to respond quickly to the specific needs of different departments. This can lead to frustration, as business units feel that IT is out of touch with their day-to-day challenges.
Decentralization, on the other hand, puts IT closer to the users. When IT is decentralized, each business unit can have its own IT team that understands its specific needs and can respond quickly to changes. This approach enhances responsiveness and ensures that IT solutions are tailored to the unique requirements of each department. But the downside is that it can lead to inefficiencies, duplication of effort, and a lack of standardization. Without a central authority, different parts of the company might develop incompatible systems, making it harder to integrate data and processes across the organization.
Most companies eventually try to find a middle ground, centralizing certain aspects of IT while decentralizing others. For example, core infrastructure, security, and enterprise-wide applications might be centralized, while application development and support could be decentralized to ensure responsiveness to local needs. Striking the right balance is challenging and often requires ongoing adjustments as the company evolves.
Splitting or Matrixing IT Reporting
In some organizations, IT is split across different reporting lines, reflecting the diverse functions that IT serves. For instance, infrastructure management might report to the COO, reflecting its role in keeping the company’s operations running smoothly. Meanwhile, IT projects might report directly to the departments they’re designed to serve, ensuring that these projects stay closely aligned with the needs of the business units.
A more complex variation of this is matrix management, where IT managers have dual reporting lines. In a matrixed IT organization, an IT manager might report both to a functional manager within a business unit and to a technical leader within IT. The functional manager ensures that IT is meeting the business’s needs, while the technical leader ensures that IT adheres to company-wide standards and best practices.
Matrix management is theoretically appealing because it allows for both technical consistency and business alignment. However, in practice, it can be difficult to manage. Conflicts between the two reporting lines are common, and when they arise, it can be challenging to find a resolution that satisfies both sides. In the worst cases, matrix management can leave IT employees feeling pulled in different directions, unsure of whose priorities should take precedence.
Temporary Teams vs. Permanent Splits
Another organizational challenge is deciding whether to create permanent IT teams based on function or to assemble temporary teams for specific projects. Both approaches have their merits.
Temporary teams can be highly effective for major projects. They bring together the right mix of skills and expertise needed to achieve a specific goal, much like how a film production crew comes together for the duration of a movie. Once the project is completed, the team disbands, and its members move on to other projects. This approach allows the organization to remain flexible and responsive to changing needs.
However, permanently splitting IT along functional or technology lines can lead to problems. When teams are permanently assigned to specific functions or technologies, they can become siloed. These silos can make it difficult for the organization to respond to broader changes, as teams become entrenched in their ways of working and resistant to collaboration. Moreover, over time, these permanent splits can lead to inefficiencies and a lack of cohesion across the IT organization.
My preference is to use temporary teams for specific projects, allowing the IT organization to stay agile and focused on delivering value to the business. Once the project’s objectives are met, the team can be disbanded, and its members can be reassigned to new challenges. This approach keeps the organization dynamic and aligned with the company’s strategic goals.
What Should Your IT Department Look Like?
Ultimately, there is no single “right” way to organize IT. The structure that works best for your company depends on various factors, including the nature of your business, the skills of your IT team, and the specific challenges you face.
Start with what you have and look for ways to improve. Consider the trade-offs between centralization and decentralization and think carefully about how to align IT with your company’s strategic priorities. Be willing to experiment with different structures and make changes as needed.
One approach I’ve found effective is to centralize the more routine aspects of IT, such as infrastructure management and support, while decentralizing project work to ensure a close connection with users. For example, if you want your various systems to work together and share data effectively, then standards for data and software should be managed—if not directly controlled—by a central IT group. This central group can ensure that the company’s overall technology strategy is cohesive and aligned with its long-term goals.
However, when it comes to projects, it’s crucial to maintain a strong relationship between the project team and the end users. This connection ensures that the project delivers what the users need and that they feel confident throughout the project’s lifecycle. While you could achieve this by having projects report directly to the user organization, this approach can sometimes diminish the focus on technical standards. To avoid this pitfall, consider alternative ways to strengthen the relationship between IT and users, such as physically colocating IT staff with users or encouraging more informal interaction between them.
The Fundamental Rule of Organizations
There’s a fundamental truth about organizational structures: they’re often shaped more by dissatisfaction than by strategic planning. When people are unhappy with the service they receive, their first instinct is often to change the reporting lines—bringing the service organization under their control in the hopes that this will lead to better outcomes.
Conversely, when people are satisfied with the service they receive, they rarely pay much attention to the organizational chart. They don’t care where IT reports, as long as it delivers what they need.
The takeaway here is simple: if you keep your stakeholders satisfied, you have the freedom to organize IT in whatever way makes the most sense for your company. Start with an approach that seems to work, and be prepared to adjust it as circumstances change and new challenges arise.
In the end, the best IT structure is one that aligns with your company’s goals, supports its strategic priorities, and remains flexible enough to adapt to changing needs. There’s no one-size-fits-all answer, but with thoughtful planning and a willingness to experiment, you can find the structure that works best for you.