To make good decisions as a leader, you need clear priorities, consistency, and a cool head.
You need to work out your principles of decision making.
How do you even start thinking about them?
Here’s an idea: take a look at the way other great leaders work out and utilize their principles of decision making. That should be a good starting point.
We bring you concrete examples, stories and warnings of all the potential pitfalls from James Trunk, VP of Engineering at Griffin. He shared his principles of decision making in an interview with Karolina Toth, on episode 53 of the Level-up Engineering podcast.
This blog post covers:
James is from the UK, but he's been living in Stockholm, Sweden, for years. He studied computer science and started his career in tech 20 years ago as a Java backend developer.
He turned to the management path while working at a company that grew from a small apartment to taking up two floors in a skyscraper during his time. Since then, he’s been taking on higher level leadership roles. He’s been CTO at a recruitment company, and currently James is VP of Engineering at Griffin, the UK’s first ever platform bank.
The basic formulation of my principles of decision making is, “I normally prefer X over Y.” In this case, I’ve seen X work well, and Y is an alternative that can lead to potential problems. Here’s my list of decision principles:
I don’t think my principles should be applied by everyone. For example, if you keep picking safe bets, you’ll probably fail to create a competitive advantage as a startup. However, in a corporate environment, safe bets might be a better path for your career.
I’ve been collecting my decision principles over time, and they’re based on my experiences. I’ve done a lot of reflection on what has and hasn’t gone well, and which principles have helped me make better decisions and which haven’t. They change over time, and I’ve been keeping track of them over the years.
I recommend every leader to come up with their own principles of decision making. You don’t have to treat them as absolute truth. Use them as guidelines that remind you to stop and reflect on whether you’re headed in the right direction.
The basic idea behind decision principles is to express what you’ve learned with clear language to make it easy to remember.
As you tackle different challenges during your career, you start to learn which strategies work and which don’t. At the same time, it’s easy to make the same mistakes if you don’t have a method to remind yourself of past lessons when making new decisions. Decision principles are a tool in your toolkit that state what you’ve learned and remind you of the dangers of certain paths.
Your principles of decision making also help you to communicate your values to the people around you. Sharing clear, concise, and constructive decision principles should help you to build trust early with a new team. They also help you align with your team and make cooperation more effective.
I don’t use my principles of decision making every day. They tend to come to mind whenever I’m facing a potentially dangerous choice.
When I’m making a decision with my team, our discussion often reminds me of my decision principles, and they’ve helped us to avoid common mistakes.
Basing decisions on opinions rather than data happens often. People get into the mindset that they know something, confirmation biases kick in, and you don’t even stop to question yourself, when you should be experimenting.
Changing a process can be similar. Treat the change as an experiment, and review what happens once you make it, rather than go all in based on predictions. In my experience, predictions are often wrong, especially when they’re connected to the complexities of software engineering.
Decision principles can help you when you get stuck in analysis paralysis—when you’re endlessly going over every possible option, weighing up the pros and cons. You can use your guidelines to push yourself forward and make a decision in the given situation.
Leaders are always exposed; they have to make public decisions and take responsibility for them.
When I first held a CTO title, making a decision about the technology stack felt like a big responsibility. My decision principles gave me some comfort in that situation, because I could explain why I decided the way I did, rather than just say, “That’s what I felt like.” Having clear arguments doesn’t make a decision right, but being able to explain your reasoning in detail can give you comfort and confidence as a leader.
I’ve stopped doing team value workshops, as they haven’t delivered strong outcomes in the past. It may be because finding values that a whole team can agree on tends to water down their crispness and clarity.
The importance of writing is huge in hybrid teams, so I’ve started sharing a manager readme when joining a new team. It includes my decision principles. The idea is to write about yourself to make your introduction easier in a remote environment.
I share my decision principles with my team as a way to find out more about my way of thinking and to help them communicate with me. They’re the Konami code to my brain. If you’re trying to sell me an idea, you can tell me, “This is how it’s simple, rather than easy.” That’ll get my attention.
I’m not forcing anyone to use my principles, I just share my values and why they’re important to me. I used to do a presentation with pictures to make them easier to remember. Once my team is familiar with my principles of decision making, I keep repeating the terms in different discussions, and my team starts to recognize the pattern.
At times, leaders need to make decisions that go against the consensus.
When you need to do it, it helps a lot to have the words ready that you need to explain the reasoning behind your decision. It gives you a better chance to say that even if others disagree with you, you have a good reason to think your option is better, and you can explain it based on your decision principles. It likely feels better for you and it helps you maintain psychological safety in your team.
I don’t bring them up as often around my peers or line-manager, as I tend not to need them as often in that context. They’re still useful whenever I need to justify a decision or explain a strategy.
I am forthcoming with my decision principles when I’m in the recruitment process for a new position. It’s important to have matching values between a leader and a company, and my principles say a lot about me as a leader and as a person.
I explicitly bring it up, go through them, and explain why I have them. I do this with the CEO, CTO or my manager. Your decision principles give you a tool to check for alignment when going into a new company.
Everyone in Griffin is open about the shared values within the company. My decision principles have a large overlap with the company’s values, even if they’re worded differently. I connected the dots between the company culture deck and my decision principles in my manager readme to show my team where I’m coming from.
When I’m recruiting others, I can rely on my decision principles to look for alignment in the applicants’ way of thinking. Decision principles can help you on both sides of recruitment.
We've introduced a new product process at Griffin, called Shape Up. Ryan Singer has an excellent book, called Shape Up: Stop Running in Circles and Ship Work That Matters.
When you want to implement a new process to your company, you need buy-in from everyone before you can get them to use it. I used my decision principles to make the argument for implementing it. You can’t just keep repeating your values and get buy-in from everyone, but you can build a number of arguments on them.
Decision principles aren’t silver bullets that fix everything. They’re an additional tool in your leadership toolkit. There are two types of mistakes that I’ve seen myself make, and others may be prone to them as well.
Following your principles to the letter can be a mistake; they’re meant to be guidelines. You can’t ignore the context of your current situation and always pick X over Y. It may have worked for you before, but situations can come together in a way that blindly following your rule can be a bad choice.
On the other end of the spectrum, avoiding to use your decision principles, or forgetting to bring them up when they’re relevant, can also be a mistake. When you’re trying to build trust, clarity and consistency goes a long way. Showing consistency by putting your principles of decision making on display is a smart choice for a leader.
This also means that when others bring you an argument along the lines of your own principles, you should listen to them carefully, and use it as an indicator to follow their suggestion. You can make a decision that appears to go against one of your values, but you need to be able to point out how the current context changes the priorities. This is the difference between flexibility and inconsistency.
I’ve overused my decision principle of innovation over safe bets in the past. I heard about the concept that startups should think of innovation as using tokens, and they shouldn’t use more than three to five tokens at the same time. The idea is to avoid trying to innovate on every decision and to balance it with safe bets.
I value innovation, but I used to push too hard for it. In my first CTO role, we innovated in many areas; we came up with a new architecture that we also open sourced. A lot of things could have gone wrong.
It worked out well, but that doesn’t mean I made the right decision; it may have been blind luck.
It all started with realizing that I wanted to increase alignment in my team. I was a product owner in a TV streaming company with a growing team under my leadership. I was working with an agile coach to improve the team’s alignment.
We decided to hold a value workshop, and we started researching how to run it. In my experience, expressing a value in a single word doesn’t help much when you need to make a decision, so we decided to steal from the Agile Manifesto. They formulate their principles in the X over Y format, giving you the flip side of the coin, and reminding you of what you want to avoid.
The team came up with a list of five shared values. This helped with alignment, but I don’t want to oversell it. We brought them up when making decisions, but it didn’t become an integral part of our daily work.
I keep a daily work diary as an engineering leadership practice. At the end of each day, I spend 15 minutes reflecting on that day and planning ahead for the next day. I found myself regularly reflecting on the team’s values.
They helped me make decisions and they gave me a clear language to communicate my values. So, I decided to turn these into my values rather than the team's values and see what happens. Over time, I adjusted them, added more, removed some, etc.
I ended up calling them decision principles, because while they’re based on values, their function is to help me make better decisions and to communicate my decisions more clearly.
I suggest starting with a brainstorming session with your team; it’ll give you great material. You get many ideas and common values out into the open that you may not be able to come up with alone. My decision principles originate from a team brainstorming session as well.
When it comes to working out your decision principles, follow up the brainstorming session with self-reflection. You may have values that you don’t share across the team. Only keep decision principles that are based on your thought process and experiences; these only come out when you spend time reflecting on yourself and your past.
A leadership diary may help you do this along the way. Writing the diary daily is a reflective practice, and when you do long-term reflection sessions, the diary can remind you of what happened over the past week or month.
My leadership diary drives changes in my decision principles.
A diary comes into play when I’m reflecting on the past week, and I go back to evaluate decisions, insights or challenges. This is when I’m looking for patterns, considering whether something similar has happened before. This is where a new decision principle may emerge, or I may need to update an old one.
I started writing a work diary while I was a product owner. I heard about successful people writing journals, but I ended up trying because as a leader, I was missing the short feedback loops.
Developers get feedback on their code from the compiler or their peers in code reviews. On the other hand, leaders make decisions that impact other people and the product, but they don’t receive much feedback.
The journal gave structure to my reflective time, which provided me with internal feedback. Internal feedback isn’t perfect, you can’t replace receiving feedback from other people. But you can use your journal every day, generate a lot of insight yourself and it has no outside dependency.
I split each day into four sections.
I write down every decision I make every day. It’s a reminder for the regular self-reflections. I take note of one-on-one meetings, their outcomes, and anything else worth tracking.
I record insights, which are usually ideas from other people. These come either from our collaboration that day, or from something interesting I’ve read or watched.
Challenges could be anything from the software, daily work, or micro challenges in the team that I need to examine from a broader context.
I keep a list of my top challenges in a different software. I usually track around 6-7 challenges, and I highlight 2-3 of them each week that I’d like to make progress on. I reflect on the results at the end of each week.
Finally, I will take notes of what’s happening tomorrow. I write down anything that I have or haven’t prepared for. It’s a great way to finish a day and get ready for the next day.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.