Engineering Management: What the Job Is and Where the Time Goes

Engineering management is the job of getting an engineering team to ship good work while the people on it keep growing. Most engineering managers (EMs) were great engineers first, and the part nobody warns them about is that the job stops being measured in code. It gets measured in what the team ships, and whether the team still wants to be there.

A: Engineering management is accountable ownership of a team's delivery and its people, across hiring, 1:1s, planning, quality, and process. An EM is judged on what the team ships and how the team feels about shipping it, not on the code the EM personally writes.

A: Mostly into coordination: 1:1s, planning, status chasing, and hiring loops. The expensive part is the weekly check on how delivery is really going, because it means digging across GitHub, Jira, and a spreadsheet. Abloomify automates that read from PR and ticket data.

A: PR cycle time and time to first review. They show where work waits, which is where most delivery time hides. Add the four DORA metrics once those two are trusted. Abloomify bands all four DORA metrics from Elite to Low straight from GitHub.

A: Yes. PR timing, review patterns, and deploy cadence are already in GitHub and Jira. Abloomify reads those signals only, with no screenshots, no keyloggers, and no code or message content, so the data describes the work and says nothing about anyone's screen.

Engineering management involves four jobs that compete for the same calendar: people (1:1s, coaching, hiring, performance reviews), delivery (planning, prioritization, shipping on the date you said), technical direction (architecture calls, the quality bar, how much tech debt the team carries), and the organization around the team (process, tooling, cross-team dependencies, and now which AI coding tools the team uses). A new EM usually arrives strong in the third job and weak in the first two, so the instinct is to keep doing technical work because it feels productive. The role only works when you hand most of that technical work to someone else and put your attention where the team is stuck. That is uncomfortable for a while, and I don't think it ever fully stops being uncomfortable.

Every one of the four jobs has a failure mode that looks fine from the outside. The people job fails when 1:1s turn into status updates. The delivery job fails when plans are accurate on Monday and wrong by Thursday. The technical job fails quietly, as tech debt that nobody scheduled. The org job fails when a team buys a tool and never checks whether it paid off.

Engineering management is the operating layer, the weekly work of running one team, while engineering leadership is the judgment layer above it: what to build, what to cut, and how engineering fits the company. In practice the two overlap and the titles blur. A manager of managers does both. A first-line EM at a 60-person company does both before lunch. The useful split is by question. Management asks "is this team healthy and shipping?" and leadership asks "are we shipping the right things, and is the whole org set up for it?" I wrote about the second half in what engineering leadership actually requires. This piece sits one level down, on the team you personally answer for, because that is where most EMs spend their first few years and where the habits get set.

One practical consequence is span. An EM with three reports can run the job on instinct. An EM with ten cannot, because the number of 1:1s alone eats a third of the week. If you are sizing teams, span of control is the number to settle before you hire the next manager.

An engineering manager's week is mostly coordination work: 1:1s, planning meetings, hiring loops, review cycles, and the steady drip of "where are we on X" questions from other teams. The coordination is real work, and some of it is the job. The problem is the slice of it that is just assembling information a system already holds. When I talk to engineering leaders, the same list comes up. Chasing people for updates. Copy-pasting numbers from Jira and GitHub into a deck on Friday. Turning meeting notes into action items. Digging across five tools to answer a basic question like who is overloaded right now. None of that is management. It is admin in disguise, and it eats the calendar that the people job and the thinking job both need.

That framing is also why I stopped thinking of Abloomify as software "for managers" and started thinking of it as the thing that deletes the low-value chores sitting on a leader's calendar. The 1:1 is worth protecting. The Friday copy-paste is not.

An engineering manager should start with the delivery signals that show where work waits: PR cycle time (open to merge), time to first review, review load per person, and the four DORA metrics, which are deployment frequency, lead time for changes, change failure rate and MTTR. If your team uses Cursor, Copilot or Claude Code, add AI tool adoption by team, because the seats are a line item now and someone will ask whether they paid off. The point of the list is to be short. Five or six numbers you check weekly beat thirty you glance at quarterly. Abloomify connects to GitHub and Jira (and Linear) and shows these together, with the DORA four banded Elite to Low, so you see the shape of delivery in one place. For definitions, see what DORA metrics are and the longer list in engineering KPIs.

A caution I'd put in bold if I were allowed to: these numbers are for the team, not for ranking people. The moment PR counts show up in a performance review, engineers split work into smaller PRs and the metric means nothing. Use them to find where the process is stuck and fix the process.

Finding the bottleneck means reading where work waits, because on most teams it waits for a review far more often than it waits for a developer to write code. Start with time to first review: if PRs sit for a day before anyone looks at them, no amount of faster coding will move your cycle time. Then check review load per person. One senior engineer reviewing most of the team's PRs is a bottleneck with a name, and it is also a retention risk, since that person is doing a second job nobody scheduled. Then look at PR size, because a large PR waits longer for a reviewer and breaks more often once merged. The fix for each is different (a review rotation, a size norm, a clearer ownership map), which is why you want the diagnosis before the process change. We walk through the review side in how to reduce code review cycle time.

Abloomify's PR flow view shows cycle time, time to first review, self-merge rate and PR size from GitHub, and Bloomy, the AI engineering analyst, can answer a question like "where are PRs stalling this month" from your live GitHub. You can also schedule it: a Monday summary of PRs merged, velocity and review health lands in your inbox, and you can reply to it like a conversation. I like that more than a dashboard. Dashboards wait for you to remember them.

AI coding tools add a fifth thing to manage: whether the tools your team pays for are changing how work gets done, and how much of the code is now written by an assistant instead of a person. A manager who bought Cursor or Copilot seats and never looked again has a license report and no answer when finance asks about return. The useful questions are specific. Which teams adopted the tools, and which bought seats and kept coding the old way? Do heavy users ship faster and get reviewed faster, or do they generate bigger PRs that clog review? Abloomify imports usage from Cursor, Claude Code and GitHub Copilot and correlates it with delivery output, and it separates human and AI-agent contributions across code and reviews. I switched our own team from Copilot to Cursor a while back and the difference was obvious to us. That is one team's anecdote though, and the point of measuring is that you shouldn't have to take anyone's word for it, mine included.

Yes, as long as the data comes from the work and not from watching people. PR timing, review patterns and deploy cadence already exist in GitHub and Jira, and reading them tells you about the process without telling you what anyone looked at on their screen. Abloomify is privacy-first and PII-free for these metrics: no screenshots, no keyloggers, no screen recording, and no code or message content. That matters for a practical reason. About 1 in 6 workers say they would quit over surveillance, and the engineers you are trying to keep are the ones with the most options. The Personnel Psychology meta-analysis found no evidence that monitoring improves performance, so the trade is a real cost for no measured gain. Share the numbers with the team, ask them what the numbers miss, and treat their answers as part of the data. A team that sees the metrics and helps interpret them will usually fix the bottleneck before you ask.

If you want the delivery picture for your own team, Abloomify's engineering analytics connects to GitHub and gives you PR flow and DORA in about ten days, and the engineering leaders page covers how it fits a VP or CTO view.

Engineering management is the work of running an engineering team: hiring and growing people, planning and shipping work, keeping the technical quality bar up, and fixing the process around the team. An engineering manager is accountable for the team's output and for the people producing it, usually without writing much code day to day.

Mostly meetings and messages: 1:1s, planning, unblocking, hiring loops, reviews, and cross-team coordination. The part that gets squeezed is the thinking time to look at how the team is actually doing. A connected view of PRs, reviews and delivery in GitHub and Jira gives that time back. Our one-on-one agenda guide covers the 1:1 side.

Start with PR cycle time, time to first review, and the four DORA metrics (deployment frequency, lead time, change failure rate, MTTR). Add review load per person and AI coding tool adoption if your team uses Cursor, Copilot or Claude Code. Abloomify pulls these from GitHub and Jira without reading code content.

A tech lead owns technical decisions on a project and usually still writes code. An engineering manager owns the people and the outcomes: growth, performance, staffing, delivery commitments. At small companies one person often does both, which is where the job gets hard, because the two roles pull your calendar in opposite directions.

No. Delivery signals like PR timing, review patterns and deploy cadence come from GitHub and Jira, with no screenshots or keystroke tracking. Abloomify is privacy-first and PII-free for those metrics. Roughly 1 in 6 workers say they would quit over surveillance, so the monitoring route costs you the people you manage.