Working on a cross-functional team is hard!
As specialists, be that specialization in software development, bioinformatics, or molecular biology, we are domain experts; yet, projects still fail to come to fruition on time, on budget and with the expected impact. This is as frustrating and demotivating to the non-technical manager as it is to the specialist team members.
Lets look at a case study…
Kate (software developer) and Darnell (biologist) are hustled into a meeting room by Xue (non-technical manager). In good faith, Darnell (biologist) lays bare his frustrations with the existing software. Kate (developer) records these as a list of requirements. After rubber-stamp approval by Xue (non-technical manager) and two weeks of furious coding, the revised software is ready. Unfortunately for Darnell (biologist), the software is even worse than before.
There is another meeting, with more senior developers and biologists in attendance Kate steps-through the changes she made, and how the changes address the requirements gathered from Darnell. The biologist and developers don’t understand much of each-others technical jargon, but do their best to provide input into Kate’s new requirements. The developers insist that ABI Instruments are used by the biologists because their output format is standardized, and therefore easier to import. The biologist demand that ‘big data’ capabilities are implemented by the developers. All Xue can think about is justifying the expense and deadline slippage to her annoyed higher-ups, along with the sickly feeling of having her neck being breathed down.
Sound familiar?
The organizational problem is that our specialists, Kate and Darnell, are trained to deliver ‘locally’ optimal solutions within their area of expertise; unfortunately, real-world problems are usually ‘global’. The challenge to the cross-functional team is to approximate a reasonable ‘global’ solution with a set of ‘local’ solutions contributed by each specialist. Put another way…”software problems” are few; “problems benefiting from software” are many.
Separation of concerns to the rescue
Separation of concerns (SoC) is a precept of modern software engineering. Focusing on the ‘what’, and abstracting the ‘how’, enables collaborative development on large code-bases, easing maintenance, extension and debugging.
The concept is simple: disparate modules of code must communicate through a common interface. As long as the interface remains intact, the internal workings of each individual module may be modified independently. Importantly, each developer need only know the details of their own module, and the interfaces of the modules they interact with. The concerns (implementation level details) of each module, are thus separated (self-contained, and preferably free-standing).
At first glance, this might not seem particularly relevant to Kate and Darnell, but managing separation of concerns should be a cross-functional team’s #1 tactical priority, second-only to sharing a common vision (#1 strategic priority). Separation of concerns forces our cross-functional team to focus on ‘what’, instead of ‘how’.
For the software engineer, separation of concerns means crafting sensible code modules, with a thoughtful API. For the cross-functional team member, it means understanding the high-level problem (what), coming to a common understanding (interface) with ones peers, making that understanding explicit (‘human API’), and sharing a common language to discuss solutions.
To successfully implement, each team member requires:1
Mutual ownership of the ‘global’ solution.
Gradient awareness of team member capabilities.
Commitment to communication, which includes trust, honesty and good faith.
Re-examining the case study…
Kate (software developer) and Darnell (biologist) are hustled into a meeting room by Xue (non-technical manager). In good faith, Darnell (biologist) lays bare his frusterations with the existing software. Kate (developer) politely stops Darnell (biologist), and asks Darnell and Xue about the actual ‘problem’ they’re trying to solve (mutual ownership). Putting aside specific frustrations with the software, the three discuss each others overall-process and ‘pain-points’, both biological and software (gradient awareness). The three state and adjust their understanding, and break to assess (communication):
Kate (developer): Problems that can be solved with software, pro/con for various options?
Darnell (biologist): ditto for molecular biology.
Xue (non-technical manager): Context. What are other teams doing?
After a few days of assessment, there is another meeting. Xue outlines the high-level overview discussed previously to make sure everyone is on the same-page about the problem. Kate (developer) presents the pros/cons of a few software options. Darnell (biologist) follows suit for molecular biology (communication). The group discusses the various options (mutual ownership); in consultation, Xue chooses the set of options to be implemented, and leaves the implementation details to Kate and Darnell. As the week progresses, software and biology changes are applied. Kate and Darnell touching base to reassess their understanding if an interface becomes unclear, or additional dependencies arise (gradient awareness). Their ‘local’ solutions each contribute to solving the ‘global’ problem. Concerns have been separated such that developers aren’t telling biologists how to do their jobs, and vice-versa.
Applying separation of concerns is an art
There are no right answers. The central challenge lies with each specialist coming to a common understanding of their interfaces with peers, walking the tight-rope of openness (about what) and abstraction (about how). Thus, applying separation of concerns simultaneously requires teams to understand more of the overall problem (what), so as to define sensible interfaces between team members, yet less of each-others implementation-level details (how).2.
If the proper balance of openness and abstraction is not achieved, then interfaces are either drawn too broadly (you’ll be stepping on each others toes and exposed to unnecessary implementation-level details), or too narrowly (the ‘local’ solutions of each team-member won’t work together to address the ‘global’ problem).
Done well, separation of concerns enables specialists to work together in harmony: delivering a reasonable set of ‘local’ solutions to the ‘global’ problem at hand.
Done poorly, separation of concerns stifles innovation by imposing artificial barriers: ‘local’ solutions which are ‘globally’ ineffective (and sad panda for all parties).
Cross-functional teams of the world, try giving the principle of separation of concerns a try on your next project.
- As corollaries, “not my problem”, dismissal of your peers capabilities and inter-specialty rivalry are unacceptable. ↩
- An added-benefit is that less field-specific jargon tends to be used because implementation-level details (how) are abstracted into higher-level problems (what). For example, everyone can understand that a software application is slow (what), but the biologist could (usually) care-less that it’s due to excessive network traffic (why), or that the developer resolved the problem by local caching (how). ↩
