Should you include engineers in your leadership meetings?

While Staff Engineer was first and foremost an attempt to pull the industry towards my perspective on staff-plus engineering roles, writing it also changed my opinions in a number of ways. Foremost, it solidified my belief that the industry too often treats engineers like children to be managed, rather than adults to be involved, and that I needed to change some of my own leadership practices that I’d inadvertently adopted.

When I started writing it, I had already shifted my opinion about reporting hierarchy, believing that it was important to have engineers reporting directly to senior leaders rather than reporting to leaf managers. But I hadn’t gone the whole distance to include them in my core leadership meeting. However, for the last six years I have had active engineers in my senior-most leadership group, I’m glad that I’ve adopted this practice, and I intend to continue it going forward.

Mechanics

The core approach here is:

1. Have a weekly meeting with my directs and key cross-functional partners. For example, at Stripe, this was my direct reports, our HRBP, and the recruiter we worked with most closely.
2. Elevate a small number of senior-most engineers to report to me directly as Head of Engineering / CTO, who then naturally start to join that weekly meeting
3. Everyone is included in all discussions, e.g. there are no managerial discussions that the engineers are excluded from unless there’s a very specific reason (e.g. excluding engineers from a performance calibration meeting for their peers at the same level)
4. If anyone violates the meeting’s trust, whether they are an engineer or a manager, they get in a lot of trouble

This is a simple formula, but has worked well for me the past decade. There absolutely are topics that some people don’t care about too much, but I try to push my leadership team to care widely, even if things don’t impact them directly.

Upsides

It’s easy for managers to get into a mode where they are managing the stuff around reality, without managing reality itself. That is much harder when engineers who write and maintain the company’s software are in the room, which is the biggest benefit of including them. Similarly, there are many decisions and discussions that would have to be punted to another forum without effective engineering representation in the room. You might not be able to finalize the technical approach to a complex problem with only a few engineers in the room, but you can at least evaluate the options much further.

Another major benefit is that these engineers become a second propagation mechanism for important context. Sometimes you’ll have a manager who isn’t communicating effectively with their team, and while long-term that has to be solved directly, having these engineers means that information can flow down to their teams through the engineers instead.

Finally, this sets an expectation for the managers in the room that they should be in the details of the technical work, just as the engineers in the room should understand the managerial work.

Downsides?

There are relatively few downsides to this approach, but it does serve as a bit of a filter for folks who have a misguided view of what senior leadership entails. For example, there are some engineers who think senior leadership is having veto power over others without being accountable for the consequences of that veto. Those folks don’t survive long in this sort of meeting. Some would argue that’s a downside, but I wouldn’t.

While I can conceive of working in some future role where I am simply not allowed to implement this pattern, I really can’t otherwise imagine not following it. It’s just been transformative in better anchoring me in the actual work we do as engineers, rather than the “work around work” that is so much of management.