Book Recap: High Output Management by Andy Grove

High Output Management is a collection of recipes for squeezing more performance out of your organization.


The output of managers is an output of organizational units under their control or influence. All focus should be on increasing team, not personal, performance.

A lot of Andy’s bear similarity to SCRUM. Both seem to be influenced by Toyota. Both focus on continuous process optimization and setting up a system that keeps people challenged and motivated.

Solid Ideas

Impacts of defective products are impossible to predict. So, any compromises on quality are unacceptable. Recognizing it can lead to a big change in prioritization patterns. When you recognize reliability as an attribute that cannot be compromised on, saying no becomes easy. Since we decided to make reliability a priority for our Todoist for Windows 10 app, saying a confident no to projects that would divert our focus has become much easier.

A manager’s day ends when they’re tired and ready to go home, not when they are done. Managers are never done. It’s a feeling that’s hard to escape. Setting more explicit daily/weekly goals could be a good start to mitigate this feeling.

Eliciting peak performance means going against something or somebody. This is an idea shared with John Legere, T-Mobile US’s CEO. Having something to compare against can be a powerful motivator for some people.

During performance reviews, assess actual performance, not potential. Andy is very strict about assessing a person’s performance. Talking about potential is best left for 1:1s.

Finding a way to create such opportunities could help create a more aligned and connected organization.


Book Recap: Work Rules! by Laszlo Bock

Work Rules! talks about the principles and practices applied by Google’s people ops team. It paints the picture of a data-driven, risk-seeking culture that’s willing to experiment and takes advantage of its scale by mining internal data to improve employees’ lives.


Let’s try to make people ops act more like a software organization. Select small groups of employees to test new benefits, don’t be afraid to iterate on ideas. When something doesn’t work, scratch it right.

Use data about your organization heavily. Employee satisfaction surveys, compensation data, percentage of pull requests accepted without the need for revisions and other data points.

People Ops should have the capability to integrate data from across the organization, analyze them, set metrics and come up with actionables. But don’t lose your soul. Keep in mind that keeping your people happy is always your ultimate goal. If you achieve it, the score takes care of itself.

Solid Ideas

Treasure and analyze your best performers. The top 10% of your people are not better than the average by 10%, but by 1000%. Reflect their performance in the way you treat them. This approach is somewhat contrary to the current industry trends, where equal pay seems to be the ultimate goal.

Google’s approach to unequal compensation should be adopted carefully. People from cultures where modesty is valued could be uncomfortable with being publicly called a top performer and being compensated differently than their peers.

Aside from paying top performers incredibly well, you need to put them under a microscope. The differences between your best and worst tell you how you can help your weakest players. That requires you to measure a host of different employee behaviors, which many organizations do effectively.

Use non-cash awards for better employee happiness. Awarding non-cash prizes such as team trips or fun hardware makes people happier in the long run than giving cash even if they tell you otherwise in the beginning.

For committee-based processes, calibration is vital. When you set criteria for candidates or performance evaluations, it’s key that committee members agree on a baseline. E.g., the baseline for an optimal hiring goal can be an existing employee.

Create easy-to-consume resources for your managers. The quality of managers is the most significant determinant of employee retention. Invest in your managers by giving them dead-simple tools to help with everyday activities (e.g., checklists for good career conversations). Give managers data that helps them understand what holds their teams back and what they can do about it.

Help your people with routine tasks, let them focus on the important stuff. Mundane activities take away your focus from critical work. Where possible, manage routines for your people (on-site hairdresser) or give them nudges to improve their behavior (make saving part of their income the default choice).

Interesting Tidbits

  • Veterans’ Affairs is a fantastic resource for interview questions.
  • Keep the compensation and performance conversations separate to prevent people from getting defensive when you suggest improvements.
  • Google’s Project Oxygen identified what makes a manager an amazing manager. It’s one of the more actionable lists of its kind you’ll see.
  • “Most companies celebrate promotions but do nothing to reach out to people who missed the cut”. This feels like a low-hanging fruit that could make a lot of difference.

Book Recap: Agile Project Management with Kanban by Eric Brechner

In classic Microsoft Press fashion, Agile Project management focuses on execution and pragmatism. To that end, I’ll structure this recap a bit differently.

Overall, where Scrum feels like a structured approach with an eye on speed, Kanban feels like a flowing river. There’s no time-boxing. Instead, Kanban focuses on creating a clean and narrow channel for your work to flow though.

Let’s take a look at the Kanban process.


The core idea of Kanban is similar to what Andy Groove talks about. Find your limiting step and optimize the rest of the process around it.

Here are the basics steps, simplified for brevity:

  1. Define the steps of your process. Specify, Design, Implement, Test, Release might be a good start.
  2. Find your limiting step. It’s the one that determines the throughput of the system as a whole. For Doist, specify and design is frequently where we spend a significant portion of the process.
  3. Optimize your limiting step. I. Break it down to multiple steps; II. Increase throughput if necessary (i.e. deploying more resources); III. shorten it (this is called elevating the constraint)
  4. Define done rules for individual steps. For coding, it could be e.g. Code complete and unit tests pass
  5. Calculate WIP (work in progress) limits for individual steps. Start low and increase the limits where necessary.
  6. Visualize your process as a board.
  7. Create an ordered backlog
  8. Let the work can start flowing
Image for post
A simple Kanban board in VSTS

After you set up the process, you need to fill it up with work. A frequent way to do this is to define an MVP (Minimum Viable Product). How do you know what fit’s in the scope on an MVP tho’?

Determining MVP Scope

All task are sorted into four priorities:

  • 0 — Must be included in the MVP. To determine these, ask the question: “Would we really hold up the release for that?”
  • 1 — Should be in the MVP
  • 2 — Would like to have in the MVP
  • 3 — Would be nice to have it in the MVP

Having work item buckets like this should make the backlog ordering much easier and enable you to react when the scope needs to change.

Comparison with Scrum

If you’re not familiar with the essential traits of Scrum, it might be worth skimming my post about Scrum before continuing.

In some ways, Kanban shares a lot of traits with Scrum, but they have significant differences as well.

Effort Estimation

Since Kanban doesn’t have time-boxing, effort estimation might not be needed at all in a lot of cases. Instead of the burn-down chart in Scrum, Kanban works with the Cumulative flow diagram.

Image for post
Cumulative Flow Chart in VSTS

There are a few things going you can see from the chart:

  • How much you’re shipping over time.
  • Is your backlog growing or shrinking over time? Seeing that the backlog is growing no mater how hard your team tries might not be best for motivation
  • How much work is in progress right now and in what stages

Notice that the unit of the Y axis is Work Items Count. If this was Scrum, it’d say Story Points. But Kanban doesn’t work with Story Points.

Instead, Kanban assumes all tasks are roughly equal in size. This means that in practice, 1 task = 1 story point. From there, you can easily deploy estimation methods like wideband Delphi in case you need to. The only difference is that you go from “How many story points will this user story cost” to “How many tasks will this feature result in?”.

Late Binding

In Scrum, you can choose whether you assign team members to specific user stories or tasks as part of the sprint planning meeting or if assignment happens organically during the spring.

In Kanban, late binding seems more mandatory. When a team member finishes a task, they should ideally take the top one from the backlog.

It’s going to be key in Kanban to make sure people still work on stuff that excites them instead of working on an item simply because it was on top of the queue.


In Kanban, there are no sprints and in extension, no sprint retrospectives that generate kaizens. Instead, Kanban relies on WIP limits to expose friction and create motivation to fix problems. When work starts piling up in a specific step, it’s time to start asking questions.

Daily Standups

The assumption of daily standups is an Achilles’ heel of both Srum and Kanban from a remote team’s perspective.

A major advantages that remote teams have is that members can do deep work for days at a time without any distractions. At least for us at Doist, this makes daily meetings a no-go.

We will need to experiment with this at Doist Windows, but initially it looks like Scrum will be more welcoming to dropping the meeting requirement. Time-boxing creates strong commitments, sohaving a single meeting per sprint to do planning as well as retrospective could be enough. For Kanban, the daily standups feel a more key as it’s the main vehicle to discuss kaizens and re-prioritize work when needed.


Eric had a few interesting remarks that are not strictly related to Kanban, but still peaked my interest 🙂

  • Developers tend to pick a workflow that works for them and stick with it. This is usually a workflow they learned in their first professional experience.
  • The role of a product manager at Microsoft combines the responsibilities of a project manager and a business analyst.
  • There’s a difference between continuous deployment and continuous delivery. Continuous deployment is deploying every build to production while continuous delivery still leaves the decision which builds to deploy to production up to the user
  • When coordinating work across multiple teams, regular weekly meetings with progress reports and plan adjustments are useful. It’s like a scrum of scrums
  • Internally marketing working on support issues as a fantastic way to get to know both the product and the customer is a smart idea
  • A ton of our processes as a human race could be vastly better if reengineered from the ground up. The problem is that as systems develop over time, most of the focus is put on local optimization, but global optimization is tough to achieve

Cover Image Credit: Photo by Joseph Greve on Unsplash