by Snehal Antani

Continuous improvement starts with IT culture

Nov 13, 2015
Agile DevelopmentIT Leadership

How to avoid IT's three toxic characteristics and create a culture of continuous improvement

IT holds the keys to a huge competitive advantage, whether you work at a small business, a government organization, or a Fortune 10 company. But even as IT has evolved from being a back-office function to a core part of the value that businesses deliver to their customers, not all organizations are using their IT teams to full potential.

To make the transformation, you must create a culture of continuous improvement. This empowers product managers to quickly identify and deliver new features, and to quickly pivot or iterate based on both the voice and behavior of the customer, enabling businesses to stay steps ahead of customer needs, rather than continually playing catch-up.

There are three toxic characteristics every organization faces that hamper IT teams’ ability to create a culture of continuous improvement: group think, analysis paralysis, and losing sight of business outcomes. The most effective way to remove these characteristics is to lead by example. Transparency is incredibly important. Gone are the days where middle managers can massage the message to leaders. IT leaders must have the background and expertise needed to get into the details and ask the tough questions. Without these attributes instilled in the leadership of an organization, these toxic characteristics will severely limit the impact that technology will have on the business.

Group think

Group think — making decisions by consensus — is both a blessing and a curse. It shows that the organization seeks collaboration, trying to be inclusive and ensuring everybody has a voice. However, group think can also signify a deeper issue: lack of clear accountability. This can have several side effects.

First, decisions that should take a meeting or two will take months or longer because of the endless debates and jockeying. Second, when things go awry, participants quickly regress to finger-pointing and focusing on “whodunit.” Finally, it can handcuff leadership to devastating and long-lasting effects.

Difficult problems lead to debates, which ultimately lead to collecting votes for one idea versus another. This creates a political atmosphere and can blow up into all-out Machiavellian war.

The challenge is balancing consensus building with making a speedy decision. Striking this balance means the decision-makers have to be crystal clear about the desired business outcomes — the KPIs that matter, what the assumptions are and what options are out-of-bounds. The rest of the group contributing to the decision should only include those with a “horse in the race.” Those who are accountable have the loudest voice and are given an opportunity to declare their perspectives. The rest have an informed opinion, but it’s just that — an opinion.

Analysis paralysis

The best IT professionals are passionate about their work, but when you have a group of passionate individuals, disagreements happen. In the IT world, these arguments become a distraction when they are divorced from the end business goal.

When adopting continuous delivery and hybrid cloud, for example, technologists will passionately debate which is better: Chef or Puppet, agile or waterfall, WebSphere or WebLogic, etc. In reality, organizations have been successful with all and none of those technologies, and of all the decisions to be made, this won’t be the most important. Rather than spend many months investigating which option to pick, quickly make an informed decision and move on.

Analysis paralysis represents a deeper problem within the organization: fear of failure. IT teams want to exhaustively investigate every possible option because they don’t want to make the wrong decision. But an organization that is afraid to fail cannot be innovative, nor can it move at market speed. Innovation by definition is about taking informed risks, and quickly iterating or pivoting based on the data.

There are two ways to break analysis paralysis. First, divide the problem into smaller, discrete pieces that can be delivered over a shorter period of time, as reducing the scope naturally reduces execution risk. Second, lead by example and reward risk taking. Never use the word “failure.”

Losing sight of the business outcome

The business outcomes should be the North Star for the entire organization. If the outcomes are not clear to the IT teams, they cannot execute to their maximum capacity and technology leaders instead waste energy herding cats. The larger the organization, the greater the middle management team and therefore the harder the situation. I stick to the “rule of three,” no matter how complex the problem, it can be distilled down to three bullet points and three KPIs. If a decision doesn’t affect these KPIs, it’s not critical.

Transparency is critical to ensuring people don’t lose sight of the business outcome. A real-time view of the KPIs that represent the business outcomes, openly accessible by everybody in the organization, is a start. However, it’s not just the quantitative aspects of the KPIs. The qualitative aspects are just as important: Are we trending in the right direction? Why did we see an adverse change in the values? Both need to be built into the continuous-improvement cadence. It must start from the top of the organization, but also be front-and-center for every employee, regardless of where he or she sits.

A continuously improving organization starts with leadership

The success of the modern enterprise demands an IT culture focused on moving the business forward, and building that culture starts with strong leadership and transparency.

Today’s technology leaders need to shape the values of their IT teams. They must identify and celebrate their collaborators — those intent on improving the business — and nullify group think. They must make decisive decisions that put an end to analysis paralysis. Most importantly, they must always have the greater business goals in mind, even when it questions traditional IT thinking.