It seems like a simple question. “Can I expense these headphones?” or “Can we write this service in Elixir?”
The person asking may have a good reason. They may have an excellent performance history. The request is simple; why not grant it? You are an experienced Dev Lead, the proposal seems reasonable and you want your team to like you.
We may make dozens of small decisions each week without considering their implications. These decisions, however, unintentionally create policies for our team or our organization that we will have to contend with later.
A simple expense decision for a single team member often doesn’t make sense when applied to everyone on the team. Your rationale for granting the first request rings hollow when denying it to someone else. You may or may not realize that your decision violates a company policy or has unintended consequences for the finance or legal teams. When challenged by these teams, you are forced to rescind your decision, thus disappointing your team member and suggesting that you aren’t empowered to make these decisions.
Allowing a developer to use a new language to write a service may let them grow their technical skills. It quickly becomes problematic when other developers on the team want to use different languages, and your codebase becomes increasingly challenging to maintain.
Each request you grant or deny is inevitably shared with everyone on your team and with other teams as well. When it is shared, the details and reasoning behind the original decision are often lost. When a second person comes forward with what they think is a similar request and you respond differently, it suggests that you act capriciously or play favorites. When a person on another team asks the same from their lead, using your decision as justification, you put that Dev Lead in an awkward position.
Some companies give a lot of autonomy to their leads. This freedom helps teams to move faster and gives them more ownership and accountability. However, suppose the leaders in these teams make inconsistent decisions about travel, benefits, job offers, promotions, or software architecture. The result is eventually chaos. To the company, it seems that the leadership is uncoordinated and full of conflict. Lacking any clear reasoning on why different teams do things differently, people create rationales, which are usually wrong and can sometimes assume the worst in management.
As inconsistent leadership produces increasingly low morale, the result is often an overcorrection: senior company leadership creates new, excessively rigid policies to clear the accumulated management debt. This correction can often feel like “the hammer coming down” or a startup suddenly feeling “very corporate.”
Even if the problems and corrections aren’t so extreme, these simple, beneficial actions will help you to be more consistent with your peers.
When there is a new situation
If someone on the team approaches you with a novel request, do not give them an immediate, definitive answer. Instead, let the person know that you will investigate and get back to them. If you have established company policies for expensing, remote working, software architecture, or something else that may cover the situation, check there first.
If the answer is not definitive, raise your intended response to your manager. If it is about benefits or expensing, include the most appropriate HR representative. This step may seem unnecessary at first, but if you are clear that you are trying to be consistent with others, that should help your team member to understand.
When you want an exception to an existing policy
If the issue isn’t new, but you think the situation warrants an exception to the policy, you need to think carefully. The exception may be wholly justified, but will this invite more people to seek exceptions? How can you clearly and objectively state the reasons for granting this exception? How will you update the policy to carve out this specific exception? While it can be uncomfortable not to give an exception to someone you think deserves it, it may be the right decision in the long run.
If you wish to create an exception to an existing policy, let the person know that you’ll need to discuss it with management due to the current guidelines. Document your reasoning for the exception and share it with your manager and, if relevant, someone from the people team or HR department. You’ll need their support and approval.
Document the decision
If you decide on a new policy or are changing an existing policy, it is good practice to document the decision and share it with your peers. A simple one-page document describing the situation; the thought process on the resolution; the existing company policies or other peer decisions that influenced this choice; the decision itself; any caveats around the decision; and the outcome for the individual affected.
Share this document with your peers. You may choose to get their input before finalizing the decision since it will affect them as well. Again, you are creating a precedent.
If you are looking for a specific template, the Toyota A3, the Spotify DIBB or for software architecture, the Architecture Decision Record are documents that many organizations use.
Suppose you are part of a particularly transparent organization. In this case, you may want to share a redacted version (to protect the individual’s privacy) with the rest of the organization. Over time these decisions can be collected and refined into a new handbook for your organization.
Isn’t this overly complicated?
This suggested process may seem more complicated than it needs to be. “To make a simple decision about expensing headphones, I need to consult the employee handbook, ask my manager and HR, write up a one-page decision document and then send it to my peers?” It does seem like a lot of work.
Consider the alternative.
In a one-on-one, someone from your team asks if they can take a vacation for two weeks right before the team’s big deadline. When you say that the timing is not suitable for the team, they tell you about their friend on another team who was allowed to do precisely that. Talking to the other lead, they say that they didn’t think it was a problem. Do you now become the mean manager that doesn’t let people on the team take a vacation, or do you put the team’s commitment in jeopardy to be consistent with your peers?
This scenario may seem far-fetched, but it happens all the time. Especially in scaling organizations that move from being a relatively unconstrained startup to a more structured company. The best thing for everybody on the team is for managers to be consistent, and to be consistent, they must communicate.
For your organization, you may find more straightforward ways to communicate decisions and achieve consistency between leads. If so, please share them!
