Working Backwards is the first book to describe how Amazon really works, written by two insiders who were in the room when the techniques were first invented. I finished the book a few weeks ago, and I’m still chewing on many of the ideas.
As I read this I couldn’t help but think about the distinction you’ve made between deliberate practice and tacit knowledge, but where the thing being developed is a product, not a person.
The “iterated taste” examples you share all involve designers crafting something that is whole enough to become critiquable - in the same way as you have to start running before you can start getting feedback about your running. From then on, it’s an iterative process of regular exposure to coaching. (And just like professional sports coaching*, the coaches have the discretion to cut you from the team if they don’t feel like you’re a top prospect)
And I might be stretching this, but a lot of traditional agile software development feels more like “deliberate practice” in that people make an initial push and then spend lots of time trying to iteratively get better. In some cases this iteration is a straightforward matter of adding features and scaling performance, but it may fall into the same trap you describe with deliberate practice that “if you are in a domain with little known training methods, you cannot do deliberate practice in its pure form”, and it may explain the focus on some companies to “move fast and break things”.
* Note - I don’t actually do sports. I think this is how it works?
Having the right people in the room is important for all of these methods. It’s interesting that the ‘high design skill’ teams sound more selective on this factor than Amazon. Perhaps optimizing for scale necessarily requires compromise on this, because there are relatively few great designers, compared to great implementers.
I’m not sure if the analogy between DP and tacit skill acquisition maps exactly to this. I get what you’re saying though — one involves feedback from a group of tastemakers/people with good taste; the other one iterates for improvement against the market.
What I will say, which I didn’t include in the piece, is that people do become better at reading PR/FAQs and giving feedback over time. I’ll quote the authors directly:
“Senior managers, directors, and executive leaders who oversee the authors of PR/FAQs become skilled evaluators and contributors to the process. The more PR/FAQs they read, and the more products they build and launch using the PR/FAQ process, the more capable they become at identifying the omissions and flaws in the author’s thinking. And so the process itself creates a tier of master evaluators as it vets and strengthens the idea and aligns everyone involved in the project, from individual contributor to CEO.”
I’m currently working on a full Working Backwards summary, and one of the things that Amazon seems to really grok is this idea of spreading tacit knowledge. Here’s an example: they have a hiring process called the ‘Bar Raiser’ program where every hiring loop is assigned a Bar Raiser — an individual whose task it is to ‘raise the bar’ on hiring. He or she acts as a coach for the interviewers, and holds veto power over the candidate — if the Bar Raiser says ‘no’, then the candidate is out, no matter how promising.
What’s particularly interesting about this program is that the original set of Bar Raisers were a bunch of skilled interviewers at early Amazon. And the way Amazon expanded the program was that only existing Bar Raisers could invite new Bar Raisers — and new BRs had to go through a training program (which many do fail!) So in this manner they are able to pass down tacit interviewing skills, even while they formalised most aspects of the interviewing process.
The tacit part of ‘getting good at reading PR/FAQs’ seems to be a thing, though it doesn’t get as much play in my post, or in the book. Those who are good at evaluating PR/FAQs (perhaps because they’ve done it longer, or they’ve built and launch at least one product through the process) are assigned more PR/FAQs, so they set the example for others to simulate.
I’m going to zoom in on my particular career of Product Management here, and ask: how might an org spread tacit knowledge amongst PMs?
I think of Product Management as a high-tacit-skill job: sensemaking; world-building to avoid designing ourselves into a corner; Interviewing users; Managing stakeholders/herding cats; Decision making; etc
All of these things happen, but they happen invisibly. You also can’t really back into them from the final shipped product, because that product will have involved many iterations and accreted layers of the above skills, along with input from many other people
So are there deliberate practice opportunities for PMs?
This is a GREAT question, @alex. I think the right way to think about this is to ask if there are org processes you can create that encourage mentorship or guidance.
For instance, many PMs already do one-on-ones; but would it be possible to find some sort of … excuse to have more experienced PMs mentor less experienced ones?
The obvious thing is to ‘create a mentorship program in the product org’, but this may be difficult to get off the ground. (It’s a lot of work, for one, and not everyone understands what mentorship is).
I’d look for something more … oblique. For instance, Andy Grove had this thing at Intel where he would get managers to do site visits. Ostensibly the reason was to inspect the, urm, site, but the real reason was to cut through the bureaucracy, so that managers would be exposed to problems at lower levels in the org.
Some ideas, feel free to add:
You can get the flavour of the thing I’m going for, I think.
Absolutely incredible suggestion. I hadn’t even thought of this and I was going to just forge forward with the “we should do a PM mentoring program” that I’ve seen try and fail at other companies over and over. I’ll keep mulling on this, and thanks for generating those ideas to get me started too!