Don’t Call Them Soft Skills | DevOps Experience 2023

Welcome everyone, and thank you for joining me for my topic today at DevOps experience 2023. As you can tell from the slide, I'm gonna be talking about, uh, what is generally known as soft skills, but what I like to think of as the more cultural intangible skills that are really harder than most people think. So, you might be reading soft skills and think we're gonna be talking about a bunch of fluff today, but believe me, this topic is as critical and as hard as any algorithm or security control.

So buckle up. For those of you who don't know me, my background is in defense and aerospace. My name is Katie Craig.

I've been working in the industry for several decades now. Um, I've, I'm an engineering consultant. I'm a graduate school professor in, uh, cybersecurity, and I'm a certified psychological safety coach.

So, um, I have a little bit of experience with this topic, but enough about me, let's just dive in. So, what are soft skills? Anyway, we're gonna be talking about this and the misnomer, calling them soft skills is really a misnomer because when it comes to interpersonal relations and dealing with teams and group dynamics, that can be kind of challenging.

So that's why I think calling them soft skills is a misnomer. We'll talk a little bit about the pillars of DevSecOps and where does, you know, people management and these quote unquote soft skills come in. And when it relates to DevOps, we'll talk a little bit about psychological safety and the importance of it in teams and group dynamics.

And then we'll bring it back to DevSecOps and how this all fits in and how it's going to strengthen your teams, especially if you have geographically dispersed teams. And then we'll conclude, and I'll summarize. So what are soft skills anyway?

I mean, there's a common perception that's got soft skills are secondary to technical skills. I mean, consider the resumes and the CVS that we have that detail our work experience. There's nothing in there really that speaks to our ability to build strong relationships or to form genuine connections.

And those things are very important to building strong teams that are trusting, that are vulnerable, that are transparent. And what we know from science is that innovation in teams really relies on folks being trusting and transparent. And so we should not undervalue these skills.

We should not think of them as secondary to technical skills. Um, soft skills have a, you know, a reputation as being soft, but they're not the marshmallows that you bring to the hard skills campfire that's misleading. Soft skills are almost undervalued, but are overly important for the, for the performance of your teams.

So they're essential soft skills or the relationship skills, um, are the, that holds the muscles to the bones, and without them, the whole system could collapse. So in DevOps, where collaboration is key, undervaluing these human connections, and you know, how we relate to one another, that's like ignoring a bug in your software code, and that's gonna come back and bite, bite you much later. So this is DevOps, uh, experience.

I'm sure everybody in the audience is very familiar with the tenets of DevOps and DevSecOps most recently. But the missing pillar, um, in DevOps is psychological safety. It's how we interact with each other, how we treat each other, how we speak to each other, how we welcome each other.

Um, psychological safety can, or a lack of psychological safety can easily break the DevOps chain. When we talk about DevOps, we talk about C I C D pipelines and automation, and of course we talk about the cloud, but we often overlook the human factor. And so today I'm proposing we add another pillar to this DevOps, uh, framework and talk about psychological safety.

Because if your team doesn't feel safe enough to express their concerns, then problems and bugs are gonna be hidden. They're gonna go unlooked un unnoticed, and your C I C D pipeline will be as good as a water pipe with a, a leak in it, a hole in it. So psychological safety or the quote unquote soft skills are critical to your DevOp DevSecOps teams in order to bring forth the best ideas and the most innovative solutions, um, when you're faced with challenges.

So what is psychological safety anyway? Well, it is about more than just feeling good. Psychological safety fosters innovation and encourages risk taking on your teams.

And while some might think that risk taking is, you know, not something that we want to encourage for innovation and, um, and novel solutions, it does take a little bit of risk taking some what if type thinking, the measurable impact on productivity and code quality from psychological safety is very apparent. And so it's not just about everybody feeling warm and fuzzy, it's about everyone feeling secure and confident about their place on the team, about being able to contribute their ideas, contribute their thoughts, no matter how far out in left field, how cockamamie the solution might be. Psychological safety helps everyone feel grounded and secure, where they can dare to speak up, they can dare to fail.

When we talk about DevOps, we always talk about fail fast, fail often, fail early, fail safe. Well, failing is a very scary thing to do. And without psychological safety, a lot of people will choose not to fail, will choose not to go out on the li limb, to will not put their neck on the line and will not offer their solution because they will fear the re retributions of a psychologically unsafe team or a psychologically unsafe environment.

So it's about creating an environment where people can speak up, can contribute, can dare to fail. Creativity isn't just welcomed, it's celebrated. And a bad idea isn't ridiculed.

It's the seed for 10 more good ones. And so we welcome the, these novel solutions and crazy ideas. And you know, we point back to the studies that have shown that teams with high psychological safety are not only happier, but they produce higher quality code, higher quality solutions, and they've got both bark and bite.

So what can a lack of psychological safety re lead to? Well, if your team doesn't have psychological safety, not only is there gonna be burnout and toxicity, but you're probably gonna get a lot of turnover. Uh, folks won't stay around very long if their teams are not psychologically safe.

So the impacts of toxicity on turnover rates cannot be overestimated. Burnout isn't a bug, it's a feature in a toxic environment. And so, you know, in toxic environments, people are treated as a means to an end and more transactionally than you know, authentically or genuinely.

And so when you use people as a means, they do, you know, tend to burn out, they tend to feel un unappreciated. It's hard to get energy up, you know, to meet the challenges of a day. And the psychological safety or lack of it is what leads to that toxicity in the environment.

And when people don't feel safe, they leave. And we see this a lot in the workforce where people will just depart and go find another place to work. It's been said, um, it's, it's almost a truism that people don't leave bad jobs, they leave bad managers or bad supervisors.

And so for the leaders in the audience, it is your responsibility to try and foster an environment of psychological safety so that your people won't experience toxicity, and your culture won't be one of burnout where you're just churning through people. And it's a revolving door of engineers coming and going. It's not an exception either.

Burnout isn't an exception. It's written into the job description in toxic environments. So no one's applying for that role.

And some of the activities that lead to this type of burnout and toxicity are the more competitive, um, aspects of work where there's competitive feelings, where there's, um, naming, shaming and blaming and one upmanship and trying to elevate oneself at the expense of others. Those are all behaviors that don't lend themselves to psychological safety or trusting and transparent and brave teams. So there's been, um, lots of really, um, impressive success stories about psychological safety, bringing about huge changes in organizations.

There's also been cases of, um, absence and where it led to failure. Companies like Pixar and Google and NASA organizations like NASA have shown significant productivity spikes after implementing psychological safety measures. And on the flip side, there's horror stories where ignoring the human element led to failure.

And so again, it's a truism, it's pithy. You know, we hear it all the time. People are our greatest asset, people are our greatest resource, but how genuinely are we treating them?

As such, how authentically are we treating people as the most valuable resource in our organization? I would, I would argue that too often we don't treat each other as humans, just meet each other as humans and, you know, provide some psychological safety so that they can be their authentic, genuine self and offer their ideas and solutions without fear of retribution or naming or shaming or being blamed if there's a mistake, because a mistake is an opportunity to learn a mistake or a failure is an opportunity to test further earlier in the process to avoid it from happening again. It's really a mindset and a shift in how we choose to look at things like failures and problems.

So implementation. How do we foster psychological safety in our teams? Uh, that falls back on leadership, quick wins to get started.

You can create a psychologically safe environment and by, by modeling the behavior you wish to see on your teams. Leaders can be that example. Um, meet people where they are.

Some simple tips are learn people's names, learn how to say them, ask them how they say their names. Nothing's more sweet to a person than the sound of their own name. And it's, it's a very important thing to know how to say someone's name.

So a simple tip, learn your people's names. Learn how to say them. If you have a difficult name or a name that people often mispronounce, don't take it personally, but do give them the gift of hearing how you pronounce your name.

Um, what other tips for psychological safety? No naming, no shaming, no blaming in DevOps and agile and Scrum, we have retrospective meetings where we look back and try to identify what we did well, what didn't go so well, and what can we improve. When we are looking back on things that we can improve, it's more important for us to look at the cause of the issue and where we can test for that cause.

And forget about trying to figure out who did what, because naming, shaming and blaming only encourages people to hide bad news, to not be honest and forthright or forthcoming about mistakes. And what that does is it reduces the amount of time that leadership has to avoid the error, avoid the mistake, apply some corrective actions. We want to know about failures and, and things that are possibly going wrong as early as possible to have as much time to maybe implement a remediation or, or kind of counter the effects of that.

So start with small changes on your teams, maybe anonymous feedback loops, uh, regular check-ins, just asking how people are doing and, and where you can help them. All these little tips are, are really strong ways that you can foster psychological safety. If you're a leader and you witness someone naming or shaming or blaming someone, try to without anger, um, address that at the time that it happens as a learning point so that, uh, your team is getting examples of it in real time as you're practicing your DevOps rituals.

So there's a lot of common pushbacks when you have an organization and you're trying to foster more psychological safety. And some of the common pushback you'll get is like, we don't have time for this. This is the soft, squishy stuff.

Um, I don't have to like that person, I just have to work with them. And who really wants to be in an environment where that is what your work is like? So it's, it's about overcoming these mindsets and trying to get folks online, um, navigating that.

In the end, fostering psychological safety would make it better for everyone in the, across the entire organization. Um, and if you're in a very highly regulated or bureaucratic type organization, it might be even more difficult because of the nature of bureaucracies in highly regulated industries. Um, you'll hear, we don't have time for this, um, but the fact of the matter is we don't have time not to do it.

Um, and, and today's work environment where it seems like we still haven't recovered from pandemic and remote and work from home and the great resignation or the big shift, people are still job hopping and making a lot of moves. And so for organizations that are looking to keep their teams intact, um, this is one way that can help. So there are tools and techniques that we can use to gauge the, uh, morale to gauge the environment of the teams that we're leading.

Um, we can use software. There are HR tools. There are, um, tools that are used for providing praise or for assessing morale.

Um, if you, if your organization has tools, access to tools like that, then use them to gauge, um, via, uh, regular surveys, for example, um, how people feel Too many times in organizations. We see people getting exit interviews by HR when they're on their way out the door. Well, by that time it's far too late.

Why not do stay interviews very short, quick morale pulsing interviews just to see if everyone's still happy enough that they wanna stay in the job. Um, there are also communications platforms like Teams and Slack where you can have a hashtag kudos channel and just send out small praise and encourage a culture of praise among your teams because it shouldn't only come top down. It should go across and bottom up.

I mean, anyone and everyone should be able to gi give kudos to a teammate. Um, some software have mood tracking apps. Um, they provide quantitative data on team morale.

Um, the retrospective rituals that we hold on our Scrum and Kanban teams, they're not just for discussing code. They can be a space for open dialogue and for gauging how the team felt. Um, and, you know, fostering positive, positive interactions among teammates, between teammates.

That's what we're going for so that it becomes a part of the daily routine. So there are key performance indicators for psychological safety. And, you know, this might wanna, you might wanna make this part of annual or quarterly reviews gathering data without breaking the trust of the folks that are working with you.

But, you know, figuring out what to measure and setting key performance indicators around them, around team satisfaction, uh, voluntary turnover, like who is voluntarily just leaving because they don't like the environment. Even innovation metrics could be measured to measure psychological safety. So you might want to consider making it a part of performance reviews.

If someone's in a role as a mentor or a supervisor, you could measure how well they're fostering psychological safety and their mentees or their subordinates, for lack of a better term. But data, while it's critical and crucial for measuring the, the value and performance of your initiative, it should never come at the cost of trust. So what's most important is fostering trust and safety in the teams.

And, um, finding a, a smart way to measure those, uh, initiatives without breaching that trust. So tech like AI can help and hinder both. Um, psychological safety.

There's a lot of ethical considerations and the limits of ai, of AI as it exists today in solving human, um, centric issues. It can help flag toxic behavior, but it can also inadvertently promote it. So if you're gonna be using ai, use it wisely.

Automation should free up human capital for creative tasks, but not make people feel like they're expendable or just cogs in a machine. Um, no algorithm can replace human intuition and emotional intelligence. So if you do consider using AI on your DevOps teams to help, um, automate some of the more tedious and toilsome jobs, make sure that the folks who used to do that work don't feel, um, diminished as a result of it.

And make sure that there is meaningful more human-centric work available for them to do if AI is gonna take it over. So bringing all of this psychological safety back to DevSecOps. Um, psychological safety is more like a security asset.

How, um, because safer teams are so much better at safeguarding against threats, psychologically safer teams, teams that are trusting enough to transparently say, oh, I think I may have inadvertently injected a bug in the software, or I think my code is not as elegant as it could be. You have to be very confident and secure in your place on a team, in your place at a company in order to willingly and freely admit that maybe you didn't do something a hundred percent correctly. Maybe you made a mistake, maybe you missed something.

What we want is for everyone to feel safe enough to admit these things because then we can find and fix them more, correct more quickly, but also we could probably engineer a test to find that error more quickly and earlier in the process so that we can avoid it happening in the future. In other words, it's a matter of flipping every quote unquote problem or failure into an opportunity for learning and improving and catching that flaw earlier in the process so that it's not repeated. So it's not just about hr.

Psychological safety is not just an HR asset, it's a security asset. And security in DevOps is everyone's job. And so that starts with making everyone feel secure in their job and secure in their role.

Contributing to your team. Key takeaways from this presentation. Encourage open dialogue, meet people where they are, model the behavior you want to see as far as psychologically safe behavior.

Avoid overly competitive environments in teams. Try to be more collaborative and cooperative. A little bit of friendly competition can sometimes bring really good results from teams, but it's very easy for that to become naming, shaming and blaming and heckling, et cetera.

So you gotta really watch the competition, start with small measurable changes and then adjust, assess, adjust and continue to tweak. And, um, look at different ways to make your teams more safe, more, um, trusting and more transparent with each other. com, um, you'll get so many great resources and information about psychological safety and that will help you keep this conversation going.

There's tips, there's resources that you can pull down to help you take some of this information back to your team so that you can implement it on your DevOps groups. Because psychological safety isn't just a one-time event, it's an ongoing practice that you want to, uh, foster and support so that it flourishes on your DevOps teams. And with that, that concludes my presentation on soft skills.

Don't call them soft skills. They're actually the hardest part, I think the hardest part in bringing teams together and keeping teams together. I appreciate you staying with me during this talk, and if you have any questions, feel free to reach out to me.

My email address is on the screen and I look forward to hearing from you. Thank you.