Managing through the WHY, WHAT and HOW

A common question I get asked by managers is how to best guide and give input to team members depending on their level of experience or expertise. More specifically, this consists of things like “what’s an appropriate level of guidance required for A players”? Is there a “one size fits all”? Do I need a different strategy for every person?

Below is a framework to match guidance to an individual based on their expertise and the WHY, WHAT and HOW of a solution.

Categorizing your team based on experience / expertise

Want to read this story later? Save it in Journal.

First, it helps to have a general sense of the people you manage and how they fall into one of three buckets depending on either their skill or experience:

1. Early stage-of-career team members with the least experience or those with less developed skillsets
2. Mid-career team members with more developed experience or expertise
3. Most senior team members or those with the most advanced skill sets (these men and women are often referred to as A players)

(Note that diverse and well-rounded teams are always filled with varying skillsets, experiences and capabilities. In a healthy team the people in bucket 1 today should be the people in bucket 3 tomorrow).

The WHY, WHAT and HOW of a problem

The next thing to recognize is that different levels of experience require a varying degree of guidance. When it comes to guidance, I like to consider the WHY, WHAT and HOW of a customer or business problem:

• WHY something is needed — typically a user problem or a business / strategic need (this is the problem and not the solution)
• WHAT to do about that problem — this is the solution. For example, “more people driving hybrid cars is the solution to reduce carbon emissions”
• HOW to implement it — the tactics for putting the solution in place. For example, the specifics of a design, a heuristic / algorithm in coding, an execution plan of policy in government, etc

Matching the WHY, WHAT and HOW to level of experience / expertise

Now we have our definitions, we can build a matrix which matches the WHY, WHAT and HOW to each level of experience or expertise. As a general guideline, it’s best to err more towards describing only the problem to the highest skilled / most experienced individuals and being more prescriptive with the solution to less experienced team members. The recommendation then becomes:

• To effectively manage less experienced team members, provide a clear explanation of HOW to implement / approach something
• For mid career /experience individuals, provide a clear explanation WHAT needs to be built / implemented
• For the most skilled / experienced, you need only explain WHY a solution is important

And that’s pretty much it. Here’s a simpler way to illustrate this:

An example

To look at this in practice, imagine a redesign of a user registration / sign up page. As a team leader / manager, you might explain the following to the differing levels of Product Managers in your team:

• For a new Product Manager, explain that you need to make a couple of changes to a user registration page by adding a zip (required, with country specific validation), age drop down (required), phone number (required, with validation) and gender drop down (optional). This level of detail provides the individual with sufficient clarity to implement it effectively while providing room for experimentation on the design, layout, etc.
• For a mid level / experience PM, explain you need location, contact and age information to be captured at sign up. This gives more freedom to the individual to figure out the specifics of implementation such as. validation, what’s optional vs required, etc.
• For an experienced / highly-skilled PM, explain that you need to begin capturing user-level data to improve ads or recommendations without significantly dropping the activation rate. This puts the responsibility on the individual to figure out the right solution based on the goal, how to make those metrics trade-offs and allows buy-in to be developed.

Avoiding Pitfalls

So what happens when we don’t get this right? This can occur when you start telling your highest skilled / most experienced HOW to implement something, leaving them feeling micromanaged and overly constrained. Similarly, if you provide an early-stage career team member with WHY something is needed, but not enough information on HOW to implement it, they may be left feeling unsupported with an ambiguous problem.

A final thought — always explain the WHY

One footnote worth calling out is that while less experienced team members need more guidance on the solution required, there is always value in describing the WHY to everyone (regardless of tenure or experience). By doing this, you’re providing the support that will help that person develop autonomy in the future, as well as generate longer-term buy-in.

Closing

Like all frameworks, this is an oversimplification therefore nuanced execution is far more important than following rigid guidelines. Hopefully, it’ll be simple enough to remember while providing a solid base to build on for your own team’s development strategy.

To close, here are a few final notes:

• I’ve given examples of PM’s but this should work equally for any discipline (Design, Eng, Ops, Sales, etc)
• Like many frameworks, this can be applied as a fractal. So you can recruit some of the highest skilled / most experienced people on your team, to translate the WHY into the HOW for more junior / early-stage team members
• I haven’t talked about the WHEN in any of the above (i.e. when a solution is needed by). Timelines are always important as a communication tool for urgency / priority / etc — so always include them in the conversation
• Even if you’re not a manager, the above may help you figure out what would be most valuable to you as a team member about what you need to be more effective in your role. Example statements you might imagine coming out of this could be: “I‘d love more more context on WHY this is important”, “HOW would you recommend I implement this”, or “I’d like to ask for more freedom on WHAT solution I use to solve the customer problem”.

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.