Tag: leadership

Six Weeks?!

Six weeks was the runway we had to rebuild a product that had taken ten years to develop, feature by feature, config by config. The custom hardware it ran on had reached end of life, and the business needed it running on Android hardware before the old platform went dark. There was no negotiating the deadline. There was only the work.

I tried to get ahead of it. I pushed to split the architecture handoff into two pieces: the networking library that everything else depended on first, and the UI and business logic second. That way part of the team could start two weeks early on the prerequisites while we waited for the rest of the spec. It was the right call, and it bought us some time.

Then the second dump arrived. Fifty pages of detailed technical specifications, with a refinement session scheduled for the following day. Not nearly enough time for anyone to build a mental model of what they were reading, let alone turn it into a coherent set of stories. We sat in front of a whiteboard with handfuls of sticky notes, trying to figure out what our story layout should even look like. We did our best. Maybe half the work got refined. With five weeks left and pressure mounting, we had to start building somewhere — refined or not. The team lead tried to finish refinement solo while the rest of the developers started chewing through the stories that were ready.

Go! Go! Go!

When the safety net got pulled

Before the first architecture dump even landed, a decision came down from above: cancel all unnecessary meetings. Concentrate. No distractions. That included 1-on-1s.

That was the decision that hurt us the most. My 1-on-1s aren’t status meetings. They’re the primary channel through which my team members tell me what they’re struggling with, where we can set goals and work toward them, and where we can pull things back before they become a crisis. Cancelling them at the very start of the most stressful project of the year didn’t help the team concentrate. It left them without a reliable way to escalate, and left me without the insight I needed to help.

All I had was the morning scrum. And by the time something surfaced there, the runway to fix it was already short.

So when problems started happening (and the incomplete refinement made sure they did) there was very little I could do about them in time. No working agreement meant no plan for pulling things back on track. Scope doubled. Last minute requirements jumped the line. Must-fix bugs as far as the eye could see.

I stayed online with the team through weekends to keep them unblocked. I was up until 2am helping debug where I could. I negotiated with product to cut even one requirement so the rest could ship on time. We were working hard instead of working smart, and we all knew it.

The team made the deadline. Ninety-five percent complete, against all odds. They went straight into bug-fixing mode the following week, chasing must-fixes and as many nice-to-haves as they could reach. And my job became documenting everything that had gone wrong, so that it would never happen again.

What I wish we’d protected

The lesson wasn’t about balancing deadlines or managing technical complexity. It was simpler than that.

When a crisis hits, the instinct is to throw out everything that feels like overhead and just run. Cancel the meetings. Skip the process. Heads down, ship it. But the things that feel like overhead in a crisis are usually the things that were keeping the team functional. The 1-on-1s. The refinement sessions. The working agreements. The feedback loops. Strip those out and you don’t get a leaner, faster team. You get a team running in the dark, working harder instead of smarter, with no early warning system and no way to course-correct.

Honestly, I wish I’d pushed back harder on the 1-on-1 decision. I understood the pressure, and I tried to work within the constraints I was given. But those conversations were load-bearing, and losing them cost us more than the time they would have taken.

Protect your Process.

From Senior Engineer to Director: A Story About Trust

Being a director means accepting that you can’t review every PR personally or weigh in on every architectural decision. Trying to do both produces engineers who stop thinking for themselves because they know you’ll think for them. The job is to build a team you can trust, and then trust them.

That’s harder than it sounds. As an engineer, your judgment is grounded in what you know. You can evaluate a solution because you understand the problem. But a director is regularly asked to evaluate solutions to problems that sit outside their immediate expertise. The question stops being “is this technically correct?” and starts being “do I trust the person bringing this to me, and have they earned that trust?”

How trust gets built

Trust on a technical team isn’t given, it’s built over time and effort. I track it through the things that are actually visible: a developer’s commit history in the codebase, the quality of the code reviews they give and receive, the features they’ve shipped that have passed QA without drama.

Over time, a picture forms. Some engineers consistently bring clean, well-considered work. Others bring good instincts but need more guidance. A few surface tech debt that genuinely improves quality of life for the whole team, which tells you they’re thinking beyond their own ticket.

At the same time, I’m working to earn their trust as their director. They need to know that when they bring me a real problem, I will either help solve it or find someone who can. That consistency is what makes them comfortable surfacing issues early rather than sitting on them until they become crises.

Trusting the track record

My tech lead came to me with a proposal to refactor one of our smaller apps around a state machine pattern, using Jetpack Compose. The pitch was that predictable inputs and outputs for any given screen would reduce our error rates significantly.

Jetpack Compose was still relatively new, and our team didn’t yet have deep experience making it work well in production. I couldn’t evaluate the technical specifics from first principles. What I could evaluate was his track record: consistently well-regarded by his peers, thoughtful in his reviews, right on his previous proposals. That was enough to work with.

Rather than defaulting to skepticism, I worked with him to develop the proposal into a full development plan to bring to the product team. The refactor took about two months. Since then, that app has needed only minimal updates to add new hardware support.

This project wouldn’t have gotten off the ground without trust working in both directions. He trusted me to champion something he believed in, and I trusted his judgment on how to accomplish it.

What building trust actually looks like

Trust flows naturally from the structures you put in place: code reviews that give engineers real visibility into each other’s work, training that raises the floor across the team, clear expectations about what good performance looks like. The more deliberately you build those structures, the more confidently you can trust the judgment that comes out of them.

The goal is a team where everyone is bringing their best thinking to the table, and where the director’s job is to synthesize that thinking, clear the path, and back the right ideas. When it’s working, the team can do things that no single engineer could do alone.

The Feedback Loop is a Feature

I’ve noticed that the best software teams have one thing in common: they get better over time. Features ship faster. Bugs get caught earlier. Cross-team dependencies cause less chaos than they used to. It usually comes back to the same thing. They have feedback loops, and they’ve built them deliberately.

A feedback loop is a simple system for surfacing information early enough to act on it. The earlier you catch a problem, the cheaper it is to fix. That principle scales from a single line of code all the way up to a cross-team architecture review — and the teams that apply it at every level are the ones that compound.

Small loops, big returns

The easiest feedback loops to build are the small ones inside your own team. They don’t require negotiation with other teams or sign-off from leadership. They just require someone paying attention and a process for acting on what they hear. Our team holds regular retrospectives to solicit feedback on anything the team wants to improve — tooling, process, workflow, whatever is slowing people down or making their day harder.

One of the more impactful suggestions came out of one of those sessions. The idea was simple: one analyst writes up the test cases, a second reviews them to check for gaps, and then either analyst can run the tests because both understand them fully. Analysts with different testing styles could backstop each other, which meant the test suite got more complete over time rather than reflecting the blind spots of any one person. We had a structural improvement that raised the floor on our release quality.

But feedback loops need to close quickly. Feedback that goes nowhere teaches the team that feedback doesn’t matter. Every suggestion that gets implemented, or thoughtfully declined with a reason, reinforces that the channel is real.

Structure the conversation early

The bigger the dependency, the more expensive the feedback loop becomes if you build it too late. When we were integrating against an API being built by another team, we had a chance to apply this lesson on the second version of that integration.

Before anyone wrote a line of code, my lead developer asked me to put together a step-by-step integration guide that laid out exactly how our UI expected to use the interface and what error cases we anticipated encountering. We presented that framework directly to the server architects and asked them to redline it, push back on our assumptions, and flag anything we’d gotten wrong.

The result was that a significant portion of the hard integration work got done on paper before it got done in code. Both teams understood the contract. The architects could design around our actual needs rather than their assumptions about them. And when surprises did come up, they came up in a document rather than in a sprint.

That’s what a feedback loop looks like at the cross-team scale. You’re giving the team a structured opportunity to get their needs addressed. This will surface the issues earlier, when they’re still cheap to resolve.

What makes any of this possible

Whether it’s a QA process review or a pre-integration framework document, the underlying principle is the same. Find the point where information needs to travel between two parties, and build a structure that makes that travel faster and more reliable.

But none of it works without psychological safety. The QA suggestion came from analysts who felt comfortable saying “our process has gaps.” The integration framework came from developers who felt comfortable saying “we need more structure around this before we start.” Both of those conversations require people to be willing to surface a problem before they have the solution.

That willingness only happens on a team that trusts its leadership to hear problems as information rather than complaints, and to work through them collaboratively rather than defensively. When that trust exists, your team becomes your best early warning system. They will bring you the questions, the concerns, and the half-formed ideas before they become crises — and they will help you solution your way through them.