By the time you realize you have a serious IT culture problem, the situation will be hard to fix. Consider these signs your culture is starting to crack – and how to respond.
Bad DevOps bosses: How to deal with them
Are you working for a micromanager in agile clothing? Or (gasp) is it you? Check out this advice on fixing the friction
Just about everyone in the working world has a “bad boss” story.
In IT, a modern iteration of that archetype poses particular problems for the DevOps age: The command-and-control manager in agile clothing. They shout things like “innovate!” and “agile!” – perhaps literally, in some cases. They pretend to embrace DevOps culture as a means of doing more and doing it faster. But in reality, they’re micromanagers who aren’t removing any of the bottlenecks, silos, and broken processes that made DevOps necessary in the first place.
If that sounds like your boss, well, we’re here for you. In this post, we’ll share some quick tips on “managing up” with this particular type of leader in a DevOps environment. (Some small consolation for you: The so-called “bad” boss probably isn’t a bad person. In fact, they might not even be aware of the characteristics or behaviors that are impeding a healthy DevOps culture.)
[ Are you known as a leader with high or low EQ? See our related story, 10 things leaders with emotional intelligence never do. ]
“The ‘bad boss’ scenario can happen with the best of intentions,” says Ian Buchanan, developer advocate at Atlassian.
Of course, you might be the boss – in which case, it’s up to you to ensure that you work on your weak spots, before your DevOps talent vanishes. We’ve got you covered, too, with some expert advice on continuous improvement for the DevOps age.
[ Are you a DevOps job seeker or a hiring manager? Get our free resource: The Ultimate DevOps Hiring Guide. ]
If you work for the bad DevOps boss...
Maybe you’ve read the DevOps book The Phoenix Project, with its fictional tale of a DevOps journey at the company Parts Unlimited. Atlassian’s Buchanan has often asked a question at various DevOpsDays events in the past: “What would Brent do?”
The story’s protagonist is Bill, the recently named VP of IT operations who endeavors to change how IT works. Brent, on the other hand, is the veteran IT pro in the trenches that every single project seems to depend upon.
“My question is about the role Brent could play as a transformational leader from the grassroots,” Buchanan explains. “Could Brent have driven a DevOps transformation at Parts Unlimited?”
To paraphrase Buchanan’s take: Yes.
It just requires reframing Bill’s executive-level strategies for driving positive change – systems thinking, amplifying feedback, and an experimental mindset – for a bottom-up approach.
Buchanan shares some examples of this in practice:
- “First, try to understand the forces causing your micromanaging boss to act that way,” Buchanan says. “Perhaps the PMO has tied his or her hands with a rigid Gantt chart.” DevOps culture depends on greater empathy, not just between functional teams, but up and down the org chart.
- “Second, learn to manage your own time as a finite resource so you can limit your work in progress,” Buchanan advises. “Quality begins with the right to say no, so assert it.”
- “Finally, focus on small, practical changes with tangible outcomes, not ‘DevOps as a goal,’” Buchanan says. This last one is particularly important because, yes, there are some limits to how much change an individual can drive from the trenches. Be pragmatic. Change might start with a simple question that’s actually intended to drive a particular outcome. Buchanan offers this example: "Hey, boss, can we try a pre-mortem in this sprint to uncover deployment risks?"
Buchanan shares another example from his own career, when he was managing a small team of just two other developers, that reveals that the “bad” boss is often anything but. They just need some help understanding the problem at hand.
“Between the mission and the small team, I felt compelled to be involved in cleaning up technical debt around builds and repository structures. Meanwhile, my small team had a growing frustration: They didn't know who these products were serving or where the products were heading,” Buchanan recalls. “In a moment of courage, one of my devs teased me about writing Maven instead of user stories. I got the message and turned focus to connecting my team with our customers and building out a vision across all the products.”
Keep reading for advice if you're the boss: