How to make your DevOps dollars go further during a crisis

The temptation during any major (or unprecedented) financial crisis is to either massively cut costs or spend money to get you out of the particular hole you’ve found yourself in. A Harvard Business Review study from 2010 found that companies that cut costs quickly in a recession a far more likely to fall behind the competition coming out of it.

The study also found that the companies that were progressive — seeking operational efficiency over immediate cost-cutting — were significantly more successful, with higher revenue growth and lower layoffs than others.

This applies to past, present, and future crises, especially when applied to software development. In a survey my company in May 2020 took of IT professionals across America, over 60% reported that they’d seen layoffs and 36% reported a reduction in spending.

Encouragingly, we found that 34% reported a shift to more agile processes and 28% reported the elimination of processes that were getting in the way — and that’s precisely what I want you to focus on, both with the problems you’re facing today, and even when your organization is soaring.

…and efficiency for all

When things are tough, it’s easy to single out things that are going wrong rather than find out why they’re going wrong.

You’re producing an app and the design team is slow to get something out the door, and they have to keep doing revisions, all because the person writing the copy isn’t getting them everything they need when they need it.

Your development team has to wait for IT to get everything ready to push the app out, and everybody is intimately aware of both the deadlines they’re facing and any particular crisis that’s happening at that time.

It’s the cliché of siloed development — everybody’s stuck in their own worlds, communicating things based on how their team functions, delivering things in a way that makes sense to them.

This is a classic example of development in series, where each team gets their piece ready when the other team tells them their piece is ready, leading to a logjam the moment anything goes wrong.

These aren’t necessarily DevOps-specific issues, but they’re the kinds of things that can bog down an organization’s ability to deliver great software. And if you look carefully, they’re entirely organizational issues that can be fixed in a relatively straightforward manner and yet make people miserable, annoyed, and unable to actually ship product.

Crucially, they’re something that you can fix without spending money. 

Breaking down walls

A great software organization should be able to work in parallel, with each part of a team shipping a product able to get what they need to get done without having to wait on another part.

To make this work requires an evaluation of how your teams communicate, whether certain parts of your organization are helping with or exacerbating problems, or even if certain tools are getting in the way. 

For example, your software team is launching an eCommerce website for a shoe brand. The web development team needs SKUs, product photos, prices, and other specific information every time they develop an eCommerce platform, and thus these are things that your organization should have requested and delivered well in advance of the project kicking off. That way the web development team isn’t held up by the client.

Similarly, the web development team can set a standard for what sort of copy they’ll need in advance, so the copywriter won’t be waiting for where to place things. Your IT team knows an eCommerce website is going to be built and the launch is on a particular day, and has everything ready.

These seem obvious, but having a standardized, well-communicated and established (say, in an internal wiki) workflow for a particular project type means there are less mistakes, and clearly-communicated milestones to hit. 

The notion of working in parallel is one that enables your team to do as much as they can separately, while all working toward the same goal and ultimately delivering better products faster.

This harmonic, parallel organization also may require you to consider what actually works for a particular project over what seems important. This may be as complex as how your IT team is putting your site into production, or as simple as the communication tools you’re using to keep a project on track.

To be frank, if something feels like a pain in the ass to get done, now is a great time to ask why you’re actually doing it, what benefit it gives you, and who is actually using it.

Having clear communication on what roadblocks exist in a project isn’t just good business, it’s a great way of building camaraderie across different parts of an organization — everyone suffers together, and gets stronger together.

Someone may not understand a particular tool’s purpose (and resent having to use it), or everyone may be having the same complaint without actually voicing it. 

Ultimately, development efficiency comes from understanding everyone (and everything, in software’s case)’s core strengths and weaknesses and building around them.

You likely already have the pieces you need, but simply need to give everybody the workflows and encourage the types of communication that gets things done quickly and efficiently.

Liked this article? Then join our online event, TNW2020, to explore the latest trends and emerging best practices in product development.