An L2 is a developer who has some experience in developing software, and a reasonable understanding of how to build production quality software. They have moved past the most common rookie mistakes, and are recognized as a solid contributor.
An L2 implements reliable production software quickly and with high quality. They mentor more junior engineers and interns, are able to complete complex tasks with guidance from their tech lead, and communicate proactively with project stakeholders. They demonstrate ownership of their team's systems in addition to their projects, and take part in relevant pager rotations. An L2 actively seeks opportunities to deepen their expertise in one or more areas, while continuing to grow into a strong generalist.
The following sections provide more details on expectations for an L2.
L2s are comfortable with the requirements for success at the L1 level, and perform them to a high degree of competency. They complete tasks quickly and with high quality, generate reasonably accurate time estimates, are effective code reviewers, and are able to take on more complex, less well-defined technical tasks.
Additionally, at this level engineers are starting to look for ways to positively impact their team output beyond just delivering projects. There are many ways in which this can be done:
- Mentor interns or new hires
- Apply particular background / interests to business needs
- Actively participate in design reviews
- Advocate for better testing / static analysis / tooling / etc.
As an L2 develops, they are expected to start thinking about their team’s business goals, and to use this knowledge to drive better results - whether by helping PMs to develop or improve specs, or by coming up with their own project ideas.
An L2 is expected to start taking ownership of one or more areas of the code base - in addition to their assigned tasks. They are expected to take the initiative, identify needs that aren’t being addressed, come up with solutions, and make them happen. They become an advocate for the code they own, look for opportunities to improve and maintain it, communicate risks actively, and protect it from breakage.
By taking ownership of these areas of the code, they deepen their understanding, become an advocate for good programming practices, and become known as the owner/expert of a particular technical area.
An L2 is expected to have internalized their team’s processes, and to help support new engineers as they come up to speed. Process is not a replacement for good judgment, and L2s are expected to be able to make the tradeoff between enforcing process in most situations, being flexible when appropriate, and knowing when to escalate.
L2s are expected to participate in and support a positive team environment.
L2s understand that it is critical to keep stakeholders in a tight loop. This includes actively communicating opportunities and risks about projects, operational infrastructure, people, and areas of unofficial ownership. An L2 is able to communicate status effectively, and keep project management tools such as Jira up to date.
An L2 is expected to continue to broaden their expertise as a strong generalist, while deepening their expertise in one or more areas - the so-called “T-shaped” engineer. This is also a critical time for pushing themselves outside of their comfort zones.
L2s are expected to start taking a leadership role within their teams. At a very basic level, “leadership” can be defined as doing something useful that no one told you to do. Completing assigned tasks is a necessary requirement for job success, but it isn’t “leadership”.
To some extent, leadership is baked into the above descriptions. All of the following are ways in which L2s demonstrate leadership:
- Taking ownership of an area of the code base or data, and keeping it clean of cruft and code rot
- Owning team process, training newcomers, and actively looking for process and technology improvements
- Looking for opportunities to share knowledge and help teammates in their personal development
- Identifying project ideas and/or revenue opportunities
- Not eating your vegetables. In order to exceed expectations, you must first meet expectations. It isn’t unusual for engineers to get caught up in side projects, and to fail to complete the specific tasks they’ve been assigned, and for which they’re being depended on.
- Always using the right tool for the job. There’s a balance between using tools in the existing tech stack which would be “good enough”, and wanting to introduce new technology that might be a perfect match for a problem, but would introduce additional costs in terms of maintenance, operational complexity, and training. This is related to the desire to use cutting edge, “cool” technology over tried-and-true, boring technology. It can be easy to see the benefits a new technology will bring, and hard to see the marginal costs of introducing it to the tech stack.
Next up: L3