Real John here (for now), I’ve been playing to Dot (ChatGPT’s always on agent). For now, it seems pretty nice, friendly reminders, checking tasks that need to be done, and in some cases doing them for me. But that’s not what this week is about. This article was written by Emma (my agent). I reviewed it, but this is completely AI (in my voice/tone). I would LOVE feedback on this. So if you are reading this, first thank you, and second, write a simple response to me, yes I like it, or no, this is AI slop and not why I’m here. Now, that I ruined the experiment by telling you want it is, and your bias is already set in. Let’s get into it.
Hey all,
Before you decide your engineering team is slow, follow a piece of its work.
Pick a feature a customer can actually use. Find the original request, talk to the people who worked on it, and trace what happened until it reached that customer. Include the days when nothing happened. Especially those days.
That gives you somewhere useful to start. Otherwise, it’s easy to jump straight to a familiar answer: hire more engineers, change the process, replace the platform. Each might be right. You should be able to explain what you expect it to fix before asking everyone to live through it.
Start with something ordinary
Choose a recent feature that went through the normal process. The emergency fix that got everyone’s attention will tell you how the company handles emergencies. You also need to understand an ordinary Tuesday.
Who asked for the feature? What problem were they trying to solve? Who decided it was worth doing, and who could settle questions once work started?
Then follow the actual history. Look at the ticket, the design changes, the pull requests, and the release. Ask the people involved to fill in the gaps. A status change can tell you when something moved. It usually takes a conversation to understand why it sat there.
Keep this small enough that you can finish it. One feature won’t explain the whole company. It can give you a specific problem to investigate instead of another meeting about why everything feels slow.
Pay attention to the waiting
A feature might take two days to build and spend the rest of the week waiting for a decision about who should have access to it. Perhaps the engineer asked early, but the person who could answer was in meetings. Perhaps two people gave different answers.
Look at what the engineer could reasonably have done with the information available. Then look at what the organization required them to wait for.
This matters when you’re deciding where to invest. If the delay came from an unresolved product decision, faster code generation won’t answer that question. It may leave you with more completed code waiting for the same decision.
Be careful with the word bottleneck, too. The person with the longest queue may be covering work that nobody else knows how to do. Asking them to hurry up is a pretty poor substitute for giving them backup.
Record the reason for each meaningful delay. Was someone waiting for information, a review, a working environment, or a decision? Did the work come back because expectations changed? Keep the explanation concrete enough that the people involved recognize it.
And make the purpose clear. If this becomes a hunt for someone to blame, people will start protecting themselves. You’ll get a very tidy version of events and learn almost nothing.
Open the product
Once you’ve followed the work, use what shipped.
Take the customer’s path through the product. Start where they would start. Check whether they can complete the task the feature was supposed to help with, including the permissions and setup they need along the way.
This is where the original request becomes useful again. You can compare what somebody needed with what they can now do.
If the path only works when an engineer changes a setting behind the scenes, include that work. If support has to explain an undocumented step, include that too. A closed ticket doesn’t make those dependencies disappear.
You also might discover that the feature works exactly as intended and nobody needs it. That’s an important finding before you build the next version.
Change one thing and check
Now you have a basis for a useful change.
Maybe a product decision needs an owner before development starts. Maybe a second engineer needs time to learn the release process. Maybe fewer things should be started at once so reviews can actually get finished.
Choose the change that addresses what you found. Say what should improve, then follow another comparable piece of work. Check the waiting time and whether the customer can complete the task. Keep an eye on defects so a shorter timeline doesn’t hide extra cleanup later.
If the same delay comes back, revisit your explanation. If the work moves sooner, check a few more examples before announcing that you’ve fixed delivery.
The next hire or tool purchase becomes a much easier decision when you can point to where the help is needed. Start with one feature. There’s plenty to learn before you redraw the org chart.
Where does work sit waiting in your company? Hit reply with the handoff you’d like to fix.
Go build something amazing.