What we're saying no to?
Hey!
Welcome back to another week of musings. We're waking up sad because the 49ers lost the Super Bowl game. If you're a Chiefs fan, congratulations!
Anyhow, onwards with today's topic!
Was this forwarded to you? You can subscribe here!
Have you ever been on a team that starts more than it can finish? Or even you, do you agree to more work than you can get done?
Don't Overpromise
If you or your team tend to agree to start new things constantly, the struggle to wrap things up raises considerably. Another aspect is that you're spreading too thin, and any change in schedule, sickness, or time-off can throw your plans out the window.
You're putting yourself in a position of underdelivering, and that breaks down trust. Or if you're attempting to keep the commitments, you might be on the road to burnout!
Limits
You'll generally read about limiting work-in-progress (WIP), a strategy used since manufacturing (which Agile appropriated).
Back in college, I had to read The Goal, which talks about this in more of a fictional story type of deal.
You want to apply back pressure to the incoming tasks so you never hit a bottleneck in your team. You'll need to iterate on your team's limit, but you might want to limit it to 80% utilization in a team setting. You might want to restrict to the smallest or most critical team in large projects, etc.
Why we don't say no?
Applying the previous theory is how we tend to solve this problem of over-promising.
It's more interesting to me to understand why we reached that point in the first place. In other words, why don't we say no? Over the years, I've encountered different cultures around this issue.
Team Players
The first culture is where all are considered "team players," we're trying our best, and nobody says no. This is hard to reverse because you'll be seen as a dissident by saying no.
Ever-present escalations
In the second culture, saying no creates a whole set of escalations to upper management. This is the extreme of the above, where anyone that says no ends up in a meeting with Directors+ explaining your reasoning. This gets tiring fast; if you're in this situation, you either "accept fate" or leave.
It'll get done when it gets done
The third culture I've come across is more of a cynic approach. People tend to think that stakeholders give unrealistic dates but don't do anything to fight back. Work gets into the backlog, and the team is consistently "behind schedule" because the dates were incorrect.
I didn't like this because the teams always felt behind schedule or consistently failing, and it's a hard feeling to shake off.
What do we say no to?
Have you ever paid attention in meetings and noticed what leadership says no to? It might be work categorized as "tech debt" or engineering-focused. They might prioritize security features and vulnerabilities.
The thought exercise would be to frame your reasons for saying no under terms that leadership would agree with you.
Conclusion
Limiting work in progress is an effective technique to deliver your commitments consistently. While WIP sounds easy or logical at face value, culturally, your origination might need to be more open to accepting people doing pushback.
Your Turn!
Have you ever had to say no? Have you had support from your manager or leadership? Let me know by replying to this email!
Happy coding!
Things I discovered in the past week
- I've been back on my usual stuff and found another note-taking app that seems like Roam Research (or Obsidian) but has better iOS and MacOS apps.
- I'll be trying out the trial and see how it goes.
- A distributed systems reading list provides a reading list and quick definitions for various concepts related to distributed systems.
- I was looking for something like this to discuss with a mentee who wanted to move from front-end engineer to back-end engineer.
website | twitter | github | linkedin | mastodon | among others