Your first tech management role

I've been lucky enough to get to support a bunch of people transitioning from a technical IC role into their first management role and it's become a bit of a specialty for me as well as a source of joy and pride. The transition from IC to people leader is tough because it's not just a step change in a career but a change in state, and this is rarely acknowledged and even more rarely fully supported in many companies I'm familiar with.

Most of my experience is in supporting data scientists taking this step, although I have some experience with software engineers as well as more traditional analysts from my pre-tech career. I took this step myself twice, in my pre-tech career and then again in my tech career. I believe the lessons are similar for any technical role.

Lesson One: It's a completely different job.

The skills that made you a good IC are only weakly correlated to the skills you need to succeed as a manager. Certainly there are some commonalities – communication, business understanding, a relentless focus on outcomes over process – but most of what got you here won't get you much further. Being a brilliant coder barely moves the needle now, and the sooner you can shift your focus to what you now need to be good at the smoother your transition will go.

It's unfortunate that many companies fail to adequately support new managers, and often don't even really acknowledge how different the role is from being an IC. In my experience, there aren't all that many great people managers out there so you may not have great role models.

This might make the transition into management sound intimidating, but that's not my goal. As long as you go in with open eyes and open heart, understanding that you're learning a totally new role, you're gonna be fine.

Lesson One Point Five: Player-coach roles are generally a trap.

Sometimes the desire for a player-coach role (a manager who spends some of their time on things an IC would normally do) indicates that a company doesn't understand how different management is from being an IC. Often, they fear that shifting someone into management means they're losing an IC. It could be that they don't see the value in good management, which might well be because nobody has really demonstrated it there. (Yet. Until you.)

Regardless of why a company wants a player-coach, this is going to hinder your learning because you won't have much time to learn on the job and you're going to get stuck doing IC things when you should be helping other people do those IC things, hopefully better and faster than you would.

I suppose it's possible that you find comfort in the familiar IC tasks and that helps ease you into the role – I haven't seen it work that way, but I don't doubt it's possible. I've seen it obstruct development over and over though.

When I started my first management role in tech, I was thrown into a team where I couldn't be an IC – I was managing software engineers working in a language I'd never used (and I've never been a software engineer). This removed any temptation I may have had to just do something myself and forced me to rely on my team to get stuff done. Kind of like learning a language through immersion, scary at first but I think I'm a much stronger manager because of it.

Lesson Two: There are no 10x engineers, but there are 10x leaders.

You need to start thinking about leverage differently. One of the hardest parts of the transition is learning to let go of most of the details, but not all of them. It's tempting to want to decide how everything gets done; this is natural because you were probably an excellent developer and these smart decisions were how you added value. If you don't let go of this mindset you will never unlock the true leverage of your new role.

Your job is no longer to make sure every technical decision is the best one. Instead, your job is to make sure your team has the information and resources they need to be more productive themselves, and to know when you do need to step in and course-correct based on the pattern recognition you've developed during your career as an IC. Learning when to lend your pattern recognition superpowers and when to stay out of it takes time, but you really don't want to become a bottleneck for decisions.

Let's say you were a phenomenal developer (I believe in you!). In addition to being very productive yourself, you probably made your teammates more productive through establishing standards, code reviews, mentoring, and other activities. Most of your levers improved your own productivity, and some improved others.

You now have access to way more (and way more powerful) levers for improving other people's productivity and you can reach more people with your new levers. Your old levers still exist, but your new levers have more impact. Where your impact used to be additive, it can now be multiplicative and eventually exponential.

The old levers are tempting because you know how they work and they got you here, but the new levers are so much more powerful. You just need to learn how to use them.

Lesson Three: Your team members are no longer your peer group, and it gets lonely sometimes.

This one can be especially tough if you're going to manage a team you used to be an IC on, but it can still be difficult if you're new to the team. I'll share an anecdote about a time before I fully internalized this.

My first management role after I transitioned into tech was with an existing team that I worked closely with as an IC but was not a part of. I genuinely liked working with them and they were exceptionally patient with me getting up to speed since I'd never done the kind of work they did. About six months after I joined the team, the company had a huge round of layoffs and I was told I could keep on four out of the ten team members (and that was after I fought to keep more). The date for the layoffs kept slipping and I managed to get in one more team outing beforehand, on the Friday before the layoffs on the following Monday.

I felt awful about trying to enjoy wings and Whirlyball with the team knowing most of them were about to have their careers upended. I genuinely liked each one of them and didn't want any of them to dislike me for a decision that was out of my control – although, to be fair, I did decide who to keep (different from "who are the best developers", which I'll get into another time) and I own that. And to be absolutely crystal clear, I am not saying my discomfort was as bad as what happened to the people whose careers were disrupted – certainly that day was far worse for them than for me, but it still hurt. I've interacted with most of them since then, and the reality is that some still resent my role in that layoff, as is their right. It makes my heart hurt, and I hate it, but I absolutely get it.

That's part of what your job is now, and if you can't handle being the bad guy in the stories of some people who you like, think hard about whether this is right for you. It should not happen often, but chances are it will happen. I've learned to have a bit of a wall up with my teams since then – I'm still 100% genuine, transparent, and honest (except when I am required to keep something confidential, which is rare), but I had to let go of wanting the people on my team to like me and be my friend. It can be a little lonely.

You do gain a new peer group, which can help offset this loss – they are the people at your level on other teams. Usually this will be the other managers reporting to your leader, but it can also include the managers and leaders of the other teams you work closely with. With the usual caveats about work friendships, it's much safer to make friends with this group if that's important to you (it is to me). Even if work friendships are not your thing, think of this group as the team that you are now a part of. The team you lead is the team you lead, and you're not a part of it in the same way anymore.

Lesson Four: Don't be the HIPPO in the china shop.

I credit Patrick Boueri for introducing me to the term, which stands for Highest Paid Person's Opinion. (This probably means it's properly stylized as HiPPO, but that feels a little too close to Spongebob case for my comfort.)

The opinions of people with the most authority – often, but not always, the highest paid person in the room – tend to be imbued with more weight than may be appropriate or intended. The subtle version of this is that your team might hear your opinion as a statement of fact, or an inarguable direction they must follow, whether you intend that or not. Even if you say that you're merely stating an opinion, the team may overindex on it without realizing it.

The worst way to be a HiPPO is when you can't keep up with all the technical details of a project (which will often be the case), but you insist on being caught up and then telling the team to make a bunch of changes. Even if you have tons more experience than your team, you're probably wrong because you're not in it the way they are. And even if you're right, your team is going to start resenting you.

This kind of management leads to feelings of lack of agency and resignation to having plans blown up at any time without warning. You might not realize you're doing it, and your team probably won't tell you if you are, but pay attention next time you're in this situation to what you say and how your team takes it. Understand that, despite your pattern recognition superpower, your team knows the details far better than you do. If you find yourself making a lot of very specific suggestions that your team never pushes back on, try to stop yourself next time and see what happens.

The more subtle HiPPO problem can come from just stating your opinion early in a discussion rather than letting your team members all speak up. Even if you think you're not overly influencing them, you probably are. Try waiting for everyone else to state their opinion and discuss, and only offering your opinion in if absolutely necessary. Not only will your team feel more empowered, but I bet you end up with better outcomes as well.

Lesson Five: If you want to be a manager because it's the only way to advance your career, consider finding a smarter company.

Most smart tech companies have figured out that it's valuable to give an IC a career progression that doesn't require taking on people management responsibilities. Very senior ICs can have company- and industry-wide impact without ever managing.

However, a lot of industries haven't caught up and are stuck in the old-school mentality that you have to take on management responsibilities to advance in your career. If you don't want to manage people but don't have a path to move up without doing so, you should strongly consider moving to a company that supports career tracks for ICs – this problem was solved decades ago and any company that hasn't caught on by now is likely stuck in other inefficient ways of operating.

Lesson Six: Managing is about giving up control, not amassing it – mostly.

First, if the reason you want to manage is because you're sick of being told what to do and want to tell other people what to do, please don't. Seriously. All you'll do is make work miserable for the people who work for you and you probably still won't be happy. Part of your job is now to give your team credit for your wins, but take the blame yourself when the team fails. People with a high need for control tend not to be good at that.

The Pareto Principle hypothesizes that roughly 80% of outcomes come from 20% of causes. The flip side of this is that the remaining 80% of causes don't matter much (or at all). This is related to the leverage discussion in Lesson Two above. Your time is limited, so spend it identifying which decisions matter and making sure the team gets them right (which doesn't always mean you make the decision for them, as in Lesson Four).

It's fairly clear why good things happen when you get the high-leverage decisions right, but good things also happen when you let your team handle the remaining 80%, even if they sometimes get them wrong. Giving your team a chance to try things, especially when mistakes have fewer negative consequences, will do wonders for their development and their feelings of empowerment. This will also make the times when you do need to step in easier, because your team will understand that you still trust them.

Those 80% of decisions that don't ultimately matter to the company are still important because you can use them to create other powerfully positive outcomes for your team.

Lesson Seven: There are a lot of different ways to succeed.

All models are wrong. Some models are useful. (The brilliant statistician George Box was talking about statistical models, but I find this applies just as well to conceptual models.)

Any prescriptive advice you hear about managing is likely wrong, but the heuristics behind them might have value. Manager roles have wide variance in actual responsibilities, and could include product or project management, technical leadership, individual contributions (yikes), or other tasks aside from managing people. Even within people management there can be different responsibilities for hiring, career development, and task assignments. On top of that, YOU are different from whoever is giving you advice (yes, including me).

Your true job is to improve the output of your assigned team within the context of your company and role. Copying someone else's approach from a different context will at best lead to getting stuck in a local maximum. Lean into your strengths, find ways (or people) to mitigate your weaknesses, and don't lose focus the true goal. I can't tell you exactly how you'll get there, but if you work at it and reflect on your progress along the way, I know you're going to be effective.

In addition to describing the various symptoms of my idiocy (I am always open!), I'd also love to hear about the lessons you've learned on your journey, the things you're concerned about as you embark on it, and any stories you want to share. Maybe your comment will trigger someone else's revelation (or mine)!