A succinct way I’ve framed the split is that a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.
Doing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.
We know strategy is an unfolding network of associations:
The evidence from the case suggests that the concept of strategy can be reappraised. From strategy as a static set of choices made at a specific point in time to strategy as an unfolding network of people, shared experiences and artifacts that is constantly being remade.
And we know that only 30% of employees can articulate a company’s strategy.
And I believe in the hyper-connected age we live in both of these things are becoming more true - that strategy is increasingly “in motion” and that most organizations are realizing their OODA loops are too slow for the modern world.
This causes the articulation of strategy to stall and get left behind - how do you articulate something in motion? It’s easier to write strategy down when it doesn’t change right?
As a result - there’s a widening gap between the perspective on strategy that the executive team has and the received ideas of the company’s direction that teams and employees have.