I keep coming back to the same three things whenever I think about what makes an engineering org actually pleasant to work in.
A company runs smoothly when people can get stuff done without hunting for information. What actually wears people out day to day is not the hard engineering problem. It is not knowing which ticket to file, which team to bug on Slack, or what invisible step stands between them and getting a simple service live.
I have seen engineers lose two weeks between writing their first line of code and shipping it, not because the code was hard, but because nobody could tell them how to get a database provisioned. I have also seen debugging sessions that should have finished in under 10 minutes stretch beyond an hour because the wiki page that was supposed to help linked to a dashboard that had been renamed six months earlier.
None of that is a skills gap on the engineer’s part. It is a tooling gap, and once you notice it, you see it everywhere. So, here are the three skills worth building for every engineering org.
create-service
This skill should provision the database, wire up logging to the central sink with the right tags, register the service with the identity provider, and deploy the service to production, all before anyone writes a line of business logic. Every one of those steps, if left manual, becomes a place where someone waits on another team or guesses wrong, and that friction is what makes day one slow.
It should know:
- The company’s standard service template.
- Infrastructure provisioning APIs (databases, secrets, networking).
- The identity provider’s registration flow.
- The logging pipeline’s tagging conventions.
End to end, the experience should be one command (agentic loop) in, a live production URL out.
deploy-service
This skill should handle forward deploys, rollbacks, environment-scoped test runs, and post-deploy smoke tests as one integrated flow. Most teams only build and regularly exercise the forward path, so rollback ends up being the least reliable part of the pipeline, even though it is exactly the path that gets used under pressure.
It should know:
- The service’s deployment history and current revision.
- Database migration state, so rollback does not leave the schema in a shape older code cannot handle.
- Target environment configuration.
- A defined set of smoke test endpoints for the service.
End to end, a deployment should run tests against the real target environment, roll out gradually, execute smoke tests automatically, and roll back on failure without a human needing to intervene or remember a separate procedure.
service-debugging
This skill should match live symptoms to known failure patterns for that specific service, surface direct links to the relevant logs, traces, and dashboards, and run diagnostic checks instead of merely pointing at raw data. Static runbooks eventually go stale, and by the time someone needs them, the links or steps are usually wrong.
It should know:
- A running history of past incidents for the service.
- Dependencies and links to their health dashboards.
- Verified failure patterns extracted from incident retros.
End to end, someone describes a symptom and gets back a likely cause, the evidence supporting it, and links to verify it, instead of a generic suggestion to “check the logs.”
Why Build Tools Instead of Writing Docs
Docs rot. A stale wiki page can mislead people for months before anyone notices. A broken tool fails loudly, right in front of the next person who uses it, which means it actually gets fixed.
That difference is the whole argument for building real tools instead of writing more documentation, even though documentation is always cheaper to produce on a Friday afternoon.
It matters even more now that AI agents are starting to create services, ship changes, and triage incidents on people’s behalf. An agent reading a stale wiki page has the exact same problem a tired engineer has at 2 AM: there is no reliable way to know the instructions are wrong. Companies whose knowledge lives inside executable tools get correct behavior by default, whether the thing acting on it is a person or an agent.
What I Would Actually Do
- Build debugging first. Incidents happen on their own schedule regardless of what you prioritize, so every incident becomes a chance to add a verified failure pattern, and the payoff is visible almost immediately.
- Build deployment second, with a rollback path that gets exercised regularly and mandatory smoke tests. Start with whichever service breaks most often.
- Build create-service last. It touches the most infrastructure of the three, and a half-built version is worse than none because it merely relocates the confusion instead of removing it.
- Feed both incidents and rough onboarding experiences back into these tools as a requirement, not a nice-to-have. A slow diagnosis becomes a ticket against the debugging tool. A two-week day one becomes a ticket against create-service.
- Track one metric per tool: time from a fresh repository to a live production deployment, deployment frequency alongside rollback rate, and mean time to diagnose an incident. All three are inexpensive to measure and difficult to argue with.
Start with your worst service, the one that pages the most and takes the longest to fix. Prove the numbers move there before worrying about the rest of the fleet.
Footnote: every company eventually needs three pieces of tooling that most never build properly. create-app should end day one with a live production deploy, not a checklist. deploy-
All three fail when they exist only as documentation, since docs rot silently while tools fail loudly and get fixed. As AI agents start creating services and triaging incidents on people’s behalf, this becomes the difference between an agent inheriting correct knowledge and one confidently acting on something stale.