{"id":910,"date":"2019-06-15T05:59:12","date_gmt":"2019-06-15T05:59:12","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=910"},"modified":"2019-06-15T05:59:27","modified_gmt":"2019-06-15T05:59:27","slug":"the-end-of-process","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2019\/06\/15\/the-end-of-process\/","title":{"rendered":"The End of Process"},"content":{"rendered":"\n
\"\"
Photo by Sweet Ice Cream Photography on Unsplash<\/figcaption><\/figure>\n\n\n\n

With the constantly increasing connectivity and data collection in everything from websites to the Internet of Things, collecting accurate measurements about user and system behavior in the field is becoming increasingly feasible and easy. This is causing a shift in the way we develop and evolve systems, away from requirements and instead focusing on the quantitative output metrics that we look to achieve.<\/p>\n\n\n\n

In our HoliDev model (see figure), we distinguish three types of development. Traditional, requirements-driven development should only be used for regulatory, competitor parity and commodity features. The other two types of development require the organization to define, in quantitative output metrics, what we\u2019re looking to accomplish. In the case of outcome-(or experiment-)driven development, we run A\/B\/n tests, quasi-experiments, cross-over experiments and such to test which way of realizing functionality leads to the best results. In AI-driven development, the expected outcome is typically expressed in terms of examples that are then used to train machine- and deep-learning models, but still it\u2019s outcomes we focus on, not how we achieve those.<\/p>\n\n\n\n

\"\"
The HoliDev model<\/figcaption><\/figure>\n\n\n\n

The\n real implication underlying this focus on outcome metrics is that we \nsee a shift in focus from \u2018how\u2019 to \u2018what\u2019. In traditional companies, \nthere typically is a defined process for performing tasks and as long as\n you follow the process with a reasonable level of proficiency, you had \ndone your part and could ignore everything else that\u2019s going on in the \norganization.<\/p>\n\n\n\n

Companies that focus on the \u2018what\u2019 specify for teams and individuals what the outcome metrics are that they\u2019re expected to improve. For instance, a team working on part of a large, complicated website may experience a conversion of 1.2 percent for their part of the site, meaning that 12 out of every 1000 people who come to that part do something that the company would like to see, such as buying something. Such a team could easily get as a target to raise conversion from 1.2 percent to 1.4 percent without any suggestions on how to accomplish this goal. It has completely free hands on how to accomplish the increase in conversion, but typically it will consist of experimenting with different ways of realizing specific functionality and measuring the effect.<\/p>\n\n\n\n

The\n consequence of this is, of course, that the focus on process and \nproperly following process becomes a thing of the past. In that sense, \none can view this as a major step forward in terms of empowerment of \nteams and individuals. Although the organization will provide \ninfrastructure and tools that will nudge teams towards certain ways of \nworking, in the end, the team is free to follow their own preferences to\n achieve the desired outcomes.<\/p>\n\n\n\n

However, as the saying goes, with great freedom comes great accountability. With the focus on outcome metrics, the performance of teams and individuals becomes transparent and quantitatively assessable. This can be uncomfortable and confronting for teams that have up to now been able to hide behind the argument that product management told them to build something. Typically, cross-functional teams will be on the hook for delivering results that matter to the organization as a whole. And if the results are not there, obviously this is not without consequences.<\/p>\n\n\n\n

The end result, however, is that rather than acting as a small cog in a huge machine of processes, teams and individuals now have real, tangible and actionable impact on the organization. You can bring your whole self, including all your creativity, curiosity and beliefs about customers, to work and do something with all that energy and initiative that you walk around with. A little bit of discomfort is a small price to pay for the end of process!<\/p>\n\n\n\n

As a leader, the challenge is to reflect on whether you \nfocus on the \u2018how\u2019 or the \u2018what\u2019. Do your people know what we\u2019re looking\n to accomplish and why? Or do you insist on them blindly following a \ndefined process with the assumption that the desired outcomes will be \naccomplished? Are your people empowered to bring their full selves to \nthe challenge at hand or are they treated as standardized cogs in a \ncomplicated machine? And if you feel that your people are not ready to \ncarry the responsibility that comes with empowerment, whose job do you \nthink it is to get them there?<\/p>\n\n\n\n

In many areas of business, the time has come to shift from a focus on process to a focus on outcomes. Empower your people to focus on outcomes and evaluate them based on those. To quote Victor Hugo, nothing is stronger than an idea whose time has come.<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at<\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>) or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

With the constantly increasing connectivity and data collection in everything from websites to the Internet of Things, collecting accurate measurements about user and system behavior in the field is becoming increasingly feasible and easy. This is causing a shift in the way we develop and evolve systems, away from requirements and instead focusing on the … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/910"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=910"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/910\/revisions"}],"predecessor-version":[{"id":913,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/910\/revisions\/913"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=910"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=910"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=910"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}