Your head of engineering just had their quarterly review.
The feedback: “We love what you’re doing. We just need more visibility into what the team is actually working on.”
Your head of engineering is confused. They’ve been sending deployment notifications constantly. The Jira board is updated daily. Every PR goes through the team Slack channel.
How is there not enough visibility?
Here’s what just happened: your engineering team thinks they’re communicating clearly. Your business team is drowning in noise they can’t parse.
The Visibility Paradox
Your engineering team is probably shipping multiple times per day.
Every deployment goes to a Slack channel. Every ticket gets updated in Jira. Every pull request gets reviewed and merged. There’s a constant stream of activity that shows work is happening.
To your engineers, this feels like transparency. Look at all this visibility we’re providing!
To everyone else, it’s incomprehensible technical noise.
“fix: update auth middleware to handle edge case in token refresh“
“refactor: extract user validation logic into shared service“
“feat: add pagination support to reports endpoint“
Your marketing team has no idea what any of this means. Your CEO can’t tell if you’re three weeks ahead of schedule or three weeks behind. Your head of sales doesn’t know if the feature they promised a customer is done or not.
Everyone’s frustrated. Your engineering team feels like they’re being transparent. Your business team feels like they’re flying blind.
What’s Actually Happening
The problem isn’t that your engineering team isn’t communicating. It’s that they’re communicating in a language nobody else speaks.
Engineering teams track work in units that make sense to engineers: tickets, pull requests, deployments, story points.
The rest of your company tracks work in units that make sense to business: features customers can use, problems that got solved, dates you’re tracking toward.
Your deployment channel shows fifteen updates this week. But your CEO can’t answer a basic question: “What can customers do now that they couldn’t do last Monday?”
Your Jira board has sixty tickets in progress. But your head of marketing can’t figure out: “Can we announce this feature next week or not?”
This gap isn’t about engineering being bad at communication. It’s about engineering being technically transparent while being practically opaque.
The Real Cost
This visibility gap costs you in ways you probably don’t see:
Your business can’t plan effectively.
Marketing wants to time announcements around feature launches. Sales wants to know what they can promise prospects next quarter. Your CEO is trying to decide if it’s time to hire another engineer or wait.
All of these decisions require knowing what’s getting done when. If they can’t see that clearly, they either bother your head of engineering constantly for updates, or they make plans based on guesses.
Your engineering team doesn’t get credit for their work.
Engineers spend half a sprint fixing a nasty performance bug that was causing customer complaints. It takes fifty commits across eight pull requests. The deployment channel lights up like a Christmas tree.
Nobody outside engineering notices. Because to them, it looks the same as every other week: a bunch of technical updates they can’t parse.
Six months later at a board meeting, someone asks what engineering has been working on. Your CEO struggles to articulate it. Your engineers feel unappreciated.
Trust erodes slowly.
When the business can’t see what engineering is doing, they start to assume engineering isn’t doing much. Or they assume engineering is working on the wrong things.
Engineers know they’re working hard. They can see all the deployments. They don’t understand why the business seems skeptical.
The business sees lots of technical activity but can’t connect it to outcomes they care about. They don’t understand why engineers seem defensive about simple questions.
Everyone means well. Nobody’s trying to hide anything. But the gap in understanding creates friction that compounds over time.
The Shipping Department News
I’ve used the same approach four different times in my career to solve this exact problem.
Every time, it’s killed.
Here’s how it works:
Create a running document called “Shipping Department News.” At the end of each week, spend 15 minutes updating it with everything that shipped to production. Then send an email or Slack message with the update and a link to the doc.
Not just buried in Slack. Not just a document nobody remembers to check. Both – a notification that gets their attention, and a living document they – and you! – can reference anytime.
Each week gets a new section with the date. Under that, three parts:
What shipped this week:
Start with a quick summary paragraph, then a bulleted list with labels that make it scannable.
“This week we focused on customer-requested features and security updates. The Excel export has been our top enterprise request for months, and we finally shipped it. We also patched a critical security vulnerability and fixed the bug that was causing dashboard timeouts for our largest customer.”
- NEW FEATURE: Customers can now export reports to Excel with custom formatting – unblocks two enterprise deals in the pipeline
- BUG FIX: Fixed slow dashboard loading that was affecting our largest customer (response time down from 8 seconds to under 1 second)
- SECURITY: Patched critical authentication vulnerability discovered in third-party library
- INFRASTRUCTURE: Reduced deployment time from 45 minutes to 5 minutes, letting us ship fixes faster
Sometimes there’s a screenshot of the new feature. Sometimes there’s a humorous aside about the bug that took three hours to track down.
Be human. Tell a story.
What we’re working on next:
“Next week we’re focused on the self-service signup flow and Stripe integration for the February conference launch. We’re still on track for the demo deadline, but it’ll be tight.”
Status and planning updates:
Anything about dates you’re tracking, dependencies, or context the business needs.
“The February conference demo requires three pieces: workflows (60% done), self-service signup (starting next week), and payment integration (two weeks out). All three need to be done by February 15th for the marketing team to prep materials.”
That’s it. The email/Slack message can be even shorter – just “Shipping Department News updated for the week” with the link and maybe one highlight. The doc has the full detail.
The whole thing – updating the doc, writing the notification – takes 15-20 minutes once you get in the practice.
Why This Works Better Than You’d Expect
This simple weekly update solves multiple problems at once:
You don’t bog down meetings with status updates.
When someone asks “what’s the status of X?” in a meeting, you can say “it’s in Shipping Department News from last Friday.”
Your Friday all-hands stops being a status update meeting and starts being about actual decisions.
You have an easy review for external product updates.
When marketing needs to write a product announcement or your CEO is prepping for a board meeting, they can scroll through the last month of Shipping Department News and filter for NEW FEATURE items.
The labels make it scannable. They can see at a glance: “Oh, we shipped five new features and fixed twelve bugs in the last month.”
You emphasize momentum and keep the company aligned.
Every week, there’s visible progress. Even quiet weeks where you’re doing infrastructure work or fixing bugs – it’s all there, labeled and explained in business terms.
The INFRASTRUCTURE and SECURITY labels help people understand that not every week is features, and that’s okay.
Engineering gets credit for invisible work.
That performance optimization gets labeled PERFORMANCE: and explained in customer impact terms. That security patch gets labeled SECURITY: and tied to compliance requirements.
Now the business understands this wasn’t wasted time. It was necessary work with clear business value.
You can spot misalignment early.
When you write “Next week we’re refactoring the authentication system,” your CEO might reply: “Wait, I thought you were working on the enterprise features for the Q1 roadmap?”
That’s a good thing. You just caught a misalignment in week one instead of week eight.
Trust builds slowly, consistently.
Every Friday, the business gets a clear picture of what happened and what’s next. The labels make it easy to scan. The narrative provides context.
They stop asking for status updates. They stop questioning priorities. Because they already know.
A Few Rules for Making This Work
Write for your least technical reader.
If your CFO can’t understand it, it’s too technical. Pretend you’re explaining to someone who’s smart but doesn’t know what a pull request is.
Lead with business outcomes, not technical tasks.
“Customers can now…” not “We implemented…”
“This unblocks…” not “We deployed…”
Use labels consistently.
Stick to a core set: NEW FEATURE, BUG FIX, SECURITY, PERFORMANCE, INFRASTRUCTURE, MAINTENANCE. Maybe add EXPERIMENTAL for beta features.
Don’t invent new labels every week. The power is in the pattern.
Be honest about delays early.
If you’re tracking toward a deadline and it’s looking tight, say so in week two. Don’t wait until week eight to spring it on them.
Give them time to adjust their plans. They’ll appreciate the heads-up way more than a last-minute surprise.
Tie invisible work to visible outcomes.
Security updates, technical debt, refactoring – all of this sounds like waste to non-technical people. The labels help (“oh, SECURITY, that makes sense”) but you still need to connect it to something they care about:
- SECURITY: Maintained SOC 2 compliance for the upcoming audit
- INFRASTRUCTURE: Reduced deployment time from 45 minutes to 5 minutes
- PERFORMANCE: Fixed database queries slowing down the dashboard
Don’t be afraid of personality.
A screenshot of something new. A joke about the bug that took three hours to find. A celebration when you finally ship something you’ve been working on for months.
This isn’t a legal document. It’s a narrative. Make it readable.
Keep it short.
The bulleted list can be as long as needed – ten items in a busy week is fine. But keep the narrative parts tight. A paragraph to introduce the week, a sentence or two for next week, a paragraph for status updates.
The Mistake Most Teams Make
The instinct when asked for more visibility is to add more process. More meetings. More dashboards. More reports.
This makes everything worse.
Your engineers now spend more time in status meetings instead of building. Your business gets more data but less understanding. Everyone’s frustrated because there’s more overhead and less clarity.
Shipping Department News is different because it’s low overhead and high impact.
Your head of engineering already knows what the team did this week. They already know what’s coming next. They already know which dates matter.
Writing it down in plain English with clear labels takes 15-20 minutes. But those minutes buy you:
- Fewer status update meetings (easily saves an hour per week)
- Fewer “what’s the status of X?” Slack messages
- Better business planning
- More trust from leadership
- Credit for work that would otherwise be invisible
- A running narrative you can use for product updates, board meetings, and annual reviews
- Scannable history anyone can review in 30 seconds
The ROI is ridiculous.
What This Actually Costs You
Fifteen to twenty minutes a week.
That’s it.
Your head of engineering already has all this context in their head. They’re not researching or gathering data. They’re just writing down what they already know in language the business can understand, with labels that make it scannable.
For that tiny investment, you get better alignment, fewer meetings, and engineering work that’s valued instead of invisible.
The Real Problem
Most engineering teams think visibility means transparency into their process.
So they open up Jira. They share deployment notifications. They invite people to standups.
But the business doesn’t want to see your process. They want to understand your progress.
Process is tickets and pull requests and deployments.
Progress is features that shipped, problems that got solved, dates you’re tracking toward.
Your deployment channel shows process. Shipping Department News shows progress.
The business needs progress. They don’t care about process.
Start This Week
Your head of engineering’s next performance review is probably three months away.
If they start Shipping Department News now, by the time that review comes around, this won’t be feedback anymore. It’ll be proof of exactly the visibility and communication leadership wanted.
Here’s what they should do this Friday:
- Create a Google Doc called “Shipping Department News”
- Share it with the team, leadership, anyone who needs visibility
- Add a section with this week’s date
- Write a paragraph summarizing the week
- Add a bulleted list with labels (NEW FEATURE, BUG FIX, SECURITY, etc.) describing what shipped
- Add what’s coming next week
- Add any status updates about important dates or dependencies
- Keep the whole thing under 300-400 words
- Send an email or Slack message: “Shipping Department News updated for the week: [link]” with maybe one highlight
- Do it again next Friday
That’s it. Fifteen to twenty minutes. Every week.
After a month, the complaints about visibility will stop.
After three months, people will start checking the doc on Friday afternoons to see what shipped. They’ll scan the labels to see if there are new features worth celebrating.
Your marketing team will end up using this document when preparing product marketing, filling out release communication with more heft.
After six months, your head of engineering will be the person everyone else points to as an example of great communication.
Not because they learned to write better status reports. Because they learned that visibility isn’t about showing your work – it’s about telling the story of what your work accomplished.
I’ve watched this work four times in my career. It’ll work for you too.
This is part of my Editorial framework, a set of modular tactics and strategies that help software companies ship with speed, alignment, and safety at the same time.