Why do strategic projects die and tactical projects live forever

In 2010, TinySpeck had a big idea for a game. A massively multiplayer game, similar to WarCraft, without the war, named Glitch. TinySpeck lived up to its name and only a handful of employees in different locations. The founder was hugely influenced by 90’s technology and used IRC as the primary mechanism for communication across the company. As they developed their groundbreaking game, TinySpeck continued to enhance, upgrade and replace IRC to cope with the demand of their growing company.

A screen capture of the game Glitch

A screen capture of the game Glitch

After 3 years of building the game, launching, and subsequently unlaunching the game, the founder, Stewart informed the investors that the game wasn’t viable. But he had, what he thought was a viable product that could be commercially successful, their IRC clone that named linefeed.

Linefeed was later rebranded as Slack. It was recently sold to Salesforce for 27.7 billion dollars.

This story is not unique and I have seen it play it in my career. I have seen so many strategic projects fail and have seen tactical projects succeed and refuse to die beyond their original expiry dates.

Looking at the characteristics of a strategic vs tactical project can shed some light:

Strategic

  • Strategy and governance structure prepared by a reputable consultancy

  • Lots of senior oversight and governance

  • Long requirements gathering process with sign-off which leads to even longer sign-off processes because people know they only get one chance before the dreaded change control process

  • With the large budget, come lots of new hiring and onboarding

  • A strong change control process

  • Big expectations and promises

  • Distributed and siloed teams with some matrix management thrown in for good measure

  • Politics between technology and change management

  • Architecture oversight

  • Strong project manager/program manager to hold it all together

  • A three-year deadline

Tactical

  • They start with a well-understood problem

  • Sense of urgency

  • Well understood problem

  • They use existing infrastructure or buy something out of the box

  • Built by a small team with a limited budget

  • Because it’s tactical, companies don’t spend a year building a future-proof architecture or gathering requirements. Both are done on a JBGE (Just barely good enough) basis

  • They fly under the radar

  • Three-to-six-month deadline

You could just as easly relable the left as Waterfall and the right as Agile and most bullet points will still be correct. The reality is that many “Agile” projects resemble the left more than the right these days. Perhaps we should stop doing Agile and only do Tactical :)

Crossing the chasm of Zoom

As I'm writing this, the vaccine is currently being distributed and it seems like life should start going back to normal by the summer. But for some companies, like Twitter, working from home will become the new normal. This post is for those companies that have embraced distributed work as the new normal. 

The current way most companies are working is anything but normal.

Matt Mullenweg, CEO of Automattic, created “Distributed Work: Five Stages of Autonomy”

I have simplified and modified it to:

0 Not possible. E.g. Fire fighting

1 Co-located first, with a distributed capability 

2 Distributed but synchronous (The chasm) 

3 From co-located first to distributed-first

4 Fully Asynchronous 

5 Outperforming

Most companies are stuck in the second stage, what I referred to as remote purgatory. Covid has forced us to stay at home, contending for space, and quiet with our family. We are still experiencing Zoom fatigue from all day calls. We have basically ported what we do in the office at home. We are constantly yelling, “Shushhh, I’m on an important call."  Companies are measuring the wrong thing(code commits) in the hopes of measuring productivity. 

Rather than adopt what we did at work to how we need to rethink how work is done at home from first principles. Here are some ideas Ideas for going from level 2 to 3 and start reaping the benefits of distributed work:

  1. Create space for long periods of deep work

  2. Meetings are the exception rather than the rule

  3. Replace output measures and oversight with trust and transparency

  4. Invest in the work from home experience

  5. Increase empathy and compassion

Create space for long periods of deep work.

Cal Newport describes deep work as:

“Professional activity performed in a state of distraction-free concentration that pushes your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.”

The goal should be that 50 to 80 percent of your time should be reserved for deep work and the rest should be meetings. It should give you pause if you find yourself questing what you will do with the free time?

Meetings are the exception rather than the rule

Meetings are on the default communication mechanism. Consider the opposite and create rules:

  • The Automattic rule: Meetings are only held if a similar outcome cannot be achieved over call, message, or email. 

  • Formal agenda must be posted ahead of time.

  • Meetings recorded to avoid FOMO.

  • Real-time documentation so that people can read the output.


Replace output measure and oversight with trust and transparency

Measure what matters: Outcomes(e.g. Features delivered to customers)  over output measures(number of commits). Many companies are tracking code commits to ensure the productivity of their workforces or hours logged into the system. 

People should not have to start at 9 am and 5. They should own their time so long as they are achieving the desired outcomes. 

Invest in the work from home experience

Companies are viewing allowing their staff to work from home as a cost-savings exercise. While there will be significant costs savings, be prepared to spend some of those savings on: 

  • Increase our travel budget so teams can get together twice at least twice a year

  • Better setup: tools, desk, seat, audio, and video

Increase empathy and compassion

It's hard to separate work and personal life when the home is also the office. Consider employees holistically, not just in their work roles. Avoid sending communications outside “official business hours”. If your new working time happens to be later, consider scheduling your emails to send during normal business hours to remove the expectation of working all the time

Write at the right time. Simply ‘getting it off your chest’ can seriously affect someone else’s schedule. There may not be a perfect time, but there's always a wrong time.

work-from-home.png

(un)manager

“(un)manager: someone who helps organizations meet/exceeds its goals through elevating people as opposed to elevating themselves. ”
— Me

My work over the past couple of years has largely focused on the manager class. This is due to the following two questions:

  1. What do managers do when teams are self-managing?

  2. Where do we source masters of scrum? Individuals who are capable of coaching teams, product owners, and the organization.

It has become increasingly clear that these two questions are interlinked. For this to work managers need to unlearn some of the very behaviors that have made them successful in the past. I propose managers and management become re-framed and a new set of behaviors adopted.

good and toxic behaviors.gif


The Magical Three Year Strategy

“Most people overestimate what they can do in one year, and underestimate what they can do in ten years”
— Bill Gates
  • How long does it take to replace an antiquated system that has been around for decades? 3 Years
  • How long does it take to build a strategic system that could leap frog the competition? 3 Years
  • How long does it to take to transform your organization to Agile? 3 years
  • How long does it take to do anything that requires large strategic investment? You guessed it, 3 years.

What gets presented is a Gantt chart that looks something like this:

Phase 1: Will be delivered 9 months after the money is secured and will deliver something called the "framework"

Phase 2: Will be delivered 6 months after Phase and will delivery the first valuable delivery

Phase 3 (where the magic happens): Will get delivered at the end of the three years and will deliver all the value

What actually happens:

Phase 1 gets continuously delayed until a senior manager threatens that heads will roll.  In order to meet said manager’s expectations, Phase 1 gets rebranded to Phase 1a and the scope is cut by 30 percent.

After 2 years, Phase 1a eventually gets delivered and drinks are had.

Discussions about how this is not working and about how to wrap it up nicely begin to replace other discussions.

One or two PM casualties later the project is shelved and another system remains to be decommissioned by another 3 year strategy.

I understand now why the answer is always three years. It looks great on a deck, and is neat and tidy. That's not what interests me. What I find fascinating is how intelligent, well-paid managers can sign-on to something they know is not possible over and over again.

Do people really believe it? Does it take three years to forget? I know the people presenting the three year strategy don't really believe it. So what is their motivation? Simple: They want the money. They are not going to get millions in investment if they tell the simple truth: it will probably take about a decade to do what we promise on page one of the deck. So they promise the impossible.

My assertion is that major banks are part of a system that is beholden to share price and providing shareholder value. CxO’s don’t have a long shelf life, 3-5 years. Their attention span is, understandably, 3 years. They are not going to sign-off on a very expensive program that will last longer than their perceived tenure.

Don't get me wrong, you can build lots of stuff in three years. It just takes far longer to realize the benefit, which is often the reason you start the project to begin with.

If your plan is to replace many systems with one system, or build a platform that will leap frog your competitors, chances are it will take at least twice as long as you have quoted on paper.

“The tyranny of the waterfall; The illusion command and control; The belief in magic; and The era of opacity.”
— Ken Schawaber discussing the four obstacles

If any of the above rings true to you, your project is doomed to fail before you begin, and your time is better spent tidying up your existing infrastructure.

Make it last...Toilet paper financing

Money is like toilet paper, if you have too much you will waste your resources and run out very quickly. Give a person an allowance of one roll of toilet paper and they will make sure they use their limited resources appropriately. Give them too much (e.g. 30 million in the first year) and they will waste it on cleaning up spills in the kitchen.

Give the team as much toilet paper as they need and no more. Down the line, they may have Mexican and need twice as much toilet paper. That’s fine. But the key is to make it last the 5-10 years that will be required to actually execute on the strategy.

You can also avoid the above by going "tactical"...

The Agile Mindset

During a retrospective with a client, we did an exercise called 5-whys to try and uncover the underlying reason behind the lack of focus on production. One enlightened developer provided a valuable piece of insight when he noted that we *may* still be in a “waterfall mind-set,” hence the lack of urgency.

This is natural after living under the tyranny of the waterfall deliveries for many decades.

Why does getting to production every sprint matter so much? Why won’t I just shut up about it?

In my experience, the greatest two barriers to a meaningful agile adoption are the waterfall mind-set and the belief that everything will magically come together at some point in the future.

Nothing has a more profound impact on changing the waterfall mind-set than actually getting to production at the end of every sprint. It will change the way you think and operate.

If the teams and the product owner do not insist on getting to PSPI (potentially shippable product increments) every sprint here is broadly what will happen. You basically end up with scrum-fall (scrum+waterfall) (devolopment sprints->line up environments-> integration test -> uat-> production). Estimates start to become meaningless as you will need an equally long time for the “release sprints”.

The net result will be a failure to deliver and ultimately blaming agile: e.g. “Agile does not work.” “We need to go back.” “If we stayed doing things the way were doing things, we would be live by now”.

As if to say that we delivered so wonderfully in the waterfall model.

But the product owner is not pushing for production

It is the job of everyone (feature team, scrum master, product owner). To date, the push to production has been coming from people outside these three groups. This should be discussed in PBR (product backlog refinement). The scrum master should keep the production tension alive. 

But there is no business value going to production every sprint

That is probably true during the first couple of sprints, but going to production every sprint will change the nature of PBR. The team/PO will start thinking about what useful things can be built to drive revenue. (e.g. if we do X can we start generating a subset of the revenue).


Nothing is getting done...

When agile/scrum is introduced into an organization one of the side effects is a perceived or real lack of urgency. I have seen this on a number of occasions, where teams seem to be losing the sense of urgency. Estimates feel too high, not enough "stuff" is getting built.

"enough of this hippy B.S., we need to crack the whip"

I want to share some of my observations regarding why this happens and some suggestions.

The traditional model of getting things done is referred to as the authoritarian model by Peter Senge (the 5th discipline). In this model, one person understands the problem and shoulders the sense of urgency and tells his “team” what to do. That person is the information bottleneck. He/she cracks the whip when he needs to be but many also reward a person for a job well done. The sense of urgency comes from the fear of this person and not from the “real problem. Let’s call this model, the Lewis model.

To a certain extent the Lewis model actually works and “stuff” will get delivered. Lewis will get rewarded. He works hard and shoulders most of the stress.  As a side effect of the stress and the whip cracking, few people want to work for Lewis.

Another model is one where the team feels and understands the problem. Rather than the sense of urgency stemming from the fear of a “person” it stems from understanding the real underlying problem or business opportunity. This will result far more creative solutions to the problem.  Teams working under this model will usually work harder/smarter than under the Lewis model. Let’s call this model the Harvey model. Everyone wants to work in this model.

A big part of the product team’s role is to translate the opportunity/problem to the team and protect the team from Lewis. The team in turn must seek to understand the problem/opportunity and deliver results.