Saying No
Hey everyone! I hope you had a great weekend. I've had this topic in draft and keep trying to write about it but never fully finished my thoughts. I thought, well, better now than never.
Was this forwarded to you? You can subscribe here!
I've always been a "no" person, sometimes making me the bad cop of teams or projects.
Especially if your culture of "team players" is about having specific roles push engineering to work on only urgent things all the time. Or engage in death marches or whatever other reason people come up with to make them work on what they want, not what is feasible or essential.
I find myself learning that as I grow in my path, we're rewarded when we are good at articulating why we're not doing something over another thing. Or even not doing it because we don't have the capacity. Depending on the role, you might need to make it happen, deprioritizing another thing and being clear about that.
Most of the time, it's more like a not right now, and when available, go back to doing it.
Some people think it will get done if they're pushy about their ticket, user story, feature, etc. Others I've seen more resourceful redefine levels or requirements to appear as they ask something smaller, but it's only valid for the surface, and implementation will take longer than that.
Another set of people will "escalate" or pull as many people as possible into a meeting. Point fingers, and tell you why you're delaying their project, which is N priority in the company list!
Part of leadership is well, owning these decisions, articulating why not right now, why it makes sense to do it later, to sync with another project that might benefit from a similar effort, etc.
I've never been a people manager, but expectations are different if you tell a director+ they need to accomplish X goal. Generally, they're not allowed to say they can't do it because they lack headcount, etc. They need to make it happen if upper management asks for it.
Otherwise, ICs are generally allowed to restrict their work in progress and limit the things they focus on. It's more critical as we grow because you can only concentrate (realistically) on 1 or 2 things that would produce very high leverage across a large organization (e.g., 1000+ person org).
I've seen some people struggle with saying no, especially as we're bound to think we're not team players. I've noticed some folks never say no, but switch quickly, feeling like they're great help. Other times, with managers adjusting their immediate roadmaps, they "shift things around" without consideration of this or next quarter, for example.
The most exciting reactions come from people that can't take the no, either by not acknowledging it or ignoring it (¯\(ツ)/¯).
I find it odd, but I understand we're all trying to achieve our goals. Nobody is trying to be unhelpful, but we have to be realistic about the amount of work in progress we can have and be mindful of limiting it for the sake of our teams.
Your turn!
How do you generally say no to other people? Or teams? Or even, have you ever said no to someone? Does your company have a culture of saying no? How do you deal with limiting work in progress in your group?
Happy coding!
Things I discovered in the past week
- Nobody cares about your blog. It talks about why no one cares about your blog and how that's liberating to keep writing for your own sake.
- A thread about books on product management. I've read a couple of those, like The Effective Executive and Working Backwards.
- Average Manager vs. Great Manager by Julie Zhuo, author of the fantastic book # The Making of a Manager
- Engineering as Art: Embracing Creativity Beyond Science guide for staff+ about embracing techniques from disciplines outside of engineering
website | twitter | github | linkedin | mastodon | among others