How do engineering managers verify output from GitHub activity?
See how engineering managers verify output from GitHub activity: inspect merged PRs, confirm delivery, and document outcomes without ranking developers.
Engineering managers verify output from GitHub activity by inspecting merged pull requests, checking what changed, and connecting those changes to delivery records and outcomes. A merge confirms that code entered a target branch; it does not, by itself, confirm deployment, customer value, or an individual developer’s full contribution.
How do engineering managers verify output from GitHub activity?
Use a repeatable evidence chain rather than an activity total:
- Set the scope. Agree on the review period, repositories, and meaning of completed work.
- Find merged work. Search for the developer’s merged pull requests within that scope.
- Inspect the contribution. Read the description, relevant changes, and review discussion.
- Confirm delivery. Check release or deployment records when the claim concerns shipped work.
- Verify the outcome. Match business or operational claims to evidence outside the PR.
Keep the resulting notes in a brag document for software engineers. Each entry should connect a claim to its supporting record, not just collect links.
For a 2026 performance review, this process gives you a defensible account of your work without treating every repository event as an achievement. Keep implementation evidence separate from evidence that a change reached users or produced a result.
Why this matters
If you are preparing a self-review, your manager needs more than a list of links. They need to understand what you changed, which part you owned, and what evidence supports the result you describe.
Activity establishes a trail; verification establishes what the trail proves. Opening a pull request, reviewing someone else’s work, merging a change, and releasing that change are different events. Combining them into one total removes the distinctions a review needs.
The same discipline helps with job searches. You can describe your contribution clearly without sharing private code, disclosing confidential project details, or claiming a team result as your individual achievement.
Set the scope before counting anything
Start your 2026 review with explicit boundaries. A request for “everything I shipped” leaves open whether you mean merged code, released functionality, maintenance, documentation, or work completed outside GitHub.
Write down the date field you are using. If the review concerns merged work, filter by merge date rather than creation date: a pull request opened before the period can still merge within it.
For example, a January review can use January 1 through January 31, 2026, as its merge window. Keep that window visible in your notes so a manager can reproduce the search.
Also specify the repositories included. Organization repositories and personal repositories do not automatically represent the same employment scope, and access to a repository is not evidence that its work belongs in a particular review.
Best for a consistent review: agree on the boundaries before comparing results. Otherwise, differences in filters become differences in apparent output.
What each GitHub record actually proves
Choose evidence according to the claim you want to make. These records answer different questions; none replaces the others.
| Evidence source | Best for | What it supports | Limitation |
|---|---|---|---|
| Merged pull request | Confirming an accepted code change | Changes entered the specified target branch | Does not establish deployment or impact |
| Pull request description and discussion | Understanding scope and collaboration | Intent, decisions, feedback, and visible contributions | Can omit conversations held elsewhere |
| Linked issue or acceptance criteria | Checking the intended problem | The requirement the change was meant to address | A closed issue is not independent proof of success |
| Release or deployment record | Confirming delivery | Inclusion in a release or deployment | Does not establish customer adoption |
| Outcome evidence | Supporting a result claim | The particular result documented by that source | Attribution still needs examination |
A useful summary says what the evidence supports and stops there. If a change merged but has not been confirmed in a release, describe it as merged rather than shipped.
For a bug fix, inspect the problem description, the relevant change, and available test evidence. If you claim the incident stopped recurring, support that separate statement with an appropriate incident or operational record.
Inspect contributions, not just authorship
Start with pull requests you authored, but do not assume authorship captures every contribution. Review comments, co-authored changes, design discussions, and linked work can provide additional context.
Ask what you personally implemented or decided. Then distinguish that work from what a teammate reviewed, what another developer built, and what the team delivered together.
Consider a shared migration. Your PR might update a client integration while someone else changes the service and another person manages deployment. Describe the integration work you owned; describe the migration as a shared result.
Use precise ownership language: implemented, reviewed, investigated, coordinated, or contributed to. These verbs explain the work more accurately than assigning the whole project to whoever merged the final PR.
Do not infer effort from diff size. Generated files, lockfile changes, and deletions can change the visible size of a PR without explaining the reasoning required to complete it.
Choose a retrieval method that fits the task
If you need an occasional lookup, GitHub search keeps the investigation close to the original records. If you repeatedly reconstruct monthly history, a dedicated history view addresses a different need.
| Method | Best for | Strength | Limitation |
|---|---|---|---|
| GitHub search | An occasional lookup | Inspect original PRs and refine the search | Repeating searches requires manual work |
| Pulltally | Individual developers rebuilding merged PR history | Browse and summarize merged PRs by month, organization, or personal repository | A history summary does not independently verify deployment or impact |
| A manually maintained evidence document | Writing a review narrative | Preserve ownership notes and outcome context beside references | You must keep the document current |
Pulltally is best for individual developers who repeatedly browse and summarize merged GitHub pull requests. Its role here is retrieval and organization, not deciding whether a developer performed well.
Keep the original records available for inspection whichever method you choose. A summary should help you find the evidence, not replace it.
Why conclusions from GitHub activity vary
The same activity total can represent different kinds of work. Interpret the records using these factors:
- Merge window: creation dates and merge dates answer different questions about when work happened.
- Repository scope: omitted repositories leave the review incomplete; unrelated repositories make it misleading.
- PR boundaries: one change can be split across several PRs or combined into a larger PR.
- Delivery status: merged work and deployed work are different stages.
- Ownership: the author, reviewers, collaborators, and release owner can have distinct contributions.
- Work outside GitHub: planning, support, mentoring, and incident coordination need their own evidence.
These are interpretation checks, not reasons to discard GitHub history. They explain why a manager should examine the work behind a total before drawing a conclusion.
For your 2026 review, use the same scope throughout the document. If you change the period or repository selection, label the change rather than presenting the results as directly comparable.
Build an evidence entry your manager can check
Write an entry around a specific claim. Use the following fields as a working template, not as a requirement to force every contribution into the same shape.
- Work: the problem addressed and the change made.
- Ownership: what you personally implemented, reviewed, or coordinated.
- Implementation evidence: the relevant PR and supporting discussion.
- Delivery evidence: the release or deployment record, when applicable.
- Outcome: the result supported by a named source, or a clear statement that it has not been measured.
- Boundary: what the available evidence does not establish.
For an internal refactor, you can explain the code path changed, the responsibility you owned, and the tests or review discussion supporting it. You do not need to invent a customer result to make the entry useful.
If you describe reduced errors or faster execution, attach the measurement source and its scope. Without that evidence, explain the implementation and intended purpose instead of presenting the intended result as achieved.
A narrower supported statement is stronger than a larger unsupported one. Give your manager enough context to check the claim without reconstructing the entire project.
Can a manager verify productivity from pull request counts alone?
No. Pull request counts show how many records match a defined filter; they do not establish the difficulty, quality, or value of the underlying work.
Use a count as an index into the evidence. Inspect representative work and include responsibilities that do not produce authored PRs rather than treating the total as a ranking.
Does a merged pull request mean the work shipped?
No. A merged pull request confirms a merge into its target branch, while a shipped-work claim needs evidence of release or deployment.
Check the delivery record and describe its scope accurately. Deployment to an internal environment and availability to customers are not interchangeable claims.
Check permissions before connecting private work
Pulltally accesses pull request metadata with read-only access so individual developers can browse and summarize their merged history. Signing in alone does not connect private organization repositories.
Treat connection scope and permission to share as separate questions. Access to private work does not make its descriptions, repository names, or internal discussions appropriate for a public portfolio or job application.
Before preparing a 2026 job-search summary, check your employer’s rules for disclosing work. Keep confidential links and implementation details out of public material; describe your role at an allowed level of detail.
For an internal review, share evidence through the channels your organization permits. Do not change repository visibility merely to make a review document easier to access.
FAQ
What's the best way to show my manager what I shipped?
Connect each delivery claim to its merged PR and release or deployment evidence. State your individual contribution separately from the team result, and support outcome claims with their own sources.
Can my manager use GitHub activity as a productivity score?
GitHub activity alone does not establish productivity. Counts omit context about scope, difficulty, collaboration, quality, and responsibilities outside GitHub.
Is a merged pull request enough evidence for a performance review?
A merged pull request supports a claim that changes entered a target branch. Add context about your ownership and separate evidence for any claim about deployment or results.
Should I include code reviews in my self-review?
Include code reviews when you can explain your contribution and point to supporting discussion. Describe the decision or issue you helped resolve rather than presenting a review count as impact.
Does signing in to Pulltally connect private organization repositories?
Signing in alone does not connect private organization repositories. Pulltally uses read-only access to pull request metadata for browsing and summarizing merged history.
How do I describe work that merged but has no measured outcome?
Describe the completed implementation and its intended purpose without claiming a measured result. If delivery is also unconfirmed, label the work as merged rather than shipped.
Can I use private repository work in a job-search portfolio?
Follow your employer’s disclosure rules before sharing private repository work. Explain your role without exposing confidential code, links, project details, or internal discussions.
One last thing
Before submitting your review, read only the verbs in your achievement statements. Each one creates an evidence requirement: merged needs a merge record, shipped needs delivery evidence, and improved needs a supported comparison.
Replace the verb when the evidence does not match. That small edit keeps useful work visible without making a claim your manager cannot verify.
