Ask the CTO: A peer manager is trying to take my engineers
Build up your “first team” relationships to avoid conflict.
Keep out sign (source: JakeWilliamHeckey via Pixabay)
The problem
I am managing a team of 20 engineers in a mid-sized company. I report to the head of a business unit. There is no CTO. Instead, there are heads of business units and engineering managers running teams similar to mine. I’ve wanted to hire an engineering manager to shift some of the responsibilities off my plate, but that request was denied and no one else is quite suited to manage a small team. As the only manager, I’m so busy with meetings that I often don’t even have time to check my email during the day, and only get to it after I head home for the evening. I have a product partner who is the lead for my area and also reports to my manager; he manages one designer.
I discovered that my product partner has been lobbying the head of the business unit to hire some engineers directly into his team. This is frustrating me for a few reasons: 1) I feel that engineers should report to engineering managers not product managers and 2) I feel betrayed that he is going to my boss and asking for part of my headcount without talking to me. So far, my boss has not agreed to give him a team of engineers, but I worry that this is just a matter of time. What do I do? Am I not playing politics right? How do I manage this relationship with my peer so that he stops trying to undermine me?
Learn faster. Dig deeper. See farther.
The solution: Think of the larger organization first
There is something called the “first team” concept. I’ve seen it expressed in a few different ways, but the idea is that when you are a manager of people, your first team is not actually the people who report to you, but your peers across the organization. The idea of the first team is there to remind you that you have to think of the larger organization when you make decisions, instead of focusing narrowly on what is best for your team. The implications of first team thinking are very broad. You never undermine your peers to your reporting team. You keep your closest confidences not with people who report to you but with the other leaders in your area. When it comes time to determine budgets, projects, hiring, promotions, and even firing, you look first to the overall ecosystem of the teams, and what will be best in that ecosystem.
This also has implications on how you spend your time. Yes, you need to spend time with your direct reports, because you are responsible for their success. But you must make time to spend with your peers, so that you can collaborate on ways to make your overall organization more successful. Have you ever worked with a peer whose inability to manage their team meant that they slowed you down? It is a very frustrating experience. It sounds to me like you are so overwhelmed with your team that you aren’t making enough time to spend with your product peer. He might be playing politics, but it seems likely to me that he is pushing for some of your headcount because you have turned into a bottleneck for the overall organization.
Practical advice: Build structure to shift the management workload
You sound completely under water. Being in meetings all day every day with no breaks, not even time for email, is usually a sign that you are trying to take on too much. Twenty direct reports is too many for anyone to manage well, especially if they have other responsibilities beyond people management. You have to get some level of structure within your organization to take off some of the management load from your shoulders.
Even if you can’t promote anyone on your team today to manage people, you can (and should) push some more project management responsibility onto them. If your team can naturally break down into a few smaller project teams, I would look to the tech leads of those teams as a source for delegation. Even if they don’t take on people management, I bet that many of those planning meetings that you are currently stuck running could be delegated to someone on the team to lead. Go through your day with a fine-toothed comb and figure out which meetings you can shorten, delegate, or skip entirely. Be brutal. You need to reclaim at least a couple of workday hours for yourself every day. Preferably, you figure out a way to give yourself a couple of free blocks of time a week, perhaps pushing meetings to three days and leaving afternoons free a couple of other days. All of this free time now should be spent in creating a plan to bring to your boss for moving forward.
The first priority after reclaiming your schedule is making time to sit down with your product manager peer and get it all out of him. What is his goal with building his own engineering team? What does he feel that he cannot do with the team now that he could do if he managed engineers directly? Where in his mind are the bottlenecks? Why does he feel that this is a good idea? What could you do to make his job easier without him managing his own engineering team? The goal here is to make it clear that the two of you together are each other’s “first team.” He should be a partner in advocating to your boss for what your team needs so that the product can be built successfully.
In this case, if you can’t promote managers from within, you need to advocate for hiring another person who can take on management responsibilities. I think you’re right that a product manager trying to manage an engineering team is a bad idea, especially if that team does not have anyone on it who is capable of acting as an engineering manager. It is one thing for a business head to manage senior leaders in engineering, but having non-engineers trying to manage junior to mid-level engineering teams is not a great idea.
The “first team” alliances with our peers across the organization are so important because they make advocating for the needs of the overall organization easier. Advocating for hiring an engineering manager can be hard when your boss thinks that management is nothing but overhead. However, when your peer in the product organization supports you in the matter by telling your boss that decisions are being made too slowly and that there’s not enough leadership on the engineering team to move quickly, your boss may start to see that there is a real issue to solve. In exchange, you may be called upon to support your product peer when he advocates for hiring product people onto his team, because one product manager may not be enough for a highly effective team of over 20 engineers.
As a leader, our success depends not just on the outcomes of our team, but the outcomes of our overall organization. Getting out of the engineering-first mindset and into a mindset where our peer group has expanded to include other departments is important to give us perspective on the organization and to help see problems with our team in the wider context of the overall company. Don’t think of it as playing politics, think of it as seeing the overall system and trying to do what is best for the team. I think you’ll find that your role is a lot less lonely when you engage your peers.