Archives

All posts by mlamantia

Our team at Lookout is growing, and we’ve reached the point where we have several distinct engineering areas within the team — for example, backend server engineers, web app engineers, and Android engineers.  Both to keep development and design on track, and to provide a path for career growth, we’re developing technical leadership roles in the team.  This is an email that I wrote to team defining this role. 

You make good architecture and technical decisions happen.

Every day, in the course of specifying, designing, and implementing, engineers on the team make implicit or explicit decisions about architecture and technology that have long-term consequences.

As a tech lead, you make sure that these decisions are good, by making sure that the right discussions happen, by bringing a customer-centric viewpoint, by asking incisive questions, by listening, by facilitating consensus, and, very rarely, by the power of veto.  In doing so, you bring balanced judgment to the team — not only about what constitutes good design and good code, but also about how these considerations relate to development process, schedule, risk, maintainability, and business priorities.  Once these decisions are made, you make sure that they are documented and communicated effectively.

You give ownership of projects and their design to individual engineers in your team.

Designing things is fun.  Great engineers love to think critically about the tough problems that they’re working, and find the best solution.

As a tech lead, even though it’s your job to make sure the design is good, it’s not your job to do the design or make all the decisions yourself.  To the best extent possible, you give ownership of problems, solutions, and projects to the engineers working on them.  Exactly how much depends on the individual engineer, and her level of seniority and experience with the tasks at hand.

You plan on an iteration-to-iteration basis and map projects and goals to individuals.

For the team to work efficiently, features and epics need to be broken down into digestible stories and tasks, with well-understood dependencies, and these tasks need to be assigned to engineers who can do them, taking into account both their current capabilities and growth.

As a tech lead, you review work items with the engineers on your team each iteration, to find appropriate projects and make sure that task breakdown is happening efficiently.  With senior engineers, this might be a quick review, and with junior engineers, you might need to mentor them on doing task breakdown well, and expand their way of looking at problems.

You are a key contributor to technical roadmap planning.

You work with product, program, and engineering managers to surface key technical initiatives in the roadmap, and to advise on feasibility of level of effort of planned features.

You make judicious tradeoffs and drive out ambiguity to set priorities

Many technical decisions do not have a clear best answer.  Sometimes, technical and/or business goals are in conflict with each other.  Sometimes, customer requirements are uncertain.  Frequently, constraints of time and people’s availability require tough choices amongst priorities that all seem important.

As a tech lead, in partnership with product and engineering management, as you plan from the iteration to the roadmap level, you need to be able to set priorities with imperfect information, by finding creative ways to manage risk and preserve strategic options.

You mentor and grow the technical knowledge of individuals in the team.

Mentoring junior engineers is the responsibility of every senior engineer, but you take a special interest in the growth of all members of the team.  Because you have responsibility for task breakdown and assignment, you need to ensure that each engineer has a mix of work that both builds on their strengths and also provides room for growth.

You check every code review in your team

As a tech lead, you take a look at every code review from your team members to verify that each one meets consistent and specific criteria, which may change as the team’s needs as priority changes:  Is the quality bar high enough?  Does it contain the right tests?  Is it in line with the architecture/design that the team has agreed on?

Checking on every code review also enables you to keep an eye on team dynamics:  Are reviews going well, or is there disagreement?  Is the project on track to hit milestones?  Is each developer producing good code consistently?

Checking every code review does not mean that you should actually do every review.  In fact, you definitely should not do every code review — you should do a few key reviews, and make sure everyone else on the team is doing reviews, too.

You push the team towards excellence in innovation and execution

Achieving meaningful innovation is a core cultural value for Lookout and critical to our success.

As a tech lead, you provide guidance and support to long-term development of technology and product differentiators.

However, our business goals as a company also depend on our ability to meet engineering deliverables, such as feature development milestones and GA’ing the product, on time.

So, as an tech lead, you also need to be critically aware of whether development projects are on track to meet their scheduled delivery.  If they’re not, you need to communicate awareness of this fact to your management chain and other stakeholders, and look for strategies to mitigate the issue, in a way that’s appropriate to the team’s goals and priorities.

You have been a stellar individual contributor in your technical area.

Being a tech lead is a hands-on role that requires knowledge about the specific technical area that the team works in.  So being an accomplished engineer with relevant experience is a prerequisite for this role.

People want to be on your team.

Peers respect your technical knowledge and judgment.  They view you as someone they’d like to work with.  Your leadership both draws and retains people to the team and to Lookout.

You are the right person to lead the team now.

Despite all of these descriptions of things that you do and qualities that you possess, in fact, it’s not about you.  It’s about the team.  Unlike a raise, which is a reward for a job well done, or a promotion, which is a recognition that you’ve acquired skills and experience that qualify you for a broader role (hat tip: Jocelyn Goldfein), a leadership position is not a statement about you or your performance, but a statement about a very specific fit that the team needs to be happy and effective.  We have commitment to providing opportunities for growth to each engineer, but it’s important to understand that, in contrast to avenues of growth that are individual in nature, the primary criterion for selecting a team lead is who will be best for the team.  We can coach you to develop these qualities and to identify opportunities to step up, but a leadership position is not the same as individual contribution, and does not follow automatically from excellence in individual contribution.

Hi there. I’m Matt LaMantia, an engineering manager at Lookout, a software company that specializes in mobile security.

In order to develop our team and its people, I’ve found it useful to put into writing things like roles, responsibilities, into writing. (And, thanks for the firm nudge to get started, to Dawn Sharifan, Lookout’s Director of People Engagement.)

More broadly, I believe that both software engineering process and management demand reflection, for all the obvious reasons: We’re building new things, and building the ways we build them, at the same time. And the philosophy and practice of managing a team affects people’s careers and ultimately their lives.

The purpose of this space is to put these thoughts out to a broader audience, where they can be the start of a conversation. Everything here is a work in progress, and I welcome your thoughts, so please jump in!