This is part 5 of a series about internet-era CTOs. Read the previous posts:

1. Why hire an internet-era CTO?
2. How to hire an internet-era CTO
3. What does it mean to be good at technology?
4. Untangling your technology spaghetti

Not every solution to every problem requires building software; but some of them do.

We meet a lot of organisations who are enthusiastic about embracing internet-era ways of working, providing digital services, and finding an internet-era CTO. Yet they don’t expect that new leader to build up their ability to make things.

Their hope is that by getting smarter in user research, design, procurement, supplier management, and use of off-the-shelf tools, they will get all the benefits on offer. That’s perpetuated by a lot of voices implying (or outright saying) that digital transformation is a thing you buy, not a thing you do.

The reality is that you can’t hope to be good with internet-era technology if you don’t have the skills to make things with it. You need to be confident drawing on a variety of approaches if you want to be able to pick the right way to solve a given problem. You need to be willing and able to build software, when the circumstances demand it.

Making use of commodity services for your workplace tools will probably make a big impact. Good cloud-based services like G-Suite and Slack (or equivalents) can make teams much more productive just by reducing the need to email massive documents back and forth. Simple task management tools like Trello allow teams to track their work and keep discussions focused.

Lean, modern software-as-a-service tools are generally far better for users than what came before them. They don’t require you to run lots of infrastructure to host them or teams to manage upgrades (so you might be able to turn off some infrastructure, and refocus some support staff on higher value activities).

But the best of them are pretty focused, and as soon as you want to do something that requires a view across them you’ll need some integration expertise. While many products and services out there claim magical integration powers, the reality is that as soon as you’re doing anything serious you’ll need some logic that’d distinctive to you and some translation that’s not yet purely about nice open standards, and that’ll take writing code.

Once you get into the things that really differentiate you (the things your customers interact with directly, the things that make them want to work with you), you need to be able to solve problems and continually make them better.

That doesn’t just mean the frontend, it means everything that makes you stand out – anywhere you could take out some friction or provide a better service. It’s become much easier to prototype products and services using a mish-mash of off-the-shelf services, but it doesn’t take long to hit the limits of that approach and find that you need to be able to mix together commodity and custom components.

Having the capability to understand what each component does and (more or less) how it works means you can keep your options open. Knowing that with some effort you could replace a third-party component with something of your own means you can really evaluate the cost-benefit of doing so, and settle on the most effective way of meeting your users’ needs.

One of the big technology trends of the internet era has been significant shifts in the economics of software development. Where the previous era was marked out by the large systems and large systems integrators to manage them, the past fifteen years have seen a wealth of new ways to make small teams more productive.

Over time, simple API-based services emerge and open source components become more mature in useful ways. It gets easier to break down a lot of the functionality that used to require a big system into small, discrete components.

Similarly as our products and services evolve and our teams grow more experienced, we can try things in new ways. When we built GOV.UK we knew that our users needed email alerts about changing content but the sensible use of our resources was to integrate with a third-party to manage that for us. Over time, the team’s understanding of the content changed and they saw far more nuance in how users wanted to manage those subscriptions. They also had access to new tools that made reliably sending large quantities of email much easier. The right decision about what to build and what to buy had changed. With the right skills within the team they could keep track of that change, and act on it.

This capability is also what protects you from being entirely dependent on your vendors. Knowing exactly what you need from their services, understanding what your options would be if those services weren’t there (what is the migration cost to alternatives? What would it take to build the minimum viable alternative yourself? What would the impact be of trying to solve the problem another way?) lets you enter the conversation with your vendors on even ground.

While you focus on the things that differentiate you, your end-to-end service will depend on something someone else provides.

You’re drawing on data from a third party (perhaps some open data), making use of third-party cloud services, and depending on some evolving standards. It’s sensible to have people who work for you who are close to the communities around those things and will spot changes that represent challenges or opportunities. That works best when they can also represent you and clearly add value to the community, like Alice Bartlett has done for the Financial Times.

The developers you want to hire won’t want to build everything. No-one does that anyway. Every modern software project builds on a huge ecosystem of open source modules and cloud services.

In his book “Developers are the New Kingmakers,” Stephen O’Grady makes a compelling case for how investing in a community of developers can pay dividends as they play an important role in helping your organisation know what’s going on and where the opportunities are.

In part 3 of this series, I talked about the importance of making technology part of multi-disciplinary teams:

“Being good at technology means having the tools and the confidence to collaborate in navigating a constantly changing environment.”

The transformation organisations need to make for the internet era will require the whole organisation to learn new skills. There’s no better way to do that than by having people with diverse skills sitting alongside each other and delivering together. To really build empathy and trust those people need to have similar incentives and be driven by the same mission–that’s much easier if they work for the same employer.

You shouldn’t be building everything. Hiring developers isn’t about building everything. It’s about building what differentiates you, and maintaining a deep understanding of your options for everything else.

With so many opportunities and challenges, no organisation that wants to thrive in the internet era can afford to just have one way of doing things. You need to be good at building partnerships, at finding and managing suppliers, and at doing some things in-house.

Invest in people who understand this, and you’ll be better prepared to pick the right approach for the problem at hand, or to balance them where success for your users requires you to do a bit of each.