I was tagged by my fediverse friend Dr Doug Belshaw on Mastodon requesting a review of an article. Never one to be backward in coming forward with an opinion, particularly when asked, I sat down to write a response. But my Mastodon instance's 500 character cap militated against a post there. Disdaining social media's enthralment with 'threads', here is my longer form response.
In a recent article on ambiguiti.es, Doug Belshaw mused on Sitting with ambiguity for innovation projects (or life in general!). The article struck me, as most of Belshaw's work does, as being equal parts philosophical and deeply practical. As Burke (1957) would have it:
The End of learning is not knowledge but virtue; as the End of all speculation should be practice of one sort or another… [for] Knowledge is the Culture of the mind; and he who rested there, would be just as wise as he who should plough his field without any intention of sowing or reaping.
Belshaw sets the scene with a brief look at what Agile Software Development sought to address. That:
Instead of having to know everything up front and then embark on a small matter of programming, there is the recognition that meaning can accrete over time as systems develop.
But what is seldom discussed is why meaning, or knowledge for that matter, accretes. Often it is a result of the maturation process, whereby a business embarks on a new initiative and steadily learns what is needed—either though market feedback (knowledge creation) or simply because stakeholders gain an understanding of how the process works in other settings (knowledge accumulation). This is write large in organisations that are in the launch or growth phases of the classic business life cycle and results from interactions in a two-sided business model (Muzellec & Lambkin 2015).
But this is also the result of stakeholder turnover in a long running project. An example of is when an agile project begins with one business owner, who subsequently leaves the organisation and is replaced by someone who sees the business process flow in a fundamentally different way. A side effect of many a new manager's need to show they are a new broom capable of a clean sweep. In such situations, the development team now have two, often competing, sets of business requirements and a need to harmonise the architecture and build to accommodate the new management direction for the project—without starting development from scratch.
Another observation by Belshaw's is:
A tendency that I see with many innovation projects with which I’ve been involved is a lack of tolerance for ambiguity.
Citing Benson, Belshaw argues that a cause of this intolerance for ambiguity stems from the reality that because:
we never have enough time, “we jump to conclusions with what we have and move ahead”. In addition, because the world is a confusing place (especially when we’re doing new things!) “we filter lots of things out” and “create stories to make sense out of everything”.
But I would contend this is only to surface the business or innovation side of the equation. To expand on Muzellec & Lambkin's (2015) two-sided model and turn it into a tripod of interaction—between the business, the customer and the development team—is to apprehend what, in my experience, brings even more pressure to bear on leaders who seek to embrace ambiguity.
Engineers are, as a general rule, very concrete thinkers. They require highly specific acceptance criteria (AC) for a build, and will test based on a largely inflexible understanding of this criteria. By way of example, in a project on which I am working at present, a tester flagged a 'bug' because in the AC the business analyst (BA) had written 'enquiry' in the body text of an automated notification, but in one instance of the supplied text had spelt the word as 'inquiry.' The developer had unexpectedly embraced ambiguity and inferred a consistency the BA had intended, coding 'enquiry' in all instances. The tester however, unable to embrace ambiguity, rigidly saw this as a deviation from the AC. A process that is doubled down on as testers increasingly use automation to test what are ambiguous business processes, in that they are still evolving.
This small vignette is to some extent inevitable in roles where nailed down accuracy is everything. As my statistics professor, John Croucher, would frequently opine: the difference between 0.1 and 0.01 is an order of magnitude and may result in a bridge sustaining traffic or collapsing into the sea. The result is that in business, roles are largely bifurcated into those that have decision making authority and those that don't. In some cases, this bifurcation is augmented by employees who abjure ownership of a problem. As a former colleague was fond of saying: "I take all care and no responsibility".
As a product owner I am a decision maker in the process, empowered by my positional authority to speak on behalf of the business. While I may rail against some of the seemingly asinine questions I get during my working week, I need to check my frustration and remember that while I am paid to embrace ambiguity and lead a product's direction, other members of staff are required by the business to follow that direction.
In summation, Belshaw doesn't offer a conclusion, but an exhortation:
sit with ambiguity! And while you’re sitting with it as a team, talk about it and resist the temptation to bring in dead metaphors. Instead of conceptualising the conversations you have about the project as “going round in circles” consider instead that it’s more likely that you are spiralling round an idea in an attempt to better understand and define it.
I will follow suit and also conclude with an exhortation: for leaders to embrace their positional purpose—to take stakeholders on a journey. Sit with ambiguity, but be aware of when a seemingly circular conversation is enhancing a definitional understanding and when it is just a group of individuals unable to comprehend ambiguity hoping that a drawn out conversation will nail down the problem. A conundrum writ large when process owners don't fully understand what they are trying to achieve and are, to use a colloquialism, 'making it up as they go'. Which is not the same thing as innovation.
The former, making it up, is the result of a lack of knowledge and grasping for any rope that may be available—even if that rope is a noose. The latter, innovation, is when knowledge is augmented with creativity, and represents the zenith of great business processes. Once this nuance is grasped, an organisation is better placed to embrace ambiguity while providing the necessary clarity to advance the development process.
Good night, and good luck.
References
Belshaw, D. (2022, February 11). Sitting with ambiguity for innovation projects (or life in general!) – ambiguiti.es. https://ambiguiti.es/sitting-with-ambiguity/
Burke, E. (1957). A Note-Book of Edmund Burke. Cambridge University Press.
Muzellec, L., Ronteau, S., & Lambkin, M. (2015). Two-sided Internet platforms: A business model lifecycle perspective. Industrial Marketing Management, 45, 139–150. https://doi.org/10.1016/j.indmarman.2015.02.012
