Decisions, Decisions, Decisions!
Sugendran Ganess
Head of Engineering at Ordermentum, formerly at Culture Amp, Skyscanner and Yammer
I have so many thoughts floating in my head about decisions. Which decisions are team decisions? Which decisions should get made top down? Why do some decisions take longer than others? The following is a bit of a brain dump with the hope that I can spark some conversation. I don't think my model is perfect, and without feedback it won't improve. So if you see something you think could change please call it out.
It all starts with this wonderful presentation about coordination headwinds and how organisations are like slime mould. It's a great breakdown on the cost of coordination and that perhaps we shouldn't try to force this in organisations. Whenever someone talks to me about standardisation or sharing of solutions I think about this presentation. I think about the slide where each team has many things on their plate, each with a level of uncertainty and each getting a percentage of effort. I think about the poor team that starts with a small problem and then is told they need to solve this for the company by picking up some extra scope. Are we fighting the slime mould when we're doing this? Should we just leave the team to do what they need to do? How will we align on common solutions and reduce waste? It's tricky.
I then think about this blog post that leads with “Those who should decide on the architecture are those that will be on call for it” - and I find myself agreeing with that. We want teams to be accountable for the decisions they make. It's hard to argue that the team is not accountable when they're handling the pager at 3am for the decisions they make. The other side effect of having the team make the decision is that they're comfortable with the decisions they've made and will be willing to work with that system rather than against it to get changes in. This doesn't mean we don't support the team, or provide insight or experience. When I talk to other engineering leaders about this approach the immediate push back I get is that teams will make choices that don't line up with the company's architectural vision. Instead, I think we should be making sure we're framing the problem correctly. If your solution differs from the team's solution, maybe you're solving different problems.
Lastly, I think about global decisions versus local decisions. Not my terms, it's something that came out in a conversation I had this week. A team decision is local - the context and impact are understood locally by that team. A global decision on the other hand has a wider impact, probably has a wider context and needs to be understood by many teams. I keep seeing local decisions getting converted into global decisions that take a long time to solve and build, and I've been trying to work out why. My thinking is that global decisions require a greater consensus on the problem being solved, and aggregating that problem across teams means we might not solve for everyone, or if we do then it might feel like we're boiling the ocean. It's an easy place to land, you see two teams working on the same or similar problems and you say to yourself they shouldn't be wasting effort like that, so you intervene and ask one team to solve for both - I know I'm guilty of doing this in the past.
The place I'm landing on with these thoughts is that we should favour local decisions over global decisions. We should promote local decisions that we think could work globally, and do this via deliberate efforts, for example, enablement teams. We need everyone to align on the same set of constraints for this work. We need everyone to align on the WHAT and the WHY, and then leave them to solve the HOW. This is probably explained with an example.
Let's imagine we have a team that needs to build a new reporting API. In this company most teams have built these APIs using protobuf over HTTP, but this team decides they want to use GraphQL because it's better suited to their use case. Now the immediate reaction would be to say no, just use protobuf because we want to have commonality across our APIs, but let's pause and look at the constraints. I can imagine in this company there is a default that all APIs provide a typed interface, that clients can be generated from this interface. These would be the WHATs. The reason for these defaults is that we believe in decoupling our systems via contracts and want to minimise the toil for systems to consume these contracts. This is the WHY. The GraphQL vs Protobuf is a question of the HOW. With just those constraints, there are many technical options that would be valid, including the team's choice. So let's add another, the libraries and tools we use must have an established community so that engineers can get readily available help on their questions, and so that future hires can bring their experience using it. That narrows the field quite a bit, and I'm hoping you get the idea.
领英推荐
These defaults in the company need to be declared upfront, and it's guaranteed you won't have them all correct to start with. As teams start to make local decisions you'll no doubt realise other constraints you had not thought of. Being transparent about these constraints helps teams to make decisions.
The natural thought after this is that teams are all going to go off and create chaos. That's entirely possible, but I think we can temper that. Do they have a prior example they can copy? Is there a path of least resistance that teams can take? We can establish these things via enablement teams. These are teams that extract best practices from decisions that have already been made so that others can leverage it. It's the shortcuts that you build into your system to help teams meet the defaults for your company. Even with these defaults, it may still be reasonable for a team to go off the path, and that's okay as long as it's a deliberate decision. A decision they make knowing the constraints and the tradeoff they're making, and it's okay because the team is the one with the most context, the one who has to live with the decision, the one with the most skin in the game.
So to summarise:
I don't think my model is perfect, and without feedback it won't improve. So if you see something you think could change please call it out.
Co-Founder / CTO @ Released. Building great software with great people.
2 年Rings true! Local decisions keep you fast and your arguments are sound. Local decisions can be promoted at any time, if they are made with the potential for global scope in mind. I think about it similar to how I write code: code should generally be written so that it _could_ be reused if a similar case crops up again, but that doesn't mean all code must be reused or even should be reused. You will likely need to tweak the code or tweak the local decision to promote it to a wider scope, but if you are writing with a little bit of respect paid to the possibility of reuse (separating concerns, good commenting at the switch and if statements that would need to change to extend to a new use case, etc) it makes it much easier. I think this is where your "Do they have a prior example to follow? Is there a path of least resistance?" questions are answered - previous local decisions are the examples and cowpaths that make global decisions easier in the future. Re: protobuf vs GraphQL, could be a design decision if these are public APIs. Every team choosing different tech would mean a more complicated API for consumers. I agree that upfront specification of those kinds of constraints (or non-goals!) is important. Nice thoughts, mate!