The Line Manager Multiverse
When I stepped into the world of management 9 years ago, I had no notion of the range of skills needed, and possibilities that lay ahead. I was a software engineer who had been promoted to a line manager (M1) role, and I was excited to learn and grow. I expected to be responsible for the career growth of my direct reports, setting direction, connecting the work of the team to the goals of the organization and the outcomes delivered.
As a software engineer, the range of skills I needed to be successful was clear. I needed to be able to identify the right problems, solve those problems (by writing or evolving code), understand the systems I was working on, and collaborate effectively with my team.
As a line manager, the range of skills I needed to be successful felt larger. Suddenly, there were many more dimensions and degrees of freedom.
In addition to the skills I needed as an engineer, I felt compelled to level up on:
- Building my coaching and mentoring skills
- Learning how to manage projects and dependencies of various shapes and sizes
- Understanding the business and domain context at a deeper level, and how my team’s work fit into it
- Learning how to navigate a wide range of interpersonal dynamics and conflicts
- Understanding how to set and communicate a vision, mission and strategy for the team
- Process management and developing a systems view of the team and the organization
Over time, I realized that the degree to which these skills are needed and the balance between them varies widely depending on:
- The size and structure of the organization, and the stage of growth the company is in
- The maturity of the team i.e. how long they’ve been working together, and the level of trust between team members
- The experience and skills of the team members
- The type of team i.e. a stream-aligned team, a platform team, an enabling team etc.
- The context of the work i.e. the domain, the technology stack, the competitive landscape etc.
The degree of variation is an unseen, underappreciated and often underestimated aspect of the M1 role. Case(s) in point:
Situation 1 - The 4 person product team at an early-stage startup
You’ve hired four software engineers in quick succession. You’re developing a product that hasn’t found a footing in the market (yet). Hopefully, you are:
- Helping the team use different techniques like rapid prototyping, spikes, paper prototypes etc.
- Working with the team to establish a vision, mission and charter.
- Helping the team understand the problem space and the customer segments i.e. you are connected to the business context.
- More hands-on with the work, writing code, establishing best practices, and helping the team learn and grow.
TL;DR - You likely need to be hands-on, agile, and adaptable. You’re a player-coach, moving rapidly and iteratively (to learn) rather than thoughtfully and deliberately.
Situation 2 - The 10 person team in an engineering R&D division
You’re managing a team of 10 engineers who are working on a product that is mature, but in a competitive space. You need to innovate to stay ahead of the competition. You’ve been in the role for a while, and so have many of the team members. You are:
- Focused on the long-term vision and strategy for the team, and how it aligns with the goals of the organization.
- Managing multiple initiatives, and helping the team prioritize and sequence work.
- Focused on the career growth of the team members, and helping them develop the skills they need to be successful in their roles, while managing performance issues.
- Still technical (some involvement in code reviews, architecture discussions, offering opinions), but unlikely to be hands-on (certainly not anywhere near the critical path) while helping the team solve complex problems.
- You’re minimizing the operational load on the team, and helping them focus on the work that matters.
Tl;DR - You’re likely to be always keeping an eye on the horizon, setting medium-to-long term direction. You’re comfortable managing processes and change, and are focused on finding opportunities for collaboration and innovation.
Situation 3 - The 6 person platform team in a highly regulated industry
You’re managing a team of 6 engineers who are working on a platform that is used by multiple teams in the organization. The platform is critical to the success of the organization, and is operating in an environment that is highly regulated (e.g. banks, health care etc). You are:
- Capable of establishing processes and practices that help the team deliver high-quality software while complying with regulations.
- Managing dependencies and relationships with other teams and stakeholders in the organization.
- Focused on the long-term health of the platform, and how it can be used to enable other teams to deliver value.
- Adept at balancing operational load and feature delivery, and understand how to communicate platform health, costs and benefits to stakeholders.
TL;DR - You’re focused on operational excellence, and the long-term health of the platform. You’re adept at managing dependencies and relationships with other teams and stakeholders.
So What?
None of the situations above even went into the specifics of the technical skills (e.g. front-end, back-end, data engineering, machine learning etc.) that the team might need, and the M1 needs to be familiar with.
Combine that with the differing levels of risk appetite, project management, iteraction patterns, and long-term planning skills, and you have one of the most challenging roles in the tech industry.
M1s are expected to be a lot of different things, by a lot of different people, in a lot of different contexts.
- If you’re moving into a line manager role, take some time to understand the range of skills you might need to be successful in your local context. Books and blogs are a good starting points and will give you some principles to work with, but the specifics will depend (more than you expect) on the context you’re moving into.
- If you’re already a line manager, take some time to reflect on the skills you’ve developed and the skills you might need to develop further.
- Moving to another organization? You must be intentional about the questions you ask during the interview process to understand the context you’re moving into. Maybe you want it to be very similar to your current context to leverage your existing skills, or maybe you want it to be very different to stretch and grow in new ways.
I’m Siddhartha (Sid) Shankar, and I am currently a Senior Engineering Manager at GitHub serving the CodeQL dynamic languages team, supporting JavaScript/TypeScript, Python and Ruby. I have had the privilege of leading and managing engineering teams since 2015. I’m at my best when engaging in opportunities that require bringing people together - often across teams - to deliver value to customers in a sustainable and pragmatic way. More about the author →
This page is open source. Please help improve it.
Edit