Presentation: Engineering Engineering Culture With Memes

I'm co-founder and COO of FullStory in Atlanta.

When we were really small, to the order of 10 - 20 people, I was able to play the role of the only engineering manager in the whole company - but as we've grown I’ve found that I can't really do a good job with that anymore, plus do all the other things I have to do.

As I’ve had to let it go from being super close to the team, I find that there are certain concepts and patterns of working that I really want to make sure continue to be part of the team's thinking.

A lot of forward-thinking companies with engineering managers and light-touch tech leads know they need to reach certain outcomes, but they don’t necessarily want to be breathing down people's necks - they want to create autonomy within the team. Of course, it’s still true that there are better and worse ways of approaching things relative to your company's goals and instilling the culture on new employees - and that’s really what my talk is going to be about.

When your team is really small, it's easy to keep everybody on the same page because you can sit around the same lunch table and talk about what’s going on, ideas and such. As a manager, a small team is easier to work with - especially if you're a communicative, energetic person. You can almost just sort of will things to be a certain way, and just through your own exuberance, everybody picks up on that vibe and it just sort of magically happens. When you have eight to 10 people, that approach works.

...but as your team grows into dozens of people and beyond, you need a different set of tools - you can't rely on personal relationships, personal conversations and face time. Nor do you really want to micromanage people. What you want to do is try to get the same kinds of outcomes that would have happened if you sat around the lunch table every day. And so the real trick is to take the locus of control from yourself, and push it out into the abstract so other people can then internalize for themselves. Thereby the culture that you care about - and the memes that you care about - allow people to take them on as their own. You're still influencing, but you're doing it by having deposited that DNA across the people in your organization already.

I'd say the motivating theme here is you have to externalize the concepts that as a manager you want to convey, so that you can frame the day to day work not as "are you making me - the manager - happy"? or "are you doing what I believe you should do"?, but rather articulating shared beliefs and goals for the team so they are empowered to make good decisions autonomously.

Then we can ask: “are we all serving our goals”? The best way to do that is to create and articulate memes explicitly. You don't want a situation in which everybody needs to look to the manager to see what the right next thing to do is - you want good ideas to bubble up.

Here’s an example. Engineers tend to be super analytical that often leads useful skepticism, but it also creates a sense of wanting to play devil's advocate and debate pretty often. Day to day, people in the company will have fledgeling baby ideas that sound crazy. Some of the most innovative ideas sound really crazy or even stupid on day one. You can't even describe it or defend it. But you think there might be something there. I found that those ideas were routinely getting beat down over the lunch table, and the ideas never could find their legs. I have a grab bag of examples I’ll be covering that helped us overcome these issues such as Prove It meetings, the Suck Less Cycle and the Grotto.

There are a few points. Firstly, good engineering management is really hard. I think there are a lot of "management practices" that are effective in the short term, but can backfire in the long term.

A practice that seems good in an obvious way, may have longer term implications that are not so obvious. That can happen on many respects in terms of being a good manager, so you could be a good manager by being a the go-to person to answer hard questions. But then you could be training people that when a hard question comes up, they can’t get it answered unless they can ask you. That’s bad.

To be the very best manager you need to find a way to have people on your team not feel the need to ask you and still do the right thing. The ideal state for a manager is to be more or less invisible. You tend to have to overthink everything–along the lines of what I'm doing right now in talking about all this– and even try to actively subjugate yourself at every opportunity. If you're not, you might accidentally be putting yourself up as the hero of the team, and that suddenly undermines people. You have to be careful not to treat engineers as cogs instead of the multi-faceted people that they really are.

Management and leadership ultimately are different things. They can overlap but it's different skill sets. And I want to make sure that as an industry that we're not accidentally conflating them so you know if we talk about them separately I feel like we can perfect each and then we can talk about how they relate to each other and where they overlap where they don't.

That one is easy and it should be the same answer for everybody: security. A close second is just the general quality of user experience in software, but that’s more directly tractable. The nature of security as a problem is that there's lots of aspects to it, but the leverage on a security problem is so asymmetric - and that is the scary thing. All it takes is one little oversight and lots of problems can happen. It’s like whack-a-mole times a million. The best security minds, security teams, and security-minded companies create layers to minimize that. But there's no such thing as like a unit test to prove you're secure.