Avoiding the All-Senior Trap, Part 2 With Charity Majors

This week, we’re diving into part two of our conversation with Charity Majors.

Charity is the CTO at Honeycomb, a company that builds observability for distributed systems. Charity’s team is on a mission to make monitoring less cumbersome so that being on-call can suck less.

In this episode, we discuss:

1. How to hire the right seniority mix for your team
2. How to see everyone at their best, both when they’re interviewing for a job and once they’ve started.

Listen to the full episode here.

[When you’re going through the hiring process] what format does the “here’s what we’re looking for” [feedback] come for you?

Well, code matters, right? So our actual interview process is, we give people the code sample the night before – we aim for it to take no more than an hour or two of their time – and we tell them to just stop coding [after a set amount of time]. Just however far you get is fine, it’s impossible to do the whole thing. We just want an hour or two of your time. Get as far as you can get.

And then the actual interview process consists of you coming in the next day and talking us through your code, doing like a code review process, because we want to hear what you were thinking – what you thought about trying, ruled out, and why. We just want to have a conversation about it so we can hear how you think about the code, because how you write the code is really secondary to that. [How you write code is] so dependent on what you’re familiar with, what’s paged to your brain, what you know – but how a person thinks about code and can talk about it, that’s what actually matters.

And for us we are privileged in the ability to talk through code. Some people are only really good at writing through code – but we do also try and give time for them to communicate in their preferred medium. If that’s chat, or if that’s pairing, etc. – whatever shows them at their best, we’re open to doing it to accommodate them.

‍

What step is this in the interview process?

This is step two. Step one is just a small coding sample that we send out – it’s really just like all right, are you this tall to ride this ride?

But we found that we can actually…. we can sense quite a bit from that small coding sample. Are they familiar with this platform? Are they idiomatic? That isn’t really what we judge them on because we know it’s not enough to judge, but it gives us a feel for them.

And then we’ll bring in people for an actual interview, and we’ll give them the take home the night before. Then we do an architecture talk with a whiteboard and they’re just brainstorming some stuff. If it’s front end then we do a user feedback session, where we see what kinds of questions they ask; how they try and draw things out, and how they listen. The entire time, of course, we’re looking for the social cues like, do they talk to women like their technical equals? Do they treat people with respect? Just the basics that you actually really care about a lot.

I don’t think that our interviewing process is easy, but I do think it is technically easier – the bar that we care about is much more about how you think and how you communicate, because we believe that the technical minutia is learnable.

‍

You said easier – I’m assuming you’re comparing that to like Facebook, or Google algorithmic challenges?

Yes absolutely. We’re not going to give you the super deep hard systems problems that they give – which even they, by the way, admit there’s no correlation between how well somebody does at Google and how well they do on those questions. They’re bullshit questions, but [those questions are] a bar that lets them feel really good about themselves.

‍

Yeah… one of the opinions I struggle with is, why don’t you just talk to everybody and then hire the people that are smartest?

Right. [Laughs]

‍

And I don’t know where to start on that… because I hate credentials. I think they’re nonsense. Like you said, the tech is learnable. But I don’t know how to respond to that.

How do you define best? Because the answer to that question answers everything, and no two people will have the same opinion. And as a startup, we are selecting for things that are somewhat different than at a mid- or large-sized company. So we can hire individuals.

And once you’re the size of like a Pinterest… you’re hiring engineers you want to be plug-and-play all over the organization, so they can move around; you can play Jenga with people…

We – for better or for worse, for better and for worse – are hiring individuals, so we can select for a different basket of attributes, and… given our connections and history in the Valley, we could have just hired a “rock star lineup” of super senior engineers who just create code all day. And we did not want to do that.

In fact, we did not want to hire people who we had all worked with before, because we’re building a tool that’s not just for ex-Google and Facebook engineers – we’re building a tool that we want everyone to use. We want it to be tracked, and we want it to be approachable. We need those eyes in the house with us, testing it every day.

And I’ll confess – this a little bit of an embarrassing story – but when we decided to do that I was like, “Man, I really would love to give these engineers the experience that I’ve had” where I’m so proud to have worked in these teams – it was super high performing… I was saying with my mouth that the best teams are the ones that have diverse [experience] levels and all these things, [but] not really believing it in my heart.

But we went out and hired this team – some people who had come out of hacker academies, and intermediate folks, and people who were clearly not super senior… and it is the most high performing team that I’ve ever witnessed, because it is a team that listens and collaborates well, learns from their mistakes, learns from each other’s mistakes, and doesn’t repeat mistakes. They’re incredibly empathetic and they ship like a motherfucker consistently.

I have never seen a team perform so consistently and so well – it’s blown me away. It really has. And I feel a little bit sheepish about myself in retrospect – that I doubted this was true. It is true.

 

‍

What’s your ratio for –  let’s call it junior, mid, and senior developers?

We’ve got two very senior engineers out of eight… [everyone else is] mostly intermediate to senior-ish by now. But like, when they joined they weren’t – like we had two people for whom this was their second job, both out of hacker academies. One it was his first job… and they’ve all grown by leaps and bounds over the last couple of years…

And it took them awhile to find their feet; it took them a lot to learn our stack. They didn’t come in knowing GoLand or anything, so it took them six months or so to skill up. And we have an amazing manager – Emily is just an amazing manager and mentor. She’s a director now, but she is on them. She’s in the code reviews, and she did a good job of helping them all level up. But like fuck they’re an amazingly high performing team.

And I look at sort of like, if they were a team of senior people it would not be as high performing,  because for every senior person, it’s boring to them to do the thing that they’ve done like 10 times – implement another web offer or whatever. You’ve got junior people like, “Oh yeah! This is exciting. This is fun. This is cool!” And for the senior people, they need people to teach, they need to be able to mentor and they need to be able to flex those muscles.

When you’ve got a team of just senior people it’s like having a meal of just desserts. You actually need the full range of flavors for everyone to be on top of their game, and working on a team of people who are inspired and learning things is what inspires you and keeps you excited. You don’t want a team of all senior people,

‍

And if you had to put on a ratio to it, what’s the ratio where stuff starts to break?

I think that thirds is decent, but honestly one or two senior people per team is great, the rest can be junior – especially if you have a highly technical manager like we do who could do a lot of the coaching, then you just need a couple of people to really light the path. It also depends on the type of senior people that you have, though, because some senior archetypes –  they’re not happy if they aren’t down deep doing the hardest problems, cranking code themselves.

Now, spoiler alert, most of the problems we have in tech are not hard problems. There’s a lot of things that just need to be built, features need to get shipped…

‍

Got to add SSO again.

Exactly! Exactly. So like, depending on the product you’re building, depending on the seniors you have – some senior people, they’re so done with building all that stuff and they really just want to mentor and do architecture, and occasionally go in and help with the thing. So you have to know which kinds of seniors you have, and I think we have a mix – we have a couple of guys who are just like they want to go deep in the code and maybe do some architecture. And then we have one that’s just kind of done with that and functions more as a manager who occasionally builds things, and that’s great!

It’s very individual at our stage, whereas at Pinterest levels and above, they’re much more [built like] recipes where they’re like, okay we’re going to assemble a team using these building blocks. This is why I love startups, because I love the unique and individual baskets.

‍

The most common objection I hear- I think most people intellectually believe that, but then they look at their roadmap, [and say] “Okay I’ve got this deadline, four months out I’ve got one headcount.” And the term I hear is “Hit the ground running.”

If you have one spot, then yes, you should start with a senior engineer. But one headcount is different from one spot, right? One headcount to me says that you have a team already, and you have one that you can hire.

And the temptation is always going to be to hire the most senior person you can get to take that salary, which is why you need to lean against those impulses. You need to look at who you’ve got, and you need to build a team with a team in mind – not just take each headcount one at a time. You need to have a plan.

And as a founder I’m super sympathetic to this because sometimes when you’re building your horizon, your lifetime is six months long. That’s as long as you’ve got until you run out of money, and whatever you do in that time to get yourself over that hurdle – you’ll do what you have to do. I’ve had to make some very hard calls like that.

But most of the time, the goal is to not be operating in that mindset – the goal is to have a horizon of a year or two. And if you’re building for a year or two you assemble a very different team than if you’re building for six months.

‍

 

What’s a belief about leading software teams that younger Charity would have strongly disagreed with?

That they were necessary, honestly.

I am very anti-hierarchy. I have chafed against every manager I’ve ever had, and I’ve seen them mostly as useless – and I would not say that I’ve ever actually had any good managers, personally, but I’ve now seen the difference that having a good manager makes in a team, and that it’s not so much about hierarchy as it is [about] cohesion.

To have a cohesive team you have to have leadership, and in my mind I try to invert the hierarchy, so that the leader is always underneath, supporting everyone – that’s how I can make it work. But the difference between teams that are on point, and teams that are just kind of wandering in the wilderness has everything to do with leadership.

‍

When you’re interviewing a leader potential leader have you hired any leaders from the outside into your team?

Yeah.

How do you approach that?

I look for that “servant mindset” of not wanting to be out in front, but wanting to be there supporting.

Emily is such a great example, she is so psyched about the most boring ass things, like the skills ladder for leveling, and for a pay bracket. And… my eyes are glazing over as soon as you start talking about this stuff – or like, the onboarding process for new engineers. Her eyes just light up… which is what you want because you want your managers to care about this structure that the other engineers are living their lives based on…

You want someone who’s looking at the shape of how organizations actually work, and who sees their role as just to enable and empower.

And what you don’t want is to take senior engineers who want to keep being tech leads, you don’t make those people the manager because you’re going to starve the team of oxygen for growth, because they’re going to want to keep hoarding and doing the hardest problems themselves.

Instead, it should be their job to offload those problems onto other engineers, so that those other engineers get to use them as an opportunity for growth. If what the person wants is to keep growing technically, they cannot manage people – because you only have so much bandwidth for growth and either you’re growing as a manager who can be interrupted at any moment; who’s first and foremost job is to make sure every single person is supported and thriving.

Or your one job is the tech, and your job is to go heads down and not be interrupted and not be bothered with everyone else’s feelings and lives and needs. And those two are just in fundamental tension.

‍

My guest today has been Charity Majors. Charity, thank you for being on Scaling Software Teams.

‍

Thank you so much for having me. This has been really fun.

‍