For as long as I can remember, I've been obsessed with organizational structures. Creating an optimal org design is critical. Titles and reporting structure matter, even in the most progressive of companies. Who reports to whom, decision rights, and compensation are all determined by the formal organizational structure.
When I became CIO, I spent countless hours working on org design. I went as far as putting names and titles on tiny squares of paper and arranging and rearranging the org chart on the floor of my living room. I believed the perfect structure was out there; I just hadn't found it yet. I was in search of the org equivalent to Einstein's E=MC2, a simple and elegant answer to all of IT's problems. At the risk of pushing my metaphor too far, some of the org designs I've attempted seem more like Schrödinger's equation than the theory of relativity. I finally concluded that there was no such thing as the perfect IT org chart. Every org design comes with trade-offs.
To create the best possible org design for your company's needs, you need to first pretend that everyone on your team died in a fiery plane crash, and start over. Too morbid? Then simply imagine that they all went in on a lottery ticket and hit the jackpot. Whatever mind trick you use, you need to get the existing players out of your head, or you'll end up designing your org around their skills, weaknesses, and aspirations, instead of the needs of your business.
To create your org structure, you first need to understand the work, then build the best structure to organize that work, and finally fill the roles with the best possible people you can get.
Document the services you provide to your business. Typical IT Departments perform these functions: strategy, architecture, application development, infrastructure, operations, support, cyber-security, and portfolio/program/project management.
You also need to account for the “business of IT.” Budgets, people development, and communications are examples of functions your “IT business” needs. Consider yourself the CEO of IT, and run IT like a business. Now, who's your IT CFO, your IT CPO, and your head of communications? By the way, don't put CEO of IT on your business card, since that could be a career-limiting move.
Once you have your direct reports in place, take it down to the next level: e.g., sales apps, financial apps, analytics, supply chain, cloud computing, cyber-security, and operations.
Sketch an org chart that best meets those needs. Do not consider people—remember, they are all on a beach drinking Mai Tais. I recommend going down two levels, including directors and managers. If you are designing an Agile organization, this may only include directors, since you typically won't have any managers.
Run use cases through your draft org design, and determine how well or poorly the following would be accomplished in your new org:
When evaluating the use cases, make sure each is accounted for in your structure. This exercise should pressure-test your org design. If there's a gap, go back to step 2.
Document the skills needed for each position. This is essentially the job description. Write down the mandatory skills and the nice-to-have skills. Are you cheating? Keep those current employees out of your head. (This is why the plane crash works better than the lottery ticket.)
It's finally time to consider the existing team members. Map them to the org chart. Don't force it. If there's a perfect fit between an existing employee and the newly designed role, congratulations: you have the right role and the right person for the job. Where there's a close fit, with one or two missing skills, work with your HR partner to develop a career development plan for that employee. Where you have a role with no qualified internal candidates, it's time for an outside hire. If you have people left over, you have the following options:
Next, we'll look a little closer at the org structure and org chart. Chapter 13, “Org Design—Just Show Me the Answer,” demonstrates one possible model of an org chart. Chapter 14, “Organization Design and Culture,” discusses just how much the org chart does—or does not—matter.