loading . . . Taking care to introduce standards Iâve written recently about âenabling teamsââthat is, teams whose purpose is to enable other teams to do things which typically require rare expertise. Examples are security, accessibility and quality assurance. These are important and valuable aspects to product development, but the skills and expertise needed are often in short supply in an organisation, so the few people who have them form an enabling team, as promoted by Team Topologies.
As part of that, this question came up in the comments: Why is it that such expert groups so often go beyond giving or writing advice and start to write standards and requirements, and try to push others to adhere to them?
Iâve been guilty of this myself, and it was a defence mechanism against perceived irrelevance. This is not a period in my career that Iâm proud of, but it happened, and I can only hope everyone recovered from it and is reasonably forgiving (or forgetful). I was in a role that supposedly carried some responsibility for ensuring projects ran smoothly, but I couldnât find anyone doing the actual projects who particularly saw there was any problem there that needed fixing. Or perhaps I misunderstood my job. But as a result I couldnât propose anything that seemed useful to people, and so I was largely ignored. As a reaction to that I introduced processes and standards which people âmustâ adhere to. It didnât work out well, and I hope Iâve learned a lesson.
You may ask how I was able to introduce these processes and standards if they werenât relevant to or welcome by the people doing the work. Thatâs probably down to me persuading my key senior stakeholders (who were not the ones at the project coalface) it was worthwhile, and them not asking sufficiently hard questions. But I cannot escape primary blame.
This is not to say organisational standards canât be valuable. They certainly can be. There is a time where mere guidelines are not enough and we need something stronger.
But standards need to be introduced with an understanding of (a) what theyâre trying to achieve, and (b) what impact they will have on the organisation.
Asking what theyâre trying to achieve is usual, butâif it is askedâis often not interrogated with sufficient rigour. Our problems might be âpoor project deliveryâ, say, but thatâs quite generic. Within our organisation there will be very specific issues, and so any generic answer (such as âletâs do agile developmentâ or âletâs do PRINCE2â) will probably do more harm than good.
We also often fail to assess the impact of imposing any standards. Writing them down is fine, but how will people discover those documents? How will they interpret them? How will they actually adhere to them? What additional skills or time will they need? How will they know if theyâre meeting those standards, and what will happen if they donât? Not just what will happen to the people, but what will happen to all the things we wanted to deliver as an organisation, and which are now clashing against new demands?
Lots of organisations have a Design Authority, which assesses technical design for products and projects, and confirms they adhere to the corporate standards. Usually approval of the Design Authority is a gate on the way to release, and the people on the Design Authority panel therefore act as gatekeepers. The best Design Authorities Iâve worked with make sure those on the panel spend a lot of time outside the monthly meeting supporting product teams, ensuring they understand the standards and can find good answers to the hard questions they will be asked. They work with those teams early and continually, so they are well-informed, well-prepared, and are not surprised. They act as an enabling team.
In these cases the Design Authority is a real corporate investment. Individuals on the panel may now be spending a good 25-50% of their time supporting product teams across the organisation, which is time away from whatever they were doing before. Setting up this kind of thing is much more than writing a few standards documents and sticking a new monthly meeting in the calendar.
Some Authorites evolve that personal support into something faster and automated: the golden path. This is when some elements of the standards have such common solutions that they are provided half-built. I worked with one organisation to develop one of these, for security monitoring. Their security team effectively said to the product teams, âWe need you to demonstrate your product meets these security standards. We donât care how you do it, as long as you show that you do. However, hereâs a technology framework we support. We have a recommended configuration for it that almost guarantees youâll to meet the standards.â Product teams get a boost to their delivery, and the organisation meets its standards much more easily. But designing, building, testing, documenting, supporting and evolving such a technology is no mean feat.
So going back to the question: standards arenât necessarily bad, but they can be introduced for the wrong reasons, or for reasons that are not adequately explored. And positive results from those standards can require significant investment. Too often, that, too, is ignored.
_Photo by Nicholas A. Tonelli_
### Share this:
* Share on LinkedIn (Opens in new window) LinkedIn
* Print (Opens in new window) Print
* Email a link to a friend (Opens in new window) Email
* Share on Tumblr (Opens in new window) Tumblr
*
Like Loading... https://niksilver.com/2026/02/10/taking-care-to-introduce-standards/
