Basecamp co-founders Jason Fried and David Heinemeier Hansson are back in the Rework studio to answer your questions. In our latest episode, they discuss listener inquiries on topics like why big companies don’t use Basecamp; how they managed the transition from a web design agency to a product company; and what their business partnership means to them. Kristin Aardsma from Basecamp Support also pops in to answer a question about how her team maintains fast response times while making time for breaks.
Keynote on the topic of open source, markets, debts, purpose, and no less than the meaning of life. Delivered at RailsConf 2019. Also available as a long read below.
We pay at the top 10% of San Francisco market rates for salary + bonus (but not stock options) at Basecamp. Those rates apply to everyone here, regardless of the role or where they actually live. We don’t even employ anyone who live in San Francisco!
We picked San Francisco as our benchmark because it’s the highest in the world for technology, and because we could afford it, after carefully growing a profitable software business for 15 years.
For programmers, designers, operations, administration, and the vast majority of other roles at Basecamp, simply following the top of the market rates is a pretty sweet deal: High salaries, benchmarked against the top market, yet most people live in places with far lower cost of living, which means we’re even more competitive in local markets.
(While we might be top 10% for San Francisco, I’m pretty sure we’re in the top 1% for, say, Fenwick, Ontario or Spokane, Washington or Madrid, Spain.)
But where this doesn’t work as well is when the San Francisco market rates reflect how technology hasn’t really raised all boats. While the rates there for programmers and designers are far higher than many other places, this is a lot less true for, say, customer support or other roles that hasn’t seen the same market competition.
Basecamp is hiring a director of operations to run the team responsible for all our technical infrastructure. Our suite of applications is served from a mix of our own servers in leased data-center space and cloud setups in Google Cloud and AWS. The job is to ensure that everything runs smoothly, the lights stay on, and we’ve prepared for bad luck with good planning.
This is a role for someone with experience running a team at least as big as ours and a multi-million dollar budget. You’ll be managing a team of seven and report to the CTO.
Basecamp is a remote-work company, but you’ll need at least 4 hours of overlap with Chicago time in your normal work-day routine.
We strongly encourage candidates of all different backgrounds and identities to apply. Each new hire is an opportunity for us to bring in a different perspective, and we are always eager to further diversify our company. Basecamp is committed to building an inclusive, supportive place for you to do the best and most rewarding work of your career.
Whenever we write a book, we include our email at the end so people can reach out and share their stories. With their permission, I’d like to share an email we received this morning from a reader of “It Doesn’t Have to Be Crazy at Work.” Published as written, only their name is being withheld at their request:
Hi Jason, David,
Your book ‘It Doesn’t Have To Be Crazy At Work’ prompted me to change my life. Thank you.
When I started reading the book back in January this year, I was working 14-16 hour workdays, working weekends, and practically had no life outside of work. I was eating unhealthy food because I had no time to cook and my house (I live alone) resounded the inside of a shabby animal’s cage. I was following what was told to me as the right path to success, and I was giving away my life for a boss who somewhere deep down didn’t really care for me at all. My company offered me no benefits and it was a pathetic environment to work in. And I stayed, slogged day in and day out, because I thought I had no choice.
However, as i read your book, things started to make sense to me. What your book said made a lot more sense to me than the life I was living. It was like a world was opened up to me, one I could not imagine. I thought success wasn’t achieved on anything less than 80 hour workdays. And I almost prided myself on being able to live through them.
Today, I just five months later, I have been able to change my life. I moved my job to a much bigger firm that gives me a lot more job satisfaction and a lot more time for myself in life. I was able to up my salary by half in this transition and more importantly, get access to a lot more knowledge and resources at work to help enhance my development. I was able to get access to things like healthcare, and even small bits like fruit water at work which helps me stay hydrated throughout the day (whereas even water breaks were seen as bad at my previous workplace). I am able to cook meals for myself almost everyday and I am able to workout on alternate days. I come home by 5 in the evening, and most importantly, I am happy. I very so happy in life, as opposed to being a miserable little person who snarled at everyone all day long.
I really hope more people are able to understand what it is that you are trying to put across with your book. Thanks a lot for putting the book together and all the best!
A tech-impact writer based out of Gurgaon, India
name withheld by request
Claire Lew is the CEO of Know Your Team, a company dedicated to solving the problem of bad bosses. The company has its origins as a product developed within Basecamp and today is not just a software tool, but a deep vein of resources for managers of all experience levels. In this new episode of the Rework podcast, Claire shares her unconventional path to becoming a CEO, how she completely revamped her company’s focus and business model, and why so much “thought leadership” around management gets it wrong.
It’s always inspiring to read about the early days of an idea. About the doubt, the pushback, the impossibilities, the models telling you it’ll be too expensive, the “but, but, but…”, the breakthroughs, the vision, and the drive when you just have a hunch. The knowing that there’s no way to know until you try. These moments are often wrapped with unusual combination of vulnerability and confidence. I find them fascinating. Here’s an oral history of how Amazon Prime came to be.
Debates continue to rage about the role of UX designers, user research, and how far knowledge about the user should permeate the organization. On one extreme, UX is seen as a specialized pocket of knowledge that informs the definition of projects and sets requirements. On the other, UX is something for which the entire organization should somehow feel responsible.
A few concepts can facilitate a deeper discussion by drawing meaningful distinctions.
- UX at the boundary between supply and demand
UX happens at the boundary between what is technically possible and what is fitting for the problem at hand. The canonical picture for this boundary is the client/firm relationship. The firm knows how to do a lot of things. The client wants something in particular. The firm tries to understand the client as well as possible to do what they want (create “value” in business jargon.)
This boundary happens at different points within a company too. Each boundary can be viewed from the supply side or the demand side. Somebody knows how to make something (supply) and somebody needs something (demand). These two perspectives meet at each link in the value chain.
For example, programmers program something according to some kind of requirement. The requirement is set according to some understanding of the problem. The person who’s responsible for understanding the problem is looking at it from the demand side, while the person who’s responsible for finding a solution to that problem is looking at it from the supply side. Or the same person may be doing both by alternating their perspective from demand side to supply side.
Often when we’re talking about UX we assume a view from the last link in the chain: the end user. Knowing explicitly which link we’re talking about can inform the discussion. For example, the user and the buyer might not be the same person. They both need “UX.” To clarify what that means and who’s involved we can make the boundary explicit. The parts of the supply side at the buyer boundary (marketing, sales, product features in macro) will be different from the parts at the user boundary (onboarding, interaction flows, back-end performance).
The concept of supply/demand boundary lets us think about how far down to go too. Consider a freelancer who builds on WordPress. The design of WordPress is affecting the UX from the most macro perspective. But from the perspective of the freelancer, WordPress is a constraint on their supply side capability and it’s her job to adapt its potential to the demand of the client.
2. Modular vs integrated boundaries and UX
The boundary between two links in the chain can be of different types: either a distant third-party style relationship or a more intimate “let’s solve it together” relationship. The freelancer using WordPress is an example of the former. A designer and programmer teaming up on an interface concept is an example of the latter. Following Clay Christensen’s lead, we can call the former ‘modular’ because there’s a standardized interface and the latter ‘integrated’ (he calls it ‘interdependent’).
This distinction describes the organization of the people who provide the supply to fit the demand. Some teams are small and intensely collaborative. They talk directly to the customer and then sit around the table together to architect the solution. In that case the boundary between requirement setting and programming is integrated.
Often when a company grows beyond a certain point the boundary modularizes. This means there’s a formal interface (aka handoff) at the boundary with some procedure for how information from the demand side is communicated to the supply side. An extreme example of this would be the relationship when one team creates specs for the project and another team fulfills those specs. Each has a different boundary. From the spec creator’s perspective, the demand side would be the use case they are looking at to design the spec, while the capabilities of their technical team are the supply side. From the spec fulfiller’s perspective, the demand side is the spec itself and the supply side is their knowledge, toolset, and stack. Both do “UX” in the sense that they want to provide the best experience to the demand side of their boundary. But they don’t all sit at that last boundary with the end user.
This doesn’t make a good/bad judgment about how to organize. Different organizations suite different constraints. Generally speaking, if the problem has been solved a hundred times already, the organization can modularize. On the other hand if the solution has never been done before, more integration is required between links in the chain. That’s why at Basecamp our designers and programmers work tightly together to design a brand new feature. Or Apple had to create its own Pencil that integrates with the glass under the iPad to outperform capacitive styluses.
3. Domain specific vs. domain independent UX
A third distinction we can make is between the knowledge and skills that improve UX in general versus for a specific domain.
Domain specific UX means understanding how the supply should fit the demand considering a specific situation and use case. For example, imagine a user of a task management tool is walking from their office to the parking lot and they suddenly think of a task for their team. They try to add the task on their phone before the forget it, but it takes so many steps to file correctly that they struggle to remember the task in the middle of the process. This is specific knowledge about a specific problem that would inform the UX of the mobile product design.
On the other hand, many aspects of UX don’t require knowledge about a particular situation. They‘re based on the common constraints of human sense faculties, memory and cognition or the net of ergonomic factors around the device and the setting where it’s used. These domain independent elements of the UX are important too. They make up much of what the early usability movement wrote about. A specific example would be using labels on icons instead of icons alone so users understand their meaning.
These types of UX problems are the subject of books like Norman’s The Design of Everyday Things or Tufte’s The Visual Display of Quantitative Information. Those examples are at the interface design boundary. For the back-end, Evan’s Domain Driven Design or Fowlers’ Refactoring show how to provide better UX to consumers and editors of the API.
Domain independent UX should absolutely pervade the organization. It belongs to the general skill and knowledge of each supplier at their link in the chain. It’s part of learning to be a good designer, programmer, marketer, salesperson etc. Looking at the firm as a whole, domain independent UX belongs to the supply side.
Domain specific UX is different because there’s a new cost to acquire it for each customer, product, or use case. If an interaction designer wants to increase their domain specific knowledge, they have to stop designing interfaces and go research for a while. Then they have to analyze what they learned and synthesize it into conclusions that are general enough to create requirements and design against. Looking at the firm as a whole, domain specific UX belongs to the demand side. It’s about understanding what to produce and sell.
Whether or not everyone in the firm needs domain specific knowledge depends on your architecture. A company with modular boundaries between teams will need to modularize the acquisition of that knowledge. In other words, specific people in the organization take the time to do research. Their requirements constitute the domain specific UX.
On the other hand a company with integrated boundaries could alternate how they spend time. Sometimes researching the customer’s situation, other times designing a fitting solution.
Which approach is appropriate will depend on the size of the company, the complexity of the use case, the complexity of the technology, and other factors.
Hopefully these concepts can help move discussion about UX to a deeper level, enable designers and researchers to think more rigorously about their place in the organization, and give companies tools to better apportion responsibility for different types of knowledge and decision making.
Update: See the discussion in the comments below for a more concrete example of how these concepts apply in practice.
We don’t ask ourselves this enough. Here are 6 critical questions to reflect on when considering if you should become a manager or not.
When we’re asked, “Do you want to become a manager?” we often assume there is only one answer.
“Oh, of course I want to be a manager.”
Right? Who doesn’t? Especially when becoming a manager is seen as the primary path of upward progression in a person’s career.
But do you truly want to become a manager? Management is not some sacred club reserved for the hallowed few. Rather, deciding to become a manager should be viewed as one might decide to become a garbage disposal collector or a parking meter attendant: If you’re doing it, you’re doing it for a reason. It’s not for everyone.
The title of this post is how Kenneth Coats described the feeling of leaving his office job to start his own business. After he unplugged from the Matrix, he simply couldn’t return—not even when a challenge from the Illinois Attorney General forced him to shut down his first venture, a service to help people expunge their arrest records. In this episode of the Rework podcast, Kenneth shares the story of how he pivoted, and the drastic move he took to make sure he couldn’t go back to his old work life. Listen below, or click “Keep Reading” for a full transcript of the episode.