Nobody likes being micromanaged, and engineers tend to dislike it even more than most. They want as few meetings as possible, they need long stretches of uninterrupted focus, and they’ll let you know when something is done. Managers, meanwhile, are constantly looking for ways to get visibility into what’s happening. Standups are introduced to “stay on top of things,” quick calls pop up to get a status update, and ad hoc meetings become the default whenever uncertainty creeps in. From the engineer’s perspective, this often feels unnecessary and disruptive. From the manager’s perspective, it's necessary to get a hold of things.

The manager's perspective

Every manager has someone to report to. Founders answer to investors, sales teams answer to clients, and project managers answer to internal or external stakeholders. All of them experience pressure to deliver and to explain where things stand. A good manager tries to shield the engineering team from that pressure as much as possible. They provide context, but they absorb the urgency, the meeting requests, and the constant demand for updates. However, that shielding only works if they have enough information to work with. The more proactively an engineer updates their CTO or engineering manager, the less that manager needs to interrupt them to ask where things are at.

The ticket as first line of defence

In almost every team I’ve worked with, a ticketing system sits at the heart of development. Whether it’s Jira, GitHub Projects, or another tool doesn’t really matter. As an engineer, your tickets are your first and most effective line of defence against unnecessary meetings. Keeping the ticket you’re working on up to date may seem trivial, yet it’s often neglected. When something meaningful happens, add a comment. If a decision was made or an issue surfaced, document it and tag the relevant people. Make sure it's in the right column on the board. This small habit provides visibility without requiring synchronous communication.

One of the most common problems I see is tickets that are simply too large. A ticket that says “implement feature X” can easily sit in an “In Progress” column for days or even weeks. From a manager’s point of view, a ticket that doesn’t move is unsettling. It raises questions that are hard to answer: are we on track, blocked, or is the work more complex than expected? Breaking work down into smaller, granular user stories avoids this ambiguity. A user story that takes three days is the absolute maximum; smaller is usually better. When progress is visible daily, trust increases. An extra bonus is the small dopamine hit you get when another ticket can be moved to "Ready for QA".

Async updates to the rescue

Beyond tickets, asynchronous updates form your second line of defence. A short message in Slack or Teams can often prevent a meeting from being scheduled altogether. Many engineers worry about communicating too much, but in practice, people rarely do. Without falling into stereotypes, engineers tend to be more reserved, and reserved people almost never overcommunicate. If you have an open question and it remains unanswered for a day, you're responsible for following up. Waiting several days and then explaining a delay with “I asked a question, but nobody answered” does no one any good. Owning your work also means actively unblocking yourself and ensuring unclear topics are resolved.

The good news show

Another common trap is the belief that communication should only happen when there is good news. Something goes wrong, but it feels safer to stay quiet and try to fix it first. A task takes longer than expected, but surely that time can be made up later. This thinking often spirals out of control. One small issue leads to another, and suddenly you’re further behind than before.

Meanwhile, silence creates assumptions. When there is no news, people assume everything is on track. The later a problem is communicated, the harder it becomes to deal with. Flagging issues early gives managers the opportunity to help, adjust priorities, or adapt expectations before things escalate.

Communicate, communicate, communicate

Good communication starts long before code is written. During feature refinement, if user stories are too large or too vague, that’s the moment to push back. Managers have a responsibility to ensure work is well scoped, but engineers should speak up when that doesn’t happen. Smaller user stories naturally make progress visible and reduce the need for constant check-ins. Once development starts, communication should become part of your daily routine. While I’m not a fan of daily standup meetings, I’ve seen asynchronous standups work very well. Writing down what you did yesterday and what you plan to do today removes the “what are they working on?” question almost entirely.

Throughout the day, short updates can go a long way. These updates don’t have to be limited to problems; they can just as easily highlight progress or small wins. When something does go wrong, communicating it sooner rather than later is crucial. It’s far better to have flagged an issue that turned out to be easy to fix than to stay silent for a week and end up in an uncomfortable conversation about missed expectations. Early communication builds trust, even when the message itself isn’t positive.

I know what you're doing

In the end, the real goal is simple: eliminate the question “what are you working on?”. If you proactively answer that question through clear tickets and consistent asynchronous communication, you reduce interruptions, avoid unnecessary meetings, and create space for yourself to actually do the work. When communication is missing, others will fill in the gaps for you, usually in ways you won’t like. Communicate early, communicate often, or accept that micromanagement will follow.