In a recent episode of DevOps Radio, I was pleased to be joined by Søren Pedersen, the founder of BuildingBetterSoftware, a consulting firm in Denmark that specializes in agile transformation. We chatted about his career in software development, why he founded his company, as how to create a successful DevOps initiative.
Doing DevOps before it was DevOps
A software engineer by training, the Danish-born Søren spent a number of years at Bang & Olufsen (B&O), the famed Danish luxury electronics brand, primarily working with software tooling and early automation systems. He says many of his early software development projects used DevOps methods even before they came to be known as continuous delivery or DevOps. Before he left, Søren saw B&O shift from making traditional audio and electronics products to embracing streaming media platforms. “This was a great engineering challenge,” Søren says.
After B&O, Søren found his way to Legos, another Danish icon and maker of plastic construction toys. As the leader of a DevOps team, Søren worked on several high-profile projects, including the company’s website, the Lego smartphone apps, and “experiences” at its Legoland theme parks. “Our team bridged the gap between IT operations and marketing,” Søren says.
Bridging the gap to BuildingBetterSoftware
Although Søren’s early DevOps projects at B&O were largely successful, they weren’t without challenges. For example, he often ran into managers who weren’t on board with the agile development approach. And he bumped into similar snags at Lego. “I came to the conclusion that there was a mismatch between the structure of traditional management layers and how engineers thought software delivery should be run,” Søren says.
There had to be a way to bridge the gap between the two camps. So, in 2019 Søren started BuildingBetterSoftware to do just that. What’s behind the disconnect between engineers and upper management that’s preventing a successful DevOps program? Søren lists a few key stumbling blocks.
Ownership miscues. Sometimes developers need to take more ownership, and sometimes managers need to give more space to developers to own what they produce.
Distance between management layers. Managers – and especially those in upper management – are often far removed from the world of day-to-day software development, and they’re often constrained by budgets, headcounts, and company politics.
Risk-averse managers. This can be particularly hard for forward-thinking development teams to understand.
Lagging developers. In some cases, you’ve got management that’s pushing developers who may not be comfortable with DevOps.
Lack of candor. In these situations, people fear a backlash if they speak openly about what’s working and what’s not.
Tips for Successful DevOps
Software quality is one of Søren’s passions and it’s the subject of an article he recently published on LinkedIn about the impact of bad software. “Quality is an attitude,” Søren says in his article. “To deliver a quality product, we have to do our best every step of the way.” So, how do you find or instill a commitment to quality? Søren offers a few tips:
1. Give people ownership so they care
Søren says leaders need to have the courage to call out lax attitudes and behaviors. It’s perfectly acceptable to say, “This isn’t what we do on this team or at this company. We need to do a quality check.” On the other hand, if you’re repeatedly telling people they can’t do something – or you don’t have the time or budget to do something the right way – developers will stop caring. Let employees know you’re willing to invest the time and effort to deliver a quality product.
2. Look for a quality attitude when you’re hiring
The old adage “hire slow, fire fast” certainly applies when you’re looking to assure quality software. Søren suggests that you invest a lot of time and effort into your hiring process, so you’ll be sure to pick candidates that meet your quality standards.
3. Make yourself available to your team
Søren says managers need to get away from constant back-to-back meetings that take them away from daily interactions with developers. His rule of thumb: Be available to your staff at least half the day so people can drop-in and chat about different topics. If you’ve got remote teams, make sure people know they can reach out to you virtually.
4. Find the first movers
If you’ve got some innovative, eager developers willing to try a DevOps approach, give them the space and guidance they need to get started. These tend to be the people who will lead the way and become your DevOps champions of the future.
Listen to more of Søren’s story on Episode 96 of DevOps Radio.