What It Means To Be A Lead Engineer

I’ve been in the tech industry for quite a while. Enough where I should be a lot higher than where I am. However, I usually end up in senior/lead roles and I think at this point, I have the experience to share what ends up happening in those roles and how one should handle them.

I think when people see a lead role the first thing that comes to mind is management. Lead (sometimes can be replaced by the title of principal) engineer sounds exciting where a person gets a chance to take a group of engineers, bestow his/her wisdom upon them, architect a fantastic solution and laud appraisal from their work.

That idea is far more fantasy than reality in my experience. A lead role really depends upon the company, engineering culture (if there is one) and how the individual accepts the responsibility. Quite a few times, the lead engineer is the person responsible for being the person to give answers, even when there aren’t any.

The keyword that should be emphasized more than anything is responsibility. It’s not necessarily a badge of honor or something that you can take pride in. It’s merely that this is your job in being one of the primary people accountable in the chain of things.

Sometimes, being a lead engineer does not entail managing anyone at all. Instead, the role might be the starter for a project or a company. But in this case, you are not necessarily a director or CTO but the person who needs to ensure the success of those aspects.

Being a lead engineer does not necessarily make you a real manager neither. Instead, you’re more like a platoon leader, trying to get through a minefield with your patrol. So that means for you to succeed, you must also ensure that your team succeeds.

And here’s where I think the delusion/dichotomy of being a lead vs a “manager” type diverges. A manager, in my view, is something with little skill who ends up worming their way upwards and whose sole purpose is to tell others to do something. It does not necessarily have to be correct as long as they are “managing.”

A lead takes a more active role with a team. They serve to inspire, to provide ideas and utilize their experience where their team normally is lacking. Also, they act on behalf of their team in between other stakeholders, similar to a project manager.

However, the difference between a project manager and a lead is that the lead understands the technical aspects of the job at hand. The project manager handles the resources and scheduling and relies on the lead to help meet milestones and provide backing whenever those resources are down. So if a member on the team cannot handle a job, it is up to the lead to figure out how to either help them, push back on their behalf or move the pebble a few feet forward.

That last part is where their technical expertise comes in useful. This is where a lead might have to become hands on. Part of it as an engineer might be through very careful code reviews, but there’s a good chance that one has to get their hands dirty and write code or fix bugs if their teammates resurface problems frequently.

The reason this part can be sketchy for some leads is that they might not want to do any coding because they misinterpreted lead and manager as being the same thing. And for those people who are like that, they should have been screened out a long while back.

The joke I’ve come to expect from being a lead developer is that it implies not only will you be doing your work, but the work of all the people under you. And it’s true to a degree because you get so many other responsibilities but still have to ensure quality from members of your team.

What about lead as an architect? Again, this depends on the company and culture. Large companies generally separate these roles out so that the architect is responsible for standards, technologies, how disparate systems interoperate, etc. A lead at such a company might be handle a subset of that standard and have a stronger voice.

At a smaller company, a lead most likely will wear multiple hats. Generally at smaller companies (like a start up), the lead won’t have people to manage but are the ones trying to set the foundation of the application up and help make the company succeed (if the company is dependent upon that app). In these cases, you’ll get to set the pace and structure the way you want but the cost is that you’ll also be handling everything most likely.

Given these situations, the real story is that if you’re hired into a lead spot, you should have quite a bit of experience that makes you feel confident in your abilities. It’s easy to become overwhelmed in both cases, especially if you’ve never worked as a lead up to that point.

So what’s some advice to help make one a good lead? Here’s a variety of tips, habits, pearls of wisdom that I have to help improve your journey to become a good lead:

• Understand that a lead is not necessarily a manager nor architect. It might be something in between.
• Learn to communicate and deal with non-technical people. That means, understand the idea of a target audience. Sometimes a sales person might approach you for questions or someone from help desk or even a customer. Be prepared to give concise answers that those people can understand.
• Seek out the big picture in a company. It’s easy to get lost in the details as someone who goes from being a hardcore developer to a lead. But one thing I’ve found is that by understanding the goals of a company and what they do, I can figure out my own place within the company.  And what that means is that sometimes you can’t go off in a corner and write cool code for yourself. That’s not how businesses work. Save that and your energy for your personal projects.
• Demand high quality not just from those around you but yourself. It’s easy to slide into a lead position and become complacent. Becoming complacent means that your skills slide and overtime your value slides. If you force yourself to constantly learn, you never will have confidence issues.
• Don’t BS people. People eventually will discover the truth. However, the problem in this industry is that it’s plagued with upper management pleasing sycophants. Things that affect deadlines, resources, quality, etc. should never be lied about because all those aspects will come to haunt you and others. This is even far more important in mission critical systems where the software should never fail (e.g. airline systems, medical, missiles, etc.)
• Be strong but tolerant towards teammates that frequently make errors. It’s easy to get upset at people who end up fucking up often. But unless they’re completely incompetent and insincere, you need to get passed your personal issues to help guide them to correct their mistakes. Another way to put it is if you fire them, you might be the one doing the actual work until you get a replacement. So that should be your motivation.
• Be prepared for much longer hours especially if you have a team. If you have a large enough team, I’ll assume that you won’t be forced to do as much actual coding just because you can delegate. But if you start feeling pressure unexpectedly, you might reconsider your priorities in life because you will have a lot of demands in this role.
• Don’t be afraid to delegate. There are other types of lead engineers who end up attempting to do everything themselves because they’re fearful of their teammates fucking up or that they’re control freaks. You have to learn to trust others to do their work and you need to build up trust in others by giving them chunks to see what their real output is.
• Work with project and product managers to create meaningful, bite sized chunks of work for your team. With the complexity of software increasing all the time and ideas like SCRUM/Agile becoming core engineering practices, then the goal of a lead in a team oriented environment with SCRUM in place would be to help craft tickets from the requirements provided by the product manager to distribute among their teammates. Ideally, you don’t want tickets with large points exceeding 8 (if you use Fibonacci)
• Keep up with the system. Make sure you’re clued in on how things work. Again, the emphasis here is on communication between groups. Larger companies with more teams tend to not function that well just because of the way the areas are divided. In some cases where the code base is within a monolith, it’s absolutely critical to be aware of other teams’ progress as people might find each other stomping on commits, especially as a project becomes out of sync with master.

  From a technical point of view, you might consider rebasing the code periodically to keep the branch of code in line with master.

• Make sure the members of your team practice good habits. A small list of habits I have are:
  • Performing code reviews before allowing merges (with two approvals)
  • Maintaining code that is consistently written in terms of standards
  • Commenting on obscure functionality and ensuring that variable names and functions are meaningful.
  • Enforce rules for functions such as maximum lengths of the internals of a function, limited number of parameters that aren’t allowed to grow out of control, the testability of a function, etc.
  • Making sure every commit is associated with a ticket. In this manner, the code can be traced back not just to the author but why the code was done in the first place.
  • Having developers test their own code. Not just unit test it, but actually do integration tests on their own.
  • Confirm that the developers understand the ask of a ticket. When a ticket is obscure, continue pushing back until proper requirements are provided. Part of that should be unveiled through the size of a ticket.
  • If you have a ticket that’s sized very high (say 13+), seek ways to cut down the size. Remember that part of being an engineer is to take larger problems and cutting them into smaller, more easily resolved pieces. Divide and conquer.
• If you’re immediately thinking of a technical solution (e.g. deciding on a database backend, whether to use a microservice architecture) before understanding the problem, YOU’RE DOING IT WRONG. Never tackle the technical aspects of a problem before figuring out what is being asked. It is ass backwards and the sign of a very immature engineer.
• Learn to control your impulses. A long time ago, I learned that I was very impulsive in a psychology test. Over the years, I tempered that impulsiveness because that aspect of my personality was becoming a bane to my existence, especially as a tech lead.

  The reason for this is that when I give an answer, I need to be as accurate as possible. Although there are others who say otherwise, as a person who attempts to be ethical in their dealings, I feel that as a lead, the people I report to deserve to hear the truth, whether they like it or not.

  But sometimes where that impulsiveness becomes a hindrance is that I can easily become overly excited about something I might have believed I solved, only to discover later on that my solution or answer created even more problems. As a lead engineer, you should know that software never is truly 100% reliable and that you should always expect the unexpected. So curbing your enthusiasm to please is critical in this role.

• Learn to walk away. There’s a time and place to fight. But not every war needs a battle at every turn. This industry has a ton of egos and having another hot headed person does not help the situation. So pick and choose your battles because you’ll save a lot of energy and hair.

I think these are pretty good tips and pieces of advice from me. Maybe others can contribute here in the future. Or that I might add more in another article.

Comments

comments