# Level Up Your Engineering Management Skills: Why You Should View Your Mistakes as ‘Misses’ | Dev Interrupted Powered by LinearB

> There’s no one-size-fits-all solution for managing engineers. Engineering leader Ian Nowland offers a framework based on 20 years in the industry. Mistakes are inevitable, but you can take the ego (and some of the pain) out of a screw up by viewing it as a “miss” — and focusing on the learning opportunity.

_This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._

[Blog](https://linearb.io/dev-interrupted/blog)

/

Level Up Your Engineering Management Skills: Why You Should View Your Mistakes as ‘Misses’

# Level Up Your Engineering Management Skills: Why You Should View Your Mistakes as ‘Misses’

![Photo of Max Kolomaznik](https://site-assets.plasmic.app/eb79bdd689efbccb3a7e936e62b3a798.svg)

By Max Kolomaznik

|

June 21, 2022

![Ian_Nowland_blog_card_5aaccc96d0](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Ian_Nowland_blog_card_5aaccc96d0?_a=BAVMn6ID0)

As an engineer, you might have learned the basics from textbooks or watching a series of tutorials. 

Managing engineers is different and isn’t something that can be mastered from simply reading a book. 

In my experience, the only proven way to learn is by plugging into the collective wisdom of smart people who have done the hard work of actually managing engineering teams.

That’s why I was so happy to speak with Ian Nowland of Datadog.

With 20 years of engineering industry experience — 10 of which have been in management positions — Ian developed a unique approach toward engineering management, encapsulated in seven categories. 

These seven categories of engineering management are based on his own software-engineering experience, which includes 10 years at Amazon and are designed to help managers successfully direct, satisfy and retain employees, as well as maintain a healthy company culture. 

Some of the central components of Ian’s framework include taking the ego out of mistakes, developing a learning mindset towards management, and building social capital between teams.

We’ll dig into this more below. 

### Using the 7 Categories of Engineering Management 

People often refer to the three P’s when it comes to management: 1) People; 2) Process; and 3) Product. 

But Ian believes that’s limiting when you’re thinking about management in engineering and doesn’t account for the full range of engineering activity.

Instead, Ian believes it’s more helpful to consider the following: 

1. **People:** Are people happy and growing in what is being built?
2. **Engineering:** How are things being built? This is about focusing on how your engineers get stuff done and how well those processes work — like the efficacy of a team’s code-review process.
3. **Product:** Are customers satisfied by what’s being built? Ian also refers to this category as “portfolio management.” It’s about communicating with an engineering team about their roadmap, what milestones they plan to explore in that year or quarter, and what story they want to tell through their work.
4. **Partners:** Do your partners understand and agree with all of the above? It’s important to foster healthy relationships between teams and any affiliated groups across the company.
5. **Execution:** How are things getting built? Managers have to think about what has to be done and how they should organize teams to meet annual milestones.
6. **Operations:** Once your product/org is built, is it going to keep running? Operational processes, like scrums or sprints, are crucial to the success of a software engineering project, so it’s important that managers ensure these processes are effective and efficient.
7. **Company**: Does the company align with all these answers? It’s every engineering manager’s responsibility to reflect their company’s culture. A manager’s actions (or inactions) will set a precedent for their teams and direct reports.

The “Miss” Approach For Managing Engineers 

Ian believes that when you’re managing engineers, there’s a lot to oversee. There are tons of opportunities for mistakes along the way — they can and will happen. But Ian’s found that it’s through making mistakes — or “misses” — that everyone gets to improve. 

A “miss” occurs whenever something goes wrong that could’ve been prevented. But here’s the key: Don’t think of a miss as a mistake — it’s a teaching moment. 

It’s a subtle mindset shift. Instead of focusing on the mistake (which can be damaging to a person’s ego), view it as an opportunity for growth.

**[Managing by Missing](https://www.slideshare.net/IanNowland/managing-by-missing "Managing by Missing")**  from **[Ian Nowland](https://www.slideshare.net/IanNowland)** 

**When you start thinking in terms of misses, it becomes easier to digest. It’s like:** **_That’s okay, I’ll get it next time_** **.** Ian found this especially effective for people with perfectionist tendencies (and I’m the first to admit I definitely fall into that category). 

### Using a Miss To Build Social Capital (aka Get What You Want)

Ian provided a beautiful example to illustrate what he was talking about.

Let’s get specific. Looking at the categories, here’s a miss I experienced in a previous job when dealing with partners at the company. 

At the time, I was managing a software team that was in charge of a network device. A previous manager had made the decision to use a different vendor, and the network team basically said: _we’re out._ As you can probably tell, there was some friction between the two teams. By the time I started working with this group of software engineers, it was clear they were in over their heads. 

I went to the woman who was the head of the network device team to ask if we could turn this over to her team — after all, software engineers have no business running networking devices. Since we were using our own vendor and her team was busy, she didn’t agree. 

At an earlier point in my career, I would have felt frustrated and left it at that. But past misses (and the seven categories!) have taught me to look at the bigger picture. In this case, she’s well-intentioned and doing the best she can. 

Considering the importance of building good relationships between teams, I focused on that. At one point, I even volunteered one of my engineers to help her with a software project to build goodwill. 

About a year later, I approached her again to ask about taking over this particular network device. This time the answer was yes. 

What changed? We’d built up some trust. We’d taken opportunities to show her that we were trying to do the right thing for the company (by helping her out), and so we’d established the social capital to get a positive response when we made an ask. 

**_Want to hear what Ian learned from other misses?_** [**_Listen in at 11:50_** ](https://devinterrupted.com/podcast/7-categories-of-engineering-management/)**_to hear about a miss in execution and how he came back from a project that went off the rails._**

### Does It Work? Measuring Success 

When it comes to measuring impact, Ian doesn’t believe there’s a universal measure of success — it’ll change according to the situation. 

Engineering leader Michael Lopp has written about management in terms of “[organics and mechanics](https://randsinrepose.com/archives/organics-and-mechanics/).” Ian tends to sway toward being an “organic,” which is essentially intuition-driven. 

In his current role, Ian oversees a lot of managers. One of the main things he looks at is whether the managers are surfacing misses early — before they feel like a surprise. 

When you manage a lot of different people, your job is to delegate well. **The number of surprises is a good indicator of whether everyone is on top of what they’re responsible for** — if there are few surprises, you don’t need to get too involved and that things are going well. 

When measuring operations and delivery goals, these are areas where it makes sense to apply different standards. For example, objectives and key results (OKRs) are helpful the higher up you go on the organizational chart. When evaluating managers, Ian wants to know: Did they accomplish what they set out to do? If not, why didn’t it work out as expected? 

Ian says you wouldn’t expect a team lead to care about OKRs; a team lead should be more concerned with measuring scrum.

Engagement surveys can be helpful for surfacing sentiment. But Ian doesn’t find them helpful for differentiating between a teams’ level of happiness versus its level of impact.

### One-On-One Meetings Should Be Fluid and Unique

There’s much written about one-on-one meetings between managers and their employees, and rightfully so. It’s an important interaction for any coaching relationship. But a by-the-book approach to one-on-one meetings isn’t always a recipe for success. 

**The thing to keep in mind is that there’s no one-size-fits-all approach to these meetings. One-on-ones should be about helping engineers find unique solutions to their unique problems, rather than trying to present a milquetoast solution.** At times, you might need to play the role of advisor, listener or coach. A fluid approach that is authentically yours is best. 

Ian also recommends managers use open-ended questions to guide these conversations. For example, he’ll start a one-on-one meeting with something like, “Hey, someone else has this opinion about something that you are or aren’t doing, what do you think?” 

This opens up the conversation so that they don’t think that you’re attacking or trapping them. Instead, it helps them gain different perspectives on their career path or a work-related problem. 

### How To Avoid Burnout Among Engineers and Managers

Lots of engineers tend to burn out in their twenties. But for Ian, it took a lot longer. It wasn’t until Ian was mid-career when he realized that his workload was no longer sustainable. 

He was taking on too much work, and was such a perfectionist that he couldn’t and wouldn’t delegate that work to other people. He had been working way too hard for too long. He felt a sense of powerlessness: Ian went from eager and motivated to unmotivated and uninspired. 

Eventually Ian realized that he had to slow down and find a solution to being overworked because he was, in fact, burned out. 

For managers, the best advice for avoiding burnout is to first focus on [delegating as much as you can](https://devinterrupted.com/video/always-delegate/). This will free up more time for you to focus on avoiding misses. 

People grow through delegation — so you want to enable your direct reports to make the mistakes for themselves so that they can anticipate and avoid them next time (and hopefully not burn out in the process of learning this all). _This article is based on_ [_an episode of Dev Interrupted_](https://devinterrupted.com/podcast/7-categories-of-engineering-management/)_, featuring expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery._

### Hear the full talk

This advice only scratches the surface of how organizations can make their business more efficient and productive. You can find out much more about the team-of-teams model and how it applies to business by [**listening to our podcast**.](https://devinterrupted.com/podcasts/)

## Real conversations with top engineering leaders

Find us on

[](https://www.linkedin.com/showcase/dev-interrupted/)
[](https://devinterrupted.substack.com/)

## Your next read

[![Cover image for Why Engineering Efficiency Should Win the Dev Productivity Debate](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Untitled_design_28_8426f08c75?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/blog/why-engineering-efficiency-should-win-the-dev-productivity-debate-1)

Dev Interrupted

[Why Engineering Efficiency Should Win the Dev Productivity Debate](https://linearb.io/dev-interrupted/blog/why-engineering-efficiency-should-win-the-dev-productivity-debate-1)

It's time to settle the McKinsey productivity debate.

[![Cover image for How Healthy Engineering Teams Invest Their Time](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Untitled_design_23_f5da1f701d?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/blog/how-healthy-engineering-teams-invest-their-time)

Dev Interrupted

[How Healthy Engineering Teams Invest Their Time](https://linearb.io/dev-interrupted/blog/how-healthy-engineering-teams-invest-their-time)

In a perfect world, leaders could show a direct line between engineering efforts and business impact. In reality, the nature of software engineering is...

[![Cover image for 6 Proven Strategies For Being A Great Platform Engineer](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/ed18598c_47e3_4396_85a6_e7aa6a65e827_1428x842_152822c90f?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/blog/6-proven-strategies-for-being-a-great-platform-engineer)

Dev Interrupted

[6 Proven Strategies For Being A Great Platform Engineer](https://linearb.io/dev-interrupted/blog/6-proven-strategies-for-being-a-great-platform-engineer)

Despite being a relatively new profession, platform engineers already have some tried and true wisdom to rely on.

## Structured data

_Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "LinearB",
  "url": "https://linearb.io/",
  "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg",
  "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.",
  "sameAs": [
    "https://www.linkedin.com/company/linearb"
  ],
  "award": [
    {
      "@type": "Award",
      "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms",
      "dateAwarded": "2026",
      "awardedBy": {
        "@type": "Organization",
        "name": "Gartner®"
      }
    },
    {
      "@type": "Award",
      "name": "Great Place to Work Certification",
      "dateAwarded": "2025-2027",
      "awardedBy": {
        "@type": "Organization",
        "name": "Great Place to Work"
      }
    },
    {
      "@type": "Award",
      "name": "America's Best Startup Employers 2025",
      "dateAwarded": "2025",
      "awardedBy": {
        "@type": "Organization",
        "name": "Forbes Magazine"
      }
    }
  ],
  "hasCertification": [
    {
      "@type": "Certification",
      "name": "SOC 1 Type 2"
    },
    {
      "@type": "Certification",
      "name": "SOC 2 Type 2"
    },
    {
      "@type": "Certification",
      "name": "GDPR Compliance certification"
    },
    {
      "@type": "Certification",
      "name": "ISO 27001"
    }
  ]
}
```

## More on linearb.io

### Top navigation

- [Book a Demo](https://linearb.io/book-a-demo)
- [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews)
- [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights)
- [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact)
- [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server)
- [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation)
- [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization)
- [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting)
- [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance)
- [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support)
- [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience)
- [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience)
- [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys)
- [Platform overview](https://linearb.io/platform/overview)
- [Watch now](https://linearb.io/event/engineering-productivity-gap)
- [Customers](https://linearb.io/customers)
- [Pricing](https://linearb.io/pricing)
- [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb)
- [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework)
- [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq)
- [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security)
- [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy)
- [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts)
- [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources)
- [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops)
- [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report)
- [Blog — Product updates and practical insights](https://linearb.io/blog)
- [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io)
- [API Docs](https://docs.linearb.io/api-overview)
- [Status](https://www.linearbstatus.com/)
- [Integrations](https://linearb.io/integrations)
- [LinearB Library](https://linearb.io/library)
- [Engineering metrics](https://linearb.io/library/engineering-metrics)
- [Platform engineering](https://linearb.io/library/platform-engineering)
- [Engineering glossary](https://linearb.io/library/engineering-glossary)
- [Developer productivity](https://linearb.io/library/developer-productivity)
- [AI in software development](https://linearb.io/library/ai-in-software-development)
- [Engineering management](https://linearb.io/library/engineering-management)
- [Developer experience](https://linearb.io/library/developer-experience)
- [DevOps](https://linearb.io/library/devops)
- [Engineering operations and the context layer](https://linearb.io/library/engineering-operations)
- [Engineering efficiency](https://linearb.io/library/engineering-efficiency)
- [Software delivery](https://linearb.io/library/software-delivery)
- [Research and data](https://linearb.io/library/engineering-benchmarks-and-research)
- [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026)
- [Sign in](https://app.linearb.io/login)
- [Enterprise](https://linearb.io/solutions/enterprise)
- [Contact](https://linearb.io/contact-us)
- [About us](https://linearb.io/about-us)
- [Careers](https://linearb.io/careers)
- [Service agreement](https://linearb.io/services-agreement)
- [Privacy policy](https://linearb.io/privacy-policy)
- [DPA](https://linearb.io/data-processing-agreement)
- [Security FAQ](https://linearb.io/security-faq)
- [Substack](https://devinterrupted.substack.com/)

### Footer

_Additional links from the site footer, not repeated from the top navigation above._

- [GitHub](https://github.com/linear-b)
- [LinkedIn](https://www.linkedin.com/company/linearb)
- [Twitter](https://twitter.com/LinearB_Inc)