Captain Domain Knowledge to the rescue
We need a combination of technical insights and domain knowledge to build quality software products.
Some domains are easier than others: clinical research is harder to explain than e-commerce. Some fields have experts with deep knowledge, and some require us to build that knowledge as we go along.
When developers need to solve problems, they'll often need more domain knowledge. If you don't understand the problem, you can't design the solution.
Most organizations solve this by assigning domain specialists. For easier domains, these are often Functional or Business Analysts. For more complex ones, we often rely on an expert.
The job of these domain specialists is to bridge the knowledge gap. They need to answer those pesky questions that the developers can't.
Unfortunately, this leads them to become yet another bottleneck in the process. If developers have to turn to their domain specialist whenever they encounter an unforeseen edge case, that's horrible for flow. In the best-case scenario, the expert has an agenda overflowing with refinement sessions. In the worst-case scenario, they become the wings of the V-model: they'll come up with the solution, specify what the developers need to code and verify that they've actually built the right thing. On top of that, they still need to be available for every ad hoc question and uncovered edge case. Such a tiny neck isn't proportional to the size of the bottle.
When we speak of knowledge sharing in software development, we often mean sharing technical knowledge. But if we want to eliminate the domain bottleneck, we must also share domain knowledge.
But how do we do that? How do we share knowledge in such a way that it removes the bottleneck?
One approach I like is assigning a "captain" to each problem. The captain is a team member who will be leading the solution design. They will set up refinement sessions and invite the right people to write the problem and solution descriptions. They'll be responsible for delivering the solution but should delegate most work to other team members.
For example, let's say we're running an e-commerce site and a lot of visitors put stuff in their basket but rarely buy. How can we improve conversion rates?
We assign one of our back-end developers as the captain of this problem. It's her job to get the right people around the table and devise an A/B experiment. She'll have to lean on our domain expert, whose input on buyer psychology will be invaluable. She might enlist a designer or front-end dev to help visualize the solution.
When we start developing this solution, something magical happens. Edge cases and questions don't get bounced back to the domain expert. The captain has enough domain knowledge to tackle edge cases and make 80% of the decisions. She can make calls that previously would have required a meeting with the domain expert. We now have two people with knowledge about "abandoned cart logic". She also has a basic understanding of buyer psychology that will come in handy in the future.
After a few weeks, our A/B test gathered some interesting feedback, and we are ready to solve the problem. We start the cycle again. This time, we'll assign our infrastructure guy as the captain. He'll organize the refinement sessions and will definitely include the previous captain, as she has valuable domain knowledge. They will depend less on the domain expert. As time passes, the domain knowledge spreads throughout the team.
The idea isn't to phase out the domain expert completely. In most domains, that's impossible. What we want to do is reduce the demand for this person. We want to see these specialists included in the scheduled refinement sessions rather than ad hoc during development. We want to put developers in a position where they can make informed assumptions rather than having to stop and ask for validation.
Assigning a captain to problems is a practical way of sharing domain knowledge. It's also a surefire way of growing leadership talent in-house.
If you're building a product and find development is often blocked because of questions, give it a shot.