“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:
When you embed this designer, you’re now asking that individual to deliver across a daunting range of capabilities:
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.
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.
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.
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.
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!
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!
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?
Both the Junior and the Senior are embedded in different squads, and both are working to the direction, cadence and pace that the squad dictates. In most cases, neither the Senior or the Junior have the overhead or space to take time out for mentorship.
They have to try to behave as a team without the ability to coalesce as a team.
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?
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.
“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.
Many design skills are not needed continuously on a product team.
Engineering solves this by having some experts service multiple teams and trying to have the team members with a full stack ability to work on anything their product needs.
So this can be a bit of a staffing issue AND an org design one. By having an “embedded” designer on a team they deeply empathize with the users and their problems. I don’t see why the alternative model isn’t to keep this and have supporting deeper expert design services for copywriting, visual design, IA, and user research — that support multiple teams.
Love the way you have described Design . I am myself a designer and can totally echo on your perspective.
This is an amazingly well written piece and captures very well the challenges in the org design faced by design teams. Particularly challenging for the organisations that have not yet reached design maturity and minimum mass of designers to be a strong voice in the discussion. This debate is a very challenging one: as the core agile practice and thought leadership gets the role of design but the process does not explicitly explain how to work with designers/ ceremonies etc thus this is often almost exclusively a job every design leader has to do ground up in any new team(I am repeating it the third time in last 4 years). Don’t get me wrong it’s very fulfilling to be able to do this but at the same time unnecessary (ideally speaking). Takes the time from making real progress for the discipline.
It’s about time this needs to be solved in a manner that can scale.
Thank you for this article, Peter. I thoroughly agree with your approach. This is something that I have also been pursuing over the years. There are pros and cons of embedding designers, of course, but overall everyone wins with a non-embedded model.
The designers are exposed to a greater breadth of problems to solve, and thus develop more skills and experience. And products improve through equal input from design specialisms.
You also safeguard your organisation against the loss of knowledge from embedded designers as they move to other positions.
However, there is a loss too. The close communication that you get from an embedded role in a team. This is the biggest weakness in my experience, and is why I run another model over the top, simply for communication. Each member of the design team is assigned to a product (“Agile”) team on a periodic cycle – for us, we use a monthly cycle. This assignment is NOT to undertake the work for that product team, but to be a regular conduit of information and priorities back to the design team. Keep in touch.
In this way, we get the benefits of a collaborative design team that does not embed any single designer, but maintain the communication lines that are so important.
Thanks again for a very nice article.
Thanks for the article Peter, you’re raising very good points.
However, can the mentioned issues not be mitigated by the Centralized Partnership model you proposed in your book? A designer can be embedded in a product team, acting as a partner to the PM and Eng / Tech lead, while also being part of the Design organization which acts as a community of practice that ensures coherence of the user flows across product surface areas and touchpoints. The Design org also provides mentoring and skills growth opportunities – more senior designers can still help their junior peers grow. (I’m assuming the team practices pair designing, and runs regular design crits, and they’d of course have regular 1:1s with their managers).
Since the designer doesn’t report to the PM, if the Product-Design-Eng org values designers are equal partners and contributors, even more junior designers could thrive in my view, since they’re supported by the Design org. If the designer is not “embedded” in the product team, I’d question whether can be be seen as an equal partner and whether they can shape the vision and strategy, esp. in complex domains where the designer needs substantial domain & product knowledge to be effective.
So I don’t see “agile” per se as the culprit here. But completely agree we need to do more to support and grow junior practitioners.
It seems correct to confine “Agile” to quotes. I was first exposed to Agile principles and theoretical practices 17 years ago, and I have yet to see it effectively implemented once across a slew of different jobs. The telling part is that “Agile” has the same problem as Design at its root: The people at the top making organizational decisions don’t understand it and don’t know how to make it work.
Maybe it’s the Peter Principle at work, but everyone seems to suffer when uninformed authority gets emplaced. I agree that this leadership flaw hinders the designers and engineers, but it also hurts the product management itself and the customers. The Big Problem is when you have decisions issued from the ignorance of the partially informed—those special people at the “Peak of Mount Stupid” on the Dunning-Kruger Effect graph.
So while it’s true that this piece touches on how it affects the plight of junior designers, it is an indicator of how entire systems can fail due to bad management.
I see some very valid points.
– True, designers are left alone in a scrum team
– True, Designers have a lot more work to do, than just pretty screen delivery
– True, juniors are having an even harder time, when left alone
TL,DR; form a design team, not a team of one IC.
You suggest, we designers shouldn’t mingle as a product team anymore, but rather mingle as a design force.
I believe a solution will be a different approach, since removing individual contributor from the scrum team harms the product increment.
Design people are operational forces, as well as Development people are operational forces.
For a moment, let’s assume you would be talking of a Developer. Would the situation be any different?
Yet, it seems the world jointly accepts that it is not possible to have a development team of one. It has to be a team of engineers to built a product.
Considering dual track agile you are only talking about the delivery phase, which is to refine and built the increment and support the dev team.
I sense he absolutely ignores the discovery track, where it is to find what to built in your increment. So a good model is to do design exploration(refinement) up front as a team to form the story, and thus the release can be supported with less effort.