Blog – Jaap Trouw

21/02/202321/02/2023

The flip-side of scaling

📈Scaling means growing, right? And that usually means hiring more people, levelling up your technology stack, adding more processes (hopefully not too much), upgrading your governance etc, and so on.

⚖️ Having a business “at scale”, means you have a business with the right amount of people, processes, technology, structure etc. to solve your challenges. The business is at a balance. Not too much, not too little, just right. I personally like to add that a business “at scale” is also flexible to address changes, meaning if the business grows faster than expected or not, it can easily adjust. These 4 steps help you to scale. They influence each other, but start with 1.

Which products/services are you (not) going to offer (in the future) and how? (Product & Technology)
What skills do you need, how many people? (People)
What processes (governance, way of working, compliance etc.) do you need? (Process)
And how will 1,2,3 be flexible enough to easily adjust in new circumstances?

📉But what if…the business is not growing and/or the economy is slowing down?

🪙 Flip-side
That usually means you need to “shrink”, “downsize”, “restructure” and/or “reorganise”. “Shrinking” is the flip-side of the same scaling coin.

Again you need to find the right balance of products, people, technology, structure, governance, way of working etc. Finding that balance involves the exact same list in a “scaling for growth” situation. And here also, start with 1. With “de-scaling” the most important things what NOT to do anymore, saying NO to things. And then see what you will be doing and who you need for that.

🙈Unfortunately, most companies just choose to cut costs and let people go, without taking the 4 scaling steps. And within month they have a scaling problem again…

Keep your organisation “at scale” all the time, and challenging times won’t be such a drama.

14/02/202314/02/2023

Permission? No thanks, give me some constraints!

Looking at the terms, you might think “Give me permissions all day long!” Not so much…

Permissions
In a permission culture of decision making, you ask permission. For everything. There are rules and procedures to follow. If a situation/procedure or rule is not defined, you cannot make the decision. Even worse, the company needs to create a new rule for a new situation before it can move on. Examples:

If you want to buy something (doesn’t matter what), ask permission of your manager.
A new business experiment first needs to be approved by manager x, board y, following procedures a, b and c, before you can start.

In essence, the company needs to define ALL possibilities and relevant rules to be able to make decisions. It is never ending and it costs a lot.

Constraints
In a constraints culture of decision making, you are allowed to make any decision you need, if they don’t cross certain rules/boundaries or constraints. Examples:

Up to 10.000 Euro you can make any business decision you think is appropriate. Treat the companies money as it were your own.
Free to do any experiment you want up to a risk of X (euro, safety, etc.)

In a constraints culture of decision making you are allowed to do anything you want except for a few things. That means everything else is up to you and that opens up an infinity of possibilities.

In essence, the company just needs to define some limits, freeing up creativity for all other possibilities.

Any other examples or though, leave them in the comments.

Credits
The Knowledge project podcast #158 Aaron Dignan: Change the way you work

07/02/2023

Don’t do #ITIL, except this!

As most frameworks, especially with a business case for selling trainings and/or certifications, ITIL and/or iTSM is way too complicated and massive to implement in organisations. It’s not practical anymore. So don’t do it.

But..

There is (at least) one thing #Agile organisations can learn from iITIL/iTSM and that the difference between incidents and problems or, even better, the difference between an incident and a problem mindset for your team.

🚨 Incident

Something’s broken. Your application/service is down or not functioning properly. Your users cannot use it (or are very limited).It’s hurting your reputation and business. 💩. Your number 1 priority is the restore the service to it’s normal way or working. With any means necessary. Here (digital) ducktape and WD40 come in. In most cases, a role-back of the change you just implemented, is needed. Or you need to temporarily patch things up (bandages). More often than not, it means your are fixing the consequences of the incident instead of the root cause and that’s fine. Primary goal is: Services/application up! And not per se, solve the (root) cause.

Services up again? Crisis gone? 😮‍💨Breath…

Now go into problem management mode. Relax, there’s time, incident is gone.

🤔 Problem

Two things are important in problem mode:

Find the root cause to the incident (if not found already). That means solving the underlying issue and removing the temporary bandages.
Prevention. The most important question is: What can we do to prevent this from happening in the future? And then implement them!

🪦Isn’t that a post-mortem?

I know this sounds a lot like a post-mortem, and for most part it is. And you can definitely use the post-mortem meeting to get things going. The difference is that a problem is solved in ITIL only when the actions are implemented and they have the results you were looking for. It is a mindset that people seem to forget when doing post-mortems (usually the ideas in a post-mortem are forgotten the moment the session ends).

By the way, this works for any kind of incident/problem! HR, Marketing, Sales, team dynamics, etc. and so on…, not just in your product organisation.

08/01/2023

My week of running (2 Jan – 8 Jan)

Finally running again! After weeks of not running due to whiplash in my right calf, since 2 weeks I’ve been running. My PT, got my on a protocol to make sure I train but not overdue it. I’ve combined the running with help of my coach with strength training and biking. This is what I’ve done

Monday: Biking ~1 hour
Tuesday: Running 15 x (1 min walk, 1 min run), ~40 min strength
Wednesday: Rest (a lot of wind/rain)
Thursday: Running 10 x (1 min walk, 2 min run), ~40 min strength
Friday: Biking, moderate-hard, ~1 hour
Saturday: Running 10 x (1 min walk, 2 min run), ~30 min strength
Sunday: Rest

Just seeing the overview, I did pretty well if I do say so myself. Tomorrow it’ll be 4 min running and strength. I’ll keep on working. By the end of the month, I’ll be running 30 min again and then we can build.

19/12/202219/12/2022

The number #1 Ethical Rule of Fraud Detection

If you see fraud, and do not say fraud, you are a fraud*

Practically that means, when you detect #fraud, you have a couple of options and 1 obligation.

🚨 The obligation
You register it as fraud and report about it. Everything after that is “optional”.

✅ The options
1. You compensate the victim AND you (try to) find the fraudsters and hold them accountable (with or without help of the official authorities). This also means banning them from your platform
2. You compensate the victim BUT you do not pursue the fraudsters
3. You don’t do anything further than the obligation mentioned above

Of course, all the options have consequences that you need to accept.

❓There are several considerations that come into play in the decision making, such as and definitely not limited to: laws about the type of fraud in your country, financial risk appetite, fraud risk appetite, being a public or a private company, repetitional damage, further ethical rules in your organisations, how you feel about a certain case, what other ethical rules you want to live by as a person or as a company, etc. and so on.

🙈 Plausible deniability…
…does not exist here. Once you see or detect fraud, you need to act.

*inspired by Antifragile, things that gain from disorder by Nassim Nicolas Taleb p. 15 prologue

18/12/2022

Spontaneous combustion rule for organisational minimalism

What if the meeting your about the attend, the process you are about to follow or the system you are using, would “spontaneously combust”, in other words, disappear immediately?

How would you feel ? Do you think you would regret it, or would you feel relieved?

Based upon (stolen from) The Minimalist Rulebook, 16 Rules for living with Less. It’s rule #13. You can find the full rulebook here.

17/12/2022

My week of running (12 Dec – 18 Dec)

Like I said last week, not a week of running. Still one full week of not running to go.

What I did do:

Mon: 1500 meter swimming + 30 min hike
Tue: rest, sore from swimming
We: 1750 meter swimming
Thu: rest
Fri: Strength training, Calestenics
Sat: 60 min hike, sore from strength training
Sun: not sure yet, probably still sore, so need to recover

Still not that much though, but changing a bit how I train, so I can incorporate more strength training once I’m able to run again. Can’t wait though…

16/12/2022

Organisational or Business Minimalism

I’m sure you are familiar with the term “minimalism”. I was introduced to it years ago through The Minimalists and the idea behind “less is more” stuck with me. One of the disorders they fight against is “hoarding”.

The definition of hoarding

“Hoarding disorder is a persistent difficulty discarding or parting with possessions because of a perceived need to save them. A person with hoarding disorder experiences distress at the thought of getting rid of the items. Excessive accumulation of items, regardless of actual value, occurs.”

Recognise this? I see an analogy in organisations. There’s a tendency to add a new process, procedure, checklist, person or team to the organisation for every new problem. Once the problem is solved, everything stays. Nothing is deleted. The humber of systems and processes pile up to a big jumble of complexity and nobody can understand it anymore. And the work environments starts to stink…

Okay, I might be exaggerating just a tiny bit, but you do recognise what I’m saying.

I think it’s time for Organisational or business minimalism and I’m interested in your:

Examples
Stories
Rules
Thoughts
Ideas

15/12/2022

Declutter your meetings, rule 1

😥 You are swamped. Swamped with meetings. And if you take a close look at your calendar, most of them are recurring meetings you have weekly, bi-weekly, monthly or something like that.

🤨 And of course every meeting has a clear goal, every member including you is needed in the meeting, there’s a clear agenda/topics to be discussed and in last for 45-50 minutes to make sure people have time for their needed bio-breaks (yeah, right…).

Still you need less of them, to stop the back to back meeting days.

✅ Use this rule:
Recurring meetings have a maximum of 6 occurrences. In the 6th meeting there is an extra topic: evaluation. Outcome of this topic:
– Continue yes/no
– If yes, how (cadence, length, improvements, members, etc.)

14/12/2022

Solve your Organisational Debt, the Boy Scout Method

Technical debt
There are 3 fundamental ways to deal with Technical Debt:

Stop everything for a period of time and just tackle the technical debt. Examples are “technical debt” sprints. Or in worst cases, a legacy system is so bad, the only sensible thing to do is just to rebuild the damn thing and replace it, with all the additional problems of phasing in and out.
Take a certain percentage of time/effort every time period and deal with a piece of technical debt. That usually means have a full overview and then chop it up in pieces and deal with it very week. Sometimes you see even a separate backlog for technical debt… Don’t do that by the way, technical debt is part of your product, so it goes on the normal list
The Boy Scout Method: when you deal with a piece of your product/code, leave it better than you found it. That means when touching code for a new solution, you also look at the code and see what you can improve.

Big chance you are dealing with your technical debt in a combination of at least 1 and 2 and sometimes 3. If possible, my advice is do 3 and not 2, but at least make a conscious decision about it.

Organisational debt
In analogy, your organisations probably also needs to deal with Organisational Debt. Just as in technical debt, you make all kind of decisions that in the ideal situation you would not have had (to make) and your organisation is not at it’s peak happiness or performance.

The same three strategies
If the analogy applies to the problem, that of technical or organisational debt, does it extend to the solution strategies as well? Let’s try

You stop everything (meaning organisational change) for a period of time and prepare a re-organisation of the team/department. Worst case you need to re-invent everything and a full company wide re-organisation is needed.
You make a “backlog” of everything that needs change and you hire a “transformation manager” to lead a change program where every team spends a bit of time every period on changing something. When one thing is done, go on to the next.
The Boy Scout Method. You as a leader know that a lot needs improvement, but you don’t organise a program. With every change, (new team member, letting someone go, new system, new tool new process, new crisis, etc.) you change what you find and deal with the organisational debt related to that part of your organisation. No big bangs, no separate change programs, just improve what you find.

Note: when dealing with organisational debt, you will always find more than you’re bargained for. I use to call them pandora’s boxes where everything that comes out is in the form of a skeleton in the closet. That also means that every transformation plan needs immediate adjustments as you go along.

My opinion

As a leader you try to make sure that option 1 is never needed. I know that sometimes it cannot be avoided due to external unforeseen circumstances. And even then, were they really unforeseen? Or didn’t you do your due diligence to make sure risks could have been prevented? For everything that IS under your control, you do your best to not go into option 1.
It could be that your problems are so big that option 2 comes to mind. But starting a transformation program takes time and energy on its own and sometimes there’s not time or energy. Of course getting a quick overview of what’s going on and then thinking of a quick strategy is good, but that should not take more than a few days. The best thing to do is to start changing and adapt as you go.
I prefer option 3 of course. Dealing with organisational debt always brings new unseen problems, pandora’s boxes and skeletons out of closets you didn’t know even existed. That means the only way is to make use of a change and improve on the organisational debt it touches. Never waste a good “crisis”.

Oh. And never forget, organisational debt as with technical debt is payed with interest!