How to Translate IT Value by Using an Outcome-Driven Mindset

An IT project is never an end in itself, but a means to attain a business objective. In this day and age, when leaders and decision-makers are exposed to buzzwords, frameworks, and tech trends constantly, it is more important than ever to take a step back and reflect on the business goal before deciding on the technological way to get there.

Decades after the advent of information technology, the challenge remains the same: to successfully apply IT practices that improve revenue streams and unlock new DevOps opportunities. Organizations urgently need to establish frameworks to manage information systems and apply them to daily operations, contributing to delivering business value and improving economic performance.

But a significant amount of DevOps practices still used today were borrowed from the automobile industry. While these worked in assembly lines and were a good starting point for IT and DevOps, they need to be reviewed and refreshed to stay relevant in today’s tech world. These outdated techniques include:

• Strict Hierarchies and Execution From the Top–Down: Teams that are organized with a strict division of labor end up creating siloed working areas, compromising the common goal.
• Strict Waterfall: The business value is released in huge cycles, lacking validation as the project goes along.

It is important for business leaders to keep their eyes on the outcome. In this article, we will see ways to separate the “what” from the “how,” providing decision-makers with some tips they can use in their challenging day-to-day work.

Retrospectives are important but they are not always done right. Especially teams that are Agile immature encounter difficulties that compromise the retrospective’s value. Let’s look at some of the most common issues.

1. Team Members Can’t Agree on Action Items

Often, team members’ opinions on how to fix issues vary. When opinions are too distant from each other, consensus might be hard to attain. If this is something you struggle with, provide your team with Agile training and your Scrum Master with knowledge on how to be a better facilitator.

2. Nobody Feels Responsible for Action Items

An action item must be assigned to someone otherwise it will never get done. If the responsibility should be split between team members, write all their names, but don’t let an action item go by unassigned. If nobody wants to take responsibility, scrap it, it means it’s not that important for the team.

3. Action Items are too Vague

Action items should be SMART: Specific, Measurable, Attainable, Relevant, and Time Based. Goals formulated like this use a specific set of criteria to help ensure that objectives are clearly defined and attainable within a certain timeframe, thus improving their chances of being implemented.

 

4. Team Members Blame Each Other Instead of Taking Responsibility

Some people focus on what others did wrong and don’t take the time to perform a self-analysis. This leads to not-so-productive retrospectives. In these cases, the facilitator should emphasize the “you” of this member, rather than the team: “What can you do about it?”

5. The Team Already has a Rule for a Certain Issue

Sometimes, topics come up only to be dismissed by “we already have a rule for that.” This implies that if everyone followed the established rules, the issue wouldn’t emerge again. However, if it did, most likely it’s because the existing rule doesn’t work.

Treat this as a new problem and discuss it within the team to assess what can be improved about the existing solution.

6. The Team Discusses the Same Topics Over and Over Again

Always using the same retrospective format might kill people’s creativity. If you manage to unblock team members’ inhibitions, they will feel freer and more open to exposing themselves and their feelings. 

Try using different formats for the meeting and do distinct exercises. For inspiration, Fun Retrospectives is a good place to check.

In tech companies, methodologies are usually a concern of Engineering teams, rather than a decision from the executive team. In most cases, decision-makers at the business level don’t have a detailed understanding of what the engineers do or how they organize to get the job done.

In the same way, the executive team doesn’t have a detailed understanding of what other teams at the company do, say the Sales, Marketing, or Operations, for example. But this is ok, as it’s not their job; their job is to have an overview of the activities of the different teams and coordinate how they fit together to reach the company-level goals.

Therefore, it’s the responsibility of Engineering management to “translate” the team’s work to the organization’s executive team. When done correctly, the organization as a whole has a better understanding of the value the Engineering team provides. The executive team gets the feeling they can more accurately forecast the Engineering team’s work and, thus, fit it into the higher-level planning.

How to Translate Engineering’s Day-to-Day Value to Executives

The job of Engineering management is to make this translation as easy as possible. But that is a hard job, so here are some tips to help:

1. Link Development Metrics to the General Organization’s Goals

In the same way that Sales has a dashboard with metrics, Engineering should have one too. When building this metrics dashboard, focus on indicators that monitor the quality of the software rather than quantitative indicators such as the number of lines of code, or bugs reported.

2. Make your Executive Team Understand Software Development Forecasting

The CEO of a company can look at the Sales team’s dashboard and understand a few basic metrics, such as whether or not the goals are in line with the organization’s objectives or not. 

If Engineering creates the dashboard mentioned on point #1, the next step is to make the executive team be able to read and understand it on their own, just so they can start driving conclusions on their own. The goal is to make them be able to measure the process of software development, not just the outcome.

3. Focus on Cross-team Relationships

It’s challenging for other teams across the company to understand the day-to-day of developers and engineers. However, if you can teach them to understand the dynamics and importance of it, you can drastically improve the way the organization sees their work and, better yet, how the rest of the organization interacts with the Engineering team members.

For example, if you teach them why developers need to focus and enter a flow of uninterrupted work, it becomes easier for other people at the company to manage their expectations of, say, how long a developer takes to answer their emails.

4. Establish a Connection Between Developers, the Product, and the Customer

The developers are the ones building the product but, oftentimes, they have zero contact with the customer. Many don’t ever get to see how their builds solve the problem it was intended to solve in the first place. They build it, it is deployed, and the cycle is finished on the developer’s side.

Take a moment to ponder how limiting this is. A study done in 2014 revealed that cooks make food 10% tastier when they can see their customers while in the process of preparing the food. This is very explained by the fact that, as humans, whenever we find purpose in our job, we tend to perform better. Treat your developers as humans and not just as another piece in a bigger puzzle.

By following these tips, you contribute to making the whole process of software development a much more holistic one. It stops being about siloed individuals performing duties that will, somehow, fit into a bigger picture they can’t see. And it starts being about united teams that work creatively on a problem they take into their own hands.

In 1968, mathematician and programmer Dr. Melvin Conway stated in a paper submitted to the Harvard Business Review something that would become known as “Conway’s Law”:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

In simple terms, the idea conveyed by Conway is that organizations need to shape themselves to the image of the outcome they want to achieve. 

Therefore, when assessing ways of working, the management team should always keep in mind the outcome and shape the teams, processes, and structures to better fit the desired outcome.

One way to achieve this desired outcome is to incorporate DevOps into the organization. The different approaches and methodologies need to come together under one driving force, and that is exactly what DevOps lets you achieve.

At the core of DevOps lie self-organizing teams of different disciplines that come together at the beginning of a project and create feedback loops that will constantly improve the outcome produced. DevOps will also automate the tasks that can be automated and free up time and headspace for team members to focus on what really matters: delivering business value.

While this might sound obvious, the truth is that nearly 50 years after Conway’s research was first published, organizations still struggle to achieve business results by making use of IT.

Product managers usually work based on a product roadmap composed of a list of features handed down to them by top management. Their job is then to drive the team to build and deliver such features.

However, it can happen that all the features get done and still the wrong product is built. Why? Because features are a consequence of a step that must precede them: problems.

As a product manager, instead of talking about features, try making the conversation about problems you need to address and outcomes that the team should attain.

Let’s say you’re building a CIAM platform, where you will manage your users. Instead of thinking of a feature such as “users must have roles and permissions,” clarify the problem: “There must be a differentiation in these users in terms of what they can see and do.” 

Now, think about the outcome: What will it look like for an admin user who is managing end-users on this platform? What will they be able to do? 

Doing this shift, it is important to still keep these goals measurable, for example by keeping them SMART: Specific, Measurable, Achievable, Relevant, and Time-Bound.

When adopting this way of working, based on problems rather than on features, you will realize several benefits:

• It gives more autonomy to teams, allowing each member to contribute with their expertise.
• The whole team can own the problem and understand when it is solved.
• The Product Manager will deliver the outcome, not the feature.
• The team stops delivering features that customers don’t want.
• The team gets more creative when asked to solve issues.
• The team might focus on improving existing features, and achieving a solution to the problem rather than creating new features.

Successful IT organizations know how to link the three main elements of software delivery: people, processes, and technology. This triad is the key to making teams and companies thrive and deliver outstanding products and projects that solve real-life problems for their users.

As technology evolves, automation becomes more available and DevOps practices become an essential part of any delivery team. Ignoring them is failing to leverage the power of technology to stimulate productivity and generate business value. It is failing the people in the organizations and the processes they have worked hard to put in place.

If you are in a management position and feel you need some guidance in picking the right approach for your teams to tackle IT problems, we are here to help.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach