Principles over Process revisited
In this newsletter I want to revisit the topic of Principles over Process once again and dig a bit deeper than previously.
Way back at the beginning of Thoughts Unravelled I wrote about Principles over Processes as a way to stay focused on the right things, reducing complexity and actually staying agile/adaptive. You can read more here.
Since that time, my thinking and experience on the topic have matured, but I’ve also gotten a lot of questions on what exactly I meant and how it actually works in a more practical sense.
In this issue, I hope to dispel some of the confusion and hopefully give you something more concrete to try and apply in your own organisation.
First Principles or Principles First?
Yes! It’s exactly that. As I mentioned in my previous letter, it’s strongly related to the concept of First Principles, but it’s also the first thing you should do in the process.
Defining the principles does not need to be a complicated exercise. In fact, the simpler, the better or they just become documentation to never be used again.
Step 1: Starting out
Start of by just laying down the main principles that you want to set as guidelines:
- What do you want to happen ex. Always focus on what you can solve for the customer
- What don’t you want to happen ex. Don’t bring your ego to the conversation
At first you may have a large list and that’s okay. You will potentially see some overlaps and that’s okay at first.
Step 2: Cleaning up a bit
Now we need to reduce the principles down to the minimum possible. As a rule of thumb, I suggest striving for a maximum of 5 principles, especially if it’s the first time you’re doing this exercise.
Also, depending on the context you will easily see whether it makes sense to have more or less.
But too many principles become unrealistic. Imagine every time you need to make a decision, having to remember 10 principles to see if you’re aligned with all. Rather group them under top level principles that are almost like a quick reference card.
If I can confirm I’m adhering to the principles in a couple of seconds, that’s the best way to keep them.
Step 3: Applying
Once you and the team have decided on those principles, you need to define how you’re going to make sure they are adopted and used regularly.
I’ve seen the best results when it becomes a regular part of everyday life almost like a mantra.
Any time there is a deck related to the topic, just a simple slide that brings up those principles. The landing page of your confluence space. In the interview and onboarding processes.
Integrate as much as possible.
Step 4: Continuous improvement
Especially when you first develop those principles, one of two things will happen. You strive to make them so perfect that you never finish them or you put together the first version accepting that they won’t be perfect and will evolve as you learn.
I always suggest the latter. Evolve them slightly as the 1st year evolves and then do a proper retro after that first year and decide whether you need any major changes.
If done right, as you go through those changes, the team is also adopting and accepting them. Avoid making big changes too often. For big changes, I suggest a yearly cadence.
At this point what you’ve created are guidelines that are adaptable to each person’s personal way of working and thinking. As long as they are applying those principles, the how isn’t as important.
Ok, but is there ever a process?
The answer is definitely yes. We will define some processes and ways of working, for sure. The principles are just the start of the process.
This is an important part to getting this right, we should avoid overly robust and defined processes. I’ve lost count of the amount of times I’ve seen a process being a blocker to agility and innovation.
Rather focus on identifying the key connectors across a process. Where do the different individual processes need to meet, communicate and work together?
I like to use the example of having a North Start Metric, Input Metrics, OKRs and Initiatives. Try to engineer how they work with each other too much and how the teams report on each, makes for a complex planning process.
However, if we define the metrics and tell teams they need to provide the numbers on a specific date, the rest of how and when they do it is open for the team to define in a way that works for them.
Disclaimer though, there will be times where we need to jump in and help a team define their process. Not because we want to micromanage, but because they may not know how to approach the situation, especially with a less experienced or less mature team.
At the end of the day, having a process that is too engineered is actually a form of micro-management. Rather create the constraints to help the organisation succeed with enough space to adapt to hedge cases or complicated challenges.
Principles in practice. A Practical example
A great and simple example is looking at OKRs (Objectives and Key Results). In most organisations, the cadence for OKR setting seems to be quarterly (I know this may vary, but for this example, let’s use the 3 month cadence).
Now, if I lay down an end-to-end process of how OKRs work, how to develop them, write them and then how to report them, some teams will be okay with the cadence, while others may feel overwhelmed, because the 3 months cadence seems too regular to do anything properly.
In most cases, we will see many people rushing at the end of the quarter to close the previous quarter’s OKRs while simultaneously developing the OKRs for the next quarter.
Applying Principles over Process
Without changing much, we tell teams by date X we transition from this quarter’s OKRs to the next quarter’s OKRs.
But, now we add a set of principles along the lines of: (Only example)
- Objectives can and should span more than a single quarter
- Key results need to change every quarter
- We prefer less KRs but at a higher quality
- Make sure you’re aligned with all stakeholders
- All KRs must be measurable in some way
These are just off the top of my head, but what we are telling folks is that these are the expectations, but how each team approaches this is up to them.
Equally with reporting, we may tell them it needs to be updated monthly, but then each team or domain may decide they want more regular check-in or discussions. That’s up to them.
What is important is that we get the information when we need it and then are able to make decisions on them. We’re not saying they need to use a spreadsheet or software. We’re saying that information is needed and their responsibility is to provide it.
This can be applied in so many other ways. This is just a simple example.
What’s stopping you?
I’m actually not asking you why you don’t just start using Principles over Process. I want to discuss some of the blockers I’ve seen to achieving success in this approach.
As a starting point, the first principle you should try and implement is Principles over Process.
Little or no commitment from leadership
I won’t lie, it’s much easier if most of the leadership is behind this way of working or at least your highest leader. They will partner with you and help you achieve success.
But ultimately, it’s a hard ask, because we’ve become used to adding frameworks, processes and complexity to our ways of working.
Most product teams want to be Agile, but ultimately want to make sure they’re super prepared for every eventuality.
But, even with the most unresponsive teams, the work can be done to move towards achieving a practices first way of working.
I find the best way to approach this is using language the team is used too. Let’s experiment before creating complex and rigid processes and documentation.
Usually, if you manage to make it work, they don’t feel as much need for that documentation. If they ask for it, tell them you’re still not there and you will need to experiment some more.
Get them used to an ever shifting approach.
Too many conflicting practices
I’ve mostly seen this in both tech led organisations and enterprise level organisations but could happen at any level.
As any system evolves, people have a tendency of trying to maintain control, so they develop processes and practices. But as the organisation grows, they add to the existing processes which adds extra complexity. Very soon we have no notion how we got there, but we have a complex system run by complex processes that in truth conflict with each other.
Another reason is based on creating safe guards for your team or function, so you ask for an extra form or signature. But then something goes wrong at another point in the processes, so you add another failsafe. This is how bureaucracy grows. We’re trying to protect ourselves.
In either one of these cases, these established processes will block being agile or innovative and they will challenge your attempts to focus more on principle first.
Again, experiment, question, push back or whatever it takes. Not to become yourself a blocker, but bring to light other ways of doing it.
An inflexible structure
Start small and show results, then scale to the next thing etc.
Just like conflicting practices, an inflexible structure isn’t built for Principles over Practices.
With this I’m not saying we should have a structured organisation and create stability for the teams. What I’m saying is that we need to create and organisational structure that at its baseline is as adaptive as our product needs to be.
What does this mean?
It means structure focused on the guiding principles you set for the organisation. Those principles, if adopted by the whole organisation will be the beacon by which all are guided. If I’m focused on a Principle along with a strong Vision, I understand why and when I need to adapt to market, industry or organisational changes.
If for example I know I want to help people reach their destination in a quicker, more care free way and my principles tell me I create only the most ecological products, it’s much easier to understand than I have to build the checkout using as many payment gateways as possible.
The first example is flexible, whereas the second fixes a person on a very specific part of the product.
This is a very loose example, but hopefully you get the idea.
This edition is a bit of a complex read and I just hope I managed to get across a more concrete example of how I see Principles over Practices.
As a simple rule of thumb, ask yourself, do I need overly complex documentation to explain it? Then it will probably go wrong.
We can never truly know everything that is going on in every corner of our organisation and trying to accomplish that is futile and pointless.
Rather accept the chaos if you will and design a system that connects the different aspects of that system at the right moments/points.
We will still need to step in and help some teams or individuals in defining their ways of working. Not everybody can be fully autonomous, but with this approach, those become the exceptions rather than the rule.
Empower people by rallying around principles!
P.S. Have anything to add or something that wasn’t clear? Please let me know!
This Newsletter is a passion project and I will always keep the content free for my readers. If you find it useful and would like to support the content, please donate with any amount