Thoughts by human, co-written by AIIn the age of abundance, less is more
Recently, my mentor suggested that I was involved in too many things at the same time. After thinking about it, I agreed. Before that conversation, I hadn't really seen it as a problem.
The projects weren't becoming risky. I wasn't failing to manage them. With AI agents helping me, I could keep several work streams progressing, and I didn't feel spread thin. That is what makes the advice interesting to me. I can be doing useful work across several projects and still wonder whether I should be doing less.
I want to stay closer to a couple of projects, including through the boring parts. I already have ownership. The question is what I do when the project slows down, becomes less interesting, or reaches a point where the next move isn't obvious.
My mind tries to optimize. I can go somewhere else and build visibility, build leverage, make an impact. There is always another useful thing to work on.
The other work is useful
At work, I own and drive two projects. I am also improving the speed, resilience, and reliability of our testing infrastructure. I want to see the results of those improvements, so I am building an insights dashboard or tooling to give me that visibility.
There is also the development tool I built to help me move faster on my project. I use it heavily, although I am no longer actively changing it over and over. It collects usage logs and metrics so that, when I return to it, I can make improvements based on how I have actually used it. That work stream is parked, but it remains on my radar.
The testing work comes from my own interest in increasing engineering velocity. It has been paying off. As a team, we have seen substantial improvements in flakiness, reliability, and speed. Fewer flaky tests mean fewer unnecessary restarts. Faster integration tests shorten the wait after each code-review change.
So I can't explain this away as work that merely looks productive. It has been useful and impactful.
Still, feeling productive, getting work done, and making a large impact are different things. I am trying to understand what I might be giving up even when the additional work has real value.
Stay with the blocked project
Here is the situation I want to think through. Treat it as a mental experiment.
I have built the UI. The backend team is working on a dependency. There is an accountable person, the blocker has been communicated, and the PMs are aligned. When the dependency arrives, I will integrate with it, validate the result, and move toward releasing the feature.
For the next twenty-four or forty-eight hours, imagine that I cannot make much progress on that implementation. Usually I could work on the testing infrastructure or one of my tools. I don't tend to sit with my legs crossed and wait to be unblocked.
But now I want to impose a constraint: I cannot pick up another project. I cannot touch the testing infrastructure, the development tools, or the insights tooling. In the age of abundance, less is more is the tenet I want to try respecting.
What would I do?
At first, I have no idea. I could probably sit there and do nothing, except my mind wouldn't leave it there. I would start looking for something to do within the project.
That is where the uncomfortable possibilities begin. Am I using the parallel work stream to avoid being bored? Is it a way to escape the uncertainty of a stalled project? Am I chasing the satisfaction of making visible progress?
I don't want to jump to any of those conclusions. I want to stay in the situation long enough to see what else I can think of.
Planning work I already understand
The first idea is planning. I hate planning, so perhaps there is something here that I am avoiding.
But what exactly would I be planning? I already know the sequence. The dependency arrives. I build against it, validate the result, get the work reviewed, communicate what changed, let people try it, and move it toward release. I know I am going to do those things.
I could write that down. But what benefit would I get from writing down a plan that already feels straightforward? Someone might say it will make the work easier. I am not convinced yet, because this part already feels easy to me.
In my head, I give this idea about one or one and a half out of five. I want to keep looking for something that feels more consequential.
Updating a document that keeps changing
Another possibility is refreshing the design document. Parts of it may need to change because the dependency is changing. I could mark unsettled sections as provisional and make the document ready for the final contract.
There is a useful version of this. Once the dependency lands, I can give my agents the design, the relevant decisions, and what changed. They can work from a coherent description of what the UI needs to do, with open questions made visible.
But the backend approach has already changed several times while it is being worked on. If I update my document every time, I can create confusion and unnecessary work.
There is a boundary here too. My design document concerns the UI product work. It needs the contract with the backend. I don't suddenly need to own the backend service's changing implementation or duplicate every decision and rationale in my document.
Updating the relevant parts once the contract is settled seems sensible. Continuously rewriting around an unsettled dependency seems messy. I initially give the documentation idea a little more weight, then bring it back down to about two out of five.
Anticipating what comes next
Anticipation has already helped me in meetings, demos, and design reviews.
When I prepare a document or presentation, I ask my agent to anticipate the questions we might receive. I use those questions to develop my own judgment and answers. I ask for references and cross-checks against the relevant documentation, services, and dependencies so that I understand the answers myself.
Then, when some of those questions come up in the meeting, I have already thought about them. I can answer with an understanding I would otherwise have had to develop on the spot.
I could do something similar while the project is blocked. What product questions, UX problems, or implementation questions might appear after the dependency lands? What can I understand now that would help me respond then?
But only some of the possibilities I prepare for will happen. A lot of the preparation could be thrown away. That makes it feel like another kind of meta-work: getting ready for a problem instead of working on the problem itself.
I give this about two out of five as well. Even though I have found anticipation useful in meetings, I am discounting it here because so much of it might never be used.
I am having trouble finding an idea I would give a three, a four, or a five.
The follow-ups that never happen
There is another possibility: pull some follow-up work forward.
Follow-up sometimes feels like the biggest lie in the universe. We decide to release the feature now and return to something later. Then the feature is out, priorities move on, and the promised follow-up no longer seems important.
Perhaps a period blocked on a dependency is a chance to do some of that work within the project. Instead of promising to return after release, I could do it while I am waiting.
But I can already hear the objection. If the work could be postponed and then forgotten, perhaps it wasn't important enough to do. Why spend this time on something nobody would otherwise prioritize?
I don't have a good answer yet. I do feel that follow-ups aren't all equal. Some may deserve to happen earlier. I haven't worked out how to distinguish them from the work that was right to leave behind.
A partial answer
I started with a feeling that my mentor was right: I am involved in too many things. I can now describe more precisely what I want to explore. When a project slows down, I can move to another useful project. I want to understand what would happen if I stayed.
So far, the alternatives I have come up with don't feel as valuable as the work I would usually switch to. Some seem redundant, some seem premature, and some seem likely to be discarded. I don't want to pretend I have discovered a better way to spend that time.
The constraint has to allow for that. I can take a deliberate, limited amount of time to look for something consequential within the project. If I find a question I have been overlooking, staying may be worthwhile. If I find no worthwhile next task, I need to be able to accept that too. Otherwise, I am forcing myself to manufacture work.
Returning to useful testing improvements could be the right decision. My mentor's advice can still be valuable without making every switch a mistake.
For now, I want to interrupt the automatic move from a project becoming quiet to starting something else. Staying briefly might reveal work I have been overlooking. It might also confirm that waiting is appropriate. I haven't yet shown whether doing this will improve the outcome.
That is an unsexy, partial resolution. I still feel the tension between wanting to stay closer to a few projects and knowing that the other work has value. It may take time to understand how those things fit together.
I would rather keep that pressure unresolved than manufacture a conclusion I don't believe. This essay can be finished while the question remains open. If a clearer answer comes, I can write a follow-up from that understanding. For now, this is as far as I have got.
Writing provenance: This essay was developed with AI from my source prompts. One message contains two explicit privacy omissions for a workplace example I asked to exclude.