I was 24 years old. A baby.
Three years into my software engineering career and loving it.
Then a freight train hit me.
Would I be interested?
Ok… I’m not going to lie. I was surprised. But it wasn’t the first time I thought about it.
CloudLock was my second job out of college. My first job was working for Nuance Communications. I got a taste of what it might be like to lead a team when my boss went on vacation for two weeks. He nominated me to be the engineering contact for tech support while he was out. In those two weeks, my network within the company expanded, I got on customer calls for the first time and I got to see what it was like being responsible for more than just my own code. It was pretty fun and I was good at it!
That experience was in my mind that day while Michael and I were talking. I wanted to say yes but I had a million questions.
I don’t remember his exact words, but he gist of what Michael said was “Don’t worry. You’re going to be great. I’ll help you and we’ll make it work together.”
Michael is a really good guy. I trusted and respected him. So that was all I needed to hear.
My first few months on the job
Looking back on it, in those first few months, I didn’t really understand the job.
I was going through the motions. Mimicking all of the things I had seen other dev team leads do.
Don’t get me wrong. I did some good. But I also had quite a few struggles.
For starters, every time there was a problem, I went into Superman mode. Single-handedly fixing it at the speed of light. After all, I was a great coder and had an expanding set of knowledge of the entire system. And I was good at helping other developers fix their problems. That is why I got promoted to team lead, right? (Kinda.)
Some of the team actually liked it at first. They acknowledged me for getting my hands dirty and being helpful and responsive.
But some of the team didn’t like it. It came across as controlling. And the ones who liked it initially stopped liking it because they were making the same mistakes over and over again and not getting better. Our weaker devs stayed weak and our stronger devs weren’t growing.
There were more mistakes. Like when I waited too long to fire a bad developer who’s negative behavior was hurting the team.
8 things they didn’t tell me
I believe being a leader is a never-ending journey. There’s always more to learn. Thankfully, I had great mentors who taught me a lot. And I also learned some lessons the hard way.
Here’s 10 things I wish I knew back then.
1. Many of your skills don’t translate.
The cruel irony is that there is a reverse connection between strong individual dev skills and dev team lead skills. The strongest devs will have more of an uphill battle starting out as managers.
75% of the issues we face as a dev team lead are not technical. The job is mostly about people and processes. Once I realized this, everything changed for me.
I could fix anything in the codebase. I was great at finding creative solutions to fix problems other devs were having. Not only are those skills not super relevant anymore, there are other traits of great devs that can actually hurt you as manager:
Superman complex. If the team has a technical problem (bug, technical blocker), great devs often have the instinct to jump in and fix it right that second. In fact, when I did that as a dev, I received praise from my peers and leaders for being a great team player. As a manager when you do that, you’re the opposite of a team player.
Instead, we need to enable our people to solve the problem. Even if it takes longer the first time. Even if they make mistakes. Even if they don’t do it as well we would.
By helping your team figure it out, instead of doing it for them, you’ll get many benefits. Your people will see that you trust them. They’ll learn more. They’ll become more self-sufficient over time. And they’ll also learn to help each other which will bring the team closer together.
Pro tip: Avoid judgment at all costs. When your people feel free to get out of their comfort zone and make mistakes without fear of criticism, you’ll see their true creativity come out and you’ll be amazed at what they’re capable of.
Deep focus. Another skill that did not serve me well as a manager was deep focus. As a dev, you have to get in the zone. I was good at locking in and focusing all of my energy on a single problem. That will kill you as a dev team lead.
Great leaders embrace context switching. They move around. They talk to a lot of people. If you find yourself locked in on a technical problem for hours, that’s probably a sign that you need to delegate more.
When you do have the luxury of deep focus time, use it to think about strategic initiatives. Like how to propose your next big non-functional investment to your executive team or the profile of your next three dev hires.
2. Keep your instincts. Change your behavior.
Great devs have great instincts. Your intuition, which comes from your experiences, your expansive knowledge of the system, and your understanding of the end-to-end process, allows you to feel things even before you can even put your finger on exactly what it is. You sense when you went down the wrong path in your code. You sense when your team’s iteration is behind schedule.
Continue to hone these instincts. Just don’t act on them the same way you used to.
You need your spidey sense even more now to figure out when others need help:
When you hear something in your daily stand-up that doesn’t sound right.When someone can’t find the root cause of a production issue.When you’re helping out on a code review.
But if we aren’t jumping in like Spiderman to save the day, then what?
(Superman? Spiderman? Make up your mind, Dude! I know. Actually, Deadpool is my favorite superhero. What’s the best Deadpool quote about engineering leadership you ask? “House blowing up builds character.”)
First, take a breath. I process things quickly but that can be a disadvantage as a manager. Keep listening and take extra time to process.
If you aren’t hearing enough info, ask questions. Gather as much information as possible before you offer any advice. Sometimes, just asking the right question helps your dev think about the issue in a new way and come up with a solution on their own.
Has (fill in the dev or team who is dependent on this work) reviewed this?What are you thinking for scalability testing?Tell me about your feature roll-out plan?
3. Communicate “why” more than “what” and “how”.
As developers, we’re used to dealing with what and how. As dev managers, those are still relevant but it’s more important for us to focus on why.
There’s four reasons for this:
Customer alignment: Product managers are hopefully delivering stories that clearly explain the customer problem and use case. But it’s still easy for devs to get in the weeds. If you constantly remind your team to come back to the problem and user experience, you’ll deliver a higher quality product more often.
Pro tip: Another question I Iike to ask when a dev is stuck: “Can you describe what your user is going to be doing before, during, and after using this feature?” If they can’t, they need more info.
Pro tip: Encourage your devs to listen to customer support calls and sales prospects calls. In my experience, lots of teams say they are going to do this then they don’t. At LinearB we have a rule (voted on by the team) that every dev attends two customer calls minimum every month.
Mission and motivation: Most people want to feel part of something bigger. Sharing the why with your team helps connect them to the rest of the company. Also, regardless of what your company does, you have customers that rely on your product. Real people. Sharing “why” helps developers buy-in to something bigger than just what you’re doing in a particular sprint which will make them happier and lead to stronger team culture.
Career path: The best bosses I had were setting me up for success for my next job. Whether your dev wants to continue down a technical path or move to a manager path, they’ll need to learn to see the big picture and be able to communicate “why” to others. I had mentors teaching me this and I try to pay it forward as much as possible.
4. Culture is a real thing. And you’re responsible for it.
Speaking of culture… it’s a real thing and you’re responsible for nurturing it.
Can I define culture? It’s easier to describe than to define. But that doesn’t mean it’s not there. So I guess culture is like gravity. It’s the invisible thing that stops us from floating away from each other.
Another thing I learned about culture… it flows from bottom-up and top-down. Your devs will know if you don’t believe it. They’ll see if you’re not living it. So it has to be authentic.
For me, when it comes to building culture, three ideas have served me well:
Be kind and empathetic toward everyone.Follow through on what you say you’re going to do.Stay humble and keep everything focused on the team.
5. Clear a path for your people.
One thing I struggled with as a manager… computers operate differently than people. Seriously. Bear with me for a second.
Code is deterministic. You tell it to do something. It does it. If the code does the wrong thing you just fix it and it does the right thing. As developers, this is how our brain is wired.
But that’s not how people work! You can’t tell them what to do. It doesn’t work. One day you’ll get one thing. The next day you might get something completely different.
With people, all you can do is set them up for success and trust them to do the right thing. And if you have great devs working for you, the best thing you can do is give them a clear path and get out of their way.
As a manager, I knew I was spending my time wisely if I was unblocking my team. There’s three types of blockers that will come up every week:
Dependencies: We’re used to dealing with this one too but now we’re in a better position to predict when issues will arise. We can use our visibility of what’s happening across our team and other teams to anticipate problems and start communication sooner rather than later.
Priorities: After a while in my role as lead, I figured out that the #1 reason my team missed an iteration was that either my devs did not truly understand what their #1 priority was or they knew what it was but they were still getting pulled into other things. This is a silent killer. Eventually, I focused a lot of my time throughout the week just making sure every dev was working on the biggest things that would help us ship our iteration on time.
6. Priority setting and estimation takes up 50% of your time
Speaking of priorities… as a dev, you do get asked for updates a lot. As a dev team lead, I found the requests for status updates increased by 10X.
The process of determining priorities and coming up with estimates for the business took up at least half of my time. I found it to be a fun puzzle and I enjoyed working on it.
7. Invest in your ecosystem.
When we get promoted our circle expands by 3-5X. We’re used to working with the devs on our team, our product owner and sometimes some devs on other teams.
All of a sudden we’re regularly interfacing with all of the other dev managers, many of their devs and all of the leadership from product, tech support, sales, and HR. Not to mention the senior leaders in our own department.
These relationships really matter. You can’t be successful in your new job without their help and you definitely won’t get promoted to the next level without their sponsorship. So invest in those people. Learn what’s important to them and go out of your way to make their life easier.
For example, with the sales team, ask them what would help their demos run better and work on something for them in your next hackathon.
8. Translate engineering to execs with data.
You can also get a 21 day free trial of LinearB. We automate the process of connecting and analyzing data from Git and Jira to give you dashboards you can use in your daily stand-up, your retro, and when you’re communicating with your boss. So you don’t have to constantly bug your devs for status updates. LinearB gives dev team leads data they need to translate activity to business value.
LinearB gives dev team leads data they need to translate activity to business value.
I loved being a dev team lead. The gratification was no longer instant like it can be when you’re directly building things. But it felt really good to help other people reach their potential. To watch them grow. And you’re in one of the most powerful positions in the company. The perfect place to tactically make things happen but also influence strategy.
I miss problem-solving with the team. The late nights working side by side to hit a deadline. The inside jokes. There is nothing quite like a small, close-knit team.
So enjoy it. It won’t last forever.