The Technical Lead

I’ve spent the better part of the past three years learning on the fly and thinking about how to be an effective technical lead at an early stage startup. Whether the role is called a VP Engineering, a CTO, an Engineering Lead, or something else, its aim remains the same: to build both product and team. Responsibilities can include defining and executing on product, recruiting a talented engineering team, building a strong technical brand, evangelizing the company’s platform, creating a fun and intelligent engineering culture and environment, forecasting for the company’s technical needs in the future, and establishing metrics and criteria for ensuring the the company’s technology is delivering and progressing according to business needs. 


While all of these things, and many more, are very important, I believe that there are really three overarching themes that the technical lead of a business needs to be thinking about all the time above all else:


  1. The technical vision of the company
  2. Enabling the engineering team
  3. The engineering culture

The technical vision of the company

It is the technical lead’s job to set, communicate, and lead the technical vision of the company by example. This includes but is not limited to:

  • clearly defining what is going to be built and when it will be delivered
  • justifying and communicating why this is important to the business
  • determining what technologies will be used and why
  • determining workflows for development including iterations, release cycles, testing practices, deployment practices, code reviews, etc

Is the team going to rush to the quickest possible minimum viable product and then iterate, or is it going to build quietly for months until it emerges with a hardened solution that’s ready to go to market? What tech stack will it use? It’s always recommended to use the best tool for the job at hand, but a company that is building using .NET and Oracle from day one is likely going to follow different technical dogma than one using Python and MongoDB. A company doing waterfall development will feel a lot different to an engineering hire than one continuously integrating and deploying. 


The technical lead will make these decisions early on in the company’s path, and the practices that they lay down by example amongst the early employees will dictate the future technical direction of the company. And with quite a bit of momentum it may be hard to change course later.


Enabling the engineering team

After the initial team is established, and all of the roles are filled that are required to get the product to market, I believe that enabling the engineering team is the most important role of the technical lead. They must identify any blockers to progress for the team, and remove said blockers as quickly as possible.


Blockers are tricky because they can come in many forms – an unnecessary midday meeting which interrupts the flow every Tuesday and Thursday, ill-defined requirements from the product side of the house, inefficient processes and lack of automation for requesting and setting up servers, unavailability of healthy snacks around the office, lack of data to validate whether the feature in question is effective or not, etc. 


Team is everything, and when the right bunch is fully enabled with the right equipment, environment, vision, and resources to do their best work, the results are magical. When they are blocked by any of the above, productivity can grind to a halt. As technical lead of the company, you have more power than anybody else to empower your team to be the best and happiest that they can be. Make it your highest priority to do so.


The engineering culture

I believe that a clearly apparent culture within a company is critical. From observing and living within the culture you can tell who the company is, what’s important to it, who will fit in and enjoy working there, and what it might look like when it grows. If a company is devoid of culture, it has no clear identity to those looking to join or work with it, and this obviously can have negative consequences. 


From an engineering perspective, the culture begins with the technical lead. Is this an engineering team that diligently works together from 9-5 and then checks out? Is it one that grinds through the night and wanders back in to work in the afternoon hours? Is techno blasting from the office speakers or do people quietly work with headphones? Does the team sit together on an open floor or sequestered within their own offices? Do you hold weekly tech talks, brown bags, hack days? Is there 20% time for personal projects?  Is it an academic environment that encourages research and publishing? Do you eat lunch together and go to happy hour? Do you break for high intensity table tennis matches or do you reward engineering milestones with prizes and bonuses?


You can build a successful engineering team by answering any of the above questions in any way, as long as the culture is consistent amongst the majority (or preferably all) of your team members. When you’re working as one team, the culture that you define, prioritize, and maintain will go farther than anything else in attracting a strong team that works together efficiently, productively, and most importantly has fun doing what they do.


At Hyperpublic I was very lucky to work with a team of some of the finest engineers I’ve ever known, within a culture that was a ton of fun to be a part of and help create. I have no doubt that as a company grows beyond ten people, and branches into multiple teams, the challenges for an engineering lead grow and become more complex. I look forward to learning and adapting to them on the next go round.