The Manager’s Path

Tech lead is usually a role and set of responsibilities, not a title. To fulfill those responsibilities a tech lead needs to grow their sphere of influence and then exercise that influence for the good of the organization.

The first place new tech leads go wrong is not differentiating managerial authority from leadership and influence. They wrongly assume that successful leadership requires managerial authority.

The second place where tech leads go wrong is perceiving themselves as managers or pseudo-managers. They start thinking of themselves and their calendar quickly fills with managerial tasks. They swing too far and the team stalls. These tech leads need to get back to the work of building.

The path from engineer to people manager runs through project management. If you’re wondering how you get into people management, it usually happens not because you’re a friendly person but rather because you have consistently demonstrated your ability to lead projects to success.

Project management skills make or break a tech lead. Engineering managers expect that tech leads can reliably deliver projects. Your reward for successful delivery is another project of higher complexity.

On the path from individual contributor to manager, the tech lead stage represents a critical point shift in mindset from self to team productivity. You need to start paying closer attention to how people on your team are producing, volunteering to help them work through tough problems, developing tooling and systems to improve everyone’s productivity, and communicating on behalf of the team.

Any manager can give positive feedback. Good managers give constructive feedback periodically. Great managers give corrective feedback immediately.

A more general principle here is to always reduce feedback loops. In development that could mean faster automated tests. In people management that can mean providing immediate feedback, particularly when that feedback is corrective because corrective feedback is the most difficult to provide and most tempting to avoid.

Micromanaging comes down to our desire for control among perceived chaos. Rather than giving into our controlling urges and trying to dominate the conversation, we as managers should first ask our teams how they are measuring success. If they aren’t measuring success, then you have some coaching to do. If they are measuring success, ask them to make it visible so you can see progress without interrupting them.

Engineering managers need to establish and maintain high standards, which requires assessing work quality from their employees. Assessing quality is much easier for technical engineering managers for two reasons.

First, you have the skills to assess quality. You know what quality code looks like. You also know what sloppy code looks like.

Second, when your direct reports know that you are assessing quality and that you have the technical skills to do so, they pay more attention to the details. Engineering managers having technical skills supports a virtuous cycle of quality.

Deployment frequency is one of the four key metrics of successful software delivery performance. So we know about using deployment frequency as a measure of productivity.

But productivity gains aren’t the only goal. Productive teams are usually happy teams. Engineers want to feel productive.

To the extent that engineering teams are simply production and execution arms of product development, they are replaceable and non-value add.

When you train engineers to think from a customer outcomes perspective, they see opportunities that non-engineers can’t see by virtue of their position.

A good CTO will drive education and training for their engineers, exposing them to business and customer outcomes and goals, which prevents engineering from being a pure execution arm.

A good rule of thumb is you need to communicate something about seven times before people start to really understand it, likely across several mediums to ensure you’re hitting both readers and listeners.

Too many engineering organizations, large and small, assess performance on a highly subjective basis and are susceptible to bias. When you interview at a company, ask them if they have an engineering growth framework or similar rubric for assessing performance.