How to Involve and Engage Your Staff in Your Business’ Strategic Plans

This part is part five of a six-part series explaining how agile strategy-making can get you to where you want to go, faster. Click here to read part one: Why having a business strategy isn’t too ‘fancy-pants’ for your business.

You know all those times you had a brilliant idea and then you started figuring out how to put it into practice and then it all got too big and hard and you shelved it and carried on like none of it ever happened? Yep. If I had a dollar for every time I’ve seen a strategic plan developed but not finalised, or finalised but not executed…

So what’s this about? Why is so much time and money invested in devising and reengineering plans that end up languishing, unloved and unused, in some fusty corner?

A common, and entirely legitimate, reason is that the marketplace, or the organisation’s own circumstances, have undergone such change that a plan is already obsolete by the time it’s ready to be acted on. This is why I find an agile approach so effective. (Not that I invented it. Nor am I the only one who sees how awesome it can be, when applied well.)

But agile is a methodology. Implementation is a different beast entirely. If you really want to see your plans performing a more useful function than replacing your Grandma's penguin doorstop, look to the people you’re involving. Or, in some cases, not involving.

For the sake of illustration and because clearly I’m peckish right now, let’s say that your strategy is to feed everyone chocolate cake. For your business to succeed, you need your team to have enough chocolate cake for “everyone”, the means to get it to them, and “everyone” needs to have the means to eat the chocolate cake. (Presumably you need to make a profit from the exercise, so there are also financial considerations; market need is another factor, but – d’uh – we’re talking about chocolate cake – so for simplicity let’s take these and other factors as given.)

If you want them engaged, engage them

If your team performs every operational aspect well, your chocolate cake strategy will do its job and your objective (presumably increasing the obesity epidemic? But I’m not here to judge) achieved.

That’s a big “if” right there.

What if all of your teams’ experience is with carrot cake and they don’t have the knowhow, or supply chain, or manufacturing infrastructure to substitute chocolate cake? What if in their experience or through their information channels they have cause to believe that red velvet cake offers game-changing advantages?

You see, devising a strategy without accounting for the realities of your commercial circumstances, and then handing it over to your team to implement, almost guarantees that it won’t be implemented effectively. Perhaps you’ll work diligently to identify those realities.

But if that too is a theoretical exercise (and even expertly gathered market research insights are often theoretical) then it won’t necessarily be accurate or useful. The solution is obvious and yet so often overlooked: to get your strategy right, engage the people who implement it.

Put your money where their mouth is

Genuinely engaging everyone involved in the process may be easier said than done, especially in large organisations. But it’s doable – and, more than that, fundamental to efficiency, effectiveness and therefore profitability. Anyway, “because it’s difficult” should never be the reason a good practice isn’t followed. So, how can you get started right now?

Start with a clear statement of purpose, along the lines of:

“We’re encountering this (or these) problems*. Here’s our understanding of the factors involved. We’d like to get insights from the team to confirm or refine that understanding, and then come up with some ideas on how to solve them.”

* Identifying a meaningful business problem and framing it clearly is always the starting point for design thinking. For a refresher on this, read part four of this series, “the importance of properly defining your business problems”

If your team is in one location or can be collected in one without too many logistical nightmares (remember that the point of agile is to move quickly and iterate frequently, so this is not a one-time annual conference exercise), you can host a strategy-themed hackathon. Break the company into teams (minimum 3 people per team; maximum 8) taking into account that:

• Diversity trumps specialist knowledge. Mix people of different divisions/areas of expertise together.
• Hierarchy can obstruct flow. Ideally elect a team leader to each team who is not a senior manager, and encourage senior managers to park their authority and join in as equals.

Typically, I run 2-day strategy hackathons, generally defined as an event where people come together to solve problems, using the following structure:

Day 1

1. Explore, challenge and refine problems to be solved, using team members’ insights and perspectives
    
2. Determine which problem is most meaningful(i.e. valuable to solve) via vote
    
3. Describe solutions as outcomes– the “future perfect” scenario, on the basis that the selected problem has been solved.
    
4. Identify obstaclesbetween the current scenario and the future perfect scenario. 
    
5. Evaluate obstacles, in terms of amount of control the organisation has, and select those over which the organisation has little control. Vote to select one of these barriers to focus on. 
    
6. Brainstorm possible solutions
    
7. Evaluate proposed solutions according to ease of implementation and cost of failure. Select the highest scoring.

Day 2

1. 10-minute check-ins – each team presents proposed solution to group, 3-5 minute explanation; 5-7 minute discussion
   
   
2. Refine solution based on feedback, then Frame proposed solution as a story: “Person X can take Y action to achieve Z outcome”, where X has some role in the original problem-to-be-solved, Y is an interaction with your organisation/product/service, and Z is a benefit gained as a result.
   
   
3. Define target user (Person X) needs in relation to the risks vs rewards of entering into interaction Y (Note: this process can be shortcut if you’ve already completed a Stakeholder Persona exercise)
   
   
4. Define “done” – what is the action that unambiguously signals successful completion of the interaction for Person X?
   
   
5. Present conclusions – each team presents:
   • Proposed solution
   • User story
   • User needs
   • Definition of “Done”
     
     
6. 10-15 minute presentation; 15-20 minute Q&A, critique
   
   
7. Score presentations, and use feedback captured during the critiques to outline specific next steps (proceed/refine in specified ways).

A strategy hackathon delivers vetted, “packaged” solutions, complete with agreement on whether to (and how to) refine, or take directly into action planning and implementation.

But if you operate out of a number of locations and it’s too onerous to gather people together, then here’s an alternative: assign a team leader in each location and have them facilitate the process, following the hackathon content structure above, but in a series of quick-fire meetings.

Heads of divisions can then collect the results from each location and assimilate them into the strategy-making process.

Bear in mind that if you do engage your people in the process as deeply as this, you’ll lose all of those gains and a fair bit of morale if this is the last they hear of it. So please don’t let the next time they come across it be behind Grandma’s door.

And if you like the sound of this approach but are unsure how best to implement it in your particular situation, contact me and we can have a chat.

Click here to read the sixth and final installation in this series: "3 ways to put the ‘performance’ into your performance culture."

This blog is written by Dan Thurston, an agile strategy expert.