Skip to main content

Engineering Superpower - đź“ť Notetaker

Problem: You're Missing Critical Info (and You Don’t Even Know It)​

Being bad at capturing requirements doesn’t look like incompetence, it looks like surprise.

You’re working through a feature. You’re mid-PR, or you’ve just demoed a working version. Then someone gives you a bunch of “new” feedback. You feel blindsided—"Why didn't anyone tell me this before?"

Here’s the hard truth: they probably did tell you, but you just didn’t take it in.

This is one of the most damaging and unseen weaknesses early-career engineers struggle with—especially in early-stage startups, where there’s often no product manager or dedicated spec-writer. You’ll get input verbally, over Slack, in passing conversations, and sprinkled across Notion, Figma, and Zoom calls. You’ll think you understood the requirements, but what you really captured was a loose vibe.

And the symptoms compound:

  • You’re constantly surprised by “last-minute changes.”
  • You reimplement features after every demo.
  • You have vague memories of key decisions—“I swear they said something about this…”
  • You feel like everyone else is a step ahead in understanding what’s going on.

If this feels familiar, you’re not alone—but it’s a problem worth doubling down on.

Solution: Become a Ruthless Notetaker​

If you don’t have a photographic memory, the next best thing is a good system.

One of the most underrated engineering "superpowers" is knowing how to capture requirements in real time. Not just the what, but the why, how, and any edge cases or side comments that might influence the work. Early-stage engineers who do this well stand out fast—they move with clarity, deliver with fewer cycles, and earn trust quickly.

Here’s a simple template I encourage engineers to use during meetings, huddles, or anytime work is being scoped:

📄 Requirements Capture Template​

  • Goal / Problem
    What are we trying to solve?

  • Users
    Who is affected by this?

  • Scope
    What’s in, what’s out?

  • Edge Cases
    What could go wrong or behave unexpectedly?

  • Dependencies
    What systems, services, or teams does this touch?

  • Technical Requirements
    Any specific implementation details, constraints, or design patterns?

  • Success Criteria
    How do we know this is done? What does "done" look like?

  • Questions / Unknowns
    What’s still unclear or needs follow-up?

Copy it into a Notion page, a Markdown doc, or the comments section of your Jira ticket. What matters is not the format—it’s the habit.

If you’re not naturally good at this, make it your personal focus for a month. Ask yourself after every meeting: Did I write down what we actually decided? If you’re getting feedback that feels like a surprise, look inward first. Your job isn’t just to write code—it’s to build the right thing.

Start by listening better. Then start writing it down. It should go without saying, the best notes are only useful if you're referring back to them before you submit your PR for review.