The rules of an organization develop primarily through case law – the collection of existing decisions that, together form the rules of operation on a team or at a company. There is a thin foundation of explicit rules and regulation that guide how work is done, but built on top of that is months and years of precedent that guide the expectations of teams and individuals for how problems will be handled and how decisions will be made. This case law answers questions like “which team will be responsible for an incoming bug?” “what are acceptable reasons to miss a deadline?” or “when have I gotten sufficient approval to move forward with a major refactoring.” Awareness of, and an ability to manage this case law is a key skill for Senior Engineers and Engineering Managers who want to operate effectively within an organization.
One of the ways that you can use this as an effective tool is by choosing your fights carefully. Any time you escalate a problem to someone with more organizational authority, either explicit authority like a higher level manager or implicit authority like the resident expert in a particular system, you are inviting them to establish a precedent for how similar issues should be resolved in the future. When I was working at Tableau, we would frequently get defects that arose from the messy interactions between subcomponents of the system. Most often these issues would get triaged and routed through interactions between individual front-line managers, but occasionally the routing would become contentious and require some conflict resolution from directors, or on rare occasions VPs. I found it extremely productive to choose which defects to escalate carefully – I never wanted to make someone with little context on the matter need to consider things too carefully, and I did not want a murky defect to lead to a similarly murky example. Instead, I would escalate issues that had a simple narrative around them, and that cleanly highlighted a difference in opinion that needed a higher authority to resolve.
I also tried, when possible, to escalate defects that reinforced the principles that I was promoting. My team owned a lot of core and legacy behavior, and a major disagreement that would crop up was when a defect was found in the interaction between one of these legacy features and a shiny new feature developed elsewhere. It was important to me that those defects be owned by the team doing the shiny new work, and so when there were disagreements, I made a point of escalating the issues where the legacy behavior was most obviously correct. I would rather quietly settle a few small defects between me and my peer, or offer to fix issues in their code, than risk a proclamation from above that there was a sudden organizational appetite to rework existing baked functionality.
Perhaps this approach seems untoward, but I did, and still do think it’s a necessary approach to helping leaders further up the organizational ladder from me make the right decision. Using my local expertise to help provide the clearest example for them to decide, lets my leadership work more effectively and not risk them being distracted by an overly ambiguous case study. It’s similar to how Supreme Court cases are sometimes chosen to highlight a more sympathetic case, to avoid a decision based on personal character rather than the applicable law.
On the other side of the discussion, it is critical for managers to be aware of the case law that their decisions create, and decide accordingly. You are never just approving travel for a single employee, you are setting an example for the rest of your organization, and they will expect the same opportunities for everyone. You are not just choosing where a single defect is being sent (unless you are choosing to personally route them all).
It can be beneficial to overcommunicate the reason for your decision. That way others can apply the same reasoning in the future, and get to the same result – that said, you will lose credibility if you can’t stick to your own rubric the next time someone comes with a similar issue, and you might find yourself looking for increasingly thin exceptions to justify why “this time is different.”
If you don’t provide your own explanation, you might find that others do it for you. In the worst case, your team might think that the answers are arbitrary or made for harmful reasons, at best, you will find people trying to reverse engineer your thinking from the decisions you make, with varying degrees of success.
Embracing decisions as policy can be a great way to bootstrap guidance as well. I’ve found it useful from time to time to explicitly avoid providing guidance when a new situation comes up: We just released a new feature, what’s our bug bar? I don’t know. Bring the defects to me and we will decide them one by one for a bit. Once we have built up a dozen or so, the bar will emerge, and we can codify the policy by describing the ad-hoc decisions we’ve made.
Ultimately, it’s not your choice that individual decisions from leaders will be treated as a sort of policy. This is a thing that just happens, but knowing this, you can choose to use it to your advantage. You can make your decisions intentionally consistent, and help others understand their internal logic. On the other side, you can ask for decisions that lend themselves to a favorable consistency, and help the organization as a whole build a logic that resembles your own.
Leave a Reply