Category Archives: Management

by | January 30, 2025 · 10:56 am

What Is A Blocker?

A recent project delay at work put me in mind of this recurring issue I’ve seen with a lot of agile teams. That is, reluctance to call something a blocker. Karthik and I are working on a new revision of our LinkedIn Learning courser “DevOps Foundations: Lean and Agile” so I decided to dig into this a bit.

I think many engineers believe a blocker is “something that prevents me from doing any work whatsoever on this entire project.” This in my experience leads to a lot of project delays and unaddressed issues because something was not identified and communicated widely enough to be swiftly resolved.

This is unfortunately encouraged by some Agile wonks who start hairsplitting with terms. “Well, there’s a blocker and then there’s an impediment,” they say. As I google this, it turns out you can differentiate between “delays, impediments, blockers, and roadblocks. Oh, and dependencies.” And boards, reports, etc. have to do/in progress/done and blockers, not 10 other categories.

Here’s the deal. Most teams out there are not formally trained on PM or agile and have essentially figured out what they know via osmosis. And there’s one term they even vaguely understand, which is “blocker”. (I have never seen a team distinguish formally between blockers and impediments in decades of doing this.).

While I love wordplay as much as the next person, I don’t think this attempt to categorize bad things on the infinite spectrum of bad things is practical, and best belongs as an organic explanation of the impact. Does it prevent you from proceeding on that piece of work? On any work? You can proceed on it but it can’t become done until the thing is resolved? Or it doesn’t technically stop work but it does put the project a week behind? Sure, say it. It’s important to know the impact but it does not change the nature of the existence of an issue and the need to swarm on or escalate it.

The practical definition of a blocker from a team member level is “anything not entirely in my control that is stopping or delaying work now or in the very near future.”

The practical definition of a blocker from a management point of view is “anything that is getting in the way of the team that I need to know about or do something about.”

We have to go back to the entire reason to have a term like “blocker”, which is to allow the team, or failing that their management escalation, to resolve issues that prevent the continued timely flow of work. Period, end of story, if process definition hairsplitting isn’t serving that core goal then do what does.

Definition people love to say something’s not “technically a blocker – yet.” “Well not having a cloud accout to use as the required test fixture isn’t technically a blocker because I won’t need it for another two days, even though there’s been no obvious headway on the request we made to IT for it.” Can anyone seriously contend that’s not a blocker? It’s a problem that is clearly visible on the road ahead, you don’t have to run into it first like my cheap Roomba does in order to escalate it, and doing so is antithetical to the overall agile goal of ensuring smooth and continuous flow. I don’t tolerate “technically true” when it becomes “wilfully dumb.”

Underlying this seems to be some unstated assumption that blockers are “bad” and you are bad for having one or reporting one. And I get it, there’s plenty of bad scrum masters/managers/etc. out there that operate unthinkingly on some Neanderthal level and react as “person say thing I don’t like, person is bad.” (Or the modern tech bro Neanderthal who has some variation of this like “well I need to discourage people from reporting blockers to make them use their masculine energy to pull themselves up by their bootstraps blah blah.”) Sure, toxic people can drive any process off track, that shouldn’t be the default however.

I believe in a healthy Agile environment team members should be encouraged to bring up anything threatening to slow or stop work. It can be a small thing, but it creates an opening for help from the team. Even “I haven’t used this tool before and it’s taking a little longer and I am not sure I’ll get this task done by sprint end” – that’s an opportunity for someone to hop on for a half hour to pair with you or train you.

If you’re off schedule there’s some blocker around, whether it can be handled in the team or needs escalation. You don’t have to escalate everything, though even if the team handled it, schedule or other impacts need to be communicated. For escalations, make it clear it’s an escalation and who to, don’t just assume everyone who gets a status report will seize on all the blocker lines as to dos. “Blocker: No headway on Azure text fixture, it’s needed to complete our work this sprint and will delay us if it’s not in place in 2 days – @ernest we need your help with this one” is perfect.

As someone providing oversight for a lot of sprint teams working on consulting engagements often with client-prescribed milestone deliverables, I keep getting into situations where a sprint full of reporting “no blockers” suddenly turns into “well but of course we won’t have any of the deliverables at sprint end tomorrow.” That makes everyone unhappy, especially me if it’s something I could have urged the client or an external team to provide for the team more promptly. Give people the opportunity to intervene to keep you on track!

I’m going to start adding “definition of blocker” right after “definition of done” in kickoff discussions because of how chronic this issue is – I venture to say I’ve seen it everywhere, it’s just more tolerated in environments where schedules aren’t taken too seriously.

Let me know how you handle this issue, if you encourage a wide definition of blocker, and your experiences on this!

Leave a comment

Filed under Agile, Management

Tagged as , , , , , , , ,

by | May 9, 2023 · 8:01 pm

Career Tip – Managing Up

“What is my manager’s deal, anyway?”

Here’s some career advice that can help you build a more effective relationship with your manager. Remember, they may be a manager but they don’t know everything, or everything that you do, and they are navigating work and life with just as much trepidation as you are! If you haven’t been a manager, it’s sometimes hard to understand why they’re doing what they are and how to best work with them to make both of you happy. So you want to figure out how to “hack” your manager by managing up!

For many years I treated my managers as random-weird-request generators, and frequently worked at cross-purposes with them. until I got advice on managing up and it helped my career.

Managing up, or managing your manager, is an important skill that can contribute to a more productive and positive work environment. Here are some key pieces of advice to effectively manage up:

  1. Understand your manager’s priorities and expectations: Take the time to understand your manager’s goals, preferred communication style, and expectations. Ask them if it’s not obvious! This knowledge will help you align your work and approach accordingly, or at least find a happy medium. (Feel free and tell them the same about you!) Managers usually have a very specific reason for why they’re asking for something and why they are stressing the things they’re stressing; understanding why is the key to understanding them.
  2. Build a strong relationship: Develop a positive and professional relationship with your manager. Be proactive in seeking feedback, understanding their working style, and demonstrating your commitment to achieving shared goals. Our managers try to share the context of what needs to happen with everyone so that they can go do it with autonomy, so reflecting your understanding of and commitment to what’s going on at a high level helps them empower you. If you can help them achieve their goals via a plan you put together, it prevents them needing to “micromanage” by also dictating how to get there.
  3. Communication is key: Maintain open and regular communication with your manager. Keep them informed about your progress, challenges, and any important updates. Be clear, concise, and respectful in your communication, and adapt your style to match your manager’s preferences – remember they have a bunch of people they are trying to wrangle to understand the state of a lot of projects.
  4. Anticipate needs and be proactive: Try to anticipate your manager’s needs and take proactive steps to address them. Take initiative, suggest solutions to problems, and offer assistance when appropriate. Show that you are capable of working independently and taking ownership of your responsibilities.
  5. Make clear asks: Your manager is there to get you what you need to do your job and be happy and healthy. But everyone is different. They don’t know how you prefer to get recognized, or what kind of projects you want to work on, or resources you think you need to be successful… So tell them! They should be trying to figure it out by asking you too, but “communication is hard” and people often make assumptions based on a given situation or communication that may or may not reflect your needs.
  6. Provide solutions, not just problems: When you encounter challenges or issues, avoid simply presenting the problems to your manager. Instead, propose potential solutions or alternatives. This demonstrates your critical thinking and problem-solving skills, and it lightens the burden on your manager by offering actionable suggestions. If you don’t have a good solution to a specific issue it’s fine, but sometimes a manager can become dismissive of someone who “just complains all the time” because it adds work to a limited time without any help.
  7. Seek and act on feedback: Actively seek feedback from your manager on your performance and areas for improvement. Be open to constructive criticism and use it to grow and develop professionally. Demonstrate your willingness to learn and make necessary adjustments based on the feedback received.
  8. Manage your time effectively: Prioritize your tasks, set clear goals, and manage your time efficiently. This will help you meet deadlines, deliver quality work, and reduce the need for constant supervision. Ask if priorities or timings aren’t clear. Your manager dearly wants everyone to be able to do their own thing without any intervention but is held responsible by upper management for outcomes and project schedules/profitability.
  9. Be a team player: Collaborate and foster positive relationships with your colleagues. Support your teammates, share knowledge, and contribute to a cooperative and harmonious work environment. Show that you can work well with others and contribute to the overall success of the team.

Managing up is not about manipulation or trying to control your manager. It’s about building a strong working relationship based on trust, effective communication, and mutual respect. By demonstrating your competence, reliability, and commitment, you can effectively manage up, have the trust and proactive support of your manager, and contribute to your professional growth and success.

(This article partially written by ChatGPT!)

Leave a comment

Filed under Management

by | May 6, 2023 · 12:34 pm

The Value Of Gratefulness


I have been in technology management for more than 20 years now and have worked in a wide variety of shops, and I think I’ve identified a key element that creates a good leader, and that is gratefulness.

Gratefulness Empowers Recognition

Everyone knows that “employee recognition” is important for morale; any company cites it as a priority whether they are really doing it or not. Sometimes it just gets forgotten – but sometimes there’s excuses given not to do it, concerns that it “sounds artifical” or that “they get thanks in form of their salary” or “people will be uncomfortable or jealous.” And some people honestly have a hard time doing it.

I’ve found that those that cultivate an actual spirit of gratefulness within them for other peoples’ work, especially for those who work for you and the sweat of their brow contributes to your success and growth, have an easier time of it.

This shouldn’t be a surprise. The classic Dale Carnegie book How To Win Friends and Influence People is often categorized as a “sales book.” It’s not, it’s way more profound than that and deserves a place in any leader’s library. In its introduction there’s explicitly a story of a man with 314 employees who did nothing but criticize them, then studied the book’s principles, and subsequently turned around his management strategy so he had 314 friends and not 314 enemies, leading to both increased happiness and increased profitability. And Part 2 of the book quickly gets to the “how” – it starts with “Become genuinely interested in other people” and ends with “Make the other person feel important – and do it sincerely.”

I don’t think it’s a shocking revelation that gratefulness leads to better recognition and therefor to better morale, but what I want to get across here is that even if you’re not good at that out of the gate, it can be learned.

And once you learn it, you get more help from other people.

I personally grew up as a very introverted person who was happy alone and on the computer, and not being very interested in others. But in my early career I quickly saw that was holding me back. I wanted to change it so I read How To Win Friends and Influence People and tried to put it into action. Awkwarly and self-consciously at first, of course.

Then something strange started happening to me. People I didn’t know would turn and talk to me in the elevator! I was, frankly, shocked. Generally in my life up to that point, in public I left people alone and they left me alone. I came to the realization that even my demeanor had changed and was more open somehow, and it was causing people I didn’t even know and wasn’t intending to interact with to feel like they could interact with me. And not to hassle me, but to help me.

Ungratefulness Leads To Bad Decisions

For many years I thought that gratefulness was just something that made you friendlier and made recognition easier and so was good in the long term. But then I worked at a startup where the CEO had a deep, fundamental lack of gratefulness, and I saw how that leads to critically bad decisonmaking.

Because people, and people’s work, have value – not in some hug-filled hippie sense, but in a very tangible sense. At the company in question the CEO came to me several times wanting to fire an engineer who had legit written 80% of the working product code in the shop “because he doesn’t think architect level.” He ousted a co-founder who was the only person who had actually brought in sales for the company. So years later it was a startup that had trouble even creating a shipping product and certainly wasn’t growing revenue, and had – seriously estimating – about 300% employee turnover in its lifetime. He sabotaged his own company because he couldn’t look at even objective value creation (working code! shipping product! sales revenue!) and value those who generate it at all.

That really made me stop and think. The stereotype of the ungrateful leader is one that only values hard objective results and “is mean” to people otherwise, but my experience has led me to the conclusion that’s a false dichotomy – if you are unable to see value you’re going to be unable to see it whether it’s in a person or in github or on a ledger book. Especially in a sector where that value is being created by the skilled workers!

Instead, you want to train yourself to see value so that you can gather more of it and help it grow! It’s not just being a kind leader because that’s “in” this decade, gratefulness is actually a strength you can develop that helps you make effective decisions.

Leave a comment

Filed under Management

Tagged as , ,

by | January 10, 2023 · 2:46 pm

DevOps for Managers Library

James and I are working on a LinkedIn Learning course entitled “DevOps for Managers” and I wanted to share some of the books we love that we’ve found helpful in preparing it! We’d love to hear books you think are indispensable for DevOps managers. We’ve generally omitted general management books like First, Break All The Rules and DevOps non-management-specific books like Continuous Delivery, trying to focus on the specific intersection of tech and management.

Here’s our list, post yours in comments!

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win and The Unicorn Project: A Novel About Developers, Digital Disruption, and Thriving in the Age of Data by Gene Kim et al. demonstrate the benefits of DevOps transformations on an organization in a story format.

Accelerate: Building and Scaling High Performing Technology Organizations by Forsgren, Humble, and Kim gathers the DORA research on DevOps into a summary of how to practice high performance leadership and management.

The DevOps Handbook: How To Create World-Class Agility, Reliability, & Security in Technology Organizations by Kim, Humble, Debois, and Willis is an encyclopedic guide to implementing the Three Ways in an organization.

An Elegant Puzzle: Systems of Engineering Management by Will Larson is specifically about managing modern engineering teams.

Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais focuses on team organization and the communication and outcome ramifications thereof.

Turn the Ship Around!: A True Story of Turning Followers into Leaders by David Marquet isn’t DevOps specific but is a great description of how to enable meaningful decision making at the lowest level. 

Measure What Matters: OKRs – The SImple Idea That Drives 10x Growth by John Doerr describes how to set goals using OKRs and avoid many of the naive goal-setting pitfalls that beset organizations that decide they want to be goal driven.

Smart & Gets Things Done: Joel Spoksly’s Concise Guide To Finding The Best Technical Talent by Joel Spolsky talks about how to attract, hire, and retain the best engineers.

The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t by Robert Sutton talks about traits to screen out to ensure a collaborative organization.

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp has a good bit of engineer-managing wisdom.

The Lean Mindset: Ask The Right Questions by Mary and Tom Poppendieck shows how to focus your thoughts and iterate towards good products, including your internal products and services.

Building a StoryBrand: Clarify Your Message So Customers Will Listen by Donald Miller is intended for Marketing but for DevOps, especially platform teams, being able to concisely define and communicate your value is key.

A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz helps IT leaders take on Agile, Lean, and DevOps.

I’ve heard about Camille Fournier’s The Manager’s Path, Julie Zhuo’s The Making of a Manager, and Lara Hogan’s Resilient Management but haven’t read any of them yet so can’t vouch.

1 Comment

Filed under DevOps, Management

Tagged as , , ,

by | October 18, 2019 · 1:53 pm

Ask A Tech Manager

We had a really interesting joint CloudAustin/Austin DevOps meeting this week – a tech manager panel!  Ask them anything!  We had 92 people attend and we had to herd them all out of the building with sticks at the end because everyone had so many questions that even at two hours it was still going strong.

My takeaways:

  • Understanding managers’ viewpoint and goals is critical to an individual engineer when looking to get hired or promoted or whatever.
  • Managers want you to be successful – you being successful vs you not being successful (and/or leaving or being let go) is a huge win for them in all ways.
  • Looking for a job?
    • Your resume should be tuned to a job and either through its top section or a cover letter tell a story. Hiring managers get 100-200 applications/resumes per job. They don’t expect you to have everything on the job application – “50% is fine” was the consensus. But they’re doing a first cut before they talk to you, and a lot of people spam resumes, so if your resume doesn’t clearly say why you, add something that does.
    • For a Cloud Engineer position, for example, there’s a big difference between a random UNIX admin resume and a random UNIX admin resume that says “I’m excited about cloud and working towards an AWS certification on the side and really want to find a new job I can do cloud in.” The first one is discarded without comment, the second one can move ahead if they’re willing for people to learn – and given the “50%” thing, they are generally willing for people to lean, if those people are willing to learn!
  • Interviewing for a job?
    • Everyone hates every different interviewing tactic (see Hiring is Broken, and we have the Ultimate Fix) – individual interviews, panel interviews. whiteboard design, online coding, takehome projects, poring over your resume, checking your github, looking at your social meda/blog/whatever. But in the end hiring managers are just trying a handful of things to see if they can figure out if you know what you need to know to do the job.
    • They can’t just take your word for it – their reputation is on the line when they bring people in, and you reflect on them. They want to understand if you’ll be successful. Recruiting, hiring, onboarding cost a lot of money so they can only take so much of a risk – they’re not real particular what the form “proof you can do the job” takes, they’re just fishing for something.
  • Performance issues?
    • If you’re having some outside problem, talk to your manager. People we work with are a cross-section of just plain people, and we expect every medical, psychological, marital, criminal, etc. issue to show up at some point.
    • Communicate. Again, it’s in their best interest you succeed. No one “wants to get rid of you.”
    • Unreasonable demands?  Communicate.  Lots of technical staff work long hours or do the wrong things because they don’t “manage up” well and communicate.  “Hey, with this change I have way too much to get done in 40-50 hours, this is what I think my priority list is, this is what will fall off, what can we do about it?” Bosses don’t know what you’re doing every minute of the day and can’t read your mind. I’ve personally worked with engineers burning themselves out while their same-team colleagues aren’t because they aren’t managing themselves – though they think it’s outside forces bullying them.
  • How to get ahead?
    • Understand the options.  What are career paths there?  How do raises and promotions work? What are the cycles, pools, etc – you can only work the system if you understand the system. Managers are happy to explain.
    • Communicate.  No one knows if you want to move into management or not, or feel like you’re due a promotion or not, if you don’t talk about it with them over time. You have to take charge of your own development – companies want to help you develop but a manager has N reports and a lot of things to worry about, they aren’t going to drive it for you.
    • Listen.  What is needed to get to that Lead Engineer position?  “Slingin’ code” and “being here for 3 years” are, I guarantee, not much of that list of requirements. Usually things like leadership, image, communication, and exposure have a role. Read “How To Win Friends And Influence People” and stuff if you need to. “I just grind code by myself all day” is fine but there’s a max level to which you will rise doing so.

Anyway, thanks to all the managers that participated and all the attendees that grilled them!  I hope it helped people understand better how to guide their own careers.

Leave a comment

Filed under Management

Tagged as , , , , , ,