My failure to proactively communicate project status almost cost me my position.
The project I was leading was late. I knew it, but I was confident we could recover and still make the June release. What I didn’t do was make sure the right people knew where things stood. I assumed someone else in the chain was passing that information up. Nobody was. When the delay surfaced in May, it came as a complete surprise to leadership. I looked like I had been concealing the problem. I hadn’t — but the effect was the same.
The failure went deeper than that. The team was also working without the full picture. I was the gatekeeper for requirements, passing down tasks without sharing why they mattered, who they were for, or what was at stake. I thought I was keeping things simple. I was leaving the team without the context they needed to make good decisions.
I was failing in both directions at once — and I didn’t see it until the damage was done. It was one of the worst moments of my career. I considered leaving. I stayed — and the experience changed how I think about communication entirely.
I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs. This issue is about the communication shift that trips up most new leaders.
The shift from pulling information for yourself to managing information flow
When we move from individual contributor to manager, our job shifts from doing the work to managing information flow.
As a senior engineer, your job is often to pull information from different sources so you can get the work done. As engineers, we read a ticket and documentation, ask colleagues, chase the product owner and team lead, and gather the information needed to understand what to do and how to do it. This is pulling.
When we step into a managerial role, we become responsible for other people’s output — the output of an entire group of people. They need to know what to do and have enough business context to make effective decisions. You need to pull information from above and across the organization, then make it accessible to your team.
It is not enough that you know what is going on outside the team. You need to ensure your team is aware.
Pull: gather context from all directions
Pulling doesn’t stop when you become a manager — it changes shape. As an individual contributor, you pulled information to serve yourself. As a lead, you pull to serve everyone else.
You need to know what is happening above you: business priorities, strategic decisions, and what leadership is worried about. You need to know what is happening around you: what other teams are planning, what dependencies are coming, what sales has promised. And you need to know what is happening inside your own team: where things are stuck, what risks people are sitting on, what your engineers are seeing on the ground that nobody else can see.
Push: make information visible in all directions
The flip side is pushing — distributing what you have gathered to everyone who needs it. There are two directions.
Pushing down to your team
They need to know what is happening outside their immediate work: what is changing in the business, what is coming next, what decisions have been made, and why. Without this, people optimize locally and miss the bigger picture.
My personal favorite way to ensure the team has the broader context is weekly updates. Every Monday, I share a report covering what happened last week, what is under work this week, and the broader technical and business context. It takes time to write and to remember everything going on, but having the broader picture saves time for many.
I write detailed updates — detailed enough to be genuinely useful. Here is a simplified version of what a typical one looks like:
“Search feature — the new filters are ready and will be released this week. Next up is performance optimization for large datasets.
Mobile app — internal beta is planned for this week. Core functionality is ready; final UI adjustments and analytics integration are in progress.
Onboarding flow — two of our largest clients are struggling with the current setup process. We are evaluating options: improving the existing flow, rebuilding it from scratch, or integrating a third-party solution. We need to decide soon, as clients are asking what to expect this year. More on this next week.
Half the team is offsite this week for a planning workshop and experiments with AI-tooling.”
The team knows what is shipping, what is at risk, and what decisions are coming. Nobody needs to chase anyone for context.
Pushing outward to stakeholders
Other teams and stakeholders commit to clients, plan campaigns, and schedule releases based on what they expect from your team. When something changes on your end, the ripple goes further than you might think. People hate surprises. Risks and problems identified earlier give them time to adjust.
“Feature A is progressing according to schedule. We expect it to be ready for testing in one week. Stabilization will take one more week, and after that, we should be able to release.
We are at risk with Feature B. It turned out to be more complicated than we thought. We identified a few edge cases, and we are coordinating with the product team on rescoping or moving the release forward. We will communicate the decision by Wednesday at the latest.”
Sales knows what they can promise. Marketing knows what they can plan around. Support knows what’s coming. And if something changes, they heard it from you first — not from a missed deadline.
I mostly reuse the weekly team updates with business stakeholders. I just make sure they are written in a way that works for them, which leads to the third part of the framework: translation.
Translate: say it in the language the audience needs
You are responsible for pushing and pulling information, but also for making sure it is understood.
When you deliver information, adapt it to the language your counterpart understands. Look at it through their eyes. What do they care about? What level of detail is useful, and what is just noise?
An engineering team does not need to know all the details of the marketing plan, but they do need to know when the webinar is happening and what new features will be demoed.
The sales team does not care about the database schema changes you need to make. They want to know whether the feature will be delivered on time.
It is often still worth telling non-technical stakeholders what technical work is being done. Just connect it clearly to outcomes.
“This database schema change will enable us to implement features for Acme Corp that they have been asking about for a year. Now that we have this in place, we can deliver the feature quickly.”
Nobody is confused. Nobody feels talked down to. Everyone has what they need.
The framework is simple — but the shift is not
When shifting from being an individual contributor to leading people, managers often undervalue some or all of the components of the pull-push-translate model. I wasn’t the exception.
I followed my old routines and pulled the information. It worked for me before, and I didn’t realize the ground had shifted until the situation went out of control.
Then I learned that my team needs more than well-written tickets — they need the bigger picture, what we are doing, for whom, and what is coming next.
My stakeholders should not have to pull information from me. If needed, I should chase them to make sure they know where we are and where the team is heading.
I have always been above average at translating, but even after many years, I still occasionally see business stakeholders puzzled and engineers overwhelmed when I explain something. Then I step back and adjust. Managers stand on the border between technical and non-technical worlds and can start to feel that everything is obvious to both sides. It isn’t. We need to stay perceptive, notice when people are lost, and meet them where they are.
Look at how information is moving
One thing I noticed when I shifted to pull-push-translate was that some of the “technical” problems disappeared. The solutions the team came up with got better and faster to implement. The pressure to deliver subsided.
This week, look at one communication gap in each direction: what your team needs more of, what stakeholders are not hearing early enough, and where your message is still not landing.
If your team feels stuck, don’t just look at the work — look at how information is moving.
That is for this week.
If this was useful, subscribe to get one practical lesson on engineering leadership every week — plus my free Process Experiment Template the moment you sign up.
Share this with a colleague who just stepped into a leadership role. This is the stuff nobody teaches you.
Have a nice week,
Roman
Thank you, Roman, for noticing my post ✌️