The problem only showed up when I checked which authentication middleware the agent had imported.

Our codebase had two: a v1 middleware backed by MongoDB and a v2 middleware backed by MySQL, which we had spent the previous quarter migrating.

New endpoints were supposed to use v2. The agent had used v1 for all three. Tests passed because user records still existed in both databases (that was the point of the migration), and the v1 middleware happily authenticated them. The code worked. But every new endpoint we shipped was reinforcing the legacy auth path we had just spent a quarter trying to retire.

I caught it on the second read. Twenty minutes after the comments, the engineer fixed it and reopened the PR. The third reviewer probably wouldn't have caught it. The migration timeline lived in a Slack thread from six months earlier. The rule that "new endpoints use v2" lived in my head.

This kind of catch is the slow-burn version of why AI changed my job as a tech lead. Code generation got faster. My review queue got longer. The hardest reviews were the ones where everything looked right, and the only thing wrong was something that lived in the team's collective memory rather than in the diff.

This handbook is about what we did to fix that. It's the story of how we went from drowning in clean-looking PRs to running a custom AI PR reviewer that catches a meaningful share of these mistakes before any human is pulled in. The fix turned out to be less about buying a better tool and more about moving the team's memory into a place the AI could actually read.

The lessons should transfer whether your team uses Claude Code, Cursor, Cline, GitHub Copilot, or any combination. The structure matters more than the tool.

Table of Contents

• The Old Bottleneck, and the One AI Created

• What the New Review Work Actually Looks Like

• Why I Did Not Just Buy a Tool

• The Realisation: Move the Rules Into the Codebase

• Two Files That Changed Everything: AGENTS.md and CLAUDE.md

• Where Per-Service Memory Files Earn Their Keep

• What This Looks Like on Disk

• Generated Documentation as a Side Effect

• Building the PR Review Command

• Guardrails: Read-Only by Default

• The Compounding Loop That Made the Real Difference

• Starting From Zero on an Existing Project

• What Still Needs Human Review

• A Two-Week Setup Plan

• What Is Working, What I Am Still Improving

• Sources

The Old Bottleneck, and the One AI Created

To understand why this fix was needed, it helps to remember what reviewing code looked like a couple of years ago.

Back then, the slow part was upstream of the PR. A ticket would land, and before anyone could open a branch, there was a long preamble of context-gathering.

Junior engineers needed time to understand what the change was for. Senior engineers had to explain business rules and architectural decisions. Tickets sat in "ready" columns for days while someone with the right context made themselves available. Then the writing itself took time, because typing real code is slower than typing comments about it.

That bottleneck mostly dissolved when the team got serious about AI-assisted development. Engineers used the agent to read the codebase, ask clarifying questions, draft an implementation plan, and produce a working branch in hours instead of days. Tickets moved through the queue faster. Junior engineers shipped more without blocking on senior availability. From the outside, this looked like an unambiguous win.

But the bottleneck didn't disappear. It moved.

Within a few weeks of widespread AI adoption, my review queue had doubled. Then tripled. Engineers were opening PRs faster than I could read them.

The PRs themselves looked clean: well-formatted, with sensible variable names, passing tests, and AI-generated descriptions that read better than most human-written ones.

On the surface, this was great. In practice, it was creating a different kind of pain. I was the senior engineer who knew which patterns mattered and which paths through the codebase were the right ones, and I was the bottleneck. The team's velocity was now capped by my reading speed.

The CircleCI 2026 State of Software Delivery report confirmed I was not alone. Drawing on more than 28 million CI workflow runs across over 22,000 organisations, the report showed feature branch throughput had grown 59% year over year, the largest jump CircleCI had ever measured. Main branch throughput, where code actually gets promoted to production, fell by 7% for the median team in the same period. Build success rates dropped to 70.8%, the lowest in five years.

The pattern was consistent across the industry. AI accelerated writing. The rest of the system absorbed the cost.

So the question for me, as a tech lead, became concrete: how do I unblock myself without lowering the bar?

What the New Review Work Actually Looks Like

Before I explain the fix, it helps to know what kinds of issues were actually piling up. They weren't the dramatic kind. None of them would crash production. They were small, recurring, and looked plausible at a glance.

Take the simplest case I kept catching. An engineer would ask the agent to add a delete button on a new screen. The button needed to call our existing backend delete endpoint. Instead of reusing the hook the team already had for that endpoint, the agent would write the fetch call inline.

The code worked. The tests passed. But a week later, when someone changed the backend response shape, only one of the two call sites got updated.

That kind of duplication doesn't show up in a code review unless the reviewer happens to remember that a hook exists.

Another example I saw constantly: the agent comparing a status field against the literal string "completed" instead of using the Status.Completed enum that the rest of the services used. The code ran. The tests ran. The next refactor of the enum quietly skipped the file. After a few days, someone would spend half a day debugging a state machine that was working fine until the agent's literal silently fell out of sync.

These were two-minute fixes once spotted, but spotting them took me a reasonable time per PR. The friction wasn't the difficulty. It was the repetition.

The pattern repeated across larger problems, too.

I once asked an agent to build an event creation wizard. The wizard needed several dropdowns and one new component.

We have a design system folder where shared UI components live, and the rule on the team is simple: check there first, and if you build something new, register it there.

The agent had no way to know that. It only loaded the wizard's own files, so it never opened the design system folder. It generated brand new dropdowns inline, with APIs that were almost identical to the ones we already had. The new component went straight into the wizard rather than into the design system. CI passed. The wizard worked. We caught the duplication in human review, but it was the kind of catch that depended entirely on a reviewer who happened to know the design system existed.

The same pattern hit in one of the repos I was looking at for backend architecture. Backend follows a strict four-layer pattern: route, controller, app, repo. Controllers must never call repository functions directly. That rule keeps authorisation centralised, business logic testable, and database concerns isolated.

One PR I reviewed had the agent calling repo functions straight from a controller, skipping the app layer entirely. The code worked. The tests passed because the agent had also written tests against the new shape. But it broke a discipline the team had spent years building. If that PR had landed, the next AI-assisted PR could have used it as a template, and the layering would have eroded one diff at a time.

The common thread is that all of these mistakes had something written down somewhere, in code, in a Slack thread, in a senior engineer's head, that would have prevented them. The information existed. The agent just couldn't see it.

Why I Did Not Just Buy a Tool

The obvious next move was to install one of the AI PR reviewers that flooded the market in 2026.

I evaluated several. Anthropic launched Claude Code Review in March 2026, billed on token usage and averaging \(15 to \)25 per review. CodeRabbit Pro charges \(24 per developer per month on annual billing, or \)30 per developer per month on monthly billing, with seats counted against developers who actually open PRs. Greptile in March 2026 moved to a base-plus-usage model at $30 per seat per month, including 50 reviews, after which each additional review costs a dollar. GitHub announced that all Copilot plans will transition to usage-based billing on June 1, 2026, with code reviews consuming both AI Credits and GitHub Actions minutes from that date.

For a small team with low PR volume, none of these is a dealbreaker. For a larger team running heavy AI-assisted development, the costs compound fast. A 10-person team running five PRs each per day blows through Greptile's included reviews in a single week. CodeRabbit Pro at \(24 per seat scales linearly with developers. The premium Claude Code Review at \)15 to $25 per PR is the most expensive option per review by an order of magnitude.

I looked at the cost numbers, but cost wasn't actually the deciding factor. The deciding factor was that none of these tools would have caught the problems I just listed.

A generic reviewer wouldn't have caught the v1/v2 middleware. It had no way to know v2 was the canonical path. A generic reviewer wouldn't have caught the duplicate dropdowns. It had no way to know our design system existed. A generic reviewer wouldn't have caught the bypassed architecture. It had no way to know that controllers must not call repositories.

The information that lets a reviewer flag any of these is exactly the information that lives in the team's head, not in any tool's default prompt.

The better-rated tools support custom rules, and that's where I started to see the real shape of the problem. Once you are configuring custom rules, you've already accepted that the value is in the rules. The tool is just whatever runs them.

This raised a different question: if the rules are the product, why pay per seat or per review for someone else's wrapper around them?

This is what made me change direction.

The Realisation: Move the Rules Into the Codebase

Once I started thinking of the rules as the product, the path forward got clearer.

I asked myself a simple question: what was I actually doing in code review that the AI was not? The answer turned out to be the same thing, over and over. I was typing review comments that captured a piece of the team's memory.

"Use the Status enum, not a string literal." "There is already a hook for this in /hooks/useDeleteItem." "Controllers must not import from the repo layer; route this through the app layer." "Check the design system folder before creating new components."

Each of those comments was knowledge that lived in my head and arrived in the codebase one PR comment at a time. None of it was available to the agent the next time it generated a similar PR.

So the fix was not to buy a smarter reviewer. The fix was to write the rules down in a place every agent on the team would read before any review happened.

If I had typed "use the enum, not a literal" three times in three different PRs, that was a rule the agent should know about from now on. If I had pointed at the design system folder for the fourth time, that was a rule. If I had explained the four-layer architecture twice in PR comments, that was a rule.

I needed somewhere to put these rules. That turned out to be a less obvious decision than I expected.

Two Files That Changed Everything: AGENTS.md and CLAUDE.md

If you start looking into how to give an AI agent a persistent project context, you run into two competing conventions almost immediately.

The first is AGENTS.md, an open standard that has gathered real momentum. According to InfoQ, by mid-2025, the format had already been adopted by more than 20,000 GitHub repositories and was being positioned as a complement to traditional documentation: machine-readable context that lives alongside human-facing files like README.md.

The standard's own site reports it is now used by more than 60,000 open-source projects and has moved to stewardship under the Agentic AI Foundation, which sits inside the Linux Foundation. The format is supported by OpenAI Codex, GitHub Copilot, Google Gemini, Cursor, and Windsurf, among others.

The second is CLAUDE.md, which is Anthropic's convention for Claude Code. The Claude Code documentation describes two complementary memory systems: CLAUDE.md, where you write the persistent context yourself, and an auto-memory mechanism that lets Claude save its own notes from corrections and observed patterns. By default, Claude Code reads CLAUDE.md, not AGENTS.md.

This split mattered for us because half the team uses Claude Code and the other half uses Cursor. We had two practical options: maintain both files with the same content (and accept the duplication), or symlink one filename to the other so both ecosystems read the same source of truth. We went with the symlink. It's one less thing to drift.

The next question was what to actually put in the file. After a few iterations, here's the shape that worked. Think of it as a briefing document for a new engineer who has read no code and seen no Slack threads. The minimum content was:

• The tech stack (languages, frameworks, package manager)

• The project structure, especially important for our monorepo

• Where shared utilities, components, and helpers live, and the rule that new code should reuse them before creating new versions

• Architectural patterns the project follows, with file path examples

• Anti-patterns and what to do instead

• Test conventions and where good examples live

• Pointers to deeper documentation when more detail is needed

Two practical rules emerged from the first month of using these files.

Keep them lean: There is a counterintuitive failure mode with long instruction lists: the agent doesn't just skip the new ones at the bottom. The average compliance across all of them drops. A bloated memory file becomes a memory file that the agent skims. If a section runs more than a paragraph or two, move it to a separate document and link to it.

Phrase rules as imperatives, not aspirations: "Controllers must not call repositories. Route through the app layer." beats "Try to keep controllers thin." The first is testable. The second is decorative.

That was the entry point. But a single root-level file was not enough for a monorepo with multiple services and frontends, which led to the next decision.

Where Per-Service Memory Files Earn Their Keep

A single AGENTS.md at the root of a monorepo collapses under its own weight pretty quickly. Each service in our codebase has its own architecture, conventions, and business rules. Trying to fit all of that into one file produced a long document that the agent treated as background noise, and we were back to the bloat problem from the previous section.

The pattern that worked: every service or app gets its own AGENTS.md at its root, and the project-level AGENTS.md becomes an index that points to them.

A per-service AGENTS.md covers things like:

• The architecture for this service (the four-layer pattern, the directory layout)

• Naming conventions specific to this service

• Test patterns and where good examples live

• Business rules that this service is responsible for

• Inter-service contracts and what other services consume from this one

• Pointers to deeper docs in docs/

• A "Lessons learned" section, which I'll come back to in the section on the compounding loop

The same lean rule applies. Keep it short, point at examples, and phrase guidance as imperatives.

The reason this works mechanically is that the agent loads the right files for the work at hand. When an engineer asks the agent to change something in backend/, the agent reads the project-level AGENTS.md, sees that work in backend/ should be guided by backend/AGENTS.md, and loads that file. It doesn't load the frontend's AGENTS.md, because that work is somewhere else. The context window stays focused on what's relevant.

Without this split, you have two bad options. Either you put everything in the root file, where the agent ignores most of it, or you put nothing in the root file, where the agent has no team context at all. The per-service split gives you both depth and signal.

But these files only work if the deeper docs they point to actually exist, which is where the next piece of the system came in.

What This Looks Like on Disk

Before going further, it helps to see the whole structure laid out. Here's the shape we settled on for our monorepo. The exact folder names follow Claude Code's conventions. If you use Cursor, it would be .cursor/, and if you use Cline, it would be .clinerules – but the shape transfers directly.

project-root/
├── AGENTS.md                       # symlink to CLAUDE.md
├── CLAUDE.md                       # root memory file
├── README.md                       # human-facing project readme
│
├── .claude/                        # tool-specific config folder
│   ├── README.md                   # explains the .claude/ layout
│   ├── settings.json               # permissions and guardrails
│   ├── agents/                     # specialised subagents (optional)
│   ├── commands/                   # slash commands engineers run
│   │   ├── review-pr.md            # the PR review command
│   │   └── plan-feature.md         # implementation plan command
│   ├── hooks/                      # lifecycle hooks (optional)
│   ├── pr-rules/                   # rule files for PR review
│   │   ├── common.md               # rules that apply to every PR
│   │   ├── frontend.md             # rules for frontend changes
│   │   ├── backend.md              # rules for backend changes
│   │   ├── service-a.md            # rules for service-a
│   │   └── service-b.md            # rules for service-b
│   └── skills/                     # reusable workflows
│
├── frontend/
│   ├── AGENTS.md                   # frontend conventions
│   ├── docs/
│   │   ├── overview.md
│   │   ├── architecture.md         # routing, state, data layer
│   │   ├── design-system.md        # design system reference
│   │   └── testing.md              # test conventions
│   └── src/
│
├── backend/
│   ├── AGENTS.md                   # the four-layer pattern
│   ├── docs/
│   │   ├── overview.md
│   │   ├── architecture.md         # route -> controller -> app -> repo
│   │   ├── auth.md                 # v1 vs v2 middleware
│   │   ├── business-rules.md
│   │   └── integrations.md
│   └── src/
│
├── service-a/
│   ├── AGENTS.md
│   ├── docs/
│   │   ├── overview.md
│   │   ├── business-rules.md
│   │   └── integrations.md
│   └── src/
│
└── service-b/
    ├── AGENTS.md
    ├── docs/
    │   ├── overview.md
    │   ├── business-rules.md
    │   └── integrations.md
    └── src/

A few things worth pointing out:

The .claude/ folder uses standard subfolder names: commands, agents, hooks, skills. These follow Claude Code's plugin model, but most modern AI coding tools have similar slots. Following the conventions makes the structure recognisable to anyone on the team and lowers the cost of switching tools later.

The pr-rules/ folder isn't a standard convention. It's a folder we created to hold per-area review rules that the PR review command loads selectively. You don't have to call it pr-rules – the name matters less than having one place where review rules live.

Each service has its own AGENTS.md plus a docs/ folder. The root AGENTS.md is short and acts as an index. It tells the agent things like "if you touch files in backend/, also read backend/AGENTS.md first." The per-service file then points at the deeper docs as needed.

Generated Documentation as a Side Effect

Setting up per-service AGENTS.md files surfaced a problem I had been quietly avoiding. Most of our services didn't have decent documentation. Not API reference material, which lives in code, but the higher-level "what does this service do, what business rules does it enforce, what does it consume and produce" information that lives in nobody's head except the original author's.

The honest reason was that writing this kind of documentation by hand had never paid back the time it took. By the time the doc was finished, half of it was already stale.

So I tried something I wouldn't have considered earlier. I used the AI itself to generate a first draft for each service. I pointed the agent at each service's code and asked it to produce a docs/ folder with a specific structure: an overview, a list of business rules, an integrations document, a domain model, and any quirks worth knowing. The agent read the code, traced the call paths, and wrote a draft.

I then reviewed the output by hand, corrected the things it got wrong, and committed the result. The first drafts were 70-80% correct. The remaining 20-30% was where the agent had made plausible but wrong inferences, and those were exactly the cases where human review mattered.

The generated docs ended up serving two audiences. The agent uses them when reasoning about changes, which means it has real context for the service it's touching rather than guessing from local files. And new engineers use them on their first day, which has cut our onboarding time noticeably.

We used to write onboarding documents that drifted out of date within months. These docs stay closer to current because the agent reads them on every PR, and any drift gets surfaced when the agent gives wrong advice based on stale information.

The pattern that works is to keep the per-service AGENTS.md short and pointing at the docs, rather than duplicating their content. AGENTS.md is the always-loaded index. docs/ holds the details. The agent loads the relevant doc on demand when the task calls for it.

With the rules in place and the docs in place, I had everything I needed to build the actual reviewer.

Building the PR Review Command

This is the piece that most directly unblocked my queue.

This command didn't appear out of nowhere. It started as the checklist I was running through in my head every time I opened a PR. I was reviewing every change manually, leaving the same comments, flagging the same patterns. So I wrote that checklist down, expanded it with references to the per-service docs for the harder rules, and turned it into a command anyone on the team could run.

Then I handed it to the engineers and changed the rule: run this on your own branch before marking the PR ready for review. That single shift moved the work from after the PR was opened to before. Engineers now catch 90-95% of the blockers, improvements, and nice-to-haves on their own machine, fix them locally, and only then push the change.

The PR description includes the AI's summary, so when anyone opens the PR, they can see the reviewer's green signal at the top before even reading the diff.

GitHub stays clean. The conversation on the PR becomes about the things that actually need a human, not the recurring stuff the team already knows how to fix.

The command lives in .claude/commands/review-pr.md. Here's a generalised version. Your tool's command structure may differ, but the shape is what matters.

# Review PR

Review the current branch's PR. Be direct. Cite `file:line`. Surface real issues,
no padding.

## 1. Scope the diff

Run, in order:

    gh pr view --json number,title,body,headRefName 2>/dev/null || true
    git fetch origin main
    git log --no-merges origin/main..HEAD --oneline
    git diff origin/main...HEAD --stat
    git diff origin/main...HEAD

Read the PR body. Note the stated intent. Every change should trace to it. Flag
anything that does not.

Use `...` (three dots) for the diff. It compares against the merge base and
excludes commits brought in by merging main.

## 2. Load rules

Always read `.claude/pr-rules/common.md`.

Then read the per-area file for each workspace touched in the diff:

| Workspace path | Rules file                      |
| -------------- | ------------------------------- |
| `frontend/**`  | `.claude/pr-rules/frontend.md`  |
| `backend/**`   | `.claude/pr-rules/backend.md`   |
| `service-a/**` | `.claude/pr-rules/service-a.md` |
| `service-b/**` | `.claude/pr-rules/service-b.md` |

For non-trivial changes, follow doc pointers inside the rules files (for
example, `backend/AGENTS.md`, `backend/docs/architecture.md`).

Apply every entry under each file's "Lessons learned" section as a check.

## 3. Output

Use exactly this format.

    ## Summary
    <one paragraph: what the PR does, whether it matches the stated intent>

    ## Blocking
    - [file:line] issue, why it blocks

    ## Should fix
    - [file:line] issue

    ## Nice to have
    - issue

    ## Verified
    - what was checked and looks good

If nothing blocks, say so. Do not manufacture concerns.

If you find an issue worth remembering for future PRs, suggest the bullet to
add to the relevant rules file's "Lessons learned" section. Do not edit the
rules file yourself, leave that to the human.

A few of the design choices in this command turned out to matter more than I expected.

The structured output format (Summary, Blocking, Should fix, Nice to have, Verified) keeps the review easy to scan and easy to paste into a PR description. The "Verified" section is the most underrated of the five: it tells the human reviewer what the AI already checked, so they can spend their attention elsewhere. Without it, the human reviewer ends up doing the same checks twice.

The instruction to be direct and stop padding does real work. Without it, AI reviewers tend to manufacture concerns to look thorough, which trains engineers to skim past the bot. Telling it explicitly to say "nothing blocks" when nothing blocks made the signal-to-noise ratio of the output much better.

The "suggest a bullet for the rules file" instruction at the end is the heart of the whole system, and I'll explain why in the section on the compounding loop. The key constraint here is that the agent suggests the bullet but doesn't commit to it. A human evaluates whether it's general enough to be a rule, and only then adds it to the file. That manual step is what keeps the rules sharp instead of bloated.

With each PR, if humans fix something or the AI suggests something, you keep adding those to your MD files and keep improving your agents for the future. The result compounds quickly.

One more thing here: the diff-scoping commands are all read-only. The command shouldn't be able to push, edit PRs, or close anything. Which is the next piece of the system.

Guardrails: Read-Only by Default

Giving an AI agent broad permissions on your codebase is a security incident waiting to happen. Even if you trust the model to behave, an LLM occasionally does unexpected things, and a fast-moving agent on an unrestricted shell can cause damage in seconds.

The fix is a settings.json (in Claude Code – other tools have their own equivalents) at the root of .claude/ that explicitly declares what the agent can and can't do. The deny list matters more than the allow list, and a good one is organised around four categories of risk.

The first is secrets and configuration. Any read against anything that appears to be a credential is blocked. That covers .env files of every variant (.env, .env.local, .env.production, .env.test, and so on), .npmrc, .netrc, .pgpass, id_rsa, id_ed25519, *.pem, *.key, *.p12, **/credentials.json, **/secrets.json, **/.aws/**, **/.ssh/**, **/.gcloud/**, and **/.kube/**. Environment dumps are blocked too: env, printenv, set, export. The agent has no legitimate reason to read or echo any of these, ever.

The second is destructive Git operations. The agent can read Git history but can't rewrite or push it. Blocked: git push, git commit, git revert, git cherry-pick, git merge, git rebase, git reset --hard, git tag. Allowed: git fetch, git status, git log, git diff, git show, git branch, git rev-parse, git merge-base, git config --get.

The third is write operations on PRs and issues. The agent can read your GitHub state but can't act on it. Blocked: gh pr create, gh pr edit, gh pr merge, gh pr close, gh pr comment, gh pr review, gh issue create, gh issue edit, gh issue close, gh issue comment, gh release create, gh repo create, gh repo edit, gh repo delete. Allowed: gh pr view, gh pr list, gh pr diff, gh pr checks, gh issue view, gh issue list, gh release view.

The fourth is workflow and automation control. These are the surfaces where a compromised or misled agent could do the most damage. Blocked: gh workflow run, gh run rerun, gh run cancel, gh secret, gh variable, gh auth, gh ssh-key, gh gpg-key, and the unrestricted gh api.

For shell commands the agent legitimately needs to run, like build and test commands, allowlist specific patterns: pnpm test, pnpm lint, pnpm format:check, pnpm build, pnpm vitest. Anything outside the allowed list requires human confirmation. These are your own settings – I've just mentioned what I prefer.

The pattern is simple: read-only by default, write-allowed only for the specific commands you have explicitly approved. The agent can investigate, plan, and recommend. It can't ship.

With the structure in place and the guardrails set, the system started doing its job. What I didn't expect was how much better it would get over the months that followed.

The Compounding Loop That Made the Real Difference

When we started, the AI reviewer was useful but not transformative. It caught some obvious issues, missed plenty of subtle ones, and produced a fair amount of noise.

The first month, my review burden dropped by 35%. The time I was spending on PR checking was reduced to 1/3, almost. Decent, not life-changing.

What changed over time wasn't the tool. It was the rules.

Every time a PR creator and reviewer caught something the AI had missed, we were adding bullets to the relevant rules file. Every time the AI flagged something useful that turned out to be a recurring pattern, the agent's own suggestion at the end of the review went into the file.

After a few days, the rules files had grown into something that captured a meaningful fraction of the team's collective review knowledge, written down in a place every agent on the team would read.

The catch rate went up. The noise went down because the rules also said what was acceptable and what we already considered solved. New engineers stopped getting the same comments on their first three PRs because the AI caught the comments first. Engineers joining the team didn't have to absorb the conventions through six months of review feedback. They installed the project, opened it in their editor, and the agent already knew.

This is the part most teams miss when they evaluate AI PR review tools. They look at the catch rate today and decide whether the tool is worth the price. The catch rate today isn't the right number. The right number is what the catch rate looks like in six months, after the rules file has absorbed every recurring mistake your team has made.

A single rule written down today saves a small amount of review time. Over a hundred PRs, it saves more. After a year, the rules file is a written-down version of a tech lead's accumulated taste. We've switched between Claude Code, the GitHub Copilot CLI, and Cursor for various tasks during this period. The AI tool changes, but the rules file in the repo stays the same.

The discipline that makes this work is treating the rules file as living documentation. Every recurring review comment is a candidate for promotion into the file. If you catch yourself typing the same feedback in two different PRs, that's a rule that belongs in pr-rules/. The "suggest a bullet" instruction in the review command is what makes this practical: the AI does the typing, the human does the deciding.

This is also what made me realise the system was worth the time it took to set up. The PR review command, on its own, is useful but unremarkable. The compounding loop is what turns it into infrastructure.

Starting From Zero on an Existing Project

If you've read this far and feel like the gap between your project and what I just described is a sprint of work, that's the most common reaction. It's also not correct.

The blank AGENTS.md is intimidating, especially on an existing codebase. You know your team has a thousand conventions, and writing a thousand rules sounds like a project that takes weeks before it produces any value.

The honest answer is that you can't write all the rules up front, and you shouldn't try. The first version of any of these files should take an afternoon, not a sprint.

Here's how I would actually start.

Run /init (or your tool's equivalent). In Claude Code, /init scans the project, infers the obvious shape (language, framework, entry points, build commands), and writes an initial CLAUDE.md. The output is a starting point, not a finished file. Read it, delete most of what it generates, and keep the bones.

Then add three things, each one bullet long.

First, an architecture rule. Pick the single most important convention your team enforces. For us, that was the four-layer pattern. The bullet was: "Controllers must not call repository functions directly. They must go through the app layer."

Second, a discoverability rule. Pick the single most important shared resource the team has, the one new code is most likely to duplicate. For us, that was the design system. The bullet was: "Before creating a new UI component, check /src/design-system/ first."

Third, a "do not touch" rule. Pick the single most dangerous file or area in the codebase. Auth, billing, or migrations whichever has the most production risk. The bullet was: "Do not modify files in /auth/ without human approval."

That's enough to start. Three rules, ten minutes of writing, and most of your team's recurring AI mistakes start to drop.

If even three rules feels like too much, start with one. Pick a single line that matters in your codebase and write it down.

"No any types in TypeScript." "Always use the enum, never compare against the string literal." "Run the linter before opening a PR." It doesn't have to be sophisticated. It doesn't have to cover edge cases. It just has to capture one piece of judgement that lives in your head today and would otherwise stay there.

Tomorrow, add another. The first week, you might catch 5% of the recurring mistakes. By 20 or 30 PRs in, you might catch 20-30%. The rules file doesn't need to be impressive on day one. It needs to exist and keep growing.

This is the compounding effect I'll come back to soon, and it's the reason this approach works on real projects rather than just in theory.

From there, the file grows the same way it would grow for any team. Every review catch becomes a candidate rule. After a few weeks, you have ten or fifteen rules. After a few months, you have a real review system.

The mistake is trying to write the perfect file on day one. The right file is the one you start with and keep editing.

What Still Needs Human Review

This system doesn't replace human review, and it shouldn't be allowed to.

The AI reviewer catches what the rules describe, plus a fair number of obvious things it would have spotted anyway. It doesn't catch problems that depend on context the rules don't capture. It doesn't catch product judgement. It doesn't catch the question of whether the change should have been built at all.

It also has an important blind spot when reviewing AI-authored code. The reviewer shares the same training data and reasoning patterns as the agent that wrote the code. If the original agent missed the v1/v2 distinction because it had no way to see the migration timeline, an AI reviewer reading the same diff has the same problem. Two AIs in a review loop are not two independent reviewers. They share blind spots.

That is why the AI reviewer in this setup never approves a PR. It produces a structured review that goes into the PR description. A human still reads the change and approves it. The AI is the first pass, not the gate.

Accountability also has to live with a human. When something the AI approved breaks production, someone has to own the post-mortem and decide what changes are needed for next time. The AI can't be that person. What it can do, well, is reduce the stack of small mistakes a human reviewer has to find before they get to the harder questions.

A Two-Week Setup Plan

If you want to set this up for your own team, here's a concrete plan that fits in a couple of weeks. None of this needs to happen in a single push.

Day 1: Bootstrap the memory file.

Run /init (or your tool's equivalent) at the root of the project. Read the generated CLAUDE.md (or AGENTS.md). Delete most of it. Keep the tech stack and project structure sections.

Add the three rules from the previous section: one architecture rule, one discoverability rule, and one "do not touch" rule. Decide whether you want both files or a symlink.

Day 2: Add per-service files for your highest-risk areas

Pick the two or three areas of the codebase that change most often or carry the most risk. Add an AGENTS.md to each, following the same lean pattern. Include the architectural pattern for that area, the naming conventions, where to find good test examples, and pointers to any existing docs. Skip anything that doesn't need to be there yet.

Day 3: Set up the directory structure and guardrails

Create a .claude/ folder (or your tool's equivalent) at the root, with commands/ and pr-rules/ subfolders. Add a settings.json with the deny list categories from the guardrails section. Test that the agent can't read a .env file, run git push, or create a PR. If any of those work, fix the settings before doing anything else.

Day 4: Write the PR review command

Adapt the command in this article to your structure. Include the diff scoping, the rule loading, the output format, and the "suggest a new rule" instruction at the end. Run it on a branch you've already merged, and tune the output until it's useful.

Day 5: Run it on real PRs

Have one or two engineers run the command on their next PRs before opening them. Read the output. Note what it caught, what it missed, and what was noise. Add the missing catches to the rules files. The first week is mostly tuning.

Week 2: Roll out and document

Once the command produces useful output reliably, ask the whole team to run it before opening PRs and paste the output into the PR description. Add a short section to your contributing guide explaining the workflow. Set a recurring item in your team's rituals to review the rules files monthly and trim anything that has gone stale.

That gets you to a working system. From there, the maintenance is incremental. Every recurring review comment becomes a candidate rule. Every architectural decision becomes a candidate update to the relevant AGENTS.md. The system improves as a side effect of the work the team is already doing.

What Is Working, What I Am Still Improving

Here's my honest assessment after a few months of running this:

What's Working

My review burden is meaningfully smaller. Engineers fix most of the easy mistakes before I see the PR. The "Verified" section of the AI's output tells me what to skip past. New engineers ramp faster because the conventions live in a place their tooling reads. The rules files have grown into something I would actually use to onboard someone new.

What Isn't Finished

The AI still misses problems that depend on context, and the rules don't capture them. The rules files grow, but they also need pruning, and we haven't been disciplined about that.

We're still figuring out how to handle rules that apply only conditionally. Docs are helping in that case, but we need to keep those up to date. And no system survives a determined engineer who skips the workflow or docs when they're in a rush.

There's no shortcut here. The work is real, ongoing, and mostly about discipline. The discipline is treating your codebase as something the AI needs to learn, and treating every recurring review comment as something that should be written down once instead of typed thirty times. If you're willing to do that, the tools take care of the rest.

If you take three things from this article, take these.

1. First, don't pay for a generic reviewer to do a job your codebase needs to inform. Generic reviewers catch generic problems. Most of your real review work is specific to your team.

2. Second, put the rules in a file the AI reads, not in your head. AGENTS.md, CLAUDE.md, per-service files, per-area rules files. Pick a structure and stick to it.

3. Third, treat every human review catch as a chance to update the rules. The compounding effect over months is the entire point. A review system that improves itself is worth more than any single tool.

That's the system. It took a couple of weeks to build the foundation and a few months for the rules to mature. It costs very little to run, and it has done more for our PR throughput than any tool I evaluated.

Sources

• CircleCI's 2026 State of Software Delivery report, analysing more than 28 million CI workflows from over 22,000 organisations: https://circleci.com/resources/2026-state-of-software-delivery/

• CircleCI's blog post detailing the year-over-year throughput numbers, including the 59% feature branch growth and the main branch decline: https://circleci.com/blog/five-takeaways-2026-software-delivery-report/

• GitHub announcement of Copilot's transition to usage-based billing on June 1, 2026: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/

• GitHub changelog confirming Copilot code review will start consuming GitHub Actions minutes on June 1, 2026: https://github.blog/changelog/2026-04-27-github-copilot-code-review-will-start-consuming-github-actions-minutes-on-june-1-2026/

• AGENTS.md, the open standard's official site, including its stewardship under the Agentic AI Foundation and the Linux Foundation: https://agents.md/

• Anthropic's Claude Code documentation on the memory system, including CLAUDE.md, auto memory, and the /init command: https://code.claude.com/docs/en/memory

• Anthropic's Claude Code GitHub Actions documentation, including notes on token-based billing and recommended cost controls: https://code.claude.com/docs/en/github-actions

• CodeRabbit's pricing documentation, confirming the per-developer-per-month seat model: https://docs.coderabbit.ai/management/plans

• Greptile's March 2026 pricing announcement, introducing the base-plus-usage model at $30 per seat per month with 50 included reviews: https://www.greptile.com/blog/greptile-v4

• HumanLayer's write-up on writing a good CLAUDE.md, including data on instruction-following degradation: https://www.humanlayer.dev/blog/writing-a-good-claude-md

Until recently, I'd spent the last 4 years of my career at FinTech start-ups. I'd always worked for smaller companies, and being at a start-up was the next logical step in looking for roles where I could make the biggest difference.

But a common problem with early-stage start-ups is that it's kind of a free-for-all in terms of how they're managed.

These companies tend to be run by people who don't have a ton of experience running companies. And management tends to consist of founders and those who got in early, not necessarily those who excel in leadership roles. (No shade – good person + talented doesn't necessarily mean they're a good boss or leader).

During my time at one such start-up, I was promoted from senior developer to lead developer.

The catalyst for this change was that the development team lacked leadership. The CTO had too many responsibilities, and the job of keeping the dev team engaged and productive was falling through the cracks.

On top of this, we didn't have a project manger, and our product managers were too inexperienced to introduce any kind of structure.

This is the story of the wins and losses, and how to add process to a company that has none.

Events leading to the change

First, a little bit of background. My previous job had been as a developer at a digital agency. This agency was a hard-core scrum shop that had trained all of their employees fairly thoroughly in scrum, and agile in general.

So I came from an environment with a lot of process. That's partially why I left to pursue a start-up.

About a year in, I started to notice some issues. Firstly, the developer turn-over was growing. Developers weren't feeling engaged. They were handed half-baked projects with no context on how it would aid the growth of the company, no input in the design or planning, and with nowhere near enough detail.

Then came a project that crystallized our problem. The product that I worked on had the concept of bills (payables) and invoices (receivables). We were working on a new feature that would allow users to upload an image of an invoice and have it input manually by a service.

The problem was that the product manager kept saying "bills" instead of "invoices". There was no user story, no ticket, this was all in the mind of the product manager. Requirements were communicated verbally or in slack messages. The developer working on the project had only ever been told "bills".

It wasn't until the CTO overheard a conversation a few days before release that we realized that we'd targeted the wrong aspect of the system.

Luckily, bills and invoices were, for the most part, symmetrical in our system, so it wasn't much work to make the change. It just became very clear that we had a problem.

Given my background and the fact that I was one of the most senior and tenured developers at the company, it made sense for me to take the lead.

Since I was leading the initiative, I chose to implement a scrum-type process. In the remainder of this article, I'll outline what we did, how we did it, and why it was done, as well as my learnings.

Getting Buy-in

I'm gonna preface this by saying that I don't like handing commandments down from on high. I feel like a leader-team relationship is a collaborative one. I may occasionally play leader because it's my nature, but it's important that ideas are discussed and that people feel their opinions are heard and valued.

The first step was to gather the developers to have a discussion. In this initial discussion, I outlined what I felt our issues were. This included lack of clarity on requirements, sliding deadlines, and our complete lack of a testing strategy. The discussion validated my thoughts, because the team felt the same way.

The rest of the meeting consisted of me outlining scrum, what elements I felt could benefit us, and what that would look like. I also discussed some things that I learned about test plans and systematic QA that I learned in my agency days. We then went around the table, giving thoughts, asking questions, and tweaking.

I conceded that manual testing wasn't fun or ideal for the dev team, but until we could justify a full-time QA engineer, we had to do the best with what we had.

Learnings:

• If you have a good idea, all you need is a chance to prove its worth.
• Enlist your team to help build this together, make everyone part of the solution and they'll own it with you.

Our Version of Scrum

After describing what a "full" scrum process would look like, I laid out to the team what the purpose of each aspect and ritual was. I wanted to highlight where we could get the most gains. No one wanted 10 hours of meetings per sprint.

Speaking of sprints, we decided to start with a 2 week time-box with an eye on moving it to 3 weeks if we wanted less overhead and could afford less frequent releases.

The process I put in place was as follows.

We'd have a sprint started with a 2-hour grooming/planning meeting on a Monday morning. In this planning meeting we (the dev team and the product manager) did a pass over the backlog. This pass consisted of clarifying the story to clear up misunderstandings; estimating using story points; and prioritizing based on company road-map. The team then picked out the amount of work we felt we could do, based on priority, and brought it into the current sprint.

This work was a collection of user stories. The product manager would leave, and the dev team would break these stories down into tasks, get a general sense of who would work on what, and then we got to work. This gave the product manager transparency on what we could deliver, which was sorely lacking. It also gave the team their full workload for 2 weeks, which allowed us to plan and pace accordingly.

The next week and a half were dev days. This included peer code reviews on feature branches before they were merged. Dev hands-off was the Wednesday of the 2nd week at noon. We would then prepare the QA build, QA spreadsheet (more on this in a bit), and start manual testing.

The idea was to finish the initial QA pass by the end of the Wednesday, and spend Thursday and Friday in a bug fix/test loop until we were satisfied with the build.

At this point, the build would be handed off to the CTO for a final code review, and it would be deployed the following Tuesday. Issues found in the code review would be fixed and tested on the Monday if needed.

Friday afternoon we would have a blameless retrospective/postmortem. Here we laid things bare. It's important to acknowledge what went poorly, and to address the cause(s) so that we could avoid it in the future.

All of the developers (including myself) learned a lot through this process. I feel like we're all better off after having gone through it. I actually overheard the CEO suggest doing blameless postmortems a few weeks after we started doing them on the dev team. It was nice to see that our ideas were catching on.

This was one of the big wins. We learned why a feature was needed, what the intention behind it was, and all of the details and expectations.

Learnings:

• Split and join meetings based on your team's needs. Don't do things "just because"
• Share your progress outside your department. Sometimes your ideas can provide benefits outside of your team.

A Testing Framework That You Can Believe In

This company had never had a formal testing process. This meant no test plan, no peer testing, just a developer verifying that it worked, and it going to production.

In my experience, developers are as good at testing as they are at estimating, so we needed to change that. We had a good suite of automated tests (unit and integration), but no end-to-end tests. I also prefer to have some exploratory testing as well. In the past, I've seen it uncover weird behaviors that automated testing can miss.

We set up a google doc with all of the tickets (including links to the user stories) in the first column, and all of the developer names (and the PM) in the first row. The idea was that every ticket had to have 2 X's, both from people who didn't work on the feature. This divide and conquer strategy allowed us to test very thoroughly in a fairly short amount of time.

Learnings:

• Lean hard on automated testing. It's reliable and finds many classes of bugs with no manual time.
• Test with a plan. You're going to waste a lot of time just wandering. A systematic approach can make manual testing more efficient.

Success

What was the result? I don't have exact numbers, but the defect rate plummeted. There were no longer rushed hot fixes to production. The work promised was delivered. Features were being released on time.

We were moving faster than ever, and the developers were happier. We were working as a team instead of in silos, we all knew each others' features intimately because we all went through the user stories and estimated together. There was no more of this "oh, I can't touch feature X, I didn't work on it" siloing stuff.

One dev who was planning on leaving stopped looking. It was great.

Learnings:

• Keep adjusting your process based on results. It's an ongoing process.
• Sometimes people don't want to leave a company, they want to leave a situation.

An Abrupt End

But nothing gold can stay :) Ok, that's a bit dramatic. While the dev team was gelling, increasing our velocity, and building more camaraderie, management was going in a different direction.

The CEO had done a ton of reading and decided that OKRs were what was gonna get the company to the next level. Unfortunately, it was decided that OKRs would go down to the individual level, meaning that the team would no longer be pooling work, breaking it down and tackling it together. Instead, each developer would work out (or in practice, given) a set of KRs, and they alone would be responsible for delivering on them.

We were back to silos. The development team pushed back, we tried to compromise, to stop OKRs at the team level, but it was no use. The dream was dead. Yes, again with the drama, but it was a little sad.

This change coincided with a slight change in power structure, my title as lead developer became little more than a platitude, "leadership" said some very unkind things to the development team (somewhere along the lines of "get on board or get out"), which led to half the dev team, including myself, leaving within a month.

Learnings:

• Good ideas don't always win out. Even in a situation like this, you can learn a lot.
• Recognize when you can no longer make a difference.

Mistakes Were Made

Given the way that last paragraph ended, you may thing that I was about to enumerate the mistakes that the company made. But I'm not going to do that.

It's been about a year since I left, and in that time I've learned a thing or two. There were some serious gaps in the process that we'd created. These were things that I just didn't really understand or know about at the time. It was due to my shortcomings, but we all get better every day.

In hindsight, here are some major things I'd missed:

We weren't measuring.

How do you know you've done it right if you didn't take measurements before and after? We had no telemetry, very little alerting, and frankly, if a feature had negative impact, we didn't know about it.

Too much manual testing, not embracing automation.

What we were really missing was a nice suite of automated E2E tests. We started working on these near the end, but we didn't prioritize them enough. Many of the errors we found during manual testing could have been caught during some acceptance tests using cucumber, or some E2E selenium tests.

Big bang releases.

I know a common part of scrum for many companies is the idea that all of the sprint work is demoed and released together.

The problem with this is two-fold. Firstly, at a start-up you need to move quicker. You need to beat others to the punch and get value out to customers and feedback from customers as quickly as possible. And the tighter that feedback look is, the better.

Therefore, multiple releases per sprint would have been better. It's more difficult to coordinate testing and QA, but it's still better to release quickly and often.

Secondly, the larger the release, the more risk is involved. Releasing smaller chunks means that fewer changes are released at one time. If there's any issue, it's easier to identify and fix, and a rollback won't affect other, correctly functioning features.

So I've learned that releasing in verticals that are as small as possible is the safest, least coupled way of releasing software.

Conclusion

For all of the missteps and the unfortunate ending, I feel like the experience was a success. I learned what it meant to guide a team of developers through a process, to take feedback and apply it, and to try and discard ideas that, even though they are "supposed to be there", just didn't fit our team.

It's important to cater your process to your team and organization. You have to add enough process to guide, but not so much to hinder. It taught me how to implement process, to push ideas forward, to help others be heard, and how to lead from within a team.

Although it ended poorly, it was a big step forward in my career, and really solidified my ability and desire to lead.

You can find more of my articles on my medium blog.

I often hear people talking about impostor syndrome and time management issues. Sometimes I hear about these issues from a friend, a direct report, and occasionally from myself. We are always challenged by them and they can affect our mood, our ability to be productive, and our judgement.

We have days where everything works great and also we have bad days, where everything seems to go wrong. This emotional roller coaster can make us doubt our accomplishments and can create a persistent fear of being exposed as a fraud.

There a few things that you can do to remember that you are great:

• Keep a daily journal with notes of achievements: this daily exercise will train your brain to feel more confident.
• Focus on your strengths, especially when you are in a new role at work, use your natural strengths to add value to your position.
• Find quick wins, they will help you build a reputation of someone adept in a particular skill.

Issues with time management also impact our feeling of getting the job done. Sometimes the problem starts early on when we are assigned a task that may not make much sense.

Let's step back for a moment and think about the levels of uncertainty of a task:

1. Well understood
2. Have a few questions
3. Understood, but unfamiliar with the approach
4. Know the area, but not the direction
5. Generally unclear

How does uncertainty affect time management?

If something is well understood, it is very unlikely you will get lost in the woods and things will take as long as expected.

Starting with the level of "have a few questions", you need to be careful because the uncertainty will affect your time management and your sense of achievement.

The good news is, you can always use this problem as an opportunity to improve.

• Have a few questions: Find the best person to answer your question. If the description is unclear, go to the person who created that task. If the question is technical, talk to a developer on the team that can help you.
• Understood, but unfamiliar with the approach: If you understand the big picture but you are not confident with the approach, talk to another developer and ask for help. This is a good opportunity for pair programming.
• Know the area, but not the direction: This is a good opportunity to talk to another developer and hear their initial thoughts. They may have an opinion on how to get the task started or be able to suggest a good resource to review.
• Generally unclear: If the problem in the task is unclear, ask for clarification. If the technical approach is unclear, talk to other developers, think about having a pair programming session, and speak with other members of your team to understand how they approach their work.

Overall, facing imposter syndrome is something that we all face at some point in our careers. It is an issue that I have certainly struggled with, but find that facing these struggles provides an excellent opportunity for me to reflect on my skills and discover new areas of potential learning.

With these suggestions in mind, I hope that you are able to improve your sense of confidence and self-efficacy in your professional life.

Also posted on my blog. If you like this content, follow me on Twitter and GitHub. Photo credit: roller coaster (Pixalbay)

Two years ago, I switched from medicine and redesigned Instagram.

Three months after, I packed what I could fit into my carry-on and two moving boxes, and flew to Saigon to become Christina’s second product designer. Fast forward to today and I am now their Head of Product.

I can still remember my first task on the job: creating color swatches for our tour guide’s awesome new helmets. It might sound like a simple feat, but after trying out hundreds of color combinations and learning a thing or two about color theory, I was pretty proud of the results.

As Christina’s grew from 100 to well over 450+ team members spanning all across Vietnam, so did my responsibilities. From tour guide helmets to redesigning the company’s flagship communication app to then launching it for Airbnb hosts all over the world to use, its been a crazy (but fun) ride.

As I look forward to my next journey back to the States, I wanted to reflect on my experiences by sharing what I’ve learned along the way as someone who started with zero knowledge about product design and technology.

Let’s be clear — I still feel like I know nothing. I just know a little bit less of nothing than the day before.

Trust your gut when it comes to recruitment.

If you, your team, and your culture are playing to the same tune — you will know whether the candidate is a good fit (or not). As a rule of thumb, my go-to question after assessing a candidate’s technical skill is:

“How did this person make me feel?”

My goal for going into any interview is to gain a better understanding of who the candidate is beyond what is on their resume and what their motivations are for arriving in this room with me. If I left the interview feeling more confused and conflicted than I did going in, it’s probably a good sign that this candidate is not the one. If I left the room feeling energized and excited, s/he is most likely a keeper.

Hire someone you would be excited to work with and most importantly, trust your gut instinct.

Be consistent in expressing your values.

From creating wireframes to leading a team of developers, I knew it was important to establish our design and engineering principles early. It helps guide us in making product decisions, examining trade-offs during development, and uniting us stronger as a team.

Our team’s north star ?

An example of when we put our principles to the test was when my CTO had fixed a bug only to have it spam our users with hundreds of push notifications within a span of minutes.

I suggested to my CTO that he should write a post to be considerate of our users, take accountability, and explain what had happened so that our users can empathize with us through our immediate transparency. It will also be the kind of leadership that our junior engineers can learn from. And he did.

Instead of receiving any backlash, his post was received with likes and heart-eye emojis. Not only did our principles became a model for how we communicated as a team and developed our products, but it also forged the path for building a trusting relationship with our users.

It goes without saying that leaders lead best through their actions, and not only by what they have to say.

Now whenever there’s a bug (not saying it happens often), our users are much more forgiving and understanding of it. Not only that, but the other engineers on our team started to follow his example and took accountability for their own missteps as well.

Don’t underestimate the power of 1:1 meetings, because they are so, so important.

Whether you’re a designer or the CEO of a company, 1:1 meetings will always be the bread and butter for building a personal connection with your team. My engineers and I have weekly 1:1 meetings to QA the state of our product and pending features. To my engineers, it might be just a routine product QA. To me, it’s a perfect window of opportunity for me to get to know them on a personal level, address concerns they might have, and provide insights to help them find more value in their work.

If you’re looking for mentorship or growth in your career, I suggest scheduling 1:1 meetings with your team leader. First, it shows initiative. Second, you might also be surprised by the feedback and support you get in return. Before reaching out, make sure you understand what your goal is for the meeting. Is it to understand how you’re doing in your role? Is it to ask for additional remote days? After figuring out what your objective is, make sure to communicate it. This will help give your team leader ample time to prepare and keep the meeting focused.

Creating a process is great, but staying flexible is even better.

Create processes, but plan for disruption. This can mean one of two things. One, the process you created didn’t work out as intended. Two, the process you created worked, but it ended up being discarded somewhere along the ever-evolving development process. This is especially true for startups during their hyper-growth stage when you have many cross-functional teams working together to build and ship a product. When this happens, you have to be able to quickly switch gears, and adopt new mental models, while pushing the overall product vision forward.

So instead of looking for an evergreen process, make your process of implementing and iterating evergreen.

Figma is king.

This article is not sponsored by Figma, but I figured this would be a great chance for me to give this amazing team (and product) a shoutout. Before Figma, our design team at Christina’s was getting around with using Sketch for design, Zeplin for hand-off, and Abstract for version control. It was a lot of tools but we had figured out a process that worked for us. Intrigued by Figma’s approach to design and collaboration, I decided to test out the tool to see for myself.

With Figma, design to developer handoff became almost instantaneous. In addition to the speed and efficiency, we also saved a lot of money in not having to use multiple software to maintain our design system, version control, and hand-offs. Since then, our entire product team has switched over to using Figma, and we haven’t looked back since.

Thanks Figma ✌?

“Work politics will always be a thing, but it doesn’t mean you have to be a part of it.”

My COO said this to me during one of our lunch conversations after I had told him my reason for not wanting to accept the promotion to Head of Product.

With my previous role as a product designer/owner, I was able to influence business decisions, resolve problems, and focus on building products from behind the shadows, politics-free. However, when he said this to me, it made me realize that it’s not about the situation or the environment, but rather how I choose to react (or not react) to it.

More importantly, he made me realize that my new role will only put me in a better position to squash any office politics (with my killer resting face), reinforce our core values, and further protect the positive and empowering culture we have built together.

Start building your persona capital early.

A persona is in short — a representation of a target audience or a person. Research shows it takes about 3 seconds for people to form a perception of you upon the initial meeting. Sometimes even before you’ve even spoken a word. Now consider this in terms of all the micro-interactions you might have with your colleagues, clients, and business partners day-to-day. Add in impromptu slack messages, random hallway exchanges, desk drop-ins, meetings, and company events — now you have given every person you’ve interacted with countless seconds to form their opinion of you.

What kind of team member would you like to be? What kind of leader do you want to be perceived as? What do you want to be known for? Have these questions answered before you join any team or company — or someone else will answer them for you.

If you want to be perceived as a competent, reliable, and self-sufficient person — show it and own it every opportunity you get.

Once you build your persona capital, it’ll be one of your most valuable assets when communicating with stakeholders, influencing key decisions, and working with cross-functional teams.

Imposter syndrome never truly goes away, but it does get easier.

Several months after joining Christina’s, I had a heart-to-heart with my CTO. I told him how I felt like an imposter. I told him how I felt like everything I’ve achieved up to this point had all been attributed to luck. It also didn’t help that I’ve never had any formal design education. I’m afraid that I was going to be exposed as a fraud one day. I was upfront about my personal assessment, and honestly, it felt good to finally say it out loud.

What he said next shocked me:

he told me he felt the same.

I was in disbelief and all I could muster was… really? This made me realized that this so-called imposter syndrome is perfectly normal, and it can happen to anyone regardless of age, sex, and experience. If anything, it just means you’re a humble person with really high expectations of yourself.

It’s been a couple of years since that exchange, and since then, I’ve felt less and less like an imposter. If you’re feeling these insecurities, share it with someone you trust. It’ll help relieve some of the burden and guilt.

One reassuring thing I’ll add is this — it will only get easier with time as long as you show up, put in the work, and commit to continuously learn.

Remember, you’ve earned your spot at the table. The only person that you need to convince now is yourself.

“Your harshest critic is always going to be yourself. Don’t ignore that critic but don’t give it more attention than it deserves. 

— Michael Ian Black”

The team leader is a key figure in a team of developers. It is a difficult role, involving both technical and social skills. This is the reason why not everyone is tailored for it.

The technical competence usually is not the problem (emphasis on usually). The social skills — let’s call that leadership — are a different story. Technical skills are fundamental, but leadership is not made of code. It is what keeps teams together and motivated.

Bad leadership can compromise not only the success of the product but the team itself. It is not uncommon to see good developers leave because of a bad team leader (a.k.a. the boss). This is not to be taken lightly, and it is a topic worth exploring a bit. So, what is leadership made of?

Leadership is made of respect

Respect is a key point in leadership. A good team leader needs to be respected by developers, first of all like a professional. It is hard to give respect to someone that you consider unqualified. But as stated before, leadership is not only about technical competence. This means that a team leader should also be respected as a person. How to achieve this? The answer is easy: if you want respect, you must give respect.

Respect is a two-way road

Have you ever felt like your boss doesn’t like you? That you are not really part of the team? That everything you do is not enough or correct? That’s the kind of feeling that leads a developer to perform below their capabilities. It is also what brings a developer not to respect the boss. If I feel you don’t like me, probably in the end, I won’t like you either.

Have no bias

Developers are human beings. They have their virtues and vices, they have a life or family outside the office. A team leader should understand and respect developers, both as professionals and as people, all the same way and without bias. Personal feelings should be kept outside the office. It is hard, but a good team leader manages to do it.

Leadership is made of trust

Trust is the foundation of every relationship, and professional ones are no exception. Leadership means trusting your developers.

Your way isn’t my way

Personally, I hate when the boss tells me not only what task to do, but also how to do it in every detail. It’s even worse when they are always shoulder-surfing me, checking what I’m doing — and how I’m doing it. Eventually, I will think that the boss does not trust me. The end result is that I’m more worried about completing the task in the way my boss would like instead of doing it the best possible way (yes, the two things sometimes do not overlap).

To delegate is a win-win

This is why it is important for a team leader to give trust to developers. There is a new feature of the product to implement? Choose a couple of developers and let them handle the feature, from design to implementation to production. Check with them on the status of the work, give suggestions if it is necessary, but let them be free to handle the task.

Delegating the task shows that you trust your developers to do a good job. This lets you focus on the big picture instead of implementation details. They will appreciate it and will try to deliver the best possible work. I call this a win-win.

Leadership is made of rules

Rules are what makes society work. The same is for a team of developers. Anyone can create a set of rules and impose them on the team. Leadership is what makes the team follow the rules because they want to follow them, not because they are obliged to. This is possible only if they trust the leader to create a set of rules based on shared values (trust and respect).

Forced rules are no rules

I don’t know you, but I have hard times following rules I don’t believe in. I cannot do it just because someone imposed them on me, without explanation and without a minimum discussion. I can try to do it, but probably I will bend the ones I find wrong. If everyone on the team bends some rules, the result is that there aren’t rules anymore. Say goodbye to productivity.

Create common ground

Even if you as the team leader have the final say, discuss these rules with the whole team. In this way, there will be a common ground to work on. No more rules bending. These rules can go from coding conventions to the choice of the IDE. It may sound trivial, but it is better to point out even simple things. The team leader should set an example, and should be the first one to follow the rules.

Leadership is made of time

A team leader should value their time; it’s one of the most important things they can give to the team. Avoid unnecessary meetings and save time for your developers. Leadership is being there for a developer asking for your time.

My time is valuable like yours

I can understand that everyone is always busy. But if I ask you to talk — because I need to talk, for some valid reason — and you set up a meeting, I expect that you will attend that meeting. My time is valuable exactly like yours. If you don’t respect my time, this is bad for a couple of reasons. First, if you made me wait for nothing, you wasted my time. I could have done something useful instead. Second, I feel like I’m not worth your time.

Take some time to talk to developers

Set checkpoint meetings to discuss the status of the work. Find a time slot monthly to do a one-on-one with every member of the team, to check how things are going and understand their needs. Always be on time when you schedule a meeting. By the way, remember a simple rule:

• 5 minutes in advance is on time.
• On time is late.
• Late is unacceptable

I said it before, but I can’t repeat it enough: the team leader should always set an example.

Leadership is made of strength

Sometimes things go south. When this happens, a team leader stays strong.

When pieces start falling down…

You as the team leader should be a reference in every situation. Otherwise, when something is falling down, you will trigger a chain reaction that will make the team unable to solve the situation. In the worst case, things go wrong and your developers are blamed because you cannot handle what’s happening. If you cannot handle a difficult situation, chances are you are not suited for the role of team leader.

Don’t panic

Leadership requires the strength to be always a solid reference for the developers, even in an Armageddon-like situation. If your developers see you panicking and losing control of the situation, they will panic too. This is the last thing you want in a difficult situation. Panic doesn’t fix problems. Do yourself and your developers a favour: stay calm. Don’t panic.

Please, don’t panic

Conclusion

The role of the team leader is a complex one, involving both technical and social skills. Technical competence is a must, but it is not enough to be a good team leader. There are aspects that are far more important in the creation of a productive and close-knit team.

As a final note, remember that the trick is to think about what’s best for your team. In the end, the team leader works for the developers, not the other way around.

See you! ?

This is me !!! @Neeraj Negi — Google HashCode Organizer

“Organizing the event is not a big deal but handling and making it successful is”- Nj

Over 900+ students participated in Google HashCode2019 from “Chandigarh University Hub”. I am writing this so that my peers and fellow juniors can learn something from my experience because in life we don’t have enough time to fall and then learn. I hope you will enjoy this and learn how I was able to manage this event.

So the story starts with getting notification from Google about “Google HashCode 2019”. I live in the beautiful city of Chandigarh, India and am currently pursuing my Bachelors in Computer Science & Engineering. Being a Google Web Specialist Scholar and Google Pytorch Scholar, I was able to get the notification about GH19 earlier via communication. ?

A little bit about me

I have already handled many huge events but this particular event has been one of the biggest — not only in terms of student engagement, but also in terms of expectations. I was very excited about the event and I also wanted to participate in the hashcode Competition in spite of being an organizer. I am a member of Women Tech-Makers by Google, Google Developer Group- Chandigarh, AWS Educate Member, 1MWIT, Linkedin Local, Adobe Club Member and in many other clubs hosted by the university.

Background: I am a Full stack web developer (MEAN Stack) |UI/UX -Web Design | Voice-Recognition Developer | Founder of Business Targeting |Linkedin Enthusiast | Google Adwords Certified | Alexa Skill and Google Assistant Developer| Mentor of 1millionWomen in Tech |Adobe Campus Representative | Working on Self Driving Cars (ML, AI) |CompTIA+| Working on AWS

I have already gotten my hands dirty with C, C++, and Python during my High School years and have learned new programming languages like Java, JavaScript, Node.Js, Angular.Js in University. My natural curiosity led me towards the field of web development and self-driving cars. I have ongoing research on deep neural networks.

So now let’s go back to the story. ? Most of the students in my university were not aware of the Google hashcode Competition. So I decided to spread some awareness to the students and convince them to participate so that they could learn something from real-world problems. Even if they didn’t know how to write <<hello world; they could still research and start exploring.

“Research is to see what everybody else has seen and to think what nobody else has thought. — Albert Szent-Gyorgyi”

Google HashCode — Competition Timing | HashCode Hubs | DashBoard | Team Formation

A little context, first: Google Hash Code is a programming competition. You get a task from Google, along with a few input files. You’re supposed to write a program that reads an input file and produces an output file which solves the problem. The hard part: you have to do it within 4 hours.

Online Qualification Round The initial online based Qualification Round was held on Thursday, February 28, 2019, from 17:30 UTC until 21:30 UTC.

Reason to participate:

Whether you’re new to programming or a coding competition pro, there are plenty of reasons to participate in Hash Code. Lindsay Taub, my mentor, put it best:

1. Optimization problems for the win. _Just like the problems that Google engineers tackle, there’s never one right answer to a Hash Code problem. Instead, each round of the competition is designed as a “battle of heuristics” — imperfect solutions. There are many ways to approach the challenge, and teams should continuously iterate on their solution throughout the round. Getting familiar with past problems is the best way to prepare; always hold a practice session (or two) with your team using the Hash Code archive._
2. Hash Code is all about community. _From competing on a team of two to four people to participating in the competition from a Hash Code hub (a local meetup that you can organize), opportunities to connect with other Hash Coders are everywhere. This is the first year Hash Code is open to developers globally, and we’re excited to see this community continue to grow. Meet other Hash Coders, find teammates and stay up-to-date on all the latest Hash Code buzz._
3. Googley fun. Hash Code is an opportunity to get a glimpse into software engineering at Google, and when our teams come together to solve challenging problems, you can bet they have some fun while doing it.
4. Learning and learning. If problems are solved by you or not! you always get some benefits by learning new things, getting familiar with new tools and methods. You can’t learn these things without participating so if you did your best, kudos to you.

You never lose…. either you win or you learn.

The best way to experience the Hash Code is to discover it for yourself. ?

Here are some of the photographs taken on that day!

Here are some questions I would like to answer:

1. Why did I choose to organize a hub at Chandigarh University?

I chose to organize a hub here at CU is because I felt that providing an opportunity for people to come together and work on a challenging problem is the best way to let them develop their skills and themselves. Hub gives you a platform so that you can showcase your coding talent and at the same time learn something from others too.

2. What was the process of setting up my hub?

There were so many things to do, like booking a room, Labs, getting approvals from our university, and ensuring Wifi was set up. At that time I was expecting around 400–500 participants but the count went way beyond that... I booked 2 Seminar halls and 14 Computer labs containing 36 PCs each for participants on that day. But later I booked 4 more rooms and that's how I managed to put all the students in one block. Getting permission for rooms for a night was one of the hardest parts, but thanks to my supportive friends I was able to do it.

We also started promoting the event a few weeks earlier to be sure we had as many participants as possible. The real fun started just before the competition when we decorated the room with balloons and posters — luckily a few Volunteers came early so they decided to join us and help!

3. What was my favorite part about hosting a hub?

Meeting new people! That’s definitely the best part. You can feel the passion and excitement in the room.

Students came here not only for coding but for being a part of world level competition.

Thanks, guys for coming here!

3 days before Google Hashcode

Planning

In India, the timing of Google hashcode Competition was 28th Feb at 11 pm at night. So I had to find out the availability of the students at night and also space, decorations, wifi, food resources, and security.

The most difficult task was getting permission for a night event. 3 days prior I emailed my department head and UIR about this event so that no problems would occur. They got my email and replied back to me on the same day. The department helped me in arranging the stay of day-scholars and getting permission for hostler to reach our Hub. Then I got help from my university branding department for printing out the Google printable kit for decorations and visitor cards or participants cards.

I would like to thank the professors, deans and all other faculty members of Chandigarh University who gave me permission for this and helped me in each and every arrangement.

Promotion

We did promotion for 2 days before hashcode by showing posters and flyers on the student portal. We were not expecting that kind of participation from students — my volunteering team told me that for a night event we could assume less than 400 participants.

But I knew that I could engage more than 400 students for this event. So I created a simple presentation describing the event and the benefits of participation. I also created a Google form so that I could get the information about participants.

Decoration

The most interesting and eye-catching thing was the decorations. Thanks to my friend ? @Deepika for taking responsibility for the decorations. She helped me a lot during this event and I really appreciate her effort.

Also, @Shushant,@Anant @Aditinegi, @ayesha, @itika @priyanka @manish @simran were working on Whiteboard Designing, Balloons and cutting Google sign prints.

Thanks for all kinds of efforts you gave to this event!

Volunteering Team

I am aware that for these kinds of events, you need your own team who can help you to arrange all kinds of stuff so that you can more focus on the core parts.

I have already a team of 150 students, but this time I thought to give this opportunity to new people.

It took me 2 days to find the right volunteers and give them the opportunity to grow. Before this, a session was held in the morning with volunteers so that they could be more comfortable and flexible with me!

What life has taught me is that you can not lead people if they do not respect you, do not trust you, and do not believe you. You can order them around, but to get them to do their best you need to win their hearts.

People do not care how much you know until they know how much you care and can help them solve their problems.

Creating this volunteering team and finding each and every volunteer becomes worth it. Thanks to all the 80+ coordinators who helped me with this event.

Special thanks to @avlin and @ashish @jatin @akhil @kartik and @karan for helping me with setting arrangements.

I think I was able to make each and everyone volunteer a good leader by guiding them in the right direction.

“Leaders become great not because of their power but, because of their ability to empower others and find out the strength they have.” — John C. Maxwell

That's what I did!

28th Feb 2019 IST

At 8:30 pm this was the crowd ?

AMA Session before HashCode Online Qualification Round!

So before the Google HashCode Competition started, I held a session to get students familiarized with the HashCode Dashboard, Point and ranking system, Optimisation of the problem and input-output logic. I also talked about lots of things other than hashcode and shared my experience with the students.

Questions and Queries

I also took some questions from the students.

1st March 2019 IST

Competition started!

As the problem was released, all coders started working on their solutions. All the students were busy with the problem statement.

Fun | Quiz | Music Game | Kahoot

After the Hashcode competition, we organized some Quiz and music ball games so that the students did not get bored and stayed connected with the event. It’s important not only to code but also to enjoy the moment.

Thanks, @sahil, and Nilansh Gupta — these are my friends who were with me while organizing Kahoot, the music ball game, and the AR game. I got feedback from the students and they really enjoyed these games. After the games, the students started taking photographs.

Thanks to @kashish, @himanngshu boro, and @saurav for taking photographs!

Kahoot Quiz

Music Game after Hashcode Competition!

At 5:00 am the students went back to their homes.

Volunteer Team Behind HashCode

I think it is the main responsibility of a Team leader to see the potential in others, to help them develop their strengths they did not even know they had, and give others opportunities to grow and always appreciate them even if it’s a small win by them.

It is impossible to be a good leader without being a good person!

It costs nothing to be respectful, kind, nice, supportive, grateful and positive.

“We are not a team because we work together. We are a team because we respect, trust, and care for each other.”

Here was my appreciation message from my side for volunteers at 6am on next day!

What I learned from my mentors was that “a person who feels appreciated will always do more than what is expected.”

Feedback & Responses After Hash Code Competition

I got around 300+ appreciation messages for the hashcode event from different platforms. I want to take this moment to thank all the participants and coordinators who were there and joined Google Hashcode 2019 with me. In the future, I will definitely organize another event like this. ?

Thanks, @Lindsay Taub for mentoring me!

Leading is not about winning, but it is about bringing others with you to the finish line. Agree?

Comments and claps are highly appreciated!

Connect with me on Social Media:

Twitter: @realneerajnegi

Linkedin: https://www.linkedin.com/in/neerajnegideveloper/
Instagram: https://www.instagram.com/neerajnegi_nj/

Follow our Hashcode page: Hashcodenj and #HashCodenj

https://www.instagram.com/hashcodenj/

This series portrays my experience as an R&D group leader of a group that has the same behavior as a failing startup. In my last two blog posts, I’ve presented a short background regarding the developers and the technologies. This blog post will deal with the vague definition of a group’s identity.

In my last blog post, I portrayed an image almost too good to be true. An image of a productive software group, full of energy and hunger for projects. I knew I must look away from newly gained success and only into the problems, however unfortunate that made me feel.

On the one hand, I felt the need to present the milestones I’ve created to restore some kind of productivity. I wanted to show the boss all the recent successes — the coding methodology, working regulations and other concepts we’ve begun implementing. I wanted to present the training concepts and procedures we’ve established. I wanted to present the strong cooperation I’ve led with another organization. This cooperation granted an opportunity to combine the organization’s knowledge pool and create better professional training for my group. On top of these, one of our projects was accepted to an acceleration program. I really wanted to show that off as well.

But I knew this image would soon fade unless I continued targeting the main issues. The primary issue was this next hard truth. The group didn’t have a strong basis and it was just a matter of time until it might collapse again. I identified it as the group’s lost identity.

What is a group identity?

When we reach a point in life where we seek our unique identity we look into various questions. Where am I from? What is my heritage? Who influences me? What’s exciting for me? What’s the reason I wake up in the morning? These questions helped me shape my personal identity both as a human being and as a leader. The same process happens one way or another in every organizational structure.

Defining a group’s identity must happen the moment a manager takes the reins. They must look at the group’s responsibilities and define each group member’s position. It clears many things up. It provides clear borders regarding the manager’s and the developers’ responsibilities.

This process must occur at the group manager’s level and even higher. It is rare that a complex organizational understanding such as an identity can depend on the team leads’ scope or lower. It is also unfair to the team leads, who already have enough on their plate.

As you may recall from my previous blog post, I talked about the vicious zero-products cycle. This cycle started somewhere, so I started retracing the group’s steps. I realized that the moment the last official product version was released was the breaking point. This was the point where there was no clear view on what the group’s main objective was, what was its purpose and what was the product it was responsible for delivering.

What was the main objective?

The main objective was software and system maintenance for a very complex system. In order to perform software maintenance on such a large amount of code, a developer must work on the code. The developer must understand it and get to know its genius functions, but also its inherent faults and flaws. The developer must feel the code. They can only gain this feeling through massive research and deep understanding of procedures within the system.

In my view, it is impossible to maintain the entire system simultaneously, as a result of a small number of maintenance dedicated developers and a very serious lack of knowledge. So I declared that maintaining specific domains every year was good enough for us. The alternative would be scattered maintenance that would only lead to more gaps in the long run.

Let’s look at a simple example such as inserting an image on a screen. This is easy in modern systems written in readable code that follows proper coding methodologies.

In our case, to insert a feature, the developer needed to follow more complex steps. They would research the entire screen’s code and the entire code of screens that might be affected by the change. It might take up to a month of research. After the research would’ve developed some conclusions. They would try to decipher the relevant piece of the system’s architecture and find a few ways to implement image insertion.

In parallel, and this is the important part, the developer must document EVERYTHING. Every difficult method. Every process they discover. Every architecture or network insight they have. Every unusual phenomenon and its investigation all the way to its origin. This is crucial since the existing documentation and most of the written code are barely readable.

The objective seems very straightforward, but regulated documentation and code maintenance is not the only thing that defines a group’s identity. The group has to have a purpose. Our purpose went missing.

Where did the purpose go?

At some point, software maintenance was performed under no regulations and slowly went out of the professional focus. What started flowing instead were side projects. Side projects became the main objective. Whenever a client approached one of the teams, in need of a quick fix, the group would pivot in that direction. People were working on side projects for the sake of working. The difficult yet crucial maintenance was completely abandoned.

When I started my position as group leader, almost every group member told me they didn’t know exactly what the group was actually meant to do. They felt they had no real goals when they came to work. Side projects scattered the purpose.

Why do we sometimes need to manage our clients?

A software group cannot blindly do what the client wants. Especially when the client changes their mind frequently. For example — back when I was a software developer, my team and I were working on a navigation project similar to “Waze”. Our product owner kept requesting changes that made no difference whatsoever to the system’s functionality. It was always a request to change button colors or move toolbars around the UI. This kept the team from making any progress for a very long time.

In my software group, the problem was on a larger scale. The group didn’t have one indecisive client. It had a few separate clients and each client pulled in their own direction. There wasn’t one integrating factor, looking at the larger picture and managing the clients and the projects. For a long time, the group worked through a queue — first client in meant first project the group developed. Therefore, almost any type of project could be brought to the group. In time the group began dealing with QA, IT and even hardware issues, rather than software development.

Retrieving the purpose, and consequently the motivation, was an ongoing process. It began with a definition — I’ve defined, along with my team leads, our projects. We’ve prioritized them in accord with our clients’ demands, thus setting a roadmap we will not slip from, as happened in the past. This roadmap indicated our objective — system’s software maintenance was declared our purpose.

We’ve added one more project to the roadmap, a second main project, related to the system but not directly. It added to the purpose since it had great unimplemented potential. I believed it would be great for PR and to enhance the developers’ belief in their own skills. This dedicated roadmap focused the teams. We knew that by the end of the year we needed to deliver two products end-to-end.

Setting the professional compass was important. The bigger problem was regaining the developers’ trust in the group. After so many years, my developers — both experienced and new — had no fuel nor will to work. After some of my scheduled one on one talks, I mapped each developer’s strengths. If for example, one developer was really good at research — I let them do the research.

After mapping individual strengths, I mapped team strengths. Some paired programming was performed in order to strengthen some developer’s self-esteem. We’ve held a professional workshop for team leads, to strengthen management abilities. I addressed the issues I picked up when I observed the programming process and the issues the developers themselves had presented.

So how was the identity restored?

By finding a definition and restoring order. We’ve defined our field of expertise. I’ve put borders around our designated projects and let no other project cross that border. Limited the issues we work on (no more hardware issues!). Made sure there was proper usage of coding methodologies and version control. Made everyone document their work. Strengthened each programmer’s strengths. Sharpened the team leads’ set of soft skills.

I targeted both professional and personal values in order to restore the group’s inevitable software DNA.

The difficulties of leading changes in an unforgiving environment, leading innovation instead of sinking and how to survive as a young female in a very ego driven male environment? Stay tuned, all this and more as the series unravels!

Part 1 — How Can Corporations Heal a Dying Software Group?

Part 2 — Overcoming a Technological Gap — a Horrible Circumstance or a Creative Adventure?

Parts 1+2 — How I started the process of healing a dying software group

If software development feels like it is only part of your professional purpose, perhaps you should consider becoming a tech lead. A tech lead could mean different things: a team lead (with no direct reports), or a manager. For example, an engineering manager is a person who is responsible for the team and its projects. That means they are also responsible for peoples’ careers, business growth, deliverables, deadlines, culture, code standards, technical debt, and more.

If you’re a developer, it may not be clear how to get from where you are to a technical leadership position. If your goal is to become a manager soon, you will need to ask yourself why you want this role. Becoming a manager may or may not align with your long-term goals.

I got into software development because I felt more comfortable working with computers than people. But after a while I found myself helping other developers more and more. I enjoyed leading projects and pushing for better code standards. It was an obvious choice for me personally.

For many software engineers, growing as an individual contributor (IC) could be a more appropriate path. Many companies provide IC alternatives to management. These alternatives include a staff engineer, distinguished engineer or fellow engineer. These are very senior technical roles, but no one reports to them as they would to a manager.

the stereotype of a developer: eating pizza, works at night alone, etc, etc

So, do you want to become an engineering manager or another type of team leader? It is important to be honest about what drives you — is it writing code and architecting software? Or, is it helping others to get better results, negotiating deadlines with stakeholders, and convincing your business team that code refactoring is not a waste of time? Your answers to these questions should help you determine which path is more appropriate for your desired outcomes.

If you’re still convinced a technical leadership path is right for you, then you have some work ahead of you. Consider working with your manager or a mentor to have them help you in areas where you are less familiar. Here is an outline of ten key areas of focus:

Stepping up. A true leader can lead without the title or authority. Anyone with a fancy title and enough authority given by the organization chart can give orders. But that’s not what leadership is — it is about what you do.

Therefore, you should start small. Take on more responsibilities during difficult projects. Help your peers by providing feedback in pull requests. Volunteer to present on the project updates. Propose improvements to your team or product workflow. Mentor a colleague.

There are enough opportunities that people either don’t want to see or don’t have enough expertise or confidence to take on. Determine what your colleagues are struggling with, and then step up and do them.

Ownership. When taking on responsibilities, be accountable for everything you do or don’t do. A leader takes responsibility and avoids blaming others for mistakes, missing deadlines, or bugs.

Rather than complaining about a bug someone introduced, just help them fix it and explain how to avoid it in the future. Coming up with excuses doesn’t help anyone. Take the time to deliver what you committed to. If necessary, negotiate a better deadline with your manager. Run a project like your own business and actually care about it.

Recently, one of the tech leads on my team pulled the latest master branch. They saw a big drop in unit test coverage. Rather than complaining, he added missing test coverage. And then presented how to properly check for the coverage and how to write a unit test for complex features. He offered to help if anyone needs it without blaming anyone. The team appreciated that.

Relationships (or politics). Sometimes people misinterpret relationships and call them “politics”. They are the same things. If you don’t want to deal with “politics” then perhaps think again if you want to get into leadership in the first place.

Building meaningful relationships is one of the responsibilities of engineering managers. Management is making things happen through other people. Start building good relationships with other engineering managers. They are your future peers.

There are a few ways to do this, such as presenting at tech talks, doing workshops, and mentoring developers outside of your team. Engineering managers will appreciate the relationships you build through these tasks.

Technical expertise. An engineering manager should be an engineer first. They must have a strong software engineering background and hands-on experience. Becoming one of the strongest engineers on the team is a requirement. A manager who can’t code or doesn’t understand the technical details can’t take part in technical discussions. Once you become a manager, you should always keep your skills sharp enough to be competent at higher level architecture.

Mentorship. Any “really good developer” on the team who’s not a team player is more harmful than helpful. If you’re technically strong, then you should be helping others to get to your level. Pair programming, code reviews, presentations, open source or inner source projects are all great examples of how to get started in mentoring others.

It is rare for someone to come to you and ask you to mentor them. Yet, by branding yourself “the expert” and proactively doing the things mentioned above, people will naturally start coming to you for advice. By helping others you build meaningful relationships and gain people’s respect. Hopefully, they do the same in return and mentor others as well.

Project management. Delivering projects on time is one of the core responsibilities of any leader. If, as a developer, you’re constantly missing deadlines and underestimating tasks, others can’t trust you. You have to be organized and be on top of your tasks.

We all know estimating software projects is hard as there is a lot of uncertainty. However, with the right process, it’s not impossible. Constantly communicate the progress and expectations of the project with your manager or stakeholders.

For example, my team is doing a weekly status report, where the project tech leads have an opportunity to communicate the progress, mention any blockers or raise a major concern of not delivering on time.

Communication. Communicating clearly and concisely is a very important characteristic of any leader. If you can’t explain clearly what you want from your team, then you have failed as a leader before any work even begins.

Communication comes in many forms, including verbal, written and even body language. Always work on improving all of your communication skills.

My team missed a few deadlines because I failed to communicate the requirements clearly and on-time. There were few instances where the lack of communication created confusion on the team who was supposed to do what. I learned that relying on project managers or business stakeholders to explain the project details isn’t working. An engineering manager has to understand the project and then explain it and sell it to the team. And motivate them to want to work on it.

Managing up. Manage your manager (and sometimes their manager). This means constantly communicating with them and managing expectations. Managers rarely like surprises, good or bad. Establish trusting relationships with your manager. Be the go-to person for important and high profile projects, and actually get them done on time and on budget. Then more projects will follow and you can repeat the process.

Conflict and crises. Production issues happen, no matter how many unit or integration tests you have. Yes, you want to minimize the number of bugs your projects have. What matters more is how you handle production issues. A person who starts panicking under pressure is immediately disqualified as a leader in the eyes of others. The team and other managers want to see a calm person who has everything under control, even in the most stressful situations.

A tech lead I used to work with was always calm. There was no conflict or pressure that could make him snap. At least nobody saw him stressed out. When it came to handling a production issue at 3 am, he didn’t disappoint. The issue was fixed in minutes and he showed up to work as if nothing happened.

Another tech lead got so stressed out with the deadline he called in sick on the day we were supposed to launch the feature. He was so anxious, it made everyone else around him uncomfortable to work with him.

Even though these are 2 complete opposites, you can guess which one was more successful as a tech lead.

Vision. For everything they are responsible for, a leader should understand “why”. They are also responsible for ensuring everyone else understands “why” they are working on a project. A leader must explain (often many times) why the project is happening, why the specific people are working on it and how this project fits into the “big picture”. A team has to believe in what they do, only then can they can be effective.

Leadership is not limited to one or two people

Lead the Way Forward, Starting Today

Leadership is not limited to one or two people, so don’t wait for permission, step up today. Be an expert in your field and start helping people when they are stuck. Work on your communication skills, even something minor like technical documentation. Build great professional relationships with your current and potential future peers. Make sure you manage your time wisely and be on top of your projects’ deadlines. And don’t forget that leadership is about people, so genuinely help people grow and do their best job.

You can find me on Twitter https://twitter.com/netxm if you have questions or just want to say “hi”.

The tech lead was moving to another team for a long-term assignment, and I took over as the engineering manager/team lead.

From the outside, the tech lead’s job seemed doable, but I quickly realized I was getting in over my head. Unfortunately, my team was responsible for a lot of centralized infrastructure as well as day-to-day technical operations. I had no tech lead training, and how could there be? I was certain that the tech lead role was so different across companies, so how could there be guidelines to it?

In my previous role as the senior engineer on my team, I felt capable of tackling larger projects, but I only ever had 1 project to tackle. Now, I needed to manage 3–5 projects for my small team of 5 engineers.

The best I could do was do as the last person did which only gets you far enough to keep your head above water. I realized that the only way for me to get past this would be to hit the books, and learn all the management that I never learned in college.

I read a lot that year. More than the past 3 years combined. The most helpful books I read all boiled down to 3 areas of the job that I (like many others) struggled with: dealing with team & individual performance, delegating, and making my team a great team to work on.

*Disclaimer: I’ve tried to link to the authors website where I could. Otherwise, the links go to Amazon (not referral links) if you want to get the book. I have no association with any of the below authors, just a fan of their writing.

Dealing with performance

One thing that I felt affected the team was an under-performing team member. Surely like many others, I hadn’t ever seen an effective performance review myself, or seen how other leads dealt with performance on their team (thats probably a good thing, but unhelpful for me).

While I know at a high level what you’re supposed to do, like talk about and deal with the problem, I struggled to actually do it — how could I, a new lead, give feedback to someone who was previously a peer on my team? It’s definitely awkward the first few times!

Fortunately, in this area, there are people much smarter than I who have shared their experiences in great deal to help you get past these types of problems.

• Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott
  If you want to focus on giving great feedback — this provides a pretty powerful mental model for giving and receiving feedback without feeling like a jerk. It’s focused on being upfront with people, lest you be plotting against them or humiliating them.
• Leading Teams: 10 challenges and solutions by Mandy Flint, Elisabet Vinberg Hearn and Debugging Teams: Better Productivity through Collaboration by Brian W. Fitzpatrick, Ben Collins-Sussman
  If you want to focus on getting yourself un-stuck from some problems on your team — these 2 books go in-depth on common issues that teams might have, and some step-by-step guidelines for how to deal with them.
  This was an area I didn’t feel comfortable asking any of the other managers about. We had many small teams, and we were all very friendly so it was hard to find people you can talk to. The next best thing was seeing what other more successful leaders had done in these scenarios.
• Manager Conversation with Low Performers at UMCB on Youtube
  It’s very rare you’ll ever get to shadow someone else’s performance review — they’re private and personal by nature (or you’re HR). If you’ve ever wondered what a “good” conversation about poor performance could look like, this video helped me a TON! There’s some other related videos there that will show you what NOT to do, but it is great to see how you can quickly diffuse an awkward situation.

Lesson #1 summary: Be incredibly explicit about your expectations with their job so that they can never say, “How was I supposed to know?”

Delegating

Another awkward part about my job was telling people what to do — our team had a mission that we were mostly aligned on, but we don’t always get to work on cool stuff and the work still has to get done on time.

I had seen other people do it well, I had seen others do it poorly — but I wouldn’t have been able to explain to you why. I felt awkward the first few times saying, “hey Roger, can you take a look at this issue?” only to have that developer come back with something that I wasn’t expecting (see Lesson #1).

When I was a fellow engineer on the team, I felt capable of working on bigger projects and making sure that we shipped the right things. But now, I was also accountable for all the projects the team was working on, not just mine. I had about twice as many things to do now, and the typical-engineer-turned-manager in a bout of frustration might ask, “When am i supposed to code if I’m stuck in meetings and dealing with people all the time?”

It was difficult to juggle all the projects that I was now responsible for, as well as do the work on critical projects, and plan cross-team initiatives, and insert 20 more things here.

• How to Delegate (Essential Managers Series) by Robert Heller
• The Busy Manager’s Guide to Delegation (Worksmart Series) by Richard Luecke, Perry McIntosh

To summarize these books: be incredibly explicit about your expectations with projects/tasks so that they can never say, “How was I supposed to know?”

While these two books sound a little cheesy, they gave me a great framework and process for delegating. After reading them, I started blocking out time on my calendar for going through our projects and trying to match people’s goals and motivations with the work we had to do. A bunch of us got AWS certificates, one engineer earned with a promotion, and an intern joined us full-time. And we built great stuff too.

Making a good team

One way to build a better team is to see more teams and how they operate, and use them as guiding examples for building your own teams. The catch is, barring you leaving your job and working elsewhere, you won’t get to see that many teams and so you might not even know what your team would look like at its best!

I absolutely loved reading these books because they provided case studies of real teams with real stories across some high-profile companies. Some people had really crappy times at their job, others didn’t, and they explain why in-depth.

These books are more focused on software engineering teams:

• Talking with Tech Leads: From Novices to Practitioners by Patrick Kua
  Patrick Kua is a great speaker with some of his talks available on Youtube about technical leadership covering things like What I wish I knew as a first time Tech Lead and Geek’s Guide to Leading Teams
• Building Software Teams: Ten Best Practices for Effective Software Development by Joost Visser, Sylvan Rigal, Gijs Wijnholds, Zeeger Lubsen

These books cover teams in general:

• Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders by Andrew Stellman, Jennifer Greene
• Extreme Teams: Why Pixar, Netflix, Airbnb, and Other Cutting-Edge Companies Succeed Where Most Fail by Robert Bruce Shaw
• Scaling Teams: Strategies for Building Successful Teams and Organizations by David Loftesness, Alexander Grosse

To summarize these in one sentence: Be incredibly explicit about your expectations with the team’s culture so that they can never say, “How as I supposed to know?”

Wrapping up

I had a great time leading my team for over a year. While at times, it was incredibly daunting to think how I would get through a particularly problematic week, my team would stay on track and over time, we were able to move to more proactive work. There’s many different areas in management where you could spend days and day learning, but if you do 1 thing and nothing else…

Tell your team to be incredibly explicit about their expectations from you as their lead so that you can never say, “How was I supposed to know?”

Fellow tech leads on Medium: What was the hardest part of becoming a tech lead for the first time?

If you enjoyed the article, give it some ? and follow me here on Medium.

Originally published at www.intricatecloud.io on December 11, 2018.

Over the past two years since I became a Tech Lead at Wix, I’ve come across questions on how I got this role. I must be honest and say that I wasn’t actively looking for it, but looking back I would like to share a few tips for developers who want to become Tech Lead.

I think the role of tech lead is hard to define and differs between people.
For me it’s mainly about mentoring: helping the engineers on the team improve. This means helping them with their design, code reviewing, and teaching them the best way to communicate with other teams and make an impression.

When I started in the industry, the only career path I knew was management. Today it’s already clear that management is a different role than it used to be, and you can also advance by becoming a Tech Lead or an Architect.

Becoming a tech leader

I think the keys to becoming a good tech lead is asking questions and expanding your knowledge while being friendly and socially aware. Here are my top tips:

Really understand what you’re working on.

Fully understand the product requirements, the design of your system and the different technologies you use. Even if you weren’t part of the decision making, ask the questions: why were specific technologies chosen? Why was this design preferred?

Know all parts of the system, including the parts other people are working on. You don’t need to read every commit done. But you do need to know what your peers are working on and what their part of the system does.

Say what’s on your mind.

It’s harder for shy people to learn and become leaders. You have to always sit at the table at meetings and make your opinion heard. Try and be involved in conversations.

Challenge decisions made by other people, and don’t be afraid to ask architects or tech leads why they made a specific choice. Successful people welcome the debate and are always happy to explain their choices.

Technical people can and should challenge product decisions. You should always have the customers in mind and make sure that what you’re working on gives them value.

When you see something wrong — get it fixed.

Don’t stand by when you think a mistake is being made. Politely inform the person in charge and ask what they think about it. You might find that you are wrong, but a lot of times you will help fix a problem. If the responsible person doesn’t have the time to fix it, you can offer to contribute your time. This way you can learn another area of the code and you will be appreciated for being a team player.

I had a few times where I integrated with other projects and didn’t think their design was right. I told them I didn’t fully understand why they chose this design and asked them to explain it to me. Most times it made sense after they explained, because I wasn’t fully aware of all the limitations and concerns. However, a few times I managed to help by highlighting concerns they weren’t aware of.

Even if your concern is wrong it’s good to raise it: You will get better at understanding design and concerns and your opinions will be valued.

Volunteer for extra work when you can.

Every once in a while an opportunity will come to volunteer for some side project or some other task. Be the person that volunteers, even if you’re not sure you can do the task. This is the way to grow, you will learn your missing capabilities and maybe get the opportunity to work with people you don’t know yet.

A few examples we have at Wix:

• Be in charge of weekly lectures organized for the backend engineers,
• Make sure Post mortems are created and shared for production issues,
• GDPR integration across the company.

I personally volunteered to help engineers that write talks for conferences, as it gave me the opportunity to work with different engineers I don’t usually interact with.

Volunteer for extra work

Invest in making connections.

Some people refer to coffee breaks as a waste of time, but I think they are crucial. When you meet people and create a social connection you create a relationship that will help you in the future.

As human beings, we’re much happier to help our friends. The more friends and connections you have, the faster you can get help when you need it. This helps integration projects go more smoothly if you know the people you’re integrating with.

This is also a great opportunity to step into conversations other developers are having about their design. You might hear about new opportunities that can advance your career. The more people know you, the more opportunities you will get.

Last week I overheard a conversation by engineers I didn’t know and realised that they are unaware of a product I was working on. So I joined in politely and was able to save them lot’s of time while make new connections.

Invest in making connections

Seize opportunities.

Opportunities will come your way, either inside your company or from companies that wish to hire you.

When a good opportunity comes by you should grab it. Don’t let your imposter syndrome deny you a great advancement. You have to believe that if you were offered the chance — you can make it. There might be a learning curve but learning new skills is how we grow.

If you hear of a good opportunity you like and weren’t offered, ask if you can have it. You might get a negative answer, but there is always a chance you will get a positive one.

My first position as a tech lead was offered to me by a project that was going through a big rewrite and thought I could help. It was a big job but I seized this opportunity. I opened many doors for me for other tech lead roles in the company.

Seize opportunities

Becoming a leader is about taking initiative and showing your peers and your managers your capabilities.

Becoming a Tech leader involves all of the above and having a deep understanding of technology and design.

If you play the part of a tech leader in your current role you will become one. Believe in yourself and your capabilities and you’ll succeed.

You’re welcome to follow me on twitter :) Thank you for reading!

By day, I work as the UX Architect for CHSI Technologies, a Las Vegas-based insure-tech company. After hours, I organize Las Vegas Developers, the largest meetup of coders in our city.

I signed up for Startup Weekend this year with the intention of personally hacking out a simple web application: a self-updating directory of developers in Las Vegas.

Prior to Startup Weekend, Las Vegas Developers had little web presence besides our Meetup page. I wanted to change that by making an application that would display our members’ projects online after they presented them at our monthly event, Demo Day.

I decided to pitch on the first night’s Call for Ideas to see if anyone wanted to help build this in the next two days. When I got six amazing team members volunteering their diverse abilities, I realized someone needed to lead. Combined with the fact that my CTO at CHSI Technologies asked me to take more of a management role this quarter, I knew I had to step away from coding and step up to lead the team. But how?

Pitch for culture

“I’m looking for stone-cold killers willing to kick ass and get st done!” I declared. I wanted to be divisive in my call-to-arms. I wanted some people to be turned off. And I wanted a select few** to rally around the cause — in this case, people who saw themselves as ass-kickers.

I learned this from fellow Vegas resident Tony Hsieh, CEO of Zappo’s, who will pay you to quit, weeding out those less dedicated to the cause.

Fire before you hire

Leading at a hackathon is an interesting challenge. People are volunteering their weekend to your idea. Turning away voluntary help can be awkward.

“Unfortunately all of our spots are filled and our team is already built,” I said, looking a newcomer in the eye. My 6 other team members froze.

“Ok,” the newcomer said and went off to join another group.

“Damn.”

“That was cold.”

“I feel bad for him.”

My team members were shocked when I immediately turned someone down who approached our growing group. I felt bad too! But I saw how disruptive this newcomer was. I had been scouting the room all night, and this particularly loud and obnoxious attendee was someone I didn’t feel good about.

When he train-wrecked the team he eventually joined, dissolving its final pitch into a shouting match and battle for the microphone, we all felt better about this decision.

We were stone-cold. I said it in my pitch and backed it up with action.

Set expectations

Immediately after that, I set expectations for the team. We’re not here to pretend we are Steve Jobs and we’re launching the iPhone. We’re here to have fun and build something cool. We are going to behave like this a viable product and a real company for the sake of the competition, but in the back of our minds we will really be there to have fun and make something cool.

“Is everyone okay with that?” I asked. “If not, you could pull me aside and join another team, or just take off without saying a word, no hard feelings.”

We talked openly about what we wanted to get out of Startup Weekend. No one said they expected to start a unicorn business from this venture. Most spoke of gaining experience or having a good time. I was glad to see our goals were realistic and aligned and made us feel good.

Break the ice and dive deep

After an intense first night, I wanted to unite the team. I spent the rest of the night at home planning how we could do this. Then we spent the first hours of the next morning getting to know each other.

I believe ice-breaker questions should have an intention behind them, not just be a silly time-waster.

One of those questions was, “What is something about you that no one else at Startup Weekend knows?”

I did this to make the team feel collegially conspiratorial — like we were all sharing secrets with each other, and we had these things to unite us.

Then I asked: “What amount of money would it take for you to ‘fast forward’ to next week, everything occurring as it would in your ‘timeline’ but you just miss it?”

Most people said their time was priceless and couldn’t put a figure on it.

And that’s the point. Our time is priceless, so let’s make the most of this weekend with each other. Let’s spend the time as if it’s all we’ve got.

Ironically, this activity took up the entire morning of the first day of hacking. But I believed it was an investment that would pay off immediately.

One of our team members said it best:

It was a worthwhile investment. I think this really brought us together as a team and unified us toward creating a working product.

Offer voice and choice

“Voice and choice” is a way to grant team members autonomy while still focusing on the team’s goal. It’s an idea taken from thought leaders in the education world.

Take 2 minutes to watch this video made by high school science teacher Jeff Robin and think of how business leaders can apply this to their teams:

Giving a voice and choice to team members increases buy-in and moves members’ motivation up Maslow’s hierarchy of needs toward self-actualization and pure joy.

Our hackathon team did this by brainstorming all the features our application could have. Then every developer initialed which feature they’d like to work on, allowing for multiple developers to initial the same thing.

They would either pair on such things or one developer would grab something while another was occupied.

Together we decided on the most minimum feature set that we had to release, truly a minimum viable product. Then we ranked the remaining nice-to-have features individually, 6 through 1, and added up their scores.

Now we had a roadmap: the minimum we had to execute, and the cool stuff we would get to if we had time. And it was divvied up according to what each developer wanted to work on, their voice and choice.

Dance in chains

If you watched the video above, you heard a beautiful phrase borrowed from Nietzsche.

The artist is he who dances in chains.

Jeff Robin explains that by giving his students constraints, he enables their creativity.

Voice and choice is tempered with… experience and preset parameters. Everyone has parameters. Pop singers have three minutes, accountants have the tax code, physicists have Newton, and artists have canvases.

So I had to use my experience and consider the skillset of the team to make “canvas” decisions — laying out an environment where everyone could feel successful.

Would I have preferred to use robust task management software like Github Projects, Waffle, or Moo.do? Yep! But one of our team members had only been coding for 13 days!

And we had two team members who weren’t coders, but were business analysts or marketing folks. So I made the decision that we would use Trello for task prioritizing and workflow and Slack for communication — tools everyone could adopt quickly.

I also made the “canvas” decision that we would use a React / Firebase / Bootstrap 4 framework I made — it was simple and modular. Our most senior dev wrote up a strict branching / pull request checklist, put it in the README, and helped everyone get aboard the codebase.

With these preset parameters, we allowed the developers to work within constraints and actually be more creative and enjoy their contribution to the project.

“Leading” is out, facilitating is in

Everyone thinks other people need to be managed, but no one thinks they themselves need to be managed.

Everyone thinks of themselves as a self-starter. But then they believe their employees need to be assigned work, or led in a direction, or “held accountable.”

If you’ve hired well, a leader’s job is to make sure the team can do their job — no longer leading them, hand-holding, managing, micro-managing, directing, or anything else that puts a bad taste in my mouth as I type the words. The only word I like to use to describe this role is “facilitator.”

Marcus Blankenship, a coach for tech leaders, redefines leadership to mean something similar:

Leadership is the process of creating an environment where everyone can participate in solving the problems at hand.

Call yourself a leader on your résumé, but act like a facilitator while in the trenches.

You’ll know you’re doing it right when people are coming to you for quick advice and leaving happily empowered to do more.

The leader isn’t the one talking the most, it’s the one everyone talks to.

A happy team = results

Again, many bad managers think their reports would be happiest slacking off all day. This demonstrates a clear ignorance of Maslow’s hierarchy of needs and the fact that “the self only finds its actualization in giving itself to some higher outside goal.” People are happiest achieving things. Enable them!

Awww, lookit these smiling stone-cold killers. :)

In the end, we came together as a group, worked hard on a common goal, and had a ton of fun. Developing something useful and winning Startup Weekend was just a byproduct of that process.

Here’s where you messed up.

Your tech lead told you to build out a new API endpoint for an upcoming feature. It was supposed to be simple: just return a list of the current user’s email addresses.

You start with the usual boilerplate. You register the new endpoint. You associate it with a controller. You add an explanatory comment.

Then you discover that the query is impossible. The user’s email addresses all live on different database shards.

The footlights flip on. The curtain rises. This is your time to be a software superstar! You’ll use your hard work and creativity to find a solution to this unique problem.

You begin building a denormalized table to keep the data local to the user’s shard, as well as a wrapping layer to keep the copies in sync. Your solution is scalable and performant. Look at you go!

Here’s the problem. You didn’t talk to your tech lead. From their perspective, they gave you a simple thing to work on, and it’s taking you three times longer than expected. It doesn’t matter if you’re creating the perfect architecture. You’ve eroded trust in your relationship with your team lead.

The best engineers can create elegant systems, but they also talk to their tech leads the right way. Here’s what I recommend.

1. During meetings, focus on how you’re tackling what’s going wrong

It’s time for the standup. What are you going to say to your team and your teach lead?

“I’ve made some progress on this thing yesterday. I ran into some test failures, and I’m fixing them now. I hope to ship this today.”

That was a status update. And it was pointless.

Status updates are communications that have no response other than “OK, sounds good.” Why spend the time giving these in-person updates then?

The whole point of holding standups is to encourage team members to unblock one another. The traditional three questions are:

1. What did you finish yesterday?2. What will you finish today?3. What's blocking you?

People often focus on the first two and omit the final thing entirely. But it’s the most important!

People often interpret “What’s blocking you” as “What’s completely stopping you from working?” That’s why I prefer the question “What’s your red flag?” instead.

A red flag is anything that’s going to slow you down. Here are some examples of red flags:

• “I’m not sure how to get started on the test for this.”
• “I need to figure out what the mobile team needs me to do here.”
• “I need to refactor this component to get this to work.”

None of these are things that are completely stopping you from working. But they are going to take up a considerable portion of your time.

This is what your tech lead wants to hear. It’s their best opportunity to do their job, to help speed you up and come up with solutions to your trickiest problems.

An important note about red flags: you should always maintain clear responsibility for your project as you state your red flag. You shouldn’t be in the habit of using red flags as an excuse for not getting your work done.

Most people want to sound impressive during their standup. They want to say, “Look at all this stuff I got done yesterday! Look at how awesome I am.” Resist that temptation, and instead focus on how you can accelerate the work ahead.

2. Between meetings, communicate proactively

When you’re working as a team lead or tech lead, you have this constant paranoia that your team is completely stuck and you don’t know it.

You come into your team’s work pod, and everyone’s at their desk. But what are they doing? Are they making good progress? Are they spending their time implementing something the completely wrong way? It’s hard to tell.

And of course, the tech lead absolutely must have a trusting relationship with their team. They can’t let this paranoia control their behavior at all times. So they end up not asking.

This is your opportunity to meet one of your tech lead’s needs. You should proactively communicate about what you’re doing at least twice per day.

What do I mean by proactive communication? I mean any conversation that’s initiated by you. Check-ins started by your tech lead and scheduled meetings don’t count as proactive.

Examples of ways to kick of proactive communication:

• Sending a Slack message
• Commenting on an Asana task that they’re following
• Catching them as they come back to their desk

Proactive communication sometimes takes the form of asking for help. “I can’t get this module to import and I don’t know what’s wrong. Can you help?” These are opportunities for the tech lead to do their job, and if you’re truly blocked then it’s time well spent.

The other form proactive communication can take is a checkpoint. Something like, “I’m working on this feature, and I’m finding that I’ll need to hoist this state up all the way to the root component for it to work. Let me know if you want to discuss this.” This is a great way to surface potential architectural disagreements. Stop waiting for code review before talking about this stuff, seriously.

Proactive communication seems easy. In practice everyone hesitates before “bothering” someone else with this kind of communication. Try adding a daily task to your to-do list to proactively communicate, and you’ll see what I mean.

Like all communication patterns, it’s worth your time to have an open discussion with your tech lead on their preferences. Do they hate Slack? How many status updates per day is too many? Did your communication over the past week benefit the team or not?

3. During technical discussions, repeat and summarize

It’s important that you and your tech lead have at least some alignment around the technical decisions you’re making. Your opportunity for making this alignment happen is technical conversations.

Technical conversations might look like your tech lead sitting down with you to kick off a new project. Your tech lead has some initial thoughts on how it could be implemented, and they’re sharing them with you.

Often, your tech lead might have more historical context than you on the system that’s changing. So they’ll probably say at least one thing that makes you go “huh?”

Your tech lead knows this. But they don’t know which things they’re saying are going to make you go “huh?” unless you actually say “huh?”

Always clarify both what you do and don’t find confusing. Rather than saying “I’m lost,” clarify “I understand X, but I don’t understand Y.”

Ultimately, you want your tech lead to walk away from the conversation with a lot of confidence that you heard and understood what they had to say. A lot of people try to achieve this by smiling and nodding. That has the opposite effect.

Instead of smiling and nodding when you understand, repeat and summarize what you heard.

For example:

“Got it. What I’m hearing is, I should calculate this value on the server to reduce roundtrips, and send it down to the client during page load.”

This pretty much proves to your tech lead that you were listening to them. And it actually forces you to listen better.

When trying this out, you’re going to resist at first. It kind of feels like you’re being bossy and interruptive. It also kind of feels like you’re just patronizingly copying what they say.

Don’t let that stop you. Think about how the tech lead will feel. I can tell you that it’s a real relief to see the other person take the initiative to repeat and summarize.

These summaries are usually action items. Your next step should be to write them down somewhere. Put them somewhere that your tech lead can see them and provide corrections if you’re wrong.

Be a super collaborator

Tech leads want to work with engineers who take responsibility. This can be hard to do on a technical level if you’re not familiar with the systems that you’re working with.

But what you can take responsibility for is how you communicate about your work. Think about how you can shift your communication patterns with your tech lead, and you’ll easily discover powerful new habits to build.

If you’re passionate about helping teams collaborate effectively, you should work with me at Asana.