The Manager-report expectations doc

The Manager-report expectations doc

A manager expects actions and behaviors from those reporting to them. Reports expect a specific kind of support from their managers. However, they will usually choose to play a game where they don’t tell each other. Or, they will summarize their expectations in a two-minute conversation that happens once every six months. Or point to a general career ladder. Then, one will behave out of it, and surprising feedback pops up. Worse! This feedback happens during a performance review.

The manager-report expectations doc is a simple flexible contract between a manager and a direct report. It contains specificities but also outcomes without specific ways of achieving them.

We don’t want to suffocate. The report defines most of the document, and the manager will simply review, edit, and agree. There are examples in the second part of this article.

The reasons to do it

Instantiating the career ladder expectations

Most companies have a Career ladder. It usually breaks responsibilities in some dimensions and describes what the company expects from them at every seniority level. Individual Contributors would have things like technical skill and impact, while managers will have People management, Product Management, etc.

Regardless of your career ladder state, it is helpful to instantiate it for your reports - and for yourself. Instantiating means getting the ladder description that should fit the whole company and tells what it means for a specific person, career moment, team, and point in time.

The people management’s Story mapping

Techniques such as User Story Mapping ¹ focus on a shared understanding between people involved in a project. The lack of clarity on the goals and how to achieve them extends to all human activities involving multiple people.

This document is pretty much doing an “expectations mapping”. Given that projects need people engaged in materializing the multiple thoughts to converge in a shared understanding about its goal and what is required to achieve it, why wouldn’t we like to do it regarding each other’s work?

The same discomfort of clashing different perspectives during Story Mapping might happen during the manager-report expectations craft. That’s the price of facing a complex endeavor.

What the report expects from their manager

Many people simply don’t know what to expect from their manager.

In a manager-report expectations doc, what is expected from the report is defined first. As soon as people know it, it becomes easy to link to specific expectations about their manager, which is usually related to setting them for success on their everyday tasks and behaviors.

For example, we can state in the document, “We expect you influence what we are going to build to achieve this OKR”. The report can set their expectations like “I expect you to get me to the rooms and forums where the decisions about what to build are taken”, “to refine discovery with me”, or “to support me on getting alignment from other leaders to prioritize large projects”.

It is a great moment to help the report know their manager better. For example, a manager telling the person that they can’t help directly improve on a specific technical skill, but they will be accountable to allow it to happen by doing this and that.

A flexible living document

We want to provide flexibility to enable creativity. The more senior the person, the more we expect them to be accountable for the output that drives the outcome. In general:

Jr: low flexibility.
Mid and senior: flexible on how.
Staff+: flexible on what and why.

While elaborating and using it, make it clear it is a tool for the benefit of the reports. If they want to use it differently, or if they want to replace it with something else, be open. Avoid getting in love with the process instead of the outcome.

The big pitfall of documents is that they are born with enthusiasm, but they die in solitude. Visit the doc weakly, bi-weekly, or monthly. Refresh what you expect from people around you, what they expect from you. As understanding changes, propose changes. Make it more specific when definitions start to happen.

A two-way tool for feedback

The fact both will constantly refresh their expectations about each other will make feedback easier. When we do not contrast what we expect from someone to what they are doing, it is hard to come up with feedback since only the extreme cases will grab our attention. For example, a manager who completely lacks providing support, or a report who misses by a lot the delivery quality.

When delivering it, both can point to a document built together, which gives the impression manager and report are working together towards the same vision about their work.

For example, a manager could point to the doc and say: “We agreed on having you mentoring X, but X struggled during that presentation last week, e.g. […]. I feel you could do more here. What do you think?”.

flowchart LR classDef classDefault fill:#286748,color:#FFF,stroke-width:2px,stroke:#286748,text-transform:none; classDef edgeLabel text-transform:none; A[Career Ladder] -->|Instantiation| B(Expecs doc) B -->|Influences| C(day-to-day) C -->|Easier feedback| B C -->|Harder feedback| A style A fill:#286748, color:#fff %%Style class A classDefault; class B classDefault; class C classDefault;

A report could tell to their manager: “We agreed on you helping me to find opportunities to be impactful in a higher scope, but when I brought one for our 1:1, you were not engaged and there was no follow-up, I need your support to shape it better.”

They notice how the work deviates from the non-abstract doc. None is supposed to get surprised.

A bonus is that the document can serve many clients of that person. If other people beyond the direct manager have expectations about that person, share the document.

Clarity on how expectations relate to the performance grade

Commonly, companies have a Performance Review associated with a Performance grade. The grade makes the expectations doc trickier. The best thing is to state the core job and clarify how it will relate to a performance grade.

The one job

First of all, try to put simply the most essential part of that person’s work. The core of their work is the set of responsibilities that, if they underperform, will backlash when we expose their accomplishments to other people in the company. For a manager, the core is to support their reports and lead some specific initiatives. Imagine this manager focused on making the documentation awesome, but all their reports were lost and underdelivered. It becomes an inconsistent performance.

It avoids having people focus on the “interesting ways to go beyond” while failing on what people expect the most from them.

What does exceeding expectations mean?

When we define what we expect from each other, the standard reasoning is “if I do what is there, I will have a grade related to achieving expectations”. It is true when you calibrate each others’ expectations at the company level. If your basic expectations are what exceeding looks like for other people, it is terrible to not be clear on it.

In general, performance grades will be influenced by:

The impact from what was performed
How well it was delivered
How does it compare to other people at the same level in the whole company

Manager and report can do their best to pick possibly impactful projects, and the report can find ways to make their impact beyond expectations. The report is the leading actor for delivering it well, and the manager is accountable for helping calibrate expectations with the company-wide understanding of it.

For managers, regardless of how they choose to express it in the document, make it clear that it is not a checklist. Making everything there and adding more stuff does not mean necessarily exceeding the expectations. Covering everything in the doc can still generate a bad evaluation since how they are delivered matters.

Keep in mind the flexibility we mentioned. If plans change, change it in the doc (or comment to keep the history). Not doing something which became impossible or not the priority should never impact people’s performance.

The more senior the person, the more it is on them to define what and how to do “surprisingly well”.

A manager and a Staff Machine Learning Engineer can agree about the expectation to own the vision of ML systems in their team. The Staff then define they want to do it by “defining the vision with the team and a strategy to achieve it”. Then the person chose good group dynamics to define it, generate clear information, spread it efficiently, materialize it in impactful short-term projects, enable the team to work on the long-term to achieve the vision, doing it in a way it is hard to imagine other Staff MLE doing it so well. They are doing surprisingly well. The manager did not have to define more than the high-level expectation. The report could use the flexibility to be creative and perform beyond expectations - even considering that tackling it was expected.

Managers can expose the expectations their work

Although every report will have a section on their expectations about their manager, the manager will have their own doc about their whole set of responsibilities.

I just started doing it recently, but it was a great sensation to expose to my reports what my manager and I expect from me. I feel like enabling them to support me in succeeding.

I’ve heard of people getting surprised by either a promotion or a firing of their manager, which I believe is unhealthy. It shouldn’t happen if they know what the company expects from their manager.

Building the document

Who starts it?

Who starts and who contributes the most depends on their seniority. As a manager, you start it for interns, junior, mid-level, and sometimes for Senior. If it is the first cycle, the manager always starts it. More about this case in the following session.

Staff+ and managers after their first cycle should be the ones leading the definition of what is expected from them.

The common part

Start the doc with the name, seniority level, and period. Add the company’s career ladder’s expectation description. I’ll use a simple made-up Data Science ladder, following that: Junior (learns how to execute), mid-level (executes), Senior (solves how to execute), Staff (scale how, supports what, lead).

Alex, Senior Data Scientist, 2022/1

Delivery: designs the solutions. Work as a solo developer in small and medium initiatives or as a contributor in large projects, designing parts of the solution.
Ownership: owns important models in their teams, guarantee they are working properly
Influence: mentors junior and mid-level. Supports peers. Influences how we approach problems in their team. Engages when the team is defining what to tackle.

This is what people will often know about what is expected from them. We want to go further.

The first cycle

The formal onboarding and the ramp-up with the Starter Project happen in the first cycle. Describe them well, since it is very likely to be the period you know the best what will happen in the next few months. Be as helpful as possible.

In this file, we formalize our expectations for the onboarding process and the ramp-up we expect to develop with you until you get to the expectations of your level (Senior Data Scientist). We kick off with the general expectation and present the formal onboarding. The ramp-up activities and the first six months consider your team roadmap.

Formal onboarding (first <#> weeks)

There'll be a couple of activities we'll set for you: Company onboarding, [...].

First Week: Company onboarding...
Week #: ...

At the end of this period

You're in all relevant slack channels and meetings for your team;
You've met everybody in the <their team> team (or it's scheduled);
Your machine is set with VPN, GitHub, AWS permissions, your kubeflow node works, etc.
[...]

Onboarding period: Ramping-up (~3 months)

We want to make a ramp-up to make sure you have a smooth transition to <company>! Because of that, we'll work alongside you in activities regarding learning how to execute (junior), execution (Mid-level), and breaking problems to execute (Senior).

Jr. Data Scientist, learning how to execute (1-4 weeks)
We want to test if features related to [...] will impact our [...] model. To make it, you will have to learn how to create these features using [...], train a new version of our model using [...], and present it to other data science people in the team. We expect you take the time to learn the tools involved. The tasks are broken in this Jira Epic.
Mid-level Data Scientist, executing (2 weeks)
We want to evaluate if we should add a new data source to our model. In this task, you will leverage the tools learned in the previous one and support the team to decide. It will present to all team members. The tasks are broken in this Jira Epic.
Senior Data Scientist, designing a solution (Starter Project, 4-8 weeks)
A new version of our [...] model will benefit the team. There are a few possible sources of improvement. We expect you to discuss and evaluate them with your peers and tech lead. You should define the analytical solution. A description of the goal and context is present in the Jira Epic. We expect you to break it into tasks with the help of [...], which will be accountable to help you succeed.

For a manager

For new managers, a ramp-up is also possible. It includes shadowing ongoing projects reviewing together internal processes, OKRs, roadmaps. The one on ones become an excellent tool to verify the understanding.

If the new manager will lead individual contributors, a nice addition to the ramp-up is a hands-on activity. It gives them some autonomy since they don’t have to request everything to their reports, and it enables them to understand their team day-to-day. Of course, only offer hands-on activities following your company’s technical requirements from managers.

Mid-level Data Scientist, execution activity: (1-2 weeks)
We have a framework to evaluate providers, and we have data from three providers to check how they could benefit from one of our models. The goal is to run our framework for these providers and answer the uplift. Here's the Jira Epic about it.
Senior Data Scientist, a high-level problem to break
We have a continuous experiment we use to evaluate our models. We need to decide to keep it, expand or shut down. Design how we can make this decision and pair with an individual contributor to execute it.
Associate Manager, talent management: 1:1s and career at <Company> (first 4 weeks)
Set the 1:1s and the expectations with your direct reports on how you like to do it. Read our career ladder and the performance review documentation. We will discuss your understanding of them in a 1:1.
Associate Manager, product management: understand your team roadmap and the projects every team member is tackling
Review the roadmap for Data Science. Expand to the whole team roadmap. Make sure you understand every project and its importance. We will review it together in a 1:1, take your questions to it!
Associate Manager, project management: <Project name>
You're going to start shadowing an ongoing project's rituals. We'll lead it together until the end, but I'm still accountable for it. Your focus should be on understanding the way we work, the rituals, observing what we can improve. Additionally, you'll need to understand how we manage models. So read the model governance documentation. We'll review it in a 1:1.
Manager (your level), project management: lead the X model (3 months)
This is your starter project and the first delivery you're going to be accountable for. This will include discovery, whiteboards, RFCs, planning, design of the releases, story mapping, development, model approval, deployment, the full cycle! I'll be shadowing it during the most critical parts and ensuring you succeed.
Manager, continuous, the onboarding is done!
After all these steps, you're expected to perform consistently in your scope!

The following cycles

There are many different situations, and the idea of the manager-report expectations document is about personalization, so it does not make sense to provide examples for all the conditions. Here are situations to pay attention to and adapt to:

Someone coming from a bad performance evaluation;
Manager and report want to stretch to pursue a promotion in the future;
It is the first cycle after a promotion;
The person is going to a new team;
There is a career change involved;

Example for a Senior Data Scientist

A Senior Data Scientist would very likely kick off it. Here’s a compact example of someone working in an identity fraud team. A real one should contain more details. A good strategy is to break the sections into the exact dimensions your company uses in the career ladder. Notice how our expectation depends on the team composition and the business involved.

[...]

Projects to get involved

Model X V2: As the main developer, leading the design reviews, accountable for the analytical solution, [...]
[...]
Other projects from the Fraud ID work stream that will be defined during the cycle.

Influence

Freedom to define how we'll tackle Model X V2
Be an active voice during the brainstorms with the whole team, not only DS
Influence how we monitor some business metrics by getting together with our analysts

Ownership and trust

Owner of the Fraud ID model: responsible for guaranteeing it works propery: monitoring and fixing bugs.
Accountable for the technical quality of the deliveries from X, the Jr. Data Scientist in the team
Be active when we are under attacks, contributing to define a quick solution
[...]

Skills to develop

Communication: written and oral. Technical presentations to peers and team.
Coding: [...]

Other activities

Contribute with 1-3h weekly to hiring;
[...]

Expectations about my manager

As I want to develop my communication skills, I'd appreciate deck reviews and your attendance, followed by feedback. I expect you to find me opportunities to expose my work to the right audiences.
It is hard for me to decide when it is good enough. I have a tendency to over-optimize. I expect you can support me in developing this skill and feedback me about it constantly.
I want to get more involved with the engineering part. I expect you to find me some learning opportunities and help me ramp up.
[...]

Conclusion

As with any particular practice, the most important is to follow the principle: a continuous effort to offer clarity on expectations. The doc can follow any format or be made in different tools, as long as it materializes the shared understanding between two or multiple people about what they expect from each other.

I’d like to thank Data Science Managers, Data Scientists, and Machine Learning Engineers working close to me for embracing this practice and refining it: Moisés Arizpe, Irene Petlacalco, Bruna Alves, Gabriel Ferreira, Pedro Igor, Ana Ortega, Ricardo Ocampo, and Juan Medina.

References

Patton, J., & Economy, P. (2014). User story mapping: discover the whole story, build the right product. : O’Reilly Media, Inc. ↩

Table of contents