Request for Faster Horse (RFH)
A Story Template Cannot Fix This
Templates can be wonderful, but not when they are used as an excuse to avoid thinking.
“Our way of doing X is not good enough“
So, you were faced with a complaint that sounds like one of these:
Engineers miss a lot in code reviews
Product Managers aren’t giving enough details in tickets or explaining the customer needs
We don’t know where to start to build a good strategy or what good OKRs look like
The team is not functioning well
Of course, for every major common problem in our industry we are offered many websites, all offering templates to solve these problems:
Pull Request Templates with code review checklists
Business/Product/Architecture Requirements Document templates
Story templates
Strategy templates
Team Retrospective templates
RFC and ADR Templates
So after spending a day of researching template formats you find one that kind-of feels right but misses a lot of the “important parts” you want to solve. Your solution is to spend another day or two tweaking it and making it “specific to us”, maybe even adding the company logo and colours onto it so it looks official. Next, you spend two weeks pushing it internally in a small group, some like it, some others really think you should use an alternative template they really like instead. After a month of stagnation and indecision it finally happens, someone got fed up and just applied the document to the system template.
But, what were the outcomes? The template is now system default for new work, and there was an email that even explained why we are using it and that it was important. But why is the work quality not improving in any of the areas we really cared about? Some people try to use it but miss the point. Lots of people just go through the motions to put some text (any text) in the boxes even if it really has nothing to do with why those fields in the template exist. A few stragglers reject the template entirely, finding a way to avoid using it and doing whatever they want instead.
A year later the template sits there like a museum relic, nobody is willing to get rid of it but it also has no purpose in the modern world. A new hire asks how to fill out the template correctly and is instructed to ignore most of it.
Templates as an excuse to not think
The real problem you were facing was never missing “just one good template”, it has always been culture, agreements, and standards. A thoughtless blank page with headings cannot drive a cohesive culture that cares about quality work, forces disagreements to become agreements, and bring clarity to work standards. That is the job of people, not paper. I will go so far as to say that if you are a manager who has rolled out a new process template and not ensured there is a deep-down “feel-it-in-your-bones” cultural transformation of your people: you have not done your job correctly. Sending an email out or holding a call to “introduce the new format” is avoiding all the work you should be doing. Talk 1:1, intensely mentor them through the first five times they use the template.
At some companies like Amazon they are known to have a process called “a six pager” which was a reaction to the same root problem that prevents templates from being effective. They had too many powerpoint slides with only shallow details, which meant the standard held for a typical thought-worker was that they only needed surface-level thinking to do their job, meaning few people thought through the details in-depth, and it was getting obvious. The six pager is meant to force people to think. That’s the only reason it exists. People were not thinking, and if they were forced to write a six page essay it was more likely to force them to think.
Did you notice all the caveats in the previous statement that makes the six pager fall apart at many orgs? If the six pager is an aggregate of short paragraphs from 10 or 20 authors there was no opportunity for deep thought to happen in any individual person. If there was nobody forcing quality standards being held the document will be full of fluff. I have seen six pagers that no single person fully understood even after reading the entire document. I have seen six pager conference calls (where it is intended that everyone spends an hour of silence together reading the document for the first time) end where few (if any) people understand the entire document, or information was massaged and softened to the point where a loss sounded like a win. I have even seen six pager calls where sections carry content forward from previous meetings with minor tweaks on some KPIs or fluff statements about the market conditions to pad it out. Infact, in the email where the six-pager was top-down mandated at Amazon the reason was made explicit: “Powerpoint-style presentations somehow give permission to gloss over ideas […]“.
This “glossing over” is exactly what happens when templates are used when there is permission to gloss over ideas. The point is not to write an essay, the point is to understand in-depth. The sad reality is that this tool that forces thinking is so misunderstood it has become like a template in other companies. If you google for it you will even find a template for a six pager which usually document what one individual person saw at their specific team when working there. This is then taken as a “fill in the blanks” activity by users of the template who wish to try and replicate the things done by successful teams while missing the fundamental reason the format exists. Even this “please think for six pages instead of writing some bullet-points“ format cannot escape the relentless push and creativity applied to avoid building deeper understandings of problems.
There truly are people walking around who do not understand the reasons for different documents like PRD and BRD, which is fine, nobody can know everything. It only becomes a problem when the differences are flippantly dismissed as something like “a literal alphabet soup of acronyms representing very similar things”, avoiding any need to think about how to establish discipline or get quality work done. These people are charlatans who fear details instead of confronting, embracing, and structuring them. The ultimate irony is that this separation of having both a BRD and a PRD exists precisely to differentiate between business and product requirements; it intends to make it clear that they are different things and independently deserve focused deep thought.
You even see it in code review checklists that list a number of things reviewers should look for in code. The “review checklist” has a list of last year’s hot topics and some good-old-rules, slowly turning into suggestions, eventually being ignored due to lack of relevance, but never deleted because it is too hard to replace. All too often these checklists feel good when they get posted, but have limited impact on driving code quality long-term. Worse, it is a limited list of what to look for, limiting the space of the review to things that may have limited importance in generic situations, and missing the elephant in the room every time.
Request for Faster Horse
“If I had asked people what they wanted, they would have said faster horses.”
- Attributed to Henry Ford(context: Ford was mass-producing cars in a time where cars were new, and Horses were the common sight on the street.)
Ford recognized customer feedback was often lacking deep thought about the bigger picture: how to transform transportation in general to provide a more powerful product. Instead customers tend to just “increment by one” because they are not focused deeply on your problems, they are focused on how your solution integrates with their world context.
All too often templates for RFCs, BRDs, PRDs and others are simply outlining “Hey, I want this thing.“ There is no deep thinking, these are just “incrementing by one“ of a status-quo or thought-limiting blinders. BRDs describing nothing about the business problems, PRDs asking for very specific implementations, or RFCs that are just something cool an engineer thought up in a closed room. I propose a new acronym into the family: the RFH (Request for Faster Horse). An RFH is easy to write as you can use any template or format from any website or internal doc. To write a good RFH you just have to remove deep thinking from the BRD, PRD, RFC, OKR, Story, Epic, checklist, or any other term you can come up with.
Jokes aside, I create and maintain a few templates myself and find them very useful. The problem is that usually these templates cannot be handed over effectively without deep levels of training and explanation about how to do everything properly and avoid common mistakes. Templates can organise thinking, but the thinking still needs to happen. It’s too easy to fraud your way through to appear to have thought about a problem by filling out all the boxes in a template, and it is even easier when you are left alone to do it with nobody holding you accountable, giving critical feedback, or mentoring you on how to improve the quality of your work actively with each document. If the templates are used as a tool to not think instead of a way to structure good thinking, you will turn them into useless relics that cannot drive outcomes, just adding process weight and disappointment. These templates become poorly distorted copies of a copy of a copy of a copy interpreted by people who never knew the original context for it existing in the first case.
Templates ask for Input and generate Output. A good Outcome is not something that your template will do for you.
So, will you write a Strategy Document or an RFH to solve your next problem?