The role of the CIO in the Agile era - part 1
This series of posts is on the one hand a review of a very interesting book by Mark Schwartz "A seat at the table". On the other, some reflections on who CIOs/CTOs really are and how this role(s) has evolved over the last 20 years. How much the image of both corporate IT has changed and how the image of software development and software development management has changed. Finally, where is the place of the CIO in the times to come?
This series of posts is on the one hand a review of a very interesting book by Mark Schwartz "A seat at the table". On the other, some reflections on who CIOs/CTOs really are and how this role(s) has evolved over the last 20 years. How much the image of both corporate IT has changed and how the image of software development and software development management has changed. Finally, where is the place of the CIO in the times to come ?
40 years ago, when computers were just beginning to arrive in companies, the IT department seemed like eccentric engineers separated from the rest of the enterprise. Photographs from the late 1970s and early 1980s still show IT specialists in white lab coats. Nobody really knew what these people did. Of course, all employees and management were aware that "computerisation is necessary", but the IT department, with its jargon, inaccessibility and therefore lack of transparency, did not inspire confidence either in management or "business -side colleagues”. Management and "business" managers were therefore very distrustful of IT initiatives, both in terms of their business justification and cost-effectiveness. Mark Schwartz draws a humorous parallel with an eastern bazaar, where vendors do not quote prices so the buyer immediately tries to halve the price from the start.
"Business" has come to the conclusion that, being condemned to „computerization”, it is necessary to control the IT department more strictly. The answer to the problem of cooperation with IT is: more control.
Within the department, largely treated in those days as a research department, the position of CIO- Chief Information Officer was singled out. Initially jokingly referred to as 'the geek in the suit'. This person was to supervise other geeks so as to convince the board that the IT department is working on solutions that really contribute to the development of the company (meaning: increasing sales) and that the cost of solutions (external and internal) is proportional and justified. At the time when such positions were created, in the 1980s, no one precisely defined the role of such a person. It was often also called the CTO (in the next post I will refer to the difference between CIO and CTO). It was simply "the highest hierarchical position in the IT department".
On the wave of this approach, the Waterfall methodology emerged - we break down the project into clear phases and monitor the performance of each of these phases. This allows for strict cost and product control.
Unfortunately, the problems of IT and business interdependence remained unresolved. As IT is in fact an unfinished business.
Firstly, the Waterfall methodology is rooted in a kind of "pushing" between business and IT. IT wants to receive a detailed specification of the project/product, therefore it does not accept the fact that during the work a new need has arisen which should be taken into account or it is obvious that something could be done more efficiently, simply and sometimes in a more complex way.
Secondly, Waterfall doesn't really prevent the problem of overspending on IT. The IT department naturally tries to secure a sufficient project budget, so it usually includes more in the specification than is necessary.
Finally, there is no denying that, in corporate speak, IT and non-IT silos are created.
In the 1990s and 2000s, two views became widespread.
The CIO needs to show business colleagues and the board that their actions support the business. He must show that they create real value for the company. That the CIO deserves the eponymous "seat at the table" where decisions are made in the company - the board meeting, management committee, etc. The CIO should be proactive, taking the initiative at these startegic meetings. If a CIO cannot justify his role and does not show initiative, he is not a good CIO.
Secondly, a second strong view emerged: "IT must provide excellent internal customer service to other departments in the company". IT is therefore supposed to have a supporting role, not a strategic one. As Schwartz writes, this approach causes IT to start dealing with problems ranging from "the Internet doesn't work" to "the mouse pad isn't compatible" or "the pull-out cup holder is too small" (yes, this is a CD ROM;).
Where does our poor CIO stand in such a model from 20 years ago? Not in a very good position. His task is to balance the conflicts which this model naturally produces. Resolving conflicts between the organization and customer service-oriented IT, controlling one's own team, politics at the central level. And yet I once heard a lovely quote in a conversation with a candidate: "It's not why I went to Tech University to deal with people". (authentic :)
Most of the problems with placing a CIO in the structure of an old-type corporation stemmed from the fact that IT is developing so fast that it is difficult to establish clear priority convergences between IT and business.
For what is the mythical "value of IT for the company"? Is IT only about supporting sales and servicing the company's IT resources? At a time when it is difficult for many industries to distinguish between what is IT and what is "business", should we perhaps define "adding value" by IT quite differently?
In the early 2000s, agile methodologies in IT project management are gaining popularity. They address the problem of IT as "unfinished business" as well as breaking down silos between business and IT. A small IT team works in so-called sprints on issues delegated to it as part of the so-called backlog by the business, which is represented by the "product owner". The team gets to solve the problem, which they solve practically without supervision, working in a fully autonomous way. So why a CIO in the "wonderful new world of Agile" ? OK, someone has to oversee order and "delivery", but when it comes to the technological development of the organisation ?
In the second half of the 2000s, the position of Chief Digital Officer emerged in large companies. As with the CIO of 20+ years ago, companies could not quite define what this person was supposed to do. Another version of the jargon emerged: "Digitise" just as „Computerize" was 30 years earlier.
Is there a place for a CIO in this balance of power? Definitely Yes. What should a CIO be for a company in the age of agile? I will talk about it in the second part of "A seat at the table" review. Look forward to Tuesday 20th April !