During my recent (and successful) series of interviews one interviewer asked me “what kind of leader are you?” I blurted out “supportive,” not having really quite prepared for that sort of question, and while it’s true, I didn’t find that answer satisfying – support is not all that I provide, though I find it important. So I resolved to do better in alter interviews. This topic came up as a prompt for a final presentation to a panel of interviewers, so I chose four adjectives and presented those. (Any one of these topics could be an article unto itself.) A slightly cleaned-up version of what I had to say appears here:
I don’t really talk about people as “my employees” or “people who report to me;” I like to think of designers, researchers, writers, etc. as “the people I support.” The people commonly thought of as individual contributors are the hands and feet of the organization, doing the actual work that our users and customers will interact with, and they need the path cleared to do their work as best they can.
I typically have a weekly 1:1 with each person I support, time specifically set aside for me to support them. And I try to create the conditions for the people I support to be mutually supportive as well.
One way this occurs is by having weekly design critique, prefaced by my giving the team whatever “news” I’ve gathered from the company. Critique is not about design approval; it’s really time to borrow the brains of other team members for help working on whatever you are working on, and the teams where I’ve put it in to practice have, over time, come to seek each others support outside of critique, have been more aware of what is going on on other teams, have borrowed good thinking from each other, and have in general started to converge in terms of the experiences they are producing. This works remote or in-person; at Cayuse most of the folks on the team had never met in person. (A good design system and pattern library helps with this too, of course, and while someone should be in charge of it, it’s worthwhile to have multiple individuals chew on it and take pieces to work on.)
In order to improve our results we need to change our behavior. “Try harder” is not typically an effective strategy. There are a great many ways we might need to adapt:
- We might need to add capabilities by bringing in people who have these capabilities, or through training.
- We might need to encourage existing behaviors through process changes, internal metrics, or incentives.
- We might need to change which people work together when.
- We might need to address specific interpersonal issues.
When something isn’t going quite right my first questions are not about who, but what is our goal and what activities are contributing to that goal or detracting from it. When I arrived at Cayuse, several product managers largely gathered feedback from customer advisory boards, and many on those customer advisory boards were not frequent users. Some weren’t users at all. And the designers basically punched out UI based on very specifically-written stories with little or no user contact. Both designers and PMs needed to be pushed toward alternate research methods, especially user interviews, so I pointed out what sorts of activities went with what parts of the Cayuse process, and gave trainings on interviewing intended to lower the barriers to actually doing interviews. Here’s how to plan, here’s how to schedule, here’s what to do in awkward situations, etc. And it worked! In the Risk Management, Inventions, and Animal Procurement teams that were only doing CABs, they started doing interviews to investigate specific capabilities they were working on, leading to more meaningful debate and decisions that could actually be explained to upper management.
We also might need to adapt when it comes to the data we seek – Belkin and Cayuse both neglected support contacts for a time. Cayuse is still wrestling with how best to use NPS comments, and for now ignoring customer forum discussions as a data source. Some orgs look for “north star” metrics when they really should start by counting basic user successes.
I’m also a little bit skeptical of “best practices” – when people speak of “best practices” it sounds to me a lot like copying. Being informed by what others have done, and experimenting, piloting, adapting, is great. But if you just copy your not learning.
I debated whether to call this “communicative” or “connective” – to be most effective, people need to to know what’s going on in the organization, how their work contributes to the success of the product they’re working on and the org as a whole, and why we are making the decisions we are making. They need to be plugged into feedback and data coming from real users and real customers. They won’t act in an empowered and accountable way until they are able to make decisions, however small, in an informed way. That’s why critique starts with the news, for example.
I’m fond of a “one page strategic plan” approach to ensuring that our adaptations are chosen to support our goals and our strategy, and I share this thinking and let people help with it. In a one-page plan, each strategic objective is broken down further and further until we get to concrete activities. Generally you’ll find that some activities feed multiple objectives and are thus especially valuable. The important part here is that by going through this exercise we can arrive at a prioritized set of initiatives to improve how we work and the quality of that work, arriving at that plan is done in public, and the plan is available for review so that when we aren’t thinking straight we can recall what we were thinking when we were thinking straight.
It’s essential that the people needed to make a decision get together to make the decision. There are many forms of “get together” but I’m especially fond of product trio, where the key product person, key technical person, and key design person make decisions together. If push comes to shove the product person owns the product, but the main idea is to avoid ill-informed decisions that invite revisiting immediately. I can’t tell you how many times a designer has come to me complaining that “the plan changed again” when the underlying issue was that the right people were not together, leading to an unstable decision, or an opinion being taken as a decision.
I also like to evaluate design in terms of themes, and to make sure we are all aware of and supportive of these themes. The experience quality themes from Cayuse are likely different than the themes we will arrive at with Invoca.
It’s also essential that in general we communicate in terms of goals rather than just instructions. I try to model this whenever I can. Instructions describe one way to meet a goal. It’s helpful to know what we are doing, but it’s essential to know WHY as we will need to adjust at some point and it’s easy to choose the wrong adjustment if you don’t have the goal firmly in mind.
There are good places and bad places to innovate. But what do we mean by innovation? I like the IDEO definition, which is simply “introducing new ideas.”
In general, I think we do NOT want to innovate in interface design. We want to make something understandable, usable, useful, informative, branded, and pleasant. People learn about how software works by using software. Thousands of hours of other people’s software. We don’t need to be boring but we do need to be familiar.
We may want to innovate as we improve our processes. It’s good to be informed by what has worked elsewhere, but let’s not copy from others, let’s learn from others and adapt.
I DO think we need to innovate when we are exploring, thinking about how to solve a problem, coming up with concepts. And we especially need to introduce new ideas when a concept is too clever or fancy to be cost-effective. We can think of our interventions on a scale from the simplest thing that could possibly work to too fancy for the ROI, and the right concept for today is somewhere on that scale, often a little lower than we’d expect. We may need to introduce new ideas to make something satisfying and effective that takes us down that scale to the right level.