Managing vs. Mentoring
24:30 Share

Welcome to Rework, a podcast by 37signals about the better way to work and run your business. Hey!

I'm your host, Kimberly Rhodes from the 37signals team. Today I am joined by longtime employee, Jeffrey Hardy. We've said many times on the podcast, you've heard Jason and David say that we don't have full-time managers at 37signals, but I started thinking we must have something when it comes to the programming side. And that led me to this idea of mentorship. So Jeff is here to join me today to talk about the differences as we perceive them about managing versus mentoring.

mentoring. Jeff, thanks for being here. Welcome back to the podcast, I should say. Thank you. Yeah. Well, before we jump right in, tell me a little bit. I know you've been at the company for a really long time. Tell us a little bit about your tenure here at 37 Signals, and then we're going to dive right into the topic.

Okay. Yeah. I've been at 37 Signals for 17 years and I've been a programmer. I know, right? I've been a programmer on the product team the entire time. So working on all our products, features, things like that. And yeah, so I have a good sense of how we've managed or how we've treated like management and what management is and the arc that it's taken. And it gives

you know, where we landed after trying lots of experiments. Okay. I have a question. 17 years. Do you know what employee number you are? I should know this. I feel like it was seven or eight. Yeah. It was, that's the thing when we first started,

When I showed up, it was just you show up. And I showed up in our campfire room and was like, get to work. And I started working with Jason Freed immediately on a project. And at that time, we didn't have any sense of managers. I doubt I know that nobody that I worked with at the time, nobody at 37 Signals had even had a manager, really. David may have had a manager in like a software role that he had.

But like managers, it wasn't really a thing. And we were very much of the mind that, no, you're a manager of one. You're there because you already know how to manage yourself. And it was,

It was not necessary. And it was also freeing because it was just like, oh, it's just us. But you've seen the company grow over time from what, seven employees to now we're at about 60. And the company has gone through kind of different iterations of management. Kind of talk me through that, what you've seen over the years and where we've landed now. And then we'll kind of dive into mentorship versus management.

Yeah. No such thing as managers, which you kind of don't need when you're really small anyway. Right. Yes. Like what would they even do? Like, actually, I shouldn't say that. Jason and David were the managers. And I think even today, that's their role, right? They're setting the tone. They're setting the values for the whole company. And we reported directly to them. And I mean, I still report directly to David. And that's how it's been my entire career here.

But I think, you know, as we started to grow and you get more and more people, you need some amount of coordination. And so what ended up happening was that people like me and another colleague that's been here a long time, Jeremy, we sort of fell into management-like roles. But we sort of thought of them as like team lead roles. Like, you know, you can't go to David for everything. He might not be available at that time and it's not necessarily efficient. Sure. And so we sort of became team.

Team leads like unofficially and then officially. And then you start to hire and you do other things and you're like, oh, you know, my team lead responsibilities or my management like responsibilities are more than we wanted. You know, right. We still prefer to do the work to be the individual contributors on the team.

And so we started to think maybe everybody could go back to being individual contributors if you had actual managers. And it seemed like everyone else in the industry had actual managers and that we were the oddballs for not having them. And I know me personally felt like maybe there was something untapped there that we didn't know about, you know, like maybe, you know,

Having actual managers to coordinate these things, to look at people's career progression, maybe that was going to be better all around. And so I guess almost four years ago now, we decided to try that and.

Now we're back to having no managers. So that was sort of the result of the experiment. So I imagine, like when I was thinking about this, I'm like, I know we say no managers, but on the programming side, I would imagine that there's something else. Like it's not everyone just doing their own thing. There has to be some sort of coordination on your side. So kind of tell me how that works as far as like the organization of the team goes. Yeah.

Are there still team leads? Like, are you still a team lead? Yes, sort of. But we're also so small now. And I think that's a feature. Like, that's not a bug. One thing we realized is that as we shrunk, we can still get as much or maybe even more done. And when you say shrunk, you mean without these manager exclusive roles, people who are only managing and not like in the work? Correct. But also with just fewer programmers.

You know, we're down to a small handful now. And it's kind of amazing, especially when I talk to other people, that we can get as much done as we do with so few people. And so many products. So many products. And I think the secret is that there is zero overhead. Like there's literally zero overhead. We're working with Jason and David directly. We ship often. We can like show our work whenever we want. Everyone is extremely patient.

good at what they do. There's a high level of trust. So that alone eliminates the need for external management. Like you just have a sense of what your team is like and what your team is capable of and you trust everyone on it. But it's true that we do need to, you can't just show up anymore. We're too big. You can't just show up and figure it out all on your own. And so what we've replaced managers with

is mentorship, what we call like mentoring. So I think there's still a management, you know, component to mentorship, but mentorship is really more about teaching. Like, so a more senior programmer, a highly skilled programmer on the team will mentor a less skilled programmer. Let me ask you this. Is that something that is assigned from day one? Meaning a new person comes in and they immediately know who they're assigned to as their mentor?

Yes, within like a day or two. I don't know if we're coordinated enough to have it lined up in advance. Actually, we do. We have it lined up in advance. But it is sort of, you know, it's less formal than I think what you would get with a manager. You know, like so when we hire someone new, whoever their mentor is, we'll sit down and they'll have a one on one and they'll just sort of introduce them to the team and they'll establish what the mentorship role is like. What is this about? And I think it's really about teaching.

That's actually what it is. It's teaching. In order to be as small as we are and as efficient as we are, we have to have similar values and tastes.

And part of that mentorship relationship is to teach the values that we as more senior people have learned from Jason and David. What are our values when we're building products and what are 37signals core values and how can we teach them and how can we help people to make decisions that are consistent with those values? So that to me is what mentorship is.

So I'll have a programmer who is maybe they're new, maybe I mean, they're new to the company, but maybe they haven't been programming very long. I think it takes a lifetime to learn how to write software. Well, I'm not done. I'll never be done. But it's imparting all those lessons you've learned along the way, how to think about something, how to make decisions, what to value. Oh, you know, like when it comes time to like cut scope on a feature, like what can be cut?

You know, what's fair game to cut? And I think that when you internalize and know those things, you don't need to double check it with someone else. I don't need to go to Jason and say, hey, is this okay? Like he trusts me to make the decision and it'll be consistent with his values, with the company values. And so you're trying to teach that. You're trying to make your role as a mentor like obsolete so that they don't need you anymore. It has a lot of parallels to parenting.

Right. Maybe that sounds too infantilizing, but it is similar. You know, like you can't force your children to do things. You hope that when you're not around, they'll make good decisions that are consistent with the values you've taught them. And you're like imparting wisdom so that they can do it on their own.

Exactly. You're trying to impart that wisdom, that hard-earned wisdom that you have and you hope it's valuable. And I think that the big difference between that and what I think of as management is that it's not really concerned with all the hygiene factors of like showing up to work, focusing.

finishing your stuff on time. If there are performance problems or like behavior that needs to be corrected or like, we don't really have that, right? Because if you've imparted the values correctly, people understand, you know, like what's consistent. They don't need that sort of external rubric-like validation. I mean, we still do have levels. I'm a principal programmer. So that's L5. That's our top level. And we start at L1.

I can't remember if we've ever hired anyone at, yes, we have at L1. Oh, really? Yes. So like that's junior programmer. More typical is L2.

And then L3 is senior. So I think that's the most fertile ground for mentorship is that L2 to L3 transition. It's true that if you're in L3, you still have a mentor. But by the time you're at L4 and 5, it's not necessary. By then you are the mentor. I was going to say, are L4s mentoring or just L5s are mentoring? L4s and 5s become mentors. Correct. Correct.

So I think that, you know, at that level, L2 to L3, that's where you can, you know, really make a lot of ground in mentoring. These are people that are already very skilled. They know what they're doing. They don't need constant oversight, but they need advice. You know, they may have two different ideas of how to implement something and they need not just to pick one. I always say to people, like, I'm not going to tell you what to do.

I'm just going to tell you what I might do and then acknowledge that like it's going to be full of tradeoffs. And by the time I actually go to do it, I might change my mind and not do it like this at all. That's why you have to be equipped with a value system that helps you make those decisions. In terms of like what I think of as traditional manager responsibilities, we do still do like, you know, if I'm mentoring someone, I'll do their performance evaluation, right, which we do yearly.

And we have a rubric and it's fairly small and it's fairly high level and filling that out and presenting that. But it ultimately report to the CTO, which is David. And there's nobody whose full time job it is to manage on the programming team. OK, so let me ask you this, Jeffrey, because.

I think a lot of people hear us say managers of one, and we don't have a lot of people who are managing, like just hearing that as a company philosophy and don't understand it. I think part of it comes down to hiring. So my question to you is what kind of things do we have to keep in mind as we're bringing people on so that it works within this structure?

First of all, it's super hard. I find hiring super hard because you're not just looking for someone that has a specific set of skills. You also have to have, like I said, shared values. It needs to be someone who will be able to work well with a bunch of uncertainty and knowing where they're going to be making the decisions. You know, you're ultimately responsible for the decisions you make. We just don't have a structure where you like push that decision to a higher up who approves it.

doesn't happen. Yeah. There's not a project manager. No, no. I mean, we have Brian is our, you know, like product manager and manager, not in like that sort of sense in managing like the, the personality of the product what's on brand for us, what should we be doing? Like helping to sequence and coordinate the features that we decide to add. Like if not now, then when maybe never like those sorts of things.

But you make thousands of little decisions when working on the product or on a feature. And we just don't have a structure where you would have to validate any of those things and go through it. Actually, what I was just thinking is interesting is because we use the whole shape up methodology and there's lots of trimming of scope.

It does seem like it's even more important that the people on the team, the designer, the programmer are independent enough to make those decisions because it is not a the deadline is going to push. It's like, what are you going to trim back? And they're making those decisions. I think that's probably a little less common in other organizations.

Yeah, that's exactly it. I don't even know how it would work if you don't have a variable scope. So we do the thing where we say it's a fixed deadline, fixed-ish. I mean, we're still making a guess about, we think this should take two weeks or it should take three weeks. And

To me, that sets the value of the feature. Like this is how much we're willing to spend. And so like what you do within that is up to you. And your goal is to like satisfy the requirement without going too far over budget, you know, and you wouldn't be able to get anything done in time if you, you know, needed a whole bunch of steps in order to do that. So yeah, you need to be able to trust that people on their own will make decisions that are consistent with the product, that they're going to produce really high quality stuff

back to like what you're looking for when you're hiring.

I look for people that are entrepreneurs, maybe people that have run their own business, people that have demonstrated that they can do this on their own. They built a whole product on their own. They organize things. They're self-starters. You were an entrepreneur before working here, too. Is that a true story? Right. That's what I thought. I remember, yeah, when I dropped out of university and started my own web design business. But the idea was I was like, I can't think of where to get a job, so I'll just make myself a job. Yeah.

that's kind of the instinct you're looking for, right? Someone that feels that maybe they're wrong, maybe it's all just delusions of grandeur that we think we can do this at all. But this idea that like, no, I've got this, I can do this on my own. And it doesn't mean you're not a team player. It's far from that. It's just that you're willing to take on all the responsibility. That doesn't scare you. And can be self-directed. Yes, you can be self-directed. You don't mind being wrong. The decisions aren't permanent.

you know, and you make them and you move on and you iterate, you iterate over and over again. I mean, this is what Jason and David learned and did, right? They started the business. And so you have people that are also like, hey, I could do that. And you're working with like-minded people to do the same things. I mean, it might be impressive if you've worked at a lot of places and had lots of, you know, positions, but I'm also looking for like,

Like at how high a level were you working and like how much were you being told what to do in these roles versus how much was self-directed? People that can direct themselves, that's really what we're looking for. And those are the folks who thrive. Okay, so then tell me a little bit about your view of your role as a mentor. Is much of it getting someone to make the right decisions, giving them the skills so that they make the right decisions about the products?

Yeah, I think so. So one way that we do this a lot is via pull requests on GitHub.

So we'll have the code and there'll be a change and we'll look at it and we'll talk it through, you know, so here's sort of like an implementation. It may not be the final one. It's usually not the final one. I think that's what differentiates less than senior from senior. At senior level, we expect that your implementation is going to be pretty good. It may need like minor corrections, but it's not going to need rearchitecture. Below that, it may well need to be rearchitected. It may be the wrong approach.

Like the last thing you want to do is say, do it like this or write the code and be like, here, make it like this. You want to explain why you think it should be changed. And that's your opportunity to teach, to say like, oh, you know, I like to do it like this because what I find is or, you know, trying to give advice based on what you've learned, but still not telling anyone what to do.

I never want to tell anyone what to do because I don't know what I'm going to do until like the moment I'm doing it. And so to work with someone like that, you just need to trust that the work they produce tends to be good. Yeah. It won't always be great. I write a whole bunch of stinkers, I'm sure. But.

But on the whole, it's consistent with what David and Jason value. And so I think that's what mentorship to me is. It's sort of reviewing code with somebody, reviewing like their actions and the things they do and sort of giving advice that

They'll be able to use. It's not tactical, right? It's not like do these individual things. It's like, no, here's how you have to think. In a way, it's like teaching someone how to think. If this weren't being reviewed, which we expect that it won't be reviewed eventually, it's

What would you do? How would you go about this? You know, does this seem like proportionate? Did you cut the right things? Did you focus on things that weren't important? Did you find the epicenter of the design and work out from that, you know? And when you see that not happening, that's a chance to redirect, right? And to say like, ah, see, like, this is good. What you've made here is good, but we probably don't need it.

Or, you know, you could have put that effort over here instead. So I think that by showing those examples and talking people through it, they get a sense of how to make those decisions, essentially. Okay, Jeff, last question for you before we wrap it up. If someone who's listening is like, yes, I would love a tip on how to be a better mentor. I mean, you've been doing this for 17 years here, mentoring people on the programming team.

Give me like a tip for them. What is something that you've like learned over time or would say you should never do this as you're trying to mentor someone who's more junior? Any takeaways? I think one thing that I really like doing is we do pull request reviews a lot. Right. And that's that's sort of the main conduit for this information is to do it live.

to have like a Zoom, you know, one-on-one and you're both looking at the code and you're going through it. There's a lot you can say in a comment on a GitHub code review and you should still do that. But there's also a lot of room for those things to be misunderstood or for someone to jump immediately to the answer, right? Like, oh, what am I supposed to do to get this right? And that's where I'm like, oh, like I might've been wrong. I could write a whole great code suggestion that's like abstracted

accurate or solve some problem, but it's not the right problem. And the last thing you want is someone to just duplicate that and be like, well, Jeff told me so. It's not that. Everybody's wrong about stuff. It's a feeling. It's subjective. It's hard to quantify.

And you can do that a lot better in person. You sort of look at the code and you say like, ah, you see here, you know what, let's try doing it like this. Or you have like much more space to explain the why. Because I think that's really what you're trying to convey, right? It's like, why? There's no answers. There's no hard answers. There's just different competing values and trade-offs.

and you want to find the things that have the most leverage. That's really what we try to go for. That's why I think we're successful as a small team. We try to find like these super high value things that are low effort or that we've made them low effort. Like we've optimized the right things so that these high value things are easy. They should be easy. It should feel easy. It should feel natural. If there's friction,

Something's wrong. You know, if it's something's hard to come by, it's something it's like not even worth doing. That's another thing is like, when is it too much? Like, when are you just trying too hard? And like, that's not what we want. That's super hard to do just like by writing comments. I mean, you'd have to write a book, but it's sort of easy to do in person.

Right. Because you can expand on what you're saying. There is no, like I said, right answer. So you're just sort of finding the right spot and being like, this is good. I imagine it's not unlike being an editor reviewing creative written work. Right. There's no like, oh, I'll check my answers at the back of the book and you've got this right. It's like, no, this this is creating a certain feeling or this feels right.

And that's what you can do, I think, live. So I think for mentoring, it really is about those one-on-one conversations, whether you're reviewing code, like actual code, or you're just talking about software architecture and like why you value certain patterns over others or why you think things should be layered in the way that they're layered. And some people will disagree. Like it's software. Everyone will disagree with something. But for us, I think that that works really well because we are sort of that group

artistic side of software development, you know, less than scientific. I know at a certain size of a company, you're going to need managers. It just wouldn't be possible for us to even be a hundred person company and not have some dedicated managers. I think that would be really difficult. And some companies are much, much bigger than ours. They have thousands or hundreds of developers. Right.

I don't think that a pure mentorship based system is necessarily going to work there. I think it can be a great component though. I don't think it's just, you know, a manager and nothing else. But for us, we found that the things that like having a dedicated manager who isn't close to the work, who isn't able to do the work themselves creates too much indirection and it's just much more efficient and satisfying to

when everybody that you're working with is also able to do it. You all understand, you're all makers and there's nobody

that's at a different level or layer than you. So even when we're at different skill levels, we're all still on the same team and we're all shooting for the same goal. And we're hoping that everybody levels up. Ideally, we want to be a company of like all L5s. And we basically have that. I mean, we have a very high level of programmer here. Yeah.

Yes, that's the thing we have to remember. So there are very few of us, but everybody is very, very highly skilled. We've experimented with internships. They've been good. We've even hired interns in some cases. And we've had junior programmers all the way up to hiring at senior. We've hired people that are definitely higher than senior level, but we haven't hired them at any level higher than senior. Yeah.

That's sort of a level you have to prove on the team because it's not necessarily going to apply from across companies. I think what we call senior is maybe what people call lead at other companies. Like, I think that our levels are also slightly skewed. And I think that when you have really, really skilled people who are managers of one who are super motivated and don't, you know, are able to make decisions on their own, you can get a lot done really, really fast.

Yeah. And that's the rewarding thing. It's totally a superpower, right? To be able to do so much with so little. What do you find rewarding about being a mentor?

For me, the rewarding part is when you see it work, when you see these ideas take hold, it reminds you that you know what you're doing. I think like for me, I'm like, I don't know what, what am I doing? I don't know what I'm doing. And then when you see that it's effective, right, you see things, you know, the work of your mentee getting praised.

then you know, like, oh, I guess it did have something to say. And I think that just that act of being a mentor, it reminds me that like, oh no, I do have heuristics that I apply. I do have like reasons for my choices. They're not arbitrary. That's a good reminder to, you know, you're not just winging it, even though we sometimes feel like we're winging it. No, you have like a lifetime of experience and it all comes to bear on the software that you write.

Jeffrey, thanks for joining us. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com slash podcast. Full video episodes are on YouTube. And again, if you have a question for Jason or David or Jeffrey about a better way to work and run your business, leave us a voicemail at 708-628-7850. You can also text that number or send us an email to rework at 37signals.com.