What I Talk About When I Talk About Design Enablement

Most of the engagements I work on at VMware Tanzu Labs have what we call a spectrum of enablement to delivery.

On the delivery side we're executing on software. For me, as a designer, that would include user interviews, synthesizing user information, helping product managers to prioritize solutions that map to specific outcomes, working through visual designs, and then helping to ensure that solutions are shipped and built according to the way the team wants to solve a problem.

On the enablement side of the spectrum, we're working to share our ideas about XP Agile teams, lean product delivery, user centered design, and offer a hands on how-to of all of the skills we use to delivery software.

I generally have a pair and pair with that designer most of the day, everyday on an engagement. (If you want to know more about design pairing, check out my Love Letter to Design Pairing.) When I'm pairing with a designer they can have a wide variety of skills. Sometimes my pair is brand new to design as a practice and other times they've had decades of experience. For that reason, "enablement" can be a tricky word.

I'm not coaching exactly, but I am trying to impart my knowledge. I'm not a teacher since we're working together. There's likely to be a skills gap between my pair and me, but that doesn't automatically mean my job is to close that gap. I think, more than anything else, I'm trying to share everything I know about design with the objective of trying to allow someone else to build their skills with mine as a springboard. I call that "enablement".

Enablement may not be the optimal word, but it is the word we use, so instead of focusing on the word itself or even the outcomes that enablement can lead to, let's just walk through the things that I commonly talk about with clients when I talk about enablement.

PRACTICE GROWTH

One of the first things I think about when I'm beginning to work with a new design pair is practice growth. I try to think about what skills I want to improve and share that skill with my pair, and I also ask my pair to share what skills they want to improve. This includes an informal assessment of what skills my pair is interested in.

I often scope this by creating buckets of skills. Those buckets may include bread-and-butter design skills like user research, research synthesis, visual design, ideas about user centered design, and in some cases technical execution through front end coding. They may also include skills that are not necessarily bread-and-butter of design but could be important skills for professional development and growth. Those skills might include facilitation, prioritization, story writing, technology-related skills, and communication skills.

While not exactly a bucket, I often find that these discussions include conversations about tooling. Sometimes clients have a specific toolkit or a design system and strengthening skills or learning new skills connected to a specific tool is a common area my pairs have identified for growth. Also, it's often both enjoyable and approachable to try out a new tool like Pivotal Tracker, Miro, or Figma or to learn some new tips and tricks on a specific tool.

Once I have established those buckets, it's easier to discuss where my pair may identify their own skills. Sometimes this is an informal conversation that's on par with a get-to-know-you and other times this is an active, facilitated discussion where those buckets are posted like categories and then skills under each are discussed and maybe dot-voted.

While I'm primarily scoping this article to be focused on enablement as a pair, broadening the scope to enablement of a group takes the same shape. In a group setting I would ask about the group's skills, the group's interests, etc. and then try to tailor my enablement per person and/or identify common threads across the group.

DOUBLE DOWN OR RAISE ALL TIDES?

Once I know more about what skills my pair is interested in improving, I often have a good idea also about what they enjoy. It's hard to learn things you really dislike, so I often try to identify what my pair will find fun so that we can maximize the enjoyment of the process. Skills discussions always include inflection. Few, if any, people are capable of discussing skills in a neutral way.

The vast majority of skills conversations include how someone feels about a skill.

Once that step of the process is complete, I usually tell my pairs that we have two options:

Option One: We can focus on the specific skill that they're most interested in or already really great in and take it to the next level. The outcome is likely to be a lot of improvement in one area, but not a lot of improvement or perhaps no improvement in any other area. For example, perhaps a designer is really interested in and loves doing user interviews but they aren't very interested in doing any visual design. Maybe the visual design tools are daunting or they'd prefer to work toward a track of user research rather than visual design, in those cases I can handle all of the visual design and spend extra effort working with my pair on user research skills.

If we're going to spend more energy in one specific skill. I call this the "Double Down" approach.

Option Two: Rather than focusing on one particular skill, we can focus on the entire end-to-end process and as many skills therein as possible. The outcome is likely to be less improvement in any one area, but a little improvement in lots of areas. This option is common in cases when a designer is new to the practice, but it's also common when skills are very high and there isn't one particular area of focus. Sometimes this "raise all tides" option occurs when a designer of any skill level is just really interested in all the aspects of design and can't really focus on any one skill.

Side note: I tend to personally have more interest in Option Two because, I'm really interested in all the different areas of design and I love to incrementally improve my skills. I'm more of a generalist than a specialist. That said, I always let my pair guide which option they would like to invest in. My job isn't to inject my personal thoughts but rather to focus on what's important for my clients.

I DO, WE DO, YOU DO

As we work through the skills with the objective of growth and professional development, I tend to employ an "I Do, We Do, You Do" framework.

In the "I Do" phase, my role is to model the right behavior, deliver on the software work, and allow my pair to learn by watching. This is an important first step because it often removes any tension or pressure. If my pair can see that I'm capable of delivering, then they're usually put at ease. That's a great starting point. It means that my pair is able to focus on asking questions, taking a step back to think through the process, and that often creates a great sounding board. While the step here is called "I do" really it's a conversation. I don't expect my pair to be a bystander. I expect them to be given a relaxed setting where they can explore ideas.

In the "We Do" phase, we do things together. Sometimes this takes the form of ping-pong where it's my turn to do something and then my pair's turn, or sometimes this takes the form of a 1-2 combo where one of us leads and the other supports and then we switch. In the "We Do" phase we're working together, complimenting each other's skills. I'm likely to offer tips, challenge ideas, give slack for new ideas, and foster an environment of safe experimentation. I want my pair to flex some new skills; I want them to learn by doing. The "We Do" phase is usually the longest section of an engagement, so it's also the time when the skills are really built up.

Finally, the "You Do" phase is a phase where my pair is leading the design work and I'm acting in support. I sometimes think of this as being like playing bowling with the bumpers in the gutters. My pair is likely to hit a lot of strikes, but if they go in the wrong direction I'm there to prevent any issues. This is also a safe place where my pair can really flex their new skills and it's often a satisfying phase where a lot of new skills are highlighted and used.

I think usually I stop here and say "I Do, We Do, You Do" is the framework, but it's actually a circle. The "You Do" phase, in my experience, is also a starting point where we can then identify additional areas for growth and then work through those.

SOME PARTING THOUGHTS

Enablement is often the best part of my job because it means focusing on people. I love to be around new people, learn from them, get energized by their energy, and ship some software in the process. I've been very fortunate in my career to work so closely with so many people wanted to improve their skills the same way I do. I'm always trying to be better and learn more. My curiosity has become a major asset in my job, but it's also been a contributing factor to my quality of life.

As a final parting thought, I think it's fair to read this article as being a single direction: I do the enablement and my pair is enabled. I think it's also fair to read this as though there is a power dynamic where I know something and my pair doesn't and I'm guiding them.

In reality, pairing is always a two way street and enablement is multidirectional.

If you loved this article, share it with your friends. If you didn't, tell me why so I can do better next time. Until then, thanks for reading!