“Agile” product practices, whether, Scrum, SAFe, squads, etc., encourage the formation of independent, self-sustaining teams. As the importance of design has become more broadly understood, these ‘user-facing’ product teams often feature an embedded designer, working with a product manager (or product owner), and some number of engineers, as depicted in this diagram:

Diagram depicting product teams, with one designer, one PM, and n number of engineers per team

When you embed this designer, you’re now asking that individual to deliver across a daunting range of capabilities:

Diagram showing the designer in the center, and their responsibility for visual design, interaction desing, copywriting, user research, strategic thinking, information architecture, communication skills, leadership, and planning

The plight of the Junior/Entry-level Designer

Any junior designer thrown into this situation struggles, as they don’t have the experience and expertise to handle this. Often, the Product Manager is a mid-career contributor, who doesn’t know how to coach up designers. So, the junior designer ends up acting as a production artist, serving at the behest of the Product Manager. I hear a lot about Design organizations that are seen primarily as production shops, and it’s almost always for this reason—the designers aren’t true peers to product and engineering, and are just expected to do what they’re told.

Given this, a common refrain I hear from design leaders is that they cannot hire junior designers, because they need to bring people on who can slot into this context and hold their own. This is exacerbated by the design leaders often being spread too thin, so they don’t have any capacity for mentorship.

So, junior designers are caught between a rock and a hard place:

  • they’re hired into an untenable situation, and struggle to do anything more than be a production artist (and wonder why they bothered getting that fancy design degree if they can only practice 20% of what they learned)
  • they keep hearing about how “there are not enough designers,” but they can’t get anyone to even talk to them about a job

Everyone suffers when we don’t make space for junior designers

This ends up creating additional stresses within design teams and the broader design industry. Within design teams, there’s a constant struggle to find senior talent, as these teams have no internal pipeline in which to mature designers, and senior designers are highly sought after in the recruiting market. Also, because there aren’t junior designers in the design team, the senior designers end up doing a lot of production-level work, which takes time away from more impactful, bigger-picture work, and which limits the strategic contribution that the design team is able to make within the organization. So then these senior designers get frustrated and burned out, and leave in order to find opportunities that are more fulfilling.

Within the broader design industry, there’s a recognition of a severe lack of talent to meet demand, but we end up getting in our own way as we continue to forsake training up junior designers. 

A way forward: organize design around teams, not individuals

This challenge with junior designers is one of many reasons why I advocate thinking of building design orgs at the level of team, not the individual. 

Diagram showing how designers can work in a team, across a set of product teams

In this model, instead of embedding designers within product teams, designers are pulled out into their own team, working across set of product teams addressing some contiguous aspect of the user experience. Instead of needing each designer to be an identical unicorn, a team of designers can have a range of experience and a variety of skill sets. The “S” designers are Senior designers who maintain the relationship with Product Managers across two product teams. They engage that Product Manager as a true peer, not as someone who just tells them what to do. The “D” designers are junior and mid-level designers who can float to where they are needed. They don’t work on their own, but always with the guidance of a senior designer or the Team Lead (TL). This is how they develop their practice. (Unrelated, but worth calling out: Since we’re operating as a team, team members can have distinct skill depths. So, here, we have a Content Designer (“CD”) who can bring expertise in writing and information architecture to the work being done.)

Through a model such as this, we have made room to bring in junior designers, situate them in a way that they can learn and grow, enable more Senior designers to focus on higher order challenges, and have created an internal pipeline to develop team members so they become our next generation of senior designers as we need them. 

“Agile” orthodoxy is harmful to the practice of design

To simply follow standard practices for “Agile” development (I’m putting “Agile” in quotes because I recognize that these practices often conflict with the original intent of the Agile movement), is to sell short the future of design as a function and a practice. We need design leaders to advocate for organizational structures and processes that enable design to deliver on its potential, or we will continue to see designers treated as subservient to other functions, order takers with little agency in their work.

8 thoughts on ““Agile” is eating design’s young; or, Yet Another Reason why “embedding” designers doesn’t work

  1. Thank you for writing this. These situations are parallel to how our design team has managed to grow in the last two plus years. Moving from that designer per project model and layering in team management/mentorship has really proven valuable for us.

  2. Interesting to read this as someone who experienced this first hand. My first full time role as a designer I had the title senior product designer. I was expected to do everything, yet had about a year of experience as a sole contract product designer prior to that role. I failed at every turn, and eventually landed with a “does not meet expectations” review when I didn’t even know what my expectations were. In fact, this is also when I learned that the only reason my title was inflated was because of my pay band. There is so much more I can say but this is just another example of how broken the single designer on a scrum team model is. You learn fast, but not thoroughly and with little to no guidance. I’ve now been doing this for 6 years and finally feel like maybe mid level since every role after this was just as stressful. I just accepted a new role at a company with the model mentioned above as are seeing the issues with the squad model as they scale and there has been a lot of backlash from the design team. I’m hoping that when I join it works because in my experience, there are never enough designers for all of the scrum teams so we tend to be spread across 3-5 in larger orgs.

  3. Great read, thanks.
    Your proposition is very similar to the agency model, which has its cons too: by removing de juniors from the direct contact of the PM, an individual cannot stand out and prove its value. Maybe somewhere in the middle there is a a matrix org just like you did with a design team + squad where the young designer can prove its value but can also seek support from the Lead on discovery, research, facilitation, communication… so it’s just creating an intermediate layer for juniors where they are both in the squad and in the design team. The seniors could have scopes (perso + checkout, product page + review, …)…
    Thanks for helping clarifying things on my side!

  4. A topic that is so on point for where design is at right now. We have come a long way and finally we are here; deciding on what to do and why, together with the business, but somehow we forgot that we also need to get our hands into the actual design tools. This is why design has become more talk than action where there is no one anymore to do any action. And this is exactly why we’d like to hire more junior designers, but alas….it will not fit into our teams because they will be eaten alive.

    Thank you for this article, it fully backs up tour struggles and gives us a way to think forward!

  5. Thank you for writing this article. But I don’t understand one thing: You mention that one way to integrate junior designers is: “They [junior designers] don’t work on their own, but always with the guidance of a senior designer or the Team Lead”. But this shadowing of senior designers is also possible if the senior designer is embedded. I don’t see why this should be an argument for not having designers embedded?

  6. I like this model for junior designers. Where I see potential issues is around the role of the “S” Designer managing two teams. This is highly dependent on the rest of the organization, but that role could easily end up either consumed with meetings (conflicting meetings at that, as the two teams would need to manage around the conflicts of a single designer’s schedule) OR the “S” designer ends up not being involved in decision making within the product teams due to a lack of availability, further decoupling design from decisions and pushing it further into a delivery/agency role.

    Have you seen these issues in practice? Or any insights into how the “S” role works in this setup?

  7. This is a staffing problem plain and simple. Why does engineering get to have multiple people on a team but design doesn’t? Because we don’t staff design the appropriate levels in orgs. If you flipped this (3 designers on a team with one engineer) everyone would laugh–and recognize this as a staffing problem, not a process problem,

    Agile is an easy boogieman here, but it’s not the issue.

    • Peter Merholz says:

      “Agile” (in quotes) is definitely the issue. Whether “Scaled Agile,” or one of the other common approaches used by companies when engaged in an agile or digital transformation, the way these orgs implement “Agile” very much is an issue.
      Now, I’m placing it in quotes, because I recognize that “Agile” often runs contrary to the mindset behind the original Agile Manifesto.
      But, you’re fooling yourself if you do not think “Agile” has not been corrupted beyond all reasonable applicability.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>