Cyber-security meets business

Here in Switzerland, the awareness towards cyber-security incidents is increasing more and more. I'd love to report that it would only be because of prevention. But sadly, the threat landscape is changing. In recent weeks, there have been multiple reported hacks in the news. And there are undoubtedly many more - which go unreported.

So, are we in the middle of a cyber-security "crisis"? Probably not. But it is a vital topic that hasn't gotten the deserved attention. Why? Because it is not generally seen as an exciting topic like crypto or generative AI.

Let's follow up with this article about cyber-security meets business and deconstruct this complicated topic.

Why? Because the threat is real.

Many well-run small to medium enterprises in Western Europe work on digitalisation initiatives. They have a well-established legacy business model, which they try to modernise.

As you can assume, these organisations have solid processes and an OK capital base, but at the same time, they are also acting in a high-cost environment, which reduces their margin for error. This setting is a worthwhile opportunity for an attack.

What exactly can you do as an SME?

As an SME, the current situation makes you pause. What is happening to partners and competitors is scary, and a cyber-security incident belongs in your risk register.

You could also give up and become fatalistic because, as an SME, you don't have the financial power to go all in from a cyber-security perspective. The fatalistic angle is neither good nor an option from a sustainability stance. But where to go from here?

Good if you are aware. It's even better if you start tackling the mountain of work ahead. There won't be an easy path to a perfect solution - but a steady incremental approach to improving the status quo.

The simple initial steps don't need a big budget or super high specialisation - just a bit of discipline. Also, depending on how extensive your business' IT exposure is, it is easily affordable.

Where to start? By analysing and understanding your business from a data and process perspective.

First, you must ask a few fundamental questions to understand how urgent the situation is and how much you need to invest. These questions are directly linked to your business model, and you may answer them quickly. Asking and answering these questions will also help you to make other business-related decisions. So, what is the first question?

How are you creating value?

What happens if you are offline from one day to another? You won't be entirely offline, but for the sake of argument, we assume that you are locked out of all your services and data. You don't have to be a rocket scientist to see that most organisations will struggle with that. Your IT capabilities are vital if you aren't in a very people-centric or physical-labour-intensive domain. For example, if your logistics solution is compromised and you can no longer track your inventory or ship products.

So, first, you need an understanding of your core value-generating flows. You will want to identify how your IT capabilities enable these processes. Next, you will want to hypothesise what happens when your IT capabilities entirely disappear from one day to another. Then, you will want to consider how to best work around these limitations. Finally, you should map a path to recover your IT capabilities.

Congratulations, you have identified your data/processes and developed a basic continuity management/disaster recovery plan.

But how far should you go?

The bad news first: Every organisation has valuable and sensitive data. The good news: Things are very diverse - depending on your data types and usage, you are a less or a more valuable target.

As an example, let's take a mid-sized fitness centre chain. Yes, a bad actor can exfiltrate potentially sensitive data (so you should keep only a shallow encrypted and segmented set of customer data), but also, if the IT systems are unavailable, the business can continue to run. You might need to wait to send invoices and turn off the automatic access control, and you can't do this forever, but your core business can continue to run. So, you are a less lucrative target.

As another example, consider a mid-sized manufacturing company; the company is dead in the water if the production line is compromised. Or think about a law firm; if the data is exfiltrated and published, you will have difficulty finding and keeping clients. Therefore, these are much more valuable targets.

Accordingly, you should also treat the urgency and invest when responding to the risk of a cyber incident. OK, you now better understand your business processes and the risk level of an attack.

But where can you start?

In general, the good practice should be that you, as a user, can only access as much as you need in the current context and nothing more. This philosophy also applies to the physical access dimension. Your IT resources should be safe and redundant. Safe from physical access - using an established cloud provider is a good practice. Also, your offline backup should be recent and tucked away safely.

Physical access is a multi-layered topic. It starts with the bad actor in mind, who tries to access your perimeter. But the physical access dimension can also concern a disgruntled employee who tried to steal hard disks from a NAS. There was recently news of a case where drives from a data centre were stolen. Don't go too far, but think it through, especially if you run your physical infrastructure.

You also need to consider other physical access-related topics like visual hacking and social engineering, but these topics are better mitigated via education - which we will cover later. The physical access dimension is rather a lower priority for SMEs. Nevertheless, it shouldn't be neglected because not considering the physical dimension can have a catastrophic impact. What about more urgent threat vectors?

Many SMEs still have shared user accounts for vital services or user accounts without any password policies. If you add unpatched services and second-factor-not-mandatory to the mix, then you basically ask about when a cyber-incident is bound to happen and not if.

First, you should get an understanding of all the services you are using. Second, you should configure them as conservatively as possible. So people can do what they need in the current situation but nothing more. Further, it helps if you have a solid offboarding checklist and a patch policy, which is also enforced. If you don't have it yet - your system-admin role will thank you for bringing it up.

The aspect of how people are actually using the services is, again, rather a question of how people are trained - which will be covered later. Not rocket science so far? We have covered the access topic, but what about the data lifecycle?

Data you don't have can't be compromised. This statement might sound a bit strange in today's data-driven world.

Nowadays, all organisations want to hoard data and learn from it. However, only a few do put their data to good use. Furthermore, since storage is so cheap, organisations have built enormous data graveyards. Again, this is not problematic by itself, but the legal dimension and the thread vectors have changed. So, it can become a problem when your data is exfiltrated.

Back to the initial statement - data you don't have can't be compromised.

Having a good understanding of what data you are storing is essential. Following up - having a good data deletion and an application lifecycle policy is even better. As soon as data is no longer needed, it gets anonymised or deleted. And old services, which may be a weak point, are discontinued. So far, we have been talking about processes and policies, but they will only help reduce the impact if somebody does not suddenly hand out the keys to the kingdom.

How can you increase awareness?

About twenty years ago, regular users started to care about computer viruses. Nowadays, threat vectors are much more elaborate. Everybody reads about cyber incidents in the news, but there still seem to be two camps of people who are immune to increasing awareness.

The "I am not a target" and the "I don't care about my data" personas.

Security and privacy aspects shouldn't scare people away from using technology. But at the same time, you also need a driver's license for a car because otherwise, more accidents will happen.

You must pay close attention, especially in SME settings, where professional and personal boundaries are usually less enforced. Think about an unpatched personal smartphone with installed malware on a corp WiFi. Or an employee is accessing corporate resources from abroad on unsecured WiFi without a VPN. Or the golden oldie of clicking a link in a well-scoped phishing email and compromising credentials. It all starts with awareness.

Today, it (sadly) shouldn't be too difficult to find a similar-scoped organisation that was a cyberattack victim, and they may agree to tell their story. All of this must happen in a blame-free environment. The worst enemy of a cyber-security-aware environment is a culture of blame and opacity. Assuming you did all of this, how can you keep the organisation aware? As so often, continuity is the key.

Only a few organisations have the financial means to pay for an actual red team or even a continuous bug bounty/penetration testing program. Financial means and urgency may change in the future, but in the meantime, you may want to start automating and optimising defence/detection (best effort). In addition, a simple emergency drill will already do a lot of good.

Keep people engaged and train them continuously. How?

You could ask an ex-colleague working for a partner to make a call and try to get credentials to a system she shouldn't be able to access. Or you could ask a customer you trust to bring someone to an on-site meeting who tries to gain physical access to a resource they shouldn't be able to access. Or you could play through a complete fallback scenario, including backup restore. So you know that your backup restore procedure works if needed. The possibilities are manifold and not necessarily expensive. Remark: Before doing such things, ensure you and your stakeholders are cleared from a legal and compliance perspective.

To wrap up - cyber-security and business can work very well together. And it is possible to make progress in the cyber-security domain with a reasonable investment. Cyber-security may still not be perceived as the "most attractive" topic - because no direct customer value is associated. However, how will your customers react when your data is leaked?

Cyber-security is an implicit value proposition; for some stakeholders, you can also phrase it differently - a critical risk that needs management. What is important is that you start building up your cyber-security capabilities. Initially, you won't be very effective and will have a steep learning curve - but you must start. Not taking action and hoping nothing happens is not a viable strategy. The question is no longer if a cyber-incident will happen - it will happen. The question is, how well will you respond, and how will you contain the fallout?

The right ways forward are starting small, learning constantly, improving continuously, and scaling over time. Get your stakeholders on board and set sail.

Organisational Debt - or what is needed to modernise organisations?

In Switzerland, we are currently questioning a bit our national identity. You might have heard that a certain Swiss corporate beacon got absorbed by its main competitor.

I once was a customer of this company and, back then, even thought about working for said company. When I got my first degree, I would have been a candidate to go down the banking or insurance road.

Sure, it would have been interesting, but at the same time, I would have also made intense contact with the concept of organisational debt.

Banking is fascinating because legacy business models are melting like ice cream in the sun, and organisations have difficulty adapting. The whole industry is currently suffering from organisational debt.

But what exactly is organisational debt?

The term organisational debt comes from technical debt, which is a well-known concept in the context of software development. Technical debt is created when you need to take a shortcut to make something work. Then, later, you will have to pay to clean the mess up.

The transition from technical debt to organisational debt is attributed to Steve Blank. He established the concept in the context of startups. In startups, you usually can't afford the perfect solution from the start. The positive angle of this is that it forces you to choose the most effective solution.

Multiple authors have already followed up and broadened the topic. So do I.

I believe that organisational debt constantly accumulates in most organisations over time. So keeping organisational debt low is essential to enable an organisation to modernise and respond to the need for change.

Where does it accumulate?

We've established that organisational debt is a useful concept. But where in the organisation does it accumulate?

In the beginning, an organisation is like a small child. Open-minded, learning quickly, outspoken, but also "chaotic".

Over time, organisations mature, processes get established and formalisation increases. For the most part, this is a good thing.

But there are also less optimal traits that emerge.

These days, these less optimal traits are often discussed and well-identified. However, more has to be done to lessen them.

Why we aren't further on this journey is almost a philosophical question. And the answer is eclectic. But this is a topic for a different series.

We need to name a few prime examples of organisational debt drivers to understand where it accumulates: Bad product design practices, encouraged hedging, extensive bureaucracy, legacy technology, overengineered processes, poor risk management, slow communication, tolerated silos, unsustainable financing and weak compliance.

These are all elements which are slowing the organisation down and reducing transparency. And if you keep our Swiss case study in mind - some signs were there. E.g., multiple reported incidents where the organisation operated in a non-compliant state resulted in penalties and important stakeholders losing trust.

It is easier to comment in the aftermath and from an outside view.

However, the signs were there, and critical stakeholders did not fully understand the severity of the incidents, or the organisation couldn't adapt.

Or both.

So the organisation accumulated too much debt, making it so heavy-footed that it could no longer change course.

Why should you care?

Why wouldn't you? Organisational debt accumulates in all types of organisations. Also, public institutions or NPOs are not immune to organisational debt. You could still say that you don't care, but you, as a citizen, are also concerned.

On a small scale, the organisation you own or pays your salary may go out of business because of organisational debt. Nonaction is no solution if you are part of an organisation you care about. Also, if you alone won't save the day, but as a team, you can succeed.

On a large scale, the economy you are part of may take over an additional financial burden or an implicit economic risk, as in our case here in Switzerland.

On a vast scale, it may destabilise complex systems, as it might have in our case study. The organisational debt of a single organisation can go as far as triggering complex chain reactions. Luckily this doesn't happen too often. And a big part of it is psychological - some aspects of how our global economy works are rather odd.

So we've established that you should care. But how can you find out if you are off track?

How can you measure it?

Were you ever part of an organisation and felt things started turning sour? Getting to this state is normal. It is even good that things start feeling off. But what you do with these insights is the big question.

The worst situation is when things are off, and nobody cares. If an organisation has reached the "beyond-care threshold", things will get worse quickly. If an organisation has reached this state, measuring anything will be challenging because most metrics will be fake. Luckily, this doesn't happen too often.

More realistic is that you are in some sort of twilight. But how can you gain vital insights?

Thanks to tools like static code analysis, it is easier to track technical debt.

It is far less deterministic and trickier on the human side.

Here are a few key vectors and linked criteria:

• Ask your employees -> focus on internal culture.

• Ask your customers -> focus on interactions with your organisation.

• Monitor your products/services -> focus on how you compare to your direct competitors.

• Consult your financial numbers -> focus on how you compare to your direct competitors.

• Where it applies: Consult your governance body/regulator -> focus on compliance.

Based on these criteria, you can develop indicators to track how your organisational debt evolves.

To recall our case study: One can only assume there would have been clear signals.

How can you manage it?

First, you must accept that your organisation will build up organisational debt over time. Therefore, it is wise to be actively on the lookout. Because, as so often, the riskiest form is hidden debt.

Transparency is a good starting point in the internal cultural context. Information should flow freely. Good quality information enables you to identify, categorise and reduce organisational debt before it grows to something threatening and unmanageable.

In the customer context, it is likely frequency. Steady contact with your customers lets you identify weaknesses in your products/services portfolio, providing organisational debt "indicators".

For example, a customer tells you that you are suddenly falling behind a direct competitor or points out disruptive innovations which may challenge your value proposition.

In the context of financial numbers, it is probably long-term viability. You should want to establish a stable profit band slightly above the industry standard.

Do you have the financial stability to ensure the organisation can consistently execute its strategy? Do you have allocated funding for innovation/rejuvenation efforts? Are your predictions close to reality?

To summarise and go full circle: Organisational debt is a holistic concept, and it is more than technical debt and also different from bureaucracy.

Organisational debt is a networked concept that fosters the blame-free identification of cross-functional and cross-department weak points.

If we recall our initial case study, they probably should have been able to identify and track increasing organisational debt over the last ten years.

Agility & Compliance & Security: A perfect match, but the domains need to be aligned correctly.

It took a while. But we are at the frontier where agility, compliance, and information security start coming together. Pressure from regulators, from a business perspective and from threat actors are making it happen.

In this article, we are going to look at the following topics:

• Breaking things - The case for compliance and security, especially for those who say it is "too expensive".

• Moving fast - The case for agility, especially for those who think less frequently about business cases.

• Slightly complex - The compliance and information security rift, especially for those with difficulties differentiating between the two domains.

• Slightly complicated - how agility integrates with compliance and security, especially for those who think it is impossible.

• Keeping accountable - Project management is risk management, especially for those needing to appreciate risk management more.

• Continuously trained - Promote mutual understanding, especially for those in charge of ensuring the venture succeeds.

• Business perspective - Finding the sweet spot - especially for those who like to think further about the topic.

Breaking things - Making a case for compliance and security.

It is too expensive. It is not fun. I often hear statements like these. They are wrong. I still remember when a listed company's corporate website needed one simple penetration testing session (security policy) or when we submitted our tax filings on paper (sensitive data). Things have changed.

Under the hood, use cases have become more complex, and the cycles have shortened. Some say compliance and information security are slowing things down and complicating things, but a substantial risk is associated with neglecting them. Indeed, fine-tuning is needed, but ignoring compliance and security in a connected world is the wrong approach.

Breaking things and not being compliant with regulations can lead to hefty fines. And not considering security aspects may lead to an interruption of your core business - with severe implications.

So compliance and security considerations shouldn't dominate every business decision but need appropriate care. Agile methodologies help you to do so.

Moving fast - The case for agility - especially for those who think less frequently about business cases.

Nowadays, things change quickly. There are clear signs of openness to frequent change on the information security front. But compliance is still moving a bit slower. True, regulatory processes need more time - which is also welcome to a certain level - but on the other hand, compliance/regulation may also become too strict and stifle change, thereby breaking business cases.

So, validating business cases against compliance and security requirements is essential. Especially in a SaaS context, there are many potentially lucrative business cases. But these business cases also need to be supported by solid business processes. And these business processes cost money. And so do the talented people taking over compliance and security roles. As a result, the business case needs to be strong enough to support paying their salaries.

At this point, agile methodologies can facilitate. For example, agility avoids too much specification in advance, which is expensive and might need rework when you finally get around to building the features.

And agile methodologies also provide methods to prototype solutions and pivot if the need arises - e.g., a competitor is adapting its offering or when entering new markets.

But then, why isn't the adaptation level already much higher?

Slightly complex - The compliance and information security rift.

Heterogenous teams usually win the day. But working in a heterogenous group can be challenging - we typically like to surround ourselves with people who think alike.

Compliance, product development and security are different domains. Compliance profiles usually have a business/legal background and are part of a "shared-services organisation" (CFO/CRO). Information security profiles typically have a technical background and are part of the product/technical organisation (CTO/COO). It goes even further - the software developer profile primarily wants to build a working solution - not necessarily a compliant or secure one.

These are all cliches and a very simplified view. But in a nutshell, diverse objectives, domain language and different mindsets need to be aligned.

Human complexity increases, and agile methodologies are the perfect catalyst to mitigate these challenges. And if you don't invest, you end up with ineffective silos. Therefore, it is advisable to improve your processes and practices.

Slightly complicated - how agility integrates with compliance and security.

You need three things to link an agile organisation, compliance and security. In the following order of importance - from macro to micro:

1. Transparency, aka a culture where you can discuss risks. Transparency shouldn't be an issue if it is a "functional" agile organisation. Nevertheless, I am mentioning it here again. Why? Because it is so essential. In a nutshell, if there is insufficient transparency, the subject matter experts will need to hedge. Because they can't openly assess the situation and discuss the resulting risks and mitigations.

2. Clear rules of the game, aka backing from a methodology perspective. Compliance and security used to work differently. So first, the domain experts usually need to become more familiar with agile methods. And every change is hard. Therefore, teams need strong leads from a methodology perspective. Yes, an actual Scrum Master and not a coaching role.

3. A facilitator, a translator between compliance, product development and security language. You might have generalists who can oscillate between the domains in smaller settings. In larger settings, highly specialised people will need support to build a shared domain language.

Why is it so important to discuss risks?

Keeping accountable - project management is risk management.

Nowadays, one must read far too frequently about a new data extraction or ransomware attack. And this is only the tip of the iceberg. Because if organisations can, there is a chance that they will try to keep the incident under the lid.

Compliance and security domains need to know what is happening "in the system" to do their job. Potential risks have to be visible, and assessing the risks needs to be possible.

For project management to succeed in the long run, transparency needs to be a given - e.g., understanding how much a shortcut will "cost"; the associated risks must be raised and managed.

Many organisations don't do proper risk management because it is hard to assign a direct "business value", or they see it as a "constraint".

In a way, this is true, but project management is risk management.

You should invest resources continuously - best by baking in some basic risk management in your processes.

If you don't, risks will materialise earlier or later. Usually, it is much more expensive to mitigate a risk that already has materialised than to reduce the impact well ahead by performing diligent cross-functional risk management.

Compliance and security need working risk management. And a truly agile organisation embraces risk management.

Continuously trained - promote mutual understanding.

Without a doubt, the three domains already have substantial touchpoints. But still, the convergence accelerates further.

The domains evolve. From a technical/infosec perspective, there is an ongoing shift from on-premise to the cloud. The migration is happening because there are fewer use cases where it makes sense to host on-premise. With (a proper) transition from on-premise to the cloud, the complete architecture changes — suddenly, you need to consider aspects like outsourcing data to your cloud provider and identities vs perimeters.

Technological advancements like the shift from on-premise to the cloud have also changed things on the compliance side. From a regulatory perspective, "the shields have been raised" due to generally more extensive user data collection and processing.

Infosec must understand the "why" behind new regulatory efforts. And compliance must understand the risks which are associated with cloud-native architectures. So the two domains must understand each other's challenges and use the knowledge to enable the business stakeholders.

This complex relationship is where agility can be a significant enabler. Agility can support involving all stakeholders and enable the domains to collaborate effectively.

However, this only works if the business sponsors also understand the challenges and embrace concepts like a learning organisation, which are vital to evolve towards more agility.

Business perspective - Finding the sweet spot.

These are challenging times - for all types of businesses. However, modern and "self-aware" organisations can better cope with the emerging challenges in a VUCA world.

One action item is to invest in all organisational domains to become more adaptable and resilient.

So the leadership team must also develop "shared services" like compliance, infosec and risk management.

While doing so, every organisation has to find its sweet spot.

Before making decisions, the organisation should clearly understand its risk appetite and consider the impact in case of a severe incident.

Then, based on these considerations and the organisation's size, a pragmatic way forward should include built-in touchpoints with the compliance and security domains early (and often) in the organisational value streams.

Agility helps to increase the modernity and self-awareness of the organisation.

If the compliance and security domains are enabled by agility, the organisation can take a critical step on the journey to solve potential weak points before they become impediments.

Software delivery 101 – What needs improvement in your setup?

Getting flow in a software delivery setup is one of the primary challenges. But fixing issues is only one part of it. Sustaining flow is the next level. So, let's start with the central question. What needs improvement in your setup?

In this article, we move bottom-up along the following questions:

• You don't know for sure if your software delivery setup is performing?

• Your software delivery setup is not performing?

• Your software delivery setup is performing but delivering suboptimal solutions?

• Your software delivery setup is performing, but the quality is inconsistent?

• Your software delivery setup is performing, but you have lifecycle issues?

• Your software delivery setup is performing. How can you improve further?

 Side note: This article makes no statement about the frequency of delivery, aka frequency of deployments to production - because requirements and good practices differ.

You don't know for sure if your software delivery setup is performing?

You don't know for sure if your software delivery setup is performing? Well, probably the worst situation. In this case, you have to assume that your software delivery setup is not working as expected.

No feedback is a brittle state - you are running blind. If you find yourself in this dire situation, introducing basic work agreements should be your primary concern.

Introduce benchmarks to define the quality of a work item that enters the system and the requirements for a work item to be designated as finished/exit the system.

Elements can include:

• Minimal issue tracking.

• An agreed-upon delivery process.

• An established universal metric like story points to create a shared understanding.

Your software delivery setup is not performing?

If your software delivery setup is not performing, this is not good, but you at least already know that you have issues and, therefore, you need to get a mandate to tackle the problems.

It is essential to align with stakeholders first to answer how much transparency the organisation supports because it will need openness to tackle the issues at hand. 

If you understand how far you can go, it is essential to do post-mortems relentlessly and retrospectives diligently. 

Often the problems are not technical but rather in the human domain.

Teams are also a form of silos. And if the organisational culture is not healthy, teams may not align enough, often resulting in suboptimisation and challenging integrations. 

If you keep an open mind in the context of the retrospectives, you will find various approaches to how you can improve things. In addition, you can get guidance from good industry practices (how are successful partners doing it) or tested and proven agile patterns (like frameworks and literature - Scrum, Clean Code, etc.).

Your software delivery setup is performing but delivering suboptimal solutions?

In a way, this is a constant task to stay on track here. Things are getting better, but there are still relatively few organisations which are good at sensing the market environment.

On the one hand, it gets complex and expensive very quickly, making it difficult for small organisations to achieve and maintain a healthy state. And on the other hand, big organisations have the potential to get clogged by bureaucracy and politics - which can make these efforts a frustrating endeavour or even nullify the impact.

It is essential here to increase customer-centricity. You can do this in multiple ways, for example, by strengthening and establishing domains and methodologies like Data Science, Design Thinking, User Experience, and Customer Experience. At the same time, you should also consider fostering processes to facilitate continuous and iterative value delivery to customers and business stakeholders.

Your software delivery setup is performing, but the quality is inconsistent?

Quality, like so many positive traits, demands a lot of discipline. Establishing a good practice is challenging because some people may see it as a hassle - resistance to change. And it is even more difficult to keep these practices going in the long run - sustain change.

When people start deviating from good practices, they often get into a vicious circle of falling back into old patterns. Therefore, the architects or whoever is in charge of your software architecture must provide clear guidance on where your setup has the highest upside potential.

Ideas can reach from refactoring core services for less duplication and better readability to increasing overall test coverage/quality to raising resilience thanks to practices like asynchronous messaging or stateless/redundant services. Whatever your specialists decide, it is vital to slice the improvements into incremental and small steps, track progress closely and celebrate wins.

Your software delivery setup is performing, but you have lifecycle issues?

Earlier or later, every solution has lifecycle issues. Over the last few years, cycles have become shorter, but at the same time, there is also a higher awareness to keep things up to date. So how should this be handled?

If possible, you should delegate the responsibility to address lifecycle issues to the teams to keep their services shipshape - at least in a simple setup.

On the other hand, in a more complex system/enterprise solution, it makes sense for you to establish a central body which handles functional lifecycles of services and technology lifecycles.

In a perfect world, you would never get into a situation where difficult decisions from an architectural perspective are needed. However, in practice, these will come up earlier or later.

Therefore, it is advisable to consult a broad range of stakeholders. Also, if it may sound counter-intuitive, business stakeholders should have a say in architectural decisions. For example, they may be responsible for the budget, have to break the news of discontinuation or cutover of a service and know the solution vision from a commercial angle. Therefore, they can help make better decisions considering how the solution will evolve.

Your software delivery setup is performing. How can you improve further?

If you have no issues in your software delivery setup, you are a lucky person/organisation. You have probably invested a lot, and your efforts are paying off. Congratulations! So, it is vital to keep up the excellent work.

At the same time, it can also be that you have a transparency issue and don't know about it. For example, suppose you are in the comfortable situation of having a well-running software delivery setup. In that case, it is essential to keep the reporting up because people may otherwise become a bit lazy "because everything is anyway always green". And at the same time, it is crucial to facilitate a hungry mindset - hungry for discovery and learning.

Elements like healthy communities of practice or incentives for experiments can be an excellent way to keep innovation going.

Or even dispatch some of your specialists to spread good practices to other parts of the organisation that may not yet run as successfully as your software delivery setup.

Do you want an agile, attractive, and modern organisation? Mindset and culture will always be at the centre of this aim.

I feel sad when I see organisations trying to strap on a random agile framework without the ambition to synchronise it with their mindset and culture.

Yes, you might improve your processes and even get more transparent as an organisation. Still, if you don't commit to working on mindset and culture, you will only get a set of improved processes that won't evolve.

If you are serious about transforming your organisation to more agility, attractiveness, and a modernised state, mindset and culture will need to be a pivotal part of the process.

The mindset and culture of people in the organisation is the decisive factor in helping your crucial customers feel that little bit more valued when they place a critical request or aid multiple teams to support each other early and proactively to deliver on time and meet critical deadlines.

In this article, I will use our experiences at inPositiv to illustrate key aspects and lay the foundation for positive mindset & culture patterns.

Not to oversell - we also make mistakes and learn - but by reading up on our journey, you might identify some action items for your organisation - small or large.

It starts at the top – leading by example.

Our corporate values tell us that we should care about our organisation, but what if leadership doesn't care about us? With increasing ambition, organisations grow in size and complexity from a coordination perspective. Leadership also gets more complicated. You can't know and form a trusting bond with every person in your company. The organisational values will need to take over and create a trusting contract.

Side note: If your organisation aims for pure efficiency and shareholder rent-seeking - I hope it doesn't - then you will probably never achieve the goal of agility and modernity - because agility and modernity strive towards effectiveness.

Your leadership team must ensure that the organisational values are defined, shared and lived. This mantra applies especially to themselves - leading by example.

In addition, leadership introduces the obligation to make strategic and difficult decisions in the organisation's interest - making every form of true leadership so tricky.

In the end, it boils down to three essential questions:

• Do I want to endorse change if it may lead to a situation where I may "lose" some of my formal power?

• Do I think our organisational values are an honest representation of who we are, and am I embodying them to the full possible extent?

• Am I doing my best to be a good citizen within the organisation, and do I also hold others accountable if I see violations of our values?

We are all human, and all of us may have a bad day here and there, but do you think your leadership team could answer the raised questions with a distinctive "Yes!"?

If this is the case, you have a good foundation for achieving maximal impact with a modernisation initiative. If not, it may be time for an intensive dialogue with your leadership team.

Build on self-organising teams.

Self-organised teams are an excellent approach to solving complex challenges and will help to achieve this goal. However, two aspects of this are incredibly challenging. 1. How to enable self-leadership and 2. how to align strategic and tactical flight levels.

Self-organised settings provide room for bikeshedding and free riding. However, being self-organised does not mean being chaotic or intransparent.

Probably even explicitly the other way around. Being self-organised requires a high level of discipline.

These are also some aspects we consider when enabling self-leadership:

• Everybody is in the loop where we aim at a strategic level - you need to know.

• Everybody can participate in defining goals on a tactical level - we need expertise.

• We delegate as much responsibility as possible - give it a try.

• We hold each other accountable and foster transparency - no bikeshedding or free-riding.

• You can always ask for more or less responsibility - find your learning zone.

It is no secret that we are using a tailor-made adaptation of the OKR framework methodology to facilitate the process. But also, if OKR currently seems to be the "state-of-the-art silver bullet", it is not a guarantee for a successful self-organised system.

Just recently, I, e.g. heard the statement - "It's an OKR thing. OKR = The stuff we do on top of regular work on Saturdays".

This statement reflects a well-meant effort gone wrong.

Enabling and strengthening self-leadership is a challenging growth process. And as so often, a good starting point is essential, but the execution is the most critical part.

How to align the strategic and the tactical flight levels?

Fast-growing or long-established organisations often have the problem of disconnecting strategic and tactical flight levels. As a result, employees don't know why they perform a particular task in daily business - they can't make the best decisions on an operational level because they don't know where the organisation wants to go in the long run.

They may not even care anymore because of all the rhetorical strategies that do not result in tangible results on an operational basis.

"Not caring anymore" is the most extreme case to be avoided at all costs.

One of the reasons why we work in organisations is specialisation.

Organisations enable us to focus on what we are passionate about and where our strengths reside - this also applies to the strategic and tactical layers. Strategical and tactical/operational thinking require different approaches - from how long-term you need to think, how big-picture you need to think, and how much uncertainty you need to consider when thinking.

I, for example, know our strategic game plan well, but I am responsible for our daily-business operational level. Therefore, this is also the view I hold and contribute most to. Of course, the people in our organisation responsible for defining strategy can always consult me, and luckily they also do. Still, my current role demands a different focus and thinking, so I would refrain from making strategic decisions.

Isn't this contradicting the problem statement I started with?

No, it doesn't. You need to separate strategic and tactical flight levels. If you don't, you end up with no clear separation. You won't be able to make the hard strategical decisions needed for the organisation to renew itself constantly.

But again, you need to ensure that the layers "connect" frequently and "honestly". So, for example, if the strategic level doesn't get insights into what is required on a tactical level and if the tactical level doesn't understand the relevance of the strategic level, the intended gap to create creativity will produce a gap that leads to inertia.

We are still a young organisation, so staying on top of things is essential. We have at least weekly check-ins spanning strategic and tactical levels to ensure they are in lockstep. This may be too extreme for big organisations - but we see value in it and will keep it happening for as long as feasible.

We propose short cycles, a participative goal-setting system and rich communication as solution vectors.

How to keep an organisational culture healthy?

Keeping an organisational culture healthy is the most complex challenge. We all know how challenging it is to maintain healthy interpersonal relationships. However, in an organisation, things become even more complicated. Because an organisation is an abstract entity, you may also have to maintain relationships with people you don't like on a personal level.

As so often, transparency is your friend. But transparency is also challenging. So often, people misinterpret an "agile environment" as something super dynamic without rules, which is entirely wrong. On the contrary, an "agile environment" is built on clear rules and transparency, facilitating controlled change when needed. This pattern can also be applied to sustain a healthy organisational culture.

Nowadays, there is a lot of talking about healthy organisational cultures. Specific cues come to mind, like "employer branding", "knowledge workers", "psychological safety", and "war for talents". But you can keep it relatively simple.

Three questions to ask while reviewing your corporate culture:

• Transparency - is transparency given? For example, can people ask questions, can people be honest, and can people speak up? A basic level of transparency always needs to be there - otherwise, unhealthy things will happen off the record.

• Feedback - is there feedback? Do feedback cycles happen, or do we allow things to fester? A minimal feedback cycle needs to be established - otherwise, the culture can't heal when it is unhealthy.

• Values - is there a basic set of shared values? For example, how should humans interact with each other, and what the organisation wants to achieve? An elemental set of shared values need to exist - otherwise, a culture will slowly dissolve into potentially conflicting subcultures.

We propose regular and structured check-ins, easy and direct communication, and a shared and lived set of organisational values as probate means to keep an organisational culture healthy.