Staffing ratios — finding the right balance between PM, UX and engineering in your team
If you are a designer or design manager you will probably know from your own personal experience that it can be difficult to lobby for more design resources. To be fair, I believe the situation has gradually changed to the better over the recent years as more and more business people understand the critical role of design for the success of a product. Still annual planning can be a pain when time and again you have to fight for each and every new design hire.
Wouldn’t it be nice to have a simple and commonly accepted formula to find the right staffing ratio between UX, product management and engineering? Jay Kaufmann recently invited me and a number of other UX and product people to discuss exactly this topic at a new IxDA Berlin format, called the Think Tank.
The most interesting question turned out to be: What are the factors that contradict such a common rule?
The magical number 7 +/- 2
Before we start, let’s clarify the terminology. Each of the three professions have a pretty broad spectrum of sub-roles and company specific interpretation. For the sake of simplicity and to be able to arrive at some general pattern at all, UX shall contain everything from user research to UX concept, to interaction design, to UI design to visual design (I will also use UX and design interchangeably). Product management in this context is the role responsible for defining the product in terms of business goals, market, vision, strategy, etc. Finally, engineering may include front-end and back-end or any number of specialized development roles that contribute to actually building the thing you want to bring to market.
Back in 2007 Marty Cagan recommended as a rule of thumb 1 interaction designer (plus 0.25 visual designer) for 2 product manager (with one product manager for each 6–10 engineers). A quick search on Google will show you a number of blog posts and articles that recommend similar numbers with a tendency towards parity between design and product management. So you often end up with a ratio of 1:1:5, give or take 2 developers (there’s no meaningful connection to Miller’s magical number seven. Take it as a memory hook and forgive me the pun). As I can tell from personal experience in various companies and verified by what I’ve heard during the IxDA discussion, at least for serious product companies who pay attention to their development process, these numbers are not too far off reality.
So, if there is at least some kind of consensus about the appropriate staffing ratio between PM, UX and development and this ratio is already reality in many companies, what’s the point? I guess there are two aspects to it: firstly, a selection bias in the discussion and secondly, the difference between a general model and real life.
The selection bias: the group of people who discussed the topic and presented some examples was by no means representative. Companies such as Zalando, Xing and Soundcloud, to name only a few, are certainly at the forefront of modern product development, at least by German standards. The reality in many other companies — small or large, start-ups or established companies — looks very different. In these other companies people still struggle with convincing their boss to hire another UX person — or a UX person for that matter — in order to pay more attention to a part of the product that isn’t properly designed yet, to fill that gap within the spectrum of UX work that the current staff is less qualified to do or simply to reduce the workload of the existing designers to a more sustainable level.
Even though — as I mentioned before — the importance of design is recognized by a larger group of people today, approving the budgets to hire the people to do the design is often a different story.
Maybe it is because often enough the final result of good design appears to be simple and effortless, that the hard work that was necessary to get there isn’t really appreciated and consequently the need for appropriate resources is neglected. Also, design is still a relatively young profession, at least in the context of software development, and many budget owners are not familiar with the actual activities that designers are doing in order to finish their work. They don’t know about the techniques and methods applied in the design process and the necessary skills and experience, so they might be reluctant to hire.
But then again, many budget owners don’t know about the details of engineering work either. Still engineering seems to be in a much better position to justify its resource needs. I guess the difference has to do with how the outcome is perceived. In the end engineering produces the product and while it is relatively easy to see whether a piece of software does or does not work, it requires a certain competence to see if a design might work or is likely to fail in the marketplace — or even to realize in retrospect that it had failed due to bad design.
Secondly — and this was the most interesting part for me –, even for those teams where the ratio between PM, UX and development is close to the rule of thumb, the balance still might not feel right. If you think about it for a minute this shouldn’t be too surprising though, because obviously there are a number of additional factors that have an impact on the right balance between roles. But what are these factors, and how do they actually affect the staffing ratio?
The product matters
Obviously the product that needs to be designed and build does have an impact on staffing ratios. First of all there is the type of product. The UX of some products is just easier to get right than others. A consumer website that follows well established workflows will benefit from design patterns that have proven successful over the years in many similar applications. On the other side of the spectrum, a professional desktop software that supports highly specialized tasks will need more time and resources to understand the context of use, identify the real user problems and goals and to find an appropriate solution for these problems, hence calling for more designers.
In a recent Medium post Jay elaborated on a related factor — the development stage of product. The idea is that during discovery, when you are exploring what to build, a 1:1:1 ratio might be what you need, while at a later stage, when the focus is on implementation, the appropriate ratio might shift to 1:1:10.
Product maturity in general or position in the product lifecycle is another influencing factor. This one is more difficult to generalize but if there is a pattern, I would argue that the UX of a product becomes more challenging over time. Sure, your pattern library might have grown to include a lot of basic components that can be used for new features, without spending too much thoughts and time. Yet if you start from scratch basically the entire internet (and some dedicated resources) are available as a pattern library — one that is more complete than everything you could ever build with the limited resources of just one company. Furthermore for anything decent that has grown for more than a couple of years and has at least some level of complexity, the benefit of reusable patterns (or more generally a history of proven solutions) is often overcompensated by the dreaded fetters of legacy.
When people talk about legacy, they often refer to the technical debt that has been accumulated over the years. Implementations that may have been good choices at the time are no longer appropriate due to scaling, new programming paradigms, new frameworks, etc. and become a serious impediment for any further development. I guess anyone who has worked on a product that has been in operation for a decade or so knows what I’m talking about. Development moving slow or stuck in refactoring projects for ages might lead to the conclusion that you’ll need less PM and UX resources.
Dated tech might not be the only issue though. Just like your architecture isn’t up to date anymore, there’s business legacy too, also known as Christensen’s Innovator’s Dilemma. If the product has been around for a while, chances are it does or did successfully serve a business model. Even if this business is declining, you cannot do without it either and traces of this business model will be apparent in the application in the form of convoluted features for important user groups or once new business opportunities that eventually proved only half successful but still add something to the bottom line. All of this will make your job as a PM or designer more difficult and time consuming.
But even if business looks great and there’s no reason to change the general direction, basic patterns and paradigms of the UX will have changed over time, or you realize that not every feature was designed with relevant follow up scenarios in mind, or you just learned so much more about your users over time that things just don’t feel appropriate anymore. And soon enough, under any rock you flip over you will find a redesign project worth of multiple sprints if not more. In the end established business models and past UX decisions might counterbalance legacy in tech so that PM, UX and development ratios stay unaffected. Then the obvious problem is speed — and a serious one.
Roles matter as well
The product is not the only determining factor for the right staffing ratio between PM, UX and engineering. Professional skill set, knowledge or years of experience obviously matter too. If you ever had the chance to work with exceptionally good people, you know that this aspect can really make a difference.
Less obvious but probably similarly important for the functional balance within the team is the way the roles are defined or, even more importantly, how they are put into practice on a daily basis. This is particularly true for the ratio between product management and UX where I like to highlight three distinct aspects. I’ll call them breadth, interdependency and delineation.
- Breadth of the PM role. In a nutshell it is the product manager’s job to set the vision for a product, come up with a strategy towards that vision and drive execution (see this recent article for a much better description of the product management role). However, depending on the organization (size, structure, history, development methodology, etc.) the actual role profile of any particular product manager will vary significantly. There might be support for certain tasks from outside the team — e.g. a centralized project management office that takes care of much of the planning and tracking. Or the product manager might have additional responsibilities, such as product marketing work. Obviously all of these differences affect the amount of time the product manager can devote to product development work and make it difficult to generalize the right ratio between product management and design.
- Interdependencies between roles. Product management and design are distinct roles with very different competences and skill sets often held by people with very different mindsets. Yet, they both define the product and even though these are complementary definitions, they are mutually dependant. Part of the creative process of design is to challenge the boundary conditions of the problem at hand. You are asked to design a kettle and end up questioning the way hot water supply is organized (example courtesy Christopher Alexander, 1964). Whether or not such a wide exploration of the problem space is encouraged or even expected, does make a huge difference for the required ratio between the roles — PM and UX but also PM/UX and development.
- Delineation between roles. This can be the notorious case of the product manager doing the wireframes and it is very different from the interdependencies I described before. Setting the boundaries of the problem space is very different from entering into solution space and performing activities that clearly belong to a different role. Most people who are into modern software product development would agree that this is bad practice and usually an indicator for a lack of designers on the team. Yet, if you take a minute and read through the actual product manager profiles on your favorite job board, you will be surprised that it seems to be common practice nevertheless — at least here in Germany.
Going freestyle
But is tapping into another professional territory really only evil in each and every case? Mentoring teammates from other disciplines to perform UX activities is a legitimate way to deal with a lack of UX resources. However, in a truly cross-functional team that is well aware of professional differences, yet curious to broaden the individual skill set, this practice might not be borne out of necessity but is rather a way to enhance collaboration and increase the overall capabilities of the team.
The obvious example is user research, that clearly needs professional skills and techniques to be performed in a meaningful way but also benefits from everyone being involved in an active way. True collaboration between UX and engineering can also extend beyond discussing the technical feasibility of design solutions or occasionally providing tips for prototyping. Although not very common, in some places hybrid roles do exist — primarily in front-end/UI heavy products — where production code is done by the same person who is also responsible for the design.
To benefit from someone who actually has the skills and competencies to work in more than one function requires some flexibility in the organization but also openness within the team. Although nowadays working in cross-functional teams is almost the default in product development, this kind of collaboration across functional boundaries is yet another story and it takes a lot of trust and confidence to let go of exclusivity in defining the roles. This is not to say, that there’s no difference between the roles anymore and specific competencies do no longer matter. However, requirements for a role change over time and differ from company to company or even from project to project. Likewise people are developing within their role and beyond. It has never been so easy to invest in personal development and pick up additional skills by using free online resources or collaborating on a side project with some likeminded people.
Functional profiles today consist of a multitude of different skills, competencies and techniques each of them rapidly evolving. There’s no good reason why they cannot be combined in a way that is different from the “traditional” set-ups of a role. Organizational frameworks such as Holacracy try to deal with this additional complexity by focussing on individual responsibilities rather than static profiles and by making these responsibilities explicit to anyone in the organization. Whatever the approach is, in order to succeed it requires openness and trust from anyone in the team and the larger organization.
If you are looking for a takeaway of this article other than “it depends”, then maybe this is the conclusion. Staffing ratios as they have been suggested before can be really helpful to back up your call for more design resources especially in companies that are relatively new to modern product development processes and techniques.
Especially in more mature organizations you might want to take them as a starting point only. From thereon take a close look at what actually needs to be done to move forward with the product (including who’s in the lead for the various decisions that need to be made) and discuss within the team who’s best suited to take on each of these responsibilities. Hopefully you end up with a shared understanding of what profile needs to be added to the team, if any. And with the joint forces of an aligned point of view it should also be easier to convince your manager to budget for a new team member.
IxDA Berlin runs bi-monthly events gathering Berlin’s Interaction Design Community.
Wrote an article related to IxDA’s activities you want to publish here?
Have a particular skill that you think IxDA could do with?
Want to share some feedback or recommendations?
Let the organisers of IxDA Berlin know by sending an email. You can also find them at their website, on Facebook or on Twitter.
