My job doesn’t afford me a lot of time to actually write code. Two years ago, that sentence would have felt like a real loss. Even early last year, coding with GenAI felt like working with an overly ambitious autocomplete plugin — occasionally faster than searching StackOverflow, but not fundamentally different. Fast-forward to today and the conversation has shifted from “should you be using AI coding assistants?” to something more interesting: over 90% of engineers are already using them. The question now is how to adapt your workflow to make the most of them.

For me, the answer has been agentic development, and it has made building software feel genuinely exciting again.

The Problem With The Old Way

Recently, I needed to help a team meet some regulatory requirements that involved verifying data against a series of repositories provided by a third-party. They had an API, so the plan was to build a small tool to simplify interaction with these data sources and eventually automate the process entirely. Multiple endpoints, rate limits, batching logic for partial failures, a range of error codes, multi-environment support — not a trivial project, but it was relatively self-contained and not related to anything on any of my teams’ roadmaps.

In a pre-AI world, my workflow would have looked something like this: pick a language, find boilerplate examples, wrestle with authentication, build a stub, test, fail, revisit docs, test again, succeed. Then repeat for every endpoint. Then remember all the things I forgot: error handling, secrets management, test coverage.

Given that my opportunities for deep, focused coding time are rare, getting to a working MVP normally took a week or more, and I’d be working in fits and starts the whole time.

The worst part was that almost none of that learning transferred. Every API is different. I’d spend most of my time acquiring knowledge I’d never use again. The boilerplate (the part that isn’t actually adding value to the solution) consumed the most time every single time.

The Agentic Approach

This time, I wanted to try something different: a more agentic workflow. This is fundamentally different from AI-assisted coding, where the engineer is still the primary driver and the AI is making just-in-time suggestions.

In an agentic workflow, you’re guiding an AI agent while the agent does most of the work. It’s not unlike how a senior engineer might work with an early-career engineer today: describe the desired end state, the constraints, the available resources, and then let them go solve the problem.

I started with a plan. Instead of jumping into code, I gave the agent all of the API documentation as context, described the endpoints I needed to consume, explained the input format, and specified what the output should look like. Then I asked it to draft an approach before writing a single line of code. This mirrors how we already work on complex engineering problems. We write an RFC before building, catching gaps in logic before the expensive work begins.

The plan was solid. The agent understood the API specs from the PDF I’d shared, and even suggested support for multiple data upload formats I hadn’t considered. I approved the plan and moved on to other work while it built.

A few minutes later, I had working software to test against. The happy path ran fine. I tried breaking it and found missing error states with unhelpful messages. I pointed the agent to the error code documentation and asked it to update the solution accordingly. A few moments later, I had a more robust iteration.

This continued for about 90 minutes. Sometimes I told the agent what to do. Other times I asked it to compare two approaches and recommend one. By the end, I had a production-ready tool that handled failure cases, multi-threading, and rate limiting. The tool did its job: the regulatory verification process that previously required manual effort can now run automatically.

Building this the old way would have taken weeks.

Software Engineering Is Dead. Long Live Software Engineering.

Here’s what surprised me most: this experiment worked because of my software engineering background, not despite it.

One API endpoint supported concurrent requests. I knew that meant I could process data faster, but also that any one of those requests could fail partially. I asked the agent to record successes and failures separately so I could inspect failures without reprocessing everything. That’s not intuition the agent would have surfaced on its own — it came from experience with distributed systems. A less experienced guide might not have caught it.

In another moment, my tests failed due to a variable referenced outside the scope where it was defined. I spotted the issue immediately and told the agent exactly where to look and how to fix it, which was faster and cheaper (in tokens) than asking it to debug from scratch.

This points to something important about where the industry is heading:

Software engineering principles still apply. The how matters less. You no longer need to know which HTTP library a language favors or how to structure a project scaffold from memory. But you still need to understand resiliency, testability, and performance to guide an agent toward a solution that actually holds up.

Understanding the goal matters more than ever. They say you truly understand something when you can teach it. To be effective in an agentic workflow, you need to deeply understand what you’re building and why because that context is the primary input.

This is a meaningful unlock for engineering leaders. Most writing (and research) about AI-assisted coding addresses engineers who code all day. This is for the ones who used to. Agentic tools lower the floor on staying technically close to the work, whether that’s building ad-hoc tooling, supporting a team under pressure, or prototyping a solution quickly. The old methods are changing in ways that make them more accessible to those of us who haven’t had the maker time to participate in the same way.

When you don’t have to fight the learning curve, building is fun again. Previously, my limited coding time was consumed just getting setup working and boilerplate in place. Now I can jump to the actual problem in a fraction of the time.

What This Means Going Forward

As an industry, we’re still working through the implications: converging roles, upended assumptions about who can write code and what good code looks like, genuine uncertainty about what engineering careers look like in five years.

But the leaders who will thrive in this next phase won’t be the ones who hand off technical judgment to the agent. They’ll be the ones who bring deep enough understanding of what good software looks like to guide it well.

The floor on staying technically close just dropped. The ceiling on what that closeness can produce just went up.

I first learned to code because I wanted to build things — to solve my own problems, then other people’s. In a world where engineering leaders are being asked to deliver more in less time with fewer resources, time is the most precious commodity we have. Agentic workflows give some of that time back, and they do it in a way that makes the building feel like building again.

In a remote-first world, where most collaboration happens asynchronously and an increasing amount of work depends on how well we structure context for other humans and for LLMs, written communication has quietly become a force multiplier for leadership.

Writing doesn’t just communicate intent—it sharpens it. The act of writing forces you to slow down, clarify assumptions, and pressure-test your own thinking before asking others to engage with it. When shared, writing scales your priorities far beyond what meetings or real-time conversations can reach. It creates durable signal. People look to leaders for cues about what matters, and writing those priorities down reinforces them in a way spoken communication rarely can.

This is why establishing a weekly internal writing practice has been one of the highest-leverage habits I’ve developed as an engineering leader.

Communicating Is Hard. Communicating Broadly Is Harder.

As organizations grow, communication doesn’t get incrementally harder. It changes entirely.

Early on, when a team is fewer than ten people, communication is direct. Everyone can be involved in most discussions, context travels quickly, and consensus is relatively easy to reach. Somewhere around ten people, that starts to break down. Roles specialize, attention fragments, and not everyone needs, or wants, to be part of every conversation.

You tend to see additional inflection points around 25, 50, and again around 100 people. The exact numbers vary, but the pattern is consistent: as headcount grows, the cost of shared context rises faster than the team itself.

Metcalfe’s Law helps explain why. Originally developed to explain telecommunications network complexity, the law states that as the number of nodes in a network grows, the number of possible connections between those nodes grows exponentially. A team of 25 people has roughly 300 possible communication paths. At that scale, it’s no longer feasible to rely on synchronous conversation or informal channels to keep everyone aligned.

The key takeaway is simple: while team size grows linearly, communication complexity grows exponentially. At a certain point, it becomes impossible to traverse every path and leaders must shift from participating in communication to designing for it.

My Journey

For most of my career, collaborative chat tools have been the primary mode of communication (RIP HipChat). I’ve leaned heavily into ChatOps across multiple roles, pulling deployments, incidents, customer support requests, and operational alerts into tools like Slack and Teams.

While these tools are incredibly powerful, they’re also incredibly noisy.

I’ve written before about the cost of constant interruption, but there’s a second-order effect that shows up as teams scale: important announcements get lost. Major changes, new initiatives, or business updates scroll by in a sea of messages. Some people see them in the moment. Others catch up later. Some never see them at all.

When teams are small, this is manageable. Daily standups and regular team meetings provide natural reinforcement. But as organizations grow, those shared forums disappear. You now have multiple teams, each with their own priorities and roadmaps. Chat remains great for real-time coordination, but its ephemeral nature makes it a poor substitute for durable communication.

What gets harder still is communicating why certain initiatives matter: product changes, engineering investments, or shared learning across teams. People who were around in the early days often miss the sense of omniscience they once had. They want context, but there’s no longer a single place to get it.

Publishing Alignment

By the time an engineering organization reaches ~20 people, no one, including the leader, has full visibility anymore. The challenge becomes maintaining alignment without sacrificing autonomy.

This is where a lightweight, weekly written update becomes incredibly effective.

I’ve found that a short internal post, shared with Engineering and key partners in Product, Design, and other functions, strikes the right balance. The exact format matters less than the consistency, but this structure has worked well for me:

Intro

Start with an industry article, research paper, or internal topic. Summarize it briefly and share your perspective. This sets the tone and signals the kinds of problems you’re spending time thinking about.

Org-Wide Updates

Use this section to highlight initiatives that affect the entire engineering organization. This reinforces priorities and helps teams understand what’s happening outside their immediate scope.

This is also where you should share your work. As a leader, your job is to work on the system, not in it. Making that work visible helps others understand how decisions are made and what outcomes you’re driving toward.

Team Updates

A few sentences per team is enough. Focus on outcomes: launches, decisions, progress against goals. This keeps people connected to the broader organization without dragging them into day-to-day details.

Pro Tip: Once you have managers reporting to you, delegate this section. It gives them practice writing for a broad audience and reinforces an outcomes-over-output mindset.

Optional Sections

Add sections as needed. Reminders for infrequent but important tasks. A “tip of the week” when rolling out a new tool or process. Evolve the format as your organization evolves.

Publishing Tips

Consistency matters. Block time on your calendar, publish on the same day each week, and share the post automatically in Slack or Teams. I’ve found mid-day Friday tends to get more engagement than end-of-day posts that disappear into the weekend.

Templates help. Whether you use Confluence, Notion, or another tool, formalizing the structure reduces friction and lowers the activation energy to write.

Start early. Create a draft on Monday and add to it throughout the week. By the time your writing block arrives, you’re editing, not starting from scratch. This also creates a subtle accountability mechanism for the initiatives you plan to push forward that week.

The Benefits

Writing clarifies thinking. Publishing amplifies it. This practice also creates another opportunity for you to start to nemawashi ideas with a broader audience, which helps to simplify the decision-making process later on.

Over time, these posts also create a living record of your organization’s progress. Quarterly and annual reviews become much easier when you already have a weekly trail of decisions, outcomes, and lessons learned.

Pro Tip: Periodically feed your posts into an LLM to generate summaries of your organization’s most impactful work over longer time horizons. It’s an efficient way to surface patterns you might otherwise miss, and helps to avoid recency bias.

Summary

As teams scale, communication stops being something you do and starts being something you design. The informal mechanisms that work for small groups do not survive growth, and real-time tools alone cannot carry shared context across an organization.

A weekly internal writing practice is a simple but powerful way to address that gap. It forces clearer thinking, creates durable signal, and scales alignment without pulling people into unnecessary meetings or conversations. Over time, it also builds a record of decisions, priorities, and progress that makes reflection and course correction easier.

Writing is a leadership tool. Used consistently, it helps teams stay aligned as complexity grows, which is exactly when alignment matters most.

Then reality kicks in.

Weeks or months after the roll out, you review the key metrics you identified to measure impact (you did identify metrics to measure impact, right?) and see that pull request throughput is up significantly: engineers are opening more PRs now than they were before the rollout of the coding assistant.

But wait…PR cycle time isn’t down. In fact, it might be flat or even climbing. Your engineers are writing more code faster, but you’re not shipping features any faster. Local speed increased while end-to-end delivery did not. What gives?

It’s a Queueing Problem

This is a classic queueing problem.

When I was studying for my undergraduate degree in Industrial and Systems Engineering, one of my courses centered around queueing theory: the mathematical study of waiting lines. It was in this course that I learned the basic principles of work-in-progress (WIP), scheduling policies, and customer waiting behavior. It also helped explain why intuitive local optimizations often fail at the system level.

In queueing theory, the major components include the arrival process, service process, number of servers, queue capacity, and the customer population.

To use a non-technical example, think of a coffee shop. Customers arrive and get in line behind one or more registers, where a barista takes a customer’s order and makes their coffee. When the customer receives their coffee, they leave the shop.

How efficiently that queue runs depends on several factors:

• How many people are in line?

• How many baristas are working?

• How long does each order take to complete?

• Is it the 7 AM rush or the 4 PM lull?

This relationship is often summarized in Little’s Law, which describes how work accumulates in a system over time:

L = λW

In practical terms, if people arrive faster than they can be served, the size of the queue will grow. Pretty obvious, right?

The Software Development Queue

I first began connecting queueing theory to software development when trying to understand why a team’s velocity didn’t improve even after finding ways to speed up coding time. Even adding engineering capacity didn’t drive meaningful results. It followed a familiar pattern: a local improvement that failed to produce a system-wide result.

Sure, there’s the whole mythical man month problem, but surely adding just a single engineer should have a positive impact. My explanation ultimately had less to do with the number of software engineers and more to do with the number of QA engineers.

In a team where dedicated QA is part of the process, and where software must be verified before it can be considered complete, accelerating development simply increases the size of the queue. In the equation above, λ represents the arrival rate of work in the form of tickets requiring verification, while W represents the time it takes a QA engineer to review and verify a single ticket.

If QA capacity remains fixed, writing more software increases arrivals without increasing service capability. Waiting time grows, work piles up, and overall throughput remains unchanged. To resolve this, we had to either increase QA capacity or reduce verification time. Only then did throughput across the system improve.

Coding Assistants Don’t Speed Up The System

Software development is a series of interconnected queues. There’s a queue for planning and estimation, a queue for writing code, a queue for reviewing that code, and a queue for deploying to production.

A coding assistant improves the code-writing queue, but on its own it does nothing to change the service rate of the others. The output of the writing queue becomes the input to the review queue, increasing the arrival rate. If the rest of the system remains unchanged, throughput does not increase.

Just like in Braess’s Paradox, where adding roads can decrease traffic flow, adding more PRs to be reviewed can slow down overall team productivity.

Addressing Service Time In AI-Enabled Systems

A recent study from FarosAI found that while AI significantly improved individual developer performance, code review time increased by 91%. Code was produced faster than it could be reviewed, creating a bottleneck that resulted in no measurable improvement in organizational performance.

Software development is a symphony of systems that must work together to produce quality output. Improving a single component can generate impressive local gains while leaving overall system performance unchanged. To see real impact, service time must be addressed across the system, not just at the point of code creation. That means looking beyond where AI feels productive and applying it deliberately at the constraints that limit flow. Some practical ways to address constraints on flow include:

• Incorporate AI into later stages of the SDLC, including code review and deployment. Productivity gains achieved during code writing must propagate downstream. When review and deployment service times decrease alongside code creation, queues stabilize and throughput improves.

• Consider automatic approval of certain classes of pull requests. This approach requires mature test automation, observability, and governance, and may not be viable in highly regulated environments.

The 2025 DORA report describes AI as an organizational mirror, reflecting existing strengths and weaknesses. Teams lacking clear standards, documentation, testing, or release discipline will see those gaps amplified. Teams with mature systems in place are more likely to experience AI as an accelerant.

Wrapping It Up

As an industry, we are still early in AI adoption. Even with widespread use, teams continue to grapple with tools that do not fully understand intent and occasionally produce incorrect output. But we have moved past asking whether AI is useful and into the harder work of learning how to use it well.

There are no silver bullets. Bolting an AI tool onto existing workflows is not enough. Teams that ground themselves in fundamental software engineering principles, then deliberately adapt those principles to new tools, new collaboration patterns, and new delivery models, will see the greatest benefit.

AI does not fix queues. It makes them visible. If you want organizational impact, start by mapping your delivery system end to end, then invest where AI increases arrival rates or reduces service time to improve flow across the system.

Answering a Basic Question

I started my own journey toward establishing an Engineering Metrics program years ago in an attempt to answer a basic question: How can I know if the Engineering organization I lead is best-in-class? And what does “best-in-class” even mean? Okay, so maybe that’s two questions, but there’s an important distinction here: if you’re trying to use metrics to answer questions like “is my team working enough” or “should people be writing more code?”, you’ll erode any trust you might have built and end up spending more time working against people gaming metrics than you will working with your team to improve performance. More on trust and metrics later. But my original questions, the very basic question you may also be asking, is surprisingly hard to answer.

Measuring in the Wrong Direction

Like any good Engineering leader, I was well aware of Google’s annual State of DevOps Report (DORA) and the four key metrics the research group espoused as being indicative of elite organizations. For the uninitiated among us, there are plenty of other articles explaining what DORA metrics are and how to measure them and I will leave researching them in detail as an activity for the reader. The first time I tried to institute an Engineering Metrics program, I built it around the DORA metrics. After all, if it was good enough for Google, it must be good enough for us, right? As it turns out, I found starting with DORA to be difficult for two reasons: First, I found instrumenting systems to reliably measure some of the DORA metrics, such as change failure rate, to be exceedingly difficult. Measuring a failed deployment is relatively easy, but that’s really just a signal of your automation tooling’s quality. If you want to measure a failed software change, I’ve found that you also need a way to reliably measure if that software failure is an escaped failure or a latent one and that differentiation tends to be more of a rule-of-thumb and a judgement call than it is something you can automatically measure. And if you can’t automatically measure it — if you rely on people to “mark it down” every time it happens — you’re unlikely to get strong, consistent measurement of any metric as your organization grows. Some organizations do have ways to measure this, though, but I found trying to solve for this with a brand new program tended to be too much inertia to overcome at the start. Setting aside the hard-to-measure metrics, though, even the easier metrics, like deployment frequency, revealed a second challenge with DORA: no one outside of engineering really cared. I believe this was ultimately due to the fact that DORA metrics are engineering metrics, not impact metrics, and Engineering’s ultimate responsibility is to positively impact the business. There was something missing in the first few metrics programs I started that failed to launch because we weren’t able to get broader buy-in from the business about the importance of measuring the things that more research than I could ever commit to the topic had shown was highly correlated with elite performance among companies. What was I doing wrong?

Measuring Where, Not How

DORA metrics are ultimately a measurement of how a team or organization delivers. Teams who want to improve deployment frequency or lead time should first introduce automation and reduce manual toil, for example. The missing link here is that my peers and other leaders were more interested in what we were delivering. Product had their roadmaps and the things they wanted to ship each quarter to move the needle on specific business metrics, and while we were delivering against that roadmap, we knew our time was also being spent in other areas — we just didn’t know how much. This made capacity planning a challenge. We tried fancy spreadsheets with people-to-hours formulas and we built in plenty of buffer for time off, unplanned work, and even some effort to “pay down tech debt”, but there was still a gap we couldn’t reconcile. Where was our time going? Eventually, this became my new single question to answer and is the basis around which a successful metrics program was started. I set out to answer the question “where is Engineering spending our time, and how can we shift those investments into the places we want to spend time as opposed to where we have to spend time?” Ok, again, that was two questions but if you noted that, at least I know you’re paying attention. Once we began to measure where teams were spending their time, the details of which I will leave for a future post, we were able to get a much better understanding of why our original approach to planning wasn’t capturing everything that was being worked on. I think this is an incredibly important story to tell for Engineering organizations, because while no sustainable organization is spending all of their time adding new features, it’s often the case that stakeholders outside of Engineering are focused only on the new features and enhancements being built. This makes sense, since these stakeholders are primarily focused on growing the business. However, what is often missed is acknowledgement that Engineering plays a critical role in running the business, as well — there is time invested in keeping software running even to minimally meet customer expectations. Once we had a better understanding of where we were spending our time, it allowed us to focus on improving Engineering impact. I prefer “impact” instead of “productivity” because I think the words we choose here matter. “Productivity” implies a machine-like focus on inputs and outputs. It also tends to suggest that we are measuring how hard a person is working, or how many hours they spend behind the keyboard. Instead, “impact” communicates that we trust people to do the right thing and that we are focused on leveraging those people to drive the best possible outcome for the business. By focusing on “impact,” you clarify that you’re measuring the outcomes of the Engineering organization as a whole on the business, and not the output of individuals. This focus on impact allowed us to shift the conversation around things like DORA metrics from being the goal towards being a tool we could use to measure the impact of changes after we’ve identified a specific challenge or opportunity.

Starting Your Metrics Program

How you start your Engineering Metrics program depends a lot on the size and culture of your organization. If your organization is large (I’d say anything over 50+ engineers), it’s best to start measuring metrics on a single team with a single goal and to scale from there. For example, if you’re looking to improve delivery predictability, find a relatively well-performing team and work together to categorize where that team is spending their time. Surprised by how much effort is going into getting software out to Production? Now you can use DORA metrics like lead time or deployment frequency to test changes to team process or to measure improvements from automation. As these metrics improve, you’ll see the time invested in Production deployments go down and an ability to reinvest that time elsewhere increase. Now you can use that success story to scale your metrics program to other teams across the organization. Again, the goal here is not “get to 10 deployments a day because that’s what Elite organizations do.” Instead, use deployment frequency to measure if changes, like additional automation or improved PR processes, impact the metric. If your organization is small enough (say, about 10 or fewer), you can take the same measurement approach but you’ll likely be able to just roll it out to everyone. While starting a metrics program with smaller teams may seem like a premature optimization, using metrics to improve team processes and deliver more business value takes time, and there’s a reasonably large barrier to overcome in building trust throughout the organization that metrics are being used the right way. I’ve found this much easier to accomplish in smaller teams, and it helps to set the culture early on of using metrics and data to measure and improve effectiveness. As you grow, that culture of measurement and trust in how that data is used is much easier to scale. You start hiring people who are data-driven and focused on continuous improvement, and a flywheel effect takes place. When you’re first starting to collect data, from investment areas to things like DORA metrics, start collecting passively at first. Don’t roll into a team retrospective waving your Metrics Bible and telling the team their lead time is too long. Listen to the challenges your teams raise in one-on-ones and retrospectives, and see if you can identify the metrics you can watch to validate whether or not changes on those teams are having an impact. Celebrate the wins publicly, and avoid using metrics to point out failures or things that aren’t moving in the right direction.

I’ve also found it helpful to identify champions on teams who are data-driven and interested in the topic of using metrics for continuous improvement. Teach them how to review the same metrics dashboards you’re looking at. Tell them what you’re looking for when reviewing this data, and ask what stands out to them. Ask what’s hard about getting work done, and then look together through the data to identify what metrics you can watch to measure improvement based on different initiatives. Finally, encourage them to suggest these initiatives and to advocate for using those metrics to monitor change. When teams are bought into using data to improve the way they get work done and the impact they have on the business, your metrics efforts are far more likely to be successful.

When we decided to fully invest in our metrics program at Paytient, it meant we needed to commit to collecting quality data. For us, this meant adding a new required field to our issue tracking system. There were two aspects of this change I underappreciated initially — first, I was worried that adding a new required field would introduce too much friction in our process and discourage the creation of issues, thus reducing overall visibility. This turned out not to be the case, I think largely because the issue creation process was already fairly lightweight so one more field didn’t meaningfully change that and because we focused on investment areas that were mutually exclusive and collectively exhaustive (MECE). Even still, the second thing I learned from this is that the definitions of the investment areas you choose needs regular, consistent reiteration. You want the categories to be clear enough that people don’t need to spend too much time thinking about which category a piece of work falls into, but that requires talking about the categories, providing examples of prior work and how that was categorized, and reviewing the categorization of future work regularly. Finally, remember that when it comes to categorizing work into investment areas, good enough is good enough. You’re looking for trends and patterns, not the precise allocation of every activity by every individual. Encourage your team to use their best judgement, and provide the examples and review opportunities to create a shared understanding.

Don’t Use Engineering Metrics in Isolation

Engineering Metrics, from investment areas to metrics like DORA, never tell the whole story. You can have the shortest lead time, lowest change failure rate, and spend 80% of your time building against the roadmap, but none of that necessarily means you’re helping to grow the business. You need to work with Product to combine your organization’s metrics with theirs to truly understand the impact the Engineering organization is making on the business. Deployment frequency doesn’t really matter if you keep deploying things your customers don’t want. Use investment area data to improve the product roadmap planning process. Knowing where your team has historically spent their time helps you and your partners in Product to be better informed about how much time you’ll have to invest in the roadmap in the future. And you can tell a much better story about how the time your teams spent improving documentation and application logging led to shorter incident resolution times and ultimately more time being available to build new features!

Benchmarking Internally and Externally

I think the hardest part of implementing a metrics program is figuring out what to do after you’ve started measuring things. If your teams spend 60% of their time on product roadmap work, is that enough? Should you be aiming for 80%? What if a team’s PR cycle time is two days — how much time and energy should you spend trying to shorten that even further? I’ve found benchmarking to be a useful tool in figuring out where to go after your first data points are collected. First, start benchmarking internally and only within the team you’re measuring; trying to benchmark across teams can be difficult due to different team compositions and areas of focus. Where has the team historically invested their time? Does it shift in a predictable pattern, such as spending more time on customer support and incident response after a major feature release? Is time spent deploying to Production steadily increasing over time? The goal here is not to compare teams or to pit them against each other. We’re using metrics for learning and improvement within a team, remember? If each team can make even marginal improvements, those aggregate across the organization.

That said, it’s helpful at an organizational level to understand how all teams are performing relative to your peers (or competition), and external benchmarking can be very helpful here. The challenge is where to get this data from, and the most reliable source I’ve found is the benchmark data available in Engineering Performance Management tools like Jellyfish, LinearB, etc. These tools have benchmark data that goes beyond just DORA metrics and includes things like investment allocations, sprint predictability, issue lifecycle, and more. Typically, you can segment the benchmark data by things like industry and company size to ensure you’re benchmarking against companies similar to your own. Investment allocations is where this benchmarking data can be especially useful in conversations with Product and other business stakeholders because it can help qualify the story you’re telling around striking a balance between growing the business versus running it.

When Metrics Won’t Help

Collecting and using metrics in-and-of-itself won’t solve any of your problems. If you’re trying to use metrics to identify low performers, don’t. If you lack the feedback mechanisms to identify these folks on your teams outside the context of Engineering metrics, you likely lack the psychological safety required to make any metrics program successful in the first place. It requires a significant amount of trust from the people doing the work you’re trying to measure to launch and scale a metrics program and if they think this data is going to be used to micromanage them, you’re sure to fail. Similarly, do not tie Engineering metrics to performance reviews or financial incentives like compensation or bonuses. These are the kinds of initiatives that fuel the horror stories of failed metrics programs and engineers gaming the system come from. Metrics should be used to measure engineering effectiveness, to diagnose problems, and to measure the impact of changes to the ways teams work.

Iterate Regularly

Once you’ve established an Engineering Metrics Program, it becomes simpler to answer all kinds of questions. But start small. Don’t overload your issue tracker with required fields in the hopes that you’ll one day need or want to slice and dice the data along those dimensions. You’ll be drowning in data at first, and will need time to acclimate to your newfound insights. From there you can start asking new questions and incrementally adding fields, labels, issue types, etc. to gain new insights. Some of the questions I’ve been able to answer by adding new dimensions after the launch of a successful program are things like “how much time do we spend doing work for specific customers?”, “what was the ROI of that engineering initiative”, and “how much planned versus unplanned work are we doing?” Look for ways to improve the process as you learn more about what data you have, what data you need, and how you can collect it. And remember: never stop improving!

To a certain extent, managing interruptions has always been a core challenge of leadership, but I’ve seen this become exponentially more difficult to manage since 2020, when COVID-19 forced companies into remote work.

Already popular, tools like Slack took on new levels of business criticality as we leaned heavily into chat-first work. Early reviews of our new work cultures popularized the notion that remote-first companies were more productive and that office culture, especially the open-office layout, served to foster distraction more than it did to foster collaboration. Over time, I’ve come to disagree with the notion that remote-first equals async-first (which I believe is where those productivity gains truly come from), or that remote workers are inherently more productive. Without careful consideration for how you encourage remote collaboration — and without clear personal execution strategies — leaders at all levels within the organization risk becoming less impactful and more prone to burn out.

We’ve all been there: You’re just getting started on that major presentation to the executive leadership team when you hear a ding and a notification slides in from the top-right of your screen:

@your-name can you take a look at this document and provide your comments?

In the worst case, you stop what you are doing, assuming the request is urgent. Much has been written about urgency vs importance and how tools like the Eisenhower Matrix can help with determining how to treat those situations. But even in the best case — where you determine that this ask isn’t urgent — you’ve still lost time and focus. First, the alert drew your attention away from the task at hand. Then you needed to review the message and document, assess its urgency, and possibly delegate it. That means finding the right person, passing along context, and ensuring they’re set up for success.

By the time you get back to preparing for your major presentation, 30-60 minutes has passed. And if your schedule is anything like mine, that might’ve been your only block of time to focus during the workday. Worse still, the more teams you support, the more likely another interruption will arrive before you finish the first one. Each interruption delays your ability to move your prior task forward until you arrive at the end of the day only to realize you got 80% of ten different things completed and none of them are the one thing you needed to finish.

Let me be clear: I believe that remote and/or hybrid work environments remain the best way to build strong, talented, diverse teams and cultures. I also believe that tools like Slack have increased our overall productivity by helping to centralize traditionally disparate tools into one place and have increased our overall knowledge by creating spaces where context is shared and information silos are reduced.

But those benefits aren’t automatic — and they’re not free. I’ve also seen tools like Slack become a crutch for eschewing the responsibility of self-serving information. Instead of searching internal documentation, wikis, or intranets, chat tools unconsciously encourage making the act of finding information someone else’s task: Can the product do X? What’s the status of Project Y? This behavior replaces active information-seeking with passive interruption.

Unlike in a physical office — where interrupting someone meant walking over and catching their attention — chat tools eliminate that friction. This has created a set-it-and-forget it culture of information acquisition, where people toss questions into chat and move on, expecting someone else to provide the answers. That switch has made context switching even more costly for many leaders.

So how can you reduce context switching and increase productivity and impact? I’ve found a few strategies that have been helpful over the years. Each of these will work in isolation but becomes much more valuable when used in concert with the other strategies. These also require a certain level of commitment from you to adhere to these practices and to set the right boundaries and expectations with your peers and coworkers that you will be operating using a modified engagement model moving forward.

Schedule Time for Certain Tasks

This has been the most impactful change I’ve made in the last few years to the way I work. In his book “Indistractable”, Nir Eyal describes using his calendar to allocate time for specific tasks. I started by manually scheduling time for things like contract reviews, architectural reviews, and hiring.

Now I use Reclaim.ai to manage most of this for me. I can create Tasks, tell Reclaim how long I need to complete the task, when it’s due, how important it is, and even if the task can be broken into chunks and it will automatically schedule those tasks onto my calendar around existing meetings. I also set up Habits for things I do regularly like reviewing architectural docs, recruiting, metrics reviews, monthly budget reviews, catching up on email, and my own professional learning and development.

This time blocking sends a signal: bot to your future self and to others trying to schedule time with you. It makes your focus work visible and reinforces accountability. And that’s critical — because if you block the time and don’t honor it, this practice won’t help you.

Establish Deep Work and Response Time Expectations

When the leaders I coach tell me they are having trouble getting other work done due to constant interruptions and urgent requests for feedback, the first thing I tell them to do is to shut down Slack.

Actually, the first step is to let people know that you are shutting down Slack and to provide a way for them to reach you in a true emergency. That message might look something like this:

Hey all, I am shutting down Slack to work on {important task} for the next hour and a half. If you need to reach me urgently in that time, please call me at 123-456-7890. Otherwise, I’ve got time blocked off at {time} to review and respond to any Slack messages and mentions. Thanks!

I’m not saying it’ll never happen, but I’m yet to hear of someone who sent a message like this and then received call. That little bit of friction helps others consider whether their request is truly urgent or if it can wait until a better time.

Create Contiguous Blocks of Time

Lara Hogan’s post on defragging your calendar inspired me to begin optimizing my calendar as a tool to enable deep work, not prevent it. My old calendar was filled with short 30-minute gaps between meetings, looking something like the example calendar below:

Over the years I’ve come to learn that it takes me about 30-45 minutes to just get into a creative, deep-work headspace and all of those open 30 minute blocks between meetings were just serving to allow time for shallow work. Now, I try to schedule meetings back-to-back (especially similar ones like 1:1’s) to create larger uninterrupted blocks for deep work. And if someone schedules a meeting with me, I’m pretty open about my preference not to schedule short gaps in my day and will ask for meetings to be moved such that they back up against other already-scheduled time blocks. With this small change in place, my calendar typically looks something more like this. Notice the larger blocks of white space, which I can use for deep work:

Use Your Chat Tool’s Chat Management Features

Recognizing that realtime chat can often become a realtime distraction, many chat tools have introduced features to help users manage the deluge of mentions, DMs, and notifications. If you’re not ready to deal with a message in a particular moment, use features like “Remind me in 30 minutes” or “Remind me on Monday at 9am”. I use these regularly to triage messages.

Slack’s “Save For Later” can also help — provided you’re disciplined about reviewing saved items. Some people use an emoji (such as a 📌) to mark important messages for follow-up. You can even use Slack workflows to trigger automations when you add a reaction to a message.

One small but powerful habit: include need-by dates in requests. Consider difference between:

Hey, I need you to review this presentation.

vs

Hey, I need you to review this presentation by 2pm on Thursday.

The second message includes just four more words and took about two seconds longer to write, but provides infinitely more information about the urgency of the request and helps you to prioritize completing the task. If you received the second message on Monday at 8am, you’ll prioritize this request very differently than if you received it at 4pm on Wednesday. Without the need-by date, you don’t know how to prioritize the first message and are more likely to delay more important work to handle something that you thought was more urgent. You can then use your chat tool’s reminder or message management features to deal with the message at a more appropriate time. If someone sends you a message like the first one, ask for a need-by date. And be sure to lead by example and provide your teams with the information they need to prioritize their own work by being sure to include need-by dates in your own requests.

Bringing it all Together

While any one of these suggestions in helpful on its own, the real power comes from using them in combination.

• Automatically block time for deep work

• Group meetings to creating larger blocks of uninterrupted time

• Use message management tools to keep chat asynchronous and prioritize messages

• Shut down tools like Slack entirely when work demands full focus

None of these strategies are perfect. They take practice, discipline, and the ability to reset when you slip. But learning to manage context switching — instead of being managed by it — is what separates good leaders from great ones.

Doing Real Work

I read a book recently about why startups are so much better positioned than large, traditional organizations to change (or create) new markets and products. In that book, the author posited that in successful startups, frontline managers occasionally do “real work” like writing code or chipping in on software development, as opposed to in traditional companies where managers just manage people and tasks. I think this is a very misguided, and often times destructive, line of thinking. Engineering Managers should not be software engineers who also do people management. I’ve seen too many companies, and interviewed too many candidates, where an engineering manager’s role is 50% hands-on-keyboard writing code and 50% people management (read: performance reviews). This diminishes the value of both roles. Software engineers should not be valued for their ability to write code. Instead, they should be valued for their ability to solve problems. Yes, writing code is part of how problems are solved, but so is talking to customers, understanding the intended value or impact of a given feature, and being able to run and maintain that software in Production after it’s been deployed. Similarly, an Engineering leader should not be valued for their ability to manage people. Yes, managing people is part of leadership, but so is consistently delivering new capabilities in line with estimates, developing (or hiring) new skills on a team to unlock new ways for technology to solve business problems, and ensuring the individuals that report to you have an opportunity for growth and development. Neither software engineering nor engineering leadership is a part time job, so it doesn’t make sense to ask a person to do both. This isn’t to say that engineering leaders shouldn’t be technical. A good engineering leader understands and can empathize with the challenges their teams face, and empathy is built through experience. Review a pull request or technical design document. Try to deploy code to Production, or pair with someone on your team as they do it. But your real work as an engineering leader is not realized through the occasional code that you write. To the contrary, you should be impactful far more often than that! The thing I find most difficult for companies, and sometimes new leaders, to come to terms with is how the timescale of impact differs for engineers relative to engineering leaders. While an engineer’s output is seen in Production in hours or days (you are deploying to Production this often, right?), an engineering manager, director, or VP may not see the outcome of their work for weeks, months, or even years. The decisions tend to be less easily reversible, as well. It’s much easier to back out a code change than it is to back out a re-org. Coaching and mentorship takes time. Establishing new processes or fixing broken ones takes time. Changing code is hard; changing people is even harder. Most often in startups, we over-value immediacy and under-value the future. This isn’t to say no one is thinking ahead, but that startups tend to live on the knife’s edge of existence such that being able to see outcomes now makes it easier for startups to justify the value. I won’t go into organizational design and team structure in this article, but suffice it to say if you’re expecting your engineering leaders to also be software engineers, you are prioritizing short-term benefit over long-term viability.

An Engineering Leader’s Focus

Any engineering leader’s primary focus should be delivery. And I don’t mean “we shipped it”. That’s the easy part. Instead, great engineering leaders focus on the quality of delivery. Was it on time? Did it launch without much fanfare (boring launches are just as strategic a decision as boring technology). Are you able to measure the impact your team has on broader business goals? These are the questions to ask when measuring how well your teams are delivering and if you’re helping to drive continuous improvement in this area. How do you impact delivery excellence? I believe engineering leaders have the greatest influence over three things: team, people, and process. While org design is another post for another time, team design is a place engineering leaders at any level can apply their vantage point to great effect. If the company is making moves in AI and you have no skills in machine learning or artificial intelligence on your team, you need to decide whether you build it or hire it. Time and money are two limiting factors here, but you need at least one of them to be able to effectively fill the skills gap. Even if you have the expertise, understanding the product roadmap and ensuring the team is prepared to adopt and maintain any new technologies that might be required to meet Product’s needs is another way leaders can leverage their team’s collective expertise to help drive value. Teams, though, are nothing more than a construct for the people that comprise them. As an Engineering Leader, it is your responsibility to make sure that the individuals on your team are motivated, challenged, and rewarded for their work. It’s your responsibility to tell them when they’ve done well just as much as it’s your responsibility to coach them in the areas they need to grow. Establishing a career framework (and establishing it early) is a great tool to use in helping to develop the people in your team. Lastly, how the team executes and how the individuals on your team feel about how work gets done is achieved through process. For a variety of reasons, “process” is a dirty word in software engineering but I believe it is one of those most effective ways to drive impact as an engineering leader. Doing the work is hard (and it should be, if it’s worth doing). The work required to do the work shouldn’t also be hard. What is this meta-work I speak of? How decisions are made, how work is estimated, how tasks are broken up, how code moves through the deployment pipeline or release train, and how Engineering engages with other organizations across the company all describe how work gets done. This is where getting closer to the work (but being careful not to devolve into taking on hands-on-keyboard responsibilities) is the most beneficial. As an engineering leader, it is your responsibility to make sure your teams have the tools they need to do their best work. Could you build a house with only a hammer? Sure. But it wouldn’t be very fun to do. And it would take a lot longer than it would if you had the right tools, the right blueprints, and the right processes to build it better. If there is friction in your team’s daily work, it is your responsibility to remove it. In doing so, you empower your teams to drive the kind of impact that makes high-functioning software engineering organizations a rewarding place for the people on your teams to build and grow their careers.

All of this is real work. It’s just different work. For this reason, I think one of the most detrimental things an Engineering organization can do is build career paths that make management something you get promoted into, as opposed to a different role you transition into. How engineering leaders drive impact is different than that of individual contributors. It’s not less, or more, but different. If you’re an engineering leader trying to figure out how you can have the most impact on your team(s), think about working on the system and not in the system. In so doing, you will help your team achieve outcomes they couldn’t have reached with just a manager focused on performance reviews, or a manager who moonlights as a software engineer. It’s this unique combination of perspective and focus that makes engineering leaders at all levels a critical part of the organization.

This is a topic I’ve been wanting to write about, and have been encouraged to write about, for a long time. I’ve struggled to get started. I’ve struggled because, as with most topics on the Internet, there is so much content available that I didn’t want to just contribute to an already crowded conversation. There are plenty of resources available about improving the way you lead a team, about transitioning from an IC role to a manager role, and about broad industry trends and practices. However, I’ve found fewer resources on how to implement a re-org, considerations when rolling out a career framework, the challenges in introducing new team practices, or using data to help improve an organization’s effectiveness. When we make a change in our code, the software we’re writing happily complies (though maybe in ways we didn’t intend). Changing tools, processes, culture, or entire organizations doesn’t respond in the same way. Every team is unique, which makes pattern matching the way we do with software design more difficult. And so, “blog name” will focus primarily on aspects of leadership such as moving from one-team-to-multiple-teams, scaling organizational and operational excellence alongside scaling software, pushing (and sometimes pulling) your teams along an organizational maturity curve, and working to meet both business and technology objectives. Many of these topics apply to more than just Engineering orgs. While some topics may relate specifically to leading technology organizations, many are what I have found to be truisms in any industry and in any team. And that’s my goal: to contribute back to the collective consciousness on ways to lead effectively, to build sustainable organizations, and to help you make your organization a place people can build and grow their careers.

Ok, so interesting set of topics, but why me? Why not just Google (or ask ChatGPT) “how to do squads” and lead your organization the same way Spotify does? Leading organizations is about doing it for the org you are today, not the one you hope to be in 3-5 years or, worse yet, the one you read about online. And, more importantly, it’s about doing it in a way that best serves your unique culture and the people who comprise it. I’ve had the opportunity to lead at scale-up and growth organizations for much of my career. I’ve done the hyper-growth thing a few times. I understand how culture changes when you go from being the only engineer to a team of five, ten, twenty-five, and beyond. I’ve not only managed managers, but introduced the concept of engineering management to companies several times. And I’ve done it while still being involved in the technical details and occasionally being hands-on-keyboard myself. If you’re leading an organization in a growth phase and trying to figure out how to maintain your culture, establish best practices, or push your org to success, this newsletter is for you. If you’re at a larger, established organization and are wanting to create more leverage, grow the next round of leaders, or become a more data-driven organization, this newsletter is also for you. Fortunately, I don’t know everything. I’ve messed up a lot. And from my failings, I hope to also share learnings to help others avoid the same mistakes. I want to contribute to the collective conversation about engineering leadership, organizational design, decision making, team building, culture, and operational excellence. And it should be just that — a conversation. If you have questions, if a future newsletter speaks to you or a challenge you’re currently facing, please don’t hesitate to reach out. Our teams, our organizations, and our industry-at-large gets better when we work together to lift all ships. I look forward to being one more rising tide that lifts others, helps to cultivate stronger leaders, fosters healthier cultures, and drives meaningful progress in the way we build and scale engineering organizations.

Subscribe now