Organisational Resilience - Design your Organisation to Flourish NOT merely Survive
A resilient organizational can not only adapt and respond to incremental change but more importantly, can respond to sudden disruptions and also, be the source of disruption in order to prosper and flourish.
The traditional risk management approach focuses too much on defensive (stopping bad things happen) thinking versus a more progressive (making good things happen) thinking. Being defensive requires consistency across the organization and this is where methodologies like Plan-Do-Check-Act (PDCA) come in. However, PDCA approach does not bake in the required progressive thinking and flexibility required for a fast company organization which operates in a volatile environment.
Professor David Denyer of Cranfield University has recently published a very interesting research report on Organizational Resilience. He has identified the following four quadrants across to help us think about organizational resilience:
- preventative control (defensive consistency)
- mindful action (defensive flexibility)
- performance optimization (progressive consistency)
- adaptive innovation (progressive flexibility)
In this talk, I'll share my personal experience of using this thinking to help an organization to scale their product to Millions of users. I've dive deep into how we structured our organization for Structural Agility and how we set-up a very lightweight governance model using OKRs to drive the necessary flexible and progressive thinking.
Outline/Structure of the Talk
- A quick overview of tension quadrant
- preventative control (defensive consistency)
- mindful action (defensive flexibility)
- performance optimization (progressive consistency)
- adaptive innovation (progressive flexibility)
- Problems with the old organizational structure and why it was not resilient
- How did we change the organizational structure and the challenges faced
- Once we formed the new structure, how did we create a governance model that encouraged the right behavior of innovation and resilience
Learning Outcome
- Understand the tension between defensive vs. progressive and consistency vs. flexibility to achieve Organizational Resilience
- Understand why Plan-Do-Check-Act is not sufficient for Organizational Resilience
- Understand why Structural Agility is important and how you can structure your organization to be more resilient
- Understand how you can set-up a very lightweight governance model using OKRs to drive the necessary flexible and progressive thinking
Target Audience
Executives, Leaders, Change Agents
schedule Submitted 4 years ago
People who liked this proposal, also liked:
-
keyboard_arrow_downCraig Brown - Better Collaboration
50 Mins
Workshop
Intermediate
This session is a guided walk through collaboration; what it is, why it is valuable and what areas you should focus on to improve your collaboration capabilities.
The purpose of the session is to help participants put some structure around the thinking and to help develop a roadmap for maturing collaboration at their workplace.
-
-
keyboard_arrow_downNaresh Jain - Improving the Quality of Incoming Code
25 Mins
Talk
Intermediate
Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.
Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.
By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.
-
-
keyboard_arrow_down
Naresh Jain - Lessons Learned by Quitting TDD
25 Mins
Talk
Advanced
By working with some of the most successful tech-product companies, I realised that code is NOT an asset, it's a liability. We should strive hard to minimise code. In 2011, when I started to hack on ConfEngine, I questioned my belief in TDD. I had also started playing around with APL style Array-Programming and Functional Programming. I felt, may be, I was getting a bit too dogmatic about TDD and automated tests in-general. As a thought experiment, I decided to build ConfEngine without ANY automated test. At first, it was really scary not to have the safety-net of automated test (something I took for granted for almost a decade.)
As I scaled ConfEngine without any automated tests, I had certain interesting realisations:
- How to embrace Simplicity and Minimalism WITHOUT automated tests
- Why Throwing Away Code frequently helps you achieve a better decoupled-design and how this helps in better experimentation
- Fear of Refactoring WITHOUT Tests is over-rated (Good IDE and safe-refactoring techniques can take you a long way)
ConfEngine grew from a pet-project to a 8 member product team. It has over 60K users and has done financial transactions worth over half-million USD. And we continue to push forward without ANY automated tests. Its not perfect, but it has certainly helped me challenge my dogma around TDD.
Background: In 2001, I stumbled upon the Test Infected paper. For the next 2 years, I struggled to really apply the test-first concept on real projects. Finally in 2003, I felt that I had fully internalised TDD and was able to apply on almost all projects. Then I started playing around with FIT and FitNesse, using ATDD on some of the projects. In 2006 I published "Avatars of TDD" paper in which I explained various styles of TDD and its design implications. Until 2011, I was a very big advocate of TDD, ATDD and BDD. I still like those practices, however I would not recommend it in all projects.
-
keyboard_arrow_down
Craig Brown - The attributes of good management
25 Mins
Talk
Advanced
In this session, I will be describing what good management looks like for agile teams and organizations.
I will present a handful of frameworks for thinking about management, and marry them up to my observations over twenty years of managing experimenting on people in technology-oriented businesses.
I will present examples of good management practices and challenge a few assumptions about what good management requires.
-
