12 Things I Wish I’d Known Before Becoming a Lead Engineer

Becoming a Lead Engineer requires a wide range of skills and responsibilities. Here’s some things to help you with the transition.

I’ve worked as a full-stack engineer for over ten years. In that time, I’ve worked on a variety of different things, from building custom USB drivers for AEM to leading a frontend team in ADP.

But this experience, while extremely useful, could nonetheless not prepare me for my current role: Leading a cross-functional team in the build of a venture from zero to launch. This role involved a year of development time at the BCG Digital Ventures office in Manhattan Beach in California before a three-week knowledge transition period in Singapore.

At BCGDV, we partner with industry-defining, global companies to build revolutionary ventures that have a lasting impact. We work with incumbent corporate partners to come up with business concepts before turning these concepts into companies. After we’ve settled on an idea, we get to work building the product. This involves breaking the list of necessary features down into user stories, staffing engineering teams on the project, bootstrapping applications, setting up cloud infrastructure, sprint planning, testing and deploying features and more. When we’ve built the full product offering, we convert it into a real company, having set it up for success. It’s a lot of work.

As a Lead Engineer, you’re responsible for many of these tasks, and the learning curve is steep. It’s rare to be given the opportunity to develop a company from idea to launch first hand, and, having been a part of a team that did this during my first Lead Engineer role, there are a few things I wish I’d have known beforehand. These tips are relevant for us at DV, but also for anyone working as a Lead Engineer on an early-stage startup.

There are 12 of them, and I hope I’ve covered everything. I hope you find them useful.

1. Build an open culture
   When you have a new team, it’s likely (and healthy!) for there to be differences of opinion, and it’s important for your team to be able to flag issues. Try to build an environment where people feel they can speak up, perhaps by assigning a dedicated person as a contact point.
2. Be a router
   Host meetings to align upstream and downstream: Sometimes expectations from leadership might not match the sentiments of your own team. As a Lead Engineer, it’s your role to route these concerns in the right direction. Try to host meetings, official or unofficial, to align your team and communicate what’s required.
3. Eat your own dog food
   You build it, you run it. This is especially important in new ventures, as the buck stops with us. Enable every product manager to end-to-end test, and encourage engineers to do QA work.
4. Turn feedback into actionable tasks
   In my experience, engineers are never short of feedback to offer. But this feedback can be improved by converting it into actionable items, which can help us build a better product. Bear this in mind in the product-building process.
5. Think about information sharing process
   It may sound obvious or boring but, believe me, it will save you considerable headaches later. For us, this is particularly important, as we have to sync between ourselves, our partners and those who will eventually take over the company. Align on one platform for each content type; Confluence to index, for example, or Google Docs rather than Microsoft Office for sheets and documentation.For sharing engineering information, think about using postman collection to share API details and Confluence to share spike results and QA workflows.
6. Allocate time for refactoring
   Software evolves all the time. None of us get things perfect the first time, and pretending otherwise will lead to headaches later. We also might come up with a vastly better way of doing things at a later stage which requires big refactors. Allocating this time as part of our delivery estimate is realistic, and will save you from unanticipated delays later.
7. Align on coding guidelines
   No team consists of members from exactly the same background. It’s likely you’ll have worked with different coding guidelines in previous teams, and it’s useful to talk about this before you get started. Before you begin to implement user stories, meet to align on agreed coding standards and principles, such as KISS, DRY etc.
8. Establish a code review committee
   The best way to ensure speed and consistency is to get things right the first time. When code has been deployed, it’s hard to remove. With this in mind, put into place a code committee, consisting of at least one engineer from your core team for backend and front end.
9. Be an unblocker
   One thing that sets a Lead Engineer apart is the responsibility to get the team operating as efficiently as possible. The most integral part of this is making sure team members can focus on their work, and aren’t blocked by day-to-day, operational tasks. These should be handled by you, whether it be onboarding a new developer and setting up their local environment or signing up for third-party services on behalf of the team, for example. It can also be a good idea to save certain tasks as “code recipes,” so that time isn’t wasted on repetition.
10. Remember that you’re delivering product and user experience, not just user stories
    User stories help us break down a complex product into manageable parts. But don’t lose sight of the bigger picture: You’re building a product. While each developer might be responsible for one feature of one module, make sure that the team doesn’t lose sight of the big picture.
11. Hire early
    Get hiring as soon as you reach beta stage (the final building phase before handing the venture to the partner or new company.) Finding good candidates takes longer than you think, and you should always be prepared for a longer transition or onboarding time.
12. Keep knowledge transfer at the top of your mind
    When you’re getting ready to hand over the company, you’ll thank yourself for documentation so that you set up the new team for success. Think about video recordings of demo sessions, document key decisions so you can justify them to the new team and generally think about how what you’re building will be operated in the long term after you’re gone.

Of course, a lot of becoming an excellent Lead Engineer is about learning from experience. But I hope that at least some of these pointers enable you a painless transition and put you and your team on the path to success.

Interested in working with us at BCGDV? Want to find out more? See our current vacancies.

Find us on Twitter @DV_Engineering.