Skip to content

September 22, 2020

Managing People, Not Resources in a DevOps Enterprise

By Mirco Hering

This post is adapted from the book DevOps for the Modern Enterprise by Mirco Hering.

Some people react allergically when you call people resources and talk about managing resources. While not exactly allergic, I agree with the underlying sentiment.

A resource is something you can manage without much tailoring; you can treat one bag of sand like the next bag of sand when it comes to making dikes.

With people, that is never true. We have probably all been planning for projects and creating a plan that includes a certain amount of “anonymous full-time equivalents (FTEs).” Then a bit later, we start putting names to it and realize that we need more or less effort based on the actual people we have available for the project. One Java developer is just not the same as another; and honestly, we would never consider ourselves to be just a resource whose job someone else could do with the same efficiency and effectiveness.

So, why do we then pretend that we can manage our people like anonymous resources?

For me, it comes back to that legacy thinking inspired by manufacturing, where replacing a worker on the assembly line was actually much easier than it would be today to replace a Java developer. In this post, I will provide some guidance on how to approach management using humanistic practices.

The beauty of this approach is that it is valid across the organization, from the first line manager all the way up to the CIO. And after all, the way people are being managed in your organization has a huge influence on your culture. So, getting this right, setting the right example, and encouraging the people who work for you to follow the same can make a real difference.

1) Have One-On-Ones

The first practice that I want you all to do (if you are not doing it already) is to have regular one-on-one meetings with the people who report directly to you. It’s very hard to manage someone as a person when she is just an anonymous entity that you only know through her work product.

And no, having an open-door policy is not the same as setting up one-on-ones. With an open-door policy, your directs might still feel that they are imposing themselves on you, and the resulting meetings might have less structure than you would like them to have.

  • When you set up the meetings and follow through it sends the sign that your people are important to you; that you are making time for them.
  • A weekly or biweekly thirty-minute slot works out very well. You want to use this meeting to learn more about the person over time, without it feeling like an interrogation.
  • Always direct the first part of the meeting to raise anything she has to say or ask, and then provide your updates and information that could be important for her afterward.
  • One-on-ones not only provide you with the opportunity to get to know the person, they will also make you more effective as a manager, increasing the time you have to focus on your job. This is possible because the people who work for you won’t disrupt you during the week with non-urgent queries, as they know they have time within each week (or every other week) when they can receive guidance on all of those things.

2) Give Feedback

Just about everyone I know would like to get more feedback from his or her boss. But as bosses, we are often uncomfortable giving feedback (especially the constructive kind that requires behavior adjustment; positive feedback is somewhat easier).

If you think about it, you probably learn the most from constructive feedback, but it is a bit uncomfortable to give. Plus, there are good ways to give feedback, and there are bad ways. I come back to Dan Pink’s mastery, autonomy, and purpose.

  • Your feedback should focus on concrete situations that are recent, not generalizations such as “you are often late” or “your work product is not of good quality.”
  • It should describe the impact the behavior had and should ask for a change in behavior. An example: “When you don’t use an agenda for a meeting like you did this morning with our vendor, we spend a lot of time discussing with no clear outcome in mind, and don’t achieve a result. Could you do this differently next time?”
  • Focus on three key elements of feedback: behavior, consequence, and the need to change. “When you do x, y happens, which is not optimal. Can you find a way to do it differently next time to lead to a better outcome?” And you can use the same template for positive feedback. 

3) Delegate

When I started as a manager, I felt bad delegating work that I could do myself or that was not terribly rewarding (e.g., filling in forms). Listening to the podcast Manager Tools, I learned of a concept called “Managerial Economics 101,” which means that if the same task can be done by someone with a lower cost rate, then it is uneconomic to not delegate it. 

The key to making delegation meaningful for the employee is to use the three motivators during the delegation process.

  1. Explain how the tasks will help them learn something new.
  2. How it helps you as a manager to do your job better.
  3. And after the initial handover, let the employee determine the best way to do it as long as the outcome is correct.

An example could be: “Michael, could you please help me by doing the weekly status reporting going forward? When you take care of this for me, I can focus on preparing the key messages for the meeting, which allows me to present the progress of our project much better to our stakeholders. The reports need to follow our standard template for status. I am happy to show you how I did it in the past, but I will leave it to you to determine the best way going forward. I am happy to do the report together for the first couple of times. Do you have any questions about the task?”

4) Create a Blameless Culture

As a boss, your job is to protect the individuals on your team from outside criticism.

  • When a problem occurs on your team, you have to cover it without delegating blame to a person on your team who is responsible. The team will appreciate this.
  • For praise, the opposite is true: the more you share the positive impact a member of your team has made, the better you will look too.

These two practices empower the people on your team to do the best job they can for you. And the rest of the organization will always hold you accountable for the results of your team anyway, so pushing blame further down or withholding praise actually does nothing positive for you.

- About The Authors
Avatar photo

Mirco Hering

For over ten years Mirco Hering has worked on accelerating software delivery through innovative approaches (what is now called DevOps) and six years ago started experimenting with Agile methods. He supports major public and private sector companies in Australia and overseas in their search for efficient IT delivery. Mirco also blogs about IT delivery at and speaks globally at conferences about Agile, DevOps and organizational psychology. Follow Mirco at Twitter @MircoHering.

Follow Mirco on Social Media


  • aconex oracle Mar 9, 2022 1:01 am

    Project management software solutions are rather versatile. They allow professionals to plan their projects, relying on informative insights from the past.

  • Philippe GUENET Oct 6, 2020 6:36 pm

    To be honest those advices keep the manager at the epicentre of the work, which is part of the problem and the resulting dysfunction. In digital, the concept of flow should apply, in the way that the work should happen naturally without needing the manager to coordinate it. The role of a manager is to drive improvements of the work system that they do not need to be at the epicentre of it all for output/outcomes to happen: From the flow of delivery to the flow of innovation, improvements, industrialisation, etc. The leadership (not manager) needs to distribute the ownership to the people doing the work without diluting accountability, involve them in the Strategy so they have the right elements to make the right decision, stimulate Kaizen to improve continuously, etc. Achieving all this is mostly about shifting the leadership from leading Tasks / Projects / Programmes / Budgets to leading people, outcomes, better practices, better competencies, and positioning Leadership as a System (human work system) connector and catalyst rather than coordinator. This is what the real change is about.

    • Ron Oct 11, 2020 6:45 pm

      Well said Phillippe. This perpetuates Taylorism. Note to everyone: there is no such thing as a defined role of lead or manager in Agile, Scrum or DevOps.

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    Essential Reads for the DevOps Beginner
    By IT Revolution

    The most frequent question we get asked is how a team or organization can…

    Editor’s Corner: How to Write a Book Introduction
    By IT Revolution

    One of the most important elements in a book is the introduction. This is…

    Is Agile Auditing Enough?
    By Clarissa Lucas

    This post has been adapted from the Introduction to Beyond Agile Auditing: Three Practices…

    Frankenstein vs. the Gingerbread Man
    By Leah Brown

    In a previous post, we mentioned how the new book by Mark Schwartz, Adaptive…