Software company CTOs are too often losing sleep and battling through stressful days. That’s because traditional software development methods often lead to CTOs spending a large portion of their time and mindshare putting out fires. They struggle to estimate how long it will take to achieve a particular result. When a CEO asks, “How soon will this new product be ready,” or “How soon will the new features be ready to go out to our customers,” this can be panic-inducing for the CTO.
CTOs often feel under-resourced. They worry that they don’t have enough budget or staff to give the company what they’re asking for; as a result, the CTO is regularly trying to explain why dates for certain deliveries keep slipping.
If you ask a CTO what is their product management strategy, the best they will usually come up with is “We manage our products.” When you ask them what is their platform engineering strategy, you’ll probably hear: “We get requests, we turn it over to the developers, and the developers figure it out from there.”
The CTO does their level best to try to herd the cats and meet the company’s expectations. They add a huge fudge factor for the estimates from their developers so they can report 3x that amount up to management.
But emotionally, CTOs are often feeling overwhelmed and underappreciated. They have to deal with too much chaos and unpredictability, with high levels of frustration managing expectations upwards, while managing a group of developers downward.
The CTO is in the middle. Their job is to get maximum performance out of their dev team and help move the company’s ball forward. The CEO lights the path and it’s their job to figure out how to get there. It’s a thankless job, in many ways; these are all reasons why the average life span of a CTO is 18 months. And that figure has not improved in the past 20 years.
CTOs are smart people with good intentions. But they’re not being well-served by the typical culture and processes of software development. Because CTOs are so frustrated, they tend to be skeptical of any ideas that might fix the situation. The software industry has been consistently chaotic, and CTOs often don’t believe that there is a better path forward.
In the past 20 years, one thing that software CTOs have hung their hat on to reduce chaos and improve predictability is agile software development. While agile software development is great, there are limitations to what it can achieve when CTOs are getting tripped up by so many other obstacles.
Let’s look at a few ideas for how to make the CTO’s job better – so CTOs and their companies’ CEOs and investors can sleep better too.
3 Levers to Drive Change for Software CTOs
Despite all the chaos and challenges swirling around them, CTOs are not helpless. The CTO has three levers of change that they can move – Technology, People, and Process:
- Technology: Bring in new and different technologies that will hopefully make things better in software development.
- People: The labor lever – hire more people, better people, cheaper people. “Do I just need one more senior person, one more magical rock star developer, or three more engineers?” The problem is that companies are constrained in terms of budget and how many people they can recruit. And once you get people, you have to manage them. The more people you manage, the more challenging it can be. And people put a constraint on the technology lever. Are you going to choose technology and then make the developers use that technology? Usually not! More senior people, especially, are going to want to choose their own technology.
- Process: CTOs have limited control of the “People” lever in terms of budget, headcount, and outsourcing. The “Technology” lever is limited by people. So the third lever that’s often more in the CTO’s control is deciding to use a new software development process. For the past 10 years, that lever has been agile development.
CTOs at organizations of all sizes have pushed on this lever as hard as they could. But here’s the shortcoming of agile development: if you haven’t aligned the people and the tech along with the processes for the needs of the business, it doesn’t matter how agile you are, you will still end up facing several challenges.
Limitations of Agile Development for Software CTOs
Agile is not a magic wand for the underlying challenges that make a CTO’s day so difficult. Just going agile hasn’t solved problems with delivery dates and unpredictability. What it has solved: before you went agile, you would develop a massive project plan with a waterfall technique, and say “Ok great, I’m going to do this by the book and come back to you in a couple of years.” However, this way of doing project planning was too rigid; by the time the product was ready, the requirements might have changed.
Most CTOs think they just need to develop software incrementally with more of a pure agile approach. They’ll say, “Let’s bring in a scrum master, let’s do more agile training.” There’s nothing wrong with each of those pieces. But the reality is, and what most CTOs don’t realize, is that the best that this incremental approach will accomplish is, every sprint, every two or three weeks of the agile cadence, you’ll have something new.
So with this incremental approach, the CTO feels like, “Good, we’re making progress, we’re shipping things out.” But often, the team isn’t thinking more than one sprint ahead, two to three weeks at a time. Very often, agile becomes an excuse for developers to not deliver their commitments. They can hide behind the process, and it turns into a tool to avoid accountability for delivering high-quality output in the expected timeframe.
Agile isn’t enough to save a CTO’s sanity. We need something bigger.
New Perspectives on Software Development – it’s Not “Writing Code”
If you step back and look at all this, CTOs need a fundamental shift in perspective to help get more out of the resources that they already have – and to better understand what the CTO’s purpose is. Too often, CTOs are principally thinking that their job is “developing software” – the team “writes code.” But even that language is wrong. Is “write” the right word for code? Is your software team “writing” a book? Even the verb is wrong.
If you’re “developing software,” what purpose and value does the software have?
What’s missing in this typical CTO perspective is product development discipline.
There’s a great deal of inertia in the culture of the software industry. Part of it is the culture around developers being seen as “artists.” Have you ever tried bringing together a group of artists to work collaboratively? There’s a reason why people call it herding cats.
Here’s the right framing for how CTOs should think of their jobs: you’re not developing software, you’re designing and building software products. It’s no different than if you were building physical, manufactured products like smartphones or cars. CTOs need a team of “engineers,” not a team of “developers.” That’s the level of discipline that is necessary.
From “Software Development” to “Software Product Engineering”
Too often, software R&D teams have a backward view of product design and development. They build first and ask questions later. In the engineering world: would you ever start building something before you have designed it? No.
But in the software world, too often, product design ends when someone draws a mockup or wireframe. That’s not good enough! Just because you can sketch it visually and have a graphic designer mock something up, that doesn’t mean you have a product. That’s like saying, “I have a drawing of a Corvette, I know what the outer body looks like, I’m ready to manufacture the car!” No! You need to know what the engine looks like, all the interior features, and all the parts. It needs to be designed and built in a way that you can get a product with high quality out to the marketplace as quickly as possible and still make a profit!
This kind of product development and product engineering mindset is often missing from the CTO. It’s not that they don’t have enough bodies. To be truly effective, efficient, and productive in software product engineering, you need the right mindset, and the discipline to truly design and engineer your product. In that context, agility is a good thing! Agile is not “bad,” but it’s not framed and measured correctly.
Are you focusing on architecture and reusable components? Any engineering team – whether it’s electrical, mechanical, or nuclear engineers – always thinks in terms of quality, reusability, and cost containment.
To be a successful product company, you have to build rock-solid, market-competitive products – and deliver quicker than the competition. How do you know if you are doing that? Let’s look at a framework that should be top of mind for every CTO.
Four Must-Have Outcomes for Every Software Product
There is a set of universal goals and outcomes that every software CTO, CEO, and Investor desires when it comes to software development, in order of priority:
- Stability: Software products need to be stable. If the product isn’t stable, you can’t keep customers and you will burn resources fighting fires.
- Scalability: The Sales team needs to be able to sell the product and add customers to it, and the product must handle that user growth without breaking. If your product can’t scale, your company can’t grow – and your software team has failed in its role for the company.
- Profitability: Profit is often top of mind for CFOs, but rarely for CTOs. The CTO needs to own the profitability of the software products they are building. How much you pay to build and run a product matters a lot. If you were building a midsize car for middle-class families, and you engineered this product like Homer Simpson, and it cost $150,000 to build – is that successful? No! It’s not profitable. CTOs need to care about profitability and consider it part of their job.
- Serviceability: Is the product serviceable? Can you keep it running, enhance it, and grow it easily? How long will this product remain relevant in the marketplace? Even if you can build a stable, scaleable, profitable product, if what you have built is not serviceable, the needs of the market will outpace the product, and at some point, it won’t be viable anymore. The millions of dollars you’ve spent to build it will evaporate; and the only answer is, “We’d better build something new to replace it.”
Achieving all four of these outcomes is not an easy task! But if you take a customer-centric view, aren’t these the universal demands of every customer? They need your product to be stable, scalable, cost-effective (that’s the customer side of “profitable”), and serviceable. This is the right way of looking at software product engineering. And delivering on these four goals – not “writing code” or “developing software” – is the real job of a CTO.
CTOs have a new lever of change to help them achieve all four of these must-have outcomes: PlatformPlus®.
How PlatformPlus® Creates Happier CTOs (and CEOs)
PlatformPlus is our fully managed and supported Platform-as-a-Service (PaaS) that gives CTOs the simplest path to delivering commercial software products quickly. It enables your team to pivot from software development to software product engineering. CTOs can use PlatformPlus to build stable, scalable, profitable, and serviceable products with the team they already have.
In the context of software product development, a CTO using PlatformPlus will:
- Get results with a smaller team. You don’t need more bodies.
- Gain access to deep expertise from Modularis. The CTO’s team is fully supported with advice and heavy-lift architecture and engineering help from the Modularis team.
- Get out of the infrastructure and plumbing business. In any software product, only 20% of the code delivers value to the customer – the fun features and secret sauce. The other 80% is infrastructure and plumbing which is necessary to make sure the product is stable, scalable, profitable, and serviceable. With PlatformPlus, all the infrastructure and plumbing – where most of the CTO’s daily frustrations and challenges normally come from – are provided. The CTO’s team can spend 80% of their time on the 20% of the code that is going to deliver value for customers.
PlatformPlus isn’t just good for the CTO and the software R&D team. It unlocks value for the business – helping the CEO have happier workdays too.
Why is the CEO happier with the CTO when their team is using PlatformPlus?
Less time spent fighting fires, more focus on shipping products.
CTOs that use PlatformPlus have many fewer fires to put out. They get greater predictability for when certain things are going to be done because they have to build up to 80% less code to get it done. This makes the software R&D team more productive, efficient, and effective at building software products. They’re still working in an agile way, but PlatformPlus provides the right level of consistency and structure to the products. This enables the team to be more agile and effective without incurring any of the risks.
Stable, scalable, profitable, and serviceable products = better sleep.
With PlatformPlus, the CTO, CEO, investors, and board chairman are all sleeping better because products are stable, scalable, profitable, and serviceable. By handling all of the infrastructure, which is a huge source of risk, engineers complain less so they are sleeping better. Engineers can work within a better structure and an approach that empowers them to deliver value for the business better and faster.
PlatformPlus enables a transition from software development to product development. CTOs deserve a better night’s sleep and happier days at the office. With PlatformPlus, CTOs and their software teams can design, build, and deliver software products more effectively, more efficiently, and at a higher velocity than ever before.
Ready to learn more? Download our Comparison Guide to see how your entire organization will benefit when you partner with Modularis & choose PlatformPlus®.