Red Line Movement
Recently, I’ve been calling for an industry-wide adoption of the red line philosophy to help with the balance of features and quality in cloud application development. It seems that everyone has the idea that if they don’t deliver new features, then they’re doing something wrong. However, anyone can produce features, but if they take too long to develop, don’t work well, and current customers are unhappy because they don’t work, then new features don’t really help anyone. It is time to change this by adopting the red line philosophy so that organizations can reach new levels of innovation while exceeding user expectations.
What is the red line philosophy?
The red line philosophy is based upon the idea that early and continuous delivery of high-quality software that is updated frequently for technical excellence and good design will improve customer satisfaction. For example, high-quality features that work as the user wants them to work is more important than providing new features.
Innovating new features for the sake of having new features is simply no longer an option – just because something can be done does not mean that it should be done. Unfortunately the “create because we can” idea is prevalent in most enterprise businesses from the sales team to developers. We all over-promise what applications can do rather than perfecting what they should do.
The red line provides a limit of what should be considered to be acceptable in the industry. It is a line drawn in the sand that ensures that quality of existing features through continuous improvement is balanced with the innovation of new features. The red line helps organizations understand how satisfied or frustrated users are with various elements and features of applications.
Finding the red line
The red line is the total number of issues in a month that occur in developed features or services divided by the total number of monthly customers . The red line represents the number of issues that are reported for applications on a monthly basis normalized by the number of customers the application serves.
For example, if a company had 100 issues that arose in a single month and had 1000 customers, the red line would be .01. On the other hand, if there were 1000 issues, the red line would be 1. The lower the red line number is the better the development team is doing meeting customer needs allowing them to innovate elsewhere.
While not every customer issue can be attributed to application issues that can be addressed by engineering or development, we have found that by monitoring trends in the red line improves the quality and innovation of an application, feature or service.
This philosophy is extremely crucial to DevOps teams and their management within an organization so that they are all on same page as to know what needs to be addressed and what priority issues should be. Most organizations will find that many of the issues that are reported, are reported over and over again. By focusing efforts to resolve these repeated offences results in better adoption and usage of the application, feature or service. It will result in fewer customer support calls and allow developers to finding new innovation that addresses unseen customer needs. Developers will also find that they are better equipped to address each issue in a systematic way – not just put out the fires when major problems come up.
Manage by Red Line Objectives
In our organization, the red line is largely how we deliver our teams MBOs. It allows us to give the teams freedom to balance between innovation and fixing issues, keeping our customers happy and keeping us competitive and fast-moving.
For instance we know that whenever the red line is sloping downwards the team can spend more time innovating new services or features. When the red line is sloping upwards, the team should spend more time focusing on fixing issues that have arisen. At times, the can and the should must be re-prioritized based on needs across the organization.
If there are significant trends of the red line downward for multiple quarters in a row, then we realize that new applications and new teams can be created. If the red line continues upward quarter after quarter we determine if resources should be diverted from elsewhere in the company to address and fix the issues that have been identified.
Now, I realize that not all issues are because of poor programming. We may determine that it could be something as simple as providing better or more accessible documentation. It may be an outage or an issue with an API or other connection. But, by implementing a red line program organizations will have happier customers and higher quality products which result in a more profitable and growth-driven company.
An Industry-Wide Red Line
If we do not implement the red line as an industry now, the gap between developers and users will significantly widen. Companies who implement the red line will be more competitive and surpass their peers in terms of adoption and customer satisfaction. Applications and services will also be more innovative and feature rich.
The industry-wide adoption of this red line philosophy will also improve the quality of existing features so that customers can realize the impact of the innovation that has taken place.
It is time for all of us to draw a line in the sand and say this is where we stand.
By Allan Leinwand