In practical terms, reading this book has made me:
- less likely to reach for Slack or Zoom as my first method of communication. Instead I’ll consider and prefer, if possible, email or Confluence as they are less intrusive and provide greater opportunity for thoughtful response
- less willing to be “immediately available” both on Slack and also in my Google Calendar. Consequently I’m more focused on the tasks I’m doing because I’ve reduced the volume of interruptions somewhat. The only problem with ignoring or logging out of Slack is when there really is an emergency in production
Jason Fried and David Heinemeier Hansson of Basecamp/Ruby on Rails/HEY fame wrote this book about the culture and business approach they’ve taken at Basecamp and why it’s better than what everyone else is doing. The goal is to be a calm company.
As I read the book I took some notes on the “chapters” that struck me as I read them. I’ve air quoted “chapters” because this is a sparse book that embraces whitespace. It is easily consumable in small chunks.
Availability
Part of my motivation for reading the book was that my work life felt like constant jumping/flipping from one thing to another, juggling many plates, struggling to do the work assigned to me to do and struggling to pick up work that I’m skilled at doing.
This quote resonated with me a lot: “imagine the day of an expert who frequently gets interrupted by everyone else’s questions… they don’t know when these questions might come up. You can’t plan your day if everyone else is using it up randomly”. Thanks Slack.
At my previous job I learnt that not being immediately available was actually more beneficial to my colleagues than being able to answer every question immediately. I’ve kinda forgotten that. It’s my intention to book in office or help hours into my calendar, and block out significant time to do my assigned work. I’ll probably use the COVID-19 childcare slots that I put in when nurseries closed earlier in the year as a first iteration of this.
No goals
The authors question arbitrary financial goals, or growth because that’s what you do, or the requirement to meet or exceed goals all the time. They suggest focusing instead on doing good work each day. Financial goals come with cultural compromise: morals, honesty, integrity, quality. Personally I have no problem with a financial goal if there is a plan for the money. (After all, money is worthless unless you spend it.) If the goal is just to constantly increase the bottom line, then I have low motivation (and little concrete idea) of how to increase revenue/profit. Especially if that goal actually hurts our customers.
There’s a sweet spot for business where customers pay affordably for a service but enough that the company they pay can provide a living for its employees and can be sustainable as a company. Atlassian has/had a value or motto of “Don’t *#!@ the customer” to try and tackle this perhaps, but it only works if you treat your customers opinions as more valuable than yours. The customer is always right, the saying goes, until someone pipes up with: the customer doesn’t know what they want… more on this later.
Work Ethic
I really liked this coherent description of what a good work ethic is: “doing what you say you’re going to do, putting in a fair days work, respecting the work, respecting the customer, respecting co-workers, not wasting time, not creating unnecessary work for other people, and not being a bottleneck”.
People do well at work, not because they work all the hours possible, overworking themselves to stand out, but “… because they’re talented, they’re lucky, they’re in the right place at the right time, they know how to work with other people, they know how to sell an idea, they know what moves people… they know which details matter and which don’t… they know how to do something with an opportunity”.
Calendars
Not being in control of my own time is something I’ve seen affect several people at work. It’s difficult to decline meeting invites, but I think more asynchronous meetings/collaboration on Confluence might be helpful. It’s another idea that’s discussed in the book, but that I’ve had conversations about before reading it. A lot of the meetings I attend are: status updates which sometimes trigger a discussion, planning sessions, or decision making events. Most of those could be done asynchronously giving attendees back some control over their time. On the flip side, having a conversation is sometimes a really helpful way to prompt or explore ideas… My starting point is to stop automatically reaching for Slack or a Zoom invite when collaboration is required.
Updates from other teams/individuals
Status updates at Basecamp, where the authors work, are monthly written updates. This is beginning to happen in Engineering and Products at Adaptavist, but could be expanded more broadly. As ever, the trick is keeping the length short, perhaps with pointers or optional extra text if people want more details. So much gets lost in time when updates are only verbal. Written updates also cater better for multiple timezones or flexible work hours when the team may not all be online at the same time each day. In my team in particular, standups can be quite the interruption and often one or two people can’t attend for one reason or another. They often provide a written update in Slack but they miss all the verbal communications that happen on the Zoom call.
Team insights
The only part of the book that spoke to me about the team management aspect of my role was the section about “if the boss wants to know what’s going on they need to ask specific questions” with concrete examples like “whats something we don’t talk about?”, “Is there something you’re afraid of at work?”, “How could we have helped colleague X to do better?”, “What would you redo if you were given the time?”, “What advice do you have before we start this next thing?” – the arguement being that open ended generic questions only go so far in exposing the truth. “Real, pointed questions are the only way to indicate that it’s safe to provide real answers” was a really useful way of helping promote psychological safety from the boss/team lead.
Benefits
The authors are clear that companies should make sure that benefits don’t require any more attendance at work (eg free office food only applies to those in the office at lunch time, and discourages people from leaving the office walls and getting some space away from the desk to think or just have a lunch break). There’s a great article in Scientific America that talks about the importance of breaks and rest. Some of the benefits Basecamp have are: 30 day sabbatical each 3yrs, Fridays off work during summer months, paid vacations, $1000 education stipend (not budget) for anything- especially non work related things, $100 fitness allowance to cover equipment or gym membership.
Disney+, unlimited holiday and a generous paternity leave policy are two benefits I can think of at work that don’t encourage more work engagement, so it feels like Adaptavist are at least somewhat on the right track with this.
Library Rules
One of my favourite ideas from the book is Library Rules. Slightly defeated by COVID and all the WFH now but something to consider, at least upstairs in the Leamington office in the future.
Knee-jerk reactions
Following on from meetings and time control earlier comes this quote in the book: “important topics need time traction and separation from the [normal Slack spam].”
I’ve begun to embrace the practice of writing things down in order to share and persist knowledge. I’ve got a long way to go to find a style or approach that works longer term (ie looking back on notes after 2 or 3 weeks and them making sense) but it’s been invaluable as far as I’m concerned to write things down rather than just share them verbally. Partly because I can’t remember everything, nor should I expect my team to, and partly because written work is a more useful reference than “what did you say about this?” and it’s a great way of sharing knowledge or requesting input from a wider group of people in their own time. Google’s design docs are a useful starter for ten.
If a decision is being made or an idea being planned, write it up and get feedback asynchronously. Allow the people deciding or planning to consider the decision or think about ideas in their own time rather than having to come up with a response or a decision immediately during an arbitrarily scheduled meeting.
Deadlines
The authors had an interesting take on deadlines that I’d not come across before. I have been fairly anti-deadline in the recent past.
At Basecamp they commit to deadlines and reduce scope instead of pushing the deadline. A lot of things that will take 6 weeks to do can be done smaller or less in some way in 1 week.
This feels like quite an Agile way to force frequently releasable progress, but I can imagine it may incur significant tech debt. Either way it’s another viewpoint on deadlines to consider next time we have one.
Disagreeing and committing
My boss has talked about this before. Someone has to decide things, usually the Tech Lead or PM or ideally a combination of them plus PMM and UX… anyway, ideas should be pitched, discussed, a decision made and the team then commit to that decision. Convincing the decision maker shouldn’t necessarily be required, but this is where autonomy fits in I think: someone or some team make a case for some decision and whether the decision maker agrees or not, the team as a whole buy into that decision, giving people the autonomy by removing the requirement that they persuade everyone.
I don’t think this means never revisiting decisions, that’s what good retrospectives are for, but it does mean that there’s a clear direction that the team are pulling in together.
Doing nothing
What if we stopped engineering work on our products? What else could we do? It’s not really what the chapter was referring to but it made me pause for thought. For how long would we need to do nothing before it became a problem? Coupling this with the earlier chapter about goals can initiate a significant existential conversion.
This chapter was trying to make a point around not changing things for existing customers. Not migrating them, not upgrading them, not changing things unless they opt in. There’s also a later chapter discussing change control: The customer knows best after all, or have at least grown used to the way things are and built business processes around how your product behaves. Forcing change on them is usually going to provoke frustration. Although letting the customer select when to opt in to change might be great for enterprises, honestly I’m not sure if that makes our lives harder or easier in Cloud. In Server/DC world it might be easier, or might be kinda what happens now?
“The only way to get more done is to have less to do. Saying no is the only way to claw back time… Time cannot be managed”. Often there are more ideas than people or hours. It’s something I’d really like to change, if only for me, but I’m not entirely sure how yet. I think my starting point is going to be to reduce the amount of interruptions I have and therefore create more time to complete things.
Team size
3s a charm according to the authors. Extrapolating out from what is said in the book, I think each team of 3 works on a particular objective on the one Basecamp product that they have. I kinda get this. I’d like to pair or triple on features/upgrades/changes in a more focused way and have less in flight all at once. A not very thought through idea would be to have subsections of each product team take an epic/initiative at a time and own that from beginning to end, in isolation from the rest of the team unless they want to tap into some prior experience when planning or something. I believe its important that designs and implementation details still get communicated around the team but perhaps some more technical writeups will help there.
Know “no“
One of the best chapters but deserves a separate blog post.
Pricing
Apparently Basecamp have a flat rate so that no one customer has more purchase power than another. A philosophical decision not an economic one! I kinda like it but it’s only ok if you’re not optimizing for dollars. Which we do more than we don’t, so I can’t see that happening at Adaptavist.
Unhappy customer engagement
According to the authors, the more you apologize and make things right the more the customer has only one response left which is ‘no worries’. Usually it’s not actually that expensive to go the extra mile in making amends. I guess this affects those engaging with customers directly more than others.
In my side business, selling mugs on the Internet, my partner responds like this very well and it breeds good feelings with our customers. Again, not optimizing for dollars.
Growth
Why grow? The theme of having enough or being satisfied with where you’re at appears again, challenging the “if you’re not growing, you’re dieing” crap. Basecamp have seemingly decided to stay small and sustainable and do less and be satisfied with that. It’s a trade-off, and David & Jason are very privileged to be able to choose to not grow, not hustle, work enough to survive and leave it at that. They are actively not making work their entire life, in opposition to the desires of quite a few Adaptavist employees who want work to be their life.
To Sum Up
Overall it’s a bit preachy or arrogant and clearly comes from a place of great privilege where this style of work and business has been a success, however I like that some of the “givens” of business are challenged or inverted. For me it was kind of a breath of fresh air. My work life had definitely become crazy and stressful and sometimes you need someone to show how the opposite of your current world view may just be possible.