Good teams are diverse. It’s a universal truth that we all accept and understand at every level. The challenge we now have is how do we define the measure of diversity that makes building the best teams possible and, further still, by what criteria do we measure diversity in the first place? There’s a variously told tale about the day Bill Gates met with IBM to discuss how Microsoft Windows would be licensed through the then-PC manufacturer. IBM failed to secure an exclusive licensing deal due to a number of bureaucratic holdbacks and a decision made by the well-pressed suits on its board at the time. History agrees that IBM made a mistake.
Business and technology futurist Peter Schwartz has used this story as part of his ‘what if’ style keynotes which he presents at conventions and conferences. To paraphrase his killer takeaway line, he ends with something along the lines of, “Now then, I’m not saying that IBM would have necessarily made a different decision if there had been at least ONE woman on that board…but, well, let me just leave that there for you.”
Beyond diversity 1.0
But this discussion is not about diversity per se. It’s more about the way we are now looking to build software engineering teams with more than just a set of coders.
Beyond the engagement of so-called citizen developers and citizen data scientists – yes, we know no-code tools can empower businesspeople to use some abstracted tools that work on a drag-and-drop basis – this is a story about fusion teams i.e. groups of individuals working to create enterprise software functionality.
Having your developers closer to the business can be both a blessing and a curse – Rob Farrow, Profusion
Sometimes known as a blended team, analyst house Gartner defines a fusion team as a multidisciplinary group that is designed to blend technology and business expertise to improve the outcomes for both disciplines. On paper at least, these teams speed up business transformation initiatives and reduce the barrier between IT and the rest of the business. In practice, they may not always gel as perfectly as this perfect new world of meritocracy might first suggest, so how do the mechanics play out?
Lost in translation
“Having your developers closer to the business can be both a blessing and a curse. As businesses get more and more specialized, the context of why we do what we do as developers or engineers becomes more and more important. This increased context means that the more steps between your engineers and your business, the more likely it is that critical information can be lost, in Jira [a project management issue tracking tool] tickets, in human conversations, in Slack messages etc. It can all get lost in translation,” says Rob Farrow, head of engineering at data science company Profusion.
Farrow advises organizations looking to achieve blended team advantage to put their software engineers right next to the business problems in the first instance. Why take that direct move? Because he says, they may very well solve them – and if they don’t, then that initial proximity will almost inevitably serve as a compass reading for where to go next.
“But of course, putting even professional software engineers into the lion’s den like that had implications – as we know, with great power comes great responsibility. The business is then reliant on fewer people to make sure that the problem is not only solved, but also documented, audited and understood long term,” adds Farrow.
If Farrow’s approach is somewhat direct, developer-centric and only perhaps blended by virtue of the business-centricity it affords the software engineering function, should the scales be balanced more evenly – or at least just a bit more gently?
Jeroen Reizevoort, field CTO for EMEA region at MuleSoft points to his own firm’s research, which estimates that more than two-thirds of organizations have created or are in the process of rolling out fusion teams.
“As organizations strive to become more agile, many are building composable enterprises using API-led integration,” says Reizevoort. “Fusion teams will be responsible for the complete lifecycle of the digital building blocks that are at the foundation of this revolution. These digital building blocks come in all shapes and sizes (APIs, events, bots etc.) and are created by different personas using different technologies and tools. The challenge many organizations face in enabling fusion teams is to build integrated user experiences with reusable building blocks, but doing so in a way that mitigates security and governance risks.”
With a keen eye on system health, Reizevoort and team highlight the need for having the tools in place that allow IT to monitor the integrations and applications created by fusion teams. This, he says, can help organizations mitigate security and compliance concerns. In a world where fusion mechanics are created by (as he puts it) “different personas” and where some of those personas are now actually machines (smart IoT devices, virtual compute machines and more), the need for higher level system control is perhaps reasonably justified.
In the future, such capabilities will ensure business and IT operate more cohesively, with fusion teams comprising members from both sides. All is well and good in theory so far then, but are organizations actually engaging in this fusion process to the degree that they can tell us what kinds of experiences they have had?
Fusion teams will be responsible for the complete lifecycle of the digital building blocks [behind the] revolution – Jeroen Reizevoort, Mulesoft
Multi-currency Fintech company, Conotoxia, has set its sights on a fusion teams operating model that, in its view, should be implemented in all high-tech companies seeking growth and competitive advantage. The company insists that it doesn’t even talk about cooperation between its separate departments, but rather, it works with an aim of uniting them.
“In practice, this business model may mean, among other things, that a company does not create different IT and business units. Instead, product departments may be created, consisting of, for instance, product creation specialists, developers, UX designers, business analysts and anyone else who can bring success to a task, from the idea to the implementation of the product and delivering it to the target audience,” enthuses Andrzej Arendt, chief product officer at Conotoxia.
Arendt says that this type of collaboration eliminates situations where, for example, one team in-house creates a product and then turns to another team with guidelines for completing the task.
“In our organization, IT is not a separate island accepting and executing orders according to strictly defined needs and criteria. Instead, it is a model in which all specialists, at various stages of the process, understand what they are doing and why they are doing it, and are involved in the idea as well as development of the product from the very start,” he adds.
A semantic evolution of Agile
But before we get carried away with this whole idea, let’s stop and question whether this is truly transformative, or perhaps just a form of new-age workplace workflow reinvention being spin doctored by some human resources bright spark.
Steve Wilcockson, data science lead for time-series database and analytics company KX, certainly isn’t convinced. He says that the term ‘fusion teams’ is not arising in any conversations with his organization’s customers. His view is that this is simply a “semantic evolution” of the agile/lean approach to multi-disciplinary software application development teams.
“That being said, we agree with the fundamentals behind the term’s meaning. We absolutely see business stakeholders now working to drive or respond to developments and fully engage in software development cycles; for example, stakeholders outlining requirements of and testing predictive dashboards built by the data scientist leveraging data coordinated by the data engineer,” says Wilcockson.
Interestingly, the KX team says that it’s increasingly seeing ‘three-pack-hunt’ techniques and behavior playing out at tech industry conferences, with three visitors from the same company visiting the firm’s booth.
In our organization, it is not a separate island – Andrzej Arendt, Conotoxia
“One will drive change, for example, an engineering or product manager or perhaps a procurement buyer; a second will be an analyst or data scientist either in-house or contracted; and the third is the software developer or engineer who drives and leads the sustaining infrastructure,” clarifies Wilcockson.
Whether or not fusion teams are a sustainable workable concept for the long term remains to be seen. Certainly, there is a strong whiff of DevOps, a definite resonance with open source systems of meritocracy designed to break down monolithic bastions of hierarchy, and more than an occasional nod to Agile methodologies that we have known for several decades now.
Whatever name we give them, and however we agree that they have come to the fore, the presence of more equitable, increasingly mixed, and variously differentiated team structures should allow us to champion and facilitate wider diversity initiatives at all levels – and that can only be a good thing.
Does anybody want to buy a worldwide Windows licensing contract?
