Is a strategy really needed?

I have heard a lot of individuals and teams saying that:

– I don’t have time to execute what is in the strategy because I am stuck with my operational or daily to daily work.

Well, in that case, there are only two options, either your strategy is sh*t or you are not doing whats in the strategy.

Another interesting comment or idea has been:

– Are we not suppose to be an “agile” company, do we really need a long-term strategy then?

I could agree to some extent, but I see more benefits having a strategy then not having one. Will explain why more in detail later on in the article.

But of course, you could do it the Elon Musk way, as with Tesla, just to have a mission “to accelerate the advent of sustainable transport by bringing compelling mass market electric cars to market as soon as possible”. He had also his “secret master plan” that contains this simple but effective roadmap:

  • Build sports car
  • Use that money to build an affordable car
  • Use that money to build an even more affordable car
  • While doing above, also provide zero emission electric power generation options

So what is really what?

Understanding how to place things like vision, mission, strategy, roadmap, priorities, initiatives and so on in between each other is not easy and googling on this topic you will find all kind of answers on how to organize and create hierarchies with different levels of granularity. And since there is not one single truth to this, I will try to convey my way of organizing this levels.

I know that might be a bit controversial to say, but don’t care if you have a vision or mission at the top. They are more or less the same, and they target the same long-term time frame, which usually is a couple of years and can usually not be achieved within a year or so.

Where on the opposite a strategy can be or should be achieved within a year. The strategy itself is just a place-holder or container for a handful of priorities, which should be a clear statement through which you can accomplish your vision or mission.

These priorities have preferably some kind of output indicator that measures value contribution, and the priorities should not be completable just as a KPI is not.

Each priority has also a handful of initiatives, which in return should be concrete and measurable actions that contribute to the priority and that its “moving its needle”.

If you then were to look solely on the initiatives, they could be seen as a roadmap, giving it further granularity, if needed, with adding dates, also seen sometimes as milestones.

Connecting this back to Elon’s “secret master plan”, you could argue that the master plan as such actually is a roadmap containing milestones without dates.

Cutting the cake

The larger an organization gets, the harder it is to align and keep everyone working towards the same end goal, independently of which terminology you use.

Does that mean that it is harder to be agile when growing?

I think that the question to that is, yes. And this is such an interesting topic, that I will write more about this in the future. In the meantime, you will have to find your own way of where and how to “cut the cake”.

But I can say this to the second comment above, about being an “agile” company, priorities should have stability over the year, but the initiatives should be flexible to adding new, change, updating or cancellation. Which in my eyes means that we are agile, enough.

So coming to the importance of having a strategy and why I see that there are reasons why a strategy is needed:

Creating alignment

Just like doing estimations with, for example, poker planning, we are forced to externalize our thoughts and ideas when there are discrepancies, which in the long run don’t only create a sense of participation and motivation but more important is that it creates alignment in between the participants and then also in the long-run, the organization, if communicated correctly.

Giving a direction of movement

When standing in front of a decision to be made, you should be at any given moment of time, be able to look at your strategy, and if the decision is aligning with your strategy and its priorities, should be an easy decision to make.

The strategy and its priorities could then be seen as a cheat sheet for decision making, which gives you a clear direction of movement.

Enabling innovation 

If knowing where and what your priorities are, they could easily give you an indication of where you should target your innovation, which then automatically should also enable your innovation.

Always important to remember is that innovation should never be focused only on the product or service that you are delivering, but instead also take into consideration your business model according to Alexander Osterwalder and as Eric Ries said, getting “out of the building” to test it.


If you are following the three first steps, you will automatically be given focus and which will help with planning and decision making both in the short and long-term perspective.

Follow up

The hardest thing with a strategy is not to create it, but to execute it. Therefore lies success of execution with the follow-up.

Just as with a new feature that you think will be a game-changer for your product or service, your strategies priorities or initiatives might not be what you thought they were, so you must be pragmatic and have courage enough to “kill your babies”.

So how do you know if your initiatives or priorities are successful then?

The key is to have KPI’s connected to the priorities, and to have success criteria connected to the initiatives preferably also with targets, connected to the presumed improvement of the KPI.

A common problem is to find a KPI that is affected as little as possible by other things then just your specific initiative, if not, it can lead to false success or failure.

Remeber, all initiatives, success criteria, and targets are all more or less qualified guesses or hypothesis. This is why an agile mindset is important to have when doing the execution and follow up.

Truth be told, not everyone needs a full-blown strategy, but instead should only have a roadmap or kanban-system to manage ad-hoc request.

Hope my ideas gave you some inspiration, but it’s all up to you to decide, where and when to use what.


Follow me on LinkedIn.

Follow me on Twitter.

Follow me on Medium.

Minimum Viable Sprint – a One Week Hackathon

A couple weeks ago we did an experiment, that was super successful.

We tried something that we have never done before, a one-week hackathon with daily sprints.

This is the perfect extension of doing a Google inspired Sprint.

Do you want to read the full story, check it out at our blog.

The agile triangle

I have seen and heard a lot of discussions regarding whether Agile-frameworks like SAFe, LeSS, DAD, Enterprise Scrum, etc is agile or not.

Some parts of the agile community tend to be very anal in their perception of these frameworks.

My interpretation of these peoples thoughts, is that they see the agile world almost like the traditional and terrible cost-time-scope triangle, but replacing it with a people-culture-<insert framework here> triangle.

And then saying that you can’t have a constant in that triangle, like the <framework>.

You should of course not see or refer to the frameworks as a constant, more as a good idea on how to do, or a smart quick-start with an out-of-the-box solution.

But of course, as Peter Drucker once famously said:

“Culture eats strategy for breakfast”

Learning and understanding the principles and core values of lean and agile, is of essence in an lean-agile implementation/transition.

A framework is not a silver bullet in any sense, or as my good friend and colleague Andreas Rowell once said:

“It is all about the context, context and context. There are no such thing as best practices – practices are good or bad depending on the context. Experience tells the difference.”

I agree that no framework in the the world will make you agile or lean, but they might give you a pretty good platform to evolve from.

Scrap your PMO?

There will be many line and project managers who are not happy with me saying that you should scrap your project management office (PMO), but please just hear me out.

When I worked at a major truck manufacturer in Södertälje, a very senior R&D manager said something like:

“The PMO is unnecessary, let the functional organization do what they know best instead”

I was at this time working as an independent consultant at this PMO, and was as usually the youngest project manager among my peers.

Me and some of my colleagues at the PMO obviously thought what he said was nonsense and that he spoke in his nightcap, not understanding the benefits of having use there. Reasoning together and coming to the conclusion that “nothing” would work without us.

Now a few years later when I am a little bit more experienced, loaded with new insights and have jumped off my high horse, I am willing to agree with the senior managers words.

A PMO often tries to dictate command and control, and instead of being proactive we always seemed to be one step behind. With the typical symptom of constantly updating our plans and asking steering committees for added funding or postponed start of production dates.

Don’t get me wrong, we did some great stuff as well, like planning exercises very much alike the Big Room planning of the Scaled Agile Framework, but instead of doing it for smaller increments we did them for a whole project, spanning a couple of years, thus making them very hard to grasp.

My interpretation of what the senior manager really meant was that we should let the development organization focus on the creation of real customer value and not make them attend to meaningless meetings and create status reports among other things.

Value itself should come from discussions with the an empowered and strong product management team.

Reading this you won’t make you scrap your PMO and you probably shouldn’t either.

But what I think you should do as line or project manager, is try to act as a servant leader and help to remove the impediments that limits the communication between product management and development teams.

But also to help them to decrease the size of increments, limit the number of projects in progress and embrace change both in scope and in workflow.

Do you agree?

Thoughts about responsibility

Way of working and personal development is important to everybody.

As a scrum master or project manager, is it not needed to have wast rules with your development or scrum team. In your effort to to increase productivity, do not tell them what or how to do. Instead respect them as independent sentient beings, who have the where with all to make conscious decisions for them selves, embrace and encourage that.

So I propose an agile mindset and not to bury yourself in the toll gate or strict scrum trenches.

So when you are in a context that has limitations like, code debt, other departments wow’s or legislation, I don’t tell them:

“You can’t do it like that!”

Instead I say:

“Have a great time and make the best possible choice for you”

But that doesn’t mean that they always make the best choices, but you are then empowering them and they continuously learn about what works and not.

I mean, waste is bad, but not learning is worse, and we probably have a long road ahead together, right?

So its all about getting your team to think consciously about their own choices; to become informed, educated and prepared. So that they are responsible stewardess of their product/system and company, and are responsible stewardess of their own roles and development.