Why Your CIO Can't Deliver Your CTO's Vision
The CTO must own the entire software development lifecycle (SDLC) from cradle to grave. That means all of development, but all of operations too. I’ve been doing this long enough that I remember when Ops was considered a cost center, and development was where value was created.
Those days are over. A good operations team, working hand in hand with the development team is a strategic differentiator for the business. In those days, because we only shipped software once in a while, it didn’t matter that it could take days or weeks to install systems in a data center. There was plenty of time for that. Now we deploy daily.
In those days we spent a lot of time working with vendors to demo expensive redundant solutions. Now we can scale our infrastructure up and down at will. Now we have functions that live for a few hundred milliseconds and disappear.
The way we deploy and run our infrastructure, the way we handle our incidents, the way we deploy our code, is just as much a part of the customer offering as is the software itself. One cannot exist without the other. If the CTO owns dev and the CIO owns Ops, you have a disconnect between two parts of the same system.
A house divided cannot stand. - Abraham Lincoln
The other CXOs
CIOs have important roles in the organization. They actually keep the organization running. Want to run an effective organization with no email or calendar? No CRM? No ERP system? Best of luck. Without the CIO you could possibly (unlikely) develop the best software in the world, and nobody would know about it. The CIO running production operations is a holdover from the days when the CIO was generally responsible for all infrastructure as it was a capital cost.
Today they are still responsible for infrastructure. It may even be cloud based infrastructure like virtual desktops. However, laptops and IAM (identity and access management) solutions are not the product that the customer pays for. The production infrastructure is an operational cost (OpEx).
-
The CIO is incentivized to keep the business running, secure, and control costs through smart choices and effective negotiation.
The CCO (Chief Customer Officer) is incentivized to keep the customer happy and effective on the platform. The happier customers are with the product the more they will buy. This can include selling professional services. -
The CTO is incentivized to deliver the product (as specified by the CPO) that the customers want securely, with high performance, and by controlling costs through engineering. The CTO can save infrastructure costs through engineering to a level that the CIO can only dream of. The CTO can secure the environments through engineering to a level that the CIO can only hope a vendor can offer.
Most CTOs came up through the ranks as software developers and because of the way our industry was traditionally structured, did not spend much time with Ops. To them, Ops is a strange place with strange people. Often they are ok with Ops being someone else’s problem.
This is not a failing on the part of the CTO, CIO or CCO. Engineering is one house, and we cannot hope to be as effective when only responsible for half a house.
Two Houses
When the houses are divided, there are many different mitigations that companies will attempt. They try to bridge the barriers, instead of being able to work together, because their leaders have differing incentives as discussed above.
- Ticketing systems. Often they will create queues between the two sides of the system instead of Ops building self-service tools for consumption by their customers, Dev. However, the Devs are still reliant on the Ops teams to complete their work and thus they have to wait. Waiting is waste in Lean. I’ve seen clients where the mean time to complete these tasks is days, but the outliers stretch to weeks. It’s in these organizations that I almost always still see software written by Dev, and deployed and managed by Ops.
- Independent reorganizations. Without clear lines of communication and accountability each side of the system attempts to optimize their side of the system leading to local (instead of global) maxima and minima; the opposite of systems thinking. I’ve seen organizations attempt to bring in two different consulting groups, one for the Devs, one for Ops. Imagine an Olympic swimmer with a different arm coach and leg coach. They would be lucky to tread water.
- Heavy process. Because the interactions between the groups do not flow, adding more and more process (intake processes, checklists, review boards) is often the solution. While process can be helpful, process without an understanding of your customer’s needs or objectives slows everyone down and leads to increased cost (time, infrastructure) and lower quality (environments are not representative). This is not about effort. If the CTO has an all-hands and the Ops folks are not invited, how can they possibly know about those needs and objectives? If they are invited, it begs the question why they are a part of a different organization in the first place.
One Organization
What happens when Ops and Dev both report to the CTO?
- There is faster decision-making, reduced complexity (no more ticketing system queues/waste), and increased agility in responding to changing business needs.
- There is increased operational efficiency, productivity, and ultimately, bottom-line results because all the tools are built “fit-for-purpose” because the teams have the same goals and objectives. I’ve seen costs reduced by more than 70% in portfolio companies because new engineered solutions were developed and deployed together which would have been literally impossible with another way of working.
- Because everyone is not trying to optimize their own part of the system and instead trying to optimize the whole, there is standardization and repeatability of processes so that when engineers understand how the system works, they see the same patterns everywhere.
Today’s Operations folks are engineers. They are no longer order takers who receive requests from other parts of the organization to set up servers, or wake up at 3 a.m. to restart services in the hopes that it will fix whatever problem. Today’s operations folks are operations engineers, or site reliability engineers (what Google says you get when you treat infrastructure problems as software problems), and as such they belong with the other software engineers, in Engineering.
How do I fix this?
Does it never work to have Dev report to the CTO and Ops report to the CIO? No, not never. In my first big PE transformation there was an outstanding CTO and CIO who worked hand in hand to deliver those results. If the Ops folks had been under the CTO could they have achieved the same results? Probably. Are you really that magic CTO and CIO combo who will succeed when it almost always fails? Do you want to find out?
PE portcos still carry a lot of baggage from the days of the data center because many of them still operate in the data center. I work with lots of portcos to help them successfully make the transition to the cloud. Having Ops under the CIO is part of that baggage, from when Ops was CapEx, not OpEx.
Modern software, especially with AI, requires high functioning software and systems that are only achievable through the collaboration of teams of teams. There is no advantage to having them on different sides of a wall. If you want your SaaS portco to have a better chance of success, all the engineers need to be in Engineering, under the CTO.