Summer's coming and a lot of team members are about to go on holiday. How do you plan projects around everyone's leave, while simultaneously creating growth opportunities for your reports?
Every company has different planning rhythms that managers must adhere to. These processes (like quarterly OKR planning) are essential for any organization to operate with transparency and alignment. But what comes next is the point when a manager translates those goals into opportunities for their team members to grow.
In three practical, easy-to-follow steps, here’s how I approach the planning of work in an integrated process that aligns business goals with personal growth opportunities for my teams.
1. Assess team availability
My first step is to determine the length of time I want to plan for, and then identify who is available during that period.
While quarters are a consistent and useful measure of time for finance teams, others usually measure using predictable markers in the passage of time – often seasons, like summer or winter. When it’s possible, I like to bring those seasons into my team planning. For instance, I’ve just wrapped up summer planning for task and project allocation within my teams. “Summer” is a little of Q2 and most of Q3. While I will continue to report to seniors and peers in quarters, my team works in a way that aligns with their real lives.
Clarifying team availability for your chosen timeframe is the next important thing. You might have a tool for this or you can simply have people note when they’re taking time off in a table (Fig.1.). I color-code to highlight which weeks our team will have low availability for work – this informs how I plan project delivery milestones. Other patterns I look for:
- Employees with little planned time off whom I want to proactively encourage to take more breaks.
- Any upcoming extended leave to pre-plan for.
- Team members with a lot of intermittent time off as this may affect their ability to lead projects.
Fig.1. Noting team members’ time off
2. Define and scope projects
A project is a track of work that achieves a specific goal and has a clear beginning and end. While goals are determined by the business, an engineering manager defines the projects required to accomplish those goals.
Projects can vary widely. For a single junior engineer, a project might be onboarding to a new system and writing a function that achieves a specific outcome. For a group of diversely-leveled engineers, it might involve solving an unscoped problem, architecting and getting buy-in on a solution to the problem, and then building that solution. That same project could also easily be broken into two separate and distinct projects: one to architect and get buy-in and one to build.
My favorite shape of project is one that’s big enough to be worked on by a squad of at least three diversely leveled engineers for around three months. It’s enough time to build deep rapport with teammates, to fall into predictable weekly rhythms, and to really practice different skill sets. And with three or more people, everyone can take on a clear role. Assigning specific roles will facilitate team growth in the final phase of planning.
Fig.2. Holiday planner denoting periods of high holiday rate
The above table is a useful tool to reference when rough-cutting my projects. The highlighted red box above shows that I have a period of about three weeks in late June/early July with light availability across the team – it would be a difficult time to plan for a meaningful launch. This indicates that I should arrange my projects in a way that can be completed before mid-June (requiring more people to complete work in a shorter timeline) or that can wait until at least mid-July to launch (requiring fewer people on a longer timeline). Accounting for individual leaves, like Isadora’s in the purple box, ensures that her knowledge transfer and offboarding is considered.
During this project cutting phase, I try to think in terms of availability, level, and domains of expertise – not about specific individuals. This helps us as managers avoid accidentally pigeonholing people by repeatedly using their skills and strengths in the same way. By planning with different team combinations (for example, two junior engineers, three senior engineers, and one staff engineer), I gain a fresh perspective on their roles and potential.
3. Layer in team growth with roles and responsibilities
“Growth” means different things at different times; it can mean learning new skills, practicing developing ones, or honing existing expertise. I use the concept of roles within my projects to define growth opportunities for my employees.
There are certain things that make an engineering project successful – things like high-quality technical decision-making, ticket writing and organization, communication, documentation, observability, and more. Assign these responsibilities across the team and give each member a very specific role with very specific responsibilities within the project.
As a team manager, you can use your creativity to craft the different roles within each project. For example, explicit project leads can be responsible for many of the project needs listed above. This role is ideal for someone looking to expand their impact (great for those seeking promotion) or those interested in becoming engineering managers. A role such as “communication champion” might help a team member looking to improve their communication skills by having them summarize weekly project statuses. The role of “documentation delegate” might be assigned to a team member responsible for ensuring that the system they’re working on is diagrammed and well-documented. This is a helpful exercise for junior team members as, though they need to rely on their teammates to get the information, the act of documenting helps to solidify their own understanding.
I invite employees into different roles in 1:1 conversations, where I lay out exactly what the role is, what success would look like, and how I believe the role will help them reach their personal goals. It’s critical to create clear agreements during this conversation to ensure that everyone is set up for success.
Principles to keep in mind as a manager
My first responsibility is to the business
This means meeting company objectives is my first priority and developing my team is my (very important) second priority. A mistake I made early in my career was to approach every problem with a “people over everything” mindset – this sometimes blinded me to very real business needs and priorities that required my strategic attention and response.
Thinking about our people is so critical. And one of the ways we do that as leaders is by protecting the business. The business must exist in order for the people to exist within it! Those projects most critical to the success of the business, where there is little room for mistakes, are therefore assigned to those with the most appropriate skill level and availability. In Fig.2. the green box underscores that Jasper has pretty consistent time off planned for the summer. This likely means that, even if he is an experienced and high-performing leader within our team who would be well-served to practice his project leadership in a new context, he’s probably not a great fit to lead an important, long-running summer project.
Growth happens in different ways and they are all important
There are many ways for people to develop professionally, and not all of them include positions of explicit leadership (such as leading a project or being a mentor). Folks can practice influencing when not in a position of explicit power and take opportunities to learn from others by becoming a mentee or following someone else’s lead. I intentionally vary the opportunities I give team members from season to season and look for different projects where they can lead, influence, and learn.
Everyone gets growth opportunities, but everyone doesn’t get a growth opportunity at the same time
It’s not practical for every single person to have a perfectly packaged growth opportunity at all times. Part of being on a team is also participating in things like support work and repetitive migration work. Often there is still a growth role to be found within these less glamorous projects: things like practicing communication skills while monitoring a team channel, learning more about the systems the team owns through on-call support, or practicing consistency in delivery while migrating artifacts. But sometimes the work is just work and it’s okay to be explicit about that. I’ve found that team members are delighted to participate in support work to help enable their teammate’s growth if they know that it’s their turn for a growth opportunity next.
Growth isn’t a secret
Creating a culture of growth means shining a light on the ways we are each learning and practicing new skills. I invite team members into specific project roles in 1:1 conversations, but ultimately everyone’s roles and responsibilities are documented and shared across the team each season. That way we can all support each other’s growth, recognize and celebrate incremental achievements, and gain knowledge by observing one another’s growth trajectories.
Final thoughts
Building your team’s culture and growing your team members’ careers happens through the work itself. By incorporating cultural and personal growth opportunities into project planning, which is a necessary task, we guarantee that these moments occur consistently and are not overlooked or disregarded.