Acceleration Software and the History of Strategy Execution Software – #2 The Real-time Era

In this blog series Johan Grönstedt, Chief Strategy Officer at Howwe Technologies, covers all you need to know about Strategy Execution trends and platforms. 

In a series of three blog posts, we’ll dig into the history of strategy execution, trends, and platforms. After the initial post – the Reactive era – it’s time to put the real-time era in the spotlight. 

#2 The Real-Time Era

After a deep dive into the emergence of the digital era. we’ll move on to what we call “the Real-Time Era” and its Proactive software.

Growing tired of the slow and reactive nature of the first strategy execution platforms, a second wave was emerging building on more agile traits. A new way of thinking was that only monitoring output was not enough. These new systems got more interested in optimizing the input that would in turn lead to improved output. The Real-Time era was here.

Goals and activities anchored in the whole orgnization
Thus, goals were broken down into activities and consultants started using words like “lead and lag (KPIs)”. A leading KPI was the activity that would lead to a goal. A lag was the lagging measurement of that same goal.

Increasingly there was a need to anchor the goals in the organization since even the most involved consultants would struggle with figuring out the leading activities in all teams for a company. Therefore, a bottom-up approach was added to the traditional top-down.

Weekly stand-ups increased accountability
Authors like Sean Covey (most notably 4 Disciplines of Execution) were very influential in adapting the emerging IT Agile framework, where teams integrated weekly stand-ups to plan the most important deliverables for the coming week and debrief the past week’s achievements, to a broader business application. This helped organizations immensely since most organizations at the time struggled with accountability in execution – ie. Teams knew more and more WHAT and HOW but struggled to just get it done.

On the flip side, even though greater accountability was achieved, and planning horizons were generally shorter as a spillover from the agile framework, anchoring was still very time-consuming, often 6-12 months before any real execution was initiated. Many business leaders wanted a quicker way of getting going.

Focus on less to get more done
Second, Covey also pioneered the thought-line to focus on less to get more done. This was probably the greatest contribution to the modern strategy execution theory he helped bring. Through studying several hundred strategy execution attempts, he and his co-authors found that there is an inverse relationship between the number of goals and the number of goals met. There seemed to be a sharp drop-off already after 2 goals, and he helped business leaders the world over to understand the need to prioritize what was most important as a contrast to the everyday whirlwind of activities.

Google and the rise of OKR
Although Covey already was in business under the brand FranklinCovey as a management consultant and that they offered a strategy execution platform, it fell to Google to be the first to successfully implement it on a broader scale with systems support. They called it OKR. With a self-developed tool, not much more advanced than an excel sheet, they challenged each individual to be ambitious with their target setting and management (and the OKR-tools) combined the best from the Lead/Lag and priority mindset to achieve some truly remarkable results.

Many companies in the Real-Time Era have later tried to replicate the same results using the same method, but it hasn’t really scaled that well outside of Google. One popular theory as to why this is is that OKRs typically work fantastic within an already high-performing culture with a heavy individualistic mindset. It integrates seamlessly within engineering teams that tend to understand the logic of the method and the need to break difficult tasks down into smaller work packages. It does not translate very well to teams that do not meet these criteria, to the frustration of many.

Before this was realized, software to support execution in the real-time era was many times adapted from IT organizations, for example, Jira or Trello. Whereas they performed as expected for engineer-heavy IT teams where rule-following came natural and system complexity wasn’t really an issue, they often times failed to grab popular support outside the IT community. They were too rigid, or too difficult, or oftentimes teams outside of IT just wasn’t eager or able to adapt the underlying method that came along with the systems (for example, work breakdowns or sprint planning).

Of course, different developers took different approaches. Some chose to continue some of the trends of the first era, choosing to increase the system integrations and trying to please end-users by getting rid of repetitive administrative tasks as much as possible. This was at face value the modern thing to do, since who could argue for increased manual registration. However, as many CTOs have had the chance to experience first-hand, this type of integration project is very time-consuming and costly. Most often it simply failed after a couple of million revenue to IT consultants or at least delayed the start of the project by a year or two. This today is heavily criticized and unless it’s the CEO’s first time being presented with a systems integration project, it is most often refused outright. (Please note that the trend is different for operations software where integration is often a necessity. What we are referring to here is (strategy) execution software, where the trend of heavy integration is most certainly passed).

An alternate, and ultimately more dominant trend was to simplify. Systems were increasingly stand-alone since this helped decrease the time of implementation.

This led up to the third, and currently the most modern trend, that we’ll explore in the next blog post covering the proactive era.