A family friend of mine works in IT for a popular retailer. She has had 7 bosses in 9 years. She is out looking for new company. I was visiting another firm and saw several Dilbert cartoons posted on some cubicle walls. Employees were joking around about the cartoons, except it wasn’t jovial. The banter resembled gallows humor. It had that tone.
Another professional colleague of mine had spent the last decade in big consulting on the “almost partner” track (including a stint with a failed firm during its grand implosion). He recently landed with a good niche consulting firm looking for some traction and some runway. That runway lasted a year as the firm merged with a much larger corporation. In a moment of frailty, this otherwise nearly invincible IT veteran was discussing the toll the stress is taking, and not in casual terms. The stress is poison and is killing him, he said.
Just the other day, a group of us CIOs were discussing why one of our colleagues was absent for our quarterly industry special interest group meeting. “He had a last minute meeting about a major reorganization. He didn’t know what it was about and had to skip our meeting,” explained one member of the group. A moment of silence in Dilbert-like support for this CIO was had. When the CIO is the last to know about a re-org, it does not bode well. We quickly glossed over the somber moment as easily as one peels a banana. It’s just another day. Next item on the agenda…
I’ve spent years reading job descriptions for IT jobs. Many industry, technology and human resources consulting firms offer lists and lists of job descriptions. Within them you see the archeological layers revealing the evolution of the IT worker. These lists of job descriptions are based on the sum total of ad hoc activities of many firms, firms that had and still do continue to go through upheaval and reorganization. Have we been defining IT jobs all wrong? Is this the reason my family friend has had 7 bosses in 9 years, why corporate IT re-orgs are incessant? Are we blindly trying to mash the pieces together in a new combination that we hope works?
Blindly, yes. And I believe that the firms doing the organizing and reorganizing badly share some common factors.
Common factor 1
Firms don’t have enough time to understand all the pieces. In order to make deadlines, new boundaries must be drawn quickly and imperfectly. The thought of taking more time in “analysis” of the reorganization to help speed up progress later gets swept up and dumped in the trash can joining the other methodologies that have attempted to do the same. Many firms simply don’t have time to think a deep and sustained thought. Until they do, they will be doomed to the endless cycle of premature and perpetual reorganizations. They will stay in the management blender on the frappe setting.
Common factor 2
Those who make the reorganization or job definition decisions do not have enough information or skill to do it well. These people are often blind to or shielded from an effective assessment of the real worth of units and individuals and must rely on the “average” anecdotal and often distorted response from typically biased players in the firm. Vultures always circle, ready to pick the bones.
Common factor 3
People doing the defining or reorganizing almost always think about the structure first rather than people first. I’ve seen teams draw boxes, put labels on the boxes, draw lines between the boxes and then finally place the names of people in these boxes. This causes executives and mid-managers to reason from their own imperfect knowledge about what they believe a structure ought to look like rather than letting their thoughts emerge from a more detailed and thorough “bottom-up” understanding of the situation. They get boxed in by their own thoughts.
I’ll offer here some suggestions for IT shops and firms looking for the magic team alignment.
Suggestion 1
Pause. Ignore the temptation to manufacture a reorganization success by a certain date. Subtle contextual forces can help teams gel in unforeseen ways. Let the details of the structure naturally emerge. Turn up the heat, yes, but don’t remove the pot from the stove before the soup is done. Once this simmering process passes a critical point, the structure can crystallize quickly. To somewhat mix the metaphor, implementing a reorganization before the crystallization process completes is like pushing water uphill.
Suggestion 2
How do you know when crystallization is coming? You will know when your managers move from “smiling and nodding” and other forms of passive resistance to suddenly sharing common assessments with each other and communicating spontaneously about features of the new structure clearly. There is a difference between a mandated structure and one co-created by the teams. Build a co-creating management pool. Work bottom up throughout the organization to collect assessments. Spend the time to really understand the internal value chain. Think carefully about how people can group activities into job roles in creative ways. Turn assessment of the organization into a form of team knowledge. Share and validate each manager’s assessment of people and units communally. Discuss among your managers the similarities and differences between assessments so that the managers understand each others’ differences in assessment perspectives. Discussing the differences between assessments helps to sharpen and quicken organizational assessment capabilities. Assessment and action cannot be easily separated, so treat excellent assessment as the first step to action.
Suggestion 3
Work from skills and passions of people first and then work towards the reorganization. Reorganizations are often done based on a thin assessment of what people or units appear to be performing poorly without deeper insight as to the causes of the performance problem. Since IT work is knowledge intensive and communal, knowledge productivity can be greatly enhanced through the proper team engagement of individual passion and emotion. A new structure made with the same old inability to cleverly align people’s passions with the team’s mission will not stick.
A line from the Tao Te Ching haunts me. “Ruling a country is like cooking a small fish.” The inference we are left to draw from this line is that if we handle such a delicate thing too much it can break apart.
Meat cleaver approaches to both reorganizations and job descriptions are inferior. The knife that hacks wildly harms the chef too. More subtle, nuanced and contextual approaches for fostering teams that gel will give better results. That is if firms can stand the cook time. Maybe they can’t and that’s why they are getting out of the kitchen.
Vince Kellen is Vice President for Information Services (CIO) at DePaul University and a member of the faculty for DePaul's computer science graduate program