The feature works. Tests are green, the PR is approved, the demo went fine. You close the ticket, and you're allowed to enjoy it.
Then it meets production. Someone pastes an emoji into a field that has never seen one. A partner's API starts returning empty responses with a 200. Marketing emails the entire customer list and forgets to tell engineering.
None of that was in the ticket, and all of it lands on somebody.
I've come to think this is the real dividing line in our work. Plenty of developers can build a feature. The ones people trust, the ones who end up leading whether or not it's in their title, stay curious about what happens after the merge. Leadership in engineering rarely looks like giving orders. More often it looks like someone asking, a week before launch, "What happens when this breaks?" and then sticking around to help find out.
Here are six things that person tends to think about. Each one ends with a question. Answer it for the last thing you shipped, and be honest, since nobody's grading.
Can you see what your users see?
Most of us add logging in the last ten minutes before opening the PR. A few console.log calls, a try/catch that swallows the error and returns a 500, done. That feels fine until production does something strange and you realize you have no idea what happened.
A healthy server doesn't mean a working product. Plenty of outages happen while every dashboard is green and nobody can check out. So start from the user's journey. Can someone sign up, search, pay? How slow is search for the unluckiest one user in twenty? Build those questions into the feature from the start, with structured logs, traces that follow a request across services, and a request ID you can paste into a search box at 2 a.m. Keep the detail in traces and logs and go easy on metric labels, because high-cardinality metrics get expensive fast.
Alerts deserve the same honesty. "CPU is high" teaches people to ignore alerts. "Payment gateway latency is over two seconds and about 5% of users are affected" gets someone out of bed for a good reason. If an alert wouldn't change what you do at 3 a.m., fix it or delete it.
Ask yourself: if your last feature broke tonight, could you work out why in a few minutes using only what it already logs?
Plan for the sad path
Networks drop packets. Third-party APIs have bad afternoons. Junior developers build for the happy path, and that's fair, because it's the one you can see. Growing as an engineer mostly means learning to see the other one.
If the recommendation service goes down, the shop should show popular items instead of a blank page. A fallback list takes an hour to build. A blank page on a busy Saturday takes a lot longer to live down.
Retries need care too. A retry with no limit and no backoff turns a small blip into an outage, because every client hammers the struggling service at once. Timeouts, exponential backoff with a little jitter, and a circuit breaker that stops calling something clearly down are all ordinary tools, and together they keep one broken feature from becoming a broken app.
Then rehearse the rollback. A rollback you've never tried is just a hope. Do it on a quiet Tuesday, on purpose.
Ask yourself: if a service your feature depends on vanished for an hour, what would your users see?
Somebody is paying for that query
In a pay-per-request world, your code shows up as a line item on someone's invoice. You don't need to become an accountant, but you should know roughly what your feature costs to run. Is that nightly job sitting on an instance sized for Black Friday? Would rewriting one slow query take a real bite out of the database bill? People call this practice FinOps, and it's less about cutting costs than about knowing them.
It cuts the other way too. The most elegant solution isn't always the right business decision. A managed service that costs more per month than the box you could run yourself can still be the cheaper option once you count the weekends someone spends patching that box. What matters is making the trade-off knowingly, with numbers, and not finding out from an email from finance.
Ask yourself: do you know, even roughly, what your last feature costs per month?
Ask how it could be abused
Security is cheapest at the start and most painful in the last week before launch. Try a five-minute habit before you write any code: ask how someone could misuse this. Where could they inject something? What happens if they change an ID in the URL? What are we exposing that we forgot was sensitive?
Privacy belongs in the same conversation. Know where user data lives, how it's encrypted at rest and in transit, and whether you could really delete a person's records if they asked. GDPR and CCPA turn that last question into an obligation, and if customers start asking about SOC 2, the answers should already exist.
And remember the code you didn't write. Your node_modules folder or your pip requirements are a big attack surface with your name on it. Automate the dependency scanning, and pay attention to where a package comes from.
Ask yourself: did anyone ask "how could this be abused?" before your last feature was built?
Make the right way the easy way
Once you're senior, your output stops being only your code. It's what the whole team can ship on a Tuesday afternoon without a knot in their stomach. That means caring about the unglamorous things: a template that gives every new service logging and health checks by default (some platform teams call these golden paths), a pipeline fast enough that nobody skips it, a deploy that takes a click and doesn't need a hero.
Here's a test. If deploying to production still makes your team nervous, the pipeline is telling you something, so listen.
Write things down, too. A short architecture decision record and a README that works will save a new teammate from six meetings. Two years from now nobody remembers why a decision was made unless somebody put it where it can be found. That somebody is usually you, and you'll be glad you did.
Ask yourself: could a new teammate deploy and debug your last feature using only what's written down?
Talk in outcomes
This is where I see people get stuck most, which is a shame, because it's the easiest one to fix. Engineers tend to argue for work in engineering terms: "We should split this into microservices." "We need to upgrade the database." Then we're surprised when the answer is "maybe next quarter."
Try the same request in the language of whoever owns the roadmap. Splitting the monolith becomes "marketing can launch campaigns without waiting on a full release." The database upgrade becomes "no downtime during the holiday sales peak." Same work, completely different conversation.
Measure what shows whether the team is healthy, too. The DORA research boils it down to a handful of numbers: how often you deploy, how long a change takes to reach users, how often a change breaks something, and how quickly you recover. They tell you far more than lines of code or story points ever will.
And a word on tech debt: not all of it is bad. Sometimes you borrow on purpose to hit a market window, and that can be the right call. The mistake is borrowing without writing down the terms. Have a plan to pay it back, and get comfortable asking your product manager for that time before the interest piles up.
Ask yourself: do you know which business number your last feature was supposed to move?
Owning it
You'll hear "you build it, you run it" a lot, and it can sound like a threat. I'd read it as an offer. The closer you are to production, the faster you learn what actually matters to the people using your work.
In practice it means staying reachable for what you ship, writing the runbook while the details are fresh, and caring how a customer experiences your work as much as you care about the elegance of your algorithm. It won't always be comfortable. It will make you better, and the people around you will notice. They'll start pulling you into decisions instead of just handing you tickets.
Count your answers. Wherever you said "not really" is where I'd start this week, and it's rarely a big project. Ask the newest person on the team to deploy your feature from the docs alone. Switch off one dependency in staging and watch what happens. Open the cloud bill and write down one number.
Then, if you lead a team, ask them the same six questions about their last release. The gaps usually show up there first, and that conversation is where the leading actually happens.
If you have a production story that changed how you work, I'd like to hear it.
Top comments (0)