{"id":1387,"date":"2021-12-16T08:12:47","date_gmt":"2021-12-16T08:12:47","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1387"},"modified":"2021-12-16T08:12:48","modified_gmt":"2021-12-16T08:12:48","slug":"platform-lesson-1-platforms-should-focus-on-speed-not-efficiency","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2021\/12\/16\/platform-lesson-1-platforms-should-focus-on-speed-not-efficiency\/","title":{"rendered":"Platform lesson #1: Platforms should focus on speed, not efficiency"},"content":{"rendered":"\n
\"Image
Image by Gerd Altmann from Pixabay<\/figcaption><\/figure>\n\n\n\n

Traditional thinking is that platforms are about efficiency through reuse. Product teams get a bunch of functionality for free from the platform and only have to build the remaining product-specific functionality. The interesting thing about software reuse is that it\u2019s been extremely successful at the inter-company level. The amount of software that\u2019s being reused through operating systems, commercial software products, the open-source community and software ecosystems is phenomenal. Compared to the situation in the 1990s, when I came of age in the software community, it\u2019s incredible what we\u2019ve accomplished.<\/p>\n\n\n\n

For many companies, however, the sharing and reuse of software developed in the context of the company itself, ie intra-organizational, still proves to be a challenging and uphill battle. The conceptual idea is to develop a platform that all product teams can use to build their respective products. The reasoning is that by focusing on building common functionality only once, we can save development effort by sharing this common functionality through a platform.<\/p>\n\n\n\n

In practice, unfortunately, the interface between products and the underlying platform tends to be incredibly complex and tends to result in a situation where the platform slows everyone down. There are several reasons for this, but the main one is that software is different from mechanics. Although the functionality in the platform might be common, very often product teams find out that they need a different flavor or that some part is missing. The product teams need to request this functionality to be developed by the platform team, which often gets overwhelmed by all the requests. The consequence is that everyone waits for the slow-moving platform team.<\/p>\n\n\n\n

This is a specific instance of a generic pattern I see time and again: when companies focus on efficiency, the consequence tends to be that everything slows down. Whether it\u2019s approval processes, bottlenecks, reviews or coordination problems, the behavior in service of efficiency tends to put hurdles and delays in the ways of working, causing delays everywhere.\u00a0\u00a0<\/p>\n\n\n\n

To address this, we should design platforms and the ways of working around platforms to maximize speed. Speed to get new functionality out to customers. Speed to extend the platform with the functionality required by products. Every activity and use case should be designed for speed. To achieve this, there are at least three strategies I\u2019ve seen companies use in practice.<\/p>\n\n\n\n

First, make the use of the platform optional. In many traditional platform setups, product teams are forced to use the platform and this tends to make the platform team prioritize its own efficiency over the efficiency of the product teams. By making the platform optional to use by product teams, the priorities of the platform team tend to change in favor of serving the product teams.<\/p>\n\n\n\n

Second, allow product teams to change the platform code. In traditional software development, only the team responsible for a software asset can make changes in it. However, with the increasing adoption of continuous integration and test, it\u2019s much less risky to let others touch the code as their mistakes are captured immediately. As platform teams tend to be overloaded with change requests, allowing the product teams to make the changes in the platform code that they urgently need can remove the bottleneck in development.<\/p>\n\n\n\n

Third, it\u2019s possible to do away with the product\/platform dichotomy altogether by creating a configurable product base where the superset of all functionality is in one code base and each product simply becomes a configuration of that superset. This will be the topic of the next lesson.<\/p>\n\n\n\n

When companies focus on speed, interestingly, efficiency is a side effect. To gain speed, teams tend to look for ways to automate and in other ways reduce the amount of time needed to accomplish various outcomes. The consequence is a significant increase in efficiency. The takeaway is that focusing on efficiency slows you down and focusing on speed makes you more efficient! So, focus on speed and get everything else as part of the deal.<\/p>\n\n\n\n

Like what you read? Sign up for my newsletter at\u00a0<\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>), Medium<\/a> or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Traditional thinking is that platforms are about efficiency through reuse. Product teams get a bunch of functionality for free from the platform and only have to build the remaining product-specific functionality. The interesting thing about software reuse is that it\u2019s been extremely successful at the inter-company level. The amount of software that\u2019s being reused through … 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,3,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1387"}],"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=1387"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1387\/revisions"}],"predecessor-version":[{"id":1389,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1387\/revisions\/1389"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1387"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1387"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}