I picked up Mark Schwartz’s
A Seat at the Table as I have recently been thinking about how we can move away from the perception of our IT team as the people who ‘turn up and fix the Wi-Fi’ to one where we are seen as true business partners. The book took me by surprise in being less of a self-help manual and more of a well-articulated argument as to why the old ways in which we did things no longer apply in the digital age. It is brilliant.
Schwartz has a way of encapsulating key concepts and arguments in short, smart prose. The book contains the best articulation of the case for Agile, Lean and DevOps that I have read. There is so much wisdom in a single sentence, for example:
One of the books referenced heavily in A Seat at the Table is Lean Enterprise by Jez Humble, Joanne Molesky and Barry O’Reilly which I read some time ago. Lean Enterprise goes into more detail in terms of the concepts and mechanics used in modern software development such as continuous integration, automated testing etc. and brings them together into a coherent whole. Schwartz does not cover these topics in detail but gives just enough information to make his case as to why they are the sensible way forward for developing software.
A company may typically engage their IT department as if they are an external supplier. They haggle and negotiate, they fix scope and cost and they then the work starts. This approach does make some sense for working with a truly external vendor where they are taking on some of the financial risk of overrunning and you are able to specify exactly what you want in detail, for example where physical IT infrastructure is being delivered, installed and configured. It makes little sense when you are creating a new software system. It makes even less sense when the IT team are colleagues in the same organisation, trying to work out what investments will make the biggest impact on the company. We win and lose together.
First of all, we came to speak about “IT and the business” as two separate things, as if IT were an outside contractor. It had to be so: the business was us and IT was them. The arms-length contracting paradigm was amplified, in some companies, by the use of a chargeback model under which IT “charged” business units based on their consumption of IT services. Since it was essentially managing a contractor relationship, the business needed to specify its requirements perfectly and in detail so that it could hold IT to delivering on them, on schedule, completely, with high quality, and within budget. The contractor-control model led, inevitably, to the idea that IT should be delivering “customer service” to the enterprise—you’d certainly expect service with a smile if you were paying so much money to your contractors.
For readers who are familiar with why we use Agile software development methods, the arguments against the old ‘waterfall’ approach are well-known. What is more interesting is that Schwartz also points to issues that advocates of the Agile approach have exacerbated. Agile people can be suspicious of anyone that looks like a manager, and want them to get out of the way so that they can get on with the job. Schwartz argues that the role of managers and leadership is to remove impediments, many of which the Agile team cannot easily deal with on their own:
When the team cannot accomplish objectives, I am forced to conclude that they cannot do it within the given constraints. The team might need members with different skills. It might need permission to try an experiment. It might need the help of another part of the organization. It might need a policy to be waived. But if the task is possible and the team cannot achieve it, then there is a constraining factor. My job is to remove it.
What if someone on the team is really just not performing? Perhaps not putting in his or her share of effort, or being careless, or uncooperative? Well, then, dealing with the problem is simply another example of removing an impediment for the team.
The critical role of middle management, it would seem, is to give delivery teams the tools they need to do their jobs, to participate in problem-solving where the problems to be solved cross the boundaries of delivery teams, to support the delivery teams by making critical tactical decisions that the team is not empowered to make, and to help remove impediments on a day-to-day basis. 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.
He makes a clear case for getting rid of ‘project thinking’ completely. If you want a software delivery initiative to stay on budget, the only way to do that is through an agile project. The team will cost the organisation their run rate which is almost always known in advance. Work can be stopped at any time, preserving the developments and insights that have been created up to that point.
As a former PMO head, and with my current responsibilities of running a portfolio of change initiatives, it was interesting to see the approach to ‘business cases’ recommended in the book. Instead of signing off on a set of requirements for a particular cost by a certain date, you should be looking to assess the team on what they want to achieve and whether they have the skills, processes and discipline to give you confidence that they will:
- be effective,
- manage a robust process for determining the work they will do,
- make good decisions,
- seek feedback,
- continually improve.
Schwartz gives a brilliant example of how difficult it is to articulate the value of something in the IT world, which gave me flashbacks to the hours I have spent wrestling with colleagues over their project business cases:
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?
The word ‘requirements’ should go away, but so should the word ’needs’; if the organisation ‘requires’ or ‘needs’ something, what are the implications for right now when the organisation doesn’t have it? Instead of using these terms, we should be formulating hypotheses about things we can change which will help bring value to the organisation. Things that we can test and get fast feedback on.
Schwartz also argues against product as a metaphor, which was a surprise to me given how prevalent product management is within the industry today:
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.
Senior IT leaders are ’stewards’ of three critical ‘assets’ in the organisation:
- The Enterprise Architecture asset — the collection of capabilities that allows the organisation to function, polished and groomed by the IT team.
- The IT people asset — ensuring that the organisation has the right skills.
- The Data asset — the information contained in the company’s databases, and the company’s ability to use that information.
Much of the book comes back to these three assets to emphasise and elaborate on their meaning, and the work required to “polish and groom” them.
The author makes the case that CIOs should take their seat at the table with the rest of the CxOs through being confident, bold, and simply taking the seat in the same way that the others do. To talk of IT being ‘aligned’ to the business is to imply that IT can be ‘misaligned’, doing its own thing without giving any thought to the rest of the organisation. The CFO, CMO or any other CxO does not need to continually justify their existence and prove their worth to the business, and neither should the CIO. The CIO needs to have deep technology knowledge — deeper than the rest of the people around the table — and bring this knowledge to bear to deliver value for the organisation, owning the outcomes instead of just ‘delivering products’.
It follows that the CIO is the member of the senior leadership team—the team that oversees the entire enterprise—who contributes deep expertise in information technology. I do mean to say deep expertise. Increasingly, everyone in the enterprise knows a lot about technology; the CIO, then, is the person who knows more than everyone else. The CIO should be more technical, not less—that is how he or she contributes to enterprise value creation; otherwise, the role would not be needed.
The age of IT organizations hiding behind requirements—“just tell me what you need”— is gone. IT leaders must instead take ownership, responsibility, and accountability for accomplishing the business’s objectives. The IT leader must have the courage to own outcomes.
IT investments are so central to corporate initiatives that it is hard to make any other investment decisions without first making IT decisions. This last point is interesting, right? Perhaps it suggests that IT governance decisions should be made together with or in advance of other business governance decisions. Instead, in our traditional model, we think first about “business” decisions, and then try to “align” the IT decisions with them. But in our digital world—if we are truly committed to the idea that that’s the world we live in—IT should not follow business decisions but drive them.
CIOs and their staff have an excellent “end-to-end understanding of the business, a discipline and mindset of accomplishing goals, and an inclination toward innovation and change.” They bring a lot to the table.
Schwartz makes a case for the rest of the organisation becoming digitally literate and sophisticated in their use of technology. This may extend to people from all parts of the organisation being able to contribute to the codebase (or “Enterprise Architecture asset”) that is managed by IT. This should be no different to developers on an open source project making changes and submitting a ‘pull request’ to have those changes incorporated into the official codebase. We should embrace it, fostering and harnessing the enthusiasm of our colleagues. We should care less about who is doing the work and more about whether the company’s needs are met.
As much as I enjoyed the book, there were points where I disagreed. Schwartz argues strongly against purchasing off-the-shelf software — ever, it seems — and advocates building things in-house. He makes the point that software developed for the marketplace may not be a good fit for our business and may come with a lot of baggage. My view is that this completely depends on where the software sits in the stack and how commoditised it is. It makes no sense to implement our own TCP/IP stack, for example, nor does it make any sense to develop our own email client. (Nobody ever gained a new customer based on how good their email system was. Probably.) But I do agree that for software that is going to give us a competitive edge, we want to be developing this in-house. I think that something along the lines of a Wardley Map could be useful for thinking about this, where the further along the evolution curve a component is, the less Agile in-house development would be the preferred choice:
Overall this book is a fantastic read and will be one I come back to. It’s given me lots to think about as we start to make a case for new ways of working that go beyond the IT department.
