On the Art of Good Change and Lifelong Learning
Sclable Insights — Interview with Karl Holzer, COO
This is the start of the Sclable Insights Interview Series. Recently joining Sclable’s Business Innovation team in Vienna I took the chance to learn more about my new colleagues and also talked with them about our industry and challenges in our daily work.
This story is about #Kaizen #Growth Mindset #Business Design
Hello Karl. May I ask you to introduce yourself and tell us a little bit about your role at Sclable?
I’m currently serving as COO for Sclable. Before joining Sclable I was working for some years as a Product Manager in the larger eHealth domain in B2B as well as in B2C settings, the latter specifically with Runtastic as part of the Adidas Group where I was working mainly in the area of Social Features like News Feed or Notification Inbox and the first larger integration with the mother company Adidas via the Adidas Runners Community. In the B2B setting, I was heavily involved in the setup of the Austrian national patient record ELGA which was a totally different world but also very interesting to provide the best experience for all participants (hospitals, physicians, pharmacies etc.) in a highly regulated field.
It was really interesting to experience the different aspects when building products — and learn from them. On one side from the perspective of the respective people using the products but also from the perspective of the company when it comes to organizing the teams building those products. In my role, I’m trying to help the teams when it comes to organization of our projects/product development efforts and I’m very much convinced of doing this in a way that fits the team and the customer best — some people call it “agile” but I think this word is often used in a wrong context or with the wrong thoughts in mind. The ability to handle unreflected switching of priorities in product development efforts is probably not what is intended.
Karl, in your profile on our internal company Wiki I found the hashtag #Kaizen. What does that mean?
Kaizen in business terms is something that has been around for some time, especially coming in from the Japanese car manufacturer Toyota, and popularized by the book “The Toyota Way”. Translated directly it means “good change” but it bears more. It means that everyone in the organization — regardless of role — is committed to continuous improvement.
A vital but not so well known part of “Kaizen” is “Hansei”, which basically contains the steps of recognizing a problem, how you contributed to the existence of the problem (not regretting but rather having the courage to own the failure — psychological safety is a prerequisite for that), having a personal sense of “well, that didn’t help” for the problem and lastly the commitment to improve. So it’s the reflection or “learning” side of the medal, whereas the other side — Kaizen — is the “acting” part — If I take Scrum as a reference, Hansei would be similar to the retrospective ceremony of the team.
There is also a saying that “there is no Kaizen without Hansei” which I think is very true but often forgotten or not really mentioned.
Kaizen is also a deeply personal thing so it’s hard to push it on an organization, everyone involved in the organization needs to have the mindset in place so it can help the organization in return. That’s not an easy thing.
So we talk about something that in the Western World is also known as the Growth Mindset?
Kaizen and the Growth Mindset are definitely closely related but I see Kaizen more as a part — and a more personal aspect — of the Growth Mindset as it goes further and rather acts as a differentiation from the Fixed Mindset. The Fixed Mindset is based on a deterministic worldview where things are believed to just stay as they are and are naturally limited by talent etc.
Kaizen for me is a personal starting point for the Growth Mindset — so I’d say “There is no Growth Mindset without Kaizen”. Kaizen, when practised, also leads to a better workplace, elimination of “hard” work and reduction of waste.
What does that mean in the context of working with clients? And what does it mean for the further development of Sclable?
Retrospectives (internal and with customers) are important in order to improve — results and outcomes as well as relationships. It’s sometimes hard to involve customers in such an open learning environment where the “Las Vegas Rule” (what happens in Las Vegas, stays in Las Vegas) is in place because it is different from what they are used to sometimes.
It needs the right mindset and incentives in place — this is absolutely not meant disrespectful but rather reflecting what is, as different organizations have different cultures, values, and incentivise different virtues and behaviours, so I think it is important to meet people and organizations where they are and not where you want them to be in the first place.
Let’s take this a little further: In the first conversation we had you said: “It’s the time to change the whole consulting business“ What do you mean? How would you change it?
Consulting — as it is mostly perceived now — is probably not relevant when it comes to digital products. It should be about the creation of value, not PowerPoint slides, it’s about getting fast feedback from users and customers (and yes, there is a difference), not relying and deciding upon assumptions. This is hard to learn and I personally also catch myself every now and then that I’m assuming things although I could easily verify by asking. But this is hard as it reveals, that you might not know everything — which can be a tough move as a consultant who is paid to have all the answers.
In some workshops and training sessions that I helped to organize and host in the past, this was really interesting to observe. We did some walking skeleton sessions where the goal was to scope a walking skeleton of User Stories for a specific product and the goal of the teams was to create it on a whiteboard. We as facilitators acted as advocates of the users and could be asked for help/more input anytime. And we saw that some teams actually fought with assumptions and had a hard time to proceed whereas others intuitively asked for input and feedback.
And this is something that you have to learn by experiencing it, not just by reading books about it. Learning to keep things small or just as complex as necessary, not overselling but rather focussing on the real needs, in Kaizen terms, it would be the reduction of waste (or muri). In the Agile Manifesto, it would relate to the 10th principle “Simplicity — the art of maximizing the amount of work not done — is essential.”
I also very much believe that the core duties or topics to care about when building (digital) products lie within the combination of the perspectives of value, usability, feasibility and viability of a product (citing Marty Cagan here, derived from the great book “Inspire” by the way). Missing out on just one of the perspectives already puts your product at risk of failing and that’s what consulting for products, as I understand it, really has to offer in the digital era.
Can you name an example of what we are doing to get there?
It is not about making your client happy by telling what she wants to hear in the first place but what she has to hear — even if it’s uncomfortable or might just directly oppose given assumptions. Because in the end, we (and with we I mean we at Sclable plus the client) want to deliver a working product that fulfils actual customer needs or solves their issues and resolves their struggles and not a pet product or the often-used term of “innovation theatre”.
For us it means that we have to get out of the corner as a delivery company, meaning “we do exactly what clients wish”, there are companies that can do that and it is perfectly fine as they might fit the specific case.
We have the ambition and aspire to be recognized as a partner along the way that helps companies lacking some skills and knowledge to get their ideas off the ground and make them successful — or also give clear feedback, that we don’t see enough evidence for the opportunity but we would rather focus on something else that might deliver more value. This is very often a hard path as you might directly oppose an idea that a person carved out for quite some time. The saying to “fall in love with the problem, not the solution” is something I like to remind people at this stage sometimes.
How about the role of the BDA — the Business Design Architect — that we have here at Sclable. Are they engaging in that direction? How?
The BDA is a probably not so known role out in the wild. The Business Designer role is around for some time but from our point of view that didn’t really cut the mustard as it leaves out/doesn’t really value the technical competence that is so important nowadays as it helps to identify feasibility very early on in the process.
I would describe it as a role similar to the skillset of a Product Manager but with a solid technical background (in fact, all of our BDAs at Sclable started as developers) and an interest to really get to the core of and understand how something works — be it a business model, a specific product or a whole industry and the stakeholders active in this field.
Just to get that right, it doesn’t mean that a BDA has to be an expert in a specific field from the start but rather have the ambition to get into the matter as quickly as possible driven by intrinsic motivation and curiosity.
So a BDA should incorporate the Growth Mindset as mentioned earlier and must be able to deal with setbacks, seeing them as an opportunity to learn and improve for what comes next.
How does that look like on the client-side, the companies we are working with? What requirements do they have to meet in order to navigate successfully within the triangle business — design — technology?
They need to learn and accept that a successful product or project needs to consider these three perspectives, especially in the digital age. It’s like the 4 risks I mentioned earlier — value, usability, feasibility and viability — a product simply won’t work if you miss out on one of them in the long term. There are of course products that seem to live without having viability (meaning financial viability) on the radar primarily (see Twitter etc.) but if you are a corporate and are not backed by hundreds of venture millions you won’t be able to afford that in the long term.
Is there something that we do at the beginning of a project to educate and raise awareness to focus on value, viability, feasibility and usability?
We try to involve the Product Owners on the client-side and introduce them to the approach that we think makes sense out of our experience — and I think we should even do more of this compared to how we do it at the moment.
So there should be an alignment before the actual project starts to get in sync about the expectations of how we want to work together. Because in the end we (again meaning we and our client) are on the same side and want to make the project or product a success — and when you go into digital, there is probably a different approach necessary as you were used to in the past.
And this can be hard for a Product Owner that was installed to “take care of the project” on the client-side. The way of working may suddenly differ from the way things are usually done within their organization and might even lead to a tension that the Product Owner experiences with his/her own organization, sometimes it can even lead to some kind of alienation. Something that is also often overlooked IMHO.
This article was written for Sclable’s blog on Medium.
If you liked it, give it a clap and share if you ❤️
