# A Seat at the Table ## Metadata * Author: [[Schwartz, Mark]] ## Highlights That context—given the history of business management over the last few decades—is of an IT organization that is separate from the business and stands in a fraught and tenuous relationship with it. Agile approaches hold out the promise of solving this problematic relationship but have focused on the micro-context of individual teams and not yet effectively taken on the macro-context of enterprise dynamics. — location: [163]() ^ref-53170 --- I’ll go further: any IT leader who focuses on demonstrating value is simply wasting company resources; IT leaders should direct all their focus to delivering value. Which of the other executives at the table puts that kind of effort into demonstrating that they are adding value? Is the CFO preparing slide shows on how drafting the annual financial statements is valuable? — location: [424]() ^ref-16507 --- Business value is delivered by the enterprise with support from IT—IT is part of a whole, a complex system in which its ability to deliver value depends on factors outside of IT. The only way that IT can deliver business value itself is through cost-cutting within the IT cost structure—in all other cases that I can think of, IT is delivering product that might or might not then be used by someone else to deliver business value. — location: [489]() ^ref-52596 --- The rest of the enterprise does not want IT to treat them like customers, and does not want IT to “align” with them. What they want is for IT to deliver outcomes.26 This screams out for an Agile and Lean solution: deliver value—outcomes—quickly and frequently, and trim away everything else, since everything else is simply waste. — location: [509]() ^ref-62254 --- When IT leadership finds itself separated from the day-to-day creation of value but nevertheless has responsibilities—security, Enterprise Architecture, cost control, reporting on accomplishments, switching from Python to Ruby and back again, sounding good in front of its peers at conferences—it asserts its control through bureaucracy. — location: [571]() ^ref-24540 --- A picture held us captive. And we could not get outside it, for it lay in our language and language seemed to repeat it to us inexorably. —Ludwig Wittgenstein, Philosophical Investigations — location: [627]() ^ref-36917 --- IT capabilities, on the contrary, are long-lived, granular, evolutionary, in constant flux, and future-oriented. After the project to build a system is finished, well, somehow the system keeps costing money! There always seems to be more work to do on systems that have already been finished. How many a frustrated CEO has complained that IT costs never end? — location: [705]() ^ref-36433 --- IT and the business have long known that they were in an uncomfortable, codependent, abusive relationship. — location: [727]() ^ref-54666 --- When the business created a project, how could it know what a reasonable price tag for its set of requirements would be? Imagine yourself at a market in rural Codeistan trying to buy a fancy snow-globe souvenir or a Sergey Brin bobblehead, and there are no marked prices. You are sure you are being ripped off. The merchants can see that you are a tourist and have no idea what the prices “should be.” You also don’t quite get that there is no price things “should be”—prices vary depending on the circumstances. — location: [731]() ^ref-30124 --- Plans are good. They get people communicating and help align people around a common goal. They set a vision that knowledge workers can use to frame their creative work. They help everyone see dependencies and risks. They initiate a conversation about what is possible, and reveal assumptions that must be tested as the project proceeds. Plans can be used to get a sense of what resources might be needed to accomplish the work of the project, which can be important if there is a long lead time for procuring those resources. Agile approaches are in no way opposed to planning, and in fact place a high value on communication and feedback. Business value is destroyed only when we substitute extensive planning for execution and when we substitute execution according to plan for thinking and adapting. — location: [1282]() ^ref-7622 --- Plans can be used to control behavior when there is relatively little uncertainty; even then, controlling behavior is not the right goal when you care about harnessing the creativity and problem-solving skills of employees. In the Agile world, plans are a tool for thinking and communicating, for framing problems and encouraging discussion, for establishing visions and values. But they are no longer tools of the contractor-control model. — location: [1522]() ^ref-23835 --- The problem with Waterfall is not that requirements are defined in advance; the problem is that there are any requirements at all. There should just be a team working together to figure out how to maximize business value. — location: [1583]() ^ref-1517 --- The best we can say is that business value is the current hypothesis of executive leadership of what will best accomplish the aims for which the organization is chartered—increased shareholder value for a publicly traded company, mission value within liquidity targets for a nonprofit, mission value with continued appropriations for a government agency, and whatever the owners want for a closely held private company. — location: [1739]() ^ref-35397 --- Basing their work on desired impacts turns the team into outcome owners: they are responsible for the entire value stream of accomplishing the desired outcome. This differs from the classic formulation of IT’s role—and even the typical Agile formulation—where the team builds the features requested by the business or its product owner and then hands things over to a business lead, who might or might not be effective at harvesting business value. — location: [1770]() ^ref-53555 --- Requirements are a way of controlling the development team by constraining their creativity. Instead of requirements, we want to charge the team—the joint business/IT team, that is—with delivering business outcomes, and let them find the capabilities that deliver these outcomes best. — location: [1795]() ^ref-30941 --- Transformational projects are evidence that a mistake has been made. The worst of these transformational projects are so-called “modernization projects”—transformational projects undertaken to bring technology platforms up to date. But whether these projects are to transform business capabilities or their technological underpinnings, they are the result of poor stewardship of IT assets and old ways of thinking about IT governance and execution. — location: [1806]() ^ref-40935 --- A transformational project occurs when the amount of debt has become too much to bear. — location: [1815]() ^ref-55510 --- To make matters worse, transforming is not in itself a business objective. How can we make good decisions about what should be in or out of scope? In the worst-case scenario, everyone in the organization seizes on the large transformation effort as a way to get their pet projects done. But even with the best intentions and focus, it is hard to make good business-case decisions when your goal is “transforming” or “modernizing.” Is this particular feature or technology something that will make us “more modernized” or “more transformed”? Transformations stimulate risk-averse behaviors and encourage feature bloat. — location: [1857]() ^ref-58831 --- But the product metaphor, like many others in this book, has outlived its usefulness. We maintain a car to make it continue to function as if it were new. A piece of software, on the other hand, does not require lubrication—it continues to operate the way it always has even if we don’t “maintain” it. What we call maintenance is really making changes to keep up with changes in the business need or technology standards. — location: [1927]() ^ref-10076 --- Theseus’s activities fall into what the software world now calls the strangler pattern: a way to incrementally modernize a legacy system as defined by Martin Fowler.5 Instead of building an entirely new system, we take a small piece of the legacy system and rebuild it in a way that lets it interoperate with the rest of the legacy system. — location: [1963]() ^ref-15299 --- Everything that resists continual change imposes economic costs. When a software designer makes a decision that will be hard to change later, he or she is imposing a cost on the company. When the company imposes bureaucratic overhead on IT changes, it incurs a cost. When a feature is created that is constraining rather than enabling, it imposes a cost. — location: [1990]() ^ref-50161 --- Transformation and modernization projects are exactly what IT leaders must avoid; continuously transforming and modernizing the company’s IT systems makes Fowler’s strangler pattern into an IT strategy rather than just a coding tactic. — location: [2031]() ^ref-47649 --- I’d like to suggest that the enterprise architects have had it right all along. We manage an enterprise-wide asset with an “as-is” state and a “to-be” state. We groom this asset in perpetuity—as the company changes and develops—by adding, removing, and improving its capabilities. We try to build into it agility and options, risk mitigations, and usability. The totality of our IT capabilities is an economic asset that will be used to derive profits or accomplish mission, and we might as well just call this the Enterprise Architecture. — location: [2064]() ^ref-20920 --- We often take a knee-jerk approach to standardization. “Of course,” we think, “standardizing on one programming language for the enterprise is essential; it will let us focus our expertise and move developers from one project to another.” This is valid, and in some cases standards can even improve agility. If everyone uses the same brand of laptop, then we can provision it quickly and make sure we have the skills to support it. Absolutely—standardization can have substantial economic benefits. — location: [2105]() ^ref-46275 --- The EA asset evolves over time through incremental investments. IT leaders must invest wisely with the goal of managing it. Grooming it. Stewarding or cultivating it so that it can easily adapt to meet tomorrow’s needs. Their goal should be to evolve it so that it continues to support the company’s strategies. No one else in “the business” will have this strategic intent. Since transformation is the normal, day-to-day Agile progress of the enterprise’s capabilities, an EA asset is always evolving. — location: [2158]() ^ref-54425 --- The EA evolves through the company’s projects. “The alternative to the ‘big-bang’ implementations is to build the foundation one project at a time. To do so, every business project must not only meet its short-term business goals but also help implement (or at least not undermine) the company’s architecture.”10 This is where I think they have it backwards: “Not undermining” the architecture is too weak a formulation. The EA is built through those initiatives; there is no separate investment in EA. The challenge for the CIO is to ensure that each investment dollar actually moves the EA forward in the direction of his or her vision. — location: [2186]() ^ref-63528 --- The EA asset is the embodiment of a strategic IT vision; the CIO’s strategy written into the company’s IT systems. — location: [2251]() ^ref-55950 --- The job of IT leaders is not to execute projects on behalf of the business; it is to steward the asset that is the total of all of the enterprise’s IT capabilities—an asset that has functional capabilities (how it is used today) but also latent capabilities (how it will support future agility and how it will offer options in the future). — location: [2304]() ^ref-47730 --- In cases where we don’t expect much change or where we understand our needs well, Raymond’s argument doesn’t hold—we are buying a product rather than services. Arguably, such is the case when we buy something like an accounting system. Our generally accepted accounting principles do not change much and are well defined. Information architectures and user interfaces have become standardized. Our requirements are essentially the body of literature that describes accounting standards and rules. — location: [2383]() ^ref-51930 --- For example, suppose the IT organization notices a need to invest in grooming the EA asset—perhaps it needs some security enhancements or some polishing of the asset to enhance agility. IT, we are told, should create one of those Star Chamber proposals, making clear the business value of the initiative in terms such as ROI. When the initiative doesn’t get funded, it is easy for us to blame the IT folks’ inability to express their ideas in business terms. A better explanation might be that there is no good way to express their ideas in business terms—at least, not a way that will allow the Star Chamber to compare them to functional enhancements. How much value does a new firewall have? Well ... let’s see ... the cost of a typical hacker event is X dollars, and it is Y% less likely if we have the firewall. Really? How do we know that it will be the firewall that will block the next intrusion rather than one of our other security controls? How do we know how likely it is that the hackers will be targeting us? For how long will the firewall protect us? Will the value of our assets—that is, the cost of the potential hack—remain steady over time? Or will we have more valuable assets later? — location: [2658]() ^ref-40506 --- Every task should be done ASAP—given normal, humane, sustainable working conditions. ASAP is just a way of stating the obvious: the goal of a Lean process is to shorten cycle times. — location: [2991]() ^ref-15898 --- Governance has traditionally been viewed as a filter; a way of allocating scarce IT resources among many competing projects. But in a world where IT is integral to strategy, it makes more sense to begin from strategic objectives and produce investment themes that accomplish those objectives. When combined with Agile and Lean practices, this approach can focus IT planning, reduce risk, eliminate waste, and provide a supportive environment for teams engaged in creating value. — location: [3060]() ^ref-26230 --- The Agile way to deal with uncertainty is to create options and then “buy” information to more accurately assess probabilities. — location: [3160]() ^ref-22034 --- The decisions of IT leaders are especially risky because they affect large areas of cost and potential revenue. In a sense, IT leaders take on all of the risks of the enterprise, since IT’s unknowns include all of the other business unknowns—in other words, the result we get from an IT investment not only depends on the IT-specific risks, but on all of the other business risks, as well. If we build a new IT system to support a line of business and that line of business declines, then the return from our IT system declines, as well. The Chief Information Officer is also the company’s Chief Uncertainty Accommodator. — location: [3174]() ^ref-17289 --- The Rugged DevOps movement promotes a hygiene-based approach to security.9 “Rugged” organizations are organizations that have developed a culture of creating software that is “available, survivable, defensible, secure, and resilient.”10 Rugged organizations build rugged software because ruggedness is one of their values—they treat it as a matter of quality like any other matter of quality. A piece of code that has a preventable security flaw is like a piece of code that has any other kind of flaw—broken. — location: [3334]() ^ref-34851 --- We know that schedules and costs will be overrun. We can admit it—everyone knows that delivery is never on time and on budget; if it were to happen by accident, we would be pretty sure that it was because the costs were overestimated in the first place. Non-IT managers have gotten used to doubling or tripling the estimates given to them by the IT folks. When the system is finally deployed, it requires people camping out in the office overnight, pizza, Red Bull, heroism—and somehow the developers expect the business to reward them for it! Furthermore, we know that, soon after the system is deployed, it will turn out that the hardware is no longer adequate and must be upgraded; that the software is outdated and must be replaced. — location: [3408]() ^ref-2102 --- Perfection is not necessary when we first release a capability, but impeccability is. The delivery teams still have a responsibility to achieve the best quality possible through everyday good practices—in other words, the quality that costs approximately nothing. — location: [3568]() ^ref-57115 --- Shadow IT—rogue IT, IT that is out of the control of the IT organization—is what has saved IT up to this point. It is a powerful phenomenon that we have not yet learned to take advantage of, caught up as we are in the contractor-control model of IT. Shadow IT is what happens when the IT organization is unable to meet the needs of a part of the company, perhaps due to capacity constraints or to the governance process’s limitations. When shadow IT arises, it means that someone is helping fill that gap—that is, doing what IT is unable to do. That person is performing IT’s work—they just don’t happen to report to IT. — location: [3655]() ^ref-64709 --- The theory of Complex Adaptive Systems draws upon evolutionary biology and complexity theory. When an environment—a business, for example—is sufficiently complex, it is no longer subject to straightforward control mechanisms. In fact, “the behavior of such complex things is typically neither deterministic nor linear; rather, living systems continuously reorganize themselves in unexpected ways.”10 A CAS hovers on the edge of chaos;11 it is a network of complex interactions that pursues “multidimensional objectives”;12 an evolutionary system that magnifies small changes into large effects. — location: [3753]() ^ref-22450 --- As a result, the economics of the open source community more resemble those of a gift culture or economy. “Gift cultures are adaptations not to scarcity but to abundance ... in gift cultures, social status is determined not by what you control but by what you give away.”4 In an economy of abundance, the measure of success is one’s reputation among one’s peers. — location: [3724]() ^ref-534 --- The critical insight here, I think, is that middle management is a creative role, not a span-of-control role. Middle managers add value by contributing their creativity, skills, and authority to the community effort of delivering IT value. — location: [3910]() ^ref-488 --- It is in this context that I say this: support shadow IT! It is a way to overcome the business-IT-contractor relationship. It is a way to motivate employees and to stimulate innovation. Finally, it is a way for IT leaders to break out of the contractor-control model, bring in the best ideas from the IT world, and contribute to the company’s framework for execution rather than trying to own it. — location: [3925]() ^ref-8951 --- But, unfortunately, we have set up IT around a control paradigm rather than a creative and enabling paradigm. This has caused business stakeholders to perceive IT as a limiter, a constraint, an impediment in achieving business objectives. As a result, businesses have found it necessary to set up new organizations—“digital services” organizations, “chief data officer” organizations, so-called bi-modal IT—that essentially have the same skills that the IT organization should have had in the first place. The consequence is a predictably uncomfortable overlap of functions, and IT organizations that increasingly have the dying skill sets of earlier decades. — location: [3958]() ^ref-28957 --- Users internal to a company do not really care about products the way that the buyers of an off-the-shelf product care about it. Users only care about capabilities. We mislead ourselves by grouping those capabilities into products and managing them at this coarser level. — location: [3989]() ^ref-5532 --- A better alternative is to think in terms of the overall IT asset—the collection of all capabilities and the technology that supports them—and look to optimize the whole. I refer to this asset as the Enterprise Architecture, using the term a bit differently from the usual. — location: [3992]() ^ref-1428 --- IT leadership has the responsibility for stewarding three critical assets: the Enterprise Architecture asset, the IT people asset, and the data asset. These three assets represent the capabilities of the company and its ability to address the future. — location: [4082]() ^ref-46171 --- EA is the collection of capabilities that lets the business do what it does; it is a map of the organization written in IT systems. The health of the EA asset determines the company’s agility and costs in the future. Because the EA is grounded in technology, only IT leadership can truly steward it; polishing and grooming this asset requires an understanding of technical debt, security risks, and architectures that will be enabling or constraining in the future. Both the IT skills asset and the data asset are future-directed bearers of latent value that are critical to the company’s ability to earn future profits. Overseeing them falls naturally to IT leadership. — location: [4084]() ^ref-19179 --- Similarly, we will create business value for the enterprise by testing software until diminishing returns from testing suggest that we do the rest of our testing in production. We will have defects, we will have roll-backs, and we will make people wonder how we could be so dumb. And then, we will humbly fix the problem. We will do this because it is best for the company. We are brave! — location: [4298]() ^ref-60954 --- If we don’t take risks, then the company’s decline will be blamed on the market, while if we take risks, then only we will be blamed. Courage is how we turn uncertainty into profit. We — location: [4304]() ^ref-23963 --- We will trust our teams and empower them, and we will serve them as servant-leaders. Yes, we will make ourselves vulnerable by doing so. We will not be able to both “control” them and empower them; we will have to trust. Not “trust but verify”—trust but influence and motivate. The teams that create value for us create value for us; we do not. We are overhead. We must allow them to create value, help them to create value, and trust them to create value. They will do so if we have chosen our teams wisely and infused them with the right vision, and if we sweep aside their impediments. Courage, my fellow IT leaders! — location: [4306]() ^ref-31669 --- The shrill noise of an IT leader trying to speak the language of cost obfuscation—I mean cost avoidance—is like the frequent boastings of someone with an inferiority complex. Do what is right—produce outcomes—and your contribution will be appreciated, or you will find a better job. Do it with the courage and confidence of someone who knows how important he or she is. — location: [4322]() ^ref-58388 --- No one else can make the electrons that run the business leaner or more agile the way we can. No one else understands uncertainty the way we do. We don’t just understand the tools and the principles—we get how to achieve outcomes with them. We are magicians, possessors of the potions and scrolls, motivators of the armies of geeks, and seers of the future. And we care—boy, do we care. That’s how we got our skills. Curiosity, motivation, intellectual prowess. We want to apply these skills to solving the enterprise’s problems in a world where the tools are the tools we know. — location: [4341]() ^ref-39942 ---