Matt Blair

Matt Blair

I read that you learn more from a poor example than from a correct one. I don't believe this but that means my site will be a success.

3-Minute Read

Incident Review

Note: This was a series of talks I gave to leadership in my organization, so some of the comments here might not make sense in the context of a blog post.

This is not original work: I pulled heavilty from these four books to put together these talks:


If I did not site some of these works here, or pulled quotes directly from them, forgive me.

Getting Started with your Team

Organize to Learn

What is the purpose of a team?

“They build & deliver products in response to the demands of their customers at a scheduled delivery time, at an acceptable quality level, and at the lowest possible cost.”

-Andy Grove, High Output Management

Your team charter cannot be to deliver whatever your customer wants whenever they want it, that would require infinite engineering capacity.

How do you figure out your charter?

The starting point is focused learning. Figure out what you most need to learn, from whom, and how you can best learn it.

If you don’t know where to start? Ask the team.

Ask the team:

  1. What are the biggest challenges the team is facing (or will face in the near future)?
  2. Why is the team facing (or going to face) these challenges?
  3. What are the most promising opportunities for growth/success?
  4. What would we need to happen for the team to take advantage of those opportunities?
  5. If you were me, what would you focus your attention on?

Points of Focus; Organize your Findings

Technical Learnings

Focus on technical learnings (strategies, technologies, practices, etc). Think about what changes you can make quickly. A better trained team can handle more situations in less time.

Wasteful Practices

Look at wasteful practices. Do you have lots of long running meetings? Figure out how to eliminate/remove them. What can you take on, to free up your team to do work?

Existing Data

Look over whatever data you already have. Do you track the type of #ask requests you get? How often are you paged? Technical state of the team? The nature of the failures/errors your team encounters? These are all useful measurements that you’ll need to put together your vision for your team.

Classifying Problems & Opportunities

Once you have everything documented, start to classify the problems/opportunities:

  • How long will each thing take?
    • Days? Sprints? Months? Years?
  • How many people will need to do it?
    • 1 dev? 1 team? 3 teams?
  • How important is it to get done?
    • Anything that slows the team down and makes you less productive is of critical importance to kill
    • Whatever wasteful tasks you eliminate immediately pay you back in increased productivity
  • A common rule for prioritization:
    • Detect and fix problems at the earliest state possible.
    • If you catch a problem right as it happens, it’s infinitely cheaper than letting your customer find your problem for you.

Create a matrix. You want to tackle the high importance / low effort tasks first. After that, you can figure it out. Your task here is to find the most cost-effective way to deploy your resources - the key to optimizing all types of productive work.

Remember while doing this exercise:

“Many managers, upon recognizing today’s gap, try very hard to determine what decision has to be made to close it. But today’s gap represents a failure of planning sometime in the past”.

-Andy Grove, High Output Management

You must understand the energy you put in early to your team and process pays off 10x, while the energy you put in at the end of the process pays off -10x.

Recent Posts



This theme was developed for Hugo.