Books for software engineers and managers

It Doesn't Have to Be Crazy At Work

It Doesn’t Have to Be Crazy At  Work

by Jason Fried and David Heinemeier Hanson, Founders of Basecamp

Categories:
Engineering Manager

How strongly do I recommend It Doesn't Have to Be Crazy At  Work?
6 / 10

Review of It Doesn't Have to Be Crazy At Work

Like all the Basecamp / 37signals books, It Doesn’t Have to Be Crazy At Work can be read in a few hours, cutting through the nonsense and offering some common sense advice for product development teams.

This book won’t offer you any earth shattering ideas, but will act as therapy for readers feeling overworked and stressed.



Your company should be your best  product

Product design ideas apply to designing your company and culture.

The authors argue that your best product should actually be the company itself. By focusing on the company, you create the opportunity for greatness within your customer facing products.

Calmness requires owning your own time, which you lose with excessive  meetings

Many engineers transitioning from individual contributor roles to people management experience a great loss – they no longer control their own time.

Day after day fills with meetings and check-ins.

To catch up we work harder, only to find we’ve accepted even more meeting requests. We’ve forgotten the first rule of holes: stop digging.

To achieve calmness and clarity as a software engineering manager, you need to reclaim your calendar.

The best companies aren't families, they are supporters of  families

Our work is enriched by close relationships with coworkers. But we shouldn’t confuse them with our actual family.

The authors provide a good, alternative way to think about work and family: “The best companies aren’t families. They’re supporters of families.”

As an engineering manager, you’ll do well to think about ways to better support your employees in building a healthy and happy family.

Stop it with best practices originating from companies that look nothing like  yours

Consider where best practices originate – usually from companies that look nothing like yours.

If you’re a small software company, take best practices from Google, Facebook, or whoever else with a grain of salt.

When we talk about best practices, we’re really discussing standards of performance.

Standards are incredibly important to improving quality, but they should only be established by people with the expertise to actually understand the work. This is where standards often go awry – they’re pulled in from some unrelated company that looks nothing like yours, then handed down from above on a stone tablet.

Use teams of three to build momentum and minimize communication  overhead

In a call back to their first book Getting Real, Fried and Heinemeier Hanson call for product work to be done by teams of three.

Anecdotally, I’ve experienced success throughout my career using teams of three both as a manager and software engineer.

Three people maintain momentum better than two person teams, which are more subject to the wild swings of human emotion and energy.

Teams of four and more require management and communication overhead adds up between individual contributors.

It Doesn't Have to Be Crazy At Work