Tips for rearranging your responsibilities and managing your time to carry out new duties

Imagine you have been leading a team of a decent size for a while, and then over time, your team grows beyond the healthy size of a single team, or your team’s mission expands, and another team joins you. You are now responsible for the overall mission of several teams, working through other managers for the teams that don’t directly report to you.

This could be a nice transition through passage two of the leadership pipeline (to managing managers). You are still attached to the reality on the ground observing the impact of your work across multiple teams. However, it has a downside, and it has something to do with time.

You already had a full calendar, but now you have to stay on top of the new teams’ work and learn how to support their managers (including assessing their performance and helping them grow). You can figure out how to perform your new duties with a bit of learning and coaching and making a few mistakes on the way. However, the most immediate problem is finding time for everything you are responsible for.

How To Catch Up?

I went through this experience recently. While fresh in my mind, I’m documenting how I approached it and calling out things that helped me during this transition. To keep this short and on point, I will only focus on how I rearranged my responsibilities and managed my time to carry out my new duties.

• Let’s face it. I did not work from 9 to 5. I was completely out of my depth and had to learn the basics quickly. I spent a lot more hours learning, organising my work, and improving my routines. Most nights, I stared at my calendar and moved things around to create a focus time in between meetings the next day. Whenever I walked in the supermarket aisles or exercised in the gym, I listened to management books or podcasts. I won’t go through the list of books here because the internet is full of book recommendations, but I would like to call out one thing in particular:
  Manager Tools was my primary source of daily doses of knowledge on random (but timeless) topics. Their subscriber-only Executive Tools podcast was also very useful because it touches on some underlying concepts you can’t easily find anywhere else.
• I had to change how I tracked my work. After trying different ways to manage my tasks and using many to-do list applications over the years, I eventually adopted the six-box system that Peter Bergman recommends in his book“ 18 Minutes”:
  The idea is to identify the top five focus areas for the whole year and then track goals and tasks related to each in its own box. These five boxes should account for 95% of your time, and the sixth box is there to track the remaining 5%. For the first time, my whole to-do list fitted on a single page which was a major breakthrough. Most days, I can find five minutes in the morning to go through this list and identify a few important tasks to address before I get lost in meetings and messages.
• When it came to working with teams, I saved time on two different fronts:
  – For the team directly reporting to me, you wouldn’t be surprised if I told you I had to delegate a lot. I delegated the day-to-day operations of my team to a senior engineer looking to have more impact. In the next section, I will describe the arrangement in detail.
  – I defined my interactions with the other teams in my organisation. Without having to be involved in low-level details, I gathered high-level information by following weekly project status updates and watching important project documentation (like decision registries). Then I asked my managers to share the results of team retrospectives, health monitors, engagement surveys, etc. (some I could discover on my own). Having a high-level idea about where the teams are helped me have a more focused discussion with my managers about challenges and opportunities without micromanaging everything. It doesn’t mean everything gets done 100% right, but we all learn and calibrate along the way.

What To Delegate?

A little about our organisation first: Our department has close to two hundred engineers, divided into smaller units called pillars and consisting of a small number of teams (up to three). Each pillar has a clear mission, and each team contributes to this mission by operating a set of capabilities and executing on a roadmap of their own (often managed by a separate PM).

Each team has an engineering manager accountable for the delivery of projects and uptime of services, relying on the help of feature leads (explained here) for leading small units in each team executing projects. Feature leads work with the PM and other stakeholders to clarify the scope, propose a solution, maintain the project backlog, and manage individual sprints. The engineering manager is ultimately accountable for anything the team delivers by setting up the smaller units, coaching the feature leads, coordinating between the units, escalating issues, resolving inter-team dependencies, etc.

When I got to this point, my day-to-day activities were a mix of what I did for my direct team and ours. Before deciding what I should delegate, I had to know what I was doing for my direct team and then see which ones I could delegate. My responsibilities fall into four main categories listed below. For each, you can find high the relevant responsibilities and the desired outcome. I have excluded implementation details and step-by-step guides to keep it short.

1. Execution

• Make sure the team works efficiently: rituals are up-to-date and fit the team’s needs, the team can make progress, the team takes time to have fun (gathering on-site, social conversations) and review how they work together (retrospectives, health monitors)
• Track and communicate team’s work: roadmap is up-to-date and accessible, project tasks are organised in Jira, and regular updates are posted in Atlas for active projects
• Ensure projects are delivered on time: projects are properly estimated and adequately funded. Risks and dependencies are addressed in time
• Ensure uptime and reliability: security and reliability requirements are met, alerts are investigated, and incidents are resolved

This area is the easiest to delegate and should be the first one. The nature of work is very familiar to a senior engineer who has ever led a team.

2. Planning

• Make sure the team is working on the right things: team has a clear mission, and projects align with the department’s goals
• Create a long-term roadmap: big rocks are identified for the next 6–12 months
• Track team’s time investment and regularly report: time investment at a high level (in a framework similar to this) is measured, and sprint velocity is tracked
• Plan for each development cycle: team agrees on a goal and commits to a plan before each development cycle starts (similar to this). The plan is presented to the leadership team, a project allocation one-pager is updated (with who’s doing what, something like this but simpler)

This area can also be delegated to someone who can work closely with product managers and step back to think about the bigger picture. However, they need to properly understand execution first. Otherwise, planning will be very abstract and out of touch with reality.

3. People management

• Hire great people and help them succeed
• Communicate upwards and downwards the chain of authority
• Assess performance and ensure compensation is fair

You can’t delegate this to another person because this is the core of what you do. Perhaps you can use some help from senior engineers in your team for mentoring, but they are likely doing it already.

4. Administrivia

This section contains all the other random asks that didn’t fall into the three other categories. I borrowed the term from Tom DeMarco’s novel Deadline. I you have read the book, you will know what I mean. It includes being present in some meetings or addressing asks coming to you directly via multiple channels. Delegating work in this category requires more work, and the time invested in setting it up isn’t likely to pay off. It may also create unnecessary confusion for other people outside of the team.

Enter the Tech Lead

By delegating “execution” and “planning” (as described above) to one of the senior engineers in the team, I got him to operate very similarly to what is often referred to as a tech lead in other organisations. Without people management responsibilities, the tech lead is primarily focused on ensuring the team works on the right thing — and it does that right.

This is not a separate role in our company because it is embedded in an engineering manager’s role. However, acting as a tech lead is a good opportunity for a senior engineer to have more impact, as long as it doesn’t detract them from their primary responsibility. Combined with some mentoring, this can act as a little taster for the engineering management job without having to commit to it.

How To Stay Close?

The main concern with this approach is, if I’m spending less time every day with my team, how can I give them useful feedback, help them advance in their career,s and properly assess their performance every year? A few things help me do a reasonable job with my setup:

• Knowing my team: I have worked with this team for over two years. I was directly involved in ups and downs, and I have a decent idea about the strengths and challenges of each team member.
• Visibility: I have multiple ways of regularly keeping up to date with the team. Our feature leads post regular updates on projects in Atlas. The team has a weekly sync to discuss current issues, taking notes on a Confluence page. The team runs hybrid stand-ups, where they send an update via Questmate, then discuss the day’s plan in a Zoom call. The updates are sent to Slack to inform the team immediately but also get appended to a spreadsheet for future review. For cases where a team member doesn’t maintain a journal, one or two bullet points in each stand-up update are the second-best things.
• More feedback: This has always been available, but the importance of getting regular feedback is more where I am not involved in the details of the day-to-day work. I regularly contact senior/principal engineers and the tech lead to get feedback about my engineers and how the team works together. I am committed to a weekly 1:1 with all the engineers on the team. Additionally, I have regular discussions with the tech lead and the PM to review projects and team health. This gives me enough data points to spot areas requiring more attention.

Over time, I will have a better idea of how much of a concern it is and what I should change. Leave a comment if you have had a similar experience.

What worked for you? What did you learn the hard way?

Scaling as a Manager was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.