Liking the Result Isn't the Same as Liking the Job

Over the past few days, I have been watching a content workflow move forward on its own.

It starts by reading my 30 most recent saved items, then checks the candidate against the past 60 articles with vector-based deduplication. Topic sorting, image preparation, and translation are handed to software wherever possible.

But the final stretch still crosses several boundaries. The draft goes through WeChat's interface, the blog goes through a content system, and the finished article goes into a knowledge base. If any step times out, I have to check the remote system before trying again. A local message saying “failed” does not prove that nothing was written.

I wanted to remove repetitive labor. After running the workflow for a while, I noticed that some friction remains not because the automation is poor, but because the work inherently depends on other systems and other people.

Engineers easily divide work into two halves.

One half is “the real work”: writing code, drawing a design, solving a problem. The other is “forced coordination”: confirming requirements, waiting for an interface, explaining tradeoffs, and finding a release window.

The first half feels productive. The second is often irritating. That creates an attractive illusion: with a better process, stronger tools, or smarter AI, the second half can eventually be cut away.

But code inside a company rarely stands alone. Change one field and a caller may have to change with it. Release early and the data side may not be ready. Choose a cleaner design and the delivery may miss its window. These are not noises outside the code. They are conditions that determine whether the code becomes a result.

When work requires several people, coordination is not a surcharge. It is part of the work.

In 2009, Microsoft Research studied a software application team of about 300 people. The researchers interviewed 26 team members and supported the findings with a survey of 775 Microsoft engineers. They grouped the main influences on coordination into communication, capacity, and cooperation.

The study is old and does not represent every company. Its three conditions are still plain enough: did the other person understand, do they have the capacity to act, and are they willing to move toward the same goal? Tools can move information faster. They cannot automatically make all three conditions true.

That changed how I think about “liking a job.”

Someone may love the feeling of breaking down a coding problem but hate changing requirements. Someone may love seeing a product go live but hate explaining it to users. Someone may want to make a good film but resent budgets, schedules, and dozens of trades waiting on one another.

That does not necessarily mean the person lacks passion, and it does not necessarily mean the organization is broken. They may simply love the brightest slice of the work without counting the way the result has to be produced.

A career is not only a subject. It also carries a way of working. Investment research can often advance alone for long stretches. A software product naturally connects to users, marketing, testing, and operations. Choosing the latter also means choosing more alignment, waiting, and compromise.

Bad meetings, blurred responsibilities, and constantly changing decisions can of course be improved. Calling every wasteful habit “the nature of the work” only excuses poor management.

The useful boundary is simple: if this communication disappears, can the result still be delivered whole? If not, the coordination should be improved rather than imagined out of existence.

AI does not erase this ledger either.

It can translate an article, organize material, check formatting, and even turn a clear requirement into code. But permissions, release timing, content boundaries, and responsibility after failure still require someone to confirm them.

Once automation removes repetitive actions, the remaining coordination becomes easier to see. Some of it comes from a process that was never designed well. Some of it is the unavoidable cost of doing this particular kind of work.

Liking the result determines whether you want to begin. Staying with the work depends on whether you can accept how the result is actually produced.

Back to the workflow that runs every day. It has saved me a great many mouse clicks, but it has not removed the need to deal with the outside world.

Writing the article is one problem. Getting it safely and accurately to the right places is the other half of the job.