Success Criteria — Why You’ll Succeed as a Member of the UX Team
This is a follow-up post to Rebecca’s discussion of what we’re looking for when we’re hiring a new UX designer or researcher. Her post outlines key indicators that we’re searching for during the interview process. However, once you’re hired and you’re starting in a position at Sumo Logic, how is your success going to be measured?
Most people ask about success criteria as it pertains to a specific project — what does it mean for a specific project to succeed or fail? However, we recently had an amazing intern start, and he asked about the success criteria for his internship during our first one-on-one meeting. It’s a brilliant question, and it’s likely valuable for most people to start a discussion with their coworkers and managers about this.
It’s taken me a few days to formulate my thoughts on this, but this is my perspective on the facets for evaluation within the Sumo Logic UX team.
Architect Mentality
As a late-stage start-up that’s growing rapidly, we’re introducing new teams and new roles regularly. One of the keys to success for these new teams and new roles is processes. In the start-up landscape of ambiguity, processes provide a place to start and a sense of reassurance. Some processes are already in place, but a lot of them need to be built or refined as the teams grow.
This is where the architect mentality comes in. I value coworkers and managers who see the need for a process and jump in to establish those, even though it’s not glamorous work. It requires an evaluation of the current state of being, and then creating a proposal for what the new process would look like. Afterward, it’s necessary to socialize the process and ensure that it cares for everyone involved. Finally, there’s judicious oversight as the process is implemented and a willingness to iterate as we discover what works.
The architect mentality requires a lack of ego, as well as a deep sense of empathy for the people who will be using the process. It also requires some fearlessness, because things will almost certainly go wrong and there will be changes. However, being able to build things is critical to the success of the team and eventually the organization, and demonstrating this to teammates indicates a sacrifice for the betterment of the team.
Craft
Craft refers to the actual practice that you do as a part of the UX team. The UX team is comprised of designers and researchers, with a few sub-specialties within those two domains. For the purposes of this evaluation, we’re interested in how well you’ve mastered the mechanics of your craft.
For both research and design, we care about the end-to-end practice. Can you gather project requirements, do your magic, and produce something that moves the Sumo Logic product forward? Along the way, we’d love to hear about your decision-making process. How do you evaluate various factors when making decisions, and can you explain that decision-making process later on?
I also believe that mastery of craft is the ability to teach someone. It is amazing to impart specific skills on another mind, and it also indicates a selflessness in that the teacher will no longer be the sole practitioner in the organization with a specific skill.
Soft Skills
Soft skills are the most nebulous part of all of this. For me, I care most about how others feel when they’re interacting with a teammate.
It sounds a bit like a kindergarten report card, but I love to hear that my teammates are a joy to work with and to be around. I know that my teammates are wonderful, and I love when people outside of our team can see this too. Being a delight to be around is a skill, and it can be cultivated in a genuine way.
This year, the UX team has a goal of improving specific soft skills. We’re doing a small talk workshop with several of our favorite salespeople next month, and we’ll be working on written communication later on in the year.
All of these facets can be wrapped up together with one question — which changes do you create?
Change can be small or large. I’m interested in how a researcher communicates the results of her findings — does the researcher start discussion and eventually produce change amongst the team? I’m also interested in how a manager models respectful dialogue during a contentious meeting, and how a teammate implements a new process to consistently polish the product. All of this change-making necessitates the architect mentality, craft, and soft skills.
How do your teams measure success? Please leave us your thoughts below!
