Red Hat Agile Coach Jen Krieger has extensive experience working with development teams on a wide range of projects. Currently, she’s focused on Project Atomic. his experience has given her great insights into what makes teams and projects work and what roadblocks get in the way. In this podcast, Jen shares those insights as well as specific steps that you can take to make your DevOps initiatives successful.
Listen to MP3 (17:21)
Listen to OGG (17:21)
[Transcript]
Gordon Haff: Hi, everyone. This is Gordon Haff at Red Hat with another edition of the "Cloudy Chat" podcast. We're going to go back to DevOps today. I'm speaking with Jen Krieger, who is an agile coach at Red Hat.
Our topic for today is, "What are the inhibitors to getting DevOps done right at your organization, at multiple levels within the organization?" Jen, welcome. What is the first thing that comes to mind that gets in the way of successful DevOps?
Jen Krieger: If you go online, and you type in "Cultural blockers to DevOps" in the Google and look at that search, you'll probably see the majority of the answers are going to be somewhere in the realm of two words, the first one being "trust," and the second one being "empathy."
What I rarely see, or maybe I do, but perhaps not necessarily directed at an individual, or an executive is, what things people can do to change those things. As in, "How can I be more trustworthy of my co‑workers," or "How can I have more empathy?"
It's easy to just tell somebody to more empathetic, but maybe not so easy in individual situations, or maybe it's hard to remember those things.
One of the things I'd like to tell people in general, especially the individual contributors is, when we're talking about trust and empathy a lot of times, it's hard to get to that place. As in, you have a collaborator sitting next to you, and they're doing something that is making you unhappy, or they've done something that has blown up your work week, because they did something wrong.
It's hard for you to have that empathy, especially if there is a sense of competition in the workplace. I've been at many companies now. A large portion of them, there's always seems to be a limited number of jobs, limited number of promotions, limited number of salary increases. I've heard, "Well, we only have X number of percent for salary increases or bonuses this quarter, and you got more than so and so."
The conversation always seems to breed competition, making it less likely that I want to cooperate with somebody, because I want that additional money. What I think employers don't understand is, when they are putting their employees in that situation.
They're starting to allow for this situation occur, where the co‑worker or the individual was not only competing with the people around them, but they're also starting to compare the company that they're working with to other companies, even competitors.
You're not only breeding competition internally, but you're also breeding competition with the people outside of your workplace.
This is not an easy problem to solve. No one has unlimited money to do whatever they want with it. No one has an unlimited number of promotions.
There's not always spaces for everybody in management, or wherever they want to take their career. There are some things that we can do as an organization that alleviate some of those situations, to help everyone.
At the executive level, what I like to tell people is, "We need to start looking at the tech industry." There is an alarming trend sometimes, where we hire and promote technical people into management positions, because they're really great technologists.
Maybe not so great at being the kind of person, who is interested in mentoring an employee, or interested in employee development.
A lot of companies will do this thing, where they have almost like a one‑size‑fits‑all employment development plans. If you are somebody who likes a lot of hands‑on interaction is probably a good situation for you, because you'll have those touch points with your manager, and they're pretty structured.
If you're somebody who is more introverted or not interested in having that conversation, then it can be overwhelming for you to have that constant touch point with your manager. Having somebody who doesn't really understand employees and individual and needs an individual‑employee development plan or individualized attention is going to be hard.
Especially if that person is more interested in the technology side of things, versus the human interaction and development side of their job.
I also like to tell them that encouraging spot awards or some sort of system, where individuals can award individuals, or individuals can award executives or vice versa, where you just have a pool of money or a pool of points or some way to say, "Hey, thank you so much for what you did, " and to use that as a way to recognize people.
You can be an individual contributor, instead of having a verbal conversation saying, "Thank you for what you did," something that doesn't get tracked, something that your boss doesn't know about, or something that when the next promotion comes up, no one knows about.
Having those automated spot awards or some sort of system that's tracked for that, cannot only help teams feel little more cooperative with one another as in, "Hey, we're all working together to get something done."
Also, help management find introverts in their organization, who may not be speaking up and may not be saying, "Hey, look at what I did over here," they may be always had astound doing a fantastic job. Therefore, no one notices what it is they're doing for the organization. I would also encourage HR to be actively included in those conversations, because these are conversation rewards.
Gordon: That's one specific, concrete thing that you've just been discussing there around peer rewards, and peer recognition. One of the things we often hear about DevOps is, it's important to have top‑down support for a DevOps initiative. Imagine you're talking to somebody at company Acme, at executive level. They really will drive these DevOps thing within their organization.
A couple of questions. First of all, what might circumstances be at Acme that you just tell them you're not ready to start today? Conversely, what might be some specific things that you tell them that you then really need to put in place, so that you can have a successful DevOps initiative?
Jen: It's hard, because you have to ask that executive to be introspectful about what it is they're doing, and who they've actually employed. I would say, if you have an organization that is actively interested in withholding information from employees. I'm not talking like, "We're going to require this brand‑new company. We can't tell anybody right now."
If you're more like, "We have this important project, but we'll just keep that information to ourselves right now, and then surprise everybody later." If you're withholding information or not actively sharing what's going on, I would say it's going to be really hard for you to have success.
If you are an executive that speaks and acts inconsistently, so you say one thing to one person, and then something different to the next, is going to be hard to maintain a culture of trust, equally hard to maintain a culture of empathy, especially if you are pitting to people against one another for resources, money, hardware, anything that you could see would be needed to get their jobs done.
If you're not necessarily open to listening to ideas from people who report to you, or maybe you're close‑minded to change, as in somebody says, "Hey, I've got this idea," or "I think we might be doing this wrong," and you're not willing to even have the conversation, or you're threatened by that conversation, I would say probably this is not the right step for you.
Gordon: What sort of change is at the individual level that really needs to be made, compared to what's more standard types of practices?
Jen: Especially for the concept of trust and empathy, a lot of times, we as humans, struggle with the word "jealousy." We are so used to comparing ourselves to the other people around us. Like, "Someone's got a new car. I guess I should get one too," or "My friend got a new phone, I need to get a new phone too."
That's probably a really good place for an individual contributing to start is start thinking about jealousy, thinking about "Why did so and so get that job over me," or "Why did they get recognition and I didn't." It's definitely been a topic that I struggled with, when I was younger.
Certainly in my career, I was always wondering why somebody got a promotion over me, or why somebody got something that I, in the moment thought I wanted. What really helped me get over that whole concept was to set attainable goals for myself. The keyword there is "attainable." For me, it's not "I want to be CEO of company X, and I want to make half a million dollars a year."
It's "I want to go and pass a certification exam, so that eventually, I can get this promotion," or "Set a clear educational goal or personal improvement goal." One of my most recent goals is to work a no more than 45‑to‑50‑hour work week. What I do for that is, I keep an eye on how long I'm working during the week, so that I'm not exceeding that.
That's mostly so that I can also have personal goals that I'm trying to meet, or keep my work out of my personal life. Things like that, what that can help an individual to do is to, when you see somebody at work, "Hey, I have a co‑worker who is in a very similar role gets promotion." I say, "Gosh, darn it. I wish I had gotten that."
What I can do is look at my already written down goals and say, "Wait a minute. Here are the three reasons why that really wasn't what I wanted, because that promotion's may come with X number of additional hours and more responsibility. Yeah, maybe it will be coming with more money, but that wasn't part of my goal set."
Maybe I didn't have a goal to make more money in the moment. Having that pre‑written down listed goals, at least for me, it helps me to know whether or not, I really should be jealous or not. I shouldn't be like, "Oh gosh. I wish I got that job." In the situation in which I feel like I should, I was really was something that I wanted.
Jealousy, disappointment, all that kind of stuff comes with that. Then, I have to be really serious and honest with myself and just ask question, "What should I have done differently, so that I could have actually been that person who got what that other person wanted?" Honestly, these are not easy questions or things to work through.
It can be hard. Even for me, it's very hard for me to set those goals. I recommend that you find a friend or a mentor, or somebody in your field of profession. Maybe not necessarily directly as working at the company they're working on, because it might be harder to talk about things and blunt in real terms, if you're working at the same company.
Find somebody that you can talk to and help stick to the goals that you've written down, so you're not being lose about it.
Gordon: You worked with teams, some of which have certainly been successful. I assume at various times in the past, maybe not so successful on projects. What are the characteristics that jump to mind as contrasting those two situations?
Jen: I worked on things that has been complete disasters. I worked on projects that prevented any enhancements going to production for almost a year, which to me is a terrible situation to be in, when you're working with a company that needs to get enhancements into the product they're working on. They can't because of the technical situation you're in.
Even with that team, they were surrounded by just a tremendous problem, which is the reason why it took them so long. It was not an insignificant project to take on. There are two things that could have made them more successful. Technology today makes it a lot more attainable, which it perhaps was not back then. The first thing obviously for me is always teamwork.
I laugh, because every time I use that phrase, I always think of "The IT Crowd," and there is a section that I absolutely love. I recommend everybody go and watch it. Just type in YouTube IT Crowd team, team, team, and you will pull up that video. It's interesting to me, because I'm kind of snarky about it, the whole concept of teamwork.
I've also seen teams that can work together so well, that even when they're faced with a project that is absolutely going to fail, they still seem to make progress or still seem to recover from that failure, much faster than a team that had a failure, and was catastrophic to their work, their working environment, their work relationships, and everything that goes into it.
What I'd want to see is a situation where even in a failing team, it did not take them weeks and months to get back to those state in which they were working at before the failure. That they can just say, "OK. We failed, no big deal. Tomorrow is a new day. We're going to see how we can prevent that from happening in the past."
That teamwork, that trust, the empathy, the lack of finger pointing, is a critical component of success on projects. I had a second one and I cannot sip in my minds right now. perhaps we'll some back, if that comes back to me.
Gordon: In the interest of Internet, top five list or top 10 list or what not, briefly, what are five things if you're thinking about starting a DevOps project? What should you should put in place today, tomorrow, next week, to make sure you're successful.
Jen: For me, the number one thing would be to look into blameless retrospectives or pre‑mortems. What are you going to do, if something goes wrong? Have a plan before it goes wrong. Have a conversation before release. Say, "What are all the things that could be gulches, and come up with a plan to address them?"
A lot of times, project managers call those "risk analyses." It can be off‑putting when you call it a risk analysis, but do them. It doesn't have to be to the level that some project managers will do it. Have the conversation. It's probably a good idea to have that culture in place before something goes wrong.
Look into if you have a management structure in place that is firm, and there's not a whole lot of employee development going on. Look into training to see if there's something that you can do in your organization, to help guide managers in a direction that will encourage them to look at their employees as individuals, and try to change the way that you are mentoring people internally.
Individuals have a list of goals. Sometimes, those goals are going to guide you out of the company you're working at. That can be quite scary, but have your personal goals. Make sure that you know individually what it is that you are going to be comfortable doing, specifically in the case of...for me, sometimes when you are going into a situation, where you're saying, "I'm going to do "DevOps. My organization's going to be great."
Sometimes, that comes with the reality of you're going to have to do the right thing. The right thing is not always going to be popular. Make sure you understand where your boundaries are before you get to that point, so is your boundary. "I'm going to do the right thing, until I get fired, because of it," or "I'm going to do the right thing until this point in times happens, and then I'll let it go."
Just know what your boundaries are as an individual. The final one is, make sure that you have a system in place to do some sort of awarding, some sort of recognition that is not manager down recognition, because manger down recognition if you're already having a problem with your managers, who are not interested in employee development. It's not that they're not interested, but they don't know how to.
It's going to be really hard to encourage a system of collaboration or teamwork, if there's no way for a team member to say thank you to another team member other than just saying thank you. Thank you's are great, but having some way to track. Even monetary words are great. Something is better than words. Those are my top five, right now.
Gordon: Great. Thanks, Jen. Anything else you'd like to add in closing?
Jen: Nope. That's it.
