/How do you structure your day as a leader? Favorite leadership books? CTO of Basecamp and Creator of Ruby on Rails, David, shares his answer to these questions and more.
What kind of leader is David Heinemeier Hansson? We were lucky enough to find out his management style, leadership lessons learned, and more during our most recent Watercooler AMA with him.
For many of us, David needs little introduction. Not only has David bootstrapped Basecamp into a company with million dollar annual profits with only 50 people located remotely all over the world, he invented a wildly popular web framework that Airbnb, Twitter, Shopify, Square and hundreds of thousands of companies are built on (including ours at Know Your Team). Oh, and he’s a NY Times best-selling author and Le Mans class-winning racing driver, to boot.
Wondering how David does it all? Or if he might have a perspective on an issue you’re facing in your company? Well, we’ve got some of those insights in this AMA he did for The Watercooler, our online leadership community.
We’re honored to have David as a member of The Watercooler, along with 400 other business owners, executives, and managers.
Read the entire AMA below on his leadership lessons learned (and join him over at The Watercooler to participate in our next AMA)…
Question #1
What systems has Basecamp used successfully to ensure employee accountability while maintaining equity and sustainability? Is it all about hiring, or are there systems you’ve put in place to ensure everyone is performing at their peak?
DHH: Good question. I think it’s something a lot of business owners and managers worry about, especially when it comes to remote work.
At Basecamp, our approach starts with the culture. We assume that people are here to do the best work they know how. If that’s not happening, it’s unlikely that’s because they’re lazy or dumb or ill-willed.
It’s more likely that it’s either because they don’t have the skills and maybe are afraid to ask. We can help fix that with mentorship and encouragement. It may also because there’s something else going on temporarily in their personal life. If so, we give the space and understanding that we would like if it was our situation.
On top of that culture, we have a number of processes that help bring evaluation of the work itself on a regular basis. We use Basecamp to ask everyone on a daily basis: “What did you work on today?”. That question has a way of ferreting out issues pretty quick. Either because someone might stop answering it for a while or because the answers are anemic. That’s a trend you can pick up on after observing answers over a few weeks.
The other element is that we work in short 6-week cycles and it’s pretty clear what a reasonable pace looks like. So if things aren’t getting done. If projects aren’t wrapping within the cycle, well, then we investigate.
We also have small teams. If you work on a team with 1 designer and 2 programmers, well, there’s nowhere to hide! If someone isn’t doing work at the level we’ve assessed them at, well, that’ll stand out pretty clearly to the other team members.
Finally, we now have a clear seniority structure that spells out expectations and scope for, say, a “junior programmer” or a “senior programmer” or a “lead programmer”. We’ve codified the responsibilities that each such level warrants. If someone is a “senior programmer”, but constantly needs someone else to drive their progress or continues to exhibit low levels of understanding, then again, there’s something to look into.
Hope these techniques are helpful!
Question #2
What’s the single most important factor in Basecamp’s success? Why did you pick that one out of a myriad of likely candidates? Why was it important?
DHH: I totally get the sentiment behind “what’s the one thing…” type of questions, but I don’t actually think it’s that helpful of a lens. The success of Basecamp comes from doing dozens, if not hundreds, of interconnected things right. Take any one principle or practice from that collection, and there’s a good chance it won’t have any discernible impact on your situation.
The fact is that different organizations and people need different things at different times to unlock their potential. That’s why our books, like REWORK and REMOTE and Getting Real and soon The Calm Company, provide a buffet of lessons and observations. Out of the, what, 80 essays in REWORK, there might just be 5 that really can change how you do things, but it’ll be a different 5 from what will help someone else.
So I try to put everything that I’ve learned and know out there. Then someone can dive through that and find the blocks that fit into the open spaces in their mind.
Question #3
You state that you have no expense policy and that you “trust employees to spend money wisely”. What experience have you had with this, have people behaved in the way you expected, or have there been some unexpected dynamics (positive or negative)?
DHH: The expense policy at Basecamp flows from the same overall culture of trust that underpins the rest of the company. We believe the people we hire are fundamentally good and want to do the right thing. We believe that if we show them trust, they will reward trust. They’ll live up to our expectations rather than down to our fears.
We’ve had this expense policy, the “spend it wisely” moniker, for over a decade. In that time I think I’ve been involved with 2 or 3 cases where I disagreed with how corporate funds were spent. And it wasn’t out of malice or deceit. It was out of a misalignment of “what’s reasonable”, and it was quickly corrected.
Imagine all the time we’ve saved in over a decade through this policy. Letting the little things slide. Taking a larger view of it. Only addressing issues if they seem like they’re representations of a larger misalignment. It’s immense.
So the overall conclusion from our end has been that this has been a monumental success. People have spent it wisely. We have shown them trust, they’ve rewarded trust. And we’ve cut out of a ton of “things that some companies do that we just don’t”.
Question #4
I’d love to learn more about your how you interview candidates. Do you have a list of questions you frequently ask? And/or do you have a list of characteristics (curious, grit, etc) that you look for in a candidate?
DHH: We’ve changed how we interview a lot of the years, but some things still carry through. For technical work, we don’t do fake gotcha work on a whiteboard or present candidates with puzzles to solve. We ask for representative work samples up front (portfolio from designers, code from programmers, writing samples from support, etc), and we use that as the basis of a human discussion about work, approach, principles, experiences, and challenges.
I do think we could stand to improve at the earlier stages in our interview process of a bit more standardization. For the last programmer position we listed, we had 400 applicants. That’s a lot to sort through, and you simply need a structure and a method to make that tolerable.
But looking back at all the hires we’ve made, I’ll sum it up as looking for “sparkle and promise”. Is there a human hook in the cover letter, or is it just a dry resume that looks like just every other resume? Is there an eagerness to learn? Is there a sparkle of future potential?
We’ve had really good success hiring junior people who’ve shown just that “sparkle and promise”. Better success than hiring senior people with a mile-long resume.
Question #5
What books/courses have had the most impact in your leadership style at Basecamp?
DHH: Some of my favorite books for leadership:
- Maverick by Ricardo Semler. This was the book that really served to give us “permission” to do a lot of things differently at Basecamp. Here’s this guy running a major industrial company with 8,000 employees, and he’s doing all sorts of unconventional stuff, and it’s working. Surely we can do it too!
- Turn The Ship Around by David Marquet. Wonderful illustration of having people live up to your high expectations rather than down to your fears. Assuming that competence is all around you, just waiting to be giving the trust to flourish.
- The Meditations by Marcus Aurelius. He was the most powerful man in Rome. Emperor of the Republic, wealthy beyond imagination. Yet his days were filled dealing with people. Subordinates, enemies, friends, politicians, warriors. The Stoic principles gave him the calm to do that job perhaps better than any emperor before or since.
- Punished By Rewards by Alfie Kohn. Management lore is full of tips and tricks on how to use incentives and other rewards to drive performance. It’s all bullshit. It does not work, at least not in the long term. Kohn deconstructs this dangerous idea with impeccable scientific rigor in domains of both employees and kids. Intrinsic motivation is really the power plant that we need to run this high level of impact that we’re all looking for.
- Drive by Daniel Pink runs along the same lines as Kohn, but wraps it in more of a business’y framework. Motivation comes from Autonomy, Mastery, Purpose. A bit repetitive and a bit stylized, but probably easier for most people to swallow than Kohn’s work.
- The Undoing Project by Michael Lewis. Half biography of two researchers, half summary of their work on human fallacies and predictable cognitive deficiencies. Kills the idea of “the rational human” and replaces it with a much more nuanced picture of a faulty human that makes mistakes in similar ways, which you can learn to identify and counter.
- An Introduction to General Systems Theory by Gerald M Weinberg. To understand organizations and systems alike, you need to be able to analyze them, examine them, study them. Gerald is a master teacher in just that.
- The Effective Executive by Peter Drucker. Full of all sorts of good tidbits, but nothing stuck more than examining how we as managers actually spend our time vs how we think we do, and what the gap between the two tells us.
- The Halo Effect by Phil Rosenzweig. We have a tendency to idolize people and companies who show success in one area and think that everything they do must be wonderful because they’re successful. Not so. The Halo effect clouds our judgment and makes us cargo cult terrible practices and traits of successful people.
Question #6
I would love to hear how you at Basecamp approach releases, communication around them. How do you release a new product within Basecamp, make sure it gets used etc?
DHH: At Basecamp our release process isn’t overly structured. We mostly decide what to build based on gut instincts, developed over two decades of making products like Basecamp. But there are a couple of pointers.
We try to use what we’re building as quickly as possible internally. That means running things on beta servers against real data, so people can use the new features in their actual workflow. Not just dummy clicking around.
Some times we will look at usage data before making a decision, but it’s not a major component for us deciding either way. We do a lot of things that has no a priori support in a data conclusion.
When we do release it, we usually write up a tale about the why, the how, and finally the what on Signal v Noise. Introducing features isn’t just about telling people about what they can do now, it’s just as much inspiring them to use it, explaining why this was important. Setting the stage.
Then after something has launched, we now do a retrospective immediately after, and then another 3–6 months later. Talk about how the project went, look for lessons in the customer reactions.
Question #7
What are the things you DON’T do, to ensure high personal growth? How do you grow and achieve in more than one area? Is it the same method for each area?
DHH: I love thinking about all the things I and we at Basecamp don’t do 😄. There’s perhaps more to learn in the negative space than there is in the positive.
One of the things I don’t do is engage with any sort of physical community of developers or business people on a regular basis. Maybe part of that is just being an introvert, but I often find myself dreadfully bored at social events in technology, and I rarely find myself learning much. So that’s out.
Same goes for networking in general. I very rarely if ever agree to meet people for lunch or a drink or even get on the phone. It punctures the day and takes energy away from moving forward on the things I really care about. Again, that’s partly a luxury of our small-business focus. We don’t need to schmooze, so we don’t.
I don’t do things out of obligation, as a general rule. “We probably should” is in my book code for “we probably SHOULD NOT”.
Rather than engage with most people directly, I prefer to engage with people from the present and past via their writing and actions. I have better relationships with many ancient philosophers and writers than I do with contemporary business leaders or managers 😂.
I constantly think about how I can cut things out from my life. If I do ever less, there’ll be ever more time to focus on the very few things that truly matter to me.
Question #8
Based upon the Jim Collins’ mantra about it is more important to determine what you don’t do as opposed to what you will do, how hard was it to get all of the 37 signals team on board to say, we are dropping everything else and focusing on Basecamp?
DHH: Rodney, it’s always good to have a look at your vision and values, but I find it’s often much easier to sit down in some brainstorm session and bullshit about it rather than actually living it. The hard part isn’t deciding, it’s doing.
At Basecamp, we don’t do 3-year plans. Or much of any planning at all. We think at MOST about what “themes” we want to cover within a year. And then we make decisions about what to work on every 6 weeks.
As for deciding to focus on Basecamp, it came at a time where we were just ready for that. The existing structure was straining. There were too many products doing too well for us to continue as we were as a small business. We decided that staying small was more important to us than growing many businesses, and that was actually pretty uncontroversial within the company.
At the end of the day, Jason and I run the show in terms of making the major business decisions. Of course we want people on board, but even if there had been more opposition, we would probably have pushed ahead regardless.
Question #9
Since Basecamp is a geographically dispersed organization how do you structure and staff (and their locations e.g. overlapping timezones) within project teams to facilitate expedient development with asynchronous communications?
DHH: Dave, we wrote a whole book on the topic of remote work called REMOTE: Office Not Required. That’ll be the best and most comprehensive take on how we’ve solved those challenges over the last two decades of working.
But my fundamental belief is that remote doesn’t actually make things any harder, but it does expose the hardship quicker. So it seems like there’s more challenges but they’re just visible. It’s like turning on the light on your process and culture.
Question #10
Do you think your strategy of paying everyone at the same level equally, and then automatically upping it every year contributes to any social loafing? Are employees engaged when it doesn’t feel like they have to give 110% or “earn it” in some way?
DHH: Aubrey, we’ve spent a lot of time thinking about pay at Basecamp in the last few years. We used to not really have any structure, individuals negotiated their own packages, we’d occasionally give bonuses, and I became sick of the whole process.
We have great people because we hire good humans and give them the room and trust to excel. Why should some of them be paid more than others because they’ve taken a negotiation class or are just more bullish by nature? Doesn’t feel fair at all.
But beyond that, I just don’t think that raises or the prospect of raises, and other monetary rewards like bonuses, are long-term effective as motivators. I cited a couple of books that cover the research on this topic, Punished by Rewards and Drive, in the book answer, but I’d highly recommend diving into the science. Dangling carrots have a few short-term benefits and many long-term ills.
So now we pay everyone in the same role at the same level the same. Regardless of where they live. And we track the industry to ensure that we’re staying near the top. We used to track top 5% of Chicago rates and just switched to top 10% of San Francisco rates. We want and can run with the top, so we do.
That’s a privileged position to be in after two decades of running a profitable company. I wouldn’t advice most companies to set such high targets. But I would encourage them to look at pay in a more equitable fair way that doesn’t require arm-twisting or begging for raises.
Question #11
What is your take on OKR’s? Did you guys at Basecamp implemented such a process or do you just track the success on some basic KPI’s?
DHH: Peter, it’s funny, I had to look up what OKR’s mean. I’m not current on corporate lingo. But no. We don’t track OKRs or the like. We boil things down to a bigger level of “do the best work of your career while you’re here”. I don’t believe in chasing metrics.
Are we generally growing? Are our A/B experiments working? Are we still profitable? It doesn’t have to be that fancy. Maybe that’s because we don’t have a sales department or a suite of executives that get rewarded in that way, but that’s how we roll.
Peter Drucker has written a lot about the toxicity of explicit targets and metrics. I find that compelling too.
Question #12
If growth isn’t the goal anymore, what is? How do you think about this personally, and how do you communicate different goals to your team to keep them motivated and challenged?
DHH: The goal at Basecamp is to be able to keep doing what it is that we’ve been doing: Make a great product that customers are happy to pay for, and take exceptionally good care of our employees.
We hit success on that scale a very long time ago.
These days it’s more about not fucking that up. It’s so easy to fuck up a good thing. Much easier than it is to make a good thing.
We’d fuck up Basecamp, as I know and love it, by growing the headcount by 2–3x. So we work hard to stay small. We’re just over 50 people. That’s enough to do the things we want to do. So we cut out things rather than hire more to stay in that zone.
I don’t think most employees are that motivated by goals, in the sense of metrics and financials. At least not the kind that we generally want to attract and hire. They’re motivated by doing great work. By becoming better at their craft. By making decisions that have a real impact for customers.
Question #13
How do you know when/if it’s time to focus on the product and stop being a consulting company?
DHH: At Basecamp, we switched from a consulting to a product business when the product business could pay our salaries and expenses and still be profitable. But we were also motivated to get out of consulting, so maybe that’s a too low bar for you. If you like doing consulting, that’s great, and you could wait longer.
For us, it took just over a year from the launch of Basecamp until we could focus on that exclusively.
Question #14
From what I understand about you, you personally you live a life that allows you to contribute in your company but also lead a life by design (travel, location, hobbies, work schedule, etc). How do you maintain this balance and what are some ways that you have over the years moved towards the balance you lead today to contribute to Basecamp while maintaining the lifestyle you want?
DHH: Adam, Basecamp was founded on habits that allowed Jason and I to have lives outside of work from the get-go. We never did the crazy 80–120 hour/week thing. Never appealed to us, never found it necessary, never saw it as productive.
So in that regard things have hardly changed since the beginning. We put in about 40 hours per week, and then we spend the rest of the time indulging in hobbies and family and travel and reading and whatever else makes life interesting. That balance is pretty much the same today.
40 hours is enough. And beyond that, taking multiple vacations every year is a good thing too.
Question #15
How do you structure your days?
DHH: Anders, I don’t believe in starting out with mad hours. And we didn’t. I didn’t. We built Basecamp on the technical side with me putting in 10-hours per week! Not per day. I was going in school at the time and I also wanted a life outside of work.
I think 40 hours is more than plenty whether you’re junior or senior. It’s all about how you spend the time and on what. Yes, if you waste it in meetings or in days punctured by interruption, that time doesn’t go very far. But if you get long stretches of uninterrupted time to yourself, it’s more than plenty.
So I don’t recommend that people starting out put in the mad hours because they generally won’t be able to stop. You are what you do and habits are very hard to break.
Focus on getting quality lessons out of your time, not quantity. You’re not going to learn more by doing the same things over and over again.
Jason and I are friends. Not hang-out-every-week-at-each-others-house friends, but friends. We have lots of overlapping hobbies as well. We split the burden of running the company pretty evenly. And then his area of expertise is design, mine is programming.
Question #16
Do you have any specific thoughts about how you can agree-to-disagree without breaking bonds?
DHH: Oana, it’s tough to align fundamental differences like that. Not impossible, but hard. One way that can help is to read the same literature and be inspired by the same voices. Maybe one way to start is to do a bookclub of sorts. All the books I recommended in my answer on leadership books could serve this purpose.
That doesn’t mean you need everyone to be clones, far from it. But there needs to be a fundamental set of shared principles.
All the best!
Question #17
Could you elaborate a little on how you involve existing customer and users in new product features and roadmap? Do you run separate beta/preview features for selected customers? Can all users opt-in to trying out new features? Finally, how do you bring the feedback from the actual users to your product team?
DHH: Anders, we’ve done a lot of Jobs To Be Done research to understand the pressures and motivations of our customer base. So that serves as a backdrop always. But fundamentally, we make Basecamp like we want to have it.
We try to build software on behalf of our customers, not by their request. So that generally means you can’t just ask them “what would you like”, because they’ll like a faster horse. You have to aggregate all the inputs and then formulate a product vision that encapsulates that.
So we don’t do any beta/preview/opt-in stuff with customers. We use it ourselves and then we push it live. If there’s a ton of pushback on certain things, we reconsider, and sometimes we change what we do.
The feedback flows up from customer support and the product group watching the channels (announcements on Medium with comments, twitter, etc).
Question #18
I’m curious to ask you to compare your experience as a leader in a large, open-source project/community (Rails) to your experience as a leader in a corporation (Basecamp)? What lessons from one have influenced your behavior in the other?
DHH: Jason, I think most leadership lessons are pretty universal. I don’t have one persona for Basecamp and another for Rails. I believe that people are generally motivated by the same factors. So whether I’m working with an employee or a peer, it’s the same factors that help unite us and drive us forward.
So I’d say that all the leadership books I mentioned in the other answer applies equally to both domains.
Thanks!
Question #19 (a long one!)
We have tried many development processes over the years but none of them felt quite right. Last summer we switched to something mimicking basecamps workflow (pitches, 6 week cycles with off weeks, etc). Best version of ourselves yet!
Couple things we still struggle with:
Pitches. Can’t seem to get people to write them, or if they do very weak on details. Salesmen baulk at the idea of writing them, so developers usually do it for them. Our two week off cycle weeks seems to be very intensely focused and stressful taking pitch paragraphs (or worse sentences) and converting them to well formed ideas. Wondering was this difficult to implement in the beginning? Is there a wide variety of people that actually write the pitches, or does it generally come from the same sources? Any tips?
Customer Support Balancing. Our customer support can fix some bugs and help confused customers out, but semi-frequently issues ends up needing higher level support, in our case a developer to take a look. Is your support capable of fixing anything? Can they make patch releases if necessary? If not do bugs get fixed right away or pushed to the small batch list? This might fall in the “it depends” bucket.
Versioning. We have multiple versions of our app that we support. Do you ever have requests for a new feature to get backported to an older version? Is that just a flat no? Do you worry that in 10 years it might be hard to support all the versions? Do bugs for basecamp 1 and 2 come up often?
DHH: On pitches, we don’t see it as the main way to drive the product development selection. It’s a source of input, but you need someone in charge of the product who have their own vision and does their own research into what you should be building to make it work. Pitches are more an outlet than anything, really. A way for people who DO have good ideas and do the work to present them well to be heard. I wouldn’t try to force pitches out of anyone.
On support, we used to just have front line support send tickets they couldn’t handle straight to developers. That became very disruptive pretty quick. Then we went to a rotation style where all developers would rotate in to do a week of “on-call”, where all they’d do would be working with these tickets. Now we have both front line, or tier 1, and a tier 2 consisting of more senior support people with some technical chops to do backend data manipulation. And then, if it really is a bug, we log it in the system for later fixing. Very rarely these days is something so critical that it must go straight from a customer ticket to a developer immediately fixing it.
I love our versioning. I did a whole talk on the topic here: http://businessofsoftware.org/2015/10/david-heinemeier-hansson-rewrite-basecamp-business-of-software-conference-video-dhh-bos2015/
Remote work: I’d recommend our book on the topic. REMOTE: Office Not Required. It gives you both the ammunition to convince management and it gives you patterns for how to do it well.
Pay: Answered that in another question. We do top 10% of San Francisco rates for everyone according to role and seniority. There are companies like Radford and PayScale that can help you understand the rates in your industry and area. But fuck having to arm-twist for market rates.
Roadmaps: We don’t do them. Ugh. Planning Is Guessing is a chapter in our book REWORK that covers this.
If you keep cutting against the grain and not making progress, then it’s time to think about getting out. Either by starting your own thing or finding like-minded people to work with instead.
You might also find these articles helpful…
