Some years back (cough c.2001 cough) I was at a startup across a change of senior technical leadership. The CTO, who was and is a friend of mine, left and was replaced by someone chosen by the investors. The replacement was – to be a bit rude – mostly useless. Much more “chief” than “technical officer.”
This fellow – who I only worked with briefly, and who’s name I’ve long since forgotten – ended up imparting something I’ve only recognized the real value of over time.
His “thing” was the importance of setting and managing expectations. Not just for managers, for everyone.
If you were on the hook for something, he was insistent that you tell the dependant party when you expected to deliver. He was downright millitant that as soon as you realized your estimate was wrong – regardless of why it was wrong – you told anyone who was depending on you.
If you couldn’t provide a new estimate, he insisted that you tell them when you would be providing that new estimate (a “date for a date”).
So if you were on the hook to deliver something by Friday, and on the preceeding Tuesday discovered additional work that put Friday at risk – he insisted you approach the party depending on your Friday deliverable on Tuesday and tell them your delivery was at risk. If you could give them a new date for delivery, great (“I think it’s going to take two more days, so I’ll be done next Tuesday”) and if you couldn’t, you needed to tell them when you’d come back with an estimate (“I’m not sure how big a disruption this is, I’ll get back to you by close of business tomorrow.”)
Acting this way gave people who depended on you options. They could look for ways to help you hit your your previous estimate (“if someone helped you with the thing that’s come up would that let us hit Friday?”). They could factor your change into their plans, and inform people who were waiting on them. If necessary, they could look for ways not to dependend on you.
Over time this “proactive transparency” would help the organization get better at estimation, and identify people and teams who weren’t getting better and figure out why and how to improve. Or at least that was the theory. The company ceased being a going concern not too long after.
This may all seem super obvious to anyone who started their career in software “post agile manifesto” but it certainly wasn’t representative of my experience in software up to that point. This was the first overt recognition I’d seen from “management” that plans change, and that how you handle that change is important.
Prior to that, dates were set in stone – and everyone pretended they never changed. (“So long as the bosses pretend to pay us, we will pretend to work.”) There was no accepted way to express that while hitting a target was always desirable, it wasn’t always possible. And by being up front about changes to your expected ability to deliver on commitments you could at least reduce the last minute negative surprise and resulting scramble.
This focus on setting and managing expectations extends far beyond software. I’ve been chasing the building manager about the lift for two days now. She can’t give me anything like an estimate because she doesn’t have one (isn’t demanding one) from the service company. If they had to provide one, they’d have to demand one from whomever they’re waiting on, and so on. It wouldn’t necessarily result in anything being fixed faster* but it just might make it harder to assume that everyone in the chain of responsibility is inept.
* Sometimes the need to tell someone you’re going to let them down incents you to find ways not to let them down, but that’s hard to take to the bank.