Why I Write a Weekly Engineering Update

Clear communication is one of the most important skills a leader can develop. More than technical depth or strategic insight, the ability to communicate ideas clearly determines whether those ideas ever turn into impact. If people can’t understand what you’re thinking, they can’t act on it—and the value of your thinking stays locked in your own head.

In a remote-first world, where most collaboration happens asynchronously and an increasing amount of work depends on how well we structure context for other humans and for LLMs, written communication has quietly become a force multiplier for leadership.

Writing doesn’t just communicate intent—it sharpens it. The act of writing forces you to slow down, clarify assumptions, and pressure-test your own thinking before asking others to engage with it. When shared, writing scales your priorities far beyond what meetings or real-time conversations can reach. It creates durable signal. People look to leaders for cues about what matters, and writing those priorities down reinforces them in a way spoken communication rarely can.

This is why establishing a weekly internal writing practice has been one of the highest-leverage habits I’ve developed as an engineering leader.

Communicating Is Hard. Communicating Broadly Is Harder.

As organizations grow, communication doesn’t get incrementally harder. It changes entirely.

Early on, when a team is fewer than ten people, communication is direct. Everyone can be involved in most discussions, context travels quickly, and consensus is relatively easy to reach. Somewhere around ten people, that starts to break down. Roles specialize, attention fragments, and not everyone needs, or wants, to be part of every conversation.

You tend to see additional inflection points around 25, 50, and again around 100 people. The exact numbers vary, but the pattern is consistent: as headcount grows, the cost of shared context rises faster than the team itself.

Metcalfe’s Law helps explain why. Originally developed to explain telecommunications network complexity, the law states that as the number of nodes in a network grows, the number of possible connections between those nodes grows exponentially. A team of 25 people has roughly 300 possible communication paths. At that scale, it’s no longer feasible to rely on synchronous conversation or informal channels to keep everyone aligned.

The key takeaway is simple: while team size grows linearly, communication complexity grows exponentially. At a certain point, it becomes impossible to traverse every path and leaders must shift from participating in communication to designing for it.

My Journey

For most of my career, collaborative chat tools have been the primary mode of communication (RIP HipChat). I’ve leaned heavily into ChatOps across multiple roles, pulling deployments, incidents, customer support requests, and operational alerts into tools like Slack and Teams.

While these tools are incredibly powerful, they’re also incredibly noisy.

I’ve written before about the cost of constant interruption, but there’s a second-order effect that shows up as teams scale: important announcements get lost. Major changes, new initiatives, or business updates scroll by in a sea of messages. Some people see them in the moment. Others catch up later. Some never see them at all.

When teams are small, this is manageable. Daily standups and regular team meetings provide natural reinforcement. But as organizations grow, those shared forums disappear. You now have multiple teams, each with their own priorities and roadmaps. Chat remains great for real-time coordination, but its ephemeral nature makes it a poor substitute for durable communication.

What gets harder still is communicating why certain initiatives matter: product changes, engineering investments, or shared learning across teams. People who were around in the early days often miss the sense of omniscience they once had. They want context, but there’s no longer a single place to get it.

Publishing Alignment

By the time an engineering organization reaches ~20 people, no one, including the leader, has full visibility anymore. The challenge becomes maintaining alignment without sacrificing autonomy.

This is where a lightweight, weekly written update becomes incredibly effective.

I’ve found that a short internal post, shared with Engineering and key partners in Product, Design, and other functions, strikes the right balance. The exact format matters less than the consistency, but this structure has worked well for me:

Intro

Start with an industry article, research paper, or internal topic. Summarize it briefly and share your perspective. This sets the tone and signals the kinds of problems you’re spending time thinking about.

Org-Wide Updates

Use this section to highlight initiatives that affect the entire engineering organization. This reinforces priorities and helps teams understand what’s happening outside their immediate scope.

This is also where you should share your work. As a leader, your job is to work on the system, not in it. Making that work visible helps others understand how decisions are made and what outcomes you’re driving toward.

Team Updates

A few sentences per team is enough. Focus on outcomes: launches, decisions, progress against goals. This keeps people connected to the broader organization without dragging them into day-to-day details.

Pro Tip: Once you have managers reporting to you, delegate this section. It gives them practice writing for a broad audience and reinforces an outcomes-over-output mindset.

Optional Sections

Add sections as needed. Reminders for infrequent but important tasks. A “tip of the week” when rolling out a new tool or process. Evolve the format as your organization evolves.

Publishing Tips

Consistency matters. Block time on your calendar, publish on the same day each week, and share the post automatically in Slack or Teams. I’ve found mid-day Friday tends to get more engagement than end-of-day posts that disappear into the weekend.

Templates help. Whether you use Confluence, Notion, or another tool, formalizing the structure reduces friction and lowers the activation energy to write.

Start early. Create a draft on Monday and add to it throughout the week. By the time your writing block arrives, you’re editing, not starting from scratch. This also creates a subtle accountability mechanism for the initiatives you plan to push forward that week.

The Benefits

Writing clarifies thinking. Publishing amplifies it. This practice also creates another opportunity for you to start to nemawashi ideas with a broader audience, which helps to simplify the decision-making process later on.

Over time, these posts also create a living record of your organization’s progress. Quarterly and annual reviews become much easier when you already have a weekly trail of decisions, outcomes, and lessons learned.

Pro Tip: Periodically feed your posts into an LLM to generate summaries of your organization’s most impactful work over longer time horizons. It’s an efficient way to surface patterns you might otherwise miss, and helps to avoid recency bias.

Summary

As teams scale, communication stops being something you do and starts being something you design. The informal mechanisms that work for small groups do not survive growth, and real-time tools alone cannot carry shared context across an organization.

A weekly internal writing practice is a simple but powerful way to address that gap. It forces clearer thinking, creates durable signal, and scales alignment without pulling people into unnecessary meetings or conversations. Over time, it also builds a record of decisions, priorities, and progress that makes reflection and course correction easier.

Writing is a leadership tool. Used consistently, it helps teams stay aligned as complexity grows, which is exactly when alignment matters most.