202211011039 Effective staff engineering meetings

The measure of an effective staff engineering meeting is the same as the measure of an effective 202206112233 Staff-plus engineer. The goals are the same and having a meeting simply facilitates people doing their jobs well. A huge portion of high-level engineering is communication and alignment. There's no better way to achieve those two things than regularly talking with people.

How to get started

Just schedule the first meeting with staff engineers to go over what this is and how the group would like to proceed.

• Set a cadence
• Assign an owner of the calendar meeting and agenda

Going forward, the agenda should be collaboratively set, allowing for leads from teams to bring things that their team and engineers on their team care about or are working on. Particularly, they should present things that would benefit from feedback from this group, things that people on their team are struggling with, or things that other teams would benefit from knowing about. This is primarily a communication meeting, though working sessions are valuable from time to time.

Purpose, benefits, and outcomes

• Setting company-wide technical direction.
• Coordinating mentorship and sponsorship for engineers across the company.
• Providing engineering perspective on leadership initiatives. How do the things going on in the company affect engineers? How will they respond to things? How can we help inspire and lead?
• Explorations and POCs: which ones do we need to do, who is doing them, what do others think about the results, is there any feedback about the tech/direction?
• Surfacing glue work that we need to accomplish as a group to keep things moving in the right directions.
• Solving and scoping complex tasks as a group.
• Coordinating and unblocking teams.
• Making sure we all have context on initiatives and technical direction so that we can carry and share it widely.
• Generating vision and purpose, and inspiring others to work towards it.
• Coordinating delegation of technical direction items that span teams and longer timelines.
• Writing engineering strategy down so that we have records and rationale to share now and review in the future.
• Curating technical quality and having a forum of accountability across teams.
• Staying aligned with technical and business leaders.
• Creating a forum for engineers on teams to be heard across teams via their representatives.
• Building a network of peers for high level engineers.
• Building a peer group for the development and growth of mid-level engineers to work with, get feedback from, and assimilate into as they get promoted.

Specific items to cover in the near term

A lot of these near-term items are just the basic foundations that are needed for a team to be able to create something new or work on their area of ownership without requiring approval and help from others.

• Does everyone in the meeting know where we want to be in 6 months, both engineering wise and the broader business? Who can give us a definitive vision on this that we can stay in sync with on an ongoing basis?
• Organization, cataloging, and archiving of code.
  • What exists?
  • Where?
  • Is it up to date?
  • What can we archive/delete?
  • Is everything documented? Is it documented well?
  • Architecture/component diagrams
  • Consolidated model of each team's area of ownership
• How do we get to a place with dead simple onboarding and development environment setup?
  • Access to systems should not be something that the new employee has to stumble across needing and ask around to figure out who can help them with it.
  • We need developers to be able to read all the code that exists, no matter what level of access is needed to edit it.
• Create a standard tech list, golden path, and tech radar.
• Coherent company-wide philosophy on things like microservices, deployments, tech, etc.

In particular, having a sense of alignment on tech standards, code ownership, and business objectives allows a lead engineer on a team to make decisions with their team that they can be confident in. They can move fast with confidence and quality. The meeting is then the valve that allows closing gaps or asking questions of the group in a timely and well-defined forum.

Role of people leadership in the meeting

Once the meeting is set up and attendees are well aligned with leadership, people leaders should scale back their involvement in the meeting. (I don’t think there’s a hard rule on what exactly this means, but people leaders should not typically drive conversation.) There are two main benefits to this approach.

First, technical leaders should be able to discuss and create goals around engineering specific concerns without the “reality of the business” influencing the discussion too much. This is a nuanced exercise whose outcome is a set of goals that are aligned with the needs of the business, but also advocate strongly for engineering needs that the business typically discounts (think tech debt, scaling, one off important migrations, etc.). This results in a healthy tension between business/people leaders and technical leaders. That healthy tension can only be maintained through high trust, pragmatic understanding, and the ability to disagree and commit on both sides. We therefore use job titles and inclusion in this group as a filter for people whose actual job responsibilities include embodying those qualities. To put it another way, we trust that engineers in this group can have these goal setting sessions and advocate strongly for engineers, but ultimately commit to some aligned strategy that takes the business needs into account.

Second, technical leaders have a responsibility to empathize with engineers on their teams and to provide context for company-wide strategy in a way that engineers understand and align with. This meeting is a good way for high-level engineers on each team to discuss company happenings and organizational issues in an engineering specific context. The goal of these discussions is to enable technical leaders to be a second, complimentary voice to engineering managers in order to align and inspire engineers to work towards the business’s goals.

For example, imagine there’s an initiative or message from leadership that we want to move faster on releasing features but increase quality and reliability at the same time. Engineers may feel that those goals conflict and can’t both happen simultaneously. This meeting gives engineers who are capable of distilling that message into a relevant framing a space to collaborate on how to help others make sense of the situation without spinning their wheels and getting hung up on things. It’s also a good forum for engineers to voice their concerns and the concerns of their teammates in a circle of trust that we’re all looking for solutions together.