How to learn a new domain quickly
Get back into your comfort zone as soon as possible!
So you've joined a new company and/or team. Maybe you're working on a completely new product. Congratulations on getting out of your comfort zone and challenging yourself. How do you get back into your comfort zone where you are most productive?
Let me first acknowledge that I always find it a little nerve-wracking, even though I've been lucky enough to experience new projects, teams, and domains many times in my career. There's always a bit of self-doubt that the techniques I've learnt to date will no longer apply, but so far (touch wood), they've served me well.
I approach the challenge of learning a new domain in four phases that I'll now christen the four Ps:
Product - understand the product that the team/company is building.
People - understand how the company and/or team is organised?
Program - understand the technology (software "program"...I wanted a catchy mnemonic).
Process - understand how the team/company operates?
But first, how do I organise my thoughts?
Learning a new domain is an exploration of the unknown (to you). Therefore, I've found brainstorming techniques designed for exploration extremely handy. For example, mind maps are great for linking related thoughts that you pick up from random documents or conversations. They let you visualise relationships and group ideas together. Mind maps also let you go deep into rabbit holes to satisfy a curiosity and later trace back up to return to higher-level questions.
Gap analysis is also something I do; when something doesn't quite fit into the mental model that I'm building up, I note it down as a question to address, and it may indeed be a gap that I can help address.
Eventually, I will write a structured summary document to serve as a reference for you and others later. By writing a cohesive and comprehensive description of a domain, I've proven to myself that I know enough to be productive.
#1 Understanding the "Product" you're building
Why does your new company or team exist? What is their purpose? Knowing the answers to these questions helps to understand:
Why (technical, organisational, business) decisions have been made.
What are the priorities for the team, and how did they come about?
Who the stakeholders are.
Understanding the product(s) of the company, and of the specific organisation that you join, is crucial. It provides context for decisions made by various levels of leadership, helps with your interactions with other teams, and may even facilitate your movement within the company.
I use 'product' loosely to mean 'the thing of value that your team, org or company produces'. It may be a sold product, some platform services, or even a human service.
How does one go about this?
Learn the product: Start with public documentation (sales, technical docs), followed by internal product documentation for more depth. In the case of internal platform teams, the public docs are those shared with other teams. Some information to keep an eye out for:
How does the company or team cohort their users? Are there different users by industry, country and/or size? Even for a platform team, you should understand how your direct users (other teams/products in the company) think about their users as it affects how they use your platform.
Is there another side to the product? What is presented to users is typically a simplified story based on what they care about. For example, Stripe Capital looks like a loan to users, but there are two sides—A user accepts a loan, and someone else is lending money. For platforms, you not only support your direct users but likely have constraints from your dependencies (e.g., the cost of using cloud services).
Understand the 'jobs to be done': Why does each stakeholder care? What do they need to do when using the product? This is where use case mapping, user stories, user journeys, business process modelling, etc., come into play. I like to understand the summary of 'jobs to be done' and the steps that users take, which may reveal interesting details and gaps. This applies equally to platforms; what do your direct users need to accomplish? Using a product typically includes at least the following:
Discovery - how do users learn about a product and realise it is useful?
Onboarding - How do users start? What information do they need to provide? Can they self-serve? How do they test it and then take it to production?
Using the product itself - what are the key workflows? Think about basic through to sophisticated users and/or different cohorts.
Administration—After using a product for a while, what other ancillary tasks does a user need to complete? Do they need to add and manage collaborators? Are there security settings? Monitoring and observability? Reports?
Support - If/when something goes wrong, who do users contact, and how are these support teams supported?
All this information should help you build a skeleton of a model for how your company, team and system(s) work. This skeleton can then help find and absorb information from the library of documents the team probably has.
Understanding the product is more than reading docs from your company and team. Try the product yourself ('dogfooding'). Do some competitor analysis by reading their docs and testing out their products. And, of course, interview people, including product managers and cross-functional stakeholders. This is a nice segue into...
#2 People
When you enter a new company and/or team, you'll probably be given a list of people to talk to (or, if not, incrementally build up a list by asking around and collating authors of interesting documents). Having a mental model of the organisation alongside a model of how the product works helps make the most out of conversations with these people. You can ask intelligent questions and slot the information from discussions into the appropriate part of your mind map (from "How do I organise my thoughts"). Understanding the organisational structure also gives you hints about the technology (yes, Conway's law is true, so use it to your advantage).
How can you ascertain the organisational structure? In addition to org charts (if they exist and are up-to-date), you can get hints based on how the product works. Teams may be structured by cohorts (e.g. those 'enterprise' teams whose features are for enterprise users) and by user journey (stream-aligned teams may own end-to-end flows, platform teams own cross-cutting components). These hints help when you ask people how they or their team fit into the org.
#3 "Program" (or really) Technology
As technologists, we need to understand the technology. You'll have some relatively up-to-date system diagrams and design docs if you're lucky. Ultimately, it's all about the source of truth for system documentation - the code.
You may be wondering why, as a technologist, I consider technology the third stage of getting up to speed. The main reason is what we learn in #1 Product and #2 People phases accelerates our understanding of the technology. Tracing user journeys we learn from #1 Product is a consistent means of learning a code base. If there are tests, they should align with some user journey. Code is also hopefully broken down into components that somewhat map to journeys and probably the org structure we learn as part of #2 People. As a corollary, jumping straight into code without the broader product and org context can be overwhelming and hence slow you down.
I've also found 'gap analysis' useful. As I learn about the product, I start designing a system from scratch in my mind. Then, when I read the code, I try to map it to my design. Hopefully, I'm close, and I just need to note differences that mayhighlight gaps in my mental model.
Other techniques include:
Working on a few small but different bugs or features. This helps you set up your environment and get a sense ofdev velocity and pain. However, they can be a time drain if you're not careful. Whether senior engineers should code is a whole other blog post.
Reading pull requests can help you understand the coding process, syntax, and quality, but it can be challenging to understand an entire system (the semantics). Being part of any design reviews as an observer is better for that.
Code walkthroughs with other team members, especially in conjunction with some user journeys.
#4 Process
Finally, we get to how the company and your team function. What is the end-to-end lifecycle of a feature? What artefacts are produced, and who reviews them? Are reviews formal checkpoints or just recommendation forums? What are the pain points for the process? How does it relate to other companies and teams you have seen? What tools are used for planning and tracking?
In addition to feature development, it's also valuable to understand 'keep the lights on' work, as it is a significant amount of a team's effort and often affects team velocity. Read through the backlog of KTLO tickets and get a sense of volume and size. I've found it valuable to group and analyse tickets to understand the type of work and components driving most KTLO.
What's next? Rinse and repeat!
Congrats on getting to a somewhat productive level of understanding. Depending on how new the domain is to you, it might take weeks or a couple of months, but hopefully as you go you'll pick up a few areas to deep dive into to solve and deliver value on as you ramp up.
Even after you feel you're productive, it isn't the end. The more you talk to people and get involved, the more you add and modify your mental model. Ideally, you should be updating your personal documentation. This can be hard to remember to do, but a good motivation is to remember that you can share with new starters to help them out.
Great framework! I'll be quoting some of this in an upcoming article!