Diversity, accomplishments, and docs 💡
Monday Ideas — Edition #122
🪣 Bucket — become a product engineer!
Last week’s article about product engineering was a hit 💥 — so many of you responded with questions and comments. Thank you so much!
For this reason, this week I am happy to promote Bucket, which is the product that Rasmus is building to help with that (also, feel free to reach out to him for any questions!)
Bucket gives you everything you need to build better features, confidently: feature flagging, adoption metrics, and customer feedback, with a single feature key.
Start for free 👇 and use REFACT0924 to get 10% off any Pro plan.
Back to this week’s ideas!
1) 👩🎤 Diversity is about your users
One of the best insights I got from our recent interview with Dana Lawson, is about diversity.
Dana has a practical approach to it: your team composition should reflect that of your community of users. That’s because you need to serve your users and empathize with their problems.
So, sure, if your users are all 20-something white males, go for it 🤷♂️ but when your product serves a global, diverse audience, your business benefits from representing those people on your team: ethnicities, genders, and backgrounds.
That’s how you create a better product for them.
2) 🏆 The Hierarchy of Outcomes
In one of the first interviews I ever did, before launching the official podcast, I chatted with my friend Matt Van Itallie about accomplishment journals — aka brag docs.
I am a long-time supporter of journaling — I believe it has incredible benefits, both for your career and on the personal side.
When it comes to accomplishments, one of the things people are often confused about, is what makes for an accomplishment. Matt has two pieces of advice on this: 1) favor outcomes over outputs, and 2) use the hierarchy of outcomes.
🎯 Outcomes — are the results that matter the most and create real value: e.g. conversion rate improved by X.
🧱 Outputs — are anything else that came from the activities but is less important than the outcomes. E.g. “I released X” is typically an output, while the outcome is how it created value for the product/business.
When you choose what to write down, favor real outcomes when they are available, and fall back to outputs when they are not.
Also, people can be biased as to what makes for a good outcome/output. To counter his own biases, Matt developed a hierarchy, from the most important to the least important:
🥇 Objective results — this is the #1 thing you should look for. Things like user growth, revenue, but also actual events, like a member of your team getting promoted.
🥈 Subjective opinions of people who matter a lot — this is the opinion of people who have some weight and are able to observe you closely. E.g. specific praise from your manager matters more than a pat on the back from the CEO who is completely removed from your job.
🥉 Subjective opinions of people who matter less — here is the opinion of people who have less weight or influence, and/or were not close to the activity. This totally depends on the activity, and might be: feedback from co-workers, praise from marginal stakeholders.
🤡 Your opinion — the least important category is your own subjective opinion! We all have plenty of biases about ourselves and we are not particularly good at evaluating what we do. However, your opinion is still useful to write down, especially to compare with #1, #2, and #3 and find such dissonances.
You can find the full article and interview here:
3) 🔄 Virtuous & Vicious Docs
Speaking of journaling and docs, yesterday we held our monthly community mastermind, and the topic was Engineering Handbooks — what they are useful for, what should go in there, how to keep them up to date, and more.
People shared a ton of insights and, as always, they will make it into a dedicated newsletter edition.
One topic we discussed was how docs tend to create self-reinforcing cycles — good or bad.
Let me explain.
People are happy to write and update docs when they perceive that their future value is higher than the current writing effort.
Whenever this is the case, you get a 🟢 virtuous cycle:
People write more docs because they feel they are valuable
Knowledge grows larger, more insights are discovered, decisions are taken faster and better
People read more and more docs instead of having meetings
Conversely, when future value is perceived as lower than writing effort, you easily slip into a 🔴 vicious cycle:
People stop writing docs because no one reads them
Docs become partial and outdated
People don't trust and read docs anymore
So, in my experience, to improve docs you should act on those two levers:
⬆️ Increase future use — by embedding docs in processes, turning meetings into shared notes, and making these a core part of how work is done.
⬇️ Reduce writing effort — through templates and clear structure. Don’t make people think about how they should write things, or where they should go.
Documentation is one of my small obsessions (I am a writer after all) and I wrote a full guide about it 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca