It’s easy to get frustrated when your team is making decisions you don’t agree with. They’re picking the wrong tools, the wrong level of complexity, or decide to do that rewrite despite the unpredictable effort and likely ballooning scope.
First thing to accept is that different folks have different preferences, different mental models in how they make decisions, and a different set of experiences that has led them to make these decisions. If it’s your goal that your team make the exact same decisions you would make, you’ve got a couple of options: don’t hire anyone, do everything yourself, or hire people with the exact same set of experiences you already bring to the table.
You can certainly make all decisions for your team, but in return, you won’t have time to do much else. Your team is likely going to feel disengaged from the work and experience decreasing levels of creativity and innovation, as everything’s coming from you.
A more productive step is to look at what information, assumptions, and expectations they had at the time the decision was made. While you can’t change these for past decisions, you can adjust all three dimensions for future and hopefully better decisions. That is assuming you don’t want to be involved in all of these decisions yourself.
In a recent conversation with a client, a scale-up CTO, we talked about this in terms of their philosophy, which is defined as being their approach to making decisions. It’s an amalgam of the parameters they look at, the stuff that’s important to them, and the stuff that isn’t. We tend to describe these in more generic terms, as context that’s shared with the team.
If you want your team to think about certain boundaries or parameters, as they make their decisions, a philosophy spells those out, like these examples:
1️⃣ Build vs. buy: Describe the trade-offs you weigh when you think about buying vs. building in-house.
2️⃣ Shiny vs. reliable and boring: Your engineers might be prone to choosing tech they prefer over tech that’s sufficient. If you want them to think outside of the confines of their personal preferences, asks them to consider at least one more alternative approach as they make decisions and weigh the pros and cons.
3️⃣ Simple vs. complex: Is quick iteration on small prototypes preferred over building large solutions first and then testing them once their done? Do you prefer smaller pieces of code over large creations?
4️⃣ Centralized vs. autonomous: What decisions do you need to be involved in? What decisions is your team able to make?
A philosophy is similar but not quite the same as a set of values, or a vision, or a set of processes. It’s like a personal readme but not quite. It’s more about supporting the people around you in doing their best work. It’s a set of parameters that outline what you consider a good decision, an input to all of these and all those decisions your engineers make week over week.