How to Write a Good Job Description

On last week's Rework podcast, Jason Fried and David Heinemeier Hansson, co-founders of 37signals, joined host Kimberly Rhodes to answer listener questions about their approach to design, decision-making, and more.

Today, they return to tackle more listener questions, covering a diverse range of topics such as delegating projects, hiring, and remote work.

Listen in as they discuss their strategies for helping team members take ownership of their work and their tips on deploying projects. They also offer advice on attracting and retaining the right talent and discuss the role of communication and culture in building a successful team.

Show Notes: 

[00:26] - Sarah McKenzie asks for tips on delegating projects rather than tasks and helping team members take ownership of their work areas as she wants to move in this direction with her small team.

[01:23] - Jason explains how Basecamp delegates projects instead of tasks. In contrast, team members are given a rough general idea of the project and some ideas for the interface design, and they figure out how to get it done in their own time.

[02:57] - David adds that even new employees and junior programmers can handle owning a whole project.

[04:38] - David shares that Shape Up's idea of a fixed time frame and flexible scope interlocks with delegating projects.

[05:32] - Let people live up to high expectations and see who does it quickly and best. Delegating a project means evaluating work based on outcomes, not effort, allowing team members to make decisions and run autonomously within the project's scope. 

[06:28] - Julio Caesar from Sao Paulo, Brazil, asks DHH about the day-to-day work in a team of two, specifically about code review, pull requests, and dev to production deployments. He's concerned about the time wasted in long change management meetings and how to avoid having someone who doesn't know anything about the project approve a deploy.

[07:11] - 37signals has teams of two working on different aspects of a product, with any given feature having a designer and a programmer working on it.

[08:24] - David shares that the company has a process where someone is responsible for the quality of the work that goes out the door. There is a mentorship process for new hires. Programmers and designers review each other's work.

[08:40] - In the Seven Shipping Principles, there is a notion that if the person is confident that the deploy is low-risk, they are not obligated to get a review. Even CTOs and senior employees sometimes request a review to increase their confidence. The team encourages individuals to have a strong sense of confidence and delegate the responsibility of reviews to themselves.

[09:22] - The review process is asynchronous and shouldn't be a blocker.

[10:29] - Jason shares that although anyone can deploy work, the company has never had a catastrophic deploy in its history. And rollbacks are very rare.

[12:38] - A mystery caller asks David and Jason if they have any rules, constraints, or systems in place to help them decide when to grow and when not to grow, specifically around headcount and staffing.

[13:02] - Jason explains that their hiring is department-based and based on specific needs rather than global goals. They follow the principle of "hire when it hurts" and aim to alleviate actual pain rather than future pain. 

[15:16] - Having two people is better than one—David shares an example where they had only one person in a role, and it was difficult for them to take a vacation or sabbatical without affecting the company. He also s