Every tool needs a team

A lot has been written about applying a service management lens to running modern services. The importance of building skills and funding teams rather than projects is pretty well understood.

It’s less common that we talk about the provision of corporate applications, particularly those which are off-the-shelf commodities – things like providing Office365 or Slack or Zoom to your organisation. It’s the things everyone’s been doing a lot more of during the pandemic.

At the beginning of the pandemic, we saw organisations rush to set their employees up with the tools they needed to work well remotely. More recently, we’ve been seeing more enquiries about how these applications should be managed in the longer term. Often, the main concern is around what ‘applications governance’ an organisation should have.

But that’s the wrong place to begin.

Again, we need to start with teams. Every tool needs a team.

Commoditised tools are there to meet a range of common, clearly understood user needs (though they’re often stretched to meet other needs too). It’s ok to start with an assumption about which tools will best meet a team’s needs, but once they’re in place we should carry on observing how they’re being used. Ultimately, these tools provide a service and they must continue to work for the team.

It’s also important that organisations build feedback loops to improve the service. You should be able to spot where those tools are being stretched to do something that could be more simply, reliably or compliantly done using another tool (for example, when is the moment to replace a set of spreadsheets with a database?) You should know when potentially better options are entering the market and be able to test them.

Traditional applications management and governance don’t incentivise either of those things. It’s typical to incentivise efficient licensing arrangements, and increasing use of a tool (even where it’s not the right thing for the job). Or – too often – we just ignore them altogether once they’re installed, opening up a whole range of risks.

Efficient licensing, good training, and getting the most out of an investment are all important, but if we lose sight of the needs we will not make our organisations successful.

What’s missing is product management. Not on the supplier side (though it is usually clear which commodity tools have good product management and it’s wise to take that into consideration when you make procurement decisions), but internally. A good product manager will identify the needs of a team and will spot where the tool does – and does not – meet them. Then they’ll then act on that insight.

A product manager will sometimes need to be able to call on the rest of the skills you’d see in a typical digital team: user researchers in particular, but also content designers, developers and others who can help make sure you’re communicating clearly, integrating the tools effectively, and evaluating all your options to deliver the service.

Sometimes, a product manager and the team will have a portfolio of tools to provide a service, which is great. But sometimes they’ll be responsible for a slice of something the organisation has bought, which can be tricky. That’s one of the places careful governance can be useful: making sure the right boundaries are set so that teams can focus on tending the right-shaped service, not just serving the software.

Every tool needs at least a little configuration, or some clear agreements about how they’re going to be used; very little really exists at either the ‘pure build’ or ‘pure commodity’ ends of the spectrum.

Sometimes we need to make or change those agreements very quickly, such as when we learn about security issues with their default settings as many of us did with Zoom as the pandemic was taking hold.

And the joy and the pain of modern software is that there’s always a new tool offering a different way to get the job done. Adopt too many, too fast and you’ll create confusion, but sticking rigidly to what you have will lead to frustration and missed opportunities.

Teams responsible for services can own the agreements about how we use what we have, create space for experiments where something new might be better, and find the balance that best meets the real needs.

Clear ownership and governance of corporate tools is essential, but to really get the best out of our tools we mustn’t start with the traditional modes of governance, we need to start with teams.