The Domain Trap: Hiring for Domain Knowledge in Software
We’ve been there, needing to solve a business problem with software. We choose first to hire for the business domain and second for the skills and competencies in software development. An “accountant” who “also can code”. This seems like a win. A two for one. And early stage and short term it is, but longer term it turns out to be a mistake.
So how should we think about the impact of domain specific knowledge in software?
How We Got Here
In business, the domain comes first and is the number one priority: the reason it exists and what it provides. This could be insurance, financial services, or cars. Businesses are organized around their domain, and this structure drives the behaviors of the organization. This spills over into the software that is provided and used both internally and externally.
Traditional businesses magnify this as a legacy artifact of how software and IT grew up playing a supporting role to the core business. Canonical examples of this abound with businesses providing their customers websites that mimic old paper based forms and in-person interaction flows even though better ways now exist. This type of thinking can also be true of pure software based organizations that provide software that does a previous task.
For early stage companies, core domain knowledge is essential. This is typically driven by the founders who start a company with deep knowledge in a domain identifying a better way or an unserved need of the customer. By understanding the domain and it’s place in the markets, they are able to quickly provide a solution which is a major driver of getting the business off the ground and early success.
As companies mature, this approach is often seen as what defines the company and its culture. They hire for people’s passion in a domain so they can “do what they love” and retain that culture, and it can also be seen as a cost savings measure not having separate roles for subject matter experts.
While this post deals with the problem of domain first in software, the opposite is also true and prevalent. When a group of technical people attempt to apply a purely technical solution to a problem without involving expert domain knowledge, the results are highly problematic.
The Downsides of the Domain First Approach
As a company grows past initial stages, the domain first approach that was an advantage often becomes a limiter. It eventually becomes a liability, and sets a company up for disruption.
Hiring and growth become problematic
The pool of qualified candidates with domain knowledge and the required software skills is limited which is a self-created cost of delay looking for unicorns.
Candidates found are often incredibly knowledgeable in their domain, but have mediocre skills in their main software job. This is often overlooked or excused due to their knowledge of the domain or product. In addition, this pool of candidates is full of people who spend their career entirely within a domain, going back and forth between different companies in that domain.
Because domain knowledge is highly expected, tacit knowledge is baked into every task and new hires take a longer time to become effective. This also means that losing people after they have a good working knowledge of the domain has a big impact.
Innovation and change become hard
The company sees the domain as it’s identity, and breeds a monoculture. This culture decreases diversity of thought and perpetuates the status quo by championing ideas from those with extensive domain knowledge. The “this is the way we’ve always done it” approach becomes the norm, limiting growth, entry into new markets, customers, and channels.
A Drift Into Failure
Sometimes this is the result of an explicit choice, but more often this is a result of years of normalized decisions — what Sidney Dekker would call “the normalization of deviance”. A series of incremental conscious and unconscious choices that slowly drift an organization away from the best approach to their current situation.
What started off with the domain being a key driver of success is never updated and slowly turns into a limiter. This is often due to our biases, including hindsight and outcome bias based on initial success.
When interviewing we unconsciously connect with and rate Billy at higher than Suzie. Instead of talking about the needed skills, we talked about the domain, which is near and dear to the business. We unconsciously overlook the fact that Suzie is the better programmer with better skills and potential. Even though our team really needs Suzie’s skills, we drift from the better decision.
Escape the Trap: Hire for Craft First
The best way to escape the trap is to not get into it by being aware of what role domain knowledge plays in your organization. For early stage companies, it’s a necessity you can’t avoid. Eventually what was a good trade off makes you less effective and a transition is required to escape the trap.
If you find your organization in the domain trap, one way to escape it is to shift to consciously hiring for craft in software over domain knowledge. This is a lot easier said than done and requires a deliberate plan and execution to build a structure that will drive the desired behaviors. It also won’t happen overnight and will require micro-experiments to slowly hone in on the support needed at your organization. How you make this happen is highly dependent on the complexity of the domain and your organization’s tolerance for change.
The results comes with a lot of advantages that are often overlooked:
- Teaching someone a domain is comparatively easy after someone has spent time learning a complex domain such as software engineering
- Teaching someone a domain requires you to explain why something is done the way it is and if done well allows you to question assumptions of the why. This improves your organization, your onboarding, and helps codify tacit knowledge. This simple feedback loop has the potential to eventually make a huge impact improving your teams and organization.
- Increased diversity of thought, breaking up the monoculture and injecting new ideas that can lead to innovation breakthroughs.
- Some of the best software engineers and product people I’ve worked with had background and experience in other and varied domains. While this a personal anecdote, it has been shared and echoed throughout my career.
Splitting Into Subdomains
One approach is to split groups or teams into sub-domains based on the activity. Still hiring for craft first, but limiting the scope of the necessary domain knowledge. This is not a new or novel approach and is commonly done by creating a team around that subdomain, such as ecommerce.
This approach is simple and effective allowing hiring to focus on primary skills and reducing the domain knowledge gap. The downsides of this approach include creating silos and even entire business units that are disconnected from the domain slowing down the whole or delivering products and services that are disconnected and be confusing to customers.
Some subdomains, such as payments, aren’t seen as very exciting to software engineers. Combat this with several other practices including team rotation and a focus on other software engineering practices.
Centers of Excellence
Once you have made the decision to hire for craft first and teach your domain, you will need to augment knowledge of that domain. Creating a Center of Excellence (CoE) is a proven method that can help. A CoE’s goal is to advance the state of the craft within the company, share innovation, learning, and understanding, determine principles and standards, clear impediments, and provide assistance in a servant leadership capacity.
A CoE is a small team with open and transparent goals that are championed and sponsored making it an organizational priority. A CoE with executive priority is key to driving change within an organization, but efforts can’t all come from the top.
Communities of Practice
Besides a CoE, sponsoring a Community of Practice (CoP) to share learnings across teams will bring additional benefits. A CoP is voluntary with an open invite to all to participate allowing people passionate about the subject to teach and evangelize in a more personal and less formal way. This is your typical grass roots effort, but grass roots can only go so far, which is why to be effective requires a coordinated effort with a CoE.
The Role of Domain In Your Hiring Strategy
Where does your domain fit into your growth and hiring strategy?
Software organizations are complex adaptive systems with people at their core. First determine what role the domain is currently playing in your organization’s culture and practices. Then evaluate if your current approach is problematic and if a change is to your advantage.
- Be aware of your domain bias. Ask how it may be impacting your culture and hiring practices
- Look for signs of a domain-driven monoculture
- Ask if your domain first approach is currently limiting innovation and perpetuating the status quo
- Set up CoPs and CoEs to strengthen your organizational culture across your domain and software craft
Finding the balance of domain knowledge and software skills needed within your organization for its stage of maturity and growth is an important aspect of business effectiveness.
Thanks, Inspiration, and References
Thanks to my reviewers: John Noble, Bernardo Fanti, Trisha Palmer, Yuvarani Loganathan
