Welcome to Rework, a podcast by 37 Signals about the better way to work and run your business. I'm your host, Kimberly Rhodes from the 37 Signals team. Today, I am joined by longtime employee, Jeffrey Hardy. We said many... times on the podcast, you've heard Jason and David say that we don't have full-time managers at 37 Signals, 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. 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 37signals, and then we're going to dive right into the topic.
Okay. Yeah. I've been at 37signals 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, 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. 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. 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 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 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? 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 sort of thought of them as like...
team lead roles. Like, you know, you can't go to David for everything. He's might not be available at that time and it's not necessarily efficient. Sure. And so we sort of became team leads like 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 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.
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. 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. 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. 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. 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'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 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.
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. So that to me is what mentorship is. And 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 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, 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. the values correctly, people understand 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 L5, 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. So I think that, you know, at that level, L2 to L3, that's where you can 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 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 ultimately report to the CTO, which is David. And there's nobody whose full-time job it is to manage.
on the programming team. 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, like just hearing that as a company philosophy. 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.
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'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. 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. 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 product? 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 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. It won't always be great. I write a whole bunch of...
dinkers, 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 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.
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?
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 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 and that's where i'm like oh like i might have been wrong i could write a whole great code suggestion that's like 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. You know, 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, bye. writing comments. I mean, you 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 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. And some people will 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, 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 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. 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 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 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. 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.