Skip and go to main content

From our Depsters June 26, 2019

What does it mean to be a Technical Lead at Rocket Insights (part of Dept)?


So you were just promoted at Rocket Insights (part of Dept) and aren’t sure what to do? Let’s talk about it.

How did you get here?

You woke up and… surprise! You’ve been promoted to the role of Technical Lead, congrats! Before panic sets in, you need to know: you were chosen for a reason. You are most likely a hard worker, reliable, transparent, and in need of a little guidance. Maybe you don’t realize these things, but you were a leader long before you knew it. Your boss trusts you and feels like you will let them know when you need help or guidance which explains the fact that you are only meeting once a week.

Chances are you report to someone that oversees a bunch of teams and they need to scale, so they need someone they can trust, to be their eyes and ears. This is where you come in. Your manager only has so much time in a day and they don’t want to stay awake until one in the morning doing work related tasks. So, this is why you were chosen to help your supervisor given your expertise.

What a “Lead” is not

A Lead is a description, not a role, but it’s your title now. It’s a bit confusing, but you are still a senior or principal engineer, that hasn’t changed. Simply put: you are an engineer, with some additional responsibilities. No worries, you still get to code. But keep in mind, the code doesn’t belong to you, you share it.

You’re not a manager. Your job is not to control your teammates. You also do not handle payroll or promote people, but your manager is going to come to you when people ask about those things. It doesn’t mean you shouldn’t care about others advancements, on the contrary, but you don’t call the shots.

What a “Lead” is

Now that we’ve got what it doesn’t mean out of the way, here’s what being a Lead actually entails.

  • Being in the know – There’s a lot going on. Most likely there are other teams working on different areas of the same project, and you need to know what’s going on. Even if other teams are working on other projects, you want to know. You don’t need to know every detail, but you will find it extremely valuable to know what practices other teams are following and what they are working on. You can learn where the company is headed just by looking at pull requests and knowing the various projects that are going on.
  • First responder – The product owner and designer are going to be meeting with stakeholders and customers to figure out the next set(s) of work, and you need to be there. When that happens varies for each company, but the earlier the better. A lead engineer knows what is possible with the current infrastructure, what’s a reasonable solution, and what shortcuts can be taken. Likewise, when things go south, you have to be there. Since you’re in the know, you probably will know what went wrong. And even if you didn’t write the code that took down production over the weekend, you’re responsible for it.
  • Keeper of all things code – You should see every pull request your team puts up. Again, it’s not your code, but you are there to guide people in the right direction. The biggest thing here is to make people aware of what could break, what practices they aren’t following. It’s not personal, so you don’t want to make people feel bad; so tell them what should change and why. Slap an approval on it and move on, unless it’s really off base. Trust that they will do the right thing, that will make your and their life easier.
  • Creator of surface area – This is one of my favorite and most important points. If you are starting a new project, set up the structure, the router, and a few placeholder pages. Or set up the express server, a few routes, and the structure that demonstrates the flow of a request. Giving people room to spread out, ahead of time, prevents people from bumping their heads into others. If two developers are trying to make that routes file you’re going to end up with merge conflicts. #annoying
  • Keeper of peace – Everyone has an opinion, and that’s okay. There are a million ways to solve a problem, but how does your engineering department manage that? There will be disagreements, so people will look to you to solve them. There might not always be the perfect answer, and that’s okay, too. You’re going to have to weigh everything out and choose. At the end of the day, it’s just code. The beautiful thing about that is: you can always change it later. But don’t throw people under the bus. If something breaks, everything will be okay. Stay calm and be responsible; focus on the fix, then after, how to not find yourself in this situation again.
  • The most productive person in the room – Honestly, it’s going to be hard for people to respect you as a leader if you sit on your high throne. This is a short one, but if you get the most done, people will look up to you.

Become a sherpa

Every company is different. There are different coding standards, practices, and politics. It’s your job to guide the new developer on their journey. Who do they ask when they need a Jira account? Who do they talk to when they are locked out of their email? Maybe they need to find the person who knows the most about writing SQL joins or the person who created the architecture. You might not always know the answers, but if you know who does, you can point them in the right direction.

Questions? We're here to help!


If you're reading this, you unfortunately can't see the form that's supposed to be here. You probably have an ad blocker installed. Please switch off your adblocker in order to see this form.

Still encountering problems? Open this page in a different browser or get in touch with us: [email protected]