Three step research process

Use your brains when developing abstract innovation. It is a game of 'balance': you think-up what is needed, you set goals that take advantage of your thinking, then you work towards your goals. If on the way something does not fit, review your goals or thinking. It is an iterative effort, you try, you repeat, until it works.

Here are the three iterative steps in more details:

1. State what you believe is true
2. Express implementation goals that will leverage your beliefs
• Check consistency of goals with respect to your environment and to underlying beliefs
• Correct your beliefs if inconsistencies are found between goals and environment
3. Develop towards your implementation goals
• Check consistency of development with respect to environment and underlying goals and beliefs
• Correct goals or beliefs if inconsistencies found between development and environment

At first, one tends often to 'juggle' and develop just one idea at a time, when developing this way. Yet with experience it becomes clear that it is the iterations that take much time, and therefore it is often worthwhile to think-up more than one idea, and bring them forward in parallel until the environment gives feedback, and one idea turns out to be better than another. Lean is therefore not always agile when working with abstract development.

All original content copyright James Litsios, 2022.

Six ways to improve your organisational agility

Failing smart 

 My agile mantra is much:

"Failures must bring you closer to your vision"

It is a mantra I have often used. And very much how I approach agile innovation (e.g. see Search and Vision for Systematic Innovation)

However...

It is only partially true, as failure may happen simply because you are disorganised, with no relations to your vision. Fixing organisation issues helps avoid drifting further away from your vision, it does not bring you closer to your vision! Still, unmanaged organisational issues will eventually consume you 'from within', therefore they too must be addressed.

Can we focus on fixing organisation issues? Can we identify a subset of failures as 'organisational failures', and others as 'non-organisational failures on the way to our vision'? The simple answer is yes! Yet we most know what we are looking for.

Six types of failures

When I act as agile manager I try to distinguish between six types of failures. These are:

1. Fail Goal: Fail to achieve previously promised goals
2. Waiting: Fail deadline because of waiting on others
3. Underutilisation: Fail to use all your team members
4. Exhaustion: Fail to stay productive because of exhaustion
5. Inconsistency: Fail because of misalignments
6. Queuing: Fail because of past work no longer relevant, or past work never finished.

Failure 2 to 6 are all organisation failures!

Failure 1, not achieving goals, might be an organisational issue, yet may also be tied to the difficulty of the the task at hand.

Six ways to improve your organisation

We can express specific actions for each type of failure observed: 

#	Failure type	Observation	Corrective action
1	Fail Goal	Fail to achieve previously promised goals	Review / pivot how resources approach goals
2	Waiting	Fail deadline because of waiting on others	Review how resources approach work
3	Under-utilisation	Fail to use all your team members	Review how goals are broken down into work
4	Exhaustion	Fail to stay productive because of exhaustion	Review how goals are picked up by resources
5	Inconsistency	Fail because of misalignments	Review how work is shared across resources
6	Queuing	Fail because of past work no longer relevant, or past work never finished.	Review how common work impacts different goals

You may note the common patterns both in the observations and in the corrective measures above. This is because they all refer to the same system! This is important, and maybe the most important learning from this post. When managing fast greenfield innovation projects:

Comparing failure types is as important as to address specific failures!

This is because when a failure type happen more often than others, we can take organisational actions even before we understand the specific details of each failure! 

A final note: the approach is scalable.

All original content copyright James Litsios, 2022.

25'000 views; Some topics I am passionate about

 This week a took a day off to walk in the alps with my son. And while doing so noticed that my blog view count was 24999. So I quickly asked my son to be the next view! 

My blog has been around for more than ten years, and a tenth of a second is all a site like Google would need to achieve the same hit count. Still, I write this infrequent blog because it helps me find what is relevant to me and to others, and helps me communicate better. And encourages me to do my best, because I do care about my audience.

I write infrequently mostly because I do not have the time. Also, my topics tend to be complex, and sometimes even sensitive, and therefor take time. Still, I often jot down a title, sometimes with a page or two of content. These then become public if I happen to have free evening or weekend. For example, these are my unpublished blog titles going back to early 2019:

• Balancing productivity, tempo, and success
• Program = complementary
• Some retrospectives in business of innovation
• Type centric vs ...
• The instantaneous view of the real world has no math
• Control and flow in innovation
• Lessoned learned: writing "coherent software"
• Careful Software Architecture (in Python)
• Absent minded at work
• Choose your inner truth: run your organization like a hedge fund
• Dealing with time
• Computer languages as data for machine learning
• My reality? Or your reality?
• The Peter principle in software development
• Innovate, but don't waste you time
• ...

Out of these, you might notice topics that I am passionate about:

• Innovation
• Productivity
• Formal software and architecture
• Teamwork and organization processes
• Modelling the real (and unreal!) world

The thing is: You cannot innovate if you are not productive. You cannot be productive if your teams and organizations do not work well together. You cannot work well together if you do not understand how to express the real world in your work, and to be precise and correct when needed. These are topics that I care about, and what this blog has mostly been about.

Cheers to all, I am looking forward to sharing some more writing!

Search and Vision for Systematic Innovation

How to be productive in innovation?

The simple answer is "work hard", "be systematic", "believe in a larger vision".

Best to illustrate this:

I am writing a python program to do something new. I know that to be innovative I need to be "one level above" what was previously done. So I include a construction which I know enables this "newness". The problem is that this construction does not fit with "the normal code".  I notice this only after my first attempt to put things together, when on the way to a design, I cannot find a way to bring back in the requirements I have dropped. Let's call this first attempt design A. 

When you fail, you try again. I pivot my design, now to focus on B. Same result, design fails to bring in all requirements. I try again, now focusing on C. Same result, the design does not fit. A this point I start worrying. I step back. I explain to my daughter: "tricky, but I have got it! What we need is to go a level above and dynamically bring in A, B, and C concepts in a pre-sorted meta-design that depends on the input data". This new design, let's call it sorted ABC is not easy... and it also fails! Now I am seriously worried.  

I try again. Yet this time, knowing that A, B, C have failed, as did sorted ABC, I step back further. I go all the way to the "one level above" concept, which I take out, and put back in, in a complementary way. In two days, I have the design, and in a week I have all the requirements in it.

Innovation is just a "search algorithm". Edison knew this. The pharmaceutical industry has scaled this to the extreme. What is a little bit tricky in computer science, and similar technology domains, is that innovation is a mental game. The result is that failure within a search effort impacts moral and motivation.  The fact is, if you have not prepared yourself, it is not possible to invest yourself, and not feel the pain of failure.

The effort I described above took me more than a month. I might mention that I was getting seriously upset with my repeated failures. Yet the trick is that failures that are progress within a bigger vision are acceptable. They are painful, they make you lose time, but they are still ok if they bring you closer to your vision. Therefore the simple rule in innovation is that your need that larger vision before you start! And in fact no work should be done without that larger vision, and that larger vision needs to be a real concept of delivery of a real product with real innovative advantages.

A key ingredient to this process is that failure must reduce the search space towards your innovative vision. As a leader or in advisory roles, I find myself repeating and emphasising this more than anything else. Because this is the "crux" of productivity in innovation. Again: FAILURES MUST BRING YOU CLOSER TO YOUR VISION!

Finally, if your failures are not bringing you closer to your vision, then you have placed the bar "too high" and you need to diminish your expectations, and reduce the scope of your vision.


All original content copyright James Litsios, 2020.

Innovation, and failure

Last weekend my dad found an old book of mine from 1979: "A solid state of progress" from Fairchild. I am not sure how I got it, and I had not seen it since ~1985. Here is a picture out of it:

The book has about 50 "art" pictures of integrated circuits, and that's it. They are all carefully presented, each one with a little marketing blurb, as this is a marketing publications, and the book has a marvelous "old color ink" smell.

For those that do not know, Fairchild was "the" semiconductor company of the early sixties and from it many were born. Here is a figure that I have copied without permission from someone who redrew without permission a version of a graphic found on page 12 of the in October 2007 issue of The IEEE Spectrum magazine:

Finding this book after something like 30 years made my weekend, but the reason I wanted to mention it, is because this book brings together a few special themes:

• Innovation: Wow, Fairchild had a crazy influential team of innovators .
• Branding:  These pictures are like the Marlboro man. Fairchild semiconductor was part of Fairchild Camera and Instrument. The pictures resonate the camera sensor company, but also with the fact that in those days chips were still "something magical".
• Failure to change: In many ways this is a story of Fairchild's failure! Branding around "static, beautiful and mysterious pictures" is great for the feelings, but not for the business.  The business of innovation is one of change, and that means that your internal process must stick to what stays even when everything else changes.  
• Failure in business: How many times have we heard smart competent engineers say "that is not the way we do things", or "I do not know how to use that"? The tricky part of innovation is that unless you embrace it, you are pretty much rejecting it! Yet rejecting change is not going to make it go away. Not to mention that adopting too much change will drain you, and cause failure too.

So here is the thing, this beautiful book out of the past of the chip industry is both an emotional statement, as it is a historical archive of how not to manage innovation.