Onboarding the Team

Starting the migration journey is an exciting experience that often leads to unfamiliar territory. The path is likely to have trade-offs and issues requiring more than a query to Stack Overflow. Selecting a single experienced engineer, or at most a small group (two to three) to lead the way is important for setting your team up for success.

The engineer(s) who’ll blaze a trail would ideally have the following qualities:

• Proven record of leading technical decisions
• Historical context of the existing application (or access to someone who has context)
• A track record of making good trade-offs under uncertain conditions
• Willingness and ablity to guide others through the new software stack

This type of engineer is rare. They have a wealth of technical knowledge, know when to apply their technical skills, and regularly work outside of their comfort zone. If your company doesn’t have one person with all these qualities, we suggest putting together a small team that covers all of these traits and collaborates well together. In the team scenario where each person brings different skills, be wary of any one person dominating the decision making. If one person dominates, you might end up with decisions that don’t reflect all the needed perspectives. To avoid this, it can be helpful to establish some shared ground rules before meetings and team discussions, and when facilitating team meetings make sure all participants have time to speak and are involved in making decisions.

If your team is highly experienced and each engineer has all four qualities outlined in the previous list, then each individual operating in parallel, seeking advice from other team members as needed, can be very effective. Each team member in this scenario should be playing to their strengths to maximize their autonomy. Design by consensus will be slower overall, without getting better outcomes in this situation.

Once you’ve got your team of trailblazers assembled, it’s time to start laying down the foundations outlined in Chapter 3. In the initial stages, the scope of the project will be fuzzy, so setting the team’s context and clearly outlining the goals for the early foundational stage will be more useful than giving the team a list of granular tasks.

For example, at Buffer we needed to enable teams to work together in a bigger codebase more effectively and we needed to make the local development environment a better experience. Exactly how our trailblazing engineers achieved these goals was up to them.

The trailblazing engineer(s) can set up the development environment as shown in Chapter 3, initialize the component library, and migrate the first Atom. The foundational work here covers everything needed to get to a stage where Atoms can be built, tested, published as packages, and consumed in the existing application.

Once this is complete, the next step is to build the new application base, following the observer pattern so that packages are only loosely coupled to each other because they’re all listening to event changes coming from the Redux store.

As the new application base starts to fill out, with applicable Atoms also shared to the existing application, the scope of the project will start to come into focus. The product manger will understand what needs to be built next, and engineers will have more clarity on how to build it. This shift from foundational engineering work to becoming driven by a product roadmap is a key tipping point. When this shift happens, it’s now time to bring in more engineers.

It is important that the scope of the next feature is very clearly defined so that the new engineers joining the project can use building that feature almost like a tutorial to drive their learning of the pattern. It is OK if the foundation is not complete in the new application when the next feature is being scoped. If the trailblazing engineers have a good understanding of how to build the project, they should be able to write up documentation and onboard the next set of engineers while the foundation is still being completed.

The trailblazing engineers’ goal should be to teach the new engineers how the system works and get them to the point where they can work autonomously. How the trailblazers teach depends entirely on the learning styles of the newly joining engineers. Some people prefer to operate independently and ask questions, while others prefer to have guided learning sessions. Both methods can be highly effective ways to level up the team to work autonomously through the process described in “Migrate the First Molecule”.

Enabling Independent Work in a Shared Repository

As more engineers are onboarded into the project, the need for guidelines on how to work together becomes increasingly important. Doing work in a shared repository in the same files is going to lead to merge conflicts and waste development time.

In “Architecture”, a few different types of packages are described. The store, backend, and frontend packages are shared across the application, while the molecule packages usually focus on one feature. These package properties provide some natural guidance on how work should be done and teams should be formed.

The molecule packages are typically isolated and independent, which means they can be worked on in parallel. Teams of two to three engineers should be formed around the molecule packages, where the molecule package is scoped at the size of a single feature of the application. The team should own the implementation of the package from the beginning until all tasks related to the feature are complete before moving on to another package. If at a later time the feature needs more functionality, the package can be revisited by the same team or another team.

Teams can operate in parallel with minimal conflicts or communication overhead because packages are logically separated into folders and each package communicates through the reducer via actions. Another benefit of this organization scheme is that a package can be completely rewritten without impacting the entire application. This allows teams to embrace change, rather than avoid it, as better libraries and practices come along.

However, when teams need to work in another package that is shared across the application, more communication is required. To increase communication and minimize conflicts on shared packages, some lightweight processes are helpful. For example, requiring a code review from at least one person on another team before merging on shared packages increases visibility with minimal impact on engineering bandwidth. We recommend this code review flow as a starting point. As the codebase and teams expand and shared packages impact more teams, defining shared package ownership processes for your team will become more important.

The Product/Business Driven Engineering Team

This team usually has a high proportion of engineers dedicated to supporting the product or overall business needs, and the roadmap is business or product orientated. Teams like this often work with another team such as product, marketing, or business development, handing over a specification or list of requirements to the engineering team, who then execute against these requirements.

In teams like this, a waterfall model of development can still be common. This type of team is usually focused on delivering business value and may find it harder to make time to address technical debt or undertake engineering projects that show longer-run returns. Teams like this more commonly view technology as part of the business, rather than the core business itself—for example, a “brick and mortar” retailer that has an online presence.

In this type of team, your main stakeholder is whoever sets the specifications that engineering executes (business development, marketing, or product team leadership). The main obstacle you’re likely to face is finding the time to do the early foundational parts of the migration, such as setting up your component library and building the first Atoms. This is the stage where initial setup is probably slower than working directly in your current application would be.

Given that you need to gain support from a business-value oriented person or team, that the time taken for the initial setup will be your major hurdle, and that once that’s passed you’re less likely to need further buy-in as the migration continues, the most effective approach here is to emphasize the upfront investment, which will dramatically increase the speed of execution for a long time.

To do this, we recommend that you avoid sharing a grand vision and announcing plans for a major rewrite, and stay very focused on business value. Your main advantage here is that if your stakeholders are not directly involved in the execution, you probably have greater autonomy in how you deliver those features.

Emphasize the overall benefit to the business of a new way of working that lets your engineering team experience a consistent, long-run step up in productivity, getting features to market sooner. Explain that you’ll do this through reusing your code more effectively, so you can build out of existing code chunks, rather than rebuilding everything from scratch each time you ship a feature. Emphasize that reusing these robust code components will improve the quality and consistency of features for your users, and will allow overall changes such as a brand refresh or an adjustment to color schemes to be done more quickly to a better standard.

Leading with all the benefits, getting support, and only then requesting extra time is a good approach for stakeholders who need to see business value to justify an extra engineering investment. Saying “we can make all these useful business outcomes happen by Q2, and we just need to schedule in some initial setup to unlock these advantages” is more likely to get you support than going in saying you need to take some extra time out of the product schedule to do a technical task without explaining the value of what you are doing. In the first approach, you’re 90% of the way to a “yes.” The second is an immediate, reflex “no”. Only once the mutual benefits are well understood (and that could take weeks or months) should you ask for the upfront time you need to set up the migration and do the trailblazing.

In this team, getting upfront time is harder because your stakeholders often don’t understand why or how that helps them or the company. It’s the responsibility of engineering leadership to make that value clear. Business stakeholders are generally skilled at cost-benefit trade-off analysis, so once you have succeeded in communicating the benefits and how your idea will help the business, they’re much more likely to support you in paying those upfront costs.

In Table 5-1 you’ll see an outline of how to gain support in a Business/Product lead team.

The Engineering-First, Technically Driven Team

This team is often found at companies who sell technology as their product, where what to work on is decided by the engineering team or by technically focused product or executive leadership.

If you have a team of engineers who generally work in a highly autonomous way and are able to easily undertake research explorations, or if your overall objectives and outcomes are usually determined within engineering, then the technically focused approach might work best for you. Vendor companies, who sell technology mostly to other engineering teams, come to mind as engineering-first.

The engineering-first team is unlikely to see as much value in lining up product and technical roadmaps, because in this team, the technical roadmap is the one that matters. In this case, your approach should focus on your engineering team or technical leadership, and we recommend you emphasize the technical benefits of an atomic migration in the long run. Atomic migration allows you to maintain a steady pace of development even as teams grow and the codebase becomes more complex because you’re building out of simple, tested components. The developer experience is also important to emphasize here—people can work with whatever technology enables the most productive environment (right now, this is React with Storybook). 

Emphasizing engineering autonomy and the ability for experimentation and innovation will be important, too. In this kind of team, your ability to stay on the cutting edge of technology and not constantly battle with outdated frameworks and piles of technical debt might be an important business need.

The main obstacle you’d face in this team is a lot of opinions on how to do things that could make it more difficult to create and implement a migration plan. For this kind of team, we recommend putting together some example repository and showing these benefits to your team early, walking them through the setup.

If your company does demos, “lunch and learn” talks or something similar, this is a good opportunity to gain broad support from engineers by showing them exactly how atomic design can benefit them. This approach will allow you to gain support, and by showing concrete examples that work, hopefully somewhat limit the scope of discussions and keep the team focused.

In Table 5-2, you’ll see an outline of how to gain support in an engineering-driven team.

The Engineering/Product Partnership Team

If your engineering team works in close collaboration with a product or business team and neither team solely defines requirements, then you probably have a engineering/product partnership. Many consumer-facing Software-as-a-Service (SaaS) companies follow this structure. If you have a partnership setup, you’d usually decide what to do in some kind of consensual process. Agile is a popular team-planning process for partnership teams, because decisions incorporate both sets of needs.

In this kind of team, the biggest challenge is getting the support to do what sounds like a major innovation from both engineering and product. Teams structured as partnerships often have efficient processes optimized for under one-month-long work cycles, and might not have a framework in which to think about projects on a longer timeline.

Here you face the same challenge as with the product-led team of making the benefits of the migration clear enough that product leaders are able to understand them. Otherwise, they will see only costs and rationally will not be in support of your plan! You also face the challenge of getting buy-in from engineering on the plan itself.

We recommend a two-pronged approach here. If you have an experienced engineer or a small team that doesn’t work regularly on product, then leverage this ability to do a “proof-of-concept” migration and lay the foundations. Doing this will greatly reduce the costs of a migration to your product team because the groundwork will be done. It will also give you a prototype to demonstrate the benefits of atomic design to engineers. That’s powerful because you can show people specific solutions that already partially solve pain points your team has, rather than talk about abstract ideas. This is where your trailblazer is key.

While your trailblazer is laying the foundations, it’s a good time to start having conversations with the product team outlining what your pain points are and how solving these will benefit both the engineers and the product. It’s very hard to convince people who are in an “if it ain’t broke, don’t fix it” mindset that you need to fix something. Your challenge here is first helping people understand what’s broken. Only once your product team is telling you about what your problems are is there enough of a shared understanding to start talking about the solution. In a partnership, it’s critical that the product team sees the same problems that the engineering team is seeing before you solve anything.

Once the product team understands the current environment’s challenges, outline the benefits of an atomic migration. The benefits to both teams are that building complex systems out of simple, reusable parts allows you to build faster and build to a higher quality standard. Code reuse also increases the predictability of engineering estimations because there are fewer unknowns compared to building from scratch. This is a major benefit in partnerships using agile processes like Scrum, where estimation is an important part of working together.

In a conventional team, the default is to slow down over time as complexity expands exponentially. Atomic design (done well) allows teams to speed up over time instead as their library of reusable parts grows and complexity is limited to specific parts. Engineers don’t need as long to build the context of the full application in order to work successfully on just one part. This allows a long-run sustainable productivity level for engineers.

Finally, a benefit that’s especially important to emphasize with a partnership team is how atomic design is a fundamentally product-orientated engineering approach. With atomic design, product needs determine what will get migrated when, and the product roadmap drives the migration. Rewrites can be challenging to a partnership because the synchronous approach (stop and rewrite) creates a fundamental divide between the product goals to deliver to customers, and the engineering team’s technical goals.

An asynchronous rewrite unites product and engineering in a shared goal with one unified roadmap. Once you’re past laying the foundation, building with components doesn’t need any special development methodology and can be done in an agile way following much the same format as how your team is coding today. Table 5-3 outlines how to gain support in an engineering-product partnership.

At this point, you should be all set up to successfully undertake a migration with atomic design, and have a clear idea of how to structure your team and build a compelling business case to gain the support of your stakeholders. As with any major technical undertaking, planning and preparation is key, and building support for your plans is vital in preventing them from getting derailed. We hope these points will help you with the organizational and practical challenges of making your plans a reality!