4 Ways to Kickstart Engineering in a new Product Domain

Do you have a team who normally works on one domain but there’s a need for them to work in another? Maybe they typically build integrations or look after reporting but you have an urgent project in billing or a high growth opportunity in another part of your product. Sometimes the priorities in a team’s domain simply aren’t the next most important thing.

One of the first things you’ll need to address is the lack of domain knowledge in a new area. From a technical and product perspective, there will be much to learn. When I say domain, I’m referring to a product domain that is internal to a product development company — domains are also commonly referred to as pillars or verticals within a business.

Why is this a problem to solve?

In software development, at a high level, our goal is to deliver customer value with quality in a reasonable timeline. To this end, planning is one of the most important activities in reducing risk. But how can you plan when the domain is unknown to you? Sure, you can get someone who knows the domain to help you plan, but that person will heavily anchor the team and it doesn’t go far enough to up-skill the team to know what they are planning for. When you don’t know what you don’t know, to have any chance of being successful, some amount of domain modelling is necessary. You need to undergo an effort to develop a mental and/or documented understanding of the system on which you are going to be working.

In our Design, Engineering, and Product teams we have an emphasis on some core principles which we feel epitomise high-performing teams. One of those is “Domain Mastery”. We believe that a deep understanding of the system being developed is key to having a good outcome for our customers. What’s more, Deputy has 18 Million+ shifts being worked on our platform each month — people rely on us to run their business. That brings us to another of our principles, “Quality Shows”. In building the next great thing, we can’t afford to lower the bar on quality for those who depend on us.

Let’s look at 4 practical steps you can take to help a team learn a new domain and hit the ground running.

1. Research tasks

Have each team member take a feature within the domain and present it back to the team.

The first step here is to break the domain into features. Reach out to one or more Subject Matter Experts (SMEs) in the domain and ask them to break it down into a collection of features. This is crucial in forming a domain model and can be considered the primary thing that a team should be familiar with. (Since writing this article and having undergone the process contained, I have been introduced to Event Storming and can see how that would have been helpful at this stage)

Each team member takes a task to learn about one or more of the features with a few key actions:

• Speak to SMEs within the business who know most about the feature
• Investigate the feature
• Create documentation
• Present back to the team

When we did this recently, engineers created an internal wiki on each feature by way of documenting their findings. They looked at the feature from the user’s perspective and also dug into the code. The documentation included high-level technical details including:

• Sourced existing internal/external documentation
• Key APIs and functions
• Relevant Database tables and relationships
• Key user behaviours

Speaking to SMEs early has the added benefit of creating dialog and a relationship with peers who will be important in the months ahead as we move into our build phase. Presenting back to the team meant we had a captive audience with everyone engaged. Simply reading or sharing documentation would not have had the same impact.

2. Know the Roadmap

When working in a domain, it is important to be aware not only of what has gone before but also of what is to come. This means that you need to understand what work is being planned by other teams in the organisation which are relevant to the domain you will be working on. It is likely you will not work in a vacuum and the last thing you want to do is create a dependency on something which is going to be removed or refactor something which is going to be rewritten anyway.

A simple way to engage with planning for a domain is to join any roadmap sessions which may be happening. This will clearly show what is being worked on now and next and give insight into what else has been identified for development within the domain. Roadmap sessions like these often reveal what teams are choosing not to work on and why. Perhaps something has technical debt attached to it which needs to be refactored first or it is a low-use feature so is not worth investing in. It can also highlight if there are any elephants in the room, perhaps some part of the application which is difficult to work with and has thus far been considered not worth time to improve.

3. RFCs are your friend

For substantive changes, we use a ​​Request for Comments (RFC)process to outline the problem, research carried out, and present suggested technical solutions. This allows opportunities for all relevant parties to review and provide feedback prior to implementation. You can read more on RFCs here.

Being forced to organise your thoughts into an RFC is a great way to ensure that you are being thorough. Comments from SMEs are extremely helpful in guiding your attention to things you may not have considered.

Some of the benefits of RFCs for working with a new domain:

• An opportunity to ask for help
• The requirement to thoroughly document solutions, trade-offs, and considerations
• Reviews from SMEs outside your team

4. Join a test party

Getting involved in testing the new domain is another great way to learn more about it.

As we approach bigger releases we go through one or more rounds of test parties where teams swarm on an initiative to test it. Specifics of how we ship with quality is easily another topic but there are some valuable opportunities here for getting exposure to a domain. Firstly, the team running the test party will have created any necessary test fixtures which is a useful insight in itself. Fixtures, amongst other things, are often useful for ensuring that an application performs at scale, and knowing where these limits are believed to be can be useful knowledge. Then there will be a high-level test strategy and, at a minimum, a checklist of things to be tested before diving into deeper exploratory testing.

There are some key learnings:

• Happy paths and advanced scenarios
• High-risk areas
• Heuristics that teams use for testing

The resources for the test party may form part of your test strategy moving forward.

Measures of success

Did these steps help us learn a new domain? Of course, it’s difficult to measure such things objectively. The team certainly enjoyed the process. For each of the features identified in step #1 we estimated our understanding of that feature on a 3 pt scale before we started; low, medium, and high. For this measure, our confidence increased for each area from lows and mediums to mediums and highs.

I hope this gives you some ideas on how to cross-train engineers in a way that is engaging and supportive. If you’ve solved this challenge in a similar or different way, or have interesting ways to measure knowledge within a domain, I’d love to hear.