June 2017 – Jeff Clark's Blog

To best foster your team’s creativity, focus less on the solution and keep talking about the problem.

You know the feeling of a new idea. It’s exciting to think about, to wrap your head around, and to whiteboard ideas for.

We all want to be part of a team just like that: high-functioning, high-output, and creative. Product leaders play an important part in the psychology of a team. And as a product leader, we are incentivized to be concerned not only with what we’re building but how we’re building it.

Our roadmaps, our backlogs, and our discussions are usually focused on the solutions: build this API, extend the UI this way, create this landing page, add this button, etc.

We like talk about solutions because talking about solutions is fun. It’s exciting to be part of a conversation that ends in a bunch of fun projects with fun codenames.

But think back to the last time a project or initiative went wrong. That retro is almost always full of the same themes: unclear expectations, ever-changing priorities, or the super-helpful “communication issues”.

What happened with all that excitement from the beginning of the project? This time was supposed to be different! Here’s exactly when it happens:

At some point, we stop talking about the problem and only focus on executing the solution.

The same solution that we designed, estimated and planned weeks (or months!) ago has been in motion for a while. At some point, we start nitpicking UI or over-thinking micro-optimizations.

We lost focus of the original problem and started polishing. That’s when the problem solving ends, when the creativity slows way down, and where the fun ends.

A team does their best work when they’re in a creative environment. To bring the creativity back to software development, bring the problems back into focus:

Your roadmap should be a list of problems to focus on, not solutions. Your roadmap should reflect a list of the problems your team is going to try to solve. Keep talking about the problems and their relative priority, and be able to clearly communicate why they’re ranked the way they are.
Repeat the problem more than the solution. To get the most out of your team, make sure that the problem is well understood by the team. Be sure the whole team can communicate what the problem is, why it’s important to address, and why it’s important to address now. I find it useful to kick off grooming and planning meetings by re-stating the problem and our current progress. Then let your creatives discuss how it gets solved.
Be stubborn about the problem you’re addressing, but be flexible about the solution. There’s a reason the problem is prioritized on your roadmap, so changing the problem you’re attacking should be painful. However, discussing and embracing new solutions is part of a healthy creative process. Challenge the team to explain why “this new solution” is the best way to address the problem, especially when taking time constraints into consideration.
Agree on how to measure the solution before you start building it. The objective judge of a solution is the impact it has on the problem. Figuring out how to measure the solution is sometimes as hard as figuring out how to solve the problem in the first place. Before you write a single line of production code, discuss the metrics you’ll use to define success, what tools you’ll use to monitor those metrics, and any work the team will need to do to facilitate accurate reporting. (I like Mixpanel)
Your problem should have a clear “re-assesment date”, not a “target ship date”. The team can’t read the future, so you realistically don’t know if the current solution is going to solve your problem. For every problem on your roadmap, you should be able to communicate how long you’re willing to invest in solving it. Whether this is purely for planning an coordination (for example, a user conference in November) or for financial resourcing, make sure there’s a date in which you will re-evaluate the problem’s priority if it hasn’t been solved.

Increase the time your team spends talking about the problems you’re trying to solve, and you’ll start seeing more creative solutions immediately.

You should follow me on Twitter @SparkleClarkle

Leaders are managers, whether or not they have direct-line responsibility for the people on their team. And part of being a great leader is understanding how to take advantage of the experience that the creative members of your team have.

But nothing kills a creative soul more than feeling micro-managed.

“Micro-management” is a phrase that get thrown around a lot – especially by younger, inexperienced teams.

The problem is: most of the time, the team isn’t being micro-managed. They’re just being managed… but don’t want to be.

There’s one, simple difference between being managed and being micro-managed:

Management: identifying and assigning the problem. Someone assigns you a problem, a goal, and asks you to figure out how to get there. An example of management: “Increase SEO traffic 2% in 30 days”.
Micro-Management: identifying and assigning the problem and the solution. Someone assigns you a problem, a goal, the solution, then tells you to do it. An example of micro-management: “Increase SEO traffic 2% in 30 days by building blue landing pages that match this mock-up for these 150 long-tail phrases.”

That’s literally the entire difference. If someone is assigning the problem and dictating the solution, that’s micro-management.

But before you send this article to your manager, consider your role on the team for this project: You may actually be in a tactical or execution role.

On a marketing team, you’re a “specialist” or “assistant”. Your role is to execute the SEO strategy and tactics defined by management. You get to decide the most efficient way of doing it (Squarespace site, hand-built HTML, etc.), but you need to get these landing page designs up in 30 days.
On a landscaping team, you’re the apprentice. Your role is to put the dirt over there, as prescribed by the site foreman. You get to decide the best way of doing it (truck, shovel, wheelbarrow), but you need to put that dirt over there before you leave today.
On a development team, you’re a junior developer. Your role is to build this feature. You get to decide the best way of doing it (Rails, React, hand-built HTML), but you need to get this feature live in two weeks.

But even in those cases, you still have the flexibility to decide how to get the thing built. You’re not being micro-managed – it’s just that your scope on the team is different.

Having the problem identified and assigned to you is not micro-management. It’s how aligned, efficient teams work well.