A toolkit to empower developers and testers

Business performance improves when technologists are empowered, when they have the right environment, and when points of friction are removed.

Early in David Theriault’s career as a developer, he was called to attend a meeting with management, in which the bosses discussed how to fill developers’ time. Managers proceeded to allocate the developers’ full schedules in 15-minute blocks for over a week out, Theriault recalls. 

In other words, the managers predetermined how much time projects should take without any room for possible overages, Theriault says. Then, the managers got into a discussion about what they should do with the developers’ remaining time – literally 15 minutes at the end of the week. 

“It was demeaning to think you’re basically punching in and out and there was no room for anything creative or any training,’’ Theriault says. 

It didn’t stop there. The managers also assigned each developer to a group with QA, product, and design people. In effect they created silos, instead of allowing for dialogue and relationship building across teams “so they don’t feel so isolated and stagnant,’’ Theriault says. “At the time, I was a junior developer and I thought, ‘I won’t make much forward progress here.’” Ultimately, he left. 

Today, Theriault is a manager in the analytics division at TraceLink, which specializes in pharmaceutical supply chain management. Fortunately, he no longer has to deal with the factory-like approach to software development. 

You’d think organizations would have mastered how to develop software effectively by now. Yet, while many have invested in software development, those investments have not led to meaningful performance improvements, according to a report from McKinsey. 

“Leaders still struggle to scale promising sandbox innovations, the firm wrote in April. “We often hear CEOs, chief technology officers, and chief information officers lament that their software development spending is a ‘black box.’”

Thinking outside the black box

It doesn’t need to be that dire. Business performance through software development improves when developers are empowered and they have the right environment in which to innovate, and points of friction are removed, according to McKinsey.

Developers, not surprisingly, agree wholeheartedly. They say they thrive when they are trusted and allowed to do their work autonomously. 

“The single thing that defines developer empowerment for me is being able to code fearlessly,’’ says Ben Boyter, technical lead for Kablamo, a cloud services provider in Sydney, Australia. “You need to be able to make any change you want to the system as a whole, small or large, with such a low cost for failure that you are no longer afraid to try things.” 

A developer should be checking code, knowing that they can revert mistakes they made, says Boyter, who wrote a blog post about developer empowerment in 2019. Development teams should also deploy code with the understanding that they can roll it back if it doesn't work. 

“They should be confident that once they check their code … the system it supports should be tested in an automated way, so even if they make a simple mistake it will be picked up,’’ Boyter adds. “Or that even if not, monitoring systems will give an idea that something has changed, and maybe even tell you what system it affects.” 

Yet, Boyter believes that companies don’t allow for this because they are afraid of failure, and don’t accept is that failure is normal and part of the process. “Nobody is perfect, no amount of testing is going to catch every bug, no code is perfect, and even formal proofs are only as good as their requirements,” he notes. 

When companies learn to accept that software development is iterative, and build failure into the development equation, “You can own it,” says Boyter. “Once you own failure, you can then control it and make it work for you. Suddenly, large sweeping changes are no longer scary.” 

The end result? Developers can code fearlessly, Boyter says. “And as such, they will feel empowered.”

Start with trust

Being an empowered developer means that you are trusted to get the work done and your time is respected, agrees Greg Reed, co-founder and technical director of digital product agency SOON, based in London.

When a developer is empowered, “People in the organization listen to you and actively seek your advice,’’ Reed says. “You’re allowed to say no. In fact, you’re expected to say no, and you’re trusted to make good decisions. You’re given the space to explore and research new technologies and time to refactor and improve old ones.” 

Ariel Illouz, senior software engineer at software development company LinearB in Israel, says he’s not only a empowered developer, but he empower his team as well. For example, LinearB establishes areas of responsibility (AORs), such as customer success and cloud infrastructure cost. He and every developer on his team has their own AOR. Each developer manages their AOR and reports on it weekly, Illouz says. “This level of responsibility and trust is empowering for individual developers.”

Give people the freedom to resolve issues

Today's developers and testers are responsible for bigger codebases spanning more languages and technologies than ever before, notes Theriault. And since they are in the code day-in and day out, they’re the only people who know if there's a component that won't scale, or a security vulnerability, or any one of a hundred other issues.

If the developers don't raise the issue, no one else is likely to until it's too late – until it's affecting customers, Theriault says. “Empowered developers are the only ones who can solve these problems.” 

Further, organizations have to acknowledge that issues are not just a software development problem, observes Reed. “The organization and all the stakeholders have to be committed to a process of prioritization, iteration, and improvement. As teams, we’ve invented all these buzzwords – agile, user research, user experience, minimum viable product – in order to focus effort and build confidence that what we’re developing will lead to meaningful performance improvements.” 

There has to be space to implement and refine these processes to get the results, Reed says. 

Illouz sees two main issues organizations have with software development: losing things that fall between the cracks and innovation. 

“Whether you’re a startup with limited resources or a new hybrid remote team, things get forgotten about, priorities change, and bugs come up,’’ Illouz says. “By giving my team members direct areas of responsibility without much oversight, they take ownership and fewer issues are forgotten about.” 

Take time for a retrospective at the end of each sprint and listen to developers. If managers don’t do this, they lose out on a lot of value, Illouz says. 

“We then test the idea to see if it works. If someone fails at being better, that’s not a bad thing. Fail fast, learn from it, and keep moving forward,’’ Illouz says. “But you always have to provide an environment based on trust.”

How to become an empowered developer

Empowered developers are creative, they tinker, and they find clever solutions, says Theriault. They are proactive. They identify and solve issues before they reach the customer.

The ability to become one starts with the organization adopting an open mindset, techies say. 

“It’s tough, but you’ve got to learn to say no,’’ says Reed. “Start having those difficult conversations with your project managers and stakeholders. You have to be honest about how long things take, and you have to raise the alarm when you know it can’t be done.” 

That way, scope can be reduced, things are appropriately prioritized, and the software team members can focus their efforts on the things that produce the best possible outcomes. 

Developers and testers also have to take responsibility. If the codebase is poor, or they inherited a restrictive system, or there’s a culture of writing bad code because there’s no time to do it any other way – they have to fix it. “Clean it up, build in time to refactor, create tests, and make it yours,’’ Reed says. 

Also, “Ask yourself, do you have confidence in what you are making? What problem are you trying to solve and does the solution make sense?” If it doesn’t, you have to give your input and start a discussion. You should feel confident that what you’re developing is going to have an impact, Reed says. 

But, Reed adds, “If you try all these things and your company still doesn’t take you seriously, then I’m afraid it’s time to leave.” 

Theriault echoes that sentiment. “If developers see that their warnings fall on deaf ears then they will simply stop raising the alarm. Leaders need to listen. I tell my team I want us to build software that we're all proud of.” 

Since developers know where the weak points are, Theriault says, “I need them to raise the issue, file the bug and in return, my pledge to them is that action will be taken, we will schedule the fixes and at every iteration, we will get stronger.” 

‍

by Esther Shein

Esther Shein is a longtime freelance technology and business writer and editor whose work has appeared in several national and trade publications. She has also written thought leadership ebooks, customer stories and marketing materials.