Tools of the Trade: What an Engineering Manager Uses

Short answer: An engineering manager needs four kinds of tool: a tracker (where work lives), 1:1 notes (where the team's signals live), metrics (where the team's flow shows up), and async comms (where decisions get recorded). Most EMs over-tool by adding people-analytics dashboards and engagement-tracking software. The one decision that compounds is the tracker, because it shapes every other view.

A manager's tool stack for each team will have four broad categories - 1. Where the work lives - the tracker 2. Where the signals from the team live 1:1 notes 3. Where the flow shows up engineering metrics 4. Where the decisions get recorded async comms. Everything else is embellishment.

.

The reason it matters: Information routing is primarily an EM’s job it’s a case of signal in, decisions out. Tools that work reduce the friction of capturing significant information and surfacing decisions. The tools that don't tend to work either add ceremony to your work or create some metrics that look like a signal but don’t have an action. Most engineering managers overuse tools to generate wasted flow, then don’t use them.

This post will teach you about the four categories you can earn your place, the tools you should steer clear of, the one decision to compound, and when the toolbox is overkill. Targeting engineering managers, both new and seasoned, refining their stack.

The four categories that matter

These combined cover about 90% of an EM’s tools. The other ten percent pertains to the organization (HR System, budget tracker, calendar manager).

The error lies in adding tools to a fifth category people analytics, engagement surveys, productivity scoring which create noise masquerading as signal resulting in decisions that harm the team. Further information is provided below

The tracker — the one decision that compounds

If you are to change one thing about your tool stack, get the tracker right. This is because all other views - metrics, sprint reviews, 1:1 talking points, status update to your manager - are derived from the tracker. An ineffective tracker delivers poor inputs to all subsequent activities.

Essential Characteristic.

• Single ordered backlog. Priority is the order, not a column. Removes the "two P1s — which is actually first?" argument. The discipline behind a clean queue is captured in this guide to backlog refinement cadence.
• Story-only velocity. Tasks and bugs are tracked but unpointed. Velocity stays a measure of pace, not productivity — and that distinction matters when the number gets used as a forecast of user value.
• Fast search. The tracker is read more often than written. Search has to be good, with stable URLs.
• Few required fields. Five is enough; more taxes filing without informing decisions.
• Notifications you can actually trust. Defaults to "you're notified when something becomes your problem", not "you're notified about everything".

The original Pivotal Tracker was built just like LiteTracker; it was discontinued in 2025. While Jira and Linear can be configured like-for-like, their defaults work against you. Use the tools whose defaults you have tuned and whose conventions you have not drifted from. Tracker defaults matter more than people expect — the Atlassian agile playbook covers the trade-offs in more depth. The wrong move will be to use one your team does not have alignment on.

1:1 notes

Each direct report requires a document that chronicles.

• Recurring themes. What this person keeps bringing up. After three months you'll see patterns the person hasn't articulated.
• Decisions and commitments. What you said you'd do; what they said they'd do. So neither party loses track.
• Career-shaped notes. What they want to grow toward; what skills they're building; when their last promo conversation was.
• The personal context that shapes their work. Within professional limits — a kid was born, a parent is ill, they're moving cities. The kind of context that explains a temporary drop in output, so you don't misread it.

Any tool that maintains per-person documents with timestamps can be used. Tools such as Notion, Confluence, Google Docs, and dedicated 1:1 apps, e.g. Lattice or 15Five. The discipline matters more than the tool: an EM updating a plain Google Doc weekly outperforms an EM with three apps who updates none.

The minimum cadence1: a brief update after each 1:1, even if just 2 lines. It takes months, not weeks, to discern patterns; it is in the aggregation that the discipline yields value.

Engineering flow metrics

Metrics an engineering manager should care about.

• Cycle time — median and 85th percentile per sprint or month, ideally excluding weekends so the number reflects working time.
• Throughput — stories shipped per week.
• Deployment frequency — how often code reaches production.
• Change failure rate — what fraction of deploys roll back or hot-fix.
• Velocity — story points accepted per sprint, rolling-3.

The tracker velocity and these are approximately the DORA metrics. Their usefulness lies in how they can be acted upon: low cycle time signals small stories and temperature-controlled WIP; high change failure rate signals a test/deploy pipeline in need of investment. Martin Fowler's writing on continuous integration explains why those last two metrics move together once a team invests in the pipeline. The reason these read differently from project-style status reporting is that reporting in agile is about trends, not dates.

What Should Not Be Done.

• Lines of code. Doesn't measure value; correlates negatively with quality.
• Commits per day. Engineers gaming the metric commit smaller, more often.
• Pull requests per week. Same gaming dynamic.
• Time spent in IDE. Surveillance, not measurement.
• AI-generated "productivity scores". A black box from a vendor isn't a metric; it's a sales pitch.

Teams reach their users up to 14× faster, whilst cycle times drop from days to hours as story sizes shrink. The flow metrics will indicate whether it is happening; the AI scores will tell you whether the vendor wants to renew.

Async comms and decision log

The fourth category records the decision made. The engineering manager needs to ensure that the team can find the decisions later, to avoid fighting every decision every three months.

The functioning model.

• Slack (or equivalent) for synchronous-ish chat. Day-to-day coordination, quick questions, social glue.
• A docs tool (Notion, Confluence, GitHub wiki) for durable decisions. Architecture decisions, team policies, post-mortem reports.
• A linked relationship between the two. When a Slack discussion produces a decision, somebody (usually the EM) summarises and writes it down. Otherwise the decision lives in a thread and gets lost.

Decision-log pattern is one of the highest-leverage patterns an engineering manager can introduce to one or more of their teams. Every decision should be documented, stating the context, options, decisions, and consequences. Instead of asking me “why did we do it this way?” every six months and thus wasting my time, future engineers will read the doc.

What to ignore

Useless tools which seem to be useful.

• People analytics dashboards. "How much is each engineer producing?" The metric drives bad behaviour, the answer is wrong (engineering output isn't measurable at the individual level), and the political cost of the team finding out you use it is high.
• Engagement surveys with vendor-defined questions. The questions are aimed at producing comparison data for the vendor, not actionable signal for you. Your own 1:1s produce better signal.
• Goal-tracking tools (OKR software). A spreadsheet works for OKRs. Dedicated tools add tracking overhead without changing the underlying conversations.
• AI meeting summarisers (for 1:1s). The summary loses nuance and the recording itself changes the conversation. If you can't write two lines after a 1:1, the issue is discipline, not tooling.
• Generic "manager productivity" tools. Most of these are dashboards aggregating other tools. The aggregation is rarely useful; the underlying tools are what you need.

If you can't place a tool you’re being sold into any of the four areas above, then it’s probably in this list.

When the toolbox is overkill

The genuine case.

• First-time EM with a team of three. The tracker is enough. 1:1 notes can be in your head for a while. Metrics aren't meaningful at that team size.
• EM in a hyper-growth phase. When the team is doubling every six months, the time you'd spend updating tooling is better spent in 1:1s. Use the simplest tools that work; upgrade later.
• Interim / acting EM. A short tenure doesn't justify the setup cost of new tools.
• EM with strong tooling already provided by org. If your company has a standard tracker, standard 1:1 doc template, standard metrics dashboard, use the standards. Don't introduce parallel tools out of preference.

Sort out the 4 categories, ignore the people-analytics noise. For everyone else.

When NOT to be the EM

Many individual contributors are forced into engineering management roles when it shouldn’t happen, and the engineering management toolbox can’t fix that. It's sometimes the right call to decline the EM role when your team has technical problems that you, as an IC, are better suited to solve than a manager. The tools are only a symptom, the underlying question is the role fit.

On the other hand, an EM who enjoys the people-routing aspect of the job needs less tooling than people think. The connections are more valuable than the dashboards, and keeping the team on track is mostly about attention, not instrumentation.

Frequently asked

What tools does an engineering manager actually use?

There are four specific types of trackers: one to track your work, another for 1:1 notes to identify team signals, engineering flow metrics, and async comms with a decision log. Predictive people analysis, productivity evaluation, and goal-tracking applications generate more distractions than solutions.

What's the best tracker for engineering managers?

Use the one your team will consistently use. The essential features are: single prioritized backlog, story-only velocity, quick search option, few required fields. You can configure Jira, Linear, GitHub Issues, and LiteTracker to implement these; the defaults differ.

Should I use a dedicated 1:1 tool?

Optional. Dedicated applications (for example, Lattice, 15Five) add additional structure, however, they are costly on discipline. Regular documents work just fine for most EMs. It’s more important to have a cadence than a tool: brief update after every 1:1, every time.

What metrics should an EM track?

The DORA four plus team-level cycle time and velocity (deployment frequency, lead time, change failure rate, time to recover). Do not use metrics such as lines of code, commits per day, and vendor-defined ‘productivity scores’. These things all drive bad behaviour and don’t even measure value.

Are people analytics tools useful?

Generally not. It’s not reliable to measure individual-level engineering productivity, the metrics drive gaming, and the political cost of your team learning you use them is high. Just use team-level flow metrics and your 1:1s.

Do I need an OKR tool?

Usually, a spreadsheet is enough. Using dedicated OKR tools may increase tracking effort without improving conversation on the goals. If your organization mandates one, use that mandated one and do not create a personal alternative.

How many tools should I have in my stack?

Four to six, covering the aforementioned categories. If you have more than that being used to switch over tools. Less is better because you would be losing an essential component. It is less important what tools are used than that they are used consistently.

Should engineering managers code?

Beyond the scope of this guide. The tools answer is: if you code, use the team’s standard IDE and code-review tools like a regular IC; if you don’t, then you can skip the IDE altogether. Either way, the four categories of management tool apply.

Still stuck

Tracker, 1:1 notes, flow metrics, async comms the four-category stack covers what an EM actually needs. Most disagreements about EM tooling comes down to which vendor in each category to pick; the bigger question is whether you’ve used the tools you already have consistently.

LiteTracker is a tracker designed for single ownership per card, story-only velocity, and a single ordered backlog so management view is honest by default. If that’s what you are looking for, then check it out. The free version allows unlimited users. If you are an interim EM or your team has less than four engineers, omit the new tool and operate using what you have.

No matter the case, by getting the tracker right, the other three categories become easy.