Read on Twitter
Some time ago I outlined in #conceptinatweet the Bimodal Gartner model. Today I would like to share a thread on its consequent key ideas and dive more into details as lately I consciously apply those ideas in my work a lot. https://twitter.com/nhndclppng/status/1367055398071582722
Almost everything in the thread is based on ideas developed and shared by Natalia Babaeva in her Telegram channel https://t.me/changemarketing , her course "Change basics" https://basics.changerschool.ru/ and promoted by her school. If you're speaking Russian, I encourage you to check it out.
Gartner refers to two different styles as Mode 1 and Mode 2. I prefer to use the terms "run" and "change" respectively as they are easier to distinguish in the texts. I will omit quotes further. https://www.gartner.com/en/information-technology/glossary/bimodal
Let's start with the basic truth.
To be a good changer, you need to understand run. To be a good runner, you need to understand change. Change and run are the stages of the one big machine, one process, they are interconnected. Understanding will improve outcomes.
To be a good changer, you need to understand run. To be a good runner, you need to understand change. Change and run are the stages of the one big machine, one process, they are interconnected. Understanding will improve outcomes.
Nevertheless change and run need different work conditions, basic rules, approaches, results, quality, and progress evaluation (not the full list). Avoid mixing up, it will save you from biases.
There is a portion of run in change and vice-versa. But the proportion is different. Example: running a launched product with a known backlog and product vision is closer to run; figuring out what new product to launch is closer to change.
There can be a lot of change in a seemingly run company. There will be a lot of run in a change company, but it will be mainly on a process level.
Run is always more effective in the short term, it's in its core. But without change, you won't evolve and eventually will die in a long term.
For changers quality is uniqueness, for runners quality is precision.
Doing run and change at the same time is hard. They need different modes of thinking and switching back and forth is not what most people do well. But if you need or want to try at least put them on big separate time blocks in days.
Good changer leads change until a stable run stage.
To make time for the change try to optimize the run, it should strive to be compact. How? Visualize, analyze, template, compose checklists, pre-pack.
First decide on product limitations or desired results, set deadlines, and plan backwards. It will force you to make your plans more realistic and cut unnecessary things.
Write out the definition of done and communicate it among others. It should not be a step-by-step instruction, leave some space to cut the corners or you won't have any instruments to be in time for the deadline.
To focus on results, visualize your progress. There're a ton of instruments, starting from physical boards and stickers up to task trackers, weekly demos, and, obviously, launched products.
In the change you don't have ready-to-go answers. Your job is to find those answers.
Add dreamability to the usual set of components of your design-thinking (desirability, viability, feasibility). Ask yourself what really drives you and motivates you.
Focus on problems, don't through in solutions and start doing them immediately. Try to understand the problem to its very root.
Make your ideas shared in order for others to correct them and enrich them. Change is a team game. Ideas in a team are shared property.
In the change you always don't have enough certainty for planning. To feel progress work in iterations and focus on results of those.
Agile in its true form is more suitable for change. Small self-organized team together checking hypotheses one by one as fast as possible.
For the change it is normal to fail a bit every day, successful change works on a bigger scale. A lot of small failed experiments for big achievements as a whole result.
Changer always changes the scale. You will zoom in and zoom out constantly.
Before scaling check if it's possible and if everybody sees it in the same way.
Always analyze the results of the project or iteration. It's the only instrument to make you grow and avoid stagnation.
Keep in mind that every metric should give us an answer or an insight. Make it useful or make it dead.
Limit your work in progress. It applies to every level of work: products, projects, tasks.
Also, control and limit the number of expected deliverables.
Also, control and limit the number of expected deliverables.
If you're clearly out of time for the deadline, cut the functionality. Avoid adding people, time, and money as those will postpone valuable feedback. I wrote about it in this thread: https://twitter.com/nhndclppng/status/1358729631931719680?s=20
Hire people that are better than you. Make them feel safe and valued.
Do not cut communications. A lot of problems are solved only through talking with others. Preferably openly and regularly.
Every team goes through phases: forming - storming - norming - performing. Stages are pretty self-explanatory from names. So be ready for storming. Morally and physically.
Think about risks, ask about possible risks, talk about risks openly. Work to mitigate those risks in advance.
And finally, celebrate.
Probably do it less with alcohol as it tends to act as a harmful substitute, do it more with emotions and activities.
Celebrate as kids do. Celebrate good, celebrate bad. Do it a lot.
Probably do it less with alcohol as it tends to act as a harmful substitute, do it more with emotions and activities.
Celebrate as kids do. Celebrate good, celebrate bad. Do it a lot.
