Pharmaceutical companies do not successfully deliver drugs just because they hire a lot of highly skilled researchers in lab coats. They deliver drugs because they have people to secure funding for research of some drugs over others, to take them through lab and clinical trial, to steer them through regulatory approval, to manufacture, to make doctors aware of them, to distribute them to hospitals and pharmacies, and to follow-up on results. When it all comes together, the overall benefit of the resulting system can be incredible, such as an increase in life expectancy. As Thomas Teal wrote succinctly, “Good management works miracles.”1
The same applies to an Information Technology organisation that is core to achieving alpha returns: it needs the management practices to match high-capability people. Consider Xerox PARC. In the 1970s it spawned tremendous innovation in personal computing technology. From those innovations came products, solutions, and even categories that didn’t previously exist. Billions of dollars of revenue and profitability were generated – for everybody but Xerox. Why? Bright people were inventing and innovating, but nobody was there to monetise their work.2
In general, IT has structural and social deficiencies that conspire against development of a management capability. Technical IT jobs offer individual satisfaction on a daily basis, with frequent feedback and acknowledgement of success at solving a very specific problem or challenge. IT reward systems are also often based on individual performance tied to granular and highly focused statements of accomplishment. This is contrary to IT management positions where the results of decisions made may not be realised for weeks or months, measures of success are often less tangible, and rewards based on the performance of a large collection of individuals. It is also not uncommon for a company to belittle the value of management by defining it as a collection of supervisory or hygienic tasks e.g., to ensure everybody on a team has taken requisite compliance training each quarter and submits their timesheet each week. In other instances, line management may simply have all decision-making denied it, relegated to polling subordinates to find what’s going on to summarise and report upwards, while also being given messages from higher up to deliver to the rank and file. These aren’t management practices, they’re tasks of administrative convenience masquerading as management.
These deficiencies are supplemented by an IT industry that, on the whole, doesn’t place much value on management. Technical people promoted into management positions will very often resist management responsibilities (e.g., electing to continue to perform technical tasks), and also be highly unleveraged in a team (one manager to dozens of direct reports.) There is more precise definition and greater mobility of technical jobs than of management jobs. The same is true for skill acquisition: there are a wealth of IT oriented books, magazines, journals and publications on very specific technologies or applications of technologies, but not nearly the depth on matters of management. And all too often, what passes for management guidance in books and publications are lightweight abstractions of lessons learnt wrapped in layers of cheerleading and self-esteem building directed at the reader, not principles of sound management science. No surprise, then, that it can be far more attractive for an IT professional to prefer a career path of “individual contributor” over “manager.” Collectively, this doesn’t help increase in number the ranks of capable managers.
One of the root causes is that IT is considered a technology-centric business, as opposed to a people-centric one. 3 By definition, IT solutions – what the business is paying for – are not delivered by technology, but by people. The misplaced orientation toward technology as opposed to people means that management tends to focus not on what it should – “getting things done through people” – but on what it should not – the “shiny new toys” of technology assets. This misplaced focus creates a deficiency in management practices, and widens the capability gulf relative to the demands being placed on IT today. It is a structural inhibitor to success in delivering solutions.
Top-down, high-control management techniques have proven to be orthogonal to the IT industry. Amongst other things, this is because of a high concentration of highly-skilled and creative (e.g., clever at design, at problem solving, and so forth) people who don’t respond to that style of management. It is also because top-down practices assume an unchanging problem space, and thus an unchanging solution space. Unfortunately, this is not a characteristic of much of what happens in technology: IT solutions are produced in a dynamic, creative solutions space. For one thing, most projects are in a constant state of flux. The goal, the defined solution, the people, and the technologies constantly change. This means day to day decisions will not move in lock step with initial assumptions. For another, in most projects there is not a shared and fully harmonised understanding of the problem: if anybody on the team has a different understanding of the problem, if there is latency in communicating change to each member of the team, or if somebody simply wants to solve an interesting technical problem that may or may not be of urgent need to the business problem at hand, decisions on the ground will be out of alignment with overall business needs.
Each IT professional takes dozens of decisions each day. The principal objective in managing a highly-capable organisation is not to take decisions for each person, but to keep in alignment decisions people take. Management of a professional capability is thus an exercise in making lots of adjustments, not pushing blindly ahead toward a solution. But facilitating lots of adjustments isn’t a simple problem because management doesn’t just happen by itself in a team. As Dr. George Lopez found out, changing to self-managed work teams isn’t a turnkey solution:
- With no leaders, and no rules, "nothing was getting done, except people were spending a lot of time talking." After about a year and a half, he decided teams should elect leaders.4
But that, too, isn’t enough. The basic management tools and structures must be present or this simply doesn’t work. Consider this description of Super Aguri’s F1 pre-race meetings:
- "The process is very formal," says Super Aguri sporting director Graham Taylor. "I chair our meetings and ask the individuals present to talk in turn. Anyone late gets a bollocking, only one person is allowed to talk at a time, and it absolutely is not a discussion. It … is absolutely the best way to share a lot of information in a short passage of time. … If you don’t need to be there, you’re not."
- … While the briefing process has always been with F1, the structure has evolved to absorb the increasing complexity of cars and the concomitant increase in team size. "When I started in F1 there were 50 people in the team, now there are 500," says [Sam] Michael, […Williams technical director]. "If you don’t have a firm hold, not everyone gets all the information. You need to have structure.”5
Consider how many layers a team, or even an individual developer, may be removed from a large IT programme. The lack of upward transparency from the individual and downward visibility from the programme management makes it nearly impossible to keep decisions aligned. This is where good management delivers tremendous value: the basic, focused structures of Agile project management – the daily stand-up, the iteration planning meeting, the retrospective, the iteration tracking report, the release plan – provide focus, structure, and discipline that facilitate maintaining alignment of individual and group goals. A salient point in the example from Super Aguri is that greater team capability makes the need to do these things that much more acute: the higher the degree of professional capability in the team, the more adjustments there can be to make, if for no other reason than the rapidity with which the highly capable will work a problem space.
“We are not a family,” Robert Lane, the CEO of Deere & Co, recently said.6 “What we are is a high performance team.” If IT is to deliver high-performance results – to be an alpha capability that contributes to alpha business results – it requires not only high-capability people but the management practices to match.
1 Teal, Thomas. "The Human Side of Management." Harvard Busines Review. April, 1996. I highly recommend reading this article. He deftly summarises the gap between the impact management has relative to the investment made into developing talent completely. It has arguably become more pronounced in the 11 years since this article first appeared.
2 Gross, Daniel. “How Xerox Failed to copy Its Success.” Audacity. Fall, 1995. Audacity, the business journal, has long since ceased publication which is a shame: it provided excellent snippets on business decisions, both successful and unsuccessful, in the broader context of their market conditions.
3 The change in moniker from “Information Systems” to “Information Technology” was, arguably, a step in the wrong direction. The word “systems” is expansive, and extends to solutions with partial technology component to them - or none whatsoever. “Technology” narrows the remit, and thus the business impact, of what we now call “IT.”
4 White, Erin. “How a Company Made Everyone a Team Player” The Wall Street Journal, Monday 13 August 2007.
5 Grand Prix Tune-Ups” F1 Racing Magazine. August 2007. As perhaps the first among high-performance industries, it’s interesting to see what sounds very much like a stand-up meeting being core to race day execution - and how it has allowed them to scale.
6 Brat, Ilan and Aeppel, Timothy. “Why Deere is Weeding Out Dealers Even as Farms Boom” The Wall Street Journal, Tuesday, 14 August 2007.
Labels: Agile Management, Corporate Psyche
¶ 12:02 AM
