The Virtues of an Unproductive Tech Lead

For first-time tech leads, transitioning from an engineering role to an engineering + tech lead role can be a bit of a culture shock.

Gone are the days of writing code without distraction. You will be asked questions on things you’ve never previously needed to give any thought to, and those questions will be across all domains of your project.

Oftentimes, these problems will come across your desk because no one else can solve them.

While these challenges are something to look forward to, they don’t always sum up to the most productive feeling days. These circumstances can beg the following questions:

• If tech leads are still engineers, where should their focus be if it isn’t writing code like it was beforehand?

• With these new demands, how should a lead prioritize what is most important, especially when demands stack up faster than they can be addressed and at the expense of your morning’s to-do list?

To answer those questions, one must fully understand the role of a tech lead and why companies find their position so important.

The Foreman Analogy

Tech leads are like project foremen.

They don’t design the visual appearance of a building, but they oversee the technical aspects required to get it built. Let me draw a few parallels by asking some rhetorical questions.

• Is the role of a foreman on a construction site any less important than the others?

• Does that person hoist the steel beams in place because he can do it faster than the crane operator?

• Does he pour the cement, install the windows, or wire the building?

The answer to all of those questions is, of course, no. Foremen are not hired for that position because they are the best, fastest, or most knowledgeable of all the related aspects of that project.

Instead, they:

• have a unique understanding of their project’s demands.

• are “people persons” who can rally their colleagues around a cause and keep the team flowing well.

• have enough knowledge of their project’s components to know when something is going right or wrong and requires further attention.

• keep the timeline on track.

Notice that there are very few technical requirements in the above list. Swap out “foreman” for “tech lead,” and you have nearly an exact blueprint of what to do.

Keep Your Colleagues’ Plates Spinning

If you can pick up a story because the team is flowing well and there aren’t other areas requiring your attention, go ahead. However, that is no longer your primary obligation.

Even if you are a savant who could smoke your keyboard as you write out line after line of perfect code, you will never be as productive as your team. All it takes are a few engineers (even new ones) to outperform a senior.

Being a tech lead isn’t a pat on the back for being the most productive engineer on the project, but it is a (kindly, metaphorical) kick in the rear to make your team as productive as possible.

Your job is to remove the barriers and friction to ensure everyone else's development process is as seamless and smooth as possible. You are looking out for your team, not yourself.

Make Difficult Jobs Simple

This point is one of those times where you put the “tech” in “tech lead.” You are not suddenly untechnical because you’ve stopped writing code every day, but your focus has shifted toward the benefit of your colleagues.

Here are some ways you can make the jobs of your colleagues easier:

• Identify bad patterns used repeatedly in the codebase and set the standard for a new way of doing them.

• Offer to take the difficult or elusive problems off your teammates’ plates so that they can be more productive and have fewer spin cycles.

• Fill in the biggest gaps in your internal documentation so that future eyes and fingers can understand what to do when that subject needs revisited or implemented elsewhere.

• Refactor or repackage complex code that shows up multiple times and always gives your colleagues a hard time.

• If your team is stuck on something, take the lead and find the answer. This answer can be technical or non-technical. Either way, it was a blocking issue that needed attention.

Blaze the Trails

Unknowns can be intimidating. That is why companies send out their best to tackle them. These discovery processes aren’t always the most straightforward or productive feeling exercises, but they often prove incredibly necessary and insightful for the product or technical direction.

Your trial-and-error or start-and-stop investigation may be slow, but it will unlock the virtue of speed whenever it comes time for you to hand the baton to the team to implement the feature. It is a trade-off that pays dividends.

Once you have gained and digested relative expertise on this subject, the added time you spend sharing and documenting your findings will make the jobs of two, three, four, or more engineers easier and less error-prone.

This process also sets the trend for how this feature and similar situations in the future are addressed. This is an important role that can have long-term impacts.

Set the Technical Vision and Direction

I cannot emphasize this point enough. This aspect of technical leadership is an opportunity to flex your technical muscles and be a leader of vision.

Even though the product team is responsible for the application’s feature set and appearance, that doesn’t make your role any less important.

How can the product’s vision be set and continued?

• Establish an architectural standard or a general practice for building commonly used components.

• Research tools or libraries that can ease the burden of custom development or simplify complex implementations.

• Identify areas where your team is not adhering to best practices and address them. Oftentimes, this problem can stem from a lack of knowledge or time.

• Keep up with the latest development trends so your team isn’t falling behind. This often involves a lot of reading during your downtime (at work, of course, not off the clock) to stay abreast of the industry’s direction.

• Take the time to build out a new way of doing something, then use it as a template for the rest of the team to follow as new functionality is added or old code is migrated to newer standards.

From a technical standpoint, fundamental practices and architectural patterns can be the most impactful and far-reaching decisions you’ll ever make.

A good leader involves listening to your team and gathering feedback, ultimately making the go/no-go call.

Conclusion

Now that I’ve laid out the most important jobs of an engineering tech lead, suddenly, they don’t seem so unproductive. Sacrificing your morning’s neatly organized to-do list for the ongoing benefit of an entire team seems like a worthy exchange.

So next time you feel unproductive because your focus has been derailed, ask yourself: is my team still progressing smoothly? If so, you can rest assured that you are doing the right thing.

After all, we can quote Peter Parker when we say, “With great power comes great responsibility.”

Use it wisely.