From engineer to manager
Your first management book will tell you the job is delegation, feedback, and one-on-ones. Those are the visible parts, and you'll get coaching on them. The part nobody schedules a training for is the one that quietly runs underneath all of it: you now have to carry an evolving understanding of several people at once, and hold it steady over months.
As an engineer you carried state too, but it lived outside your head. The code was in the repo, the decisions in the tracker, the design in a doc. When you forgot a detail, you reopened the file. The read you now keep on each person you manage (how they work, what they're good at, where they're stuck, what's shifted lately) has no repo. It lives in memory, and memory is the wrong storage for it.
The job that has no file to reopen
Think about what you actually hold about one report: a sense of how they handle ambiguity, a hunch about what's been weighing on them, a half-formed theory about why their last project stalled, a note-to-self to check whether that rough patch in spring ever resolved. Now hold that for six or eight people, keep it current as it all changes week to week, and have it ready the day a review or a promotion case or a hard conversation asks for it.
You can't, not from memory. What happens instead is that the read on each person collapses to the last few weeks, because that's what recall serves up first, and the earlier months go soft. You end up reconstructing the arc of someone's year out of whatever you can still see, which is mostly recent, and calling it the whole picture. It's a documented effect, not a personal failing; it just lands harder in management, because the list you're trying to recall is people.
The move that helps
Put the read somewhere it can accumulate. Not the meeting notes; those hold what was said, not the model underneath. The read itself: what you believe about how someone works, written as a plain sentence you could later find you were wrong about. "Priya does her sharpest work when the goal is fixed and the method is hers." Say how sure you are in plain words rather than a number, because a number on a person is a false kind of precision. Note what you notice when you notice it, and when your read shifts, change it on the record and keep the old version underneath. The day-to-day version of this is its own guide.
None of that is a performance file, and it isn't scoring anyone. It's the opposite of a verdict: an opinion, held lightly, with the date on it, that you're free to revise the moment you learn more. Which, when you're new and still forming most of your reads, is constantly.
Why write down something you "already know"
Because you don't already know it, not reliably, and the moments that prove it are the expensive ones. The review where you can vividly account for October and grope for March. The skip-level where your boss asks how someone's really doing and you realize your answer is three weeks old. The promotion case you have to argue from a feeling, because the evidence has faded. Writing the read down is cheap insurance against being caught reconstructing your own judgment under time pressure, which is the specific anxiety of a first management year.
It's also, quietly, fairer. A read you keep only in your head gets no correction; nobody audits it, including you. A read on the record can be shown to be wrong and then changed. Put next to each other, the second is the one you'd want someone keeping about you.
Full disclosure: I make Continuum, a Mac app for holding this read as you make the switch. You write a belief about someone as a sentence and revise it as you learn, with every earlier version kept; you tag what you notice in a one-on-one and those notes update the belief they touch; and it opens on the people you haven't written about in a while, so a quiet report doesn't fade out of view. It never scores anyone, and nothing leaves your Mac. It's free for up to three people, which is most of a first team, and Pro is a one-time purchase if you'd rather not subscribe.