The purpose of this document is to think through how to manage decision-making authority, performance management, and (resourcing?) in order to maximize our effectiveness and reduce complexity and misunderstanding.
Some of this memo will touch on the typical manager-to-individual-contributor relationship (like an individual contributor (IC) engineer and their engineering manager), but the bulk of this memo is intended to think through leader-to-leader relationships, which are inherently more complex.
First, let’s align on definitions, then on the problems we seek to explore. These might seem like arbitrary semantic differences, but they have real implications. First, definitions:
It’s important to distinguish between these two concepts because they solve different problems (though they often overlap).
<aside> ⭐ “Reporting” solves the problem of performance management.
</aside>
Reporting matters when managing performance. When you’re accountable (more on this in the next section) to someone for the delivery of a project, you are expected to perform, but that accountability has inherent limitations.
If someone does not report to you (meaning, you don’t have the responsibilities that come with being their manager), there’s only so much you can do to remedy the situation when someone is not performing. You’re not in a position to change their priorities, work with them on a performance improvement plan, or change the scope of their role. Being in this situation can feel like your hands are tied, and it’s incredibly frustrating.
<aside> 📖 I was actually talking to another CEO recently who is in this situation now. Someone on his executive team is not performing, but he doesn’t have the authority to change this person’s role or move them on from the company — he needs Board approval. Unfortunately, this person is especially cozy with the Board (I was getting flashbacks of Sarah from The Phoenix Project) and the Board doesn’t have enough context on the situation, so they haven’t taken action. His hands are tied.
</aside>
The way you visualize reporting is simple. This is the typical org chart that you see in every company, with everyone at the company reporting to someone, which ultimately ends with the CEO. Example below.
Your manager is responsible for your performance, setting your priorities, and for helping you achieve your personal goals, among other things.
The person you report to should be the person with the most context on the primary work you’re doing. They should be the person with the best lens on whether you’re meeting your objectives and they should be the person who can help you define those objectives. This can change as your role in the company changes — we are a startup after all!
We also want to avoid situations where people frequently change managers. It takes months to get ramped up with a manager, and it’s disruptive to change managers on a regular basis. If we change someone’s manager more than once per year, we should seriously investigate if we’re doing something wrong.
If your primary work output is in service of a larger company objective, and that objective is owned by someone else, it’s likely that you should be reporting to that person. For example, @Tom Griffin is responsible for Partnerships, and Partnerships is in service of the top-level growth company objective that is owned by @Ben Grynol. Therefore, @Tom Griffin should report to @Ben Grynol.
A good rule of thumb is:
<aside> ⭐ If someone’s primary expected output for at least the next 6 months is in support of the higher-level goals of another group or team, that person should report to the owner of the higher-level team.
NOTE: This definition only applies to leader-leader dynamics, not to manager-ICs. Manager-IC are often grouped by functional area or specialization (e.g. “Frontend Engineering”)
</aside>
Another thing to keep in mind is that leveling (“L4”, “L5”, etc) is confidential, but reporting is not. Leveling is the primary determinant of someone’s compensation, not their decision-making authority or management role within the company.