This is the third and final installment of a series attempting to redeem words tarnished by management. Previously I looked at “strategic” and “leadership”. Today: governance.

This is a word that doesn’t tend to get used much among software development teams, and when it does it tends to carry the claustrophobic feel of heavy bureaucracy: ITIL, ISO, and lots and lots of very dull paperwork. But while it might not be thrill-a-minute stuff it’s something that the software team on the ground does need to be aware of: not just what it is, but how it works in your organisation.

About governance

Governance is about providing the link between what people do in the software team and what people in senior management need and expect. Without that link there would be no mutual trust. That trust is important to the tech teams because, to be frank, none of us would be here without senior managers’ say-so. They provide the time and resources for us to do our jobs — not just the physical working environment and pay-cheques, but a meaningful and stable programme of work.

Here are a couple of examples.

Example 1: Life with poor governance

The importance of governance came home to me a few years ago when I worked on a project which involved a group of management execs somewhat separate from the development team. As with many such projects there were all sorts of unexpected problems, but we on the development team had the great benefit of working closely with the end users who who provided regular guidance and advice. As a result we developed something which more or less made those end users very happy — they didn’t get everything they wanted but they were happy that they got a good system within the bounds of budget and time.

The management execs, meanwhile, met regularly to track our budget, which was used responsibly and didn’t provide too many alerts.

Unfortunately when the final product was delivered the executive group was distinctly unhappy. It turns out they had expected one or two key features which the end users had decided they could cut among some of the compromises they had to make. When the development team and end users were proud of their finished work the executive group were disappointed.

The result was that future work with this group was incredibly difficult, because trust had been lost — they authorised future work only after a great deal of pain, and we generally had a work an awful lot harder to get anything done.

As result of poor governance the people on the ground had a much harder time in their day-to-day lives.

It’s clear to me that no one person or group was at fault here, but as a development team we could have done better. We should have flagged up not just budget changes but also changes in the evolving feature set.

Example 2: Governance on the guardian.co.uk

Good governance isn’t about reporting absolutely everything upwards, because you want your executive group to focus on the relevant issues.

On the recently completed guardian.co.uk rebuild project we were careful about what did and did not go to the board. For example, while the development team estimated and costed work in “ideal days” or “story points” we were careful to translate these into pounds sterling for the board. Ideal days is a useful abstraction for development estimation, but a pointless additional layer for a board.

In terms of the evolving feature set, change was tracked carefully within the development team and percolated upwards. But again, the information wasn’t conveyed verbatim, because development teams worked on lower-level tasks than were meaningful to users. So all lower-level task changes were translated into higher-level feature changes when presented to the board.

The result of this good governance was that when the the project ended both the board and the development team were united in recognising a job well done. We have further plans now, and although we’ll still have to justify each of them we are at least starting from a position of trust.

By the way, all this governance this did involve paperwork — in the form of writing board reports. But that’s only because paper is often a good vehicle for communication, and communication is central to building trust. We shouldn’t dismiss governance simply because it involves careful communication.

Governance in review

Good governance is therefore all about trust through communication; for software teams it means they get the trust and support of those senior people who shape their working environment and daily lives. Without good governance that trust won’t be forthcoming. Understanding how it works in your organisation means you have a route to ensuring you have senior management support when you need it.