One thing people often get wrong about software work is stakeholder management, and one thing people get wrong about stakeholder management is minimizing surprises.
This is actually pretty simple. There’s a design principle known as the Principle of Least Surprises (or Astonishment), which generally states that the behavior of a product should not surprise users. Surprises are bad.
The same principle carries over to project execution and stakeholder management. Generally, any project you work on will have stakeholders:
- Colleagues you work with directly. If you’re an engineer, this might be other engineers, product managers, designers, etc.
- Other teams that have dependencies on your work (ie your work must get done so their work can get done).
- Other teams on which your work depends (ie their work must get done so your work can get done).
- Company/team leadership.
- People who are inexplicably (from your perspective) excited about or worried about the work you’re doing.
You’ll be a lot more successful, and build a lot more trust, if you minimize surprises with these stakeholders.
Form a mental map of who your stakeholders are, what sort of information they’d want to know and what cadence, and make sure they’re never surprised. For example, it’s bad if your work is delayed, it’s much worse if that’s a surprise. It’s impossible to create zero surprises, but you should be creating near-zero surprises.
And keep on the lookout for unsolicited “checkins”, which can be a leading indicator that people are worried you might surprise them. This isn’t always true, sometimes people just need a status update or a piece of information, but if you’re communicating well and proactively, and people trust you to deliver, the volume of unsolicited checkins you get will be very low.
Somehow Manage 