SEASON 2 - EPISODE 143 - FEBRUARY 12, 2025

Managing vs. Mentoring

There are no full-time managers at 37signals, but that doesn’t mean the company is void of mentorship. In this episode of The REWORK Podcast, host Kimberly Rhodes chats with Principal Programmer Jeffrey Hardy as he breaks down the company’s focus on peer-to-peer mentorship. They discuss hiring practices that allow for less management and what mentorship looks like amongst the team.

Watch the full video episode on YouTube

Key Takeaways

00:42 - Meet Jeffrey Hardy, Principal Programmer
02:09 - The evolution of 37signals’ management structure
05:19 - Replacing managers with mentors
10:53 - How hiring impacts the ability to operate without managers
13:35 - The power of seeking entrepreneurial experience
15:10 - A day in the life of a mentor
17:40 - Tips for being a better mentor

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. 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. Jeff, thanks for being here. Welcome back to the podcast, I should say.

Jeffrey (00:39): Thank you. Yeah.

Kimberly (00:40): 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 37signals and then we’re going to dive right into the topic.

Jeffrey (00:50): Okay. Yeah, I’ve been at 37signals for 17 years.

Kimberly (00:54): That’s crazy.

Jeffrey (00:55): 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. 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 where we landed after trying lots of experiments.

Kimberly (01:17): Okay. I have a question. 17 years. Do you know what employee number you are?

Jeffrey (01:22): I should know this. I feel like it was seven or eight. That’s the thing, when we first started, when I showed up, it was just you showed up and I showed up in our campfire room and it was like, get to work. And I started working with Jason Fried 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 37signals had even had a manager, really. David may have had a manager in a software role that he had, but 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 not necessary. And it was also freeing because it was just like, oh, it’s just us.

Kimberly (02:07): 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 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.

Jeffrey (02:28): No such thing as managers, which you kind of don’t need when you’re really small

Kimberly (02:31): When you’re seven, right?

Jeffrey (02:33): Yes. What would they even do? 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 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 thought of them as team lead roles. You can’t go to David for everything. He might not be available at that time and it’s not necessarily efficient.

Kimberly (03:16): Sure.

Jeffrey (03:17): And we sort of became team leads unofficially and then officially, and then you start to hire and you do other things and you’re like, oh, my team lead responsibilities or my management-like responsibilities are more than we wanted. 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 odd balls for not having them. And I know me personally felt like maybe there was something untapped there that we didn’t know about. Maybe 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.

Kimberly (04:21): So I imagine… 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. 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 the organization of the team goes. Are there still team leads? Are you still a team lead?

Jeffrey (04:46): Yes, sort of. But we’re also so small now, and I think that’s a feature 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.

Kimberly (04:58): And when you say shrunk, you mean without these manager exclusive roles, people who are only managing and not in the work?

Jeffrey (05:06): Correct, but also with just fewer programmers. 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.

Kimberly (05:17): And so many products

Jeffrey (05:19): So many products. And I think the secret is that there is zero overhead. There’s literally zero overhead. We are working with Jason and David directly. We ship often. We can show our work whenever we want. Everyone is extremely good at what they do. There’s a high level of trust. So that alone eliminates the need for external management. 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 is 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 mentoring. So I think there’s still a management component to mentorship, but mentorship is really more about teaching. So a more senior programmer, a highly skilled programmer on the team will mentor a less skilled programmer.

Kimberly (06:14): 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?

Jeffrey (06:24): Yes. Within 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’s less formal than I think what you would get with a manager. So when we hire someone new, whoever their mentor is will 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 taste. And part of that mentorship relationship is to teach the values that we as more senior people have learned from Jason and David. Like 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?

(07:18): So that to me is what mentorship is. So I’ll have a programmer who is, maybe they’re new, 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 when it comes time to cut scope on a feature, what can be cut? 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? 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 obsolete so that they don’t need you anymore. It has a lot of parallels to parenting. Maybe that sounds too infantilizing, but it is similar. 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

Kimberly (08:30): And you’re imparting wisdom so that they can do it on their own.

Jeffrey (08:34): 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 showing up to work, finishing your stuff on time. If there are performance problems or behavior that needs to be corrected or we don’t really have that right? Because if you’ve imparted the values correctly, people understand 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 L1. I can’t remember if we’ve ever hired anyone at… yes, we have at L1.

Kimberly (09:18): Oh really?

Jeffrey (09:19): Yes. So 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 L5, it’s not necessary. By then you are the mentor.

Kimberly (09:40): I was going to say, are L4s are mentoring or just L5s are mentoring? L4s and L5s become mentors?

Jeffrey (09:47): Correct. So I think that at that level, L2 to L3, that’s where you can really make a lot of grounding 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. They may have two different ideas of how to implement something and they need not just to pick one. I always say to people, 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 it’s going to be full of trade-offs 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 what I think of as traditional manager responsibilities, we do still do, if I’m mentoring someone, I’ll do their performance evaluation, 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.

Kimberly (10:53): Okay, 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 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?

Jeffrey (11:18): 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’re ultimately responsible for the decisions you make. We just don’t have a structure where you push that decision to a higher up who approves it. Doesn’t happen.

Kimberly (11:45): Yeah. There’s not a project manager.

Jeffrey (11:47): No, no. I mean, we have Brian, is our product manager. Manager, not in that sort of sense in managing the personality of the product. What’s on brand for us? What should we be doing? Helping to sequence and coordinate the features that we decide to add. If not now, then when? Maybe never. 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 have to validate any of those things and go through it.

Kimberly (12:22): 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’s 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.

Jeffrey (12:50): 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. This is how much we’re willing to spend. And so what you do within that is up to you and your goal is to satisfy the requirement without going too far over budget and you wouldn’t be able to get anything done in time if you 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 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.

Kimberly (13:52): You were an entrepreneur before working here too. Is that a true story?

Jeffrey (13:55): Right.

Kimberly (13:56): That’s what I thought.

Jeffrey (13:57): I remember 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. That’s kind of the instinct you’re looking for, someone that feels that maybe they’re wrong, maybe which it’s all just delusions of grandeur that we think we can do this at all, but this idea that 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.

Kimberly (14:28): And can be self-directed.

Jeffrey (14:30): Yes, you can be self-directed. You don’t mind being wrong, the decisions aren’t permanent 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. 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 thing. I mean, it might be impressive if you’ve worked at a lot of places and had lots of positions, but I’m also looking for at how high a level were you working, and 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.

Kimberly (15:10): 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 product?

Jeffrey (15:24): 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. 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 minor corrections, but it’s not going to need re-architecture. Below that, it may well need to be re-architected. It may be the wrong approach. 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, oh, I like to do it like this because what I find is, or 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 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.

(16:31): It won’t always be great. I write a whole bunch of stinkers, I’m sure, 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 their actions and the things they do and sort of giving advice that they’ll be able to use. It’s not tactical, it’s not like do these individual things. It’s like,

(16:56): No, here’s how you have to think. In a way, it’s teaching someone how to think. If this weren’t being reviewed, which we expect that it won’t be reviewed eventually, what would you do? How would you go about this? 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? And when you see that not happening, that’s a chance to redirect and to say like, ah, see this is good. What you’ve made here is good, but we probably don’t need it. Or 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.

Kimberly (17:40): 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 better mentor. I mean you’ve been doing this for 17 years here, mentoring people on the programming team. Give me a tip for them. What is something that you’ve learned over time or would say you should never do this as you’re trying to mentor someone who’s more junior? Any takeaways?

Jeffrey (18:07): I think one thing that I really like doing is we do pull request reviews a lot, and that’s sort of the main conduit for this information, is to do it live, to have a Zoom 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, oh, what am I supposed to do to get this right? And that’s where I’m like, oh, I might’ve been wrong. I could write a whole great code suggestion that’s accurate or solves 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.

(18:52): 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 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 much more space to explain the why, because I think that’s really what you’re trying to convey is why. There’s no answers, there’s no hard answers, there’s just different competing values and tradeoffs, 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 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.

(19:47): If something’s hard to come by, sometimes it’s not even worth doing. That’s another thing is when is it too much? When are you just trying too hard? And that’s not what we want. That’s super hard to do just 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? 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 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 why you value certain patterns over others or why you think things should be layered in the way that they’re layered.

(20:45): And some people disagree. It’s software, everyone will disagree with something. But for us, I think that that works really well because we are sort of that artistic side of software development, 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. 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 a manager and nothing else. But for us, we found that the things that 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 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 all L5, and we basically have that.

Kimberly (22:08): I mean, we have a very high level of programmer here.

Jeffrey (22:12): 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. 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. 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 are able to make decisions on their own, you can get a lot done really, really fast. And that’s the rewarding thing. It’s totally a superpower to be able to do so much with so little.

Kimberly (23:11): What do you find rewarding about being a mentor?

Jeffrey (23:14): 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 for me, I’m like, I don’t know. What am I doing? I dunno what I’m doing. And then when you see that it’s effective, you see things, the work of your mentee getting praised, then you know like, oh, I guess I 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, do have reasons for my choices. They’re not arbitrary. That’s a good reminder to you’re not just winging it even though we sometimes feel like we’re winging it. No, you have a lifetime of experience and it all comes to bear on the software that you write.

Kimberly (24:01): Jeffrey, thanks for joining us. REWORK is a production of 37signals, so you can find show notes and transcripts on our website at 37signals.com/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 7 0 8 6 2 8 7 8 5 0. You can also text that number or send us an email to rework@37signals.com.