Accountability, TPMs, and good handbooks💡
Monday Ideas — Edition #144
Welcome to a new edition of the Monday Ideas! Every Monday I send you three engineering / management ideas to start the week on the right foot.
Here are the ones for this week:
⏲️ The Accountability Dial — a simple framework to correct bad behavior.
🗺️ Signs you may need a TPM — all the right reasons + some of the wrong ones.
📖 The Handbook Journey — the three stages teams go through in using docs.
Let’s dive in! 👇
💸 Get $50 for a 30min product feedback session!
Before we dive into this week’s ideas, my friend Matt Van Itallie, founder of Sema, is looking for product feedback on their new product!
I have known Matt for a long time — we wrote articles and held workshops together.
Matt’s new product is designed to help engineering & product teams keep the roadmap on track and stay aligned, and he wants to ensure that it matches the spirit and ethos of Refactoring.
Matt is offering a $50 gift card for a 30 minute product demo. The only requirement is extreme bluntness in your feedback!
Participants who like what they see will also get 2 months free access to the product 🎁 …in exchange for sharing even more feedback along the way!
If you are interested, fill out this form below 👇 Matt’s going to interview as many people as he can but may not be able to get to everyone who signs up.
Back to this week’s ideas!
1) ⏲️ The Accountability Dial
I am a fan of the accountability dial, by Jonathan Raymond, as a simple framework to correct bad behavior. It is based on five steps:
🟢 Mention — is the first check-in in which you mention the issue. You can address this from a place of curiosity, rather than judgment, by asking questions: “I saw you missed the meeting, is everything ok?” or “Your design doc doesn’t address X, were requirements clear?”.
🟡 Invitation — is a more serious chat in which you address the issue directly. You investigate why it happens, make sure expectations are clear, and that your report knows/has everything they need to get back on track.
🟠 Conversation — after two mentions already, you should have a dedicated conversation about it to express urgency. This is also where you can be more prescriptive about how to fix, and get a commitment in terms of timing.
🔴 Boundary — after three mentions, it is time for a warning conversation that makes it clear there will be consequences if the behavior doesn’t change. If you think your report might not be able to move forward, sit down with them and show them how to do it (when relevant). Nobody wants to be micromanaged on a regular basis, but, every once in a while, microguidance is what people need.
🟣 Limit — is the final ultimatum that makes it clear you should part ways if things don’t improve. This is a crucial conversation to have and should act as the final eye opener for them. Put it in another way: if you lay off someone because of underperformance, and they did not expect it, you did something wrong.
Parting ways isn’t the only way to reset the dial, here are more things you can try:
🎌 Move them to a different team — switching teams can reset their work environment and help them rebuild their impact and reputation with new people.
🧢 Move them to a different role — in some cases, changing roles is useful. E.g. some underperforming managers may benefit from getting back to an IC role, instead of being let go completely.
🏖️ Let them take time off — if you suspect they are stressed out or have personal problems, consider giving them some extended time off.
You can find more ideas on helping underperformers in this previous article 👇
2) 🔨 Signs you may need a TPM
The Technical Program Manager is a tricky role that only pays off once your org has grown beyond a certain size and complexity.
But what is this size, exactly? It depends on many factors: the skills of your team, the type of projects you work on, how much cross-team coordination is needed, and more.
So, instead of rules, you can watch out for signs that you may need a TPM. Here are some:
Bad collaboration — have you noticed a lack of cross-team collaboration on programs? Do you feel information flows effectively between teams?
Missing tasks — are you constantly surprised by a missing task or work stream or dependency on complex programs?
Swamped PMs — have you noticed your Product Managers are spending way too much time focusing on tactical execution rather than strategic action?
Undecisiveness — have you noticed a lack of follow through on decisions, action items, or communication?
Shallow planning — have you noticed that planning feels haphazard nowadays?
Little ownership — do you feel like no one has the full 10,000ft view of what’s happening on a critical program?
Unmanaged risks — do complex projects continuously suffer from completely predictable and otherwise manageable risks?
Bad alignment — is leadership unsure that engineering teams are spending time on the right things?
If you answered yes to half or more of the items above, well, congratulations — you may need a TPM! 🎉
Conversely, here are also some wrong reasons to hire a TPM, that you often hear nonetheless:
I want someone to write our Jira tickets.
I need someone to write meeting minutes.
I don’t want to have to deal with building GANTT charts.
We need someone to offload sprint ceremonies so engineers can write code.
We need someone to come implement Scrum for us.
We need someone to help us be agile.
I don’t want to write or roll up status to leadership, let’s hire a TPM.
We need someone to clean up and keep grooming our backlog.
I need someone to help me manage the meetings on my calendar.
These are all tactical issues that, yes, may legitimately drive people mad, but are not conclusive of the TPM opportunity per se.
Adding a TPM is a strategic choice, one that is grounded in how you want work to happen across teams and projects. Yes, down the line this may help with many of the issues above, but only if their root cause lies in the collaboration and project management work that is TPM’s bread and butter.
We explored the role of TPM in this previous article co-written with my friend
👇3) 📖 The Handbook Journey
A couple of months ago I wrote a guide on how to create good engineering handbooks, inspired by a recent mastermind session.
There I observed that teams usually go through a predictable adoption journey with three levels: handbook-free, handbook-supported, and handbook-first.
Let's explore them.
1) Handbook-free — people are the docs 🙅♂️
Most teams start here. Knowledge lives in people's heads and is transmitted through conversations. This works fine as long as the team is small and everyone talks to each other frequently.
However, when the team grows or becomes distributed, this approach breaks down. Knowledge gets lost, inconsistencies arise, and onboarding new people becomes super long.
To leave this stage you need to start documenting things 👇
2) Handbook-supported — the unstable middle 🥈
This is where many teams land in their first attempt at documentation. The typical pattern is:
Conversations mostly happen in meetings and chat
Decisions are taken and later (often begrudgingly/hastily) reported in docs
Documentation is seen as a chore, something you do after the real work
But here's the key insight: this is not a stable state. One of two things typically happens:
❌ Revert to the mean — if docs always come after decisions, there is little benefit in having docs at all. Over time they become outdated and forgotten, reverting to no handbook.
✅ True adoption — team sees benefits and naturally moves towards a handbook-first approach. The virtuous cycle begins when docs start preventing sync conversations from happening, thus saving time.
3) Handbook-first — documentation drives decisions 🥇
In a handbook-first culture, the dynamic changes completely:
Fewer conversations happen, and they often start from documentation.
Decisions are made because of docs, not the other way around.
The handbook becomes a tool for thinking, not just recording.
Teams that adopt a handbook-first approach are more resilient and do clearer thinking. In fact, writing things down often reveals gaps in logic or process that weren't apparent in conversation.
It also makes knowledge a team quality, rather than a personal one, so that it doesn't walk out the door when people leave. And new team members can quickly get up to speed by reading documented processes and decisions.
You can find a lot more rambling about good documentation in the full article:
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. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca