When leading projects, in any capacity, avoid startling your colleagues. Tech leads, engineering managers, product managers, etc. need to keep peers and stakeholders informed. When there are successes, let them know. When risks are discovered, communicate the steps taken to mitigate them. When setbacks occur, indicate how it will affect the remaining scope and schedule of the project. Dig out, not up.

Stakeholders and peers are startled when they think a project is smooth sailing only to hear the ship is sinking. When things go poorly, projects slip by inches, then feet, then all of a sudden. It’s on project leaders to detect these slips, address the root causes, and let people interested in the project know what’s going on and what you’re doing about it.

This may seem obvious! But it’s easy to get so wrapped up in solving the problem that you forget to communicate the problem. To want to say, with ease, “things aren’t going great, but I have it under control.” Or, to feel like the issue is yours alone and forget you may have peers in the organization that could help if only you communicated it.

A non-obvious way to surprise people is to silently, but suddenly, succeed. Release new features or change functionality in production without any kind of internal notice or documentation, and I’ll bet you hear something from customer support, marketing, sales, etc. They won’t begrudge you for doing your job and shipping code, but they might ask you to please let us know next time so we can prepare our teams, campaigns, or update our documentation. Or, they might come at you with pitchforks, wanting to know why things are changing out from under them.

Corollary: Don’t Be Spooky. If you need to tell someone, IC or stakeholder, that a project has run into surprises, just tell them. Don’t open up with context-free messages like “can we talk?”

Have the hard conversation now, before it gets tougher.