In the DTC landscape, where every pixel of your e-commerce site holds the potential to captivate customers and drive sales, the significance of a robust design system cannot be overstated. It's not just a luxury anymore—it's a necessity.

A design system comprises patterns and methodologies that assist not only designers and developers but also product managers and marketers in creating cohesive and user-friendly digital products. While various models exist, most encompass a pattern library, design tokens, brand and style guidelines, along with documentation detailing the system's usage.

At its core, a design system is the backbone of your brand's digital identity, ensuring that as your e-commerce business scales, every page, button, and interaction maintains a consistent brand image and delivers an optimized user experience.

But diving into the world of design systems can often leave brands navigating a maze of challenges, especially under the relentless pressure to rapidly deliver fresh, compelling landing pages and new features. That's where the magic of design systems truly shines—by providing a reservoir of pre-built components and guidelines, they turbocharge the creation process, allowing your team to keep pace with demand without sacrificing quality.

Explore the power of design systems to transform your digital journey and drive success in the competitive e-commerce landscape.

## How Design Systems Accelerate Time to Market

In a traditional scenario, the journey of redesigning product pages begins with designers crafting prototypes. These prototypes then undergo a series of checks: stakeholders review, QA stages with engineers, validation by UX researchers, and eventual exposure to a segment of the site’s visitors for performance evaluation through A/B testing. Multiple design iterations are crafted and assessed, with many discarded in pursuit of the optimal solution. This iterative process is vital to ensure only the highest quality updates reach the entire customer base. Yet, the involvement of various teams and multiple revisions makes it inherently time-intensive.

However, with the aid of a design system, the approach is streamlined to fewer phases, significantly accelerating the design-to-production timeline. Tools like [Figma](https://www.figma.com/) provide a collaborative environment where designers can rapidly prototype by pulling pre-defined components and patterns into their workspace, cutting down prototype creation from days to hours.

But the efficiency doesn't end there. Developers can swiftly compile new features by accessing the same pool of components, bypassing the need for detailed visual direction for every interface. Tools like [Storybook](https://storybook.js.org/) become invaluable in this context, enabling the isolation and coding of UI elements for seamless integration. This streamlined workflow ensures that projects progress swiftly from ideation to implementation, allowing teams to deliver high-quality updates in a fraction of the time.

## Implementing a Design System: First Steps for E-Commerce Brands

> A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem. — Nathan Curtis

The journey towards a comprehensive system that aligns with [Nathan Curtis](https://medium.com/@nathanacurtis)'s vision—a "*living, funded product with a roadmap & backlog, serving an ecosystem*"—might feel overwhelming. Yet, the truth is, embarking on this path doesn't require an army. It's about smartly leveraging what you have and starting somewhere meaningful. Let's explore practical steps to initiate and nurture a design system with your current resources.

- **Conduct a Design Audit**: Begin by taking stock of your current design elements across all digital assets. This includes colors, fonts, button styles, and any reusable components. The goal here is to identify inconsistencies and opportunities for standardization. A comprehensive audit paves the way for a more cohesive digital presence. [FigJam](https://www.figma.com/figjam/) is a great tool to kickstart this first step and to keep all the screenshots accessible to everyone on the team.


- **Assemble a Cross-Functional Team**: This doesn't mean hiring new roles but individuating people across existing departments who will be responsible for creating and maintaining the design system. Even a small team, comprising a designer, a developer, and a product manager, can kickstart the process. Their diverse perspectives will shape the design system to be both usable and technically feasible.


- **Create Design Tokens and Components**: Start by standardizing the most frequently used elements. Design tokens are the building blocks (like colors, typography, and spacing) while components are reusable UI elements (such as buttons, and input fields). Focusing on these foundational elements is essential to pave the way for creating patterns (components that come in a specific combination).

- **Set Up Documentation**: Initially, your documentation could be as straightforward as a shared online document or a simple internal wiki. Maintaining the same structure (tokens, components, patterns) and vocabulary of your design system is the key to fostering accessibility and clarity.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/0202c0d7fe5620978d813c8a6d989a41ec7084e5-1600x1052.jpg?fit=clip" alt="Cometeer design system by Nebulab">
</figure>

Remember, the essence of a design system is to foster efficiency, consistency, and innovation across your online store. Starting small and scaling thoughtfully can lead to significant long-term benefits, setting a strong foundation for growth and adaptation.

## Overcoming Obstacles to Adoption

Introducing a design system might initially meet with skepticism from your teams. Overcoming this involves embracing a culture of collaboration and shared ownership. As discussed in [Boost Your eCommerce Team’s Productivity with Open Design](https://nebulab.com/blog/the-open-design-process), developing an open design process is essential for fostering broader adoption of the design system throughout the organization.

Demonstrating the design system's value through small, visible projects that improve the e-commerce experience—such as improving the navigation bar or updating product grids for holiday sales—showcases the practical benefits. These successes not only build confidence in the system but also serve to highlight its effectiveness in real-world applications.

Organize hands-on sessions where stakeholders from different teams—be it design, development, or even marketing—redesign an e-commerce product page or streamline the checkout flow using the design system components. This is a great opportunity to turn skeptics into advocates (and they can have fun doing it, too!).

> A design system’s value is realized when products ship features using parts from the system.
> 
> — Nathan Curtis

## Tips on Scaling Design Systems

As your e-commerce brand navigates through various stages of growth, the need for your design system to adapt and scale becomes increasingly apparent. A scalable design system not only ensures consistency across your digital presence but also facilitates a more collaborative and efficient workflow as your team expands and your product offerings diversify.

Here are some practical tips on achieving just that, ensuring your design system remains a thriving, integral part of your brand's evolution:

- **Foster Shared Language**: In a design system, a "primary button" component is defined with specific attributes such as size, color, and behavior. This terminology is consistently used by both designers (on Figma) and developers (on the code), ensuring seamless communication and alignment throughout the project.

- **Prioritize Regular Reviews**: Schedule frequent review sessions dedicated to assessing and updating the design system. These reviews are opportunities to adapt to new brand needs, incorporate feedback, and integrate emerging design and tech trends.

- **Encourage Contribution**: Organize workshops to make the design system a collaborative project where team members can contribute ideas, feedback, and improvements. This not only keeps the system dynamic but also fosters a sense of ownership among the team.

- **Document Religiously**: Keep comprehensive and up-to-date documentation of the design system. The documentation can be on Figma, a separate document, or a tool. It can even be a website, it depends on project dimensions. With [Shopify Polaris](https://polaris.shopify.com/), Shopify provides clear and accessible documentation to streamline the design and development process for Shopify merchants and partners.

Implementing these strategies can help your design system remain a vital, evolving asset that supports your brand's growth and adapts to its changing needs.

## Design Systems: The Blueprint for E-Commerce Excellence

In wrapping up our journey through the landscape of design systems, e-commerce brands must grasp just how vital these frameworks are. At the heart of it, design systems foster higher quality products and markedly enhance the user experience. One of the standout benefits is scalability. As your brand grows and your digital footprint expands, a design system ensures that scaling up doesn't mean starting from scratch every time. This seamless scalability goes hand in hand with maintaining brand consistency—vital for cultivating brand recognition and trust among your audience.

Moreover, design systems contribute to better website performance. By eliminating repetitive components and streamlining the design-to-development process, websites become leaner and more efficient. With a design system in place, accessibility is not the only built-in standard; for brands eyeing the global market, having a design system is a strategic step for embedding localization best practices right into each pattern, ensuring that your brand resonates with diverse cultural sensibilities —as we explained in [Expanding Your Brand Globally With Cross-Cultural Design](https://nebulab.com/blog/cross-cultural-ecommerce-design).

Embracing a design system isn't merely an operational upgrade; it's a commitment to elevating your brand's digital presence, ensuring that every interaction your customer has with your brand online is as intuitive, engaging, and memorable as possible. As you consider the next steps for your online store, remember that a design system offers more than just a collection of components. It's a pathway to crafting experiences that truly resonate, setting your brand apart in the competitive digital marketplace.

Why E-Commerce Brands Should Have a Design System

Have you ever found yourself pondering over a complex problem for hours or days? You explore all possible paths yet end up with more doubts than certainty. Then, a casual conversation with a colleague suddenly illuminates your thoughts. Just articulating your challenge out loud, especially in a trusted circle, opens your mind and allows your ideas to blossom.

Imagine having a format to refer to every time you are stuck on a problem–a structured approach that unblocks the flow of ideas and brings order to chaos. A workshop is precisely that: a repeatable process to create an environment where conversation flows, ideas flourish, and solutions are nailed down.

At Nebulab, we use workshops to help our teams and clients navigate complex business domains, design efficient middleware integrations, and tackle multi-faceted productivity and collaboration challenges. Over the years, the humble workshop has proven, time and again, one of the most effective ways of taming complexity.

In this post, we’ll explore the practices we adopt for running workshops that bring value to both organizers and attendees.

## The Key Ingredients of a Good Workshop

If you’ve watched movies like A Beautiful Mind or the recently released Oppenheimer, you might be familiar with the process mathematicians use to dig into a problem. They gather in front of a whiteboard, and for the most part, they sketch formulas and diagrams rather than relying on verbal communication. They alternate themselves in the writing, pause, take a step back to glimpse what they produced, and question their thoughts with “what if” questions. 

It might not be evident at first glance, but these whiteboard conversations have a lot in common with workshops:

* The participants are exploring a complex domain
* The rules of engagement are well-understood
* The physical environment has the proper setup
* The participants visualize their concepts

All these elements are integral to a successful workshop, all concurring to create a space where ideas can be developed and examined collaboratively.

Let’s take a look at each of them, one at a time.

### Complexity and Collective Intelligence

The heart of a workshop lies in the rich interaction between participants.

This interactive environment is particularly effective when tackling complex problems characterized by uncertainty or requiring diverse expertise. Participants from different areas of the business (e.g., industry experts, e-commerce managers, and tech leaders) bring a range of diverse insights that rarely have a chance to converge.

In a workshop, we leverage the group's collective intelligence, which often leads to superior decision-making, problem-solving, and innovation than an individual could achieve by themselves. This is particularly true in scenarios where the complexity of the subject matter benefits from a multitude of perspectives.

Each aspect of a workshop–from its physical setup to the methods of visualization and facilitation– is designed to harness this collective wisdom to navigate and illuminate complex issues.

### Rules of Engagement

A simple, clearly understood set of rules is essential to facilitate efficient interaction and meaningful conversation in a workshop.

We can’t just put people in a room and expect valuable outcomes to emerge. Every workshop has a format and rules; for mathematicians, the format is mathematical symbolism, and the rule is to alternate in front of the whiteboard until a satisfactory outcome is achieved.

It’s critical to keep things simple: the participants need to be focused on exploring the problem domain, not on remembering or feeling constrained by the rules.

For instance, in a workshop I recently facilitated, we started with two rules: blue sticky notes to indicate a system and yellow sticky notes for activity in a system or data exchanged by two systems. In the second half of the workshop, I introduced a third rule: red sticky notes to highlight the critical/challenging aspects of a system’s behavior. With such a simple set of rules, all participants had an easy time contributing, the workshop ran all day with little effort, and the outcomes were excellent.

Pro tip: progressively revealing the rules is a trick that helps attendees focus on the matter at hand and ensures they aren’t overwhelmed.

### Physical Environment

An often overlooked but crucial aspect of workshops is the room setup.

Adequate space is necessary for participants to move freely, interact with each other, and engage with tools like boards or flipcharts. Think of the mathematician with unobstructed access to their whiteboard–this accessibility is critical.

In my experience, it's beneficial to rearrange the furniture to suit the workshop's needs. Typically, I align chairs along the room's perimeter, creating a central, open area in front of the board or designated workspace. This layout encourages movement, collaboration, and a focus on the current task.

Remember: the ideal setup can vary depending on the nature and size of the workshop. The goal is to create an environment that fosters active participation and easy access to your collaboration tools.

### The Power of Visualization

Relying exclusively on verbal communication often limits us to our existing mental models, creating a clash where new, breakthrough ideas struggle to emerge. This is because it's easier to interpret what we hear within our existing frameworks than to challenge and change them. 

Visualization offers a powerful solution to this limitation.

Going back to our example, mathematical symbols serve as the visualization tool. For a diverse workshop audience, simpler tools are often more effective: these can be post-its, diagrams, or even Lego bricks. Visualizing concepts on a wall is particularly impactful: it not only allows workshop participants to step back and see the 'big picture,' but also ensures that all participants can engage and contribute equally.

This method ties in with our earlier discussion on room setup (an open space in front of a wall facilitates this kind of visualization) and with the idea of a simple ruleset (guiding participants on how to contribute visually is vital).

## The Role of the Facilitator

In our example, a group of mathematicians might naturally fall into a collaborative rhythm without a facilitator. However, in a larger group setting, especially with individuals who have strong perspectives and diverse backgrounds, having a facilitator becomes essential.

A facilitator isn’t required to be a domain expert. Instead, their skills lie in observing group dynamics, actively engaging participants, offering suggestions discreetly, and summarizing discussions. The facilitator must be able to identify and guide the group’s focus to emerging concepts, even when they don’t have an in-depth understanding of the workshop’s subject.

Facilitators are crucial in navigating the complexities of group interactions, which can be unpredictable and challenging.

A note of caution to facilitators: not every workshop goes as planned, hence flexibility is key. Much like a jazz musician improvising in a jam session, a facilitator must read the room and adjust the workshop's flow as needed.

A good facilitator can transform a potentially chaotic discussion into a harmonious and productive session.

## How We Use Workshops at Nebulab

Across various industries, workshops are versatile tools that can be tailored to various needs. From Retrospectives and User Story Mapping in Agile teams to Event Storming for Domain-Driven Design architectures, their applications are manifold.

As an e-commerce agency, we find workshops particularly effective in two main areas. Hopefully, you can use these examples as inspiration for your own workshops.

### E-Commerce Middleware Design

Firstly, as detailed in [my previous blog post,](https://nebulab.com/blog/ecommerce-middleware) we use workshops to explore connections and dependencies between systems when architecting middleware software.

This workshop format is inspired by [Event Storming](https://www.eventstorming.com/), and it’s best described as a form of generative business process mapping: treating the wall as a timeline, we use sticky notes to represent the systems we are discussing (e.g., the e-commerce platform or the ERP software), the activities performed by the user or system, and events those activities generate.

Aligning the sticky notes on a timeline gives us a general overview of the business process and the system’s relationships. It also allows us to rearrange the responsibilities and dependencies between systems and the middleware.

On the brand side, we typically invite any stakeholders with an active role in the systems we’re analyzing. On the Nebulab side, we have a workshop facilitator, one or more strategists to provide insights into the business domain, and technologists to provide insights into the system’s architecture.

### E-Commerce Domain Mapping

Workshops are also invaluable when implementing complex business rules or requirements deeply rooted in a brand's unique domain.

In this case, we start by representing the different types of actors involved in the domain, then the names of the business rules, and then the logic behind each rule. Finally, we arrange everything as a tree. Focusing on the users and visually representing the conditions and constraints applied to the system helps us untangle complex business domains and spot corner cases that were not previously covered.

The value of these workshops lies in their ability to bring together people with diverse expertise–from those with deep business or process knowledge to technology experts who may not be as familiar with the brand's specific domain. This diversity is crucial for surfacing and clarifying assumptions, removing ambiguity, and fostering mutual understanding.

An additional benefit is the reorientation towards the “bigger picture.” It's common for individuals immersed in day-to-day tasks to lose sight of the organization’s broader objectives. These workshops serve as a vital tool to realign everyone’s focus on the overarching goals, ensuring a cohesive and comprehensive approach to problem-solving.

## Don’t Be Afraid To Experiment!

If you are tackling a gnarly issue or trying to untangle a business problem, a workshop might be the answer you’re looking for. While they seem intimidating at first, the benefits of an effective workshop far outweigh the complexities–just follow the rules we’ve outlined, and you’ll be halfway through!

Of course, if you’re an e-commerce brand and would like some help from experienced facilitators who can challenge your assumptions and contribute with their own insights, [feel free to reach out!](https://nebulab.com/contact-us) We’re always down for a good workshop.


Using Workshops to Navigate Complexity and Build Alignment

Here’s a story you might have heard before: a brand has a dedicated design team, handling everything from packaging to ad creative to Web design. The design team works closely with the brand’s executive team, constantly asking for feedback and creative direction. Because designers work so closely with the executives, there’s no need to prioritize projects: people can just talk to each other and “figure it out.”

Then, as the brand starts scaling their Web development efforts, all hell breaks loose.

The brand’s development team starts complaining that the mockups they get from the designers are useless: they’re incomplete, contain visual bugs or inconsistencies, neglect to cover obvious error cases… the list goes on and on. On their side, the designers complain that the developers have no consideration for their work and constantly introduce discrepancies between the original mockups and the final implementation. In all of this, the executive team doesn’t know where the problem lies or how to fix it.

If this sounds familiar, it’s because it happens at least once, in some shape or form, to most e-commerce brands that invest a decent amount of time into their DTC store, not to mention brands that have mobile apps or other digital properties.

In the past, I faced this conundrum several times as I designed brand identities and digital experiences for brands across different sizes and industries. **When designers and developers don’t work well together, it slows down everyone’s work and kills team morale.** It’s the kind of technical problem that has a very tangible impact on a brand’s bottom line.

Luckily, there’s a better way to work. It’s an approach I found through a lot of trial and error, and I’m delighted to share it with you today. Through open communication and clear guidelines, you can create peace of mind for executives, designers, and developers peace of mind, increasing the velocity, scale, and quality of your digital team’s output.

Let’s see how exactly!

## The Myth of the Perfect Design Handoff

When I first tried to bridge the gap between designers and developers, I did what every detail-oriented person would do when tasked with a sufficiently complex problem: create a process. My thesis at the time was that if I _just_ included enough detail in my designs to remove even the smallest amount of guesswork, developers could just translate my mockups into code one pixel at a time, and we’d all live happily ever after.

So, I started doing just that: rather than treating every project as unique, I created a thorough process for prioritizing, executing, and delivering my designs. This included elements like annotations in the designs that clearly explained what the UI was supposed to do and in what way, error states, and even Loom recordings of me going through each screen in the flow and explaining it verbally. Every time a developer had a question that I forgot to cover, I made a note and refined my template, all in pursuit of The Perfect Design Handoff™.

![](https://cdn.sanity.io/images/kqgmf0g2/production/df5a6ddad1bd6e9696f714c4c736b42d249ddf0b-1600x1052.jpg?fit=clip)

There was only one problem with this process: **it didn’t work.**

It’s not that it didn’t help: being more detailed in my handoffs made life a bit easier for our development team–at the very least, we now all agreed on the bare minimum that should be included with every new user flow.

However, it didn’t really _solve_ the problem: no matter how detailed my annotations or how long my Looms were, developers still had questions about edge cases I forgot to cover, new components that needed to be implemented, and interactions between different user flows that I couldn’t possibly have foreseen.

Furthermore, after seeing the implemented designs, product managers often provided feedback that required design changes, forcing designers and developers to redo their work. With such a detailed handoff process, this required a lot of time and slowed down delivery.

I knew we needed to try something else, so I went back to the drawing board.

## The Only Path To Order Is Chaos

After deep thought, I realized I was trying to solve the wrong problem: my theory was that designers could single-handedly collect stakeholder requirements, work on them for a week or two, and turn them into pixel-perfect mockups that contained all the information developers needed for implementation. Developers would then use that information to implement a user flow that matched the mockup pixel by pixel.

That sounds very nice in theory, but it’s virtually impossible: product managers, designers, and developers approach projects from different angles and bring different perspectives. **These three stakeholders need to collaborate constantly and provide continuous feedback on each other’s work**–only then will the final product really satisfy their needs, not to mention the needs of the brand’s customers.

With this new collaborative spirit in mind, I worked with our product and development team to completely rearchitect how we delivered new features to our customers. Rather than aiming for the perfect handoff from stakeholders to designers and from designers to developers, we started investing much more heavily in open and constant communication:

* **We established a series of recurring calls** where every member of the team would present what we were working on, no matter whether it was a product requirements document, an initial mockup for a new feature, or a code-complete user flow.
* **We encouraged everyone to offer feedback** at any point in the process and worked hard to foster a sense of psychological safety on the team, so that no one would feel like their work was “under attack.”
* **We asked team members to coach each other** on their respective areas of expertise. Designers showed developers the basics of working with Figma, while developers taught designers about their implementation process.

![](https://cdn.sanity.io/images/kqgmf0g2/production/f69a781f488e3cadaa00f1737c1e7c8143eb6898-1600x1052.jpg?fit=clip)

We kept a light process in place to create consistency in how we worked together, but also empowered everyone on the team to contribute cross-functionally. This led to several situations in which a developer provided insightful feedback on how to handle an edge case, a product leader realized that a flow didn’t feel as smooth in the real world as it did in the mockups, or a designer spotted a visual bug while testing a developer’s work.

Most importantly, **it created a sensitivity and deep appreciation for the work done by our fellow team members**, making us better at our respective jobs: designers understood the importance of component-based design, developers became more mindful of visual discrepancies, and product leaders understood that design and implementation are never going to match perfectly.

The new process didn’t fix all our problems, but it did give us the tools we needed to address them together! **Internally, we called this approach Open Design.**


## Adopting Open Design for Your Brand

As I mentioned in the introduction, it’s not uncommon for an e-commerce brand to be stuck in a sense of constant chaos and urgency or to feel constrained by an overly structured handoff process.

The root cause of the problem often lies in the fact that brand founders are very visual people, and most of their design experience lies in branding, packaging, and product design. As a result, they approach design very rigidly and try to make everything perfect before it’s handed off to their development team for implementation. This approach then cascades to the rest of the team as the company grows.

Unfortunately, the same can be said for agencies: many e-commerce agencies are design-driven and treat development as an afterthought. This leads to a lot of friction in their internal workflows or how they collaborate with their clients or other agencies.

As much as we would like to give you detailed, step-by-step instructions for how you can break out of this jail and implement an open design process for your brand, there’s only one thing you need: **people who are willing and able to set their egos aside and work together.**

As a first step, we always recommend creating stable, recurring ceremonies for cross-functional team members to talk to each other and exchange feedback. We found that **once you establish that baseline for collaboration, people will re-orient themselves around the new way of doing things, and everything else will magically fall into place.**

But if you need any help adjusting your process or are looking for an agency that lives and breathes Open Design, [feel free to reach out](https://nebulab.com/contact-us)–we’d love to help!

Boost Your eCommerce Team’s Productivity with Open Design

Here at Nebulab, we’re privileged to work with tens of brands across different categories, business models, team compositions, and revenue stages, helping them shape, launch, and refine their eCommerce experiences. Some of these brands started with us, while others used to work with different agencies and told us about their experience.

While every agency has its own culture and way of doing things, we’ve identified a few traits that separate successful brand-agency collaborations from the rest. These are not defined processes, but rather a philosophy for working together.

In today’s article, we have distilled this philosophy into five fundamental principles. When implemented, we’ve found that these principles consistently lead to dramatic increases in agency productivity and effectiveness.

If you already have an agency and would like to take your collaboration to the next level, or are looking for an agency and unsure how to evaluate their work methodology, you should dive right in!


## 1. Promote Knowledge Sharing

Many executives provide context to their agency on an as-needed basis: burned by previous experiences or just strapped with time, they create a structure where communication only flows in one direction, and the agency only knows what they absolutely need to do their job.

While this might get you the short-term results you’re looking for, it also means you’re missing out on _a lot_ of value your agency could bring to the table.

Pretty much all eCommerce agencies are verticalized–that means they only work in the eCommerce industry. As a result, they accumulate valuable expertise about industry trends, baseline performance, and best practices, not to mention the networks that they often manage to build up over time.

**If your relationship with your agency resembles an assembly line, it’s very unlikely you will ever benefit from any of their organizational knowledge.**

Instead, aim to remove all communication and knowledge barriers between your team and your agency. Give them free access to your team, and expose them to as many ceremonies and artifacts as possible–all hands, cross-functional meetings, strategy documents, and anything else that might be useful.

Once you do that, you’ll be surprised at all the different ways your agency can help you.

**Recommended read:** [Sense and Respond](https://www.amazon.com/Sense-Respond-Successful-Organizations-Continuously/dp/1633691888/ref=tmm_hrd_swatch_0?_encoding=UTF8&qid=1693399466&sr=8-4)


## 2. Demand Extreme Ownership

Here’s a controversial take: dedicated QA teams are a waste of time and money–at least in the way most brands structure them. If everything your agency does needs to pass a QA check, you’re doing it wrong.

This doesn’t just apply to QA but to any other areas where your agency needs “gatekeepers” or handholding. Instead, **you should aim for a structure where your eCommerce agency is responsible for all stages of execution:**

* Your agency should be responsible for contributing–as much as possible–to the product roadmap, based on their knowledge of your brand.
* Your agency should be responsible for refining your requirements and uncovering edge cases, problems, and needs you might have missed.
* Your agency should be responsible for QA’ing their own work, releasing it, and ensuring it’s working as expected once it’s live.
* Your agency should be responsible for proactively diagnosing and fixing the problem when something goes sideways—as it inevitably will.

If you’re reading this list and thinking, “My agency would never be able to do that,” there’s a fundamental lack of trust that you need to resolve. Perhaps they don’t have the skillset, or you tried giving them more freedom, and they failed. Talk to them openly about what you’re trying to achieve and see if the situation improves.

**Recommended read:** [Turn The Ship Around](https://www.amazon.com/Turn-Ship-Around-Building-Breaking/dp/0241250943/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1693407060&sr=8-1)


## 3. Think in Products, Not in Projects

A structured product management practice is what separates the brands that aimlessly wander from project to project and the brands that are intentionally pursuing a business strategy with their eCommerce website.

Unfortunately, many brands confuse _product_ management–the practice of collecting and leveraging quantitative and qualitative data to inform your product roadmap–with _project_ management–the practice of establishing and following a structured process in the execution of said product roadmap. Let's put it this way:

* Doing product management without project management means moving chaotically in the *right* direction.
* Doing project management without product management means moving meticulously in the *wrong* direction.

A good place to start is how you frame problems and validate solutions: **rather than just writing down business requirements, use quantitative and qualitative data to explain the business need driving a particular initiative.** Then, once a solution is implemented, use data to validate the impact of the solution.

Obviously, there’s much more to product management than just leveraging data: a good product manager is a master storyteller and can craft compelling narratives for why your brand should head in a particular direction, collaborating with different stakeholders and rallying your whole team behind a shared vision.

In the past, we have written extensively about the value of product management and how to establish a product management practice in your eCommerce team, so feel free to check out our previous articles [here](https://nebulab.com/blog/ecommerce-product-management) and [here](https://nebulab.com/blog/product-led-ecommerce-growth).

**Recommended read:** [Escaping the Build Trap](https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X/ref=sr_1_1?keywords=escaping+the+build+trap&qid=1693410820&sprefix=escaping+the+build+trap%2Caps%2C212&sr=8-1)


## 4. Improve Continuously and Systemically

You and your eCommerce agency should be on a path of continuous, systemic improvement of your baseline performance. Rather than shooting for the stars only when the situation requires it and then falling back down to your usual standards, **you should constantly reassess your work together to understand how to take things to the next level.**

If you’re unsure how to do this effectively, try running a retrospective. In a retrospective, all team members can bring and discuss their feedback in a blame-free environment, with the only goal of improving the team’s performance. Retrospectives are most often used by software development teams, but they are a generic tool that can be applied to pretty much any business scenario.

Retrospectives allow you to improve continuously, but you should also ensure you’re improving systemically. By that, we mean that you should strive to maximize the impact of any work you do by considering how the work will affect different areas of your business, now and in the future.

A prime example that we like to use is building a design system for your brand. A design system will allow you to dramatically increase your iteration speed in the long term: you’ll be able to build more in a shorter timespan and reduce the amount of decision-making needed during the design process.

Unfortunately, design systems never seem important in the short term: **you need to make a conscious effort and invest a bit of your time in your future needs**–in a way that’s compatible with your immediate goals, of course.

**Recommended read:** [The Goal](http://amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271951/ref=sr_1_1?crid=291LJ6ND5CVPB&keywords=the+goal&qid=1693411801&sprefix=the+goal%2Caps%2C305&sr=8-1)


## 5. Do What’s Right, Not What’s Popular

The relatively recent commoditization of eCommerce infrastructure is fantastic news for brands: you can now build rich eCommerce experiences with a fraction of the effort that was previously required. Sign up for any modern eCommerce platform, and the amount of functionality available out of the box is mind-boggling.

However, this comes with a side effect: **many brands have stopped thinking about how to properly align their [eCommerce stack](https://nebulab.com/blog/ecommerce-tech-stack) with what their business really needs.** Instead, they just pick whatever’s most popular and stick to that. Unfortunately, agencies are not immune to this pattern–especially those that lack experience or strong R&D capabilities.

The result is a sea of online stores that all look and act the same and a borderline irrational fear of doing anything that deviates from the status quo.

**Best practices should be considered a starting point that you can build upon, not an absolute constraint.** Whenever you’re making a choice, it is your agency’s responsibility to present all your options and then determine what resonates the most with your market, vision, and business requirements.

Don’t get us wrong: there _is_ a cost for deviating from the most traveled road, and you need to be able to quantify it. It all boils down to whether the additional benefits justify it.

**Recommended read:** [The Lean Startup](https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0670921602/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1693414149&sr=8-1)


## Change Is Hard, Not Impossible

As you’ve seen by now, none of the principles we’ve just outlined are quick wins–in fact, many of them require a significant mindset shift, and we can’t promise that they will deliver results overnight.

What we _can_ promise is that **this way of working is infinitely more powerful than more transactional agency relationships**, where you’re just paying money in exchange for pixels or code.

We’ve also seen first-hand that this kind of change can be implemented–you just need to be patient and accept that there will be slip-ups in the process. When they happen, treat them as your opportunity to practice continuous improvement!

5 Principles for Doing Great Work with Your eCommerce Agency

Let’s consider two engineering managers, John and Jane. They have the same seniority, they both work on similar projects in similar conditions and their teams are both terribly smart.

John insists on personally reviewing and approving every change, no matter how small. This doesn’t just concern the codebase: if an engineer wants to try a new productivity tool with the team, they have to go through John. If the team wants to move an internal meeting to a time that better suits everyone, she has to go through John. Every little detail is scrutinized and torn apart to make sure John’s team don’t waste their time on “useless” initiatives.

Jane, on the other hand, is more comfortable with experimenting. She doesn’t require the team to ask her approval for everything, but she is there to support them when they want to try something new, and helps them validate initiatives by setting clear goals and metrics that make sense for them. Then, she takes successful experiments and acts as the team’s champion in the larger organization, implementing these initiatives at a higher level.

Which team do you think will be happier, more productive and more innovative — John’s or Jane’s?

## Bottleneck Managers Create Permission-Centric Organizations

John is the typical example of a **Bottleneck Manager**. We all know at least a few Bottleneck Managers: they hoard information and authority and require teammates to go to them for every little thing. Want to try a new tool? Ask your manager. Want to move a meeting? Ask your manager. Want to change the name of a Slack channel? Ask your manager.

Put enough Bottleneck Managers together and you have an alienating workplace where there’s a process for everything and no way to change that process, until one day you realize you’ve just been doing the same thing for the past five years and you’ve become irrelevant two years ago anyway, but no one has told you because they were too busy writing code. You have, to put it briefly, a **Permission-Centric Organization**.

Permission-Centric Organizations are the natural result of one or more of the following factors:

* **Lack of trust**: his goes both ways. Managers may not trust their teams to make sensible decisions, or teams may not trust their managers to make good use of the results of their decision-making. If a teammate wants to try a new technology but knows their manager will scoff at it, they may not even propose it, to avoid the uncomfortable feeling of rejection.

* **Lack of time**: managers want to make sure everyone on their team is using their time in an optimal way. In doing so, they may overly centralize the decision-making process, to the point where the team is not free to do anything but write code. In some companies, managers will allocate all of the engineers’ time to “busywork”, leaving no room for anything else.

* **High cost of error**: if you have a proven process and battle-tested tools in place, it’s scary to try something new. Sure, the new tool/methodology may improve your work by an order of magnitude, but what if it doesn’t work and you end up alienating your stakeholders? The more successful you get, the more this becomes a problem.

* **Lack of competency**: when team members are not competent enough to experiment in a safe, productive way, management may create constraints around experimentation and take the reins of the engineering process. This may also come from the team members themselves: if they are not (or don’t feel like they are) competent enough, they may avoid trying new ideas for fear of making a mistake.

These are all valid problems. If you’re running a successful company, you want to make sure innovators are competent, you want to trust them and you want them to trust you, you want to dedicate time to the things that really matter, and you want to eliminate or minimize any room for mistake.

However, there’s a way to have your cake and eat it too. You can have all of the above, without hindering your team’s ability to come up with new ideas and validate them. The way to do it is to stop being a Bottleneck Manager and start being a **Multiplier Manager**.

## Multiplier Managers Create Feedback-Centric Organizations

Unlike John, Jane is a Multiplier Manager. A Multiplier Manager supports their team, but also allows them to make their own decisions. They’re proactive in identifying opportunities, but let the team capitalize on opportunities in their own way. They create processes and boundaries for safe innovation and encourage the team to pursue their ideas. They are — by far — the best kind of manager you’ll ever work with.

Multiplier Managers are the bread and butter of **Feedback-Centric Organizations**. These are workplaces where you can — and are strongly encouraged to — run an initiative by your manager to get feedback on it, without first having to ask permission. They are workplaces where ideas move freely from one desk to the other, in continuous evolution.

Just like a Bottleneck Manager and a Permission-Centric Organization are identified by a particular set of dysfunctions, Multiplier Managers and Feedback-Centric organizations exhibit and promote most (preferably all) of the following virtuous traits.

### Provide context about the business

Lack of transparency about the business context and business goals of their organization is one of the most common reasons why people don’t feel like they’re empowered to change their surroundings — withholding information may save your team some time, but it also prevents them from providing their perspective and putting their own twist to what you’re doing.

Multiplier Managers make sure to share all relevant information with their team. Not just what they’re doing, but why they’re doing it and whom they’re doing it for; any decisions that are made, and why they’re being made; who’s responsible for what; any processes the team follows and the rationale behind them, and anything else that might be of interest to other people.

Once the amount of information is too much to be pushed to all teammates all the time, they start publishing it instead and give their teammates an easy, clear way to access it, so that they don’t risk wasting the team’s time with anything they don’t find interesting. This may take different forms: a shared Google Doc, an entire shared folder, a company playbook, meeting recordings or a bunch of those — whatever works for the company and how people communicate.

## Define what “good” innovation looks like

This is where bureaucracy and innovation meet: the best approach to innovating is by doing it within clear constraints and with a streamlined process. Constraints give your team members a way to frame their ideas in a way that makes sense for everyone, and process lets them validate and execute their ideas in a controlled way.

Here’s the stuff that Multiplier Managers are concerned with:

* What kind of innovation is good innovation? Is it okay to propose rewriting a perfectly working project in a new, shinier technology? Is it completely forbidden, or should it just be a time-boxed endeavor?

* How do we determine if an idea is successful? Do we need to set clear business metrics in advance, or do we use more qualitative metrics? Does it depend on the context?

* What’s the process for collecting feedback? Even more important, what’s the process for understanding whom to collect feedback from in the first place? What kind of feedback should be asked for at what points during the process?
Your mileage may vary, but the mere act of creating a process will be beneficial to your team and make it known that not only is it okay to experiment, it’s encouraged and codified.

### Use automation to create safeguards

If your organization is run by humans, someone is bound to screw up at some point. While Bottleneck Managers run from mistakes and pretend everything can be perfect all the time, Multiplier Managers embrace chaos and try to minimize the ways in which things could go wrong, the cost of things going wrong, or both.

Multiplier Managers use automation to their advantage: they know that systems are dumb and infallible while people are smart and fallible. This leads them to give their team ample freedom to innovate and move quickly *without* having to ask permission. At the same time, they create automated safeguards around the critical aspects of the company’s infrastructure to protect them from human error.

The most obvious example of this is creating a CI pipeline and setting up the proper telemetry to ensure developers can iterate on the codebase as quickly as they can think, *without* running the risk of breaking the app with a bad deployment. Removing the human element from the approval process is key to boosting speed and creativity in the organization.

### Promote technical excellence and innovation

As you create more room for experimenting and taking ownership, you should also make sure you’re promoting technical excellence at all levels of the organization. Having the right skillset empowers individual contributors to spot and seize opportunities for improvement, and it empowers managers to recognize and support innovators.

Before you start firing people, though, make sure those “code monkeys” on your team are not monsters of your creation. Even the most proactive engineer in the world will stop coming up with new ideas when there’s no room for execution. Consider each team member’s history and their aspirations and, most importantly, *talk* to them about the kind of change you want to create to see how they react: are they excited, worried or indifferent?

If you’re trying to revive a stagnating team, a useful icebreaker may be to allocate time for intentional brainstorming and innovation. Try to put aside 20% or 10% of each iteration for the team to try their craziest ideas, and see how that pans out. This will give you time to get aligned on what innovation means to you, and how you want to go about it.

However, remember that this is still not ideal: “thinking time” is still you giving your team permission. Instead, you want to get to a point where they come to you spontaneously with their ideas, without waiting for you to tell them it’s okay to think. If you can get there and maintain that momentum, you’ll have a real Feedback-Centric Organization.

The Feedback-Centric Organization

Everyone keeps telling us to be gentle when reviewing Pull Requests, and that’s the right thing to do, but are we nice with who reviews ours?

A Pull Request is a way to communicate with other individuals who are responsible for the project’s maintenance, so we should do a good job improving our Pull Requests code and documentation to make their work straightforward. It’s also in our best interest to do that since the easier the review is the faster we’ll get our code merged.

## Who reads our Pull Requests?

Creating a reasonable Pull Request is a matter of walking in the shoes of people that will open it later, who fall into the following categories:

* **Code Owners**: who are in charge of reviewing and merging the code.

* **Developers implementing new features**: who are changing previously merged code and need to understand why that code is there.

* **Developers fixing bugs**: who encounter a bug and need to go deep in the git history to understand where the regression has been introduced and why.

We should be respectful of each of them while creating a Pull Request since facilitating their work both in the present and in the future is what makes software development honest and practical. “Time is running out” kind of excuses here are not valid, every moment that we don’t spend improving Pull Requests that we leave in our project is a lot of time wasted for who will interact with them later.

> A Pull Request is created one time but evaluated multiple times.

Do the math!

![](https://cdn.sanity.io/images/kqgmf0g2/production/61e451b8aa097487f4e8e20ab17f3ac713117f8c-560x240.gif?fit=clip)

## What reviewers dream to see

Let’s take a look together at what makes a Pull Request easy to review.

### Well organized code

Code is the soul of the Pull Request, but it won’t be my focus here. You can find a lot of resources about this on the Internet. I’ll only mention some general rules to apply code side:

* Make it small, try to break it into multiple Pull Requests.

* Write well-separated and well-documented commits, the why is the most important thing.

* Add tests, they’ll help reviewers understanding the context of the Pull Request.

* Take a look at the contribution guidelines usually at CONTRIBUTING.md; it may have important information.

### Meaningful title

It needs to clearly and exactly describe what has changed. For example:

![The preview of a wrong-formatter Pull-request title](https://cdn.sanity.io/images/kqgmf0g2/production/2c23d7ca307eba19629a23417b8c92525c59f42f-1340x200.png?fit=clip)
🔴 Bad: This one is too generic and doesn’t provide any value.

![The preview of a well-formatter Pull-request title](https://cdn.sanity.io/images/kqgmf0g2/production/e51f25dbd3166b9566efd0606c4f264866d63a64-1340x200.png?fit=clip)
✅ Good: This one is specific and explain what changed.

If you can only come up with a generic title, that’s probably a first signal that we could split the Pull Request into multiple ones.

A rule that I apply to determine if a title is good is to ask myself this:

> Could this title fit a CHANGELOG entry?

This soft-rule comes from my experience maintaining [Solidus](https://solidus.io/), the open-source project I mostly work on. On Solidus, before each release, we run a script that auto-generates entries for the CHANGELOG.md file using Pull Request’s titles. When they are self-explanatory, there’s much less manual work to do for maintainers.

### A description that really helps

Here’s the core of the Pull Request documentation. It’s quite common to assume that the Pull Request title and commits are enough for people to understand the context, but that’s not always true. For example, let’s consider this Pull Request title:

![](https://cdn.sanity.io/images/kqgmf0g2/production/2a55753537b7c1d02daf6a0746efd6d2e744bd47-1340x200.png?fit=clip)

I’m sure that when reading the Pull Request title today, with all the team focused on this specific change, everyone will immediately get what’s going on and **it could be tempting to leave the Pull Request’s description empty**. But what happens if you have to come back to this Pull Request in 1 year? Will you immediately remember how this switch has been done, and why?

Luckily, the “how” could still be read by commits description, even if it would be more time and energy-consuming to scan all the commits to get the sense of what’s happening. The real problem is that it’s tough to see the “why” of the change.

Let’s see what makes a good Pull Request description:

* It contains a **quick recap of the changes introduced**. It doesn’t have to be a lot of text, just something to quickly understand what changed without opening every single associated commit.

* It describes **why things changed**, try not to take for granted that the reader has a clear picture of the state of the system when the change happened. If the Pull Request comes from a change request done via an issues tracker, it could be handy to link that issue here.

* It describes the **steps to reproduce the changes introduced** with the Pull Request. It could be calling a method from a console, or make some interactions in a UI. It will drastically help reviewers to touch with hands the code they are seeing. It allows them to figure out any doubts that could arise in autonomy, without the need to ask for clarification and extra back and forth with the author.

* It includes **screenshots**: if the change has an impact on how the website looks or on any other visual part of the system, it’s a good idea to attach some screenshots. It will be super easy for those who look at the Pull Request to identify what changed and how.

With GitHub, you can guide the Pull Request author into providing all these things by using **Pull Request templates**. It’s a feature that allows to specify a template that will populate the Pull Request description for any new Pull Request. It’s just a matter of adding a markdown file into `.github/PULL_REQUEST_TEMPLATE.md`. Here’s a collection of [ready-to-grab Pull Request templates](https://github.com/stevemao/github-issue-templates) and the [GitHub documentation page for Pull Request Templates](https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository).

There’s also another hidden, not well-documented GitHub feature, that allows having multiple templates for Pull Requests. You can get them by just reflecting this filesystem structure:

```
.github/
  - PULL_REQUEST_TEMPLATE.md .       # The Default Template
  - PULL_REQUEST_TEMPLATE/extra.md   # Additional templates
```

When you create the Pull Request, you can use the infrastructure template by adding the `&template=extra.md` in the URL’s query params.

### The right reviewers

The policy about asking specific persons to review our code could change depending on the project. For this reason, GitHub offers a [Code Owners](https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners) functionality that allows us to specify rules that automatically trigger review-requests from the right people. Here’s an example of a CODEOWNERS file:

```
*                   @project/backend-team
/app/javascript/    @project/frontend-team
/docs/              @project/documentation-team
```

This will ask for a review to the `project/backend-team` for all changes in the project excluding those that are located in `app/javascript` and docs, which will ask for a review to their respective teams.

I suggest integrating the usage of this feature with a clear team policy on how much time and how often developers are expected to review others’ code.

## Preview App linked to each Pull Request

Reviewers’ work is way smoother when they can test what a Pull Request changes before merging, and it’s a good practice to have a preview environment, very similar to staging, generated for each Pull Request open.

If you are deploying on Heroku, you can just use their [Review Apps](https://devcenter.heroku.com/articles/github-integration-review-apps), whose setup is quite simple. It’s also possible to build something very similar by yourself: GitHub offers a Deployments API to create a Deployment section in the Pull Request page. By calling something like:

```
curl -X POST -H "Content-Type: application/json" \
-H "Accept: application/vnd.github.ant-man-preview+json" \
"https://api.github.com/repos/nebulab/project/deployments/42/statuses?access_token=XXX" \
-d '{ "state": "success", "environment_url": "https://your-custom-url/", "environment": "preview"'
```

You’ll see the deployment link in your Pull Request.

![The deployment button in GitHub](https://cdn.sanity.io/images/kqgmf0g2/production/bfe079861626b276e4e2cf4a47eb55f201bf93e7-1564x784.png?fit=clip)

At Nebulab, we use CircleCI and we’ve created a [CircleCI Orb](https://github.com/nebulab/circleci-orbs-feature-branch-preview) that allows us to have this functionality ready in minutes in all our projects by adding the following lines to the `.circleci/config.yml`:

```
version: 2.1

orbs:
  feature-branch: nebulab/feature-branch-preview

workflows:
  cool-workflow:
    jobs:
    - do-cool-things
    - run-specs
    - feature-branch/preview:
        domain: <domain-for-preview-apps>
        github_repo: <your-github-repository>
        github_token: <your-gh-auth-token>
        letsencrypt_email: <email-for-ssl-cert>
        server: <docker-server-to-run-containers>
        user: <docker-server-user>
```

### I bet you now want to be nice too!

After reading this post, you should! Being nice with reviewers gives you better and contextualized quality checks for your code, which should help you **grow as a developer**. It decreases **time-to-merge** for your code and will increases the **velocity to implement new features** that depend on existing ones. **Debugging is also faster** since you don’t have to read all the code to understand how and why a specific thing has been done. Helping reviewers means helping your team and your future self!

What Every Teammate Wants to See in Your Next Pull Request

During my career, I’ve had the honor of observing and being part of tens of engineering teams as a consultant, IC and manager.

Obviously, not all of these teams were equally effective at reaching their goals: some worked like perfect machines, others fell apart at every little problem, and most of them were somewhere in between these two extremes.

One would be tempted to explain these performance differences through a mere gap in technical skills — simply put, some people are more skilled than others and get more done, faster. The theory here is that the more highly-skilled engineers you hire, the better your team will perform.

This is certainly true, at least to an extent. However, if you talk to a seasoned manager, you’ll find that they’ve dealt with these two types of engineers at least once during their career:

* A junior engineer who absolutely crushed it not just from a technical perspective, but also in terms of the impact they had on the organization.

* A very senior and skilled engineer who never managed to accomplish anything meaningful, and ultimately moved on or had to be let go.

**Technical skill cannot always justify gaps in the performance of individuals or the teams they comprise**. There must be a more important underlying factor, one that justifies such dramatic differences in the impact people have on an organization, beyond their direct knowledge of the technologies and tools they work with. When present, this factor leads people to overcome their technical limitations in order to be effective at their job. When absent, it discourages them from pursuing meaningful results, no matter their skill.

Lately, I’ve come to realize the root factor may be **ownership**.

## An Intrinsic Trait with Extrinsic Results

Ownership is an intrinsic trait with extrinsic results: it’s born *inside* you, but most of the good things it leads to happen *outside* of you, in your interactions with others.

**Intrinsically, ownership is a sense of belonging and pride in one’s efforts that ultimately leads to the pursuit of excellence.** People who have ownership genuinely care about everything they do because they have the ability to see the value in it, even when it’s not obvious. Because of this love, they are willing to do the right thing.

**Extrinsically, ownership is the collection of traits that give managers peace of mind**: people who have ownership are dependable and consistent; they don’t wait for someone to assign work to them, but autonomously pick the thing that will have the most impact; they are in touch with the company’s mission; they work to the best of their abilities; they remove blockers from their way; they are not afraid to roll up their sleeves and fix something that’s broken, even when it’s not supposed to be their concern; they constantly re-evaluate and improve their way of working.

Most importantly, **ownership is contagious**, and it spreads very quickly: while technical skills take years or even decades to truly master, it only takes a few weeks of working in a team that consistently exhibits ownership for a new person to get up to speed on what’s expected of them. This is probably because we all have a natural sense of ownership and can recognize it and appreciate it in others when we see it.

## Ownership and Organization Design

In most mature organizations, there are at least three layers an individual is interacting with at any given time:

1. **The craft (the “how”).** When I am working, I am connected to the craft I am practicing to produce my work. An example is the relationship between an engineer and the code they write.

2. **The team (the “what”).** The code I write doesn’t exist in isolation (most likely), but is part of a larger endeavor my team is collectively working on. Together, we work on something bigger than ourselves.

3. **The company (the “why”).** Ideally, we don’t write code simply out of love for the code, but because we want to solve a problem we care about. Our company connects us all through its mission.

The three layers are also directly connected, and almost equivalent, to the three factors Daniel Pink identified in [Drive](https://www.amazon.com/Drive-Surprising-Truth-About-Motivates-ebook/dp/B004P1JDJO/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1587991379&sr=8-1):

* Ownership towards **the craft** corresponds to **Mastery**.

* Ownership towards **the team** corresponds to **Autonomy**.

* Ownership towards **the company** corresponds to **Purpose**.

In some organizations, ownership is experienced at all three layers: people love their craft, trust their team, and believe in their company. This perfect alignment creates the ideal environment for individuals to do their best work, and such an organization is bound to have an impact.

In other cases, there is a disconnection between these three layers. It’s important to note that, while the layers are connected to each other, the different levels of ownership people feel towards them may be completely independent of one another. Here are some examples:

* An organization whose members are deeply connected to the company’s mission, but completely uninterested in their craft.

* An organization that hires superstar employees by offering extremely generous compensation packages. In this case, employees will own their craft, but most likely not feel connected to the company.

* A dysfunctional organization that happens to have one or two very good teams in it. Their members are bound to feel a strong sense of ownership towards their team, but a very weak one towards their company (in extreme cases, people may favor their team while antagonizing their company).

Another important aspect is that the ways to foster ownership in these three layers are completely different. While ownership should be practiced first and foremost by the CEO, ultimately **it’s up to the individuals who comprise the organization to find the best ways to implement ownership in their work.**

Because the ways to foster ownership towards the company is largely independent of the type of company, and has been written about extensively already, and fostering ownership towards the craft is not something managers should be concerned with, let’s instead focus on how to foster ownership towards one’s team, especially in the context of an engineering organization.

## Ownership and Cycle Time in Engineering Teams

In a team setting, the biggest obstacle to team members’ ownership comes in the form of bottlenecks. Bottlenecks are steps of the work process that require team members to wait for someone before they are able to move forward with their work. **By removing responsibility from the person who is producing the work, they discourage that person from “owning” the work all the way to its completion.**

In the average engineering team, bottlenecks come in many different shapes:

* Software engineers need to wait for a PM to define the next sprint and assign work to them before they can start working.

* Software engineers need to wait for a QA engineer to test their work before their work is approved for deployment.

* Software engineers need to wait for a release manager to follow a very long and complicated checklist before their work gets deployed.

Every single bottleneck reduces the ownership individual team members feel towards their team: QA engineers find bugs in the features they test, but these bugs are never fixed and the work lingers in a limbo forever; engineers sit on their hands all day because they don’t know what they’re supposed to work on next. This results in a very tangible increase in cycle time.

Unfortunately, **engineering teams often don’t know a better way to do things**. In fact, many of them will argue that the bottlenecks are necessary: we need the engineers to have their priorities clear before they work, because the priorities change too quickly. We need to do manual QA on our system, because our system is too complex to rely on automated tests alone. We need to handle deployments with care, because the cost of a mistake is too high.

I would agree with all of these objections: there are products where the priorities would change dramatically from one day to the next, there are enterprise systems that are too complex for automated tests to catch all the permutations of interactions and edge cases that would cause a bug, and there are applications where the cost of a bad deployment can be computed by multiplying the minutes of downtime by a factor of one thousand or more.

And yet, I would never ever advise such teams to strip their engineers of their responsibility and ownership to protect the business — not because I think the sacrifice isn’t worth it, but because there is a better way. One that empowers teams and makes them more productive, resulting in more value for the organization and a better use of the engineering budget.

## A Practical Framework for Fostering Ownership

There are three activities paramount to building ownership in your team:

* **Communicate:** by communicating constantly with your team, you create alignment on the business priorities and expectations. Frequent and consistent communication gives your team the information they need to make decisions autonomously.

* **Streamline:** by streamlining processes, you empower everyone to follow them and make sure their work gets done. Note that streamlining doesn’t necessarily mean automating: while automating a process is the ultimate way to streamline it, proper documentation can also do wonders.

* **Trust:** ultimately, you need to trust your team to do the right thing. Most teams lack ownership because their managers don’t think their members can do the best interest of the organization without micromanagement. In the long-term, this lack of trust is a recipe for failure.

These three activities will take different shapes depending on the size and conformation of your team, but your end goal should always be to establish a framework for ownership and collaboration within the team. Everyone on your team should know not only what ownership means, but also how to exhibit it in their day-to-day work.

For example, here are some of the practices I have adopted over the years to foster ownership in the engineering teams I led:

* **Enforce direct communication:** when you’re a team lead, people have a tendency to go to you when they have a question, effectively turning you into a bottleneck and reducing their contact surface with the business. The next time someone approaches you with a question you can’t answer, encourage them to seek the answer by themselves. This may seem like you’re forfeiting responsibility, but what you’re actually doing is removing a bottleneck in the communication process.

* **Take “done” to the extreme:** most engineering teams don’t even have a definition of “done”, yet alone an extreme one. It should be clear that a feature is only finished once it’s been successfully deployed to production and used without problems by your users. Until then, the developer’s first priority should be to keep the feature moving through the development pipeline so that it gets done  — *actually* done.

* Turn **bottlenecks into leverage:** bottlenecks often come in the forms of individuals or teams who are responsible for keeping another team’s work moving forward. I’ve already made a couple of examples when I spoke about QA engineers and release managers. This kind of repetitive work alienates people and doesn’t add any value to your team — in fact, it slows them down. Instead, find ways to turn bottlenecks into leverage: the job of a QA engineer, for instance, should be to document QA processes and build tooling to automate them as much as possible. QA on individual features should be done by the engineer in charge of that feature.

* **Make ownership visual:** having a highly visual representation of the state of work can be extremely helpful in creating ownership. Most development teams work with Kanban boards, which are great for this sort of exercise: make sure your Kanban board actually has columns for every single step of your development process (e.g. don’t conflate code reviews with QA) and make it clear that it’s an engineer’s responsibility to keep things moving through that board at all costs. Also, make sure people give priority to things on the right (i.e. closer to get done) over things on the left. Having strict rules in place helps fight our tendency to start something new when we feel blocked on in-progress tasks.

* **Delegate decision-making:** nothing empowers people such as… their manager empowering them. Delegate decision-making as much as possible, even and especially when it feels a little uncomfortable. This doesn’t mean you should leave people to themselves: always be there for your engineers to talk a problem through, but give them the last word if possible. When someone has autonomy, they will honor that autonomy by exhibiting ownership.

As I said, your mileage may vary, but a good starting point is to try these practices in your team, keeping what works and adjusting what doesn’t. People will start taking ownership in ways that surprise you, identifying bottlenecks and creating original solutions to keep the process moving.

## Ownership Is a Gateway to Velocity

You have probably heard the term “velocity” before. A lot of articles talk about velocity and the difference between velocity and speed: while speed is just about how quickly you’re moving, velocity is also about *where you’re going*.

Many teams move crazy fast, but they often lack a clear direction. As a result, they do work that is not truly meaningful for the business, or they have to redo their work over and over again because of defects, incomplete implementations or missed requirements.

Once you and your team start exhibiting ownership, you will realize how connected ownership and velocity truly are: teams that own their work are teams that move both quickly and in the right direction. This connection exists for two reasons:

* **Ownership is first and foremost about doing the right thing.** Low-ownership environments discourage engineers from thinking about the business value behind their work, but high-ownership teams carefully consider each initiative and its impact from all possible angles. People will start doing things that really move the needle.

* **No one wants to own a half-done task.** Teams that don’t own their work often do the quickest thing that will allow them to cross an item off their list, whereas teams that exhibit high levels of ownership know that the work doesn’t stop when it’s in production: quick and dirty solutions mean more maintenance work down the line and less time for high-impact initiatives.

As you can see, creating a high-ownership environment is not just the best thing you can do for your team members, but it’s also the best thing you can do for your business: it will increase the volume, quality and business impact of the work produced by your engineering team.

For a lot of managers, it can feel scary to give away control so radically, once you have seen the results, you’ll never want to go back.

The Transformative Nature of Ownership in Engineering Orgs

These days code is a collaborative matter. Good developers are expected
to both write great code and help others write code. Code reviews play a crucial part in this: they're the main tool a team has to ship great code and have fun while doing so.

## 😤 Reviews are hard

First of all, let me say it loud and clear: doing code reviews is **damn hard**.
If somebody says giving a pull request review is easy it's probably because they never actually went over a pull request. Pull request reviews are hard because:

* you need to be polite and forgiving;
* it happens remotely 99% of the times;
* you need to think like someone else;
* everyone has their own coding style and it should be respected;
* code written in 10 hours is often reviewed in under 10 minutes;
* praise and criticism happens publicly;
* you are going to write stupid things and completely fail;
* ...

It also depends on the PR of course: certain PRs are pretty straightforward.
You can relax with simple PRs, just approve them and merge them ASAP, your
code deserves it.

I think you get the picture: pull request reviews are more about people and less
about code and computers. In a productive development team reviews should happen
often and be stress-free; they should help the team improve over time, spread
knowledge and increase overall badassery.

## 📕 My Checklist

When I need to go over a pull request I do it several times and use each time a
different point of view. I do this because checking everything at once is simply
unbearable... I lose track of what I'm looking for and I need to start all over
again. So each time I need to look at a PR I look for:

1. syntactic correctness
2. feature completeness
3. meaningful use of git

### ✅ Syntactic Correctness

This is the first check: it's easy and fast (depending on the amount of code)
and doesn't require a fresh brain and, usually, can even happen late during the
day because it's just a matter of checking:

- do tests pass? Is the build green?
- does static code analysis report problems (i.e. [RuboCop][rubocop] and
friends)?
- overall look of the code, are there any code smells?
- are the description and the commit messages written in proper English?
- does the PR respect all of the project conventions (i.e. branch naming,
labels, ...)?

Generally, if something is clearly wrong I either assume the PR is not ready to
be reviewed or straight away ask for a fix on those simple things before digging
into the PR.

The key take-away here is **automation**: you'll save a ton of time by using
tools like [overcommit][overcommit] or [Hound][hound], take the time to
configure them properly so they can do the work you would do manually.

Another thing I do regularly is using [pull request templates][pr-templates] to
add a checklist of what a project needs. Depending on the project and team, stating
clearly the review process within the PR itself can be a huge time-saver,
especially for simple requirements. There are a [ton of examples][pr-template-examples]
you can choose from.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a30b68397c4da12a3e1274e08ff86159eff9e1fa-200x144.webp?fit=clip)

### ✅ Feature Completeness

This step is the hardest. First of all, I read once or twice the issue the PR is
trying to solve (it should be linked in the PR description), then I go over the
code changes, class by class, file by file and dig down the code as in depth as
I can.

The idea here is to try to understand if the person that wrote the code:

- had a good understanding of the issue (asked the right questions, had the
required skills, ...)
- wrote code that actually solved the issue
- didn't miss any edge-cases
- used the right design patterns (and didn't over-engineer the code)

All of the above can be *extremely hard* because you're generally looking at
the result of several hours of work in a short amount of time (sometimes you even
need that code in production and it won't help).

The key takeaway here is **open-mindedness**: never assume anything. Always be
neutral when reviewing code, you should look at code as something that can
advance a project, not like a form of art.

If you've been asked for a review there's a good chance you're the more senior
developer (at least in that competence area). It can be tempting to request
changes just because the code "looks ugly" or maybe because that doesn't look
like something you would write... That's not the way you should do it: look for
real problems, effective solutions and give developers the freedom to write the
code in their style within the project guidelines.

![](https://cdn.sanity.io/images/kqgmf0g2/production/eacaebf6b0ca46c088f79d4baeef17bc69419e5a-499x341.gif?fit=clip)

### ✅ Meaningful Use of Git

So, the code looks solid, now onto the commits. Why are commits so important?
I think of the git history as a ball of yarn that needs to be untangled: would you
prefer the thread to be neatly rolled around... or would you prefer it to be randomly
put together just for the sake of building a ball form?

This makes sense to me because we've always used [Trunk Based Development][trunk] so
our projects' `master` history is a single line of commits with each commit connecting
(hopefully) to the following one, in a single stream of changes. As the features grow and
evolve, the git history linearly represents what happened and why.

With commits following one another it's helpful to try to tell a story with [good git
messages][git-messages] and overall common sense. I ask for changes on a PR when:

- meaningless history added (code is added and removed within the same PR)
- lots of changes and few commits (history is not explained properly)
- lots of commits and few changes (meaningless history probably added)
- commits explaining what the code does instead of saying why it does it
- merge commits (rebasing is a tidier way of making changes on PRs)
- commits not explaining what's happening (the infamous "fix the fix")

A lot of my time goes into reviewing git messages and it can sometimes feel like a
chore (in particular for smaller projects) nonetheless understanding clearly
what and why a particular piece of code is there is crucial for long term success
of a team of developers. On long term projects developers often forget what happened
a year ago, not to speak of new developers picking up the project later down the road.

![](https://cdn.sanity.io/images/kqgmf0g2/production/528c59f74aa0bd3b3a7ab8c1f93c258813f22db0-392x208.gif?fit=clip)

##  💅 Tips and Tricks

And that's pretty much it! I'll end this post with a final list of random things
that I find helpful:

* automate everything that can be automated
* giving reviews will help you write reviewer-friendly code, encourage everyone to review code
* speak to your team so that they know you don't hate them
* practice [Radical Candor][radical-candor]
* add gifs and funny pictures once in while to a review, a good laugh will set the right mood
* you're not on Twitter, don't troll around
* always explain why, never say "change this" without actually providing some examples
* if everything else fails, schedule a pairing session
* schedule your "review time" (I generally do 80% code/20% reviews)

A Guide to Effective Pull Request Reviews

Once the number of decision-makers in a company increases, it becomes increasingly more difficult to
gather feedback and get stakeholder buy-in on organization-wide changes and policies.

Conference calls and instant messaging, the two communication mediums of choice at most modern
companies, are not the right tool for the job: their fast-paced nature and volatility makes it
difficult for people to collect and organize their thoughts before sending them out to their
colleagues for evaluation.

## Feedback takes time

For most of us, it takes hours or even days to analyze a new idea from all possible angles and
structure it properly, but in a chat or a call, you only have minutes to do it before losing
people’s attention. This makes these tools the perfect place for quick back and forth, but not a
good choice for decisions or projects with a wider scope.

The same goes for feedback: **if you really want someone's opinion on your plan, you need to give
them time to think it through.** You are not going to have someone’s full attention by Slack-ing
them in the middle of the morning - the best you can hope for is a thumbs-up. It gets even worse
when people are sick or on vacation: in this case, you risk completely missing out on their feedback
because they were simply not in the right place at the right time.

At Nebulab, we started experiencing a few of these problems and then some more. With four directors
handling all aspects of the company’s operations and a marketing and design department to coordinate
with, we started experiencing a lot of frustration when trying to propose new initiatives that
affected the entire company.

Furthermore, people would be too busy to leave their feedback on new ideas or simply miss them in
the daily sea of Slack messages. When left, feedback would then sometimes be misplaced and/or
forgotten, which caused a lot of friction and slowed down the implementation of new initiatives.

We knew there _had_ to be a better way to discuss ideas and make decisions. We just didn’t expect it
would come all the way from 1969.

## Enter the world of RFCs

The Internet has had a structured format for gathering feedback and describing initiatives for quite
a long time: in 1969, Steve Connor wrote the very first RFC (Request for Comments) at UCLA to
organize the work of the new ARPAnet research program. In fact, RFCs were the first online
publication series.

Over the years, RFCs have been used as a way to gather peer review on new ideas, architectures and
protocols by many official bodies and independent authors all over the world. While some RFCs end up
becoming Internet standards, for the vast majority of them the purpose is to gather initial feedback
on an idea to refine it and make it ready for real-world usage.

We thought RFCs would be the perfect format to propose new ideas and initiatives in Nebulab.

## Our RFC template

We knew we’d need to tweak the format slightly: RFCs used by the IETF tend to be very formal,
because they describe standards that will be potentially adopted by the entire Internet, but in our
case we just wanted to propose changes for our company.

With this goal in mind, we listed a few constraints for our RFCs:

* They had to allow us to **explain an idea in detail** and reply to reasonable objections in
  advance rather than on the spot.
* They had to provide us with a **centralized place to gather peer feedback** and implement it
  before being rolled out.
* They had to provide **a clear framework for experimenting** with new ideas before making them
  official company policies.

We quickly sketched a first draft of our RFC template in Google Docs. We chose Google Docs because
it makes it extremely easy to organize files, share them with the right people and gather and
implement feedback in the form of inline comments.

This is what we came up with:

![](https://cdn.sanity.io/images/kqgmf0g2/production/1c6b4aade8b264af3c9ff37d121b518e9d0de0b3-1278x1526.png?fit=clip)

I’ll skip the header, since it’s quite self-explanatory. Instead, let’s walk through the other
sections one at a time.

## Why, what, how

First of all, we want to explain _why_ we are proposing this change. This really forces us to think
about the problem we’re trying to solve and the outcome we want to achieve. This is probably the
most important part of the entire RFC: **the best-designed initiative in the world won’t do your
company much good if it’s solving the wrong problem**, and putting it in writing helps you ensure
you deeply understand the challenge at hand.

Next, we explain the solution we are proposing to the problem. These are the implementation details,
and we usually go quite in depth here about what we want to do and how we plan to do it. This allows
peers to visualize our solution and provide feedback to propose improvements and better alternatives
to our plan, as well as to find any drawbacks or areas of the company that we forgot to cover.

Finally, we describe the roll-out plan for our initiative. When you start with a brand new policy or
project, it’s not enough to simply dive into the execution. Instead, **you need to create the proper
structure to support your initiative**, communicate it to the relevant team members and ensure
everyone’s on board and clear on how to execute. We quickly realized that this initial phase can
make or break our ideas, so it can’t be left to chance.

The first three sections give you a pretty good overview of the problem we’re solving and how we
want to solve it, but how can we go about validating our solution?

## Define what success looks like

This is where the _Metrics_ section comes in. For each RFC, we do our best to list two or three
metrics that we can use to evaluate the proposal and determine whether it’s working as expected or
not.

This is necessary because it’s very easy for new ideas to start accumulating on people’s plates and
drag on even when it’s clear they aren’t working. No one wants to shoot an idea in the head,
especially when it’s not ours, but **every new policy and every new initiative come with a burden:**
management needs to document it and team members need to understand it and execute on it.

By having clear metrics, we can revisit an RFC and quickly determine if it solved the problem it was
designed for or not.

This is what we use the _Status_ column for: when an RFC is first created, it’s a _Draft_. Then,
once it’s ready to be shared with relevant team members, it becomes a _Proposal_. At this point, any
feedback is integrated and the RFC is finalized and rolled, and it becomes _Experimental_. When we
revisit the RFC and determine whether it’s working or not, it becomes either _Effective_ or
_Abandoned_.

## Plan for the future

You may have noticed the template also has a _Future possibilities_ section. This is because we
encourage people to keep their initial RFC for an initiative as lean as possible, which allows them
to quickly validate ideas before deciding whether to continue with their development or not.

So, for instance, for an RFC that describes a new type of service Nebulab could offer to its
clients, future possibilities may include productizing that service so that we can provide the same
value to clients with a fraction of the work. However, this is definitely not something we want to
do in the initial phase of the implementation, since it would cost us a lot of time before we even
know if the service resonates with our customers.

By planning for future possibilities in advance, you can write down any ideas while they’re still
fresh in your mind without spending the time to implement them.

## Asking for and integrating feedback

As I mentioned, one of the reasons we chose Google Docs is because it makes it extremely easy to
leave inline feedback on a document, and the comments system allows the author of the document to
reply to the feedback, reach a conclusion and incorporate it in the original content (or drop it).

When we’re working on an RFC, we usually ask for **30% feedback, 60% feedback and 90% feedback** so
that we can adjust the document at different stages of its lifecycle. This concept is better
explained in <a href="https://blog.trello.com/avoid-the-seagull-effect-30/60/90-feedback-framework" target="_blank">an
article by Trello</a> which we strongly invite you to read. It can be applied to all kinds of
feedback, not just RFCs, and **it can truly transform how a company thinks about feedback and
collaboration.**

In the case of an RFC, an important aspect to keep in mind is that, because of their experimental
nature, the author(s) have complete freedom on which feedback to accept and which to discard. Your
RFC is your baby and you can decide how you want to raise it - after all, that’s why we have a
structured way to determine success!

## When NOT to use RFCs

I want to end on a note of caution: RFCs can be a great tool for driving change across a company. As
we’ve seen, they give us a structured way to document a transformation, get buy-in from teammates
and evaluate the results. However, they’re not a one-size-fits-all tool, and there are a few
scenarios where I’d advise against using an RFC:

* **When the change is so small it doesn’t warrant a full-blown discussion.** This can be the case
  for instance with small implementation changes for existing initiatives. At the end of the day,
  you set this boundary, but make sure to use your judgment.
* **When the change has limited scope (i.e. it only affects a team of the company).** In this case,
  you’re probably better off discussing the change with the individuals involved directly rather
  than trying to capture all the details in advance.
* **When you don’t actually care about the feedback.** We strongly encourage people to own their
  aspects of the business here at Nebulab and we give them all the freedom they need to do it. If
  you feel very strongly about a choice and you can validate it easily and with little to no
  repercussions, then just go for it.

As always, your mileage may vary, but we’re pretty sure most companies could benefit immensely from
having a more structured approach to organizational change.

## Additional resources

The following articles have been a source of inspiration for our RFC process and we strongly
recommend them:

* [https://philcalcado.com/2018/11/19/a_structured_rfc_process.html] A Structured RFC Process
* [https://blog.trello.com/avoid-the-seagull-effect-30/60/90-feedback-framework] Avoid The Seagull Effect: The 30/60/90 Framework For Feedback

Finally, [https://docs.google.com/document/d/1cSNTB0ECzyiuTMm2Rb8RiGtN_iizzmjWJZiztljTv4w/edit"] (we
have published our RFC template), so that you can easily fork it and use it at your company!

The Nebulab