Artwork by Tammy Estrada — Visual Designer at Wizeline
Every professional needs a path for growth. A path keeps people motivated and centered while doing their best work in a company. I have seen this right from the start — as soon as we hire or even during the hiring process, candidates and new hires ask us: how can I get promoted here? As managers, we are responsible for providing a clear answer, giving them the tools, and coaching them as they move forward in their careers. One of these tools is the Career Rubric.
Career Rubrics allow people to know where they stand, where they can go next, and what they can do to get there.
In February 2020, the Design Team at Wizeline had already designed and released a couple of versions of our career rubrics. Still, through time, we became aware of two areas of improvement:
1. Design consulting vs. in-house: previous versions of our rubrics were based on what product companies such as Dropbox and Medium were doing, but we, as consultants, needed to emphasize specific non-technical skills, essential for our designers’ success at Wizeline.
2. Fast-growth and ever-changing environment: these two conditions meant that both our designers and the company needed the flexibility to adapt to new types of projects and develop skills that probably were initially not on their radar, but that would still allow them to get a promotion.
The Design Leadership Team was aware of these challenges and was ready to address them — we had read a lot on the topic, and some members, such as Aditi Ruiz and Clara Balderas, had taken external training on Design Management and Career Rubrics. So we kicked off this project as we typically do with any other project; with a workshop.
In February 2020, our fantastic partner from PeopleOps, Chema Gómez, organized an offsite for the Design Leadership Team to work on the new version of our rubrics.
As big fans of Org Design for Design Orgs, we adopted a rigid and flexible structure. This means that we use a set of non-technical skills required for every designer to grow across each level, and another set of technical skills as a “catalog” for designers to “pick” from as they shape their careers. We named the groups “Baseline Skills” and “Complementary Skills,” respectively.
These are the steps we followed to determine and line up our skills during the workshop:
1. Braindumping: on the board, we put every skill that would come to our minds.
2. Technical vs. non-technical: based on these two categories, we classified the skills.
3. Baseline skills: we selected the skills required for every designer.
The process seems straightforward, but we ran into several challenges that allowed us to reflect and come up with particular solutions for the needs of our team and the company.
We kicked off the workshop with everybody writing down skills into sticky notes and posting them on the board. We did this individually and silently to avoid bias. After we got everything out, we removed duplicates to work only with unique skills. Now it was time to separate them into technical and non-technical.
At this point, we noticed some misalignment on how technical and non-technical skills should be classified. There were discussions around how technical skills were learned while non-technical were innate to the person, but if that was true, how could we ask people to grow across skills such as communication and collaboration? In our opinion, those two are definitely learned. So in that case, they should be called technical skills (according to our classification), which didn’t make much sense when we thought of putting them in the same basket with interaction design or qualitative research, which are definitely technical.
It was difficult for us to get out of this rabbit hole because there wasn’t much literature to rely on, and the conversation was getting philosophical. So after a while, we came up with our own criteria:
Technical skills would be those essential for you to be called a Designer or Researcher.
Technical skills would be qualitative research, information architecture, interaction design, and visual design, but not communication, presentation, or organization. Not that the last three were not relevant — they are, sometimes, even more relevant than technical skills (especially in the consulting world where you need to be excellent at getting your message through, speaking correctly and professionally, solving conflict, negotiating, or thinking outside of the box).
Non-technical skills allow you to become a well-rounded professional, but we needed to tell them apart from technical skills to properly structure our rubric.
After bridging the first gap, we ran into another one: we had defined the list of technical skills and had already voted on the more relevant ones for our team, but we hadn’t considered the aspect of granularity. These are some of the skills we had on the board:
All of these are related, but some are more specific than others. So we started asking ourselves: at which point does a skill stop being a skill to become a practice area or a discipline? Conversely, how can we spot those too specific to be called skills but rather activities?
Again, we were getting into another philosophical hole. So instead of going deeper this time, we decided to replicate Jeff Patton’s approach in his book User Story Mapping and forgot about semantics. Instead, we thought of our skills as rocks of different sizes. Some were tiny pebbles, and some were giant boulders. So we drew a few horizontal lines on the board and placed the skills across the different rows, from top to bottom, from general to specific.
Once we did that, we looked at the rows and decided on the level of granularity we felt the most comfortable with. We finally had a solid list of technical skills for our designers to grow through.
With the list of technical skills defined, we went back to the non-technical skills and voted on the ones that should be required for every designer.
In this case, we chose a higher level of granularity than the level we decided on for the technical skills. We did this because we needed the skills to span across the six levels of our rubric (Associate, Mid, Senior, Lead, Staff, and Principal) and avoid forcing abilities that were not “broad enough.” For example, skills such as mentorship were essential but impossible to stretch across the six levels. These “smaller” skills were still added to the rubric but assigned to a specific level.
Baseline Qualities should allow designers to accomplish three simultaneous goals:
In our minds, the culture should grow along with our people, and in turn, people should grow by making our business successful.
After the workshop, every leader took on a different part of the rubric and spent the next four weeks creating the definition for every concept, making sure those definitions were gradual and consistent, and filling any gaps in the rubric that we might have missed during the workshop.
Although we were using the six levels for the progression for the Baseline Qualities (Associate, Mid, Senior, Lead, Staff, and Principal), we needed to provide an exclusive path towards mastery for the technical skills.
Initially, we followed the *10,000 hour* theory from Malcolm Gladwell that says that it takes 10,000 hours of practice to achieve the mastery of a skill. So we defined a progression of five levels and assigned hours to each: novice = 2,000, competent = 4,000, proficient = 6,000, expert = 8,000, and master = 10,000 — if someone wanted to prove they were competent in Content Design, they would need to prove they had invested 4,000 hours practicing that skill.
We presented this idea to the Senior Designers to get their feedback, which was far from positive. In their opinion, time invested was not a solid indicator of expertise. They were right, so we changed our focus from hours to behaviors and outcomes instead:
This approach brought a much more positive response when we circled back with our Senior Designers. Having them as a sounding board was crucial to prevent the rest of the team from freaking out once we released our rubrics.
Lastly, we had some concepts on the board that were important but didn’t seem to fit anywhere in the rubric:
These are some of them:
We decided to include them in the intro of our final document and called them The givens — those actions and behaviors we expect from people, no matter their level.
Once we had all the pieces, we put together a Google Spreadsheets file with the following tabs:
Once we had all the pieces, we put together a Google Spreadsheets file with the following tabs:
For the baseline qualities and the technical skills, we specified the level of progression across each level but realized the non-technical skills would be more challenging to measure — how can you know you are proficient in critical thinking?
For this reason, we mapped non-technical skills to each of the levels, but we didn’t create a progression for these types of skills.
Our rubric was finally ready.
Our team is very diverse in terms of personality types: we have both outspoken and quiet designers, logical and emotional, analytical and intuitive. It is unfair that those who feel more comfortable speaking in public and promoting their accomplishments get more recognition than the rest.
Those usually quieter designers are also more focused, detail-oriented, analytical, and excellent at mentoring others (among other qualities). We, as managers, are responsible for noticing their successes and letting them know their efforts are being noticed and recognized.
This is a principle that drives our practice and needed to be translated into our rubrics. For this reason, we included non-technical skills for both types of personalities and focused on outcomes rather than actions. So, for example, while some designers might choose to grow in public speaking or training, others might decide to do it through one-on-one mentorship sessions or writing.
In the case of introverts, once they get enough experience, they might be willing to develop their public persona in the service of their professional growth (as mentioned in Quiet, by Susan Cain). If not, they can continue growing as mentors, writers, or specialists focused on mastering their craft.
These rubrics were the product of the hard work of the brilliant Design Leadership Team, who was part of this from beginning to end: Aditi Ruiz, Clara Balderas, Emilio Uribe, Xavi Fajardo, and Rodrigo Partida. I’m incredibly proud of everything we have done together.
Designers spot opportunities in every experience, not only for their users but also for their clients, peers, and employees, not only for their projects but also for their internal tools and processes. Give them the chance to influence other areas of your company, and they will open up their toolset for the service of your teams. They will streamline every internal interaction and positively impact the way you operate and serve your clients.
This is what this team has done at Wizeline for years, and we will continue doing it as long as we have the room to influence the direction of this company