What I learned leading an engineering team at Oracle

I spent four years as an engineering team lead at Oracle Global Services, on a team split between Romania and Kansas City, working on clinical systems. Twenty-plus milestones, an eight-hour time difference, and a domain where being wrong has consequences beyond a rollback.

This is not a management manifesto. It is the handful of things I would tell myself at the start, written for engineers considering the same move — and for the ones who want to understand what their lead is actually doing all day.

What actually changes?

The honest version: your output stops being code and starts being other people’s ability to produce code. That sounds like a poster. It has a very concrete consequence — the feedback loop that told you whether you were doing well disappears.

As an engineer, you know by Thursday whether Monday’s work was good. As a lead, the signal arrives in weeks and it is noisy. My first instinct was to keep writing code, because that was the part where I could still tell I was useful. That instinct is understandable and it is a trap: the team was waiting on decisions I was too busy to make.

Before	After
Solve the hardest problem yourself	Make sure the hardest problem is being solved by the right person
Know your part of the system deeply	Know where the seams are, and who knows what
Optimise your own throughput	Optimise for the team not being blocked
Feedback in days	Feedback in weeks, indirectly
Being right is the goal	Being right and alone is a failure

That last row took me the longest.

Should you stop writing code?

Not entirely, and not for the reason usually given.

The argument you hear is “stay technical so you keep credibility”. That is real but secondary. The better reason is that if you never touch the code, your estimates decay silently — you start believing your own mental model of a codebase you have not opened in a year, and you commit the team to dates based on it.

What worked for me: stay in the code, but pick work that is interruptible and off the critical path. Tooling, the build, test infrastructure, the migration nobody has time for. Never the feature the milestone depends on. The moment your own task is on the critical path, every interruption becomes a cost you resent, and a lead who resents interruptions has stopped doing the job.

What does a time-zone gap really cost?

Eight hours between Brașov and Kansas City means roughly two hours of overlap on a good day. Everyone knows this costs communication. What is less obvious is which costs are avoidable.

The expensive failure is not the delay — it is a question that takes 24 hours to answer. One blocking question asked at the wrong hour costs a full day, and three of those in a sprint is a missed milestone that looks like an estimation failure.

What we changed:

• Written by default. A decision that lives in a call exists only for the people on that call. Written decisions survive the timezone. This is also, not coincidentally, exactly what a regulated environment wants from you anyway.
• Optimise for unblocking, not for status. The overlap window is the scarcest resource you have. Spending it on a status round-robin — information that could have been read asynchronously — is the single most common waste I have seen.
• Ask questions in a form that can be answered while you sleep. “What do you think about X?” costs a round trip. “I’m going with A unless you object, because B breaks the Y case” costs a round trip only if someone objects. The second form is a skill, and it is teachable.

How do you review code without becoming the bottleneck?

Review is where a lead has the most leverage and does the most damage.

Two mistakes I made. The first: reviewing everything, which made me a queue and taught the team that quality was my job rather than theirs. The second, correcting for the first: reviewing nothing, which meant standards drifted in four directions at once.

Where I landed:

• Review the boundaries, not the interiors. Public interfaces, data model changes, anything touching security or the audit path, anything that sets a precedent. The body of a well-tested function is someone else’s review.
• Separate “this is wrong” from “I would have done it differently”. Say which one you mean, explicitly. A lead’s stylistic preference is heard as a requirement, and you will spend a team’s afternoon on something you did not care about.
• Explain the why, once. A review comment that only says what to change teaches nothing and you will write it again next month. One that explains the reasoning is a lesson; the same person will not need it twice.

The mentoring instinct that this builds transfers well outside work, incidentally — I have found the same pattern holds when volunteering with kids learning to code at CoderDojo Brașov. Explaining why is what scales; explaining what does not.

What about estimation?

The most useful thing I learned about estimates is that most of the error is not in the estimate.

Teams do not usually misjudge how long the work takes. They misjudge how much other work will arrive, how long reviews will wait, how many dependencies will move. The engineering time is estimated reasonably well; everything around it is estimated at zero.

Two practices did more than any estimation technique:

• Estimate ranges, and say what the range depends on. “Three to eight days, eight if the external integration behaves like last time” is information. “Five days” is a number that will be treated as a commitment.
• Track what actually blocked you. After a few sprints, the pattern is visible and boring — the same two or three sources of delay, every time. That list is worth more than any velocity chart, because you can act on it.

What did the regulated domain teach that generalises?

Clinical systems come with process overhead: traceability, controlled changes, documented verification. It is easy to read that as pure friction, and some of it is.

But the underlying habit generalises further than I expected: you are asked, routinely, to explain why you believe something works. Not to assert it — to show the reasoning and the evidence.

That is a good habit anywhere. It makes design reviews sharper, it makes code review comments concrete, and it makes the difference between “I tested it” and “here is what I tested and what I deliberately did not”. I carried it into my own products, where nobody requires it of me, because it turns out to be how you avoid shipping something you merely hope works.

The one thing I would tell myself

Decide, and say what would change your mind.

The most damaging thing I did in the first year was defer decisions in the name of consensus. A team blocked on a decision does not experience your caution as thoughtfulness; it experiences it as ambiguity, and it fills the gap with four different assumptions.

Making a call that turns out to be wrong is recoverable — usually cheaply, usually within a sprint. Leaving four people to guess for two weeks is not. Decide, write down the reasoning, and name explicitly what evidence would make you reverse it. That last clause is what makes deciding quickly compatible with being wrong occasionally.

If you are moving into a lead role and want to talk it through with someone who has made the obvious mistakes already, I am happy to have that conversation.