Most people who do not build software systems consider it to be an additive process - like building a house. It is, however, far better understood as a reductive process.
When a software developer performs their craft - that is to say, when they develop software - they make thousands of decisions. Each of these decisions explicitly narrows the possibilities of what the software can and will do.
The software developer does make these decisions with malice, or spite but with the best of intentions. If a metaphor is required at all then building software is more like sculpture.
1/ In government, there is a flawed belief that software development is a skill that they cannot afford, but software governance is a generalist’s domain, and any required specialist skills can be quickly acquired.
2/ This understanding often manifests in the hiring of third parties to build software to a set of requirements.
3/ Once that piece of software has gone through the three Government Digital Service sanctioned alpha, beta, and live stages, the software is done and everybody moves on.
I find it remarkable how often "leadership teams" sabotage the organisations they purportedly work for. There are many ways in which this happens, but I want to focus on one that I see quite frequently.
Reorganisations often take place because somebody gets singled our for greatness, or more frequently, somebody senior finally gets identified as being a bit shit but no-one really wants to do anything about it.
When organisations reorg just to accommodate someone they don't really want to accommodate, they tend to just organise people into slightly different groupings, while ignoring the operating model, tooling and business intelligence.
@swardley Designing around pioneers, settlers and town planners is possible, and to do it takes a lot of willpower. It's flies in the face of 30 years of received wisdom and getting it right means going back to real basics and having a lot of people look at you funny.
@swardley Lots of the work we do @stanceglobal with customers helps them down the path to being able to implement these models, but pioneers, settlers and town planners are something you get to think about once you've got everything else right. If you start there, it's gonna go wrong.
@swardley@StanceGlobal That in itself is a challenge, because people intuitively understand P/S/TP and want to exploit it. But it is less true for the groundwork that is needed to put the right structures around those people types and govern those structures in a way that takes advantage of them.