What Does Engineering Leadership Actually Do All Day?

I used to count what I built

Early in my career, a productive day was one I could point to. A router configuration that held up under load. A script that took a manual job off someone’s plate. A bug closed, a feature shipped, a system I designed running in production. The evidence was in the commit history or on the network graphs, and nobody had to tell me whether I’d done a good job.

That habit came with me when I co-founded a company and became its CTO. For a long stretch I was most of its engineering department, which I’ve written about in why I still write code, so counting my own output still worked. Then the company grew into a global team of more than 30 engineers, VoIP specialists and designers, and the measure quietly stopped working. I could spend a whole day on decisions and conversations and have nothing to point to at the end of it. Some of those turned out to be my most useful days. It took me a while to believe that.

So what does an engineering leader actually do all day? In my experience, most of the day goes to decisions and the people making them: deciding what to build and what not to, weighing delivery against reliability, security and cost, clearing obstacles, developing engineers, and explaining technical risk in terms the business can act on. Writing code becomes a smaller share of the job, and often not the most valuable one.

Faster for me, slower for everyone else

When you built the first version of a system, you know where everything is. Someone brings you a problem and you can often fix it faster than you can explain it. So I fixed things. It felt responsible, and in the moment it usually was faster.

The cost showed up later. Every problem I took back taught the team that hard problems came to me. Decisions queued behind my calendar, and engineers who could have worked something out stopped trying, which was reasonable when I was going to step in anyway. I had become the bottleneck I would have flagged in anyone else’s system. The longer version is in the founder story.

The lesson is easy to say and still hard to practice. Being able to solve a problem doesn’t always mean I should be the person solving it. My job moved toward making sure the team could solve it: giving people the context and the constraints, handing over ownership, and leaving room for them to do it differently than I would have.

Later roles pushed the same way. As a VP of Operations I rebuilt an engineering team, and as CTO of a media publisher I worked with the CEO on the business and operations as well as on the platform. Neither job would have worked if every hard problem had waited for me.

Much of the work happens before anyone writes code

A request usually arrives with a solution already attached: a dashboard, an integration, a new service, a redesigned workflow. The team could build it. The first thing I want to know is whether we should, and whether a smaller version would solve the actual problem.

Plenty of requests are exactly right as written, so this is a habit of asking rather than refusing. Still, the most expensive engineering work I’ve seen is work nobody needed, and the same goes for architecture nobody needed. A team can deliver on time with clean code and still spend a quarter on something that didn’t deserve it. A question asked before the work starts is one of the few places where a leader can save weeks with a single conversation.

Can we make this simpler for the user?

The place I push back most often is the shape of the feature itself. When a UX design or an implementation proposal adds screens, states, settings and branching behavior that the user’s problem doesn’t seem to need, I ask the question I’ve probably asked more than any other as a leader: can we make this simpler for the user?

People sometimes hear that as an engineer who wants to write less code. Less code is a side effect. I want us to solve the real user problem with the simplest experience that works, because when time and people are limited, extra complexity lands on everyone involved, starting with the user.

For the person using it

Users shouldn’t need training to understand a feature. A more complicated interface might do more, but more capability doesn’t make it better for the person in front of it. Teams, mine included, can get so focused on what the system is able to do that we stop picturing someone trying to finish a task on a busy afternoon. Every extra choice, step and mode is something they have to understand before they get what they came for. A simpler workflow means less confusion, fewer steps and less time to finish. I learned that first on a support line, back when I designed every screen myself.

For the developers

Complexity is implementation time. Each additional screen, state, interaction and conditional path is code to write, review and maintain, and the ways those pieces interact multiply faster than the list grows. When we simplify the experience, the team can usually deliver sooner, which puts working software in front of users sooner. Less scope also makes for smaller stories and pull requests that are easier to review and safer to ship.

For QA

Every additional workflow is more scenarios to test. Two optional settings that each change behavior already make four combinations, before anyone tries them on a phone, over a slow connection or with a screen reader. A complicated feature takes longer to validate and gives defects more places to hide. A simpler one gives QA a test surface they can cover within the release timeline, instead of choosing which paths to skip.

For the business

Add those up and a simpler first version means working functionality sooner and user acceptance testing that starts earlier. It takes less development and QA effort, puts less pressure on the release commitment, and costs less to maintain afterward. Most importantly, it gets feedback from real users before we invest in more complexity. The benefit runs through the whole delivery process, from design through development, testing, release and adoption.

Engineering leaders should push back on unnecessary UX complexity because it costs everyone at once. Users have more to learn, developers have more to build and maintain, QA has more to test, and the business waits longer for feedback while carrying more release risk. The aim is to remove complexity the user’s problem doesn’t need while keeping essential functionality, accessibility, security and usability.

Simpler has limits

Simplifying can go too far. An oversimplified design can hide information people need, behave in ways that surprise them, or leave out something the requirements depend on. Removing the confirmation from an action that can’t be undone doesn’t count as simplifying, and neither does cutting accessibility, security or a permission check to save a sprint.

The test I use is whether a piece of complexity earns its place. If a designer can show that users will get lost without something, or QA can show a case we would otherwise get wrong, it stays, and I’m glad someone made the case. When nobody can say yet who needs it, I would rather ship the simpler version, watch how people use it, and add complexity when the evidence asks for it.

Why this is a leadership call

Everyone in that conversation is doing their job. An engineer focuses on implementing the design. A designer is trying to create the best experience they can. QA wants to know the functionality works, and product wants to deliver the capabilities that were requested. Each of those views is right about its own part of the work.

My responsibility is the whole picture. I want to know whether the extra complexity is necessary, whether it improves the experience enough to justify what it costs to build and test, and whether a simpler version could solve today’s problem while we learn from users. Those questions sit between roles, and if the engineering leader doesn’t ask them, there’s a good chance nobody will.

For me, that is the difference between being responsible for implementing a solution and being accountable for delivering the right outcome. Implementation asks whether we built what was specified. Accountability asks whether what we specified was worth building in that form, given the users, the team, the testing effort and the release date. Sometimes the most useful leadership decision is to question a design before the team spends weeks building it.

Clearing the way without standing in it

Some of my most useful days produce nothing I could attach to a ticket. A team is blocked on another team’s change. Two groups each assume the other owns a piece of work. A decision has been sitting with three people who can each block it and none of whom can make it. Sorting those out is my job, whether that means resolving the dependency, making ownership explicit, or escalating when the block needs someone with more authority than I have.

The risk is that removing obstacles turns me into a new one. If every blocker routes through me, I’ve rebuilt the bottleneck and given it a nicer name.

The way I try to avoid becoming a bottleneck is to fix the cause of a blocker as well as the instance: name an owner, write the decision down, and give the team the context to settle the next one without me. I don’t want engineers waiting on me for decisions they are closer to than I am.

That connects to the part of the job I care about most. I want to develop people who could eventually take over what I do. That means mentoring, sharing the context that usually stays in leadership meetings, and delegating decisions that matter, not only the ones nobody else wants. It also means accepting that someone will solve a problem differently from how I would. Sometimes their way turns out better. Sometimes it’s worse in a way that’s cheap to fix, and they learn more from it than they would have from my version. I go into this further in why I enjoy mentoring and on the mentorship page.

Explaining technical problems as decisions

A good part of my week is translation. When something goes wrong, or looks like it will, the people who need to act on it rarely need the technical detail first. Engineers tend to lead with the cause because that’s the interesting part to us. The business needs to know what changes for them. So I try to cover four things in plain language:

• The impact on customers and the business, as it stands now
• The risk that remains and how likely it is
• The next steps, with an owner and a date for each
• The decisions or tradeoffs that need someone above the team

The technical detail goes underneath for anyone who wants it. Translation runs the other way too. When I explain to the team why the business needs a date, or why a feature matters to a particular kind of customer, engineers can make better tradeoffs on their own without coming back to ask.

Work that never shows up in a tracker

Some of the most valuable leadership decisions leave nothing behind to look at: a project that never started because a smaller change solved the problem, a service that was never created, a design simplified before anyone built the complicated version, or a risky change that got a rollback plan it turned out not to need. None of that appears as a completed ticket. It’s hard to measure and easy to undervalue, and I include myself in that. I’ve had to get comfortable with a good week looking quiet from the outside.

Today against tomorrow

The same tension runs through most planning conversations I’m part of. Shipping features matters, because it’s how the business keeps earning the right to invest. Reliability, security, maintainability and the team’s ability to keep delivering matter too, and they rarely have a stakeholder asking for them by name. The right balance depends on the company. A startup looking for its first paying customers and a team running a public-sector system people depend on should make different calls, and I’ve worked on both sides. I wrote more about matching the process to the risk in speed versus quality and when process helps.

Not everyone will like where I land. My job in those conversations is to make an informed decision, explain the tradeoff and own it, so that people who disagree at least understand why.

The parts I’m still learning

Some of this job stays uncomfortable. I push back on deadlines that aren’t realistic, and on technical proposals from people I respect. I address performance problems directly instead of hoping they improve on their own. When something my team shipped goes wrong, I take accountability for it in front of the business, whether or not I wrote the line that caused it.

I don’t always get those right. Sometimes I still want to jump in and fix the problem myself, especially when it’s technical and I can see the answer. Sometimes I hold onto a decision too long or hand one off too early. Sometimes I argue for the simpler version and later wonder whether we left out something users needed.

What helps is treating my own decisions the way I would treat a change in production: watch what happens, and change course when the results say I should. Every organization and team is different, and an approach that worked with one group can be wrong for the next. I don’t expect to finish learning this.

Short answers