Congratulations – you’re a new manager! No, really, I’m being sincere. You can hear the sarcasm in my voice? Sorry, I tried, but I know that along with some excitement, there’s plenty of doubt and angst. You have likely followed a path that’s similar to mine and many others. You‘ve been a software engineer (or insert role here) for many years. You became the “go-to” person, earned a senior title, and were known as an informal leader by those outside and within your team. Probably played the “tech lead” leading up to this point. You may have even been fighting this “promotion” for some time, didn’t want to get out of the code, lose your skills. But really, you were afraid that you wouldn’t be as good in the new role. Finally, somehow you were convinced to take the chance, and now here you are. From senior engineer to junior manager.
How do you succeed in this new role? How do you once again rise up through these new ranks and achieve the same level of results and credibility that everyone is expecting, especially yourself? There are decades of books and thousands of blogs dedicated to trying to answer these questions, so I‘m not here to pretend that I’ve got the secret to success. But I do know a few ways that I’m pretty sure can guarantee you’ll fail.
1. Keep coding.
That should get the comments flying. Your company may expect managers to do some coding, to be a manager and individual contributor. In my experience, and seemingly that of many others, that usually fails. You aren’t able to consistently give the attention that either role requires, so you fail at both. If you’re lucky, you work for a company like I do, where I practically signed an oath saying I wouldn’t code.
Ok, so even if some coding is expected of you, it certainly is no longer your primary purpose in the company. What I’m really talking about is when you fall back into coding because you are not sure what the heck to do in your new role. So you return to what you know, where you’re comfortable. That might provide short-term benefit to some projects and make you feel good, but I guarantee that you are not achieving your primary objectives. You’re hurting the long-term output of your team, and you’re also not growing in your new job.
I don’t think any of us want to simply give up on all that valuable and hard earned technical experience. This article provides some good options for managers that want to hold onto those coding chops.
2. Focusing only on the work, not the people.
As a manager you have two important duties: to grow the team and to deliver value to the business, and I’d argue that you should prioritize them in that order. The former amplifies the latter.
Our typical picture of delivering value is completing projects, shipping features, fixing bugs, etc. And if you’ve managed to escape not falling back into being the “lead engineer” and coding all day, then you are still probably trying to satisfy that need to complete tasks each day to get that feeling of utility. This often leads to one acting as a project manager or task master, focusing on assigning tickets, tracking metrics, asking for status updates, leading design discussions, story authoring and so on. In short, you’re focused on the work of the team. You can check things off the list each day and feel like you’re getting things done.
And you are. But just half of your job. The easiest half. Because the other half is hard, the most unlike what you’ve been doing your whole career and probably where you lack the most skill. That other half is growing your team. Helping individuals in their career not only technically but as productive people. Finding ways to make your team work better together. Having one on ones, listening, coaching. Turns out the “soft” stuff is the hard stuff. And if you ignore this part of your job you’re leaving a lot of value on the factory floor. You may deliver results, but they will be far short of the team’s potential. You may optimize some efficiency, but you’ll always lack true progress in the effectiveness of the team. You won’t ever meaningfully raise the bar, and you won’t know why.
The effectiveness of the team, and the ultimate value they produce, starts with the team members themselves not their work.
3. Measuring your value by your output
Back in your days as an individual contributor, as a builder, it was easy to quantify your output, your value. “I finished 2 stories today”, “I figured out that crazy bug”, “I’ve got all the tests passing”. These were tangible units of work, easily tied to the team’s deliverables. And those commits have your name on them. Its easy to see the work that is attributable to you and measure your value by how that output helps the team progress towards their goals.
But now much of your impact is seen in 2nd order effects. Its harder to draw the correlation of your work to that of the team’s. Adding to this confusion is the fact that your work is no longer neatly defined by well prescribed tasks. You might not even be really sure what “work” you do.
And so, as a new manager, you tend to grasp the few concrete tasks you have and use those to get a feeling of accomplishment, of adding value, and likely over-inflating the actual worth of that work. Powerpoint decks, budgets, status reports, scrum artifacts; these might be the output of work you do, but it’s not the job. In truth, your work is reflected in the work of the team. Having them accomplish their goals is your goal. Your value is ultimately measured by their success. Focus on the team and whatever is needed to help them succeed.
4. Expecting without expressing.
Do you have clear expectations in your head about what you need from your team? From each individual? Have you actually told them?
Its quite natural for us to think the mind of another will work similar to ours. That we share the same discipline, motivations and reasoning. And this leads to many assumptions. If you and I are both looking at the same set of work with the same information, then naturally, we should come to similar conclusions about how and when that work gets done. Uh-huh. So we hand out assignments with some amount of information but with unstated and assumed expectations. And you know what they say happens when you assume.
When tasks are assigned or work is delegated, make sure it includes the assumptions and expectations.
“Hey remember this is just a spike, I expect you to document your findings and then review them with the team before you move forward with any real coding.”
“This story is blocking QA, so it’s your top priority. I assume you’ll want to time-box yourself 30 minutes to get your current work paused. If this story can’t be done by the end of the day, communicate with the stakeholders asap.”
What’s much harder are your subconscious expectations, those you don’t realize that you have until they aren’t met. They’re your personal model for decision-making, the way you would have done it. You just assume that’s how its going to happen. But of course you didn’t communicate any of this, and when the result doesn’t fit into that mold you’ll be disappointed in others. This can be very demotivating and demoralizing to the team. If you have expectations about their work you’d better let them know. You can’t leave them guessing. And if you are unsure what your expectations are, then spend the time to go deep with yourself and figure it out. It’s your job, your responsibility to the team, and likely the expectation of your boss.
5. Leaving the team out of commitments
You’re a new manager, and you want to impress the boss. “Sure we can do that”, yes yes yes yes. Writing checks your team can’t cash. I’m pretty sure most of us have been on the other side of this. You are given deadlines that are impossible, expected to hit deliverables that you never agreed to. What did you think of your boss? Sure, maybe the team rallied a few times and hit their targets, but I bet that wasn’t enough. Your boss is looking great now and just keeps making those big promises. Pretty soon, the team’s had enough and people start to check out, move to other teams, or leave the company altogether.
You know what they say, shit rolls downhill, but to the best of your ability that needs to stop with you. You need to protect the team. So how do you do this? To start, don’t be the hero. Don’t immediately answer yes to every request from your boss, customers or business partners. Buy a bit of time and get your team involved in making the commitment. As much as possible, you want to lay out the bigger picture for the team and let them connect. Why is this important to the company? How are the customers being impacted? What are we actually being asked to solve? And most important, engage the team in the solution: “given what we know, what do you think we can do?”
There are going to be times when you have no choice but to receive and deliver marching orders, but when the team is involved in the commitment and has skin in the game, everything gets better.
6. Mistaking directing for leading
Standing on a chair and barking orders is not leadership. There are many times when its appropriate for the manager to be in the weeds and coordinate or direct the team through a set of work. But don’t mistake that with being a leader. Too much direction is often a symptom of what we like to call micro-management, and that leads to teams who are unable to work autonomously, requiring all decisions to go through you. And you will end up as the bottleneck for your team. You’ll have created a group that is inefficient and probably checked out, just going through the motions, waiting around for the next task and mindlessly executing.
Leadership inspires, it doesn’t dictate. A leader paints the picture of destination, setting a direction rather than giving directions. Instills a shared sense of purpose and meaning. Provides enough context via the mission, strategy and objectives to enable individuals to make the good decisions.
7. Avoiding hard conversations
If you’ve managed to avoid most of these failures, have I got a personal challenge for you. This is what separates team leads from people managers, learners from leaders, the noobs from the pros.
As an engineer, you likely had a few heated conversations with others about a project, the design, technology choices, coding techniques and such. But dealing with the people themselves, personal conflicts and complaints? Well, that usually got handled by the boss, if it was ever addressed at all. Guess what? You’re the boss now, and it’s coming your way. Sometimes it’s one of your employees bringing you into an issue, or someone outside the team that wants some incident addressed. But most often, it will be actions and behavior that you see yourself. They do not meet your values or those of the team, and you really need to deal with it. Your chest and stomach tighten up, and your mind starts coming up with all kinds of rationalizations and reasons to avoid it. But this moment right here is where you test your meddle, where you earn your paycheck. Its what separates the haves from the hacks. This is the best opportunity you have to make a difference in your organization. It’s these moments that can grow people and move them forward (including yourself). Dealing with these situations positively is the secret to building a highly effective team.
So how do you stop avoiding hard conversations and instead meet these challenges head on? Have hard conversations. Like so many other skills, the only way to learn how to do this is to do it, for real. You’re pretty much coding in production here. But there are ways to be more prepared and certainly tactics for improving your chances of a good outcome. The internet is filled with good advice here, so seek it out and pick a technique or two to try. You may want to start with the book Crucial Conversations.
Here’s some basics I’d suggest:
- Try to address the issue as soon as possible. The longer it lingers, the harder the conversation.
- Be specific and have examples. Another good reason to address an issue quickly, while the information is fresh in your mind.
- Be prepared. Think about how you want to start the conversation, and most importantly, what you want to get from this conversation. What’s your main message and what is the desired outcome? Think ahead to possible reactions, questions and comebacks the individual may have and think about how you will respond.
- The conversation should be focused on a person’s behavior or actions, not the person themselves. Instead of “you’re disrespectful” try “when you do X it’s disrespectful”. It’s also a good idea to focus on the impact of their actions. The effect on others or negative and non-obvious consequences they are bringing on themselves.
- Pick an appropriate time and location. Grabbing someone in the hallway might be fine for some quick feedback, especially for reinforcing a previous discussion. But if you need to have a long hard talk with someone, make sure you have a private spot and that you also both have plenty of time. The worst thing you can do is try to squeeze an important conversation into some small time-slot and then have to cut it short, leaving it hanging unresolved.
- Of course the best plan is to not need them. Avoid these difficult confrontations by addressing issues when they are small. Having regular and effective 1-on-1’s with your team members is a perfect opportunity to discuss problems while they are still small or before they exist at all.
The first time I had to have one of these conversations was scary, and I agonized for days. But it turned out much better than the apocalyptic episode my imagination had conjured. It really made an impact and made future dialog much easier. So face your fear, it’s not as bad as you think and the results are worth it. Your team deserves it and your future-self will thank you.
8. Stop learning your craft
Remember those years spent learning the latest technologies, tools, languages, frameworks in pursuit of becoming a great engineer? That doesn’t end when you become a manager. Management is a skill, an art, a practice. It is an ability you acquire over time and requires the same effort and dedication to learning that you devoted to engineering.
I’ve found I can use many of the same successful methods to learn about management that were already part of my engineering self-learning. Blogs, books, conferences and social media. For every blog post about container orchestration with Kubernetes, there’s one about scaling your teams using Lean methodologies. For every book about learning Golang, there’s a book laying out strategies for better 1 on 1s. And for every conference talk on monitoring your microservices, there’s one on best practices for understanding your team using data and metrics.
Ok, I decided that was too much hyperbole. In reality the ratio is more like 100:1 tech to management resources.
There are bad managers, and there are great managers. Novice and expert. Like engineering, it’s part natural inclination but mostly it’s the desire and constant pursuit of learning and improving your skills that makes the difference.
