This article shows the importance of translating IT’s value to executives using an outcome-driven mindset and provides decision-makers with tips to execute.
Join the DZone community and get the full member experience. 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. However, 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. 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; for example, sales, marketing, or operations. 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. The job of engineering management is to make this translation as easy as possible, but that is a hard job. Here are some tips to help:
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.
