Skip to main content
All writing

Why automation work shouldn't stay behind the scenes

Tools that save other teams time are often treated as background work. Here's what that costs the tool, the teams who could use it, and the people who built it.

AUTOMATION · OUT OF SIGHT Story generator No funding No new users No credit RESULT Easy to cut

Good automation is built to disappear. Once it works, nobody has to think about it again. That’s the goal for the people using it, but it becomes a problem when the people funding, adopting, and evaluating the work don’t know it exists either.

I work on a design system team that supports roughly 3,500 engineers and designers. Two pieces of our automation show the pattern well. Storybook story generation saves more than 10 hours of setup per component. Figma Code Connect mapping means designers and engineers no longer translate the same components by hand. Neither one appears in a screenshot of the product, and both changed how much time teams spend on features.

Work like this usually gets filed as behind-the-scenes support for the real project. That label limits what the work can do, and it’s worth talking about openly for four reasons.

Unseen tools are easy to cut

Budget and staffing decisions are made by people looking at roadmaps, demos, and release notes. A tool that runs quietly doesn’t show up in any of them. When priorities change, it looks like a cost with no visible return.

The risk grows when the person who built it moves on. If nobody else knows what the tool does or which teams depend on it, it stops getting updates. Automation that breaks quietly can be worse than having none, because teams have already stopped doing the manual step it replaced.

People can’t use what they haven’t heard of

A tool only saves time for the teams that know about it. Everyone else keeps doing the task by hand, or builds their own version. Over time, the organization ends up maintaining several tools that do the same job, which is the same problem that inconsistent components create.

Telling people about a tool is part of building it. The documentation, the announcement, and the answer to “does this work for my team?” decide how much of the tool’s value actually reaches anyone.

The work disappears from reviews and résumés

Sprint reports count features. A tool that gives every team 10 hours back per component isn’t a feature, so it rarely appears in the places where work gets evaluated.

That’s a loss for the people who built it. In systems thinking, a leverage point is a small change in one place that has a large effect on the whole system. Automation is often exactly that, and it’s often the most valuable thing someone did that year. If they don’t describe it, performance reviews, promotion cases, and résumés leave it out.

If nobody knows a tool exists, nobody will fund it, use it, or fix it.

It changes what the organization asks for

When leaders see what a tool returned, they can start asking where else the same approach would help. That’s how automation moves from something one person does in their spare time to something a team plans for.

When the work stays out of sight, that conversation never starts. The organization keeps treating repeated manual work as normal, because nobody has shown it a different option.

Describe it by what changed

Talking about automation works best when you describe the change in someone else’s day.

What the work isWhat it changed
Automated Storybook story generationEngineers skip more than 10 hours of setup per component and spend that time on features.
Automated Figma Code Connect mappingDesigners and engineers no longer translate the same components by hand.
Accessibility documentationTeams using the components ship correct patterns without having to ask us.

The left column is accurate, but it doesn’t explain why the work mattered. The right column names who benefited, what they stopped doing, and how often that happens.

Most automation is also team work. Say “we” for what the team built and “I” for the part you owned. Being specific about your part is more believable than claiming all of it.

How to start

Pick one tool or process you built that other people use every week. Ask two of those people what they did before it existed, and write their answer down. Then share it somewhere the decision makers will see it: a release note, a team update, a demo, or your next performance review.

Useful to your team?

Share on LinkedIn