When working with a new manager that’s reporting to me for the first time, I like to share this document. Hopefully, it helps us get on the same page about our shared expectations for your role. I hold myself to the same bar on all of these – you can expect the same things from me that I expect from you.
These are probably not controversial. If they are, let’s talk about it!
Weekly 1:1s
You should have weekly, regularly scheduled 1:1s with your direct reports. For most roles, this will be somewhere between five and eight 1:1s a week. For product teams, you should also have weekly 1:1s with your direct product manager and design partner. Let people reschedule as needed, but don’t skip too often.
You can expect the same from me. You can also expect that I will have monthly skip level 1:1s with your more senior individual contributors, and any managers that report to you. These are mostly for feedback, which I will share with you as appropriate. I also use them to develop bench talent.
How you run the 1:1s is up to you. You will find that I tend to run mine with written agendas, and lots of transparency.
Tight Meetings
If we’re in a meeting together, it should be well run! As an engineering manager, either you, me, or my manager will probably run 80% of the meetings we’re in together. Even if it’s a meeting hosted by a cross-functional partner, you should take responsibility for making sure it’s well run.
You can expect that if I invite you to a meeting, that it will have an agenda ahead of time. I will make sure that we stay on topic, take notes, and end on time.
If I take an action item in a meeting, I will resolve those 100% of the time (or get back to you and say I won’t be doing it after all).
Excellent Execution
When you commit to a deliverable on a quarterly roadmap, those should be delivered on time 90% of the time. If a team has four or five main items on their roadmap, that means that one item might slip every two quarters. The expectation that 9/10 items ship on time can surprise people; that is a higher bar than industry average for not slipping commitments.
I hold myself to the same bar for the roadmap delivery across all my teams, collectively. That doesn’t mean that I expect teams to kill themselves to hit unrealistic timelines. What I expect is that after a period of forming/storming/norming, a team gets proficient at estimates that include an appropriate risk buffer.
The real secret sauce is when a team develops a working relationship with their product owner such that they can seamlessly trade off scope, time, and quality. In my experience, these teams can deliver on any timeline; because the scope is fluid.
At the end of the day, I expect the engineering manager and the product owner to agree on whether something was delivered on time, and that it satisfies the deliverable. As long as you agree, I’m happy on execution.
You can expect me to jump in and help identify and mitigate large risks that could derail us.
Also related to execution:
- Commitment misses should be on the lowest priority items
- Be able to “do the math” to rationalize quarter level commits based on team velocity
- If you’re going to slip, communicate it early, for example 1/3 of the way in to a quarter
- There should not be confusion about the exact commitment, for example code complete versus shipping to production
Product Partnership
You and your product manager should be in sync. I expect the 360 feedback for each other to be excellent. It’s unusual for there to be a dysfunctional relationship between an engineering manager and their product partner. When it happens, you can expect that I will dive in and try to debug that as a top priority. In this state, the team has a very low chance of success.
For a deep dive, see What are Healthy Relationships?.
Impact Outside your Team
You should have one major piece of impact a year, outside the scope of your team and mission. This could look like shipping an internal tool, revamping an interview question, or updating the company career framework. I can help you identify opportunities. If you sign up to take on something like this, I expect you to proactively drive it forward.
Influence the Roadmap
You should also come up with one major product or foundational initiative a year. These will mostly be in the scope of the team mission, but could be anything related to the overall product, or internal processes. As you get more senior, this means understanding the business context almost as well as a product manager, and understanding the technical context almost as well as a senior engineer. Trust your own insights, and put a stake in the ground about something you would like to see happen.
This doesn’t mean that it’s always going to get onto the roadmap. An ideal outcome is that it influences the product org, and helps set strategy going forward. If this exact idea ships, it’s a bonus. That will probably happen about 25% of the time.
You can expect ideas from me, as well. These are never directives, but I do expect you and your product partner to follow up and either validate or invalidate the idea.
Be Comfortable with Uncertainty
Dealing with uncertainty and ambiguity is part of the job. This will only become more important, the more senior you get. You should never let uncertainty become a blocker for the team, or an impediment to healthy relationships.
You can expect a reasonable level of transparency from me about any given situation. I won’t necessarily commit to pushing to resolve any given uncertainty as soon as possible. That’s often a premature optimization. But, I will tell you when I plan to sit with the uncertainty, and when I intend to resolve it.
Grow a Successor
It’s not always possible, but you should try to have a succession plan for both yourself, and the primary technical lead on your team. Pick one person, and create a growth plan for them. Document where you think they are already ready for a next level opportunity, and where they still have to grow. This will come in handy, often on short notice, when an opportunity opens up. Ideally, we’ve already talked about this person, and have the beginnings of a transition plan in place.
Deliver Business Impact
You’re primarily going to be judged on your track record of delivering business impact. This should not be a surprise; it’s the cornerstone of most written company expectations for any role.
As an engineering manager, we are going to primarily deliver impact through excellent execution. What if something is delivered on time, but does not result in the impact that we hoped for? I expect this to happen on individual projects maybe 50% of the time. I do hold engineering managers accountable for their portfolio of projects, and the total impact. Part of our job is to influence the roadmap towards high impact work, refine the scope so that it actually does have impact, and deliver quickly so that we can fail and learn fast.
Anything in the realm of execution is also fair game. Common blockers like cross-organization dependencies, alignment with leadership, and even a project being de-prioritized before shipping are things we are ultimately accountable for resolving.
Do the best thing for the company
When in doubt, do the best thing for the company. I expect this from anyone in a leadership position. Often there is temptation to optimize for the local team. As you get more senior, I expect you to optimize for the company more.