advice from a lead engineer

Day 26 of 30. As a lead engineer, I often get asked what it means to be a lead engineer - and this mostly by senior engineers I work with, who are curious what the next step in their career might be.

There are loads of fantastic resources out there like StaffEng or the Staff Engineer's Path - and that hints at one reason answering this question is so difficult: it's so specific to which company you're in, often even to which team you're leading. This is also why it's important to ask your lead: if you stick around the same company and want to grow, their instantiation of this role is the one you need to know more about.

Some companies call it a tech lead; others an engineering lead; others don't have this role, and instead have staff or principal engineers. So even figuring out what to ask about is hard.

On early-stage teams, lead engineers might spend a lot of time on strategy, technical discovery (i.e. what is actually possible to build here?), and hiring plans, with little or no time spent coding: after all, in this stage, you don't even know what to code yet. On more mature teams, lead engineers might spend the bulk of their time mentoring others, reviewing code, and scoping out tasks.

On teams with a product requiring deep domain knowledge, lead engineers might focus inwards, using their expertise to plan and sequence the right work, dive into especially domain-driven areas of the codebase, and train others up around them. On teams with many dependencies, lead engineers might focus outwards, finding the right architecture that spans many teams, surfacing and documenting key details on integration points.

And it changes week-to-week, day-to-day. Meetings where someone has to speak to the technical side, and that someone is you. Interviews where your input is crucial to finding the right candidate to hire. Technical discussions with other teams, especially if you depend on their services (or vice-versa). Design-dev sparring to help get designs ready for implementation. A surprise demo to your product manager's boss' boss, who just happened to be walking by. Helping to scope the upcoming sprint, or epic, or cycle, or increment, or milestone, or whatever your team's next useful time horizon looks like.

My usual short, offhand description of being a lead engineer: I'm an engineer who's chosen to multiclass as a manager.

But less offhand: what's essential in this job?

Communication. Listening to what others are saying (and not saying). Being clear around dependencies, timelines, details. Raising a flag when something isn't possible, or is much harder than expected. Raising a flag when something is possible, and easier than expected. Documenting your work. Updating that documentation. Presenting to key stakeholders. Mentoring other engineers. Giving feedback: lots of it, both positive and negative, in a timely manner. You should have started learning these skills as a mid-level and senior engineer. You will depend on these skills as a lead engineer, and you must continually refine them. You are the technical voice of the team. You are a leader to other engineers.

Logistics. In many cases, lead engineers are the technical planners for entire products. You'll likely have a large say in hiring the right people to build the product: defining the skills needed, writing job descriptions, conducting interviews. Your scope extends beyond the next sprint, the next milestone: product managers will ask you to inform roadmaps for the next year, define plans for the upcoming MVP launch several months out. That means you also have a large say in defining architecture, which in turn informs your external dependencies, which in turn creates work to de-risk those integrations that you are primarily responsible for.

Leadership. It's in the title. But what does it mean in practice? You own your mistakes, openly and proactively. You set an example to others, not just with words but with action. You honour commitments you make. You make decisions where no one else will, and make space for others to be involved, and continually find the right balance of these two. You make time to meet 1-on-1 with others. You set the emotional tone of meetings, discussions, teamwork in general. You delegate to help grow others, and get involved enough in the work to lead from the front, and continually find the right balance of these two. You'll do a lot of balancing, which brings me to...

Time management. As you can guess from the above, you'll have a lot of competing demands on your time. You won't be able to do everything everyone wants of you: you'll have to choose, and be clear about what your choices are (and why), and occasionally defend those choices. I like to ensure I'm spending 30-50% of my time on building: coding the product, yes, but also code reviews, pairing, mentoring other devs, setting up tools, defining architecture. Any more, and I'm probably letting my non-building duties slip. Any less, and I won't have the visibility I need to be an effective technical leader.

Like I said: there's no One True Way to do this job. There's the way that works for your team, your product, your organisation. Above all, you'll need to be flexible, and build a toolbox that is both deep and broad - in both technical and interpersonal areas.