samarv/manager-readme-for-scaling-trust

The Manager README for Scaling Trust

This skill allows you to "scale yourself" by documenting your leadership style, expectations, and personal quirks. In high-growth environments where headcount doubles or triples annually, a written manual provides immediate clarity, reduces the "getting to know you" friction, and creates a safe space for radical candor.

Core Components of the README

A high-impact manager manual should be broken into three primary sections:

1. Expectations and Success Traits

Define what "good" looks like in your organization to remove ambiguity.

• Values in Action: Don't just list values; describe behaviors. (e.g., "Customer obsession means doing deliveries yourself to find bugs.")
• The Bar for Quality: Be explicit about what traits you value most (e.g., bias for action, intellectual curiosity, humility).
• Communication Norms: Detail your preferred channels (Slack for quick updates, email for deep dives) and expected response times.

2. Personal Operating Manual (The "Keith" Section)

Be ruthlessly transparent about your flaws and how to navigate them.

• Personal Quirks: Admit to your "bugs." (e.g., "I am a litigator by training; I tend to argue about things even if I agree with you just to test the level of conviction.")
• How to Give You Feedback: Lower the barrier for upward feedback. Explicitly state that you expect to be challenged.
• The T3 B3 Framework: Implement a "Top 3, Bottom 3" pulse check.
  • T3: Top 3 things the manager is doing well.
  • B3: Bottom 3 (constructive) things the manager needs to improve.

3. Commitments to the Team

State exactly what the team can expect from you in return for their performance.

• The "Career-First" Promise: Commitment to the individual's long-term career, even if it leads them away from the company.
• 1:1 Structure: Reserve specific time for career coaching. (e.g., "The last 10 minutes of every 1:1 are dedicated solely to your professional development.")
• Resource Protection: Your commitment to getting them the tools they need and getting out of their way once they are enabled.

Implementation Guide

1. Draft the Document: Write the first version focusing on your "bugs" and your "non-negotiables."
2. Request "Bug Reports" from Peers: Ask current colleagues if your self-assessment of your flaws is accurate.
3. Deploy to New Hires: Send the document during the offer stage or on Day 1. Use it as an "icebreaker" for the first 1:1.
4. Action the Feedback: When someone uses the "Bottom 3" to give you feedback, thank them enthusiastically and report back in the next 1:1 on what you changed.

Examples

Example 1: Managing a High-Stakes Conflict

• Context: A PM and a Designer are stuck in a deadlock over a feature.
• Input: The PM has read the Manager's README, which states: "I value steel-manning. If we are stuck, I will ask you to argue the other person's side."
• Application: Instead of escalating for a "decide for us" meeting, the PM asks the Designer to swap roles for 10 minutes to argue the opposing case, as per the manager's documented framework.
• Output: The team reaches a compromise without needing a tie-breaker, increasing velocity.

Example 2: Receiving Hard Upward Feedback

• Context: A Director of Engineering feels their manager (the CEO) is being too "curt" in meetings, making the team nervous.
• Input: The CEO’s README says: "I know I can be aloof when I'm focused on numbers. Use T3 B3 to call me out."
• Application: In their 1:1, the Director says, "For my B3 today, you seemed dismissive in the sprint review. It’s making the devs hesitant to share bad news."
• Output: The CEO thanks them, acknowledges the "bug," and sends a Slack to the team clarifying their intent, reinforcing the culture of trust.

Common Pitfalls

• Treating it as Static: A README is a living document. If you get feedback that you've developed a new bad habit, add it to the "Personal Operating Manual" section.
• Lack of Action: If you ask for constructive feedback via the T3 B3 framework but never change your behavior, the team will stop being honest. You must demonstrate that "feedback is a gift" by actioning it.
• Using it as an Excuse: Don't use "I'm just an asshole, it's in my README" as a shield. The goal of documenting a flaw is to provide a roadmap for others to help you fix it or navigate around it while you work on it.
• Ignoring the "Next Job" Conversation: Managers often fear talking about their reports leaving. Avoiding this prevents the transparency needed to plan for backfills and creates "surprise" departures.