Imagine you had a goal – perhaps to lose weight or to learn a skill, or even to build some capacity/capability as a person, team, company or country.
Lets call that goal ‘B’ and your starting point – now – is ‘A’.
The sharp angle path
Now imagine you did very little towards getting to ‘B’ until one day when ‘B’ stops being a nice-to-have and , instead, becomes a must-have. I call that day or the event triggering that realisation ‘a sharp turn event’.
So now you’re scrambling, stressing and enduring a massive disruption to everything so you can start heading towards ‘B’ and you needed to be there yesterday.
An example of a sharp turn event is cancer, a heart attack i.e it happens and to reduce the chances of it happening again or as severely – you start to eat better, exercise, cut out smoking and excessive drinking.
Other examples might be being mocked for being overweight or a global pandemic.
The arc path
Now imagine you are in exactly the same starting point and the goal remains unchanged. But instead of doing very little about getting to ‘B’, every day you did something tangible towards the goal and you kept the goal alive by checking if those things you did got you closer and adjusted as you went.
Sharp turn events are not entirely eradicated on this path, but their negative effects can be significantly reduced. You are already some way to the goal, you are on the path.
An example might losing your livelihood whilst pursuing a goal of saving for a home and choosing to live frugally whilst you were saving – being lean. Of course, it seems calamitous that you have lost your job – but given how you are living as you pursued the goal, you are in a better position to weather the disruption vs someone who lived extravagantly (even if they had the same goal as you!).
Arcs are softer but build habit and resilience.
Some thoughts on arcs and sharp angles…
Arcs require diligence and deliberate action to the goal – not huge steps, but small ones, consistently taken.
Sharp angle paths are easy – you don’t have to do anything but wish and occasionally lie to yourself and others that you are doing something.
The longer you leave a goal without working towards it, the sharper and more disruptive the turn. Sometimes, you can leave it too late you pass a point beyond which that exact goal is unattainable and you have to pick another that is within you then-current abilities. E.g. I want to buy a home in 2 years time. I need to save €50,000 for a deposit. The sooner I start the more likely I will be able to do it. If I leave it until, say, a month before I wanted to buy the home – I would have to find €50k in 1 month – an almost impossible task for most people not robbing banks. So maybe you now have to set a goal to buy a house in 5 years vs 2 or not buy at all.
Arcs require regular reflection and calibration that what you are doing is still valid towards the goal. You might even question if the goal is still valid.
Critically reviewing your goals can shine a light on what potential sharp turn events might happen. e.g. if my goal was to save €50k in 2 years, an obvious sharp turn event is that I could lose my job. That might lead me down the path of developing side gigs that build resilience to my finances.
In closing, I am no expert in this and I’m not selling any ‘improve your life’ crap. I am simply introspecting into events and paths in my life and things I see around me.
The coronavirus pandemic has shown us that many – if not all – countries have been fixated on either the wrong goals or have not acted in an arc way towards the right goals and we find ourselves in a sharp turn event where the world is mostly unprepared for massive unemployment coupled with a lack of digital tech for everything from government to education.
What are your thoughts on this theory? Please disagree with it and lets explore it further.
I’m terrible at focusing and single-flow discipline, so I tend to practice the Pomodoro technique – which is about enforced habit of working for short, concentrated bursts, taking a short breaks and longer breaks after a number of work bursts.
I love not being focused and everywhere – I get to be curious and explore, finding interesting things, people and relationships – but when I need to get stuff done, there’s nothing for it but to hunker down and FOCUS!
That’s when I am absolutely grateful for a fantastic little app called Pomodone App.
At it’s heart is a timer that works based on the Pomodoro technique.
Projects I’m working on, daily tasks, can be sourced and sync with a range of tools – from Trello to Evernote, Asana and more.
Three Reasons I love Pomodone App
#1: It is easy as pie
Right out of the box, it is set up to have a work cycle and cycles that follow the textbook technique.
I changed mine to 45 minute long pomodoros (basically the period you are focused on workd) and 5 minute breaks, with a longer 30 minute break after my 4th pomodoro.
You create your tasks (in my case, I get my tasks from Trello, more on this in the integrations bit). I also, occasionally, create local ones. Wherever you get your tasks from they are easily selectable to start working on.
#2: Notifications range from nice to naggy
You can set the reminder interval, when the clock isn’t ticking. To be honest the regular reminder really pulls me back from the weeds and helps me refocus on my list.
I used to have the reminders every 90 minutes and that was nice, but I found that I could get lost in other things – emails, chat, browsing and 90 minutes is a big chunk of time. So I set it 15. Now it is proper naggy!
Annoying as it might get – I don’t want to be timed all the time, so better the irritation than 2 hours going ‘poof’ on containerisation or AI or some other interest that is not immediately relevant to my delivery goal.
#3: It integrates with my work flow – perfectly
I use StoriesOnboard – and online tool for user story mapping, which I use for big picture business /strategic planning and Trello for more operational stuff.
Recently we started using Sentry to log any errors that happen on Decksender.com. Really cool that Sentry lets you create Trello cards for things that need resolution.
At my desk, all my tasks primarily from Trello and Pomodone App integrates just beautifully with that. When I start a task, it automatically moves it to the right ‘Doing’ list on Trello, recording on the card how much time has been spent on it and finally we when I’m done – it moves it to ‘Done’.
Now, I’m not ninja-level at managing my focus – where is the fun in that – but every now an again, the right mix of tools come round that really hit the sweet spot and PomodoneApp is the core of that sweet suite!
Try it out and let me know how you get on, happy to answer any questions I can and even learn from how you use it.
Full Disclosure: I’m not paid or receive any payment or benefits for writing.
I was recently in a dialogue with a client and the conversation turned to “Evil Scrum” and some previous negative experiences that some people had experienced.
They imposed velocity targets and demanded estimates a year in advance and then bashed people when those forecasts weren’t met
Now, I’m no big fan of Scrum or Kanban in the same way I’m no fan of the Catholic Church or any religious organisation. It’s not the tool that I object to per se – it is the commercial agenda and what it makes otherwise nice people do in order to profit from the tool.
However, I am deeply knowledgeable about Scrum and Kanban and the agile manifesto that broadly underpin the credentials of both as better ways to handle complex adaptive systems and work.
My response to the client group was this:
Even a bluebell could be used by a bully to bludgeon you to death.
Neither of these process frameworks advocate any kind of violence to anyone. But they provide the hooks by which the brutish minded can exact violence on some people.
There was consensus in the room that this misuse of process and power e.g. Evil Scrum (could as well be Evil Kanban / SAFe / LeSS / whatever – was often worse than no process.
So my assertion is that those who get what they want through bullying others will try it with whatever tool they can find. From process, to working conditions and contracts to , yes, even bluebells.
Looking at the current landscape of tech giants, from Facebook to Google, from Stripe to Intel, it is almost impossible to imagine they can ever be out-spent or out-competed.-
Whilst they might seem unstoppable – with the sheer brain power they employ and the almost bottomless stash of cash they command, it is reassuring that every giant has its weaknesses.
Some weaknesses might be transient – momentary lapses of attention, or wrong footed by some government legislation or mishandle a sensitive public issue and start to lose patronage. Others might be systemic – by virtue of their size, their industry, regulatory constraints, their leadership failings or something more permanent.
For those wishing to find the kink and exploit it – they should be prepared to move as fast as they possibly can. They need to cultivate now, the ability to make decisions very quickly, to execute spectacularly fast and to maximise the natural love that the market has for upstarts and underdog to their advantage.
What kinks in iron of the giants have you spotted? What should the upstarts and underdogs watch for?
We are working on an experimental mobile based social photography app called Snaptime and we have an ambitious plan to have it on the various app stores by the 1st of February so that people can start to play with it and help us learn what it does [and should do] for them.
8 hours to try and resolve Plan A
But today we got word from our cloud provider – Digital Ocean -that our server had been sending data out at an alarming rate. For the non-techie a cloud provider doesn’t provide fluffy clusters of water vapour in the sky, they provide computers you can access via the internet that are really quick to set up. Anyway, we use this Digital Ocean – for my other startup Amazemeet. We imagined (or used to) they were our partner in running a reliable service and when some kind of emergency happened, that they would be right with us, working to resolve it.
Well, it turns out this ‘alarming rate’ was 35 million packets of data in a very short time – approximately 18 minutes. That’s more than 220 megabytes of data in a 18 minutes. Their systems detected this and locked down our server and disabled the network connections so the flooding could be contained. They also locked the account.
They both entitled and entirely correct in taking this course of action.
Then they emailed us and asked us to investigate and then explain to them what happened and then they would investigate and consider whether to switch it back on.
Well – so we did – as much as their lock down would allow. Which is not very much – and my 2 emails to them in 8 hours to get assistance went unanswered.
Meanwhile the development is at a standstill. But not for long.
10 minutes to switch to Plan B
Fortunately I keep a backup provider – Vultr.com – for just these kind of situations and the turnaround time to get a new server, set it up and be back online is frankly hard to imagine possible even 5 years ago.
After 8 hours of getting nowhere, I tired of Digital Ocean’s lack of cooperation in this matter – which lets face it is simply a cheap lesson in picking hosting providers – and made the decision to bring the service back up, things happened rather quickly.
I emailed Digital Ocean to tell them since there seemed to be an impasse and frankly radio silence from them, I had no other choice but to destroy the server (so I didn’t continue to pay for it) . Even to destroy it proved impossible until they removed the lock – which they did on request. In fact – they replied faster to me deleting my server and initiating my plan to move all my services away from Digital Ocean than they did to my requests for assistance. I think that is a poor business decision.
It took me less than 10 minutes to get a new server on Vultr.com, change my Cloudflare settings to point to a new IP address and now my developer is going to take anywhere from 30 minutes to 2 hours to put all the software we need back on it and bring it back to full strength.
Mike Gets Philosophical
I have a saying I recite to myself when things don’t go the way I expect them to – “Don’t get angry, get philosophical”.
Given that we have growing subscribers on Amazemeet who are increasingly relying on our service to be robust and reliable. I consider the relatively unimportant downtime on Snaptime as a dress rehearsal for what the experience of the extent of Digital Ocean’s willingness to help me overcome a revenue impacting service. So this was a cheap lesson of an important subject and for that I am a grateful student.
Downtime in the Age of Cloud Computing means that provisioning metal (thats system administrator speak for getting servers setup) is now a fairly simple, quick and inexpensive task. It also means that with the technical complexity resolved, the battle ground for providers is in customer service and recovery partnership.
In this regard I’m disappointed to say Digital Ocean has let me down. I did like them – or my impression of them – young upstarts daring to grab a sandwich from Amazon’s unconquerable AWS service. The underdogs, the cool kids doing cool things for other cool kids. But alas that is not really the case, from this experience my impression is they really couldn’t give a cockroach’s wotsits about my predicament.
But heigh ho – I simply hop on another cloud and carry on my merry way. Lesson learnt, achievement unlocked for fastest Plan B ever.
Web Summit was a major experience. There were a lot of people – the organisers claim 42,000 people were in attendance – and it felt it.
If you aren’t a people person don’t go.
If you are exhibiting, go to a busy vegetable market or car boot sale a few weeks in advance and learn to engage and trade. Otherwise you are wasting your time.
This is exactly what it’s like.
I personally consider The Alpha track to have been great value. Even after flights and accommodation, it worked out at about €800 per person. We made leads, tested product fit of the app with a wider audience and made some really great contacts.
On the other hand, it is blatantly obvious that profit is a major thing for the organisers – pay very little out, bring as much as you possibly can in. Even if that means screwing people over. The debacle of the food tokens demonstrates this perfectly.
There were some really cool exhibitors and some speakers – I tried to see all the exhibitors but only 3 really sparked my interest. There seemed to be a multitude of people doing things that were not really solving a problem or solving a known problem differently.
If you were attracted by the quality of the ‘celebrities’ and the possibility of rubbing shoulders with successful and influential peeps – you would be out of luck – they were there but not mixing and as my speaker friend said ‘oh they are all in there, but no one is coming out – there is food there and its not so crowded’. I don’t really blame them.
The WIFI also classically sucked. Given the much reported problem from last year’s event, you would have expected such focus on getting that bit right. I met at least 10 alpha track cohorts negatively affected by this. Such a lack of attention to detail on a sensitive issue speaks volumes to my earlier point about profiteering. We even joked there was a lot of ‘summit’ but not enough ‘web’.
Ultimately the organisers are awesome at what they do – marketing, data mining and building their business – whatever you as the attendee or exhibitor gets seems accidental. They deserve alot of respect for that alone.
I personally got very little value from the talks – with such a huge range of people, I can appreciate the speakers easily going for the lowest common denominator level to pitch their talks.
So, Web Summit – it is like the Eiffel Tower. You only really need to see it once. We won’t be going back.
The long bit is coming in another post. Too busy, can’t complete.
I just watched the entire Daredevil season 1 on Netflix in 3 days.
Prior to that I watched the entire Arrow series in 4 days.
And Agents of Shield? I polished that off in 2 days.
Before Netflix – I got into the Sopranos box set – that was a killer.
Earlier today, my 6 year old son and I explored the idea of being able to watch episodes of a series whenever you wanted and I explained how different his experience was to mine when I was his age – 35 years ago.
When I was a kid, you watched an episode of something a week – at the predetermined time. When video recorders came up, you could choose to record a series but had to do that weekly at the predetermined time. You could only watch the entire series after it had been aired.
Then came boxsets. Boxsets moved things on a bit. You could watch entire seasons that had aired a few years to a few months ago. But the interval based episode format was still the same.
Netflix disrupts this format by making both syndicated and original content available in episodes but without the interval – you don’t have to wait at all to watch episodes in a season and only a short time for new seasons. I don’t know whether they are following the trend of the ‘NOW’ generation or leading it. Actually I don’t care.
What I care about is the content – specifically how stories are told. Three hours of a series of episodes is theatrically different from a three hour movie. Even my 6 year old – Ruben – understands this. Things developed to be consumed in intervals must build in enough hooks to keep you coming back every week to see how it unfolds. So there needs to be drama, thrill and suspense – all key emotional manipulators – in each episode – to trigger anticipation. Over the course of a week, perhaps our human system can handle such manipulation, but when you binge – as I and millions of others do – what damage does that cause to our emotional and sensory systems?
To a large extent we have the same experience with franchises like Lord of the Rings and Avengers. The interval is longer between episodes and each episode is itself a longer show. But collapse the intervals and watch them back to back and you are in danger of seriously messing with your mind and possibly your perception of reality.
I’m sure Netflix and others – Amazon etc – argue this is disruption in format is about choice and in part I agree. However, I am curious to understand whether that choice is both real and actionable when the content is designed to hook.
Do you watch Netflix or binge on boxsets – how does it affect you?
It has always amused me when people – usually men – say their company or team ‘eats their own dog food’. It has always struck me as a very ‘macho’ thing to say.
I’ve searched for the origin of the phrase ‘ eat your own dog food’ – there seems to be a couple of places it could have come from, but its wide spread technology industry usage dates back to 1988 in Microsoft.
Of course the point of ‘eating your own dog food’ is to demonstrate that you have confidence in your own product and can learn – and improve – from your own internal use of it.
Before I continue – let me say that I think when done correctly, using your commercial product internally can be a very powerful learning and empathy building experience.
Here are some things to consider before ‘eating your own dog food’.
Is making dog food mandatory likely to increase joyful adoption or encourage resentful compliance?
A couple of places I have seen have made ‘dog food’ mandatory. Usually the order comes from the top by someone concerned that the product has quality or user experience problems.
In my experience – how people work and the tools they use should not be made mandatory or imposed in any way. If the product solves a problem that the user has, then they’ll use it. If it doesn’t – that itself is some valuable learning. If it has to be forced then the data you get from the dog food experience may not be authentic.
Understand the risks to your business
You might argue that if your product brings a business to its knees, you would be better off experiencing that yourself first. Or not.
As much as you might not realise it – your company knows more about how your product works – or should work – than your customers. This insider information is hard to ignore.
So invariably, the product as used internally does not often cause the same effects as when used by your customers. Or if they cause the same effects – the knowledge your employees have masks the perception of the effects in a way that your customers’ users don’t.
For example – I had one customer who made security scanning software – the stuff that sits on your machine and scan files and access. Their CTO encouraged their teams to ‘eat their own dog food’ with some dire results.
Given the nature of the work they were doing, the software completely crippled any kind of software development on the employee’s machines. The order remained, except the developers – choosing to do work rather than remain frustrated – tampered with the configuration by effectively disabling it.
Not all dogs are the same – be clear which dog you are.
Sure you might be selling an email client – and you think everyone uses email the same as you do. Before you unleash dog food on your employees – make sure you know what kind of dog you are purporting to be.
Are you a small enterprise simply using email for inter company communications or are you a marketing agency for whom email is an art form? Knowing what kind of customer your company is, will help you exercise your product more comprehensively.
Also knowing what kind of user you are not reminds you not to have false faith in dog food – it is only as good as it is used. If you never exercise some parts of your product internally, you aren’t getting the early warning of how real customers might be using it.
How will you deal with what you find?
At a higher level – dog food is about feedback. Specifically getting real world usage feedback on your product from internal users.
The big question is – what are you prepared to do about it when you get it and how quickly will you do it?
This is perhaps the biggest problem I see when folk use their own products internally. More often than not, the internal users have no way of getting the broken things fixed quickly – so they continue to endure it.
Where I have seen it work well – the feedback from internal users is treated as an express lane item – because it comes earlier than feedback from external users (who typically are not on the latest versions anyway). By ‘express lane’ I mean, the triage and categorization of the feedback – i.e. urgent bug, enhancement etc – happens very quickly. Repair/remediation also happens very quickly – depending on the stack – the same day.
I’d like to share 3 handy checklists items before you commit your company to eating dog food:
Will this critically affect our ability to run our business?
Which customer usage do we represent?
Are we prepared to respond quickly to what this experience will reveal?
I’m having a wonderful time being helpful on SoHelpful.me.
So many different people – with amazing stories – reaching out to and trusting a complete stranger to help them via experience, learning and a diverse perspective.
Recently I met with Greg – a super smart engineer with a really interesting invention who sought to understand how to turn customer interviews into an investment pitch. After a few minutes of conversation and hearing about where he is at with his startup work, I concluded that he has a different and more pressing problem.
He has a solution looking for a problem.
If you use Lean Startup or Steve Blank’s Customer Development approach, you’ll probably be doing it the other way round.
With Customer Development , we find and validate a problem that people have and try and solve it for them. It is a very successful strategy that delivers learning, risk reduction and human connection in a neat little package. But that is not the only way to build a startup. Sometimes – especially if you are a maker – you go ahead and make something and then try and figure out who might use it.
Solutions are always from a problem
I can’t think of anything that is devised as a solution that wasn’t problem driven. It might be a problem you have or one that is well publicised that many people have. It might be real or imagined. The problem might exist today or might be a logical future result of how things are evolving in the present. But solutions mostly always stem from a problem.
What we do in Lean Startup and Customer Development is – through experiments – tests the assumptions we make about the problems.
Work backwards, look for assumptions
As the conversation progressed with Greg, it was clear to both of us that he had built something for his own very specific problem and was now trying to sell it to the wider world. Almost all of the interviews he had were about markets and how to access them. Almost none were about a problem someone had. Even in established markets where you think you have a Unique Selling Point – USP – you are better off validating that your USP is both unique and a selling point – with actual people.
So to help Greg understand his situation better, I asked him to tell me how he thought his product might be used. This is a great technique – tell a story of who uses and how they might use it.
Well, the person that uses this might have a need for this much output and they may want to use that much storage and my product gives them that flexibility
Stop. Rewind. We just found three assumptions.
“They might need this much output”,
“They might need that much storage” and
They value the flexibility.
This gives Greg something to start better customer development – he can take a few steps back and design experiments to test those assumptions.
As he designs his experiment, he can explore where to find people who use similar products or are trying to address the problem but with similar products. Once he’s found them, he can start conversations with them – not about his product – but about his understanding of the problem. Those conversations will inevitably lead to other learning and new assumptions and we continue doing experiments until we have enough validated information to do the next thing.
The moral of the story is…
The fact that you have a product does not mean it is marketable. It means you got over enthusiastic and built something that was scratching your own itch – nothing wrong with that – or you simply wanted to do something fun and interesting – definitely nothing wrong with that!
But reality check yourself. Sure it was fun and it probably was perfect for your problem but unless you establish product-market fit, it is almost certainly not marketable as it stands.
A really straightforward way to determine product-market fit is to turn it into a problem-solution question. Once you positively answer this question with actual data, then the next thing is to determine whether the problem is perceived enough to have people pay money for the solution. Then you have a marketable product. Then you can go try and seek investment and all the other things the cool kids do.
Are you stuck with your startup? Do you have a product that you are struggling to find market fit for? I don’t have any answers, just a difference set of experiences and perspectives through which we might together find answers in. Check me out on http://sohelpful.me/mikesutton and lets get a conversation started.
With the experiment now complete, here are some conclusions I can draw both from qualitative feedback from doing the experiment and quantitative feedback from surveys conducted during the experiment.
Always face to face before going remote. Always!
I had two groups that I met with and worked with, face to face, for 2 days as a kickstart to the experiment. During this time I made the invitation as sincerely as I possibly could, reinforcing it regularly during the workshops in my actions and through my language.
This facetime was essential in creating the bridges through which future collaboration. People had online conversations with a friendly personality they knew by name and sight and someone they had laughed with and exchanged stories with vs simply a voice on the end of the phone.
The third group did not have the facetime, we simply spent 2-3 hours online using tools to create the improvement lists and to make the invitation. Whilst this may have generated the same outputs – stuff to improve – I don’t think it we ended with the same outcomes – great rapport and bridges. This third group whilst still somewhat engaged, lost interest very quickly and had fewer collaborative sessions with me and with each other. I also got quantitative feedback that this group would have preferred a face to face workshop at the start.
Remote work tools generally suck
I tried to keep tools to a minimum. Mostly we used google docs and Trello for online collaboration. For communications I tried lots of different tools – iMeet, Skype, GotoMeeting and Google hangouts.
Each tool had its benefits and drawbacks, but the take-away for me is that anything that travels on the interweb is going to be slow and unpredictable at various times. So I need backups and alternatives.
Most effective for me, was not the tech but the design of the sessions. The secret for me was to have shorter sessions with fewer people and to use video sparingly, maximise visual collaboration – ex: google docs to draw vs speak.
Buzzwords like “Agile”, “Scrum” are turn offs
From the very first improvement workshop – it was clear to me that people lost interest in the conversation when we talked on Scrum, Kanban and even Agile. The conversation suddenly stopped being about them – the people and their needs – but about the tools.
Everyone had some opinion why ‘technique A’ wouldn’t work. Different ‘truths’ about how these techniques work and experiences of ‘how’ they work.
At the risk of introducing yet another over-used word, I tried to steer the groups away from dwelling too much on techniques, but focus instead on outcomes and on some fundamental truths.
Keep the focus on effectiveness
Overwhelmingly across all the groups, ‘effectiveness’ was the key word that everyone could get their head round. It wasn’t divisive – even if we didn’t define it explicitly, everyone had a similar understanding that it was about making things better.
I helped by offering my perspective on 4 elements of ‘effectiveness’: Value – what we are building/doing, Flow – how smoothly are we building/doing it , Quality – how suitable for purpose it is and how easily are we able to keep doing it and, finally, Joy – how do we each feel doing what we are doing. (Major hat tip to Emergn and Joshua Arnold for their invaluable work on Value, Flow and Quality – VFQ). I invited everyone to consider effectiveness to be these 4 elements in balance; or the first 3 at levels that keep the 4th – joy – high and trending higher.
Most people – more than 80% of all participants – understood and agreed with this simple perspective on effectiveness.
Improvements take time and persistence
Without a doubt, the energy of the workshops and the enthusiasm for improvement was really high at the end of the workshops with all the groups. I believe the openness of the invitation helped the participants give the whole thing the benefit of the doubt and participate more fully. I was really impressed, yet concerned.
I worried about how could we transfer this energy into the work to continue the improvements when people got back into their ‘day jobs’. I was concerned because I thought it would be difficult and undesirable for a single individual to sustain work on any improvement item, so I suggested that groups of between 3 and 5 form around each of the most popular improvement items that we dot voted on and prioritised by the number of votes.
Yet, despite the groups forming, the improvement work – even just meeting to explore questions that could yield greater understanding – still took time to get off the ground. In one case we didn’t even get to have the weekly reviews until the very last one, where it then turned out that there had been a lot of activity that had happened to move the improvements forward!
Persistence is hugely important – at one point, only two out of the five members of one working group turned up to have their conversation. I was so glad they persisted – because what they discovered helped attract greater interest in that improvement and more people joined later.
There is a need!
In my experiment, I worked with over 80 people in total – some more closely than others. Most had experienced some kind of ‘injection’ consultancy and most had generally a negative view of this model of consultants coming in – usually to coach or work with a team in Scrum/Kanban or something packaged – disrupting how people are working and then leaving after a few weeks or months. Most often, people shared that they just went back to how they worked – a bit more disillusioned.
The management in the various groups also generally felt they got less valuable outcomes from these engagements for the amount of money and time invested and disruption that everyone endured.
Almost universally, participants welcomed help and support to help them to focus on their improvements and explore different ideas and experiences to help them work on the items.
I believe there is a need because of a fundamental problem that many organisations have. Here are what I believe are the crux of the problem:
There are always things to be improved and some of them are critical.
Each group averaged 26-35 things they would like to improve. Some of these were pretty big things – like ‘getting more customers’ and ‘feeling more appreciated for my work’.
Improvements take time and effort.
During the experiment, most of what people shared were symptoms and therefore needed deeper exploration to understand, diagnose and find solutions for. It took time to get people together, time to explore the questions and sift through data. Most of this time was ‘stolen’ from the other time that people are normally busy.
There is a general lack of facilitation skills in companies.
The biggest discovery for me – a huge proponent of self organisation – was that empowerment with permission is not enough for people to self organise. To do it effectively and to enjoy it requires supporting that empowerment with facilitation skills. If self organisation means everyone having pointless meetings that go on and on with no measurable outcome, then it is little wonder that groups would rather be told what to do than be more autonomous. My belief now is that everyone should have basic facilitation skills as a fundamental requirement to work with others. Basic techniques to get a group together with clearly articulated purpose, a framework to explore the purpose and means to converge the conversation into summaries, clear next steps and action.
The people who can best explore the problems that need improvement are hardly ever invited to do so.
This is perhaps one of the biggest aspects of the problem that I observed. The experiment was based entirely on making an invitation -a request – for which there were no consequences for not accepting. Even with the invitation made, I got regular feedback about the fear of it not being genuine or genuinely supported by management. I found myself having to reiterate and reinforce the open-heartedness of the invitation often.
The core need that I identified and validated is that people involved in the improvement work need help, access to expertise and support at a pace that suits them. Most importantly, I discovered that there is a distinction to the way the help must be presented – friendly, empathic partnership is preferable to pushing knowledge or being an aloof teacher/trainer/’guru’.
What Next?
So, I have data, many mostly satisfied experiment participants, plenty of learning, great ideas and some validated conclusions. What next?
I am working on finalising the details of a new service to meet this need that I have identified and validated and I will be sharing it soon. I would really love your input when I have something to share.
If you would like to learn more about the smaller details of the experiment or are thinking of running something similar, consider booking a free slot on my new soHelpfulMe page and I would happily spill the beans about how it worked, the gotchas, what I would do differently and even share some of the feedback – anonymously , of course.
For all other comments – please use the commenting system or tweet me @mhsutton. Please consider sharing this post. Thanks.
