Every decision creates a policy
Hola món! (“Hello World!” in Catalan)
Welcome back to the newsletter, and thanks again for reading/subscribing. Please share with anyone you think would appreciate it!
I plan to write more new material for you all, and I’m eager to hear what subjects you’d like me to cover. The survey provided some good suggestions. If you haven’t had a chance to take the survey, please do so, or you can e-mail me (info for both is below).
If you are new to the newsletter, please check out the archives on Substack. Of course, you can always buy the book.
New Blog Post
Creating the newsletter or podcast every week and promoting the book has seriously impacted my blogging frequency, but I published a new blog post a few weeks ago: “The CTO’s Guide to Crafting a Technology Leadership Resume.” I wrote it after reviewing multiple resumes of senior engineering leaders I mentor who are considering switching roles in the next year and finding that I was giving the same advice to all of them.
About this newsletter
What makes this newsletter unique is that every two weeks, I share a chapter from my book It Depends: Writing on Technology Leadership 2012-2022, which Unit Circle Press released in March of last year. These chapters are not sequential; each is a standalone piece. In addition, a podcast serializes the audiobook in order, released alternate weeks from this newsletter.
The Latest Podcast
The latest episode of the podcast is “Building a Management Training Curriculum at Avvo.” It follows the previous episode that covered the team structure we created at Avvo and the self-selection exercise we used to re-org from the bottom up. I shared this chapter in the newsletter back in March of last year. The episode goes into much more depth about the actual manager training we created at Avvo after we created the curriculum, so it is worth a listen, even if you read the newsletter, the chapter in the book, or the original article.
You can download the episode from Apple Podcasts, Spotify, YouTube, directly via the RSS Feed, or wherever you listen to podcasts (see pod.link for a more extensive list).
Send me your questions about being or becoming a CTO
Do you want to know what it is like to be a CTO? Are you already a CTO and having some challenges? Do you want to understand the C-level career path better? Please send me your questions! contact@itdependsbook.net. You can also add them to the chat on Substack or in the comments for this post.
Reader Survey
I’m thinking about what happens to this newsletter and the podcast after we complete the book. I want your help! Please complete a very quick and anonymous survey to help me out.
About this week’s chapter
The title of this chapter is self-explanatory. It covers an essential lesson that engineering leaders often don’t learn until they’ve made some mistakes. In my mentoring, I repeat this admonition more often than I would like.
In larger companies with little autonomy, this is usually not a problem because managers quickly learn that they need to validate any decision with their managers or HR before talking to someone on their team. However, it happens all the time in smaller companies because there are usually fewer policies, and how things work is assumed to be common knowledge.
This is chapter 14 of It Depends.
Every decision creates a policy
Originally published on July 26, 2021
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 manager, 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 manager 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 employees, it seems that the leadership is uncoordinated and full of conflict. Lacking any clear reasoning on why different teams do things differently, people will try to invent 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, there are the Toyota A3, or the Spotify DIBB. 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!
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores