10 indicators that your tech culture is broken (and what you can do about it)

I’m a big fan of explosions. You know, the ones in Hollywood films, not in IT projects.

And although technology is everywhere and plays a major role in almost every business, explosions just keep happening.

Why? Mostly because many organizations still regard IT as a cost center, not as what makes everything possible in the 21st century.

These places just cling on ideas of the past that no longer work, while the rest of the world just keeps moving on. Some of them are even proud of not having changed their processes for years!

Image source: knowyourmeme.com

As a direct cause of that mindset, several major incidents have surfaced over the last few years: healthcare.gov, Knight Capital, Toyota, Equifax, to name a few.

And although the answer keeps staring them in the eye, most places don’t do anything about it until perhaps it’s too late.

DevOps to the rescue

Fortunately, some others know better. Here’s an excerpt from The DevOps Handbook:

In 2009, Etsy had thirty-five employees and was generating $87 million in revenue, but after they “barely survived the holiday retail season,” they started transforming virtually every aspect of how the organization worked, eventually turning the company into one of the most admired DevOps organizations and set the stage for a successful 2015 IPO.

The question is, what DevOps really is?

Prefixing the name a traditional Ops team with the word “Dev” doesn’t even begin to cut it. In fact, that approach can cause bigger problems than the ones it hopes to solve (false advertising tends to have that effect).

DevOps is something wider that touches on every aspect of technology within an organization.

DevOps is a culture

Within a true DevOps culture, development, operations and product people work close together towards a common goal: delivering high-quality, reliable software that enables an organization to conduct its business.

Of course, that culture can’t flourish when leadership is not 100% on board.

Unfortunately, the existing culture in many organizations directly opposes any opportunity for making real progress. It’s broken, and leadership either doesn’t see it or doesn’t dare accepting the challenge of changing it.

What a DevOps culture does not look like

Here are 10 indicators that an organization’s tech culture is broken. Such an organization could greatly benefit by switching gears and embracing the ways of DevOps.

1. When the single most important thing is always delivering features under tight deadlines, at all costs. Technical debt is considered insignificant and can be dealt with “later”.
2. When deadlines are oftentimes decided without asking the programmers for an estimation, or even discussing the technical feasibility of the requested features before committing to various stakeholders.
3. When quality is an afterthought, and low quality is only seen as a problem when something actually explodes – usually in a public setting.
4. When provisioning new resources or deploying software is a slow, manual and error-prone process, usually accompanied by a round of applause at the end (go team!).
5. When the correctness of software is not verified by an automated process, because “there is no time for writing tests”.
6. When simple procedures that should normally take a few minutes to complete, end up taking days or weeks, due to layers and layers of meaningless red tape.
7. When projects fail one after another, but there are no lessons learned. The very same mistakes are repeated at the next project.
8. When there’s a constant need to work overtime, which is usually an indication of either poor management, the lack of good engineering practices, or both.
9. When all incentives (bonuses, promotions etc.) point solely towards individual performance metrics, significantly impeding any chances of meaningful team work or inter-team collaboration, and encouraging people to keep pursuing their individual (and often conflicting) agendas.
10. When important technical decisions are made by “enterprise architects” (or any other flavor of architects) who don’t code. Code is all about details. Thinking of details as unimportant, and making decisions solely based on the “bigger picture” is a well-disguised death march.

Architects who don’t code are not architects; they are something else… – Robert C. Martin

If you recognize any of these red flags at your workplace, I strongly suggest that you read The DevOps Handbook cover to cover. If you enjoy it, tell your team too!

In case you are hungry for more (and I guarantee that you will), I highly recommend that you read The Phoenix Project next.

Closing thoughts

DevOps is the -not so secret- ingredient that allows organizations move fast, adapt and succeed in the ever-changing IT landscape.

It’s the way of professionals to fight for what they believe is right for their organization. Change doesn’t happen overnight, but rather one step at a time, from the inside-out.

Even if you think you’re not in a position to affect your workplace’s culture in any meaningful way, developing a good sense of what’s right and what’s wrong will still help you make better decisions, lead by example, and influence people.