Building authority while employed at a big company
The senior PM playbook for publishing under your real name while employed at a big company. What is safe, what is not, and the four rules I follow before every post.
There is a version of the senior PM career where you keep your head down for twenty years, ship, get promoted, and no one outside the org knows your name. That version still works. It is quieter than it used to be.
There is another version where you build a public track record while you are employed. A newsletter, a talk, a repo, a thread that goes farther than you expected. The compounding is real. So is the risk of doing it badly.
I am nine weeks into writing this newsletter under my real name while employed at a big company. Long enough to have made the small mistakes but short enough that I still remember what they felt like. Here is the playbook I am running.
Why do this at all
Three reasons.
First, leverage. The single hardest thing about senior PM careers is that most of the signal you generate is trapped inside the company. Internal docs, internal reviews, internal decisions. If you leave, most of that evidence does not travel. A public body of work is a portable resume that also makes the internal one better.
Second, thinking. Writing forces the argument to be clean. I have caught more sloppy reasoning in my own head by trying to explain it to strangers than I ever caught in a spec review. The newsletter is a forcing function for a clarity of thought that the day job rewards but rarely demands.
Third, optionality. The market for senior PMs is bifurcating. On one side, people known for a specific point of view. On the other side, people known for a specific title at a specific company. The first group has more doors. Building the first version of yourself while you have the second is cheap insurance.
What the risk actually is
The risk is not that a VP reads your post and gets angry. Most VPs do not read newsletters. The risk is more specific.
You accidentally publish something that reads as a competitor pitch.
You describe an internal process in enough detail that a security or PR team asks who authorized the disclosure.
You take a stance in public that contradicts a stance your team is about to take, and now your team looks incoherent.
You develop a public voice that is materially more interesting than your internal one, and eventually someone asks why.
Notice that none of these are catastrophic. They are correctable. But they are all easier to prevent than to unwind, which is the whole point of having rules.
The four rules
Rule 1. Write about the craft, not the product.
The safest topics are the ones about how you think, not about what you ship. How I run a spec review. How I decide when to say no. What I look for in a launch. These pieces reveal the operator without revealing the operation. They are also, not coincidentally, the pieces that build authority fastest, because they are the pieces a reader can actually use.
Product specifics are where the trouble starts. Unlaunched features, roadmap intent, internal metrics, customer names, deal shapes. Anything a competitor could use, anything a customer could feel exposed by, anything a lawyer would want to review. That is not the same as “never mention what you work on.” It is fine to say what team you are on. It is fine to say what problem space you think about. It is not fine to describe a decision that has not been made externally yet.
Rule 2. If you would not say it in an all-hands, do not put it in the newsletter.
This is the single rule that has saved me the most. If I would not raise my hand at a company-wide meeting and say the exact sentence, it does not go in the post. Not because all-hands are the ceiling of what is acceptable, but because the audience is the same: employees, customers, partners, and people who wish they were any of the three. Public writing has the same reach with less context.
The rule is not that the newsletter has to be corporate. Mine is not. The rule is that the version of me writing the newsletter has to be recognizable as the same person who shows up at work. If I would not defend a sentence in front of my manager and my team lead in the same room, I do not want it in print.
Rule 3. Publish about the past, not the present.
The riskiest posts are about work you are doing right now. The safest are about work you did months or years ago, at a level of abstraction that a reader can generalize. This is a hard rule to hold because the present is where the good material is. But the present is also where the confidentiality is thickest, the framing is least settled, and the risk of contradicting an as-yet-unannounced position is highest.
The workaround is to lag. I let ideas sit for weeks before I publish them. By the time a post ships, whatever proprietary edge it had is gone or public. What is left is the reasoning, which is the part worth publishing anyway.
Rule 4. The “views are my own” line is not a shield. Behave as if it did not exist.
Every senior PM who publishes under their real name uses some version of the disclaimer. It is polite. It is professional. It is not, functionally, protection. If a post causes a problem at work, the disclaimer will not save the conversation. It will just make the conversation slightly shorter.
The right posture is to write posts you would defend without the disclaimer. The disclaimer stays because it is a norm, not because it is doing work.
The mechanics I actually use
A few concrete practices, in case they are useful.
A four-eyes rule for anything ambiguous. If I am not sure whether a paragraph crosses a line, I ask a peer I trust to read it before it ships. Not to get a formal approval. Just to check whether the read from outside my head matches the read from inside it.
A “delete this sentence” test. Before I hit publish, I look at the piece and ask which single sentence would cost the most if it were quoted back to me in an unfriendly context. Then I ask whether that sentence is doing enough work to justify the cost. Usually the answer is no, and it gets cut.
A weekly cadence, not a daily one. Daily publishing at a big company is a way to eventually publish something you regret. Weekly gives time for the “would I still write this in three days” filter.
Real name, no anon. Anonymous accounts feel safer and are actually riskier. The moment you are outed, every piece of the archive gets re-read in a hostile frame. Publishing under your real name from day one forces the discipline the anon account lets you skip.
What I have not done
I want to be honest about the moves I am deliberately not making, because a playbook without omissions is not a playbook.
I have not filed an Outside Activities Approval. My current writing is analysis and opinion, not paid work or consulting, and my read is that it does not require one. If the writing ever generates income, or if I take on paid speaking, that changes and I file first.
I have not built an audience play around the company brand. I do not want the newsletter to succeed because of where I work. If it does, the audience is not really mine.
I have not done a launch post about my current team or product. Some day I might. It would be a specific choice, cleared through the right internal channels, not a default.
Why this matters more than it used to
Ten years ago, a senior PM at a big company could be visible or invisible, and the market would treat both roughly the same at hiring time. That is not the market anymore. The bar for “senior IC PM at a top-tier company” has enough people at it that the differentiation is starting to happen outside the company, not inside. That does not mean everyone needs to be public. It does mean that the option value of being public is going up.
The playbook above is not the only way to do this. It is the way I am doing it. If you are in a similar spot, I hope some of it is useful. If you are not, and you are thinking about starting, my suggestion is to write the first three pieces in a private doc before you publish anything, so you can see whether the voice holds up when nothing is at stake.
That is the piece for this week. Next week: the PM job description in eighteen months, and what I think will actually be on it.
If this was useful
Forward it to a senior PM who is thinking about writing in public. That is the whole distribution engine at this stage.
Luiz