Operations & leadership · United Indians · 6 min read

Making the work visible is part of doing the work.

I used to think good independent work would mostly speak for itself. Managing projects with people who could not see my day-to-day work changed that view.

At United Indians, I had a lot of autonomy. I was younger than many of the people around me, worked across garden operations, interns, reporting, and grants, and often spent time on analytical or administrative work that was not physically obvious.

At one point I realized that being productive was not enough if other people could not tell what I was working on or why it mattered.

Silence creates its own story

If a manager sees someone moving between a garden, a classroom, a spreadsheet, and a grant file without context, they have to infer what is happening. Even when the work is legitimate, the absence of communication creates uncertainty.

I started sending concise updates every other day: what I had completed, what I was working on, what I was waiting for, and where I needed input. I also made a point of asking other staff what they were working on so my own work could connect to theirs.

The goal was not status theater

I did not want to create constant reporting for its own sake. The useful communication was lightweight and specific enough to answer a few questions:

  • What changed since the last update?
  • What am I doing next?
  • What decision or information do I need from someone else?
  • Is there anything here that conflicts with another person’s priorities?

Visibility creates an earlier correction point

If someone disagrees with an approach, it is cheaper to discover that while the work is in progress than after a deliverable is finished. Communication gives collaborators a chance to redirect, add context, or flag a dependency.

What I learned: communication is not just a social courtesy. It is a control mechanism for collaborative work.

It also changes trust

People do not need to inspect every detail when they have confidence that work is progressing and surprises will surface early. Over time, that can create more autonomy rather than less.

I see the same pattern in software and AI-assisted workflows now. A worker state file, a pull request, a test result, or a short project update all serve the same purpose: make enough of the state visible that someone else can understand and challenge the work.

My communication rule now

If the work is collaborative, I ask whether the people who depend on it can answer three questions without chasing me: what am I doing, what has changed, and what do I need from them?

If the answer is no, the work may be correct—but the system around the work is still fragile.