What is my Manager Doing?
Objective
I often get asked what it is like being a manager at a big tech company. In order to help with (indirectly) answering that, I wrote this list of all my regularly-scheduled processes. It gives a little insight into how I stay apprised of and influence all the work in my organization.
This only covers regular meetings, it does not include technical contributions like coding or writing/reviewing design docs.
Direct 1:1 Meetings
I meet bi-weekly with each of my direct reports. This is an opportunity for my reports and I to check in with each other on any topic. We typically discuss progress on projects, career growth, and challenges at work. In practice all sorts of random topics arise. I have one report who loves to spend time at the end of the meeting talking about the latest TV show and book we have read. It's a lot of fun.
I keep a notes doc for each meeting that is shared only with my direct report. This gives a history of topics for posterity. This is a space where my report and I can post topic reminders ahead of our next 1:1 so that we don’t forget about them.
Expectations Check Ins
Once per quarter I have an expectation check in with each of my direct reports. This is an opportunity for my reports and I to understand the progress we have made on our quarterly projects so far. Ideally, this meeting happens at the midpoint in each quarter, i.e., week six. This replaces my regularly scheduled 1:1. I try to finish them all by week eight at the latest.
Occasionally we identify when projects are behind and it allows us to pivot engineering resources to get it back on track or to deprioritize the project if it is no longer critical. I try to provide strategies to keep projects on track and advice to unblock folks. Engineers, especially junior ones, suffer from Annie syndrome; they are eternally optimistic that the feature they are implementing will be done tomorrow. It can take an entire meeting like this to get them to reflect deeply enough to realize they are much further behind than they thought.
Engineer Report Card
Once per quarter I review an engineering report card with each of my direct reports. This is a rough characterization of how much each engineer completed in the previous quarter. My report card template includes:
CLs and lines of code written in the quarter and year-to-date
CLs reviewed last quarter
A grade for each complete and incomplete project
A list of all the documents the report wrote
Specific feedback from me
Kudos and feedback from peers
None of these are good metrics to optimize for; it is easy for an engineer to increase the number of CLs they write by arbitrarily splitting them up into smaller pieces. These metrics only provide a rough characterization of the work output by the engineer each quarter. The metrics do work well as minimums to check for. E.g., if a report wrote zero CLs in a quarter it's probably worth looking into what they were up to.
The report card is also an opportunity for my reports to inform me of any unplanned work I may have missed so that I may iteratively build their calibration packet throughout the year.
I also ask three simple questions to create an opportunity to discuss career growth:
How would you rate your performance?
If you could change one big thing, what would it be?
How can Jim help?
In order to generate these metrics I do a deep dive on all my report’s work for the quarter. I manually look through all of their design documents and add them to my running spreadsheet of all docs for the year. I query CL stats to get their CL numbers and the percentiles of CLs in all of my product area so that my reports have an understanding of their output relative to others. I do a cursory look through post mortems and high severity bugs from the quarter so that I can call out any heroics/firefighting that they performed.
I am half way through Accelerate and am excited to add some new metrics to this report card soon.
Annual Project Planning
Once a year I participate in my product area’s annual project planning process. This process begins by soliciting projects from our business partners and our engineers. Business partners submit projects that are priorities for them for the next year. Engineers propose projects to improve the platforms we maintain.
Once we have project descriptions, I partner with my engineering leads to estimate (as best as possible with incomplete information) the engineering effort (typically measured in focused engineering weeks) needed to complete each project. We then work with our business partners to rank the projects based on the impact of the project relative to its cost. Based on the number of engineers in each of my teams, we compute a simple bandwidth for each team for the year. This allows us to commit to projects until we have reached our bandwidth for the year. Any project not committed is marked as “below the line”. This gives us and our partners a rough plan for the large projects we will deliver for the next year.
My participation in this process typically lasts from the beginning of June until the end of August. Approximately 25-50% of my time is occupied with this process as I meet with business, engineers, product partners, and UX partners from each of my teams.
I typically like to look back after the annual plan is submitted and put all the projects for the next year in conversation with each other by writing a tech vision doc. This is an opportunity for me to identify trends between teams and areas for collaboration. It is an opportunity for me to influence the technical direction of the team. It is an opportunity for me to engage my engineers in a thoughtful discussion about what things need to be built to support the 2025 requests with excellence.
Quarterly planning
Once each quarter, I participate in my product area’s quarterly project planning process. This is similar to the annual planning process but on a smaller time scale. Business partners submit projects that are priorities for them. Engineers propose projects to improve the platform. Product area leads review the annual plan and submit projects to make sure we are making progress to complete the annual projects.
Once we have project descriptions, I partner with my engineering leads to estimate the engineering effort needed to complete each project. We then work with our business partners to rank each project based on its impact. We use that list to commit to which projects we plan to deliver the following quarter.
We look at the bandwidth of each engineer and come up with a proposal of which engineers will work on which projects. There are many considerations when making this proposal. Important considerations are:
balancing engineers workload
balancing high priority items and those with hard launch dates amongst the team
presenting strong trajectory engineers with growth opportunities
My part in this process typically occurs starting on the sixth week of the quarter and ends on the tenth. Approximately 25% of my time is occupied with this process.
I copy the projects into an official tool once they are finalized so that all my business stakeholders have a single place to view all of my committed work. I include the original engineering estimate of the project and the actual amount of work in each project. The latter comes from simply asking engineers how much time they spent and may not be entirely accurate. I expect engineers to produce an artifact that I can link to at the end of the quarter. Examples of an artifact include:
a Buganizer ticket linked to the implementing CLs
a design document
a launch document
We are also asked to score projects as part of this process. I score all projects after the quarter is over as discussed in an item below.
Ratings Discussions
Once each year, I review my reports’ ratings with them. This typically happens early in the year. I compile all the report cards I have built to create one big calibration packet for the whole year. The rating discussion is a chance to celebrate my reports’ accomplishments, give critical feedback, and discuss ways for the report to grow in the next year.
4-Box Meetings
I meet weekly with the 4-Box for each of my teams. A 4-Box comprises an engineering, product, business, and UX lead. In these meetings we discuss:
the progress of key projects throughout the quarter
projects to work on next quarter
challenges with day to day operations
brainstorming ideas for future work
Iteration planning
I occasionally join weekly iteration planning meetings. My engineering leads drive these meetings. The goal of the meeting is to ensure projects are on track, engineers understand what they are working on next, and to identify any blockers that I or my leads can help with.
In the meeting leads typically use an internal tool that is like a lightweight version of Jira. Engineers are expected to break down their OKRs into one-week-or-smaller tasks. Engineers assign themselves a number of tasks each week that they expect to complete in that week. Leads ask engineers to explain their tasks for the next week and to identify anything that is blocking them from work.
The following reasons encourage me to attend these meetings:
I want to attend at least one per month to stay apprised of how engineering work is going
If I don't have a conflict I'll go (but I often do)
If I want to make a team announcement or strategic push on an OKR.
Standups
I require my teams to host a stand up meeting in addition to the iteration planning meeting. They are driven by my engineering leads and I typically do not attend. Standups are expected to be less than 15 minutes. Each engineer briefly describes: what they worked on since last meeting; what they plan to complete next; any blockers they face.
Quarterly Project Sync
I meet every week with my engineering leads to review the status of every quarterly project. I ask for a high level evaluation of whether or not each OKR is on track to complete before the end of the quarter. I track the history of these evaluations each week so that we can see trends over time and review later our ability to accurately track progress. I ask leads to explain what the next steps are for projects to encourage deep thinking about the status.
This is an opportunity for me to understand the progress my organization is making. This is an opportunity for me to learn about blockers or challenges faced by the team and escalate when needed. My project manager partner loves this meeting because it directly translates to regular updates they are responsible to share with the rest of the organization.
Engineering Monthly Review
I participate in the Engineering Monthly Review each month. This meeting is an opportunity for my VP to inspect the quality of each pillar in our product area and to push to get issues fixed. My teams produce a number of graphs and metrics that appear in the EMR, e.g., time it takes for a particular ETL pipeline to complete or the 95th percentile latency for each of our mission critical APIs.
This meeting is typically held during the eighth week of the quarter. Product area leads publish the EMR metrics during the sixth week of the quarter and ping folks (like me) when there are concerns. I review these concerns, try to triage the issue myself, and reach out to my engineers if I am unable to diagnose the issue. I partner with my engineers after diagnosis to determine what work can be done to fix/prevent the issue in the future.
Design Reviews
I attend all design reviews for my teams and also those from adjacent teams that may be relevant to us. They are presented in a shared forum for all teams that report to my director. My director often attends.
Most quarterly projects that take two or more months to complete will have a design doc. I am an implicit approver on all design docs in my org and I read and comment on every one. This gives me an opportunity to understand the work my teams are doing. This gives me an opportunity to influence the technical direction of the team. This gives me an opportunity to identify overlaps between teams so that I may suggest leveraging existing or shared architecture.
Design reviews have regularly scheduled slots that engineers may sign up to present at. Typically there is at least one design review for any of my teams in a given week.
Product managers and UX leads also present their designs at this meeting. I review all UXDs and PRDs for my area.
Director Staff Meeting
I attend my Director’s staff meeting each week. This is a meeting with all the L6+ SWEs who report to my director. This is an opportunity for my director to push down announcements to the leads in his org and share his vision and direction with us. It is an opportunity for us to flag any issues or topics. This gives me an opportunity to make sure my director has visibility into specific things. This is a chance for me to get a download of what information is important to my director.
Retrospective
Twice each year I like to host a retrospective for each of my three teams. This is an opportunity for me to get collective feedback from the team about what is going well and what needs improvement. It is also a nice opportunity for the team to vent any frustrations.
We use a collaborative surface, e.g., Miro for engineers to simultaneously post their feedback. I follow a simple template where we ask engineers:
What things have gone well since our last retrospective?
What things have gone poorly since our last retrospective?
What concrete things do we want to do to improve?
Engineers fill out virtual stickies with as many responses to each question as they want. We group similar answers into themes and open the floor to discuss. For the final item, we vote on which theme is most impactful to the team. We spend about 20 minutes on each question and a retro typically lasts 60 to 90 minutes.
It is my goal to prioritize the highest voted item into the next quarter’s OKR planning. I get these items prioritized close to 100% of the time. 50% of the time they complete successfully.
Product manager 1:1
I meet weekly with each (approximately four) of the product managers in my area. This is an opportunity for me to download information from their discussions with our business partners. This is an opportunity for me to influence the product vision of the team. This is an opportunity for me to get an update on particular OKRs from our product partner’s perspective.
Topics in these meetings vary wildly, but we often check in on the status of current OKRs, discuss requirements and feasibility of future projects, and wax philosophical about how the teams are performing and the impact our products have.
My All Team
Twice a year we hold an all team for all of the members (engineer, product, program, business partners, etc.) on my three teams.
This is an opportunity for us to highlight our major successes and upcoming impactful projects. This is an opportunity for individuals in my organization to gain context on what else is happening in the area. This is also an opportunity to socialize and for folks who normally do not meet to get to know each other better.
We typically present a slide deck that is built by many members across the team and those members take turns presenting their section. This gives members on the team an opportunity for visibility which they may not otherwise get.
The event is typically accompanied by a fun event like an escape room or lunch at the beach.
1:1 Skips
I meet bi-monthly with each of my skip-level reports. This is an opportunity for my reports and I to check in with each other on all sorts of topics. We typically discuss progress on projects, career growth, and challenges at work, but all sorts of topics arise. I especially find it useful to gain insight into how their day-to-day work is going since I am not chatting with them in person as often as my direct reports.
I keep a notes doc for each meeting that is shared only with my direct report. This gives a history of topics for posterity. This is a space where my report and I can post topic reminders ahead of our next 1:1.
Project Grades
Every quarter, I review projects with product and engineering leads and grade each one. This is an opportunity to verify which commitments we actually completed. This is an opportunity to review how well we planned work before the quarter started. This is an opportunity to ensure that projects that did not complete get reprioritized if they are still needed.
I request proposed scores from each engineering lead. I am pushing to also have an engineering artifact (launch doc, design doc, CLs) that I link to in the project tool for posterity. I ask the engineering lead to get an estimate of the actual work that I leave as a note in the project tool.
I prefer my product area’s project scoring guidance. In particular, I focus on whether the project was green or not. A project with a score >= 0.7 is considered green and we will not expect work for the project to continue into the next quarter. A score < 0.7 indicates that a project did not launch and/or there is necessary work in the future before the project can complete.
