Skip to content →
Linear Method

Principles & Practices

Software project management tools should build with the end users – the creators – in mind. Keeping individuals productive is more important than generating perfect reports.

Productivity software should be opinionated. It's the only way the product can truly do the heavy lifting for you. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.

We should find a cadence and routine of working. In cycles, we decide priorities and assign responsibilities. Our goal is to maintain a healthy momentum with our teams, not rush towards the end.

Our daily work might be filled with tasks but we should understand and remind our teams of the purpose and long term goals of our work. Roadmaps, projects and milestones are all important to keep in mind as we plan our weekly schedules.

Don’t invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects.

Our tools should not make us the designers and maintainers of them. We should throw away or automate the busy work so you can focus on the more important work.

Teams at different sizes have different needs. Tools should be simple to get started with and grow more powerful over time.

There isn't always a best answer. The important thing is to make a decision, and move on.

Ambitious goals are the only way to make a significant impact. Companies should focus on them when they define their high level direction. Reserve some space on your roadmaps for unexpected and reactive work that always comes up and allow your roadmap to change if needed.

All projects and work should directly correlate to these goals. Review projects and their target dates during roadmap meetings and pull from projects as you plan cycles.

Cycles create healthy routine and focus teams on what needs to happen next. 2-week cycles are the most common in software building. They're short enough to not lose sight of other priorities but long enough to build significant features. Cycles should feel reasonable. Don't overload cycles with tasks and let unfinished items move to the next cycle automatically.

You don't need to save every feature request or piece of feedback. Important ones will resurface and low priority ones will never get fixed. A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done.

All software has bugs, more than we can ever fix. Include bugs and other fixes as part of your cycles. Invest in tooling as it is a force multiplier if done right.

Each project should have a named owner responsible to own delivery and write the project brief. The same goes for issues. Others should collaborate but responsibility should lie with a single person.

Aim for brevity. Short specs are more likely to be read. The purpose of a spec is to briefly communicate the "why", "what" and "how" of the project to the rest of the team. Ideally these short documents force teams to scope out work so priorities are clear and teams avoid building the wrong thing.

The more popular your product, the more feedback you'll get. Overflowing inboxes are a good sign unless they're bug reports. Don’t worry too much about organizing all the feedback. Collect it and use it as a research library when developing new features. Try to spot trends. Use feedback, even complaints, as an opportunity to get to know your users and ask them to explain why they want a specific feature so you find out their needs. Solve the problem – don’t just build the feature.

It's hard to see visible progress when working on large tasks, which can be demotivating. Break down work into smaller parts and create an issue for each one when possible. Ideally you can complete several concrete tasks each week. It feels great to mark issues as done.

The clearest way to see whether something is complete or not is to show the diff in the code or design file. When the tasks are scoped small, your changes will be small and easier to review, too. Avoid massive pull requests or large design changes.

Designers and engineers should work together on projects, creating a natural push and pull. Designers bring their skills to explore ideas and push your team's thinking. Engineers can challenge thinking around implementation and will bring the winning ideas to reality. The best creators often have talent for both. Directly loop in other teams when building features they'll use or ask customers they interact with to use.

It’s important to look back and celebrate what you achieved as a team. Consistent changelogs also communicate to the user new features, the value they get from your product, and your commitment to improving it. It's also an easy way to connect your team's individual work to the collective value they create. Read more on how we write ours.