“Because I said so!”
When asking why a project needs to get done or a deadline needs to be met, there are very few unacceptable answers. Sentences like the following drop into that unacceptable bucket for me:
I don’t know, just get it done
If you don’t, I’ll find someone else who will
The client said they’re going to bail if we don’t
Please don’t ask questions, just do it

While this is just a small list, I’m sure you’ve encountered unsatisfactory answers to why something needs to get done across your career.
Good leaders give business context when asking for a change in priority or a tough-to-hit deadline. By giving business context, leaders are granted an opportunity to coach those doing the work on how to prioritize or how to optimize in a given situation. The goal of giving more business context is to help individuals make better decisions autonomously.
If an engineer knows the why behind interruptive or deadline-driven work, they can make better decisions around scope and how to complete the task within the timeline. If they don’t have the context, it could lead to poor decision-making, conversation churn, and create an overall unpleasant experience.
I’m sure some folks I work with sometimes get annoyed because I consistently ask for data, dashboards, or forecasts to help our team understand requests. It’s all to help my team get more clarity on the business need around why something is more pressing than pre-planned work. It’s not inflexibility, it's business curiosity.
If you’re asking for a change in priority but can’t articulate why the change needs to happen, do the additional legwork to figure it out. Stop gatekeeping information and help your teams understand the business context of what you’re all working toward.
Have you ever had to deal with a “because I said so” ask? How did you deal with it?
Helpful Links From The Week:
The Seven Dispositions of Task Management - Rands in Repose - I felt both seen and attacked in this one. Definitely have too many tasks in the IGNORING stage.
Google to cut down on employee laptops, services and staplers for ‘multi-year’ savings - CNBC - With many companies making cuts, it’s interesting to see where MAANG companies are trimming. Sounds like staplers are still safe at Google though.
“The Rehearsal” Demonstrates How Algorithms Are As Imperfect as the Coder - Jamie Cohen - One of the most intense versions of thinking through a conversation prior to having the conversation is on full display in this show. It seems a bit outlandish, but Jamie Cohen walks through how to apply The Rehearsal to algo learning.
Behind the Scenes with Two New Salary Transparency Websites - The Pragmatic Engineer - Pay transparency continues to pick up steam and I think that only leads to a positive change overall. Keeps all sides honest and will hopefully lower wage gaps across the tech industry.
How to run a shadow library: operations at Anna’s Archive - Anna’s Blog - Always love a look at tools used for sites, architecture leveraged and overall thoughts in approach.
How To Do Hard Things - Acceptance and Commitment Therapy - Casey Rosengren - Hadn’t heard of this previously, but especially the section on Inaction → Committed Action looks helpful.
12 ways IT leaders can build business buy-in - CIO - I continue to find #3: Be fluent in the language of the business units, to be incredibly important for broader business discussions.
What I’m Reading: Boring Meetings Suck - Jon Petz
I’ve read this one before, but it’s worth revisiting. The subtitle “Get More Out of Your Meetings, or Get Out of More Meetings,” is something I think about frequently and am admittedly still bad about. If you read no other section of this book, take a look at “Agenda Item 4: Why Everyday Office Meetings Suck…Skip This and You’re Screwed.”
Petz is pretty aggressive about his disdain for meetings and what to do about them, but any change made because of it will likely be a positive one.
Anything in particular you are doing to stave off meetings? Let me know below!