The Design Job Matrix

One of the advantages of publishing and consulting is that you get to see how a lot of different people go about design.  I’ve worked with a couple dozen studios in my career, and no two of them approached design in exactly the same way.  Roles are different; tools are different; expectations are different; processes are different.  There are as many languages of design as there are design communities, and each studio in its own way has to define what “good” looks like and how it is different from “bad”.  At the same time, there are common, fundamental problems that every studio faces and has to address.  One common design management problem is defining what progression means for a designer – how are senior designers different from juniors, and how do you know when someone is ready for a promotion?  The common answer to this is “I know it when I see it”,  but let me propose that there is a less naive approach available.

Now, much like a taxonomy of design, there is more value in the tool for the person doing the work of developing it than there is to any potential audience.  There is no universal taxonomy worth the weight of implementing, but investigating your own system of knowledge analytically can provide valuable insights.  Similarly, the Job Matrix is a tool for thinking through this problem, not a set of answers.  It will be much more valuable for you to develop your own definitions within your own context than to try to apply someone else’s.  I’m happy to share what I’ve come up with as an example, but no one should mistake this for gospel.

Design Team Job Matrix

Basically, if you can take each level of design role and break out all of the things they are responsible for, what’s expected of them, how they interact with the team, get approvals, etc., then you can create a “ladder” of behaviors and expectations that reaches from your basic, entry-level designer up to your studio design director.  There are a couple of things that are important to do in this process to make it work.  First, you must make meaningful distinctions between the roles; the language is arbitrary.  What “basic skills” means vs. “intermediate skills” is something that you will need to work out with your team, but there have to be distinctions between the roles that map to meaningful behaviors that can be monitored and documented.  Second, you need to cover as many of the areas on which designers will be evaluated at performance review time as you can; decoupling career progression from performance evaluation is a recipe for endless headaches.

It’s useful to take a first stab at coming up with something like this on your own.  It takes some time to figure out the right categories, level of detail, etc.  However, this is only ever the beginning.  Where this tool really starts to matter is when you talk about it with your team.  This is essential; every member of your team should understand exactly where they fit in the matrix, what they need to do to “level up” to the next role, and how they can demonstrate those behaviors within the context of their current project.  You need to have this conversation with them one-on-one, in private, so that you can address any discrepancies they might have between their self-perception and your evaluation of them, but also so that you can candidly discuss what each of these terms mean in your particular context.

This is a great forcing function as a team leader, as it makes you really think through each of your designers, where their strengths, weaknesses, and opportunities for improvement are.  Ideally, it pushes you to think about how you are going to grow each of them – what kind of opportunities, coaching, training they might need.  But, it also forces you to be really honest with your team about where they are, how they are performing, what is expected of them, and what doing better looks like.  These are things we should always be doing as leaders, but it can be easy to avoid the uncomfortable conversation with someone who is not excelling.

Don’t be surprised if you end up going through a lot of iterations.  As you talk with your team, areas are going to come up that you didn’t anticipate, or definitions will shift for certain terms.  Again, the process is more important than the end-point.  By working through the categories, you will develop a common understanding within your studio of design practice, roles, and responsibilities.  Incidentally, once you are done, it also fairly easily gets re-composed into job listings, but that’s just whipped cream on top.

One side-note, in my matrix, I’ve divided the career progression path from Sr. Designer/Lead Designer on into two parallel tracks: one for individual contributors and one for team management.  As discussed here, promoting great IC’s into management can be disastrous, and the best way around this is to provide advancement without requiring management.  However, the base reality is that managers tend to get paid more, which is reflected in the salary numbers at the bottom (again, don’t take these as gospel; salary figures vary highly by region).

(This material was re-posted from my business blog at www.betterrealities.com, which explains - among other things - that I am available for consulting if you need help getting to this level of clarity in your organization.)