Read an Excerpt
CHAPTER 1
SITTING ALONE
I don't know why we are here, but I'm pretty sure that it is not in order to enjoy ourselves.
— Ludwig Wittgenstein, conversational remark
Well chaps, first I'd like to say a few vile things more or less at random, not only because it is expected of me but also because I enjoy it.
— Donald Barthelme,Snow White
I've read a number of books on IT leadership and how to be a good CIO. None of them mention the major change of the last two decades: the rise of Agile and Lean practices for IT delivery. I've read plenty of books on Agile and Lean practices for IT delivery. None of them explain the role of IT leadership in an Agile world. The two domains are evolving separately: The field of IT leadership continues to frame its problems in its same old ways, oblivious to the deep changes brought on by the Agile revolution, while the Agile world, ever suspicious of management, proceeds as if it can manage without the involvement of IT leaders.
Surprisingly, this divergence continues despite the deep influence of Agile and Lean thinking on general — that is, non-IT — management. The disciplines continue to evolve separately even though corporate strategy is increasingly about both agility and IT strategy. The two worlds do not converge, even though IT leadership books advise CIOs to pull themselves closer to strategy formulation and claim a "seat at the table." But while the other C-level executives around the table are discussing the need for agility, senior IT leaders, eager to gain or retain a seat at the strategy table, are pursuing the path of demonstrating the value of IT ... by locking in old-school practices that encourage rigidity.
Agile and Lean thinking represent, simply, the best way we know of practicing IT. The techniques of Continuous Delivery (CD) and DevOps might have originated with the so-called "unicorns"— the leading technology companies — but they have spread quickly through the "horses" to the "donkeys," dramatically increasing their deployment velocity and market responsiveness and in the process becoming table stakes for playing in competitive industries. The Puppet Labs and DORA 2016 State of DevOps Report found that those high--performing horses and donkeys spent 22% less time on unplanned work (a proxy for quality) and 50% less time remediating security flaws, experienced 2,555 times shorter lead times, and had employees who were 2.2 times more likely to recommend their companies as a place to work. The stock market bets happily on those horses, as they show a 50% higher growth in their market capitalization over three years.
Admittedly, IT is always changing, and rapidly. Suddenly, we were delivering for desktops rather than mainframes; for client-server architectures rather than monolithic ones; for distributed abacuses, n-tier whatchamacallits, clouds, extra-large-size data, re-oriented objects. Our services became microservices, apparently skipping right over milliservices on their way to becoming nanoservices. Our Businesses had Intelligences and our Internet filled with Things. We outsourced, we insourced. In this context, it is tempting to see the Agile/Lean movement as simply a buzz term that describes how we deliver IT product today.
In fact, these changes of the last 15 years are revolutionary: they are not about the mechanics of IT system delivery, but about what IT is, how it should be managed and led, and how it fits into the enterprise. Yet somehow, the literature on IT leadership and the techniques taught to current and future CIOs through books, seminars, conferences, and membership organizations continue to emphasize a decades-old, control-oriented paradigm that is inconsistent with the new Agile ways of thinking. This inconsistency, as I will show, runs deep — there are very good reasons why the CIO community is not taking advantage of the powerful changes brought on by the Agile revolution (revolution, yes — it even has a manifesto!).
Because of this divergence, senior IT leadership is pulled from one new marketing buzzword to the next, drawn to the trend of the day, while missing the deeper currents that could change the way technology is used to drive business value. Locked into an understanding of its role that involves protecting or striving for a seat at the table, practicing governance, finding cost efficiencies, executing projects against defined milestones, and delivering service with a smile, IT leadership is blindsided by IT-like initiatives it plays no part in — initiatives executed by shadow IT organizations, rogue developers, and the newly knighted Chief Digital Officers and Chief Data Officers.
Indeed, the prevailing wisdom about what makes for good CIO leadership would make an Agile thinker squirm.
As the project reaches each gate in a series, the project is reviewed with sponsors, the project team, and the project management office for progress against goals and key risks. Each gate calls for a go/no-go decision for the next stage of activity and funding.
So say Richard Hunter and George Westerman in The Real Business of IT: How CIOs Create and Communicate Value, perhaps missing the point that this is a faithful description of the old school Stage-Gate or Waterfall model that Agile approaches reject. One CIO, answering the question of how to maintain control over IT in Martha Heller's book The CIO Paradox, says, "You do that through very rigorous architectural thinking, planning, and review." The Agile Manifesto, on the contrary, says that "the best architectures emerge from self-organizing teams"; its focus is on experimentation and evolution rather than on trying to plan architecture "very rigorously" in advance.
While Agile organizations increase delivery velocity on the theory that rapid feedback cycles and early delivery of value are critical, Heller advises CIOs to "understand that one of the most evolved of all executive traits is the ability to be patient, the ability to balance the need for speed with the patience to set things up correctly." Hunter and Westerman seem to agree: "Successful CIOs don't skip steps, and they don't run them out of sequence."
But Agile and Lean approaches recommend that teams put product in the hands of users quickly and then continuously refine both the product and the team's practices, rather than waiting for perfection before starting or "moving on to the next step." Risk is managed not through cautious planning but through bold experiments combined with frequent inspection, feedback, and adaptation.
When Hunter and Westerman say that IT must demonstrate value through "on-time project delivery, on-budget project delivery, and 'first time right' application delivery," are they aware that the Agile community speaks instead of maximizing business value delivered, creating minimal viable products which are later incrementally enhanced, and even of testing in production?
IT leadership experts have struggled to express the practical implications of the changes brought on by our increasingly Agile, digital-service-driven world. George Westerman, in his book Leading Digital: Turning Technology into Business Transformation, encourages us all to become digital masters. Digital masters, he says, "use technology better than their competitors do and gain huge benefits ... [they] see technology as a way to change the way they do business." Well, of course they do.
Peter Weill and Jeanne W. Ross think it's important that businesses become IT Savvy. "IT-savvy firms distinguish themselves from others by building and using a platform of digitized processes ... to disengage people from processes that are better performed by machines," they explain. To me, that sounds more like the slogan of the Industrial Revolution, not advice for IT leaders adjusting to the digital age. I don't disagree with these thinkers, but how exactly (or even approximately) should IT leaders make their companies IT-savvy digital masters?
I don't mean to pick on Westerman, Weill, Ross — and especially not Heller — who've written much that is helpful and to the point. But the implications of the last few decades — the changes brought on by the Agile, Lean, and DevOps movements and the increasing importance of digital services — are much more profound than these glib pronouncements would indicate.
*
Surprisingly — and ominously — Agile thinking has gone right around IT leadership to influence non-IT executives, with books like Eric Ries's The Lean Startup, which makes validated learning a critical goal for the enterprise and argues for moving quickly to implement minimal viable products and hasten corporate learning. In fact, Agile and Lean approaches — which, in truth, are management techniques rather than technical practices — have spawned literature that bears on general corporate leadership. Non-IT executives can learn how to apply intrinsic motivation techniques from Daniel Pink's Drive, and can learn to see the business as a Complex Adaptive System — an evolving organism that continuously adapts to environmental factors and incentives set by leadership (from The Biology of Business: Decoding the Natural Laws of Enterprise, edited by Henry Clippinger III).
The literature on autonomous teams in the workplace is substantial — Harvard Business School Press, for example, publishes Richard Hackman's classic book on the subject, Leading Teams: Setting the Stage for Great Performances. General Stanley McChrystal's book Team of Teams draws lessons for businesses from the military's increasingly agile ways of organizing to fight global terrorism. And the Beyond Budgeting movement teaches executives that the artificial annual budgeting cycle is not agile enough for corporate planning. All of these ideas have been deeply influenced by Agile IT thinking. While the writers on IT leadership are talking about the "need to be digital," non-IT leadership is already absorbing the lessons of actually becoming digital.
To further complicate matters, senior executives, and indeed everyone in the enterprise, have become more sophisticated in their use and understanding of the technology. They have high-speed wireless networks at home, smart watches and fitness bands, media streaming out of their devices and into their sensory organs. They shop online and ask Google, Siri, or Alexa when they have a question. Their standards for usability and functionality are high and climbing. Many of IT's partners and users have learned to talk intelligently about the cloud; they know about big data and predictive analytics; their wearable devices have more computing power than IT's servers had a few years ago. I mean, ordinary folks in the company have already learned just to hit the restart button on devices that aren't working right — what more can we teach them?
Any C-level executive can see that Facebook is changing the features on its site every day, while IT projects in his or her own company are still spitting out dribs and drabs on quarterly or annual release cycles. Yes, there are very good reasons why IT is run the way it is, and yes, IT leaders increasingly understand why Agile and Lean techniques are important for product delivery and project execution. But that is just the point — they are framing the new ideas in Agile and Lean thinking in terms of an old paradigm and missing their deeper implications. As I will argue later, IT leaders should not even be talking about product delivery and project execution. The world has moved on, and we should be glad of that — the old model wasn't working all that well for IT leadership.
Perhaps the most far-reaching change to consider is in whom executive leaders look to as their corporate models — whose strategies, cultures, and competitive tactics they study in business school and try to emulate. Netflix, Google, Amazon; the "unicorn" leaders of the technology world, of course. These companies are not just business role models but familiar and important to the company's executives in their daily lives. Leaders want to run their companies more like these successful technology companies, and who is in the way? Generally, it is the IT department, which is still producing more Gantt charts than useful product.
Non-IT executives are now speaking the language and technique of IT. But many IT executives are not.
*
If not adapting to Agility, then what are CIOs concerned with?
The typical book or blog on IT leadership asserts — as it has for decades now — that the CIO needs to claim a seat at the table — that is, a place among the strategic-thinking C-level executives who report to the CEO. Jill Dyche, in her book The New IT: How Technology Leaders are Enabling Business Strategy in the Digital Age devotes an entire chapter to "Getting and Keeping a Seat at the Table." In the study on "The DNA of the CIO," they say that "securing a seat at the top management table is — and should be — a key priority for CIOs," but point out that less than one in five CIOs occupy such a seat. A 2016 article in InfoWorld online called "CIO's May Finally Get a Seat at the Grown-Ups' table" starts out "for as long as I can remember, CIOs have obsessed about getting a seat at the executive table."
Some of these obsessive CIOs already have one, of course, but those who don't, according to these sources, must learn to put technology aside and develop the skills of C-level executives: financial savvy, polished communication, strategic visioning, and customer intimacy. It is interesting that this is posed as some kind of a difficulty. These writers seem to assume that CIOs are naturally all introverted, anti-social techno-nerds. Is the invitation to join the strategic table being withheld because the CEO doesn't believe that IT is strategic, or because he or she does not believe that someone with technological savvy is capable of playing a strategic role?
How, according to these books, should the CIO go about gaining the coveted seat at the table? There apparently are a number of preconditions, according to the literature. "Show value for money before you try to prove that IT is an investment in future business performance," Hunter and Westerman say. Let's think carefully about that statement. IT leadership should first focus on things other than future business performance (to demonstrate trustworthiness) before doing the things that the business is trusting IT to do (influence future business performance). Does that sound right?
The CIO must, according to the literature, "sell" the accomplishments of IT. He or she must show that he or she can think and act like an executive and demonstrate that he or she can be trusted to keep the business's interests in mind — most importantly, by controlling the costs and schedules of IT projects. Hunter and Westerman give examples of ways CIOs can prove IT's value through measurements, including uptime, application performance, on-time project completion, and "first time right application delivery." The not-so-hidden assumption here is that IT is not businesslike; the CIO must prove something, show business value, demonstrate business savvy. The CIO must earn a seat at the table.
As a consequence, IT leadership has been obsessed with demonstrating value by establishing control over IT project execution. According to a 2015 survey by the CIO Executive Council, 53% of senior IT leaders believe that "proving the business value of IT's contributions" is "highly important" and a further 39% believe it is "important." IT leaders set up Project Management Offices (PMOs) — not only to ensure on-time and on-budget delivery but also to prove that such delivery is occurring. Because proving on-time delivery is the price of a seat at the table, the CIO must fight against anything that would make it harder to demonstrate that control. PMOs, for example, are encouraged to be enemies of the dreaded "scope creep"— that is, changes that the business stakeholders request when they realize that a system won't actually meet their needs as specified ... but which might make it difficult for IT to show that it is delivering on schedule.
There is a danger that the CIO's struggle to prove that he or she is delivering value will actually destroy business value for the company. Because not all IT-related spending is directly under his or her control, the CIO is often forced to exert influence through policies, standards, bureaucracy, and no-saying. IT "adds value" by constraining solution formulation and delivery through its Enterprise Architecture standards, by slowing down delivery to users through its governance processes and maturity models, and by adding overhead through risk-averse security policies. By saying "no" to any work that would make it difficult to show that IT is under control — scope changes, exceptions to standards, newly unveiled technologies — IT is swallowing up forkfuls of potential business value.
(Continues…)
Excerpted from "A Seat at the Table"
by .
Copyright © 2017 Mark Schwartz.
Excerpted by permission of IT Revolution Press, LLC.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
