First Job Out of College

What to Actually Say in Your First 1:1 With a New Manager

Mike Halpert — Sat, 11 Jul 2026 00:00:00 GMT

Your first 1:1 with a new manager is not an intro chat. It is a calibration interview.

If you spend 22 minutes on weekend plans, your background, and "happy to be here," you will leave with the exact thing you did not need: good vibes and no operating rules.

That is how people end up guessing for a month.

What this meeting is actually for

Your manager is trying to answer a boring but important question: will working with you make their week easier or harder?

That sounds harsh. It is also the game.

Good first 1:1s answer that question fast. Bad ones stay abstract. You ask about the team, they say everyone is great, you say you are excited to learn, and both of you leave with nothing you can use on Tuesday morning.

The first meeting is where you learn four things: what good looks like, how they want updates, how early they want risk, and how feedback is going to show up before review season.

1:1s are partly therapy, partly chess. Mostly chess.

Here is the move

Do not bring your whole life story. Bring one short context paragraph and a few calibration questions.

Yes, this feels a little corporate. Do it anyway. The first 1:1 is not where you prove you are low-maintenance. It is where you learn how not to become maintenance.

:::template{title="First 1:1 with a new manager: the calibration script"} Open "I want to make sure I work with you in the way that makes your life easiest. Can I ask a few calibration questions?"

Self-context "For context, I currently own [workstream], I am ramping on [system or process], and the thing I am least sure about is [dependency or area]. My goal this month is to become useful fast without creating surprise work for you."

Success "Thirty days from now, what would make you feel like I am ramping well?"

Communication "When something is on track, what level of update do you want from me? And when something is at risk, how early do you want to know?"

Decisions "When I bring you a decision, do you prefer a recommendation first or options first?"

Feedback "What is the best way for me to get quick feedback before something becomes a review-season surprise?"

Close "I will send back what I heard so we have the operating rules in writing." :::

If the conversation is flowing, ask all four. If your manager is brief, ask the success question, the risk question, and get out.

Why these lines work

"What are your expectations?" sounds mature and gets you almost nothing back.

Most managers will answer with fog: be proactive, communicate well, take ownership. Fine. None of that tells you what they will actually reward in the next 30 days.

"What would make you feel like I am ramping well?" forces a real answer. A clean handoff. Faster ticket closure. Better stakeholder updates. Fewer surprises. Now you have a target.

The risk question matters because managers vary a lot here. Some want smoke. Some only want fire. If you learn that after a project slips, you learned it too late.

The decision question saves a different kind of pain. Some managers want options. Some want a recommendation. If you bring the wrong format every week, they start reading you as high-effort and low-help.

I have gotten this wrong before. I thought sounding thorough would make me look prepared. It mostly made me sound like I needed supervision.

The part most people skip

Send the recap the same day.

Not a long memo. Five bullets. That is the first useful artifact in the relationship.

What success looks like in the next 30 days
What kind of updates they want
How early they want to hear about risk
Whether they want recommendations or options
How feedback should happen

That recap is what turns the meeting into something real. If you want the ongoing version after this first meeting, use the manager 1:1 agenda. If you are still learning how your boss thinks, reading your manager is the next layer. If you need a recurring document, steal the first 1:1 agenda template.

If the meeting is weird

If your manager is new too, ask what would be useful for you to summarize each week while they learn the team.

If they hate structure, keep the questions conversational and send the recap afterward.

If you are working in a US office and this level of directness feels rude, frame everything around usefulness. "I want to make sure I am giving you the right level of visibility" lands better than "How do you manage?"

—

I still think this script feels slightly stiff on paper. In the room, it reads as relief. Most managers are dying for someone to make the expectations legible. Be that person.

Burnout Early Career: The 5 Warning Signs You Shouldn’t Ignore

Mike Halpert — Wed, 24 Jun 2026 00:00:00 GMT

Burnout early career rarely arrives as a dramatic collapse.

It looks like a hard week. Then another hard week. Then a Tuesday afternoon where a normal email makes you want to close your laptop and stare at the wall.

That is the dangerous part. You can explain away a lot when you are new.

You are still learning the company. You are still trying to prove you belong. You are still afraid that saying "I am at capacity" will sound like "I am not cut out for this."

But burnout is not private for very long. Eventually your work starts reporting it for you.

A hard week recovers. Burnout does not.

A hard week makes you tired. Burnout makes recovery stop working.

If you work late for three nights, sleep hard on Saturday, and feel human again on Monday, that is stress. Annoying, but normal.

If you sleep, take a day off, avoid Slack, and still come back with the same dead battery, something else is happening.

The World Health Organization defines burnout as a workplace phenomenon tied to chronic work stress that has not been successfully managed. The shape is simple: exhaustion, mental distance from the job, and reduced effectiveness.

That last part matters at work. Your manager may not see the exhaustion. They will see the reduced effectiveness.

I learned a version of this the hard way at Walmart. I walked into a performance review proud of all the stakeholder work, context gathering, and strategic thinking I had done on a project. My manager agreed the work was useful, then rated me average because the project had not shipped and had not moved anything measurable.

From my side of the table, I had been working hard. From the manager's side, the useful signal was missing.

That is why early burnout is worth catching before it becomes visible through missed details, slower delivery, and weirdly flat energy.

The five warning signs

These are not medical diagnoses. If this overlaps with depression, anxiety, or anything that feels bigger than work, talk to a professional. A blog post is not a doctor.

For the work version, look for five signals.

1. Cynicism replaces curiosity.

You used to ask, "What are we trying to solve?" Now every new project lands as, "This is stupid." You might even be right. Offices do produce plenty of stupid work.

But when contempt becomes your default setting, pay attention. Your brain may be trying to protect you by detaching from work it no longer believes will pay you back.

2. Sunday dread leaks into the week.

Sunday night anxiety is a boring corporate ritual. Tuesday dread is different.

If the "I cannot do this" feeling shows up during normal work hours, not just before the week starts, your recovery window is shrinking. You are not resetting. You are waiting for the next hit.

3. Basic work gets strangely hard.

You forget the attachment. You miss the obvious typo. You reread the same Slack message four times. You stare at a spreadsheet you could normally fix in twenty minutes.

This is the sign that scares high performers because it feels like you are getting worse at your job. You are probably not getting worse. Your system is overloaded.

4. You avoid people you actually like.

You skip the harmless banter. You bail on the coffee walk. You watch a teammate type "quick question" and feel irritation before you even know the question.

Yes, coworker small talk can be a tax. But if everyone starts feeling like another demand, your social battery is not just low. It is defending itself.

5. Rest stops counting.

This is the cleanest test.

You take Friday off. You sleep. You do the responsible adult recovery routine. Monday arrives and nothing has changed.

If rest does not result in feeling rested, you are not dealing with a normal hard week anymore.

Run the signal check before you talk yourself out of it

Yes, "capacity risk" sounds like something a consultant says after three coffees. Use it anyway. It is less dramatic than "I am dying over here," and much more useful to your manager.

Start by making the problem concrete.

:::template{title="Burnout signal check"}

Recovery: Did real rest help, or did I come back just as depleted?
Quality: Am I making mistakes that are unusual for me?
Dread: Has the Sunday feeling started showing up on normal weekdays?
People: Am I avoiding people I normally like working with?
Commitment: Is my current workload making one important deliverable less reliable? :::

If you check one box, watch it.

If you check two, adjust something this week.

If you check three or more, do not wait for your work quality to become the evidence.

What to say to your manager

The mistake is walking into a 1:1 and saying, "I think I am burned out," then hoping your manager translates that into a work plan.

Some managers will. Many will not.

Give them the operating version instead: what is on your plate, what is starting to slip, and what trade needs to happen.

I want to flag a capacity risk before it turns into a quality issue.

Right now I am carrying:
- [Project or deliverable A]
- [Project or deliverable B]
- [Project or deliverable C]

The thing starting to slip is [specific signal: timeline, accuracy, responsiveness, review quality, focus time].

To keep the quality high, I think we need to either move [specific item] to [later date] or narrow [specific scope].

Which trade would you rather make?

That last question does the work.

You are not asking your manager to rescue your mood. You are asking them to make a prioritization decision. That is their job.

This is the same muscle I write about in workload triage: every yes is a no to something already on your plate. If you do not surface the trade, the trade still happens. It just happens silently, usually against the work that matters most.

When the script is not enough

Some teams run hot for a week. Fine. Every job has those weeks.

Some workplaces use burnout as a business model. Different problem.

If the culture rewards constant hero hours, punishes honest prioritization, and treats recovery like weakness, a better script may buy you time but it will not fix the system.

And if your symptoms feel bigger than work, treat them that way. Mental Health America has a useful plain-English burnout overview, but the important line is this: burnout can overlap with mental health issues. Do not force a workplace explanation onto something that needs real support.

Catch the smoke

The goal is not to become the person with perfect boundaries and a color-coded recovery routine.

The goal is simpler: catch the smoke before your work catches fire.

I still get this wrong when I am tired or trying to prove a point to nobody in particular. The move is not heroic. It is boring and useful: name the signal, name the trade, ask for the decision.

That is how you stay good long enough for the job to matter.

Turning a Fuzzy Career Goal Into a 12-Week Action Plan

Mike Halpert — Tue, 09 Jun 2026 00:00:00 GMT

At some point in your first real job, a form or a manager will ask for your career goals, and your brain will serve up one of three useless phrases:

"Be more strategic."

"Get promoted."

"Improve communication."

Those are not bad goals. They are unfinished goals.

A 12-week career plan works because it forces the next question: what proof will exist 12 weeks from now that did not exist today? Yes, this is corporate-roleplay. Do it anyway.

That is the part most career-planning advice skips. The sentence is easy. The hard part is turning a vague ambition into evidence someone can see, use, or react to.

A goal without proof becomes theater

I once walked into a performance review proud of how much work I had done on a strategic project. I had talked to stakeholders. I had gathered input. I had done the alignment work. From inside the project, it felt productive and fairly senior.

My manager saw it differently.

The work was useful, but the project had not shipped. It had not moved a metric. It had not gotten users onto it. The rating was average.

That one stung because both versions were true. I had done real work. I had also failed to leave enough visible proof.

That is the danger with fuzzy career goals. "Be more strategic" can turn into three months of reading, coffee chats, internal docs, and thoughtful notes that never become something your manager can point to. Visibility without self-promotion is part of the same problem: if nobody can see the work, it might as well be vapor.

Effort matters. But effort that leaves no evidence is hard to defend in a review.

The better move is to make the proof artifact the center of the plan.

Translate the fuzzy goal into a work outcome

Start with the phrase you would normally write in the HR system.

Then ask, "What would this let me do at work?"

Not what would make you feel more adult. Not what sounds impressive. What would change in the work?

"Be more strategic" might become:

"I can write a one-page recommendation that frames the tradeoff, names the customer impact, and helps my manager make a decision."

"Improve communication" might become:

"My weekly update gives my manager the status, risk, and decision needed without a follow-up Slack."

"Get promoted" might become:

"I can independently own one recurring deliverable and show before/after evidence that it improved."

Now you have something to build.

The book's job-goals chapter makes this point in a broader way: your goals need to connect to the company's goals, your team's objectives, and the way your work is measured. In other words, your career plan cannot live entirely inside your head. If it does not help the team win, your manager has very little reason to care.

If the part you're stuck on is the ask, how to tell your manager what you want without sounding ungrateful is the next click.

Use 12 weeks because it is hard to fake

Annual career planning invites fantasy.

Five-year planning invites fan fiction.

Twelve weeks is annoying in the right way. It is long enough to ship something and short enough that you cannot hide behind "still developing."

You do not need to redesign your entire career. You need one cycle of evidence.

For a new grad, that might be:

A cleaner weekly update format your manager keeps using.
A dashboard people trust instead of a spreadsheet people complain about.
A meeting recap template that stops decisions from getting lost.
A small process fix that saves the team repeat questions.
A before/after writing sample that shows your communication got sharper.

Notice what all of those have in common. They are not vibes. They are artifacts.

An artifact is something another person can inspect. A memo. A dashboard. A template. A recurring report. A client-ready document. A cleaned-up process. A feedback trail.

If your 12-week plan does not produce an artifact, it is probably too vague.

Copy this 12-week plan

Here's the move: write the proof first, then work backward.

12-week career goal plan

Fuzzy goal:
[Be more strategic / improve communication / get promoted / become more visible / figure out what I want]

What this would let me do at work:
[Specific work outcome this goal should support]

12-week proof artifact:
By [date], I will produce:
[memo, dashboard, template, process fix, stakeholder recap, before/after work sample, project result]

Weekly rep:
Every week, I will:
[small repeatable action that builds the artifact]

Who needs to see it:
[manager, senior peer, project lead, stakeholder, mentor]

Manager ask:
"If I produced this by [date], would it be useful evidence of [goal]? If not, what would be stronger?"

Risk that could make this fake:
[too private, too broad, not tied to team goals, no evaluator, too much extra work]

Review date:
[date 12 weeks from now]

The most important line is the manager ask.

Your manager cannot calibrate a vibe. They can calibrate an artifact.

If you bring them "I want to be more strategic," they may nod and say something encouraging. If you bring them "I want to write one decision memo by August 30 that frames the customer tradeoff and gets used in the roadmap discussion," now they can react.

They can say yes.

They can say no.

They can say, "Close, but the better proof would be presenting the recommendation in the product review."

All three answers are useful.

How to write a status update your manager actually reads sits right next to this. A good status update is one of the easiest proof artifacts to make visible without turning your job into a performance art project.

Separate reps from proof

A common mistake is confusing the weekly rep with the result.

"Have three coffee chats" is a rep.

"Create a one-page map of how decisions get made on this team, reviewed by my manager" is proof.

"Take a presentation course" is a rep.

"Deliver the Q3 project readout with one round of feedback from a senior peer" is proof.

"Read about strategy" is a rep.

"Write a recommendation memo that compares two options and gets used in a decision meeting" is proof.

Reps are how you practice. Proof is what remains.

You need both. But in a review, proof travels better.

This matters even more on remote teams. Hallway reputation is weaker. Written evidence carries more weight. A clean artifact, a weekly update, and a manager check-in make your growth easier to see.

When this plan does not apply cleanly

If you are in your first 30 days, keep the plan small. Your proof artifact might be a map of team goals, a cleaned-up onboarding note, or one finished task. Do not invent self-directed scope before you understand the room.

If your company promotes once a year, a 12-week plan will not force the title change. Treat it as evidence-building for the next conversation, not a magic lever.

If your manager is absent or checked out, find another calibration source: a senior peer, project lead, mentor outside your reporting line, or the written leveling rubric. Do not rely on private certainty.

If you are burned out, shrink the weekly rep. A plan that needs five extra hours every week is probably too big. The best career plan is the one that survives a normal work week.

For foreign professionals, this may feel unusually explicit. Some workplaces rely more on tenure or seniority. Many US offices expect you to name goals, show evidence, and ask for feedback before the formal review. That does not mean you need to brag. It means your work needs a paper trail.

The move

The cleanest version is simple: one goal, one proof artifact, one check-in. That's the whole game.

Your five-year goal can stay a little fuzzy.

The next 12 weeks should not.

The One-Page Memo Template That Makes You Look Senior

Mike Halpert — Sat, 06 Jun 2026 00:00:00 GMT

The first time I sent my manager a five-page doc and got back "lgtm," I thought he hadn't read it. He had. He'd read enough to know I hadn't told him what to do.

That's what "looks good to me" usually means. Not "I read this carefully and agree." It means "I don't see anything I have to push back on, and I'm not going to do your job for you and find the question buried on page three."

If you've gotten "lgtm" with no comments, no follow-ups, no decision, your memo didn't fail to convince anyone. It just took up space.

The misunderstanding behind every long memo

First-year professionals treat the memo as a record of their thinking. The doc proves they did the work. Every consideration, every option, every footnote, in the body, in order, so the reader can see the path.

Seniors treat the memo as a forcing function for the reader. The doc isn't proof of effort. It's a request for a specific decision, written so the reader can say yes or no in 90 seconds.

Same Google Doc. Completely different job.

You can tell which version someone wrote in the first line. "Here's an update on the Q2 forecast project, including methodology, key assumptions, and proposed next steps" is a record. "Recommend: ship the Q2 forecast on the updated assumptions; risk is one missed scenario, mitigation below" is a decision request.

The first one earns "lgtm." The second one earns either a yes or a sharp question. Either is better than silence.

A scar from earlier in my career

Early in my career I sat through a performance review at a Fortune 1 retailer where I was, on paper, having a great year. I'd run stakeholder interviews. I'd synthesized exec input into a strategy framing. I'd built decks. I'd built docs.

The review came back average.

I asked why. The answer was something like: "You did a lot of thinking. Nothing shipped. No metric moved. No user touched the thing."

It stung because it was right. The artifacts I was proudest of were the artifacts that documented effort, not the ones that drove a decision. The deck looked like work. It wasn't the work.

I think about that review every time I'm tempted to add another section to a memo. A four-page doc lets you hide inside your own thinking. A one-pager forces you to convert effort into a question. Questions are what get answered.

The template

This is the version I use now. Steal it. Adjust the headers to match your company's voice if needed, but keep the order.

TITLE: [Decision needed in 8 words or less]

To:        [Decider's name]
CC:        [Anyone whose objection could block this]
From:      [You]
Date:      [Today]
Decision needed by: [Specific date — not "ASAP"]

RECOMMENDATION
[One sentence. What you want them to say yes to.]

WHY
- [Reason 1 — the strongest one]
- [Reason 2]
- [Reason 3 — stop here]

ALTERNATIVES CONSIDERED
- [Option B]: [why not, one line]
- [Option C]: [why not, one line]

KEY RISK + MITIGATION
[The biggest thing that could go wrong, and what you'll do about it.]

WHAT I NEED FROM YOU
[Specific action: approve, reject, ask one question, forward to X.
 Not "let me know your thoughts."]

APPENDIX
[Everything else. Methodology, raw numbers, alternate scenarios,
 the spreadsheet, the Figma link, the Slack screenshots, the
 background reading. The body of the doc points here. The reader
 only opens it if they want to.]

That's the whole thing. Two-thirds of a page if you're verbose. Half a page if you're disciplined.

What's missing on purpose: a "Background" section. An "Objectives" section. A "Next Steps" section that restates the recommendation. None of those help the decider decide. They help the writer feel thorough.

The pre-read script

The template only works if the reader sees it before the meeting. A memo handed across the table at the start of a meeting is a deck in disguise. You'll end up walking them through it instead of letting them read it.

Send this 24 hours before, or at minimum the night before:

Subject: Pre-read for tomorrow — [decision needed in 8 words]

Hi [Name],

For our 2pm tomorrow, here's the one-pager on
[topic]: [link].

The ask is on line 1. If you can read it before we meet,
we can spend the meeting on the risk section instead of
the background. If something on the page is a non-starter
for you, a quick reply is fine and I'll regroup.

Thanks,
[You]

That message does three things. It tells the reader where the ask lives. It signals you respect the way they actually work — skim on a phone, mark up in comments. And it gives them an explicit out. They can kill it in writing without a meeting, which is the kindest outcome for everyone when the answer is no.

Yes, sending a pre-read 24 hours early feels like LinkedIn-influencer behavior the first time you do it. Send it anyway. The first time a director replies "looks fine, we can skip the meeting" you'll never go back.

Why one page is a thinking constraint, not a writing constraint

People hear "one page" and think it's a stylistic preference, like double-spacing or sentence case. It isn't. The page limit is the discipline.

If your memo runs to two pages, it's not because the topic is too big. It's because you haven't decided which of your three recommendations is actually the recommendation. You're hedging by including all of them. The reader can tell.

The senior move is the subtractive pass. Write the four-page version first if you need to. Then cut. Cut the "Background" section. Cut the recommendations that aren't the recommendation. Cut the section where you list the things the reader already knows.

If after cutting you still can't fit on a page, you don't understand the problem yet. That's useful information. Stop writing and go think for an hour.

What goes in the appendix

Anything you'd defend in a meeting goes in the appendix. The methodology. The raw spreadsheet. The full list of alternatives you considered before narrowing to two. The screenshots, the customer quotes, the legal review.

The page-one line that points to it ("see appendix for methodology") is the line that signals seniority. It says: I did the work. I'm not going to make you read all of it. Ask if you want to dig in.

The fix isn't to pre-empt every question on the front page. The fix is to know the appendix cold so you can flip to it in real time.

When this doesn't fit

The template is built for a reversible-but-expensive decision with two or more stakeholders. That's most of what you'll write memos for in the first five years.

Two exceptions. In a Slack-first startup of under thirty people, a one-pager reads as overkill for routine asks — use it when the decision is hard to reverse or when more than two people have to agree. In regulated industries (healthcare, finance, legal), the memo lives on top of whatever compliance document policy already requires. It's a cover sheet, not a replacement.

The manager who graded me average wasn't being harsh. He was being literal. The doc looked like work. It wasn't asking him for anything. The one-pager fixes the same bug — it converts effort into a question. Questions are what get answered.

Reading Your Manager: How to Tell If They Want Detail or a Headline

Mike Halpert — Wed, 13 May 2026 00:00:00 GMT

The biggest reason junior updates land flat isn't the writing. It's that the writer was solving for being thorough when the manager wanted being useful. The five-paragraph slack message during a calendar crunch. The one-line answer in a 30-minute 1:1 with a manager who actually had time to think. Both feel like "I delivered an update." Only one matched the room.

This is the skill nobody teaches you, and it might be the single highest-leverage move in your first eighteen months on the job. Get it right and you become the person whose updates everyone trusts. Get it wrong consistently and you become a tax on your manager's attention. Yes, this feels a little like surveillance. Read your manager anyway.

What you're actually doing

Your manager has limited working memory and a long line of people asking for it. When you bring them an update, you're not delivering information into a void. You're asking for a slice of their attention, and the appropriate size of that slice depends on what they're about to do with it. Brief my boss in twenty minutes needs a sentence they can use. Help me think through whether this approach is right needs the unfiltered raw. Same project, same person, different ask. Reading the difference is the skill.

What the manager is trying to do

Three things in tension at any moment. They want a signal they can act on. They want material for the next conversation they're walking into. And, especially in your first six months, they're calibrating how much they trust your judgment with every interaction. Does the bottom line come out of this person, or do I have to drag it out, or do I have to filter through filler? You're not paranoid for noticing this. It's just what management is.

What good looks like

You walk into a 1:1 with thirty minutes blocked. You open with one sentence: "On the Q3 launch, want the headline or want to dig in?" They tell you. You deliver the right shape and the meeting works. Or it's 4:40 on a Friday. You DM: "Quick one, copy review is at risk for Monday, fixing it first thing, just FYI." They thumbs-up it and close the laptop. They got the signal, they didn't get a wall.

What bad looks like

Five paragraphs in slack when the manager asked "how's it going." A one-sentence answer in a 1:1 followed by ten seconds of silence. Burying the headline three paragraphs in, so the manager reads the first line, decides it isn't urgent, and now your work is in the queue behind their inbox instead of on their radar. Half a 1:1 spent catching them up on context they already had. None of these feel like failures while you're doing them. All of them are.

Four signals to read before any update

The calendar signal. Five minutes in a corridor or a DM, headline. Always. A 30-minute dedicated 1:1, they have time and intention to think — bring the detail. Five minutes before a leadership meeting, they want a ready-to-use line. End of day Friday, headline. They are tired.

The explicit instruction signal. Most managers won't tell you how they want to be updated. The good ones will. If your manager has said "give me the punchline first, I'll ask for detail if I need it," that's a literal instruction, not a polite suggestion. Honor it for six months minimum, even when you think the detail would help. It usually wouldn't.

The audience signal. Listen for what they're going to do with the update. "I need to brief my manager on this" means headline, framed in a sentence they could paste straight into a Slack message. "I'm trying to figure out if we should pivot" means detail, with tradeoffs. "Just curious where we are" means headline plus one or two specifics, no more.

The energy signal. Some managers, on some days, want to think. They lean in, they ask second-order questions, they pull up the doc. Other days, the same manager wants the thing off their plate. They look at their inbox. They check the time. They say "got it" before you finish. The energy signal trumps the calendar signal when the two conflict. A 30-minute 1:1 with a manager who is visibly in headline-mode is not a 30-minute detail conversation. Read the room.

Three modes, not two

The crude version of this read is headline or detail. The more useful frame is three:

Headline. One sentence, plus a flag if something is off-track. Hallway, DM, scan-reading.
Status. Three to five sentences, structured: what's done, what's next, what's blocked, ask. 1:1s and standups.
Briefing. Full context with tradeoffs and a recommendation. For when a decision is being made or your manager is about to advocate for the work elsewhere.

Most juniors live in mode two by default. Mode two delivered when mode one was needed is the most common failure. Mode one delivered when mode three was needed is the second most common.

The two-line opener that protects you when you can't tell

When you genuinely don't know which mode they're in — new manager, weird calendar, mid-week of a chaotic launch — start with the headline and then offer the depth. One sentence of status, then "happy to go deeper on any of this if useful." They'll tell you with their next sentence. Either they say "yes, the copy issue, what's the read" and you're in mode two. Or they say "great, thanks" and you saved them eleven minutes. Either way you read correctly.

The two-line opener also quietly builds trust. The implicit message is: I know your time is finite, I know I don't always know what you need, I'm going to make it easy for you to get what you need from this exchange. Managers do not consciously notice this. They notice it on the way out of the room, in the form of I like working with this person.

:::template{title="The pre-update check"} Before any update of any size, ask yourself:

Calendar: how much time do they actually have right now?
Audience: is this for them, or for the next conversation they're walking into?
Mode: are we deciding or reporting? Deciding wants briefing. Reporting wants status or headline.

If you have time and access, ask directly: "Headline or dig in?" If you don't, default to headline plus "happy to go deeper if useful." :::

The longer arc

I had a manager at Walmart whose 1:1s ran 45 minutes and felt thorough, so I assumed he wanted detail. Then we hit a stretch of six weeks where everything was on fire across three reorgs and I kept showing up with structured updates because that's what the template said. He never told me he was drowning. The 1:1s got terser, the feedback got shorter, the energy in the room got lower. I figured he was annoyed at the work. He was burning out, and my 1:1s were one more thing on a fifty-thing list. The week I started opening with "one-line update or want to dig in?" the 1:1s got useful again. Some were fifteen minutes. He started asking me to lead more. Neither of us said the words "I was making your job harder." We both just got better at the read.

The cohort that gets promoted in the first three years isn't the one with the cleanest status reports. It's the one that figured out, fast, that their manager is a person on a treadmill, and that every interaction is a chance to make the treadmill go a little smoother. Reading your manager isn't politics. Politics is when you start performing for them. Reading them is just paying attention to who you're talking to.

When a Peer Takes Credit for Your Work: 3 Responses, From Subtle to Direct

Mike Halpert — Wed, 13 May 2026 00:00:00 GMT

A few years into a senior PM role, I walked into a performance review proud of about six months of work. Cross-functional research. Stakeholder alignment. A strategy doc with my name all over it. My manager rated the half "average." The work hadn't shipped. Hadn't moved a metric. Nobody was using it. From the inside it felt like a great half. From the calibration room, it didn't exist.

Credit theft is the social version of that lesson. If your name isn't legibly on the shipped artifact — the deck, the doc, the recap — someone else's name lands there by default. And managers grade what they can see.

So when a peer stands up in a meeting and says "I" about a model you built, the instinct is to correct them in the room. Don't. The room is grading your response more than it's grading the credit theft. Almost nobody else even clocked it.

Here's the response ladder. Lightest move first. Escalate only if the pattern continues.

Response #1 — Subtle: re-attach your name to the artifact

First instance, every time. Cost: five minutes.

Send the follow-up. Forward the original deck. Write the recap. Put your name back on the work in a place the right people will see it. You don't say a word about the credit-grab.

Yes, sending the original deck two days later feels like passive-aggressive credit-staking. That's because it is. Do it anyway. The person who sends the recap gets credited for running the meeting, regardless of who actually ran it. The person who forwards the source doc gets remembered as the author.

Here is the email I use:

:::template{title="The recap email"} Subject: Recap from Tuesday's [project name] review

Hi [Manager], [stakeholder 1], [stakeholder 2],

Quick recap of where we landed on [project] yesterday so we have it in writing:

[Decision 1]
[Decision 2]
Open question: [one thing still unresolved]

Attaching the underlying model / deck for reference — happy to walk anyone through the assumptions on slide [X] if useful.

Next step on my side: [one concrete thing you'll do this week].

Best, [You] :::

The "attaching the underlying model" line is the whole point. Your name is on the file. The timestamp is on the file. Your manager has a copy of the artifact, not just the meeting story.

Performance reviews are theater. The calibration meeting you're not in is what your follow-up email is actually for. And the only inputs that conversation has are the artifacts in your manager's inbox.

Do this once, it's a recap. Do it after every meeting and over six months it makes you legible.

Response #2 — Direct but private: ask, don't accuse

Second instance, or the first one where intent looks deliberate. Cost: one slightly uncomfortable conversation.

Put fifteen minutes on the peer's calendar. Frame the credit-grab as a question, not an accusation:

"Wanted to ask about the share-out yesterday — was leaving my name off the deck intentional, or did it just slip in the edit? I wasn't sure how to read it."

Two things happen. If it was accidental, they apologize, they remember, and it stops. If it was deliberate, they know you noticed, and most people will not try it a second time on someone who's clearly watching.

The question framing matters. You are not asking them to confess. You are giving them a door to walk through that lets both of you keep working together. Jumping to "you stole my work" wins the argument and loses the next two years of being on the same team.

One caveat: this move requires a relationship strong enough to hold a slightly awkward question. If the peer is much more senior, or you've been on the team three weeks, skip back to Response #1 and let the artifact do the talking.

Response #3 — Up the chain: escalate with documentation

Third instance, or one truly egregious one, like presenting your deck as theirs to leadership. Cost: a move you can't take back.

Bring it to your manager. Two rules.

First, lead with impact on the work, not feelings about the peer. "I'm worried about how decisions are getting attributed on this project, and I think it's going to slow us down on [specific upcoming thing]" lands. "She took credit for my model" doesn't.

Second, walk in with documentation. The forwarded emails. The original timestamps. The dates of the share-outs. You're not litigating intent. You're showing a pattern.

Two outcomes are real here. Escalate well and your manager handles it cleanly. Escalate badly and you get quietly labeled the difficult one. The difference is almost always in the framing and the receipts. If you don't have receipts yet, you're still in Response #1 territory. Go build them.

When the ladder bends

The peer is more senior than you. The ladder collapses to Response #1; the artifact move is the only safe play. Don't ask a director "was that intentional."
The credit-taker is your manager. Different problem, different post. Make your boss shine and find other surfaces for your work.
Your manager was in the room and said nothing. Almost always inattention, not complicity. Send the recap. It catches both of them up.

I've watched first-years lose their composure over the first credit-grab and never recover socially from the moment they did. I've also watched people swallow ten of these in a row out of "professionalism" and quietly stop being seen as the owner of anything. Neither one is the move.

The move is the artifact. The forward. The recap. The receipt — quietly, three times, until your name is on the work in the room that grades it.

A Script for the "I Think You Dropped the Ball" Conversation

Mike Halpert — Fri, 08 May 2026 00:00:00 GMT

There are five words that make a coworker stop listening:

“I think you dropped the ball.”

The annoying part is that occasionally they did.

The deck was due Tuesday. The copy never landed. The ticket has been sitting in the same column since last week. Now your part of the work is stuck, and somehow you are the person who has to say the uncomfortable thing.

This is where new grads either wait too long or turn one missed handoff into a courtroom scene. I get it. Nobody wants to sound like they are auditioning to become the office hall monitor.

But there is a middle move. You do not accuse someone of being irresponsible. You name the missed handoff, the impact, and the next commitment.

That is the difference between blame and accountability. Blame asks for a villain. Accountability asks for the next working plan.

“Dropped the ball” is a character judgment

When you say, “You dropped the ball,” the other person hears more than a missed deliverable.

They hear:

“You are careless.”
“You made me look bad.”
“I am keeping score.”

Maybe none of that is what you meant. It still lands that way.

The safer version is boring and specific:

“The launch deck is blocked because the customer quotes did not land by Tuesday.”

That sentence is harder to argue with. It does not diagnose their work ethic. It does not guess at their intent. It points to the fact, the timeline, and the downstream problem.

This is close to the feedback structure the Center for Creative Leadership calls Situation-Behavior-Impact: name the situation, describe the observable behavior, explain the impact. I like that frame because it keeps you from wandering into amateur psychology.

You are not saying, “You do not care about this project.”

You are saying, “This part is missing, and this is what it blocks.”

That difference saves relationships.

Start with a prep note, not a speech

Before you send the Slack or ask for five minutes, write down the facts.

Not because you are building a legal case. Because your brain will want to add adjectives once you are annoyed. Mine does too. The first draft in my head has occasionally been much sharper than the version I should have said out loud. The sharp version feels satisfying for four seconds, then creates two more meetings.

Use this instead.

:::template{title="Dropped-ball prep note"}

1. What was due?
[Name the deliverable, task, decision, or handoff.]

2. When was it due?
[Use the agreed date, meeting, ticket, or message thread.]

3. What is the observable fact?
[Example: “The file is not in the shared folder” or “The ticket is still unassigned.”]

4. What is blocked?
[Name the person, decision, launch, customer, or next task waiting on it.]

5. What do I need next?
[The new commitment, owner, and deadline.]

6. If that cannot happen, who needs to know?
[Manager, project lead, client owner, stakeholder.]

:::

If you cannot fill out those six lines, you may not be ready for the conversation yet. You may be irritated, but you are not clear.

Clarity comes first.

The script to use

Send a short note first. Do not write “we need to talk.” That line makes normal people assume they are being fired, dumped, or both.

:::template{title="Quick check Slack"}

Hey [Name] — quick check on [deliverable]. I expected it by [date/time] based on [meeting/thread/ticket], and I don’t see it in [place].

Without it, [specific next step] is blocked.

Can we do a 10-minute reset today on what happened and what timing is realistic now?

:::

Then, in the conversation:

:::template{title="10-minute reset script"}

I want to check on [deliverable]. It was due [date/time], and I don’t see it in [place].

The reason I’m raising it is that without [deliverable], [specific downstream work] can’t move.

What happened on your side?

[Listen.]

Got it. What can you commit to by [new deadline], and is there anything you need unblocked to hit that?

If that timing does not work, I need to reset expectations with [manager/project lead/stakeholder] today so the rest of the work does not drift.

:::

That last line matters.

You are not threatening them. You are telling them the project needs a new plan if the old one no longer works. There is a real difference.

Why this works

The script does four useful things.

First, it keeps the conversation private. A peer reset should not start in a public channel unless the work truly requires it. Public correction creates a second problem: now the person has to manage the work and their embarrassment.

Second, it gives them room to explain. Maybe they missed it. Maybe the original deadline was vague. Maybe they were blocked by someone else and never said so. You do not have to pretend all reasons are equally good, but you should hear the reason before you decide what to do next.

Third, it turns the conversation toward the next handoff. The goal is not to get a confession. The goal is to keep the work from failing twice.

Fourth, it creates a clean record if you do need to escalate later. If the person misses the reset deadline too, you can tell your manager: “I checked with Jordan on Tuesday. We agreed on noon Wednesday. The file still has not landed, and the QA slot is now at risk.”

That is much stronger than: “Jordan keeps dropping the ball.”

One sounds like a person trying to protect the work. The other sounds like a person trying to win a blame round.

If you are new, use the softer version

If you are in your first few weeks, slow down.

A week-two employee telling a peer they “dropped the ball” can read as overreach, even when the employee is technically right. That does not mean you stay silent. It means you frame the conversation as a dependency check.

:::template{title="First-few-weeks version"}

I’m still learning the handoff process here, so I want to make sure I understand the expectation.

I was waiting on [deliverable] by [date/time] so I could complete [your task]. Is that the right ownership, or should I be getting this from somewhere else?

:::

That protects you from sounding like you are grading someone else’s performance before you understand the team.

It also surfaces the real issue. Sometimes the ball was dropped. Other times, no one ever agreed who was holding it.

When to skip the peer script

Skip this if the issue is harassment, sabotage, retaliation, discrimination, or anything that belongs with HR, legal, compliance, or your manager right away.

Also skip it if your manager has already told you not to direct this person. In that case, escalate the dependency, not the coworker. Say, “I am blocked on X because Y has not landed,” and ask your manager how they want to handle the ownership.

For remote teams, be extra plain. Written tone can turn a normal reset into an ominous message. Avoid “per my last email” energy. Use short context, then talk live if the relationship matters.

For foreign professionals, one US-office norm is useful here: calm directness about work impact is read as professional in many teams. Vague hints may be missed. You do not need to be harsh. You do need to be specific.

If this is part of a bigger communication pattern, you may also want the Slack vs. email decision tree or the guide to resolving conflicts with coworkers.

Yes, this whole thing is slightly corporate. You are taking an emotion — “I am mad this did not happen” — and turning it into a tiny project-management artifact.

Do it anyway.

The point is not to make someone feel bad. The point is to keep the work from failing twice.

Slack Etiquette 101: The Channels, Threads, and DM Rules Nobody Documented

Mike Halpert — Tue, 05 May 2026 00:00:00 GMT

TL;DR

Default to public channels for questions and updates—searchable history beats duplicate pings every time.
Thread every reply to keep the main feed clean and notifications targeted.
Use DMs only for truly private stuff or quick 1:1s; anything team-relevant goes public.
Search before posting—80% of your questions are already answered somewhere.
Set your status for boundaries; it cuts off-hours noise in half.

You're three weeks into your first job. The #general channel is buzzing with updates. Someone posts a question about the client deck. Five people reply right there in the main thread. Your notifications explode. You try to find the answer later—it's buried under cat memes and lunch polls.

That's when you realize: Slack isn't IRC or SMS. It's a searchable archive that can make you look sharp or bury you in noise. And nobody tells you the rules.

I learned this the hard way at my first agency gig. We had a shared channel for client feedback. I DMed a quick question to the lead instead of posting publicly. It got lost. The client deadline slipped because no one else saw the loop. Cost us a week's rework—and my credibility with the team.

The fix isn't complicated. It's three rules: public channels first, threads for replies, DMs for private only. Follow them, and you cut clutter by half. Ignore them, and you become the person everyone mutes.

Rule 1: Channels Are Public by Default

Post in channels unless there's a real reason not to. It's not about transparency for transparency's sake—it's about making knowledge stick around.

Why? Duplicate questions waste everyone's time. If you're asking about the Q2 budget format, someone else probably needs it too. Public channels mean one answer serves the team. Searchable history means you find it next quarter without pinging again.

In my consulting days, we had a #project-x channel for every client. New analysts posted questions there. Seasoned folks answered once. By month three, the channel was a FAQ no one had to rewrite.

What it means in practice:

Use channels for anything team-wide: updates, questions, decisions.
Name channels clearly: #q2-planning, not #stuff.
If it's sensitive (HR, salaries), use a private channel. But default public.

What it's not: A broadcast tool. Don't @channel for "quick yes/no" unless it's urgent. That's noise.

Edge case: Small teams under 10 people. The transparency tax feels heavier—DMs are fine for casual back-and-forth. But as you scale to 20+, channels prevent silos.

Rule 2: Threads for Every Reply

Replies go in threads. Not the main channel. This keeps the feed scannable and focuses the conversation.

The problem with main-channel replies: They notify everyone again. A 10-message back-and-forth on a side question turns #general into a war zone. Threads notify only the participants. The main post stays clean as the summary.

From the book: In high-volume teams, threading cut our response time by 30%. You reply once, the thread builds the details, and the channel pinpoints the outcome.

How to do it:

Click the reply icon on the original message.
Type your response. If it's long, break it into bullets.
Use @mentions sparingly in threads—only if you need input from someone outside the loop.

Example: PM posts in #product: "Ideas for onboarding flow?" You reply in the thread: "What about a checklist for account setup? Here's a quick one I mocked up." Others chime in below. The main channel sees the hook; the thread has the depth.

What it's not: A place to hide. If the discussion uncovers something team-wide (like a process gap), summarize and post the key takeaway to the main channel.

Edge case: Urgent fire drills. If it's blocking today, reply in main and thread the details: "Yes, pivot to the backup plan [thread for specs]."

Rule 3: DMs Are for Private or Quick Only

DMs aren't the default. Use them for 1:1 stuff: feedback, scheduling, or async check-ins that don't need group input.

Why? DMs die when the conversation ends. No searchability, no team learning. Plus, they create blind spots—managers can't see if you're looping in the right people.

I once DMed a status update to my boss instead of posting in #weekly-sync. She followed up in a team meeting: "Hey, anyone else need this?" Awkward. Lesson: If more than two people might care, channel it.

When to DM:

Private feedback: "Quick note on the deck—tone feels off on slide 5."
Scheduling: "Available for 15 min Thursday?"
Quick async: "Saw your email—yes, that works. Confirming with legal."

Start with context. No standalone "hey" or thumbs-up emojis as replies. "Hey—quick question on the timeline?" wastes a round trip.

What it's not: A channel substitute. If it's work-related and not confidential, public wins.

Edge case: Remote teams with time zones. DM for "I'll review this tomorrow— heads down till 10 AM PST." But follow up publicly.

The Slack Etiquette Checklist

Here's your one-page guide. Pin this mentally—or actually pin it in your workspace if you can.

Search first. 80% of questions are already answered. Hit Cmd+K, type keywords. Save 15 minutes. Source: ClearFeed productivity study.
Public channel default. Unless private, post there. Reduces duplicates by 40%. Source: Slack Blog.
Thread all replies. Keeps feeds clean; notifies only who needs it. Source: Grammarly Business Report.
DM with context. No "hey." Say what you need upfront.
Emoji reacts over short replies. 👍 acknowledges without adding noise.
Status for boundaries. "Heads down till 3 PM" cuts pings by half.
Proofread before send. Typos in channels stick around—searchable forever.
Archive inactive channels. Keeps the sidebar under 50. Post-project, done.
Pin key messages. Guidelines, decisions—make them easy to find.

Worked example: You're the new analyst. Lead posts in #q1-planning: "Budget template due EOW." You search—nothing. Post: "Confirming: Include headcount projections? [thread for details]." Three replies in thread clarify. You summarize: "Got it—projections yes, opex no. Draft incoming." Team sees the outcome; details are there if needed.

When These Rules Don't Apply

Not every team is the same. Startups under 15 people: Looser norms, more DMs. Big corps: Enforce with pinned guides. Foreign pros: US teams expect directness—channels over email chains.

If your team ignores threads (common in creative shops), adapt: Propose a trial week. "Let's thread replies this sprint—easier to follow?"

Off-hours: No pings unless critical. Schedule messages if needed.

One Thing to Do Today

Pick one channel you're in daily. Next question you have, post publicly and thread the follow-ups. Watch how it changes the flow. You'll save your team time—and look like you get it.

This isn't about rules for rules' sake. It's about being the person who makes work easier. Start small. The rest follows.

How to Ask for Help Without Sounding Helpless (The 3-Part Ask)

Mike Halpert — Mon, 20 Apr 2026 00:00:00 GMT

Every new hire hits the same moment. You're stuck. You don't know how to move. You draft a Slack to your manager, read it back, delete it, and rewrite it three times. Then you send some version of "hey, quick question when you have a sec?" and wait.

That message is the problem. It sounds small and polite. It's actually the most expensive way to ask for help.

A vague ask forces the other person to do two jobs: figure out what you're actually asking, then answer it. You've handed them a blank context and asked them to fill it in. Most managers respond with "sure, what's up?" — adding a second round trip to a conversation that should have been one message. The pattern doesn't make you look humble. It makes you look like you haven't done the thinking.

Three parts, in order, fixes it.

Part 1: The context

One sentence. What you're working on, what you're trying to accomplish, what's blocking you.

Not a paragraph. Not the full backstory. One sentence. If you can't compress the context into a sentence, you probably don't understand the situation well enough to ask about it yet — which is a useful discovery on its own.

I'm pulling the Q2 retention numbers for Jasmine's board deck, and the data warehouse is returning null values for cohorts after March 15.

That's it. The other person now knows what you're working on, why it matters, and what's wrong.

Part 2: What you tried

One or two lines. The things you already checked, the dead ends you hit, why you're escalating instead of continuing to dig.

I checked the cohort definition against the March release notes — nothing changed. I also pinged the data-eng channel; no response in 90 minutes.

This part earns you credibility in the same message. You're not outsourcing your thinking. You're asking them to skip past the work you've already done.

It also protects you. If your manager is the kind who defaults to "did you try X?", you've already answered that. The conversation advances instead of looping.

Part 3: The specific ask

One sentence. Exactly what you want them to do.

Can you check whether the warehouse role permissions got changed in the last week, or point me to someone who can?

The ask has two properties: it's concrete (a verb, a specific thing), and it's bounded (they can answer yes/no or redirect you). Bad asks are abstract — "any thoughts on this?" Bad asks are unbounded — "help me debug this." Good asks are things the other person can actually do in under two minutes.

If your ask is "let's discuss," you don't have an ask. You have a meeting request hiding inside a help request. Say so.

Why this actually works

You're not writing the message for yourself. You're writing it for the person reading it.

Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for. They will give your message about four seconds of attention on the first read. Those four seconds need to deliver the entire payload: situation, what you tried, what you need. If they can answer in one message — "check with Devin, he owns that role" — they will. If they have to reply "what's the context?" you've added a 15-minute delay to your afternoon.

There's a second-order effect that compounds: the colleague who sends structured asks gets fast, direct answers — because their manager has learned the response is always worth writing.

What not to do

Don't apologize for asking. "Sorry to bother you" frames the ask as an imposition. It isn't. Asking for help is part of your job. Skip the preamble.

Don't hide the ask at the end of a long message. If the third part is buried under two paragraphs of explanation, rewrite it. The ask should be skimmable in ten seconds.

Don't ask in DMs what belongs in a channel. If the answer would help anyone else on the team — and most answers do — ask in the team channel. You get more responses faster, and the answer is searchable the next time someone hits the same problem.

Don't follow up in under 30 minutes. You sent a structured message. Let it breathe. Following up at minute ten reads as anxious, not diligent.

The template

Context: I'm working on [X], trying to [Y]. Blocker: [Z].

Already tried: [thing 1], [thing 2]. Didn't work because [reason].

Ask: Can you [specific action], or point me to someone who can?

Three lines. Under sixty seconds to write. Gets better answers than any thirty-minute Slack session you could have instead.

—

I've sent the bad version of this message more times than I want to admit, usually when I was tired or anxious. The structured version is harder to write — that's the whole point. The fifteen seconds of effort it takes to compress your problem into three lines is what separates "I have an emergency" from "I have a question." Be the latter, and the answers come faster.

The coffee-chat script that isn't creepy

Mike Halpert — Wed, 01 Apr 2026 00:00:00 GMT

Every first-year thinks they should be doing more coffee chats. Most don't know how to ask for them without it feeling weird. So they either never send the message, or they send the version where they end up copy-pasting a template they found on LinkedIn, and the recipient can tell.

There is a version of the coffee-chat request that works. It's short, specific, and signals that you've actually thought about why you're asking this person. It's also not that hard to write.

The script

For an internal colleague:

Hi [Name] —

I'm a [role] on the [team] — joined six months ago. I saw your recent [specific thing: write-up, doc, presentation, project launch], and the part about [specific detail] is something I've been trying to figure out for my own work.

Any chance you'd have 20 minutes in the next couple of weeks? Happy to come to you, grab coffee, or jump on a video call. No agenda beyond asking a couple of questions about [the specific thing].

Thanks, [You]

For an external person:

Hi [Name] —

I came across [the specific thing] and it stuck with me, especially the point about [detail]. I've been working on [adjacent thing I'm actually working on], and I'd love to ask a couple of questions.

Would you be up for 20 minutes in the next few weeks? I'm a [role] at [company] — not trying to sell you anything or pitch a job. Just curious about how you think about [topic].

Thanks, [You]

Both messages share the same structure. Five short paragraphs. One specific reason. One clear ask. One disclaimer when warranted. Sign off.

Why this works

You named a specific thing. The moment you reference a specific doc, post, or project, you've demonstrated that you aren't copy-pasting a template. That's 80% of what makes this not creepy. The recipient's instinctive read goes from "this is a form letter" to "this person actually paid attention."

You named what you're trying to figure out. You gave them a reason to say yes that wasn't "I'd like to meet you." People are much more likely to agree to a 20-minute conversation that has a concrete purpose than a vague one.

You asked for a bounded amount of time. Twenty minutes is small. "Pick your brain for an hour" is large. 20 minutes gets yeses that "grab coffee" doesn't.

You removed the friction. "Happy to come to you" or "jump on a video call" — giving them the cheapest option for their calendar makes yes much easier.

You were honest about why. You didn't pretend it was a two-way conversation where you have value to trade. You asked a question and said you'd be grateful.

What doesn't work (and why)

"I'd love to pick your brain" is the most overused phrase in corporate messaging. Vague, and it implies you're the one getting value and they're the one giving it up. Replace with specifics: "I'd love to ask about how you structured the Q2 rollout."

"I'd love to hear about your career journey." Nobody wants to give you their whole career story. If you're interested in their career, ask one question about one part of it: "how did you end up on [X] team — was that an internal move?" That's a manageable question. The full journey isn't.

Flattery openers. "I've been a huge fan of your work" lands as pandering unless backed by specifics. If you genuinely respect someone's work, say what specifically about it affected your thinking. That's the version that reads as sincere.

Long explanations of yourself. A three-paragraph autobiography about why you deserve 20 minutes is the opposite of what convinces them to say yes. Two lines — your role, how you found them — is the whole intro.

"Let me know when works for you." Open-ended scheduling from a stranger is a lot to ask. Propose two or three windows: "Would Tuesday afternoon or Thursday morning work?"

Asking for a job or a referral in the first message. Coffee chats aren't job asks. Leading with one kills it.

What to actually do in the 20 minutes

You asked for it. Run it well.

Come with two or three questions, written down. Not twenty. When in doubt: one question about their current work, one about a decision or tradeoff that interested you, one open-ended "anything I'm not asking that I should be?"

Talk less than half the time. A well-run coffee chat is about 25/75 — you talking 25%, them talking 75%. Your role is to ask good questions and listen. If the meeting becomes about you, you're doing it wrong.

Take notes visibly. It signals respect and helps you remember. "Mind if I jot a couple of things down?" is always fine.

Don't ask for something at the end. Don't ask for an introduction. Don't ask them to look at your resume. Don't ask them to review a project. The meeting is the thing. Extracting more from it cheapens it.

Leave one minute early. Twenty-minute meetings should run 19. Respecting the clock is a senior signal.

The follow-up note

24 hours later, three lines:

Thanks again for the time yesterday — the specific thing about [detail] has already changed how I'm thinking about [my thing]. I'll let you know how [next step] goes.

Also wanted to share [one small thing: an article, a tool, a thought] in case useful.

[You]

The "in case useful" line is the reciprocity move. You can't match them on experience, but you can share something they'd plausibly find interesting. It changes the feel from "they did me a favor" to "we had a useful conversation." If you have nothing relevant to share, cut that line.

The medium-term follow-up

Most coffee-chat relationships die in the follow-up. You did the meeting, sent the thank-you, and then lost touch. Six months later, the relationship has cooled.

Fix: circle back once, casually, six to eight weeks later with an update. One sentence about how their advice played out. No ask. Just an update.

Hi [Name] — quick update from the conversation a couple of months ago. Ended up doing [X]. Wanted to close the loop since your framing really shaped the approach. Appreciate it.

That update turns a one-off meeting into a relationship. Two or three coffee chats run this way over a year is enough to build a small network that compounds.

—

The single biggest barrier to a useful coffee chat isn't the script. It's the part where you actually press send. The version of you that's overthinking the phrasing for the third time tonight is exactly the person whose specifics will make the message land. Stop polishing. Send.

For the adjacent "do I have to network at this conference" question, see the Reader Q on networking at industry events. For the weekly status rhythm that gives you things worth bringing to a coffee chat, see the status update template.

First 1:1 with a new manager: the exact agenda

Mike Halpert — Sun, 15 Mar 2026 00:00:00 GMT

The first 1:1 with a new manager is one of the highest-leverage meetings of your first year.

It's where they form the sentence that lives in their head about you: "low-maintenance," "gets it," "easy to work with" — or "needy," "vague," "I'll figure them out later." Whichever sentence lands in the first thirty minutes tends to stick.

You don't need to impress them. You need to make them relax.

What a new manager is actually trying to figure out

When a manager sits down with a new report, they have four unasked questions:

Will this person surprise me?
What will I need to do to help them succeed?
How much do they already know about the team and the work?
Can I trust their judgment yet?

Your agenda should answer all four without them having to pull it out of you.

The 30-minute agenda

Six blocks. Five minutes each.

0–5 min — Quick context

Not a resume recap. They've seen your LinkedIn. Give them two things:

What you've been doing in a sentence. "For the last six months I've been on [project], focused on [narrow thing]."
What you're most interested in learning next. "I'm trying to get better at [specific skill or domain]."

Four sentences total. Leave room for the real conversation.

5–10 min — Three questions for them

You're not here to ask about hobbies. You're here to learn how they operate.

Pick three. Pre-written.

"How do you like to receive updates — written, live in 1:1, Slack? How often?"
"When you need a decision from me vs. just want to know about something — how do I tell the difference?"
"What does a great week look like for someone in my role?"
"Who else on the team should I build a strong working relationship with early?"
"What's the biggest risk or initiative on the team that I should be aware of?"

Take notes visibly.

10–15 min — Short status with a risk

Even brand new, you have context they don't. Three lines:

What you're working on now.
What you're worried about, if anything.
One decision or piece of clarity you'd like in the next two weeks.

This is the move that separates "I'm waiting to be told what to do" from "I'm a pro who happens to report to you now."

"I'm wrapping up the [first project / first ticket / first month]. One thing to flag: I'm a little unsure about [X] — I'm planning to handle it by [approach], but if you'd rather I check in sooner, just say the word."

15–20 min — Their goals

Ask:

"What are you personally being measured on this quarter? What would make this a great quarter for you?"

Then shut up. Let them talk. You're learning what your work should ladder up to. A new manager will almost always answer this generously — it's a question they wish more reports asked.

20–25 min — Align on the next two weeks

Close the loop on the ambiguous parts. Confirm out loud:

What you'll work on between now and the next 1:1
Any meetings you should add or drop
One thing you'll send them as a follow-up

If they gave you direction in the last ten minutes, play it back: "So — I heard you want me to prioritize A and B, and hold off on C for now. Is that right?"

25–30 min — Ask for the coaching you want

The sentence most juniors forget to say. Pick one:

"I'd love feedback at roughly 50%, not 90%. I can take it early."
"I'd rather you tell me directly when something is off than pattern-match it over time."
"If I'm doing something annoying without realizing, I'd want to hear it sooner, not in a review."

You're telling a new manager how to manage you. Most people don't, and then get surprised when their manager doesn't read their mind.

What to send before the meeting

Write the agenda in a doc. Share it 24 hours in advance. Keep it short:

1:1 agenda — [Your Name] + [Manager] — [Date]

Quick context on where I'm at

Three questions on how we'll work together

Short status + one risk

What you're focused on this quarter

Align on the next two weeks

How you'd like me to surface feedback

You will be the only direct report who did this. It costs you five minutes. You get ninety days of reputational goodwill.

What to avoid

Don't over-disclose. Personal details, family stress, salary gripes, complaints about your previous manager. Wait six months, minimum.

Don't dump problems. If you have a blocker, bring two options and a recommendation, not a pile.

Don't promise anything specific. "I'll have the full redesign done by Friday" is a commitment. Don't make one in a meeting where you haven't even calibrated what "done" means here yet.

Don't be too casual. A first 1:1 is not a friendship ritual. Warmth is fine. Small talk is fine. Don't pretend you're peers yet.

—

I've sat on both sides of this meeting more times than I can count. The version that lands is always the one where the new report did the prep — not because the prep itself is the value, but because nobody else does it. You're in a category of one within thirty minutes of starting.

For the weekly rhythm that turns first-1:1 goodwill into a promotion case, use the Manager 1:1 agenda. For the update format that runs through every 1:1, steal the Status update template.

How to ask for more work without sounding desperate

Mike Halpert — Wed, 25 Feb 2026 00:00:00 GMT

A common early-career moment: you've finished everything on your plate, you're sitting idle, and you're two minutes from sending the "hey, anything I can help with?" Slack.

Don't. That message is how you end up reformatting someone's deck at 4:47 p.m.

Asking for more work is a good instinct. The execution is where people lose.

Why the default Slack doesn't work

"Anything I can help with?" puts the cognitive load on your manager. They have to stop their actual work, scan their mental list of tasks, find something vaguely juniorable, and type it out. Most won't bother — they'll send you whatever's easiest to describe in a sentence. Usually admin.

You want real scope. That requires you to do the framing.

The three ingredients

Context. Why you're asking now. ("I wrapped X earlier than planned" — not "I'm bored.")

Options. Two or three things you've already noticed could use help, specific enough that your manager doesn't have to think hard.

A default. What you'll do if they say nothing. Makes it safe to decline.

The Slack message

"Hey — I finished [X] earlier than expected and have about 1.5 days of capacity before [next thing] starts. Three things I've noticed I could pick up:

1. [Specific thing you saw], which would free up [person / time]. 2. [Another specific thing], which would unblock [something]. 3. [A third, if you have one].

Option 1 is my default unless you'd rather I take 2 or 3. Happy to do something else entirely if there's something more useful."

That message does four things at once: shows you're paying attention to the team's actual work, makes it trivial for your manager to say yes, gives them an easy way to redirect you, and proves you can run with ambiguity.

Where to find the three options

If you're stuck on what to propose, walk the team's docs and Jira channels for 20 minutes and look for:

A doc or process everyone complains is out of date
A recurring task your senior does manually that could be templated
A meeting series with no notetaker
A ticket on the backlog that's been there for over a month
An onboarding gap (you just lived through it — fix one thing)
A metric nobody's owning
A half-finished automation someone started but never wrapped

Almost every team has at least three of those lying around.

Timing

Don't send this Monday morning. Your manager is drowning.

The sweet spots:

Mid-week, early afternoon (Tue–Thu, 1–3 p.m.) — they've dealt with their inbox, they haven't hit late-afternoon crunch.
The day after you ship something visible. "I wrapped X. What's next?" is a question a manager is mentally ready to answer when X just landed.
Before your 1:1, not in it. Send the Slack 24 hours ahead so the 1:1 conversation is about which of the options, not whether to take one.

How to make sure you get real scope, not busywork

Two rules.

Never take unscoped work. If your manager says "Can you help with the Q2 launch?" — great. But before you say yes, ask: "Happy to. What's the specific thing you'd want me to own — a piece end-to-end, or support on a workstream? Who should I coordinate with?" If they can't answer, the work isn't ready for you. Offer to come back when it is.

Close the loop hard on whatever you pick up. Visible ship → short update → "what's next." That's how the next ask becomes a bigger piece of work. Managers give scope to people who make small scope look handled.

What not to do

Don't ask every day. Asking once a week signals capacity. Asking every day signals anxiety.

Don't volunteer for everyone else's leftovers. The first couple of times, it builds goodwill. Past that, you become the person who absorbs crap work, and the ceiling of your role gets lower without anyone noticing.

Don't lead with "I'm bored." Boredom is your problem, not theirs. Lead with capacity.

Don't ask a skip-level. Don't route around your manager for scope. That's a relationship-damaging move even when well-intentioned.

The harder version: you're genuinely under-utilized

If you've done the structured Slack three or four times over a month and you're still sitting on two days of capacity a week, that's a 1:1 conversation, not a Slack message.

"I've had extra capacity for the last few weeks and I've been picking up smaller things. I want to flag it because I don't want to be the person who's coasting without anyone noticing. Is there a larger scope I could be ramping onto? I'd rather stretch than fill."

Two things can happen. Either your manager gives you a stretch, or they don't, and the "is this role actually growing" question becomes legitimate. Useful either way.

—

I've watched first-years with extra capacity do every variation of the wrong thing — sit silent and read Twitter, panic-DM their manager hourly, volunteer for everyone's worst tickets — and the correct move is honestly the simplest one: walk the team's docs once, write down three things, send the Slack. The whole exercise takes thirty minutes and saves you from a week of being the new grad nobody trusts with anything good.

For the status rhythm that turns every piece of pickup work into visible progress, use the Status update template. For the meeting where this ask lands best, see the Manager 1:1 agenda.

Negotiating your first raise: scripts and timing

Mike Halpert — Tue, 03 Feb 2026 00:00:00 GMT

You've been at the job a year. You've shipped real work. You've heard the words "great job" a few times. Nothing has happened to your paycheck.

A raise rarely shows up because you deserve one. It shows up because you asked at the right time, with the right framing, in the right room.

The framing that wins

A raise is not a favor. It's a decision your manager has to justify upward — to their manager, to HR, to a budget. Your job is to make that justification easy.

The raise conversation is not "here's why I deserve more." It's "here's the business case my manager can forward."

When to ask

Three windows work. Everything else is a coin flip.

The formal review cycle. If your company has one, that's the window. Asking outside of it usually means "we'll consider it at the next review," which is a polite no.
After a visible win that changed something. You shipped the thing. A metric moved. A VP noticed. Ask within two to four weeks. Memory fades.
When you take on scope above your level. You backfilled a role. You led a project that used to be your senior's. The gap between your work and your title is the argument.

Bad timing: right after a bad quarter, during layoffs, the week your manager is underwater, before you've accumulated six months of pointable work.

The prep

Walk in with three things.

1. A short list of contributions, in outcomes. Not "I worked on X." "I shipped X. It did Y. The impact was Z." Five to eight bullets. Each one under a line.

2. A benchmark. What are people at your level, at comparable companies, in your market making? Levels.fyi, Glassdoor, the salary thread in your industry's subreddit, a trusted peer at a competitor. You don't need a perfect number. You need a defensible range.

3. A specific ask. Don't say "more." Say "$X" or "a Y% increase." Specific asks get specific answers. Vague asks get deferred.

The conversation

Do this in a scheduled 1:1, not a drive-by. Email the subject line a day or two before:

"For our next 1:1, I'd like to talk about my compensation. Wanted to flag it so you have context going in."

That's it. Don't explain in email. The conversation is the point.

The opening script

"I'd like to talk about my comp. I've been at [role] for [time]. Over the last [period], I [two or three biggest wins, in outcomes]. Given the scope I'm now carrying, I'd like to discuss a base increase of $X / Y%."

Three parts: context, evidence, ask. In that order. Short.

Now stop talking.

A lot of people ruin the ask by filling the silence with hedges. "I know budgets are tight…" / "I don't want to make this awkward…" Don't. Let your manager respond. Their job now is to think.

What you'll hear, and how to respond

"Let me look into it." Good. Close the loop:

"Thanks. When can we follow up — next 1:1, or two weeks?"

Make it a commitment, not a vibe.

"The budget is set for this cycle." Fine. That's an answer, not the end:

"Understood. What would it take to be considered in the next cycle? A specific project, a title change, a scope expansion — I'd like to know what to aim at."

"I can't do the full amount. I can do half." That's a yes. Take it, and anchor the rest:

"I appreciate that. Can we put the remaining gap in writing as part of the next review, tied to [specific outcome]?"

"This isn't the right time." Translate that:

"Is that about company budget, or about where I am in the role? If it's about me, I'd like to understand what would change that."

Silence. If you don't hear back in two weeks, bring it up again. Once. Not every 1:1.

The answer you can't let slide: a polite no without a path

If your manager tells you no and won't give you a path — no timeline, no metric, no scope change that would trigger a yes — they're telling you something about the ceiling of this job. That's a data point. File it.

Give it three to six months. If the ceiling holds, start looking. The biggest comp jumps in early career come from switching jobs, not from waiting.

What new grads get wrong

Asking in a group setting. Comp is a 1:1 conversation. Always.

Leading with personal finance. "Rent went up" is not an argument. Your manager isn't setting your pay against your expenses.

Threatening to leave without being ready to leave. If you float a counter-offer, be ready to take it. Once you've said "I might leave," the relationship changes.

Apologizing for asking. Don't. You're running your career.

Asking for a title change as a substitute for money. Titles are cheap. Make sure the title comes with the money, or at least a clear path to it.

—

The raise conversation is one of two or three career conversations where the script meaningfully changes the outcome. Most of your peers will mumble through it and accept the first answer. The version above takes ten minutes to learn and pays out at literally every comp cycle for the rest of your career. Ten minutes. Decades of compounding.

For the weekly habit that builds a raise case without anyone noticing, use the Status update template. For the calibration conversation that precedes the raise conversation, steal the Manager 1:1 agenda.

When you see your first bonus number: what to say in the 1:1 after

Mike Halpert — Sat, 17 Jan 2026 00:00:00 GMT

There's a specific emotional loop most people run the first time they see a bonus number from an American corporate job. You open the letter or the portal. You look at the figure. For about four seconds you feel something — relief, surprise, disappointment, vague confusion about what the number even means. Then you close the window and go back to work, because you don't know what to do with what you just felt.

Most first-year employees say nothing to their manager about the number. They assume the 1:1 after the bonus is just the normal 1:1. It is not. It's one of the most important 1:1s of the year, and most people waste it.

First: understand what the number is

Before you talk to your manager, make sure you know exactly what you're looking at. Bonus letters are often more cryptic than they need to be. You want three things:

What was your target? If your offer letter said "15% target bonus," your target was 15% of base.
What was the payout multiplier? Many companies have a company-performance multiplier (ranges like 80-120%) AND an individual-performance multiplier (tied to your rating). Your payout = target × company × individual.
What are peers getting, roughly? Glassdoor, levels.fyi, sometimes your HR intranet. You want to know if your payout multiplier was high, low, or middle for your level.

Without those three numbers, you can't have an informed conversation. Sit with a coffee and your offer letter for 20 minutes before the 1:1.

The three-question conversation

In your next 1:1, raise it. Don't wait — most managers won't bring it up.

"How did my payout compare to the team?"

Direct and factual. You're not asking to renegotiate; you're calibrating where you are in the distribution. Most managers will answer at a general level: "solidly middle of the team," "top quartile," or "a bit behind — here's why."

If they're vague, press once: "More or less than the team average?" That's usually enough.

"What drove the individual multiplier?"

This is the one most people never ask. The number was chosen. Someone — your manager, maybe in a room with their peers — assigned a multiplier based on a rating which was based on their judgment of your year. You have the right to ask what drove it.

You're not asking for a re-rating. You're asking for the narrative behind the number. That narrative is the most useful development feedback you'll get all year.

Most managers will give you two or three sentences: "you got a 115% multiplier because X and Y went really well; what kept you from being higher was Z." Write Z down. That's the punch list for next year.

"What would it take to be meaningfully higher next year?"

The critical word is "meaningfully." Not "a little higher" — that gets you a flat "keep doing what you're doing." Meaningfully higher forces your manager to name the concrete thing that would bump you from a 115% multiplier to a 130%.

This question often produces the most honest feedback you'll get. "A 130% would usually go to someone leading a cross-functional project, not just executing their own work." Now you know what to aim at.

What not to say

Don't express disappointment, even if you're disappointed. Disappointment in the 1:1 reads as "this person thinks they deserve more than they got" — which may be true but is never the message you want to land in that moment. The right moment for a disappointment conversation is later, separately. Schedule a dedicated 30 minutes for it a week or two later. Do not mash it into the 1:1 after the number drops.

Don't ask for more money directly in this meeting. The 1:1 after a bonus is not the renegotiation moment. Most managers have no authority to change a bonus once it's been approved. Asking puts them in an awkward position and changes nothing.

Don't compare to specific people. "I heard Jake got 130% and I got 115%" is a trap. Even if accurate and you're right to wonder, this comparison comes across as petty.

Don't thank profusely. "Thank you so much, I really appreciate it" is fine in small doses, but if the bonus was less than you expected and you effusively thank your manager, you are signaling that you think the number was generous, which will be quoted back at you in calibration next year.

The asymmetry nobody warns you about

First-year employees often make a disproportionate calibration mistake: they assume bonuses are fair representations of performance, so a smaller-than-expected bonus must mean they performed worse than they thought.

This is usually wrong. Bonuses are pool-constrained. There's a fixed amount of money the team gets to distribute, and someone has to get the smaller slice so someone else can get the bigger one. Even strong performers can get middling multipliers in a year with a small pool, because there's not enough money to go around. The inverse is also true — a great bonus can be a function of a generous pool year, not just your performance.

So treat the number as one data point, not a verdict. The real verdict is what your manager says when you ask Question 2.

—

The bonus letter is a document; the conversation is the value. Most of your peers will read the number, feel something for ninety seconds, and then never bring it up again. The handful who turn it into the three-question diagnostic above will accumulate a year-over-year information advantage that compounds into the next promotion. Same number on the page. Wildly different career trajectory.

For the broader raise-negotiation mechanics that use the same muscle, see negotiating your first raise. For the feedback-collection questions that make next year's bonus conversation better, see the Reader Q on managers who give no feedback.

Your probationary review: 5 questions to pre-answer

Mike Halpert — Tue, 23 Dec 2025 00:00:00 GMT

Most first-job probationary reviews are not about whether you're smart. By Day 90 that's already settled. The review is about whether you're trainable.

A manager wants to know: can I give this person a piece of scope and not worry about it? The review is where they either confirm that answer or get a quiet alarm bell.

The good news: the questions are predictable. Pre-answer them and the meeting becomes a formality.

The five questions (and how to pre-answer them)

1. "What have you shipped?"

You need a list. Not "I worked on the Q1 launch." A list of specific outputs with specific outcomes.

Template per line:

I shipped [thing]. It did [measurable outcome or signal]. The reason it mattered was [team impact].

Aim for five to eight bullets. Mix of big and small. Include "invisible" wins — the process doc you wrote, the Slack recap habit you started, the question you raised early that prevented a bigger problem.

Bring a one-page doc. Email it the morning of the review:

"Wanted to share my first-90-days recap before we meet. Happy to walk through it or skip to the parts you care about."

Managers love this. You just wrote their prep doc for them.

2. "What did you struggle with?"

This is a trap, but a friendly one. "Nothing" makes you look unaware. A long list makes you look fragile.

The right answer: one specific gap, and how you closed it.

"My first month, I was slow on [tool / domain / process]. I spent two weeks going through [specific thing] and pair-coding with [person], and I'm now doing those tickets at the team's normal speed."

Translation: "I noticed a gap, I had a plan, I executed." That's what they want to hear.

3. "What do you want to work on next?"

Have one concrete answer. Not "more responsibility." A specific piece of scope that would be a stretch.

"I'd like to own the weekly [recurring thing] end-to-end next quarter. I've been shadowing [person] on it for six weeks. I think I can take it cleanly, and it would free up [their] time for [higher-leverage thing]."

That answer shows three things: you know what's happening around you, you know what's valuable, and you've already been doing the pre-work.

4. "What do you need from me?"

Most juniors answer "nothing, I'm good." Don't. Your manager is asking what the coaching looks like:

"Two things. First, faster feedback on drafts — I'd rather hear 'this is off' at 30% than at 90%. Second, I'd like to sit in on [meeting type] so I can see how decisions get made one level up."

Specific. Coachable. Doesn't cost them much.

5. "Where do you see yourself in a year?"

This one gets answered badly a lot. "I want to be promoted" is lazy. "I want to be a VP someday" is cringe.

The right answer is tied to the role, not to a title:

"In a year, I'd like to own [specific scope] independently, be the go-to person on [specific domain], and be mentoring the next new hire on [specific thing]. I'm not in a rush on titles — I just want the scope to keep growing."

That reads as mature. It's also easier for your manager to engineer, because it's specific.

The two questions you should ask

The review is a two-way conversation. Your prep isn't complete without these.

"What would make me 'easy to promote' when the next cycle opens?"

If the answer is vague ("just keep doing what you're doing"), push once: "Is there a specific scope or behavior that would change the answer to yes if someone asked?"

"If you could change one thing about how I operate, what would it be?"

Your manager has a piece of feedback they've been saving for the review. Ask for it directly and they'll give it to you — better than hearing it in six months after it's already hurt you.

The 24 hours before

Send the one-page recap the morning of
Re-read your last eight weeks of Slack messages and PRs. Pick two quotes or moments that show the story you want to tell
Write your "struggles" answer out loud. The first time you say it should not be in the room
Don't send the recap to your skip-level. Just your manager

The 24 hours after

Send a follow-up email summarizing what you heard: priorities for the next quarter, any commitments on either side. One paragraph
If you heard something surprising, don't respond that day. Sit on it overnight
If you got a promotion signal, write down the exact criteria you heard. Save it. Reference it at the next review

If the review goes badly

A bad probationary review is not a firing. It's a warning with a timeline. Three moves:

Ask for it in writing. "Can you send me the two or three areas we discussed so I have them clearly?"
Ask for a 30-day check-in. Not the next quarterly review. Sooner.
Pick one area and visibly fix it in the next two weeks. Progress on one thing beats incremental progress on three.

If it feels off-track after a real effort, that's also useful data. The best time to start looking for the next job is when you still have this one.

—

The review meeting your manager dreads running is not the one where the recap doc shows up in their inbox at 9am. Spend the prep time, walk in with the five answers, and you've turned a meeting they were nervous about into a meeting they're impressed by. Same 30 minutes on the calendar. Wildly different outcome on the rating.

For the weekly update habit that makes the recap easy to write, use the Status update template. For the 1:1 structure that builds the relationship the review depends on, use the Manager 1:1 agenda.

A reader asks: I'm benched as a first-year consultant — am I going to get fired?

Mike Halpert — Thu, 04 Dec 2025 00:00:00 GMT

The question (paraphrased from r/consulting):

I'm a first-year consultant at a mid-tier firm and I've been on the bench for almost three weeks. My last project wrapped early, utilization reports are coming out, and I know my staffing lead is aware. People keep telling me the bench is "normal," but I also keep hearing horror stories about first-years getting counseled out after long benches. How worried should I be, and what should I actually be doing with this time?

Three weeks isn't the problem. Three quiet weeks is the problem.

The bench is normal. The bench plus radio silence is where firms decide you're not their best draft pick. Your staffing lead is currently building a quiet impression of you based on the emails you didn't send.

Good news: you have ~2 weeks to flip the impression.

What's actually happening at your firm right now

When a first-year goes on the bench, three things happen behind the scenes simultaneously:

Your staffing lead is matching warm bodies to projects.
Your last project's senior is deciding whether to keep mentioning you or stop.
The performance committee is glancing at utilization reports without context.

You can influence #1 and #2 directly. #3 is downstream of both.

Week 2: stop being a passive resource

Two specific moves.

Make yourself reachable to more than your staffing lead. Pick 2–3 senior people you've worked with — or who run practices adjacent to yours — and send a short individual note. Not a group blast. Three personal sends:

"Hi [Name] — wrapping some bench time after [last project]. If anything comes up in [practice area], I'd love to be considered. Happy to send a quick summary of what I did on [last engagement] if useful."

Each one plants a name in someone's head who might think of you next week. Your staffing lead is not the only routing layer in the firm. Pretending they are is how first-years stay benched.

Start a visible bench project. Not "skill development." Not reading. Something with an artifact attached to your name, useful to your practice. Some shapes that work:

A short deck on a trend in your vertical (15 slides, no more)
A reusable template the team uses constantly but nobody's standardized — exec summary, stakeholder interview guide, post-project readout
A rewrite of a problem from your last engagement: "if I redid the [project], here's the approach I'd take now."

Post it in the right Slack channel. Send it to two seniors you want on your side. The point isn't the deck. The point is leaving evidence that you treated the bench as work, not as a vacation you got mad about.

Week 3: more visibility, more specificity

Send your staffing lead a different ping than the one you sent in week 1:

"Checking in on staffing. Still open for anything; I've also been using the bench to put together [thing], which I'll share shortly. Happy to flag where I'd fit best — I think [practice X], [Y], or [Z] given my last engagement."

Three things in that message: you're visible, you're productive, you're specific about where you'd land. Specificity is everything to a staffing lead. Vague availability is what every benched first-year offers; specificity is what gets you onto a project.

What "first-year counseled out after a long bench" usually means

The bench itself almost never gets you cut. The bench plus one of these does:

Soft ratings on your last project. If the feedback was lukewarm, the bench is the firm's window to decide whether to keep investing in you. You should already know if this is your situation. If you don't, ask the senior on your last project directly: "Is there feedback I should be working on? I'd rather hear it straight." That conversation is awkward. Skipping it is more awkward, six months from now.

No senior sponsor. If you finished your last project and never followed up with the senior who liked you, they're not thinking about you when staffing comes around. Recoverable in one email.

Practice with no demand. Sometimes the bench is structural. Your practice is genuinely slow and everyone is in the same boat. The move is to get fluent enough in an adjacent area to be staffable there too — but that's a months-long pivot, not a two-week sprint.

If you're worried it's option 1, the answer is to find out, not to spiral.

What to stop doing

Three things first-years on the bench do that make it worse:

Reading the utilization report daily. Lagging indicator. Watching it doesn't change it. Close that tab.
DMing peers about "is your bench this bad too?" This is how panic becomes a group activity, and it gets back to staffing in ways you'd be surprised by.
Taking "the bench is normal" entirely at face value. True on average. Your firm has its own version of average, and "normal" varies wildly by practice and partner.

The one question to ask your staffing lead

In your next bench check-in:

"Is there anything specific I should be doing more of, or less of, to be easier to staff?"

The question converts a vague am I in trouble? feeling into actual data. Either they give you something concrete (a goldmine — go work on it) or they say "no, just waiting on the right project," and now you can actually relax. Either answer is better than the silence you're currently living in.

—

The cohort that makes it through year one isn't the smartest one. It's the cohort that figures out fastest that consulting careers are managed by you, by name, in writing, repeatedly, in ways that feel slightly cringe. Your staffing lead has too many bodies to keep track of. Make yourself the easy one to remember.

For the update rhythm that makes you visible without being annoying, use the Status update template. For the staffing-lead 1:1, lift the Manager 1:1 agenda — same shape applies.

—

If you have a question like this? Send it in. Anonymity guaranteed.

A reader asks: is it normal to be scared of my skip-level?

Mike Halpert — Tue, 11 Nov 2025 00:00:00 GMT

The question (paraphrased from r/Big4):

My skip-level is about to schedule a "getting to know you" 1:1 with me. She's a senior partner. Every time I pass her in the hallway I get nervous. I respect my own manager but I can actually talk to him. With her I feel like I shouldn't open my mouth. Is this normal?

Yes, it's normal. It's also useful, in small doses.

Being scared of your skip-level is a signal that you know she's higher-consequence to talk to. That's true. What she thinks of you matters more than what most of your peers do. You are right to take the conversation more seriously.

The problem isn't the respect. It's when the respect turns into paralysis — when you'd rather avoid the conversation than have it. That's the version that actually costs you.

The skip-level is not evaluating you the way you think

The biggest mistake new hires make before a skip-level is assuming the meeting is an evaluation. It isn't, usually. Your skip-level is not trying to decide whether you're any good. She already knows, roughly, from your manager and from whatever she's observed.

Senior leaders usually have three reasons for skip-level 1:1s:

She wants information her team layer isn't fully giving her. What's the team actually working on? What's the morale like? What's being deprioritized? You are a data source for her, not a candidate.
She wants to build a weak-tie relationship so that when she needs to reach into her organization, she has names and faces, not just levels on an org chart.
She wants to show up in your narrative as a senior sponsor, because that helps retention and helps her influence where attention goes.

None of those three things require you to perform.

The three questions she's most likely to ask

Prepare one answer for each. Two to four sentences.

"How are things going?"

This is the opener. Do not answer "great!" The skip-level did not schedule a 30-minute meeting to hear "great."

"Mostly good. Most of my time's been on [project]. The piece I'm most excited about is [X]. The thing I'm working through is [Y] — I've got a path on it, but it's been the harder part of the quarter."

Specific, honest, not complainy, names one thing you're navigating. This is the shape of the answer she's looking for.

"Is there anything I should know that I might not be hearing?"

This is her actually asking you to tell her things her team isn't telling her. You can be useful here without being a rat. Some fair categories:

Team morale signals you've noticed. "People seem pretty tired after the Q1 push. Not sure if that's registering at your level."
Confusion about strategy. "I think there's still some team-level uncertainty about what the Q2 priorities actually are."
Process friction. "The engineering-design handoff has been rougher than usual — we're getting it done, but it's a lot of interpersonal cost."

Do not name individual people as problems. Do not dish on your manager. Think of yourself as giving her temperature data, not performance reviews.

"Where do you want to be in a year?"

She's not going to judge the answer. She'll judge whether you've thought about it at all.

The worst answer is "I don't know yet, I'm just focused on doing my job well." That's a new-hire non-answer.

Better: "A year from now I'd want to be owning [X] end-to-end, and contributing more to [Y]. I think the biggest thing I need to develop is [Z]."

You don't have to be right. You have to have thought about it.

What to actually wear mentally into the room

Three small shifts that make a difference:

She is a person, not an office. She also had a first-year-fear of her skip-level once. Everyone in the building did. Ask her a personal-but-professional question at some point: "What's the thing you're most interested in right now that isn't on your team's roadmap?" She'll brighten.
Match her register, don't try to be more formal than she is. If she jokes, allow yourself to laugh. If she uses first names, use hers. Senior people disarm new hires by being human; don't stiffen up in response.
Come with one real question. Not a flattery question. "I've been curious about [specific strategic thing]. What was the thinking behind it?" That shows you're paying attention to the same level she's paying attention to.

Afterwards: the follow-up note

Within 24 hours, send one email or Slack:

"Thanks for the time today. One thing I want to follow up on — you mentioned [specific thing]. I'd love to dig into it more. Here's [short related thought or link]."

That follow-up makes the meeting stick in her memory and builds a thread she can reference later, which matters more than most people realize.

When the fear is actually telling you something useful

Being scared of your skip-level can be diagnostic. Ask yourself: what specifically am I scared of?

If it's "I'm scared of saying something dumb," that's normal first-year nerves. Manageable.

If it's "I'm scared she'll find out I don't actually know what I'm doing," or "I'm scared she'll ask me a question about [X] that my manager should have answered and didn't," the fear is pointing at a real gap. The fix isn't to avoid the skip-level. The fix is to go to your manager and get the briefing you need.

"I've got the skip-level 1:1 with [her] on Thursday. Anything specific you think she'd want to hear from me? Anything you want me to reinforce or be careful about?"

Good managers love this question. Great ones preload you with two or three things.

—

The skip-level fear evaporates in a specific moment that you'll remember years later: the first time you realize she's just a person with a calendar like yours, who's interested in what you're working on, and who would prefer you to be honest rather than polished. That moment is on the other side of one good conversation. The version of you that forces yourself into that conversation gets a sponsor for the next ten years. The version that hides in the bathroom doesn't.

For the "end the meeting well" move that also works at the skip-level, see the one sentence that ends a good 1:1. For the general structure of a senior 1:1, the secret to good 1:1 meetings still applies.

—

If you have a question like this, send it in. Anonymity guaranteed.

How to get promoted when there's no clear ladder

Mike Halpert — Sun, 26 Oct 2025 00:00:00 GMT

At big tech companies and consulting firms, the ladder is basically a document. You can read the L3-to-L4 criteria on a wiki. You know what "scope," "impact," and "sphere of influence" mean at your level and the next. Promotion becomes a game of accumulating evidence against a rubric.

At most other companies, there is no document. The ladder is a conversation between your manager, your manager's manager, and sometimes HR, happening twice a year, informally, with criteria that are partly written and mostly vibes. If you sit there waiting for a document, you will wait forever.

This is not a flaw of smaller or less mature companies. It's a common state. The promotion path at most places in the US corporate world is built on conversation, not criteria. You have to run the conversation.

Here is the playbook.

Step 1: Build the sentence

Before any of the rest of the work matters, you need a single sentence that describes what makes you promotable. Not a bullet list. A sentence.

The shape:

"I'm the person who [specific capability], which [organizational outcome], and I'm ready to do [next-level version] because [evidence]."

Example:

"I'm the person who runs our monthly business review, which has changed how our VP thinks about renewals, and I'm ready to own the quarterly exec recap because I've already been drafting the underlying narrative for the last two quarters."

That sentence does four things at once: names a specific capability, a concrete impact on someone senior, the next-level work, and evidence that you've already been doing parts of it.

If you cannot write this sentence for yourself, you don't have a promotion case yet. That's fine — it just means your first month of work is building the sentence, not campaigning.

Step 2: Make the sentence visible

Once you have it, it needs to be the first thing your manager thinks when your name comes up. The only way that happens is if they've heard it, in your voice, multiple times.

Three places to say it:

In your monthly 1:1 framing. Not as an explicit ask. As context. "Quick update on where I think I am — I've been doing more and more of X, and I'd love to keep pushing in that direction." Your manager begins to hear a narrative.
In the written self-review at cycle time. Most people under-sell themselves here. The self-review is a document your manager copies from heavily. Write the sentence, clearly, and back it with three concrete examples. Make it easy for them to lift it into their own review of you.
In your status updates. Over time, the pattern of what you volunteer to work on and what you flag as progress tells its own story. If the story aligns with the sentence, the narrative becomes real.

You're not campaigning. You're giving your manager the draft of a story they can tell on your behalf.

Step 3: Make the sentence true for the next version of you

The most common mistake is to campaign for a promotion based on what you've already done without having started doing the next-level version. The answer a calibration committee is usually looking for is not "has this person performed at their current level well?" — it's "is there evidence they're already performing at the next level?"

Start acting at the next level a quarter before you expect to be promoted. Volunteer for the project that's a stretch for your current level. Write the doc that a more senior person would usually own. Speak up in the meeting where you'd usually be silent.

Your manager needs to see you, in the room, doing next-level work. Not just hearing about it in 1:1s.

The practical version:

Identify one thing someone a level above you currently does that you could credibly take a piece of.
Propose to take it. "I'd love to take a first pass at the quarterly exec deck if you'd like — could be useful for me, and it'd save you a pass."
Do it well enough that your manager comes to expect it from you.

Six months of doing that is more promotion-relevant than two years of doing your current-level job perfectly.

Step 4: Have the direct conversation

At most fuzzy-ladder companies, people get stuck waiting for the promotion conversation to happen spontaneously. It usually doesn't. You have to start it.

Around the six-month mark of doing the stretch work:

"I'd like to start working toward a promotion within the next [12/18] months. Can we talk about what the specific gaps are? I'd rather hear the real picture so I know what to work on."

Three things make that sentence good:

"Working toward" is the frame, not "I want this now." You're asking for a trajectory, not a grant.
The time horizon is realistic. 12-18 months is long enough that the conversation isn't awkward.
"What are the gaps" invites honesty. Your manager has gaps in mind. This is the question that lets them name them.

Take notes. Write down what they say. This is your punch list for the next year.

Most managers, asked this way, will be more specific than you expect. Some will be vague — escalate the specificity: "If you had to name two concrete behaviors or outcomes that would move me from here to there, what are they?"

Step 5: Accept that some of this is political

Fuzzy-ladder promotions involve visibility to people other than your direct manager. Your skip-level has to know who you are. Your manager's peer managers have to have heard your name. The ways to build this are slow and cumulative:

Volunteer for cross-functional projects. Not because they're glamorous but because they embed you in more rooms.
Present at team or all-hands meetings. Once a quarter if you can.
Send a quick written recap of a meaningful project to the room, including your skip. "Wanted to close the loop on the [project] work — here's what we shipped, here's the measured impact." It's a cheap way to be remembered.
Build a relationship with one HR partner or a cross-functional senior. One mentor one level up from your manager is worth more than ten peers.

You are not playing politics. You are making sure the people who weigh in on your promotion case have data on you when the conversation happens.

Step 6: Negotiate the title and the comp separately

One thing nobody tells you about fuzzy-ladder promotions: sometimes the company will give you the title but under-pay the raise, or give you a strong raise but keep the title. Both are possible moves. When your manager tells you you're being promoted, ask two questions:

"What's the change in title and level?"
"What's the change in compensation?"

If the answer to the second one is significantly behind what a same-title hire would be paid externally, you have room to negotiate — politely, specifically, with market data. "Thanks, this is great — I want to make sure we're in the same place on comp. The external market for this title is around [X]. Is there flexibility?"

Most companies, asked directly, have more flexibility than they led with. Always ask. Not as a threat. As a question.

—

The fuzzy-ladder companies aren't actually harder to be promoted at than the rubric companies. They're just harder to be passively promoted at. Run the playbook above for twelve to eighteen months and you'll find that most of your peers are doing the version where they wait, complain in private, and assume someone will notice. Someone might. Probably won't. Make it easy for them to.

For the broader compensation-driver frame, see negotiating your first raise. For the 1:1 structure that makes these conversations natural, see the Manager 1:1 agenda.

A reader asks: my coworkers never use video — should I?

Mike Halpert — Thu, 09 Oct 2025 00:00:00 GMT

The question (paraphrased from r/cscareerquestions):

I joined a new team a month ago and I'm the only person who turns my camera on in meetings. Everyone else — including the manager — is just a static avatar. I don't want to be the weird new person with the camera, but I also don't want to be invisible on a fully remote team where the only other signal I have is how I type. What do I do?

You've correctly identified that camera-on/off isn't actually about cameras. It's about legibility — how new people become visible to a team, and how teams trade face time for focus time.

The right answer is almost never "match exactly what everyone else does." It's "match the direction of the norm while protecting your visibility window."

First, read the norm correctly

Camera culture splits into four patterns. Figure out which one you're in before you change anything.

Default off, everyone. Fully async, deep-work culture. Camera on reads as "making this meeting a bigger deal than it needs to be." Usually engineering teams, especially infra and backend.

Default off for engineers, on for cross-functional. Mixed. Engineering internal = avatars. Product review with stakeholders = cameras on. If you don't know which kind of meeting you're in, default to whatever the most senior person does.

Default on, one or two holdouts. Usually business/operator-heavy teams. Cameras-off here reads as "checked out" unless the person has a known reason.

Intentionally flexible. A few teams explicitly say "cameras optional." The hardest to read, because the real norm is hidden under politeness. Observe for two weeks, then match your manager's pattern.

From what you've described — manager and everyone off — you're in pattern 1 or 2. Which means: you being the only one on camera is the problem, not the solution.

Why camera-on-when-everyone's-off is costly

Three things happen you probably aren't seeing:

It's performative. On a team where nobody else is on camera, yours reads as "I'm the one trying to look engaged." That's the opposite of the signal you want. The strongest performers on a video-off team are confidently video-off; they don't need the camera as a presence indicator.
It makes meetings slightly more awkward. Others feel the asymmetry even if they don't comment on it. Small thing, but it accumulates.
It limits your speaking range. When you're the only visible face, you self-regulate more. You interrupt less. You nod more. You behave like the only student at a seminar with their hand up.

None of those are disasters. But they're real.

The better visibility strategy on a camera-off team

Camera isn't your visibility mechanism on a team like this. These are:

Written communication. A team that doesn't use video lives in Slack, docs, and PRs. The best writers become the most visible people. Spend your visibility budget there.
Recorded audio presence. When you do speak, speak with clarity and brevity. Three good audio contributions per week outperform five hours on camera.
Async updates. Send a short Friday recap in your team channel, even if it's not the norm. It will be read. You will be remembered.
Post-meeting notes. Be the person who types the action items in the thread after the meeting. Costs you five minutes, makes you the "I know what's going on" person for the whole team.

Move your visibility budget from your face to your writing and your audio, and you'll be dramatically more visible than a camera-on person who otherwise stays quiet.

When to turn the camera on anyway

A few situations where camera is worth it even against the team default:

1:1 with your manager. Almost always worth it, unless your manager keeps theirs off. Relationship density matters more in 1:1s than in group calls.
First week of a new team. On for your first 3-5 meetings so people can put a face to the name. Then match the norm.
When you're presenting or leading. If you're driving, the camera makes your presence legible.
Cross-functional or external meetings. Default to on, especially with clients, candidates, partners.
Hard conversations. Performance discussions, disagreements, emotionally loaded topics.

How to transition without it being weird

Don't narrate it. Don't Slack your manager "hey should I turn my camera off?" Just, in the next meeting where you're not presenting, turn it off. Nobody will mention it. Nobody will notice, honestly.

If you want to be neat about it, use your first camera-off meeting to signal audio presence more strongly. Say something in the first five minutes. Make one clear contribution. The shift from "visible and quiet" to "invisible and audible" is the one you're making.

Why this matters more for foreign professionals or introverts

If you grew up in a culture where formality means visibility — standing when a senior speaks, making eye contact as a sign of respect — the "everyone's off camera" US engineering meeting can feel rude, and your instinct to stay on camera is partly defensive. Two reframes:

Camera off is not disengagement in US engineering culture. It's focus. People are often coding in a second window while listening. That is normal and not considered rude.
The replacement signal is written and verbal, not visual. Post-meeting summaries, high-quality PR reviews, crisp Slack messages. That's your engagement signal on this team.

Same job, different medium. Shift the signal, don't multiply it.

—

The instinct to stay on camera when everyone else is off is rarely about cameras. It's about feeling new and wanting to be seen — entirely fair, completely human. The fix isn't more visibility. It's the right kind of visibility for the team you're on. Match the medium they actually use, and you'll be the well-integrated new hire instead of the eager one.

For the written rhythm that becomes your visibility mechanism on a video-off team, use the Status update template. For the 1:1 where camera-on stays worth it, use the Manager 1:1 agenda.

—

If you have a question like this, send it in. Anonymity guaranteed.

What to do when you get sick in your first 90 days

Mike Halpert — Sun, 14 Sep 2025 00:00:00 GMT

Getting sick in your first ninety days feels higher-stakes than it is.

You're new. You don't know the norms yet. You worry that taking a day will register as "first-year who can't hack it." So you half-work through the fever, send a couple of replies that don't quite make sense, and everyone comes away mildly worried about you.

Don't do that. Sick days are normal. Managers expect them. The only thing that goes wrong in your first ninety days is not the sick day — it's how some new hires handle it.

The morning-of message

Send it early. Before the day starts, not two hours into the morning. Keep it short. Give your manager three things and nothing else.

Hey [Manager] —
Woke up with a bad cold / stomach bug / etc. Going to take today
to rest. I'll check messages briefly mid-morning to flag anything
urgent, but I'll be offline otherwise. If anyone needs X today,
Sarah has the context.
Back tomorrow (or will update you in the morning if I'm not).

What's in there:

What's wrong, one phrase. Cold, stomach bug, migraine, injury. "Not feeling well" is vague enough to sound fishy. "Cold" is honest and specific enough that nobody wonders.
The plan. "Taking today to rest" is a plan. "I might try to work a little" is not a plan and worries your manager.
Coverage. If something concrete needed you today, name the backup. Shows judgment.
When to expect you back. Default to tomorrow. If you'll need more, say so now — don't stretch one-day-at-a-time.

Send it. Then stop managing the office.

The thing to absolutely not do

Don't try to work sick from home unless you genuinely have to and can actually function. The output you produce with a fever is unreliable. The emails you send are worse than the emails you'd send not sick. The Slack messages you type half-conscious are the ones coworkers remember awkwardly for a year.

Your manager would rather you take a real day than send low-quality output pretending everything is fine. "I worked through it" is not the badge you think it is in your first year. "I took the day, came back clear-headed Wednesday, and shipped the thing" is a better story.

How many days is normal

In most US corporate jobs:

One honest day, clear message, clear-headed return: normal. Nothing to explain.
Two or three days for a cold or flu, with clear comms: normal.
A week+ without clear communication: concerning. If you'll be out more than three days, tell your manager on day two, not day five.
Frequent single-day absences without a pattern: can look avoidant. If you're chronically dealing with something, it's worth a one-time conversation framed as "I've had a few rough weeks with allergies / migraines / etc., didn't want you wondering."

Don't try to hide a recurring issue by camouflaging it as one-off days. Managers notice the pattern eventually, and it's worse when they've noticed without you naming it.

What to do while you're out

Rest.

If you're really bored: nothing. Watch TV. Sleep. Do not answer Slacks, do not "just quickly send this email," do not check in halfway through the day to prove you're virtuous. The day off is the product.

One exception: if something blows up that genuinely only you can unblock — a client escalation, a deploy gone wrong — triage briefly, hand it to someone, return to rest. Don't try to fully handle it.

The return-to-work message

The day you come back, low-key:

Hey [Manager] — back today. Caught up on the most urgent threads.
Picking up X and Y first; Z slid to later this week — I'll shift
the timeline in the doc. Let me know if priorities moved while I
was out.

Three lines. You're oriented, you're picking up the work, and you've proactively flagged the one thing that slipped. That last piece is the move most people skip. Acknowledging the slip upfront saves your manager from having to ask.

Do not apologize profusely. "I'm so sorry for being out, I really feel terrible about it" makes your manager feel weird. You were sick. You took a sick day. You're back. A short, oriented message is what they want.

What your manager is actually thinking

Most managers react to first-year sick days in one of three ways:

"Thanks, feel better." That's 85% of the time.
"Is everything okay?" When they're being genuinely kind. Not a trap.
"Huh, that's two sick days in three weeks." When there's a pattern. If you see this, it's time for the "by the way, here's what's going on" conversation.

Very few managers secretly judge first-year sick days harshly. The ones who do are the same managers who'll find something else to judge harshly, and there's no game you can play that makes it better.

—

I've watched first-years burn three days of credibility by trying to push through illness instead of taking the one day. The math is bleak: you produce 40% of your usual output, look 80% as competent, and use 100% of the energy. The sick day is the strictly dominant strategy. Take it.

For the first-week rhythm that builds enough credit that a day off doesn't feel costly, see the Week 1 Checklist. For the broader first-90-days system, see the First 90 Days OS.

A reader asks: I'm in FP&A and want to pivot to IB — is it too late?

Mike Halpert — Sat, 23 Aug 2025 00:00:00 GMT

The question (paraphrased from r/FinancialCareers):

I've been in FP&A at a mid-sized tech company for almost two years. I like the work, but I'm realizing I want to get into investment banking — M&A specifically. I went to a decent state school (not a target), I don't have a CFA, and I'm 24. Half the threads I read say "pivot now, analyst programs still recruit 22-year-olds" and the other half say "it's too late unless you do an MBA." Which is it?

The honest answer sits between the two extremes. It's not too late. It is harder than it was a year ago, and harder than it would have been if you'd gone direct out of undergrad. The right pivot at 24 with two years of FP&A is not "apply to analyst programs." It's "engineer yourself into an associate-adjacent track through a specific mechanism" — and there are three mechanisms that actually work.

Why the internet disagrees

The "it's too late" crowd is pattern-matching to the traditional path: target school → analyst stint → associate promotion. Every year you're away from that path, the door narrows.

The "pivot now" crowd is pattern-matching to the existence of a few specific off-cycle routes that do work for corporate finance people in their mid-twenties.

Both are right. The question is which mechanism to target, and the answer depends on how much time you're willing to commit and what you're optimizing for.

The three mechanisms that actually work

1. Off-cycle analyst at a boutique or middle-market firm

What it is: Lateral into a 2–3-year analyst track at a boutique M&A shop, a middle-market bank, or a regional firm. Not Goldman or Morgan Stanley — think Houlihan Lokey, Harris Williams, William Blair, Piper Sandler, or smaller regional players.

Why it works: These firms hire off-cycle more often than bulge brackets. They value finance experience over pedigree, especially if you can talk about deal-like work (corporate development, treasury modeling, M&A integration, pricing analysis).

What you need:

A strong modeling story. Not "I built FP&A models." Specific: "I built a three-statement model for a potential acquisition that informed the CFO's go/no-go recommendation on a $X deal."
Clean technical prep (LBO, DCF, accretion/dilution). If you can't build an LBO in 40 minutes under pressure, you're not ready. This is 200–300 hours of prep for most people.
Named targets. Research 15–20 firms. Know their recent deals. Pick three you'd seriously join.

What you don't need: CFA. Top-tier MBA. Target school pedigree. These firms index on modeling ability and deal enthusiasm.

Timeline: 6–9 months from "start prep" to "sitting across from an MD."

2. Corporate development → IB (less common, but real)

What it is: Move from FP&A to an internal corporate development team (in-house M&A) first. Work on real deals from the buy-side perspective for 12–24 months. Then lateral into an IB associate role on the back of deal experience.

Why it works: Banks hire corp dev people as associates because they show up with live deal reps. You're no longer "FP&A with potential" — you're "someone who's run an LOI process from the buyer side."

What you need: Your current company has a corp dev function (or you can lateral into one). The ability to wait 2–3 years on this pivot.

Timeline: 2–3 years.

3. Top MBA → associate program

What it is: The well-worn path. M7 or T15 MBA, summer at a bank, full-time associate offer.

Why it works: Banks reset their view of you through the MBA brand. You are no longer "non-target FP&A at 24." You are "Booth '28."

What it costs: Two years, $200K+ all-in, and the opportunity cost of not earning. Also non-trivial GMAT/GRE time and application effort.

When it's right: If you decide IB is a long-term career and not a stint, or if you want the full associate-track trajectory with maximum optionality. At 24 with your profile, you're well-timed for a 2-year MBA.

What you should be doing in the next 90 days, regardless of path

1. Learn the technicals cold. Rosenbaum & Pearl's Investment Banking is the gold standard. Work through it over 60 days, with a spreadsheet open. Build an LBO from a blank sheet at least three times.

2. Source deal reps at your current job. Go to your CFO or head of strategic finance:

"I've been thinking about moving into corporate finance longer-term. Is there a way I can get involved in the more strategic projects — M&A analyses, business case work, scenario modeling for big decisions?"

Most FP&A managers will say yes. That work becomes your "deal-adjacent" story on a banking resume.

3. Start networking, in a specific way. One informational conversation per week with a banker. Target people 3–5 years ahead of you at firms you'd seriously want to join.

"I'm in FP&A at [Company] and seriously considering a move into banking. I'd love 15 minutes to ask a few questions about your path and the associate vs. off-cycle analyst decision. Happy to work around your schedule."

4. Decide which path, within 90 days. Running all three in parallel is how people spend 18 months doing nothing.

The hard truth on state school + no CFA + 24

Neither item is disqualifying. Plenty of bankers came in from non-target backgrounds, especially at boutiques and middle-market firms. The age is fine at 24; you'd be older than the standard analyst class by a year, but not by three.

The CFA doesn't matter for IB as much as people on Reddit say. Level 1 is a fine signal of effort. Nobody in banking cares whether you have Level 3. Spend your prep time on modeling instead.

If you don't get there

A common thing happens: people do 6 months of this prep, have the informational conversations, and realize they don't actually want IB. They want the skills of IB — modeling, deal work, strategic thinking — which can be picked up in corp dev, PE-adjacent roles, strategic finance at a bigger company, or even advanced FP&A.

That's not a failure. That's the prep doing its job. Make the decision with real information, not with Reddit fumes.

—

The most frequent way this pivot fails isn't lack of skill. It's lack of commitment. People hedge for eighteen months — "I'll see how the prep goes," "I'll keep my options open" — and end up with neither IB nor a clean alternative path. Pick one of the three mechanisms above by the end of next month, and run at it like you've already accepted you might fail. That's the version that works.

For the weekly rhythm that makes "deal-adjacent" work visible on your FP&A resume, use the Status update template. For the manager conversation where you ask for strategic-finance scope, see How to ask for more work.

—

If you have a question like this, send it in. Anonymity guaranteed.

A reader asks: my onboarding buddy has gone AWOL — what now?

Mike Halpert — Sat, 02 Aug 2025 00:00:00 GMT

The question (paraphrased):

I started three weeks ago at a mid-sized tech company. My manager assigned an onboarding buddy, and for the first week and a half he was great — answered questions on Slack, walked me through a couple of systems. Then he basically vanished. Two unread Slacks, one "sorry, slammed — will get back to you tomorrow" that was four days ago. I don't want to be that new hire who complains, but I'm stuck on two things and don't know who to ask.

This happens to maybe 40% of new hires. Buddy programs work great until the buddy hits a busy week, a project lands, and you become the lower-priority obligation on their list. Not malice. Just gravity.

Three moves. None of them involve complaining about your buddy.

1. Stop treating one person as your only source

The first instinct when the buddy goes dark is to try harder with the buddy. More pings, more "hey sorry to bug you." This rarely works, because the buddy is busy and now feels guilty, which makes them avoid the Slack thread instead of engaging with it. You've created an awkwardness loop.

Let him off the hook in your own head. Your job isn't to fix his calendar. Your job is to find people who'll actually answer.

In rough order of cost to other people:

Your team's shared channels. Most of your stuck questions have already been asked by someone before you. Search before pinging anyone. The answer is often right there in October's threads.
The documented onboarding guide, if there is one. Even if it's outdated, it's a starting point.
Other recent hires. Anyone who joined in the 90 days before you remembers what it's like — and they're disproportionately willing to answer because they recently had your exact questions. Find them on the team page and Slack them directly.
Peers in adjacent roles. If your buddy was supposed to show you how something works, the person who most needs you to know is usually your closest peer, not your assigned buddy.
Your manager, for blocking questions only. Save manager asks for things actually blocking work — not "which Confluence page do I start with."

Your buddy was one tile in the onboarding mosaic. The mosaic still works without him.

2. Translate "I'm stuck" into 30-second questions

If you're stuck on two things, resist the urge to send "I'm stuck, can we chat?" That's a costly ask. It requires a meeting. Most busy people will not schedule a meeting with a new hire on short notice — they'll respond on the "I'll get to it when I can" timeline, which is never.

Instead, translate each stuck question into something answerable in two lines:

"What's the right Confluence/Notion space for [X]?"
"Is [Y] something we use a standard template for, or does each team do it their own way?"
"Who owns [Z] — I've got a question about it but don't want to go to the wrong person."

Send five of these to different people. Get four answers within a day. The bad version is one big "can we hop on a call" message that sits unanswered for a week.

3. Tell your manager — about the work, not the buddy

This is the step most people get wrong. They either say nothing and drift quietly for weeks, or they say "my buddy has been unresponsive" and force the manager into a messy political situation with someone who was trying to help.

Bring up the two things you're stuck on. Don't bring up the person.

"Want to flag a couple of things I'm trying to get unstuck on. I'm looking for the right way to run [X] — couldn't find a clear pattern in the docs — and I need to understand how the team handles [Y]. Any chance you could point me at who would know?"

Your manager solves it in 30 seconds by naming two people or sending two Slack intros. You didn't complain. You didn't make the buddy's issue visible. You got unstuck. If the buddy pattern continues past week four, your manager will usually notice on their own — they see their team's activity — and adjust.

Six months from now, when you're well established, you can share the observation casually: "by the way, the buddy program was a little hit or miss for me — is there a version that works better?" That conversation, from an established employee, produces action. The same conversation from a three-week-old new hire produces eye-rolls.

The thing that feels unfair

Your buddy was assigned to help you. He's not doing it. You should not have to do extra work to compensate.

All of that is true and none of it matters for the next ninety days. The job is to get up the ramp. The onboarding program is one of your tools, not your entitlement. If one tool is broken, you pick up others. The people who accept this early and find their own way tend to integrate faster than the people who wait for the program to work.

—

The cohort that ramps fastest in any new role is the cohort that figured out by week three that onboarding is something you do TO yourself, not something done to you. Your buddy was a bonus, not the system. Build the system around him.

For the broader first-week plan that builds this kind of self-sufficiency, see the Week 1 Checklist. For the 30/60/90 version that anchors your ramp with or without a buddy, see the 30/60/90 plan.

—

If you have a question like this, send it in. Anonymity guaranteed.

Your first performance review: what actually changes after

Mike Halpert — Mon, 14 Jul 2025 00:00:00 GMT

People over-index on the rating in their first performance review. The rating matters — it usually determines whether you get a raise, what size, and in some companies whether you're in line for the next promotion. But the rating is the headline. It is not what actually shapes the next year of your career.

What shapes the next year is what the review sets in motion. Three things, specifically.

1. Your manager now has a written story about you

Before the review, your manager had an evolving, slightly fuzzy picture of who you are. After the review, they have a document they had to write about you that HR has now filed. That document has a thesis. It names two or three strengths and one or two areas to develop.

That thesis becomes the prior for everything that happens next year. Performance reviews are sticky in a way most first-years don't realize. If your manager wrote "strong analytical skills, needs work on stakeholder communication," that's the lens they're going to use to interpret everything you do for the next twelve months. Good work on a deck will be filed as "still the analytical one." A decent stakeholder meeting will be noticed as "working on the development area." A bad stakeholder meeting will get more weight than it would have pre-review.

The move in the first 30 days after the review is to consciously build evidence against the development area. Not perform against it — build real evidence. One specific stakeholder meeting where you ran it better than usual. One deliverable where the framing for the audience was clearly the point, not the analysis. Once your manager sees you moving, the lens relaxes.

2. Your skip-level has now heard about you for the first time

In most companies, first-year reviews involve calibration — your manager goes into a room with their peers and their boss, and they discuss the ratings for each team member. Before calibration, your skip-level often doesn't have a sharp picture of you. After calibration, they do.

They've heard two or three things your manager said about you. They've compared you briefly to the other first-years on the floor. Your name is now somebody they'd recognize in a hallway, at a staff meeting, or when a cross-functional opportunity comes up.

This is one of the most underappreciated outcomes of the first review. You're no longer anonymous to the next layer up.

The move: ask your manager for a short recap of how calibration went, a week after the review. Not the rating — the texture. "Did anything come up in calibration I should know about? Anything from a skip-level view I should be calibrating to?" Most managers will share a general version. That tells you what your skip-level thinks of you, which you couldn't know otherwise.

3. Your compensation trajectory has been set

This is the part most first-years underestimate. The first review sets a pace that is hard to reset.

Three ways this happens:

The raise percentage becomes a reference point. If everyone else on the team got a 4% raise and you got 3%, you're playing from behind next year. Not dramatically — but the gap is real.
Your role and level are reaffirmed or adjusted. If you stayed at the same level, you've been implicitly told "you need one more year before a conversation about level." If you were promoted early, you've been told "we see above-level work here."
Your bonus or stock set expectations. In some companies, the first bonus determines the size of your next target.

The move: ask the three questions your manager may not volunteer.

"How did my raise compare to the band on this team?"
"What would it take to be in the top of the range next year?"
"What's the typical timeline from this level to the next one at this company?"

Most first-years don't ask these. The ones who do accumulate a huge information advantage over the first three years of their careers.

What to do in the 30 days after

Day 1-7: Let it settle. Don't react, don't over-process. Read your written feedback twice, at least a day apart. Write down the three themes you hear, even if they overlap.

Day 7-14: Schedule a follow-up specifically about the development areas. Not "how do I get a better rating" — more like "I want to make sure I'm working on the right things for the next six months. Can we talk through the two development areas in more depth?" This is where the real plan for the year gets made.

Day 14-30: Pick one concrete weekly habit that moves you on the biggest development area. A specific meeting you'll run differently. A deliverable you'll ask for feedback on twice before finalizing. Something small that compounds.

Then stay quiet about it for three months. Execute, let your manager notice, don't ask every week whether they've noticed.

What the review is not

It is not the sum of your reputation. Your reputation is what people say when you're not in the room. The review is one data point inside that, not the whole thing.
It is not a verdict on your career. Some of the best-performing people I know got unremarkable first reviews. The question is where you end up in three years, not one.
It is not a reliable signal of how much your manager likes you. Managers are often kinder in 1:1s than in written reviews. The written version is calibrated for HR.

—

The review you got is the snapshot of who you were over the last twelve months. The review you'll get next year is the consequence of the ninety days after this one. Almost nobody acts on that asymmetry. Spend three weeks running the moves above and you'll be operating on a different timescale than your peers without anyone consciously noticing.

For the broader "what changes after your first 90 days" frame, see the First 90 Days OS. For the feedback-collection questions that make sure next year's review isn't a surprise, see my manager gives zero feedback.

A reader asks: I'm told to be proactive, but get snapped at when I try

Mike Halpert — Mon, 23 Jun 2025 00:00:00 GMT

The question (paraphrased from r/cscareerquestions):

My manager keeps telling me to "be more proactive." But every time I actually try — pick up a ticket, suggest a change, bring an idea to standup — I get low-key snapped at. Last week I rewrote a config file because I thought it would help and my tech lead called it "unnecessary work." Two weeks ago I proposed a refactor at a planning meeting and got a terse "let's not go there right now." What am I supposed to do? It feels like a trap.

It's not a trap. It's a miscalibration.

When a manager says "be more proactive," they almost never mean "do more stuff without asking." They mean: "anticipate more, communicate sooner, own the ambiguous parts."

Those are almost opposite behaviors. The first is taking action. The second is surfacing judgment. If you're pattern-matching "proactive" to the first one, you're going to keep stepping on landmines.

The two kinds of proactivity

High-signal proactivity — the kind that gets you promoted:

Flagging a risk before it becomes a problem ("I noticed X looks fragile — want me to look into it?")
Bringing a recommendation when you surface a question ("I think we should do A. Here's why. Want me to proceed?")
Closing loops on the ambiguous pieces of a project. Notes, recaps, decision confirmations.
Asking better questions earlier in a project, not at the deadline.
Offering to help with a visible team priority.

Low-signal proactivity — the kind that feels productive but creates friction:

Unilateral code changes or doc rewrites outside your scope
Ideas introduced mid-meeting with no prior context
Process suggestions in your first 60 days
Scope expansion on tickets you didn't own
Refactors nobody asked for

Both feel like initiative. Only one reads as judgment. The difference is whether you asked before you moved.

Why your tech lead snapped about the config rewrite

Probably not because the rewrite was wrong. Because you:

did it without context about why the config was the way it was
did it without context about who might be affected downstream
did it at the wrong time in the review cycle
committed them to either defending your change or unwinding it

That's three hours of their week that came out of your one hour of "being helpful."

The fix isn't to stop suggesting things. It's to front-load a 60-second conversation:

"I noticed the config file is inconsistent and it's slowing me down in the [X] area. Would it be useful if I spent an hour cleaning it up? I don't want to create a rabbit hole."

Now the answer is either "yes, please" (you're a hero) or "hold off, that file is load-bearing in ways you don't see yet" (you avoided a landmine). Either way, you look thoughtful.

Why the refactor proposal in the planning meeting landed badly

A planning meeting is not a brainstorm. It has a narrow agenda and a deadline. When you drop a new idea in, you're asking the room to either take it seriously (which burns time they didn't budget) or table it (which makes you look off-topic).

The move: propose the refactor before the meeting in a Slack to your tech lead.

"I've been thinking about the [X] area — I think there's a small refactor that would save us time long-term. Want to talk about it before planning, or should I write up a one-pager you can look at offline?"

Now your idea has a champion before it enters the room. If your lead says "write it up," the planning meeting becomes the place where they advocate for it — with your name on it.

The two-sentence test before you act

Before any proactive move, ask yourself:

Do I have the full picture of why things are the way they are?
If I'm wrong about why, is this reversible in under an hour?

If you can't answer yes to both, ask before you act.

That's not timid. That's senior. The most senior people on a team are the ones who move slowly on things they don't fully understand, and fast on things they do.

What to actually do more of

These will get you rated "proactive" on your next review with zero landmine risk:

Send a Friday recap. Five lines. What shipped, what's next, what's at risk, one question, one ask. Takes 10 minutes.
Flag risks early, in writing. "Heads-up — X might slip because of Y. I'm handling it by Z, but wanted you to know." That line is career gold.
Take notes in meetings, send action items after. This gets noticed at a comical rate.
Bring recommendations, not questions. "I think we should do A because X. Any objections?" instead of "What should we do?"
Close the loop on things vaguely assigned to the team. If nobody owns a follow-up, grab it.

None of these require you to make a unilateral change anywhere. All of them read as "proactive" in a way your manager can articulate at review time.

The line to steal

In your next 1:1:

"You've mentioned a few times that you'd like me to be more proactive. Can you give me one or two specific examples — either from me, or from someone on the team you think does it well?"

You'll get one of two answers. A specific example (great — now you know what to aim at). Or a vague "you know, just... take more initiative" (also useful — your manager doesn't have a clear picture, and vague feedback won't hurt you if you nail the five things above).

—

The asymmetry is brutal: a single unilateral move that backfires can erase weeks of well-built credibility, while six clean Friday recaps in a row build a reputation that survives most everyday mistakes. Optimize for the boring high-floor moves. The flashy stuff will come, and when it does, you'll have the credibility to actually land it.

For the rhythm that makes "proactive" visible without the landmines, use the Status update template. For the meeting structure where the calibration conversation lives, use the Manager 1:1 agenda.

—

If you have a question like this, send it in. Anonymity guaranteed.

A reader asks: my manager gives zero feedback. How do I get some?

Mike Halpert — Sat, 07 Jun 2025 00:00:00 GMT

The question (paraphrased from r/cscareerquestions):

I've been at my company for eight months. My manager is friendly and seems to like me, but I genuinely can't tell if I'm doing well. 1:1s are mostly about the work. When I ask "how am I doing?" I get "you're doing great, keep it up." I want real feedback. How do I get it?

Your manager isn't unusual. Most managers are not naturally good at giving feedback. Most managers think "you're doing great, keep it up" IS feedback. It isn't. But if you ask vague questions, you get vague answers.

Three specific questions almost always unlock real feedback, even from managers who are bad at giving it.

Why "how am I doing?" doesn't work

Your manager hears that question as a social check-in, not a request for analysis. It's like asking a friend "are we good?" It puts them in a position where the honest answer — "well, there are a few things…" — sounds like an attack. The easy answer is reassurance. So that's what you get.

You need questions that are specific enough to require an actual answer and structured enough that the honest version of the answer doesn't feel like a fight.

The three questions

1. "What's one thing I should do more of, and one thing I should do less of?"

The highest-hit-rate question. It asks for two concrete answers, not a general assessment. It frames the feedback as directional, not judgmental.

The "more of" answer usually points at the thing they already liked about you. The "less of" answer is where the real value is. Listen carefully. Even a soft answer — "maybe a bit less volume in the standups" — is a specific data point.

Ask quarterly. Not monthly. The answers only evolve meaningfully on that timeframe.

2. "If I were being considered for a stretch project / a promotion / a new role six months from now, what would be the thing that gave someone pause?"

Almost nobody gets asked this, and it forces the manager into a specific mental frame: imagining you in a future context, not just evaluating you now. That frame produces better feedback because the answer has to be predictive, not judgmental.

The "gave someone pause" framing is critical. It gives your manager room to name something imperfect without saying you're bad. You're inviting the realistic version of the answer. Managers almost always have one.

Ask twice a year. Or once, before your review cycle.

3. "If you could go back and give me one piece of advice before I started this role, what would it be?"

This one flips the time frame. Retrospective, not present. That asymmetry lets your manager say things that would feel awkward to name about you today but are fine to name as lessons. "I'd have told you to be less deferential in the big meetings." / "I'd have told you the real currency on this team is written docs, not just code." / "I'd have told you to stop apologizing in standup."

Ask once around the 9-month mark. Again at two years.

What makes all three work

Three things in common.

They're specific. Each has a noun and a direction. Your manager isn't asked to rate you; they're asked to complete a sentence.

They give permission to be critical. "What should I do less of" is a legitimate request for a negative, not a fishing expedition for reassurance. "What would give someone pause" explicitly names the concerns frame.

They're easy to answer in 60 seconds. Your manager isn't being asked for a performance review. They're being asked for one data point.

The hardest part: sitting with what they say

When you get a real answer, the temptation is to rebut. "But the reason I do that is…" is the most natural thing in the world, and it kills the feedback flow forever. Your manager just risked telling you something honest. If the response is "well actually," they learn not to do it again.

The right response:

"That's useful — can you say more about what it would look like if I did it differently?"

That's it. You're not defending. You're not thanking profusely. You're asking for the actionable version. Your manager will respect this and give you more feedback next time.

What if your manager actually has nothing to say

It happens. Either they don't have visibility into your work, or they're conflict-averse to a degree that blocks them from naming anything imperfect. If "what should I do less of" gets you "nothing I can think of" four quarters in a row, the problem isn't your feedback-collection technique anymore.

Your moves:

Get feedback elsewhere. Cross-functional partners, peers, a skip-level, a mentor outside your team. Don't rely on one source.
Make your work more visible so they have something specific to evaluate. Status updates, shared docs, "here's what I'm working on" conversations.
Quietly decide whether this is a manager who's going to be useful in your review cycle. If they have no specific view of you, your review will be similarly shapeless. Worth knowing before year-end.

—

A year of feedback collected through these three questions is worth more than any single annual review, because you've had chances to act on the feedback along the way. The annual review is a snapshot of who you were. The quarterly conversation is a record of who you became. Optimize for the latter.

For the broader 1:1 structure that creates the room for these questions, see the Manager 1:1 agenda. For the question that closes a good 1:1 well, see the one sentence that ends a good 1:1.

—

If you have a question like this, send it in. Anonymity guaranteed.

The meeting where someone's about to throw you under the bus

Mike Halpert — Sat, 17 May 2025 00:00:00 GMT

You can sometimes see it coming before the meeting starts. A preamble on Slack that sounds like scaffolding — "just want to make sure we're aligned heading in." A peer who hasn't talked to you all week suddenly asks "remind me, whose call was it to go with Option B?" ten minutes before the review. A senior person who phrases the agenda in a way that puts a specific decision in a specific person's lap, and that person is you.

Not every signal means what you think. But enough of them, in a row, usually does. The instinct is either to panic or to prepare a defense. Both lose. There's a third option.

The signals, roughly ordered by seriousness

Pre-meeting "alignment" messages from someone who hasn't been coordinating with you all week. People who are about to distance themselves from a decision often want to establish a record of "I flagged concerns."
Ownership questions that feel slightly wrong. "Whose idea was it to…?" when the question isn't really necessary for the conversation.
A peer cc'ing leadership on something that didn't need it.
Selective rewriting of a timeline. "As I recall, the team decided in March that…" when the team didn't decide that in March.
A pre-read or slides you didn't see, presenting work you were part of, that attribute decisions in a way you wouldn't have.

Any one of these could be innocent. Three together means a meeting is probably going to happen where someone wants their version of events to be the version of record.

What to do before the meeting

Two moves, short and unflashy.

Put a written version of the facts somewhere searchable. Not in a confrontational way. Just: "re-upping the thread from 3/14 where we landed on the Option B path — wanted to keep it handy for today's review." Post it in the team channel or the project channel. Now the actual record is one click away from your manager.

This is not pre-emptive confrontation. It's housekeeping. If the narrative in the room matches the record, you've helped the meeting. If it doesn't, you've made sure the gap is obvious.

Tell your manager. Not "I think Jake is going to throw me under the bus." That sounds paranoid even when it's true. Instead:

"Heading into the review today — wanted to make sure you had the picture on the Option B decision. It came out of the Mar 14 working session with [names]. I'll have the data in the deck; holler if you want a pre-read."

You've now oriented your manager to the actual facts thirty minutes before the meeting. If a peer tries to reframe those facts, your manager has already heard the true version.

This is one of the most underused senior moves. Pre-briefing your manager is not going behind anyone's back. It's respecting your manager's time.

What to do in the room

If it does happen — someone attributes something to you that wasn't yours, or frames a decision in a way that makes you the problem — here's the rule:

Correct the fact, not the character.

The temptation is to push back on the person: "that's not what happened" or "Jake is twisting this." That loses. It turns a factual disagreement into a personal one, and in a meeting, the calmer person wins, not the more accurate one.

Correct the fact:

"Just to make sure the record's clean — the Option B choice came out of the Mar 14 session; I can send the thread. Happy to walk through the rationale."

That's it. One sentence. Factual, specific, offering the receipts. Don't look at the person who misstated it. Don't use the word "actually." Don't raise your voice. You're not mad; you're the person with the facts.

Nine times out of ten, this is enough. The room now has the correction. The meeting moves on. The person who tried the reframe usually retreats quietly, because their version now looks less complete than yours.

What never to do afterward

Do not vent to a peer.

This is the one everyone gets wrong. After a meeting like that, you want to turn to someone on your team and say "did you see what Jake just did?" It's the most natural thing in the world.

Don't. Not one sentence to one peer.

Reasons:

It looks unprofessional even to the person you're venting to, even if they agree.
It gets back to the other person, always, usually faster than you'd imagine.
It marks you as the one with the grudge, not the one who was wronged.
It makes it hard for your manager to handle the situation without it becoming a team-wide drama.

Instead: go on a walk. Write an email to nobody. Tell your partner when you get home. Vent to a friend outside the company if you must. Inside the company, silence.

The only conversation inside the company worth having is with your manager, privately, if the misattribution actually hurt you. Same framing as before: "I want to make sure the record of the Option B decision is accurate — can I walk you through how it actually played out?" Facts, not character.

The longer game

People who throw peers under buses tend to do it more than once. If this is a pattern, your manager will see it on their own, given time. The most durable move is to keep producing good work, keep documenting it in public, and keep the factual trail clean. Within six months, the pattern becomes obvious without you ever having to name it.

People who fixate on punishing the peer who did it tend to lose twice: once in the original meeting, once in the reputation they build as the person with the grudge.

—

The version of revenge that works in corporate America is structurally boring: post the meeting notes in the channel, send your manager a one-line pre-brief before reviews, and keep producing the work. Six months of that is more devastating to a peer who plays games than any single confrontation. Patience is the most undervalued tactical skill in offices, and the people who learn it in year one operate on a different level by year five.

For the peer-credit pattern that shows up alongside this one, see the Reader Q on peers who take credit. For the broader healthy-vs-toxic collaboration frame, see workplace competition.

A reader asks: how do I get promoted before my MBA application?

Mike Halpert — Sat, 26 Apr 2025 00:00:00 GMT

The question (paraphrased from r/MBA):

I'm planning to apply to full-time MBA programs in the next cycle (R1 next September). I've been at my current company for two years, my performance reviews have been good, and I really want to get promoted before I apply because I think it'll strengthen my application. My manager is supportive but hasn't committed to a timeline. Am I crazy to try to engineer this, and if not, how do I actually do it without looking like I'm gaming it?

You're not crazy, but the instinct is a little off. Admissions committees don't care about the title on your LinkedIn as much as the story you tell with it. A promotion strengthens an application when it's used as evidence of trajectory — "I was trusted with more scope ahead of the normal timeline" — not as a prestige stamp.

Which means the question isn't really "how do I get promoted." It's "how do I engineer and document a visible expansion of scope in the next 12 months."

Reframe: you're not asking for a promotion. You're building a case.

Promotions at most companies happen because three things line up:

Business need. Someone has to need the scope you'd fill.
Evidence. Your track record shows you can already do it.
Sponsorship. Someone with influence will advocate for you.

Most people trying to "get promoted before the MBA" focus on #2. That's the part you already have. The leverage is in #1 and #3.

12-month timeline

Month 0 (now): diagnose the gap.

Set up a dedicated 1:1 — not a casual check-in. Script:

"I want to apply to MBA programs next cycle. Before then, I want to grow into a role with more scope, and ideally have a title change to reflect it. Can we walk through what that would take — what scope I'd need to own, what's missing from my current track record, and what's realistic on the business side?"

Don't bury the MBA reference. It's actually helpful — it gives your manager a deadline and a reason to be specific.

Expect three kinds of answers:

"Absolutely, let's map it out." Supportive manager. Get the criteria in writing.
"It's hard because [specific business reason]." Helpful. Now the conversation is about how to work around it.
"Let's keep working and see how things go." Polite no. You now know your promotion case has to get made to someone other than your manager, or this role isn't the right home for the MBA story.

Months 1–3: take visible stretch scope.

Whatever scope your manager said was "the next level," take a small piece of it now. Don't wait for permission on the whole thing. Own one slice visibly. Examples:

Lead a workstream on a project that's usually an Associate or Senior Analyst thing
Represent your team in a cross-functional forum where your manager usually goes
Mentor a new hire formally (not just "be nice to them" — actually own their ramp)
Own a recurring executive-facing artifact (the monthly business review, the weekly dashboard commentary, the quarterly pitch deck)

Pick one. Do it for 3 months. Document the outcome.

Months 3–6: build the sponsor network.

One person who advocates for you is a promotion case. Two is safer. Three or more is unshakeable. Invest in one structured 1:1 per month with someone senior outside your direct chain. A skip-level. A leader of an adjacent team. The question:

"I'm working on growing into [next-level scope]. Is there an area where our teams overlap that I could be contributing more on?"

That's a sponsor-cultivation move disguised as a tactical ask. They'll remember you for it.

Months 6–9: formalize the case.

Put the promotion case in writing. One-page memo. Sections:

Current scope vs. level-plus scope (specific examples of what you've been doing above your current level)
Business impact (outcomes, in numbers where possible)
Sponsors (people who've seen the work)
What the new title would unlock for the business

Share with your manager 6 months ahead of application season. Not because you expect a yes on the spot, but because you want the conversation started with concrete evidence, not abstract hopes.

Months 9–12: close.

If your company has a formal promotion cycle, submit. If not, push for a specific timeline:

"Based on the conversation we had in [month], what's realistic on a title change in the next quarter? If that's not doable, I'd like to understand why now so I can plan."

That question commits your manager to either a "yes in Q," a "no because X," or an uncomfortable silence. All three are useful.

What to avoid

Don't frame it as "I need this for my MBA." The scheduling is about the MBA. The case is about the scope and the business. Keep the two separate.

Don't promise you're not leaving. Your manager is not naive. They know MBA applicants leave. If they ask, be honest about the plan; if they don't, don't volunteer it.

Don't burn out trying to engineer every possible signal. A cleaner version of the promotion case with fewer scope expansions but deeper ownership reads better to admissions than a frantic scope-grab.

What if the promotion doesn't land

It's fine. Your MBA application doesn't need the title. It needs the story. If you can walk into your essays and interviews with "in the last year, I expanded my scope to include X, Y, Z — here's the outcome, here's what I learned, here's why I'm ready for the next thing," you have the material, title or no title.

Admissions readers have seen thousands of applications. They can tell the difference between real scope and a stretched title. They'll reward the real scope every time.

—

The version of this play that works isn't the one where you negotiate hardest for a title. It's the one where you build twelve months of evidence so airtight that the title becomes the obvious next step. Either you get it, or you walk into your MBA essays with the strongest "here's what I did before I applied" paragraph in your cohort. Both are wins.

For the 1:1 structure where the monthly calibration lives, use the Manager 1:1 agenda. For the status habit that leaves a paper trail of scope expansion, use the Status update template.

—

If you have a question like this, send it in. Anonymity guaranteed.

A reader asks: my first industry conference — do I actually have to network?

Mike Halpert — Wed, 09 Apr 2025 00:00:00 GMT

The question (paraphrased from r/sales):

My company is sending me to an industry conference next month. My manager keeps telling me "the real value is the networking." I'm introverted, the thought of forcing conversations with strangers in a hotel lobby is exhausting, and I'm not even sure what I'm supposed to get out of it. Do I actually have to "work the room"?

No. You do not have to work the room. "Working the room" is a Hollywood framing of networking that was invented for salespeople in the 1990s and is mostly bad advice for everyone else.

What you do have to do is come home with two things. Not twenty business cards. Not 300 LinkedIn connections. Two real conversations that turn into follow-up and, over the next year, turn into people who know your name.

The two-conversation rule

For a three-day conference, aim for two real conversations.

Real means: a conversation long enough that you exchanged more than job titles. Where the other person left thinking "that was a useful chat" and you left with something concrete to follow up on. Twenty to forty minutes, usually. Sometimes a dinner. Sometimes a coffee in the lobby. Sometimes a walk between sessions.

Two. That's the target. Anything more is upside.

Two real conversations is much better than twenty quick hellos. Hellos evaporate. A real conversation becomes a LinkedIn message on Tuesday that becomes an email exchange in May that becomes a coffee when you're thinking about your next job in 2027. The compounding is the point.

Where to find those two conversations

Most conference-goers make the classic mistake of trying to network at networking events. Cocktail hours, hotel lobbies, open-bar mixers. These are the worst possible places to have a real conversation. Everyone is scanning over everyone else's shoulder. Conversations are shallow by design.

Better places:

Before and after sessions. If you found a talk interesting, the person who asked a good question from the audience is usually worth two minutes of your time afterward. "I liked your question — how does that play out in your org?" is the entire opener.
The speakers' downtime. Most speakers hang around for ten minutes after their session. They're disproportionately approachable because they expect it. One specific, substantive question, not a fan moment.
Your own company's booth, table, or lunch. Your colleagues are trying to network too. Stand near them and be introduced. Warm intros are the easiest conversations of the whole conference.
The airport or the hotel gym. Some of the best conversations I ever had at conferences were in Ubers to airports. Everyone is tired, out of performance mode, willing to talk honestly.
Structured small-groups. Roundtables, dinners, workshops. Anything that forces a small group to spend 90 minutes together is a much better bet than an open mixer.

Skip the opening-night cocktails entirely if you hate them. Nobody remembers who was there.

What to actually say

The single hardest thing about conferences is the first sentence. Three that work:

The content opener: "I'm curious what you made of [specific session or topic]." Works because it's about something real, not about each other.

The role opener: "What's the thing that keeps you up at night in your role right now?" Senior people love this question because most of the conference is small talk, and this skips it. Don't use it with someone you just met in an elevator — use it ten minutes into a conversation.

The route-in opener: "How did you end up in [X] — was it a straight path?" Works because everyone's career has a story and most people don't get asked about it.

You don't need a pitch. You need one question and the ability to listen.

The one habit that changes everything

Before each day of the conference, pick one specific person you want to talk to.

Not "someone senior." One person. By name. Looked up on LinkedIn the night before. With one question you would only ask them.

The reason this works: attending a conference without a target is like shopping without a list. You come home with nothing you needed. With one target, your day has a shape. If you have the conversation, great. If you don't, you still did something deliberate.

Over three days, that's three named targets. If one turns into a real conversation, you've made the conference worth it.

The follow-up that matters

The conference isn't over when you get home. It's over 72 hours after you get home, when you either send a thoughtful follow-up or don't.

Thoughtful means:

Specific to the actual conversation. "Loved what you said about how your team structures the quarterly review — here's the piece I mentioned."
Sent from your work email, not LinkedIn. LinkedIn messages look like networking. Emails look like colleagues.
Offers one thing. An article, an introduction, a follow-up thought. Not a "let's stay in touch."

One thoughtful email, seven days after the conference, turns a chance meeting into the beginning of a relationship. You can't scale this to twenty contacts. You can scale it to two.

What's actually overrated

Collecting business cards. Cards without memory are noise.
The mega-mixer. Big mixers are social theater. Useful only if you're already senior and use them to say hi to people you already know.
"Adding value." You don't have to come pre-loaded with brilliant insights to offer strangers. You have to listen and be curious.
Small-talk skill. Small talk is the price of admission, not the event itself. Be mediocre at it and good at the second layer of conversation.

—

Most career networking advice is written by extroverts for extroverts and reads as exhausting to everyone else. The real version: build a small handful of real relationships over five years, never a big handful of shallow ones, and you'll quietly have access to roles, intros, and information that the room-workers never reach. The people who change your career are people you've had three good conversations with — not thirty.

For the coffee-chat script that works beyond conferences, see the coffee-chat script that isn't creepy. For the broader "what does downtime at the office look like" question, see what to do with downtime.

—

If you have a question like this, send it in. Anonymity guaranteed.

How to Actually Finish a Project When No One Is Checking on You

Mike Halpert — Tue, 25 Mar 2025 00:00:00 GMT

Your project is the single deliverable on your plate that landed with a title like "look into X" or "run Y initiative," but no weekly steering committee. A business partner gave you a goal, maybe a six-week deadline, and a vague expectation that magic will happen if you "keep it moving." No one is nudging you with reminders, no one expects a daily update, and the only shared doc is a blank one titled "progress."

The other party, the manager or partner who needs the outcome, wants confidence without playing babysitter. They are trying to prove to their own boss that work is happening without clogging their week with weekly stand-ups. They want a little evidence that deadlines are met before the delivery hits their inbox. They are also doing subtle theater: they will not ask for a formal check-in because that feels controlling, but they will judge the quality of your final file like it was their idea all along.

Good looks like a ten-minute check-in every other week, even if it is with yourself. It sounds like: "Here is what shipped, here is what I am blocking on, here is the decision I need from you before Friday." The document you send includes the expected deliverable, the trade-offs you are balancing, and the next action you want sanctioned. You leave the meeting with the partner saying, "That makes sense," and the next meeting starts with "Here's what changed."

Bad looks like silence until the day before the due date, followed by a frantic "Do you remember that project?" call where you read the memo right out loud because there was no shared signal path. The new file lands in their inbox with a separate "I hope this is close enough" message. They open it, find scope drift, and need to rewind the work from scratch to understand the assumptions. That is a black hole of effort that could have been prevented with even one intentional beat.

How to make the invisible checkpoints real

Execution is task capture plus prioritization plus follow-through. That is not inspiring poetry; it is a reminder that your brain will never remember every to-do and your willpower is not a project manager. The keyboard is your system. Start by capturing every idea, request, and reminder the moment it arrives, Slack, hallway chat, whatever. Without that capture, you will forget the project's scope because your inbox only remembers the loudest incident.

I've been there, six months into a role at Stylitics where I had a dashboard project with zero check-ins, and yeah, I forgot half the original asks until I dug back through old emails. Autonomy is not freedom from process. It is freedom to invent the dull process that keeps you honest. Here's what that looks like:

Weekly capture. Dump the deliverable, decisions pending, and new risks into a doc every Monday. Even if you never send it, the act of summarizing forces clarity. Yes, writing a status for a meeting that does not exist feels a bit silly. Do it anyway. Managers remember what you remind them about, even if they were not watching.
Prioritized work queue. Pick three things you can do this week that move the needle, one on the architecture, one on the research, one on the delivery detail. No more. Your brain defaults to "all the things," and in a project with zero oversight that means everything stays half-baked.
Confirmation ritual. Every time you finish a chunk, write one sentence describing what you did, what changed, and what the next person sees. Send it as a Slack thread or a one-line email with "For visibility" in the subject. It feels silly. It is your signal that the work happened. We all did this at Stylitics back when I was shipping those early analytics tools, and it saved me from explaining the same half-done feature twice.

At Stylitics we used to treat these updates like a "micro-review." If you could not explain what you shipped in one sentence, the work was probably not finished. The exercise forced you to see scope creep before it became a crisis.

Your manager's inbox is a war zone of half-baked pings and forgotten threads, so these rituals punch through the noise without demanding their full attention. Most onboarding is vibes-based, leaving you to build your own guardrails or watch the project fade.

The pulse check that keeps the project alive

Here is a reusable structure that replaces a missing sponsor. Use it before every sprint or delivery milestone. It gives the person who assigned the work what they secretly need, a quick fix-it view of where things stand.

:::template{title="Project pulse check"} Date YYYY-MM-DD
Deliverable What we are building
Done this week Specific change or artifact shipped
Decision needed What input/approval is blocking next steps
Priority shift What I am focusing on next and why
Risk or question Any new unknowns or trade-offs
Stakeholder shout-out Who needs to hear this and why :::

Deadpan corporate observation: the slide in every status deck that says "open issues" and has three identical rows labeled "waiting on X." Fill that slot with actual decisions and risks so no one has to guess what the problem is.

Also, try this script when a milestone feels murky: "I have three directions the work could go, Option A keeps the scope tight, Option B adds the experiment, Option C trades timeline for polish. I recommend A so we can keep the deadline, unless you want to force the trade." That sentence gives the other person something to react to without making them babysit you.

One weird observation that helps: treat the project like the plant on your apartment counter. You are not watering it for drama. You are watering it because dead leaves mean people start asking where the deliverable is. This project, like that plant, needs reminders, otherwise you forget it exists until your manager asks about it at the quarterly review.

Honest closer

Yes, the system is messy, and you will miss a beat. But you now have a doc, a ritual, and a pulse check that together make it impossible for the project to disappear into the ether. Looking back, those self-imposed check-ins were the only thing that kept my Stylitics projects from turning into ghosts, a quiet win in the chaos of solo ownership.

(Word count: 928)

The Friday shutdown routine that makes Monday behave

Mike Halpert — Tue, 18 Mar 2025 00:00:00 GMT

Friday shutdown is not a last-minute sprint to prove you're working. It is about petitioning Monday to behave like a normal weekday instead of a surprise audit. The thing you are doing is a 20-minute ritual: capture every loose thread in your inbox, list the top priorities for Monday, note which human still owes you something, and leave the week in a document so anyone who wakes up Monday before you can quickly understand where the puck is. No metaphors, no drama, just a short checklist that means nothing will sneak up on the team over the weekend.

The other party you are serving is not your manager’s ego. It is the Monday stand-up that wants someone to say, “Here is where work landed. Here is what is next.” Your manager wants a concise handoff to their calendar crowd, stakeholders want to know someone remembered their deadline, and the people on call at 9 a.m. would prefer not to ask, “Wait, where were we?” That is what they are trying to do: avoid waking up to uncertainty and still look like they have a plan.

Good looks like your Monday 8:30 a.m. meeting being a confirmation instead of a flood of fresh context. Someone says, “Cool, you finished the spec; now we just need QA” instead of “Who was owning that spec?” You can answer every question with a link in your Friday note, a status line, or a follow-up request. The readout is calm, not frantic.

Bad looks like coming back to eight unread emails, a calendar full of “follow up on X,” and three people chasing you for updates you forgot to send. It is the Monday where you start by rebuilding what you already did, because nothing from Friday made it out of your head. It sounds like panic, not a plan.

How to spend the 20 minutes

Pick a time between 4:20 and 4:40 p.m. on Friday. Pick the same 20 minutes each week. Consistency beats willpower. If the week collapsed in a pile of meetings, this is your chance to cordon off what survives. Here’s the work, in order:

Task capture: Pull every ticket, email, or chat strand you touched this week into one place. Include anything you committed to but never announced as done. That includes the little commits you shipped and the follow-ups you promised. Yes, writing another “shipped” bullet about something the entire team already saw feels silly. Do it anyway. That bullet is the only thing the person writing your review is likely to remember.
Priority triage: List the two wins you need to preserve first thing Monday and the two blockers that can derail them. Also drop one status item you can share 2 minutes into the stand-up, this is the “here is what landed, here is what is next” moment.

:::template{title="Friday shutdown snapshot"} Tasks to mention Monday <task 1 detail>, <task 2 detail> Top two priorities for Monday , Active blockers and owners : , People I’ll ping before Monday : Hand-off note for the team :::

Follow-up rituals: Update the doc or thread where your team trusts the truth, maybe a wiki page, Slack channel, or shared project doc. Use the “I will follow up with X on Monday” script internally: “Monday, I will check back with X on Y by 11 a.m. If I hear nothing by then, I’ll escalate.” Saying it out loud in Slack or the doc removes the mental poker game where everyone pretends a blocker is fine.
Logistics check: Confirm your calendar for Monday’s big meetings, drop the necessary pre-reads in the same doc, and mark where to find the updated numbers. The ritual is like swapping the kettle out of the dishwasher before company arrives, you can ignore it and wrestle with drips later, or you can walk into the living room with everything already clean.

Deadpan corporate observation: the Friday status thread that only exists so someone can reply “thanks for the update” before leaving the floor. Punch up this process as the only way to make your Monday welcome you back with a handshake instead of a slap. The corporate system loves 30-minute post-mortems. You are doing the pre-mortem in 20.

Why the routine still matters

The thing about process is that it rewards the performer you never thanked: your future self. At Stylitics, six months in, the number of times I opened my laptop Monday to discover that a blocker was still “awaiting review” because I forgot to ping the reviewer dropped to zero after I started this ritual. I've seen that habit save a Monday when a director slid into my calendar asking for a status update from the weekend; my doc already had a “here’s what’s waiting on you” bullet.

We all slip now and then. I still forget the “send the blockers note” line occasionally, and Monday grinds harder because someone else has to triangulate the work. But the 20 minutes is the one investment where process outperforms willpower every time. Keep it simple, keep it consistent, and the chaos of Monday becomes something you prepared for, not something you apologize for. It's that quiet win where the week ends on your terms, even if the inbox never does.

Saying no without saying 'no'

Mike Halpert — Tue, 11 Mar 2025 00:00:00 GMT

Most advice on saying no in the workplace is about having the courage to refuse. That frames it wrong. The thing that matters isn't whether you have the nerve. It's whether you have the vocabulary.

In a healthy office, nobody actually needs to say the word "no." You say five or six variants of "not now, not me, not like this, not without a tradeoff" — and those cover 95% of the situations where a new employee feels pressured to overcommit.

Here are the phrases. Steal any you like.

"Happy to take it on — which of the things I'm working on should slide?"

Use when: a new task is being added on top of a full plate, and the person adding it has visibility into what else you're doing.

Why it works: reframes "no" as a prioritization question. You're not refusing. You're asking for a call on tradeoffs, which is your manager's job. If they genuinely need the new thing, they'll decide. If they were just batting it your way without thinking, they'll back off.

What happens next: half the time, the new task gets deprioritized on the spot. "Actually, don't worry about it — I'll have Sarah take a look." That's a no that never had to be a no.

"Can I come back to you on that? I want to check my week against the other two things in flight."

Use when: the ask is coming at you in real time and you need thinking space.

Why it works: "let me check" is always available and is not a refusal. It buys you an hour or a day to evaluate, which is often enough to kill a request that shouldn't have existed.

What happens next: 30% of the time the person forgets they asked. 40% of the time you come back with a thoughtful response. 30% of the time it becomes a real tradeoff conversation. All three beat an impulsive yes.

"I don't think I'm the right person for this — have you thought about asking Dan?"

Use when: the task is genuinely in someone else's wheelhouse and would be awkward or slow for you to take on.

Why it works: you're redirecting, not refusing. Naming an alternative. Subtly showing you know enough about the org to route the ask correctly.

Caveat: use sparingly. If it becomes your default, you become known as the person who pushes work to others. Two or three times a quarter is fine. Once a week is a problem.

"I can do v1 by Thursday, or a fuller version by next Wednesday. Which works?"

Use when: the ask is reasonable but the timeline is unrealistic.

Why it works: you're not pushing back on the work. You're offering the asker a choice between scope and speed. Most people, asked to pick, will pick the calmer timeline. You've just saved yourself four days of panic without ever saying no.

"That's outside my scope — happy to bring it to [manager] if you want it prioritized."

Use when: a peer or cross-functional partner is asking you to take on something your manager hasn't authorized.

Why it works: surfaces the real decision-maker without you playing bad cop. You're telling them where the authorization lives.

What happens next: three out of four times, the peer decides the ask isn't important enough to escalate. The fourth time, your manager weighs in, and you get a clean yes or no with official backing.

"I want to make sure I get [existing commitment] right before I take on more."

Use when: someone — often your manager — is asking you to take on something while your plate is already full.

Why it works: invokes your existing commitment to the team as the reason for not doing more. Hard to argue with, because it's aligned with what the manager previously asked for.

Caveat: this only works if "existing commitment" is actually visible to your manager. If they don't know you're deep in something, the phrase sounds like excuse-making. Weekly status updates are how you make this invocation legitimate.

The version to never use

"I'd love to help but I just don't have time right now."

This sounds kind. It doesn't work. It implies the issue is personal, that if you had a little more time you'd say yes, and it creates a reopening for the asker to come back later. It also subtly invites negotiation: "can you find fifteen minutes?"

Every version above names a tradeoff or a constraint. The kind sentence names only your preference, which isn't something the asker has to respect. Drop it.

When you do need the word "no"

Two situations where the soft versions aren't enough.

Ethical issues. If someone is asking you to falsify a number, misrepresent a status, or take credit for something you didn't do — say "I don't think we should do that" or "I'm not comfortable with that." No softening. The softer versions create the impression you're open to being talked into it.

Personal or legal lines. Requests that cross into your personal life (work on vacation, cover for someone's absence, answer on a sick day) or legal/HR territory (sign something without reading it, attend a meeting you weren't invited to for cover) — plain no is the correct register.

For everything else — scope, priority, timing — the soft versions win.

—

A quick yes to too many things is much more damaging to your reputation than a thoughtful "which one slides?" The phrases above feel weird the first three times you use them. After that, they feel like the only adult way to handle the ask. The colleagues who still feel awkward saying no two years in are usually the ones drowning in commitments they made in two-second hallway conversations.

For the scope of tasks your manager actually wants vs. things they'd rather delegate elsewhere, see how to ask for more work. For the broader pushback-on-deadline version, see pushing back on a deadline.

A minimal task system for your first year (no apps required)

Mike Halpert — Tue, 04 Mar 2025 00:00:00 GMT

The biggest mistake new hires make is treating their brain like a hard drive. You tell yourself you'll remember to follow up with the product manager on Tuesday, or that you'll definitely update that slide deck before the Friday sync.

Then Tuesday comes, a fire breaks out in a Slack channel, and that follow-up vanishes into the void.

Execution is not about willpower. It is about capture. If a task exists only in your head, it doesn't exist. It's just a vague anxiety you're carrying around until someone asks you for a status update on something you forgot.

A task system is a basic setup to track commitments so work doesn't slip through the cracks. Your manager and team want reliable progress on shared goals, without constant chasing. Good execution shows up as steady delivery: you hit deadlines, follow through on asks, and keep projects moving without surprises. Bad execution means dropped balls: stalled work, awkward status meetings, and a growing sense that you're not pulling your weight.

The productivity app trap

New hires in their first quarter often chase the "perfect" system. They spend four hours configuring a Notion workspace or tweaking a Trello board, thinking the tool will somehow grant them the ability to be organized.

This is a distraction. Tool-hunting is just a sophisticated form of procrastination.

The goal isn't to have a beautiful dashboard. The goal is to ensure that nothing you promised to do disappears. I spent six months at Stylitics trying to build the ultimate automated tracking system, only to realize I was spending more time maintaining the system than doing the actual work.

A task system is not about optimization. It's about reliability. Your manager juggles thirteen Slack threads, six open Jira tickets, and a meeting they're late for, so they need you as the steady hand.

The "Low-Fi" capture system

You don't need a subscription. You need a way to get things out of your head and into a list. I recommend a simple notebook or a basic digital text file.

The system relies on one rule: if it takes more than two minutes, it goes on the list. If it takes less than two minutes, do it now.

Every single request, a "quick question" in a DM, a side-note in a meeting, a directive from your manager, gets captured immediately. Yes, writing down "send calendar invite" feels partially silly, like you're treating a sticky note as sacred text. Do it anyway.

To keep the list from becoming a graveyard of impossible dreams, use this triage framework every morning for ten minutes.

:::template{title="The Daily Triage"} The Brain Dump: List every single thing on your mind, regardless of priority.

The Non-Negotiables: Pick 1-3 items that MUST be finished today for you to feel successful.

The "If I Have Time" Pile: Tasks that are important but won't cause a crisis if they move to tomorrow.

The Waiting-On List: Things you can't move forward until someone else responds (include the date you asked). :::

The "Waiting-On" secret

The "Waiting-On" list is the most underrated part of professional execution.

Juniors on a new team fail not because they forgot to do their own work, but because they forgot that someone else was supposed to do theirs. You send an email to a stakeholder on Monday. They don't reply. You assume they're busy and wait. By Thursday, your manager asks why the project is stalled.

Now you're the bottleneck, even though you're the one waiting on someone else.

The fix is a deadpan corporate observation: the "gentle nudge" is a primary job function. By tracking who owes you what, you can send a follow-up every three business days without feeling like a pest. It's not pestering; it's project management. I've nudged the same engineering lead twice a week during a tight sprint at Stylitics, and it turned a two-week delay into three days.

Running the system

Your day should look like this:

AM Triage: Use the template above. Set your non-negotiables.
Active Capture: Every time a new task appears, add it to the dump.
PM Clear: Look at your "Waiting-On" list. Send the nudges. Clear the wins.

This is essentially a manual version of a ticketing system. It's boring. It's repetitive. It's exactly how you get a reputation for being the most reliable person in the room.

The system is like a basic insurance policy for your reputation. You don't want to use the "I forgot" excuse more than once a quarter. After that, it's not a mistake; it's a pattern.

We all miss a random Slack request now and then, especially when you're deep in a flow state. The real win is turning that vague anxiety into a controlled rhythm, one list at a time.

The 3-line Slack that gets faster answers

Mike Halpert — Sat, 22 Feb 2025 00:00:00 GMT

Most Slack messages that sit unanswered for six hours share the same problem. They're not rude. They're not unimportant. They're just too much work for the reader.

The person on the other end opened your message, saw three paragraphs, had four other Slacks queued up, and decided to deal with yours later. Later became never.

A three-line Slack fixes this.

The format

Line 1: what you need. Line 2: the context they need to answer. Line 3: what you'll do if they don't respond.

That's it. No preamble. No "hey hope you're having a good week." No "circling back."

Example: you need a decision

Bad:

"Hey! Hope you had a good weekend. Quick question — I've been working on the Q2 onboarding flow and I'm kind of stuck on whether we should gate the email verification step or not. I looked at the old docs but couldn't find a clear answer. Wondering what you think? Let me know when you have a sec 🙂"

Good:

Need: your call on gating email verification in the Q2 onboarding flow. Context: old design gated it, new PRD doesn't specify. [doc link] Default: I'll keep it gated unless I hear back by EOD Thursday.

Same information. 80% less cognitive load for the reader.

Example: you need a doc review

Bad:

"Hi! Would love your thoughts on this draft when you get a chance. No rush. Let me know if you have any feedback or see anything off! [link]"

Good:

Need: 10-minute review of this draft before I send it to legal Friday. [link] Context: I'm specifically worried about the scope section and whether the risks are framed right. Default: I'll send it Friday 2pm ET as-is if I haven't heard back.

The second version is faster to read and easier to act on, because the reviewer knows exactly what you want them to focus on.

Example: an access or intro request

Good:

Need: intro to someone on the data team who owns the customer dashboard. Context: I'm trying to understand how a metric is calculated for a doc I'm writing. Default: I'll ping #data-help if I don't hear back by tomorrow.

Why the "default" line works

The default line is the unlock. Three things happen:

It removes urgency performance. You're not making them feel bad for not responding instantly. They can deal with it when they have a minute.
It protects you from blocking. If they don't respond, you keep moving. That's not aggression — that's a pro.
It forces you to decide what you'd do without them. Half the time, you realize you didn't actually need the message.

The default doesn't have to be "I'll proceed." It can be "I'll ping someone else." / "I'll ask in the next standup." / "I'll assume yes." / "I'll escalate to [manager]." Any default beats "I'll wait and hope."

Channel vs. thread vs. DM

Same three-line format. Different surfaces.

Public channel: the answer is useful to other people, or you want visibility on the question. Thread under an existing message: your question is scoped to something already under discussion. DM: the person is the specific owner, the question is sensitive, or you need speed.

Simple rule: if you'd be happy for five other people to see the answer, use a channel. If not, DM.

What to strip from every Slack

These phrases make you look junior and they slow everyone down:

"Hope you're having a great week" at the start
"Sorry to bother you"
"Whenever you get a chance" without a default
"I was wondering if..."
"Does that make sense?"
"No rush!" (the reader knows)
"Just checking in" / "Circling back" (same message, lower confidence)

Strip all of them. You'll be surprised how little is left, and how much clearer it is.

The 2-minute rule before you Slack at all

Before you send, ask: can I answer this myself in two minutes? Check the doc, the channel search, the last meeting's notes, the shared drive. Half of "I need to ping someone" moments dissolve in two minutes of looking. The other half are genuine and deserve the three-line format.

A note for foreign professionals

The three-line Slack can feel abrupt if your previous workplace was more formal. It isn't. American office Slack norms reward brevity. A well-formatted direct message is read as respectful of the reader's time, not rude. The pleasantry you skipped was costing the reader a beat of cognitive work. Removing it is a favor.

—

I've watched the same three-paragraph "hey hope you're well" message sit unanswered for six hours, then watched the same person rewrite it as three lines and get an answer in eleven minutes. Same recipient, same question. The difference was entirely the shape of the ask. The reader doesn't owe you longer attention — they owe you exactly the attention your message asks for. Ask for less.

For the update rhythm that means most of your asks get anticipated instead of asked, use the Status update template. For deciding email vs. Slack in the first place, see Should you send an email or a Slack?.

Back-to-back meetings are a productivity illusion

Mike Halpert — Tue, 18 Feb 2025 00:00:00 GMT

A calendar full of back-to-back meetings feels like a badge of honor. It signals that you are "in demand," "collaborative," and "essential to the process." In reality, it's just a very expensive way to ensure you never actually do the work you're meeting about.

Back-to-back meetings mean scheduling calls with no buffer time between them, often in 30- or 60-minute slots that butt right up against each other. Your manager or team is trying to pack as much coordination as possible into the day, assuming that constant alignment keeps projects moving. Good looks like everyone leaving the room with clear next steps and energy to execute; bad looks like frazzled faces, forgotten action items, and a vague sense that nothing advanced.

The "back-to-back" setup is a corporate mirage. You think you're maximizing your time, but you're actually just creating a high-stress environment where you arrive at every call slightly frazzled and completely unprepared. Your manager is juggling thirteen Slack threads, six open Jira tickets, and a meeting they're already late for.

The math of the context switch

The problem isn't the meetings themselves. It's the transition.

Your brain is not a light switch. You cannot flip from a high-stakes budget review to a creative brainstorming session in the zero seconds between two Zoom calls. When you stack meetings, you pay a "context switch tax" on every single transition: it hits hard every day.

If you have four meetings in a row, you aren't spending 100% of your time in those rooms. You're spending 10% of each meeting trying to remember what the goal of the current call is while your brain is still processing the conflict from the previous one.

I've seen this play out at Stylitics during our busiest quarters. We had a culture of "calendar Tetris," where we'd squeeze 15-minute syncs into the tiny gaps between hour-long workshops, like right after our weekly product standup. The result was a team of people who were technically "working" ten hours a day but shipping nothing because they had no contiguous blocks of time to actually think. We all fell into that trap at some point.

Meetings are not the work. They are the coordination of the work. If you spend all your time coordinating, you've effectively become a professional scheduler.

The 25/50 rule

The fix is a simple change in your default settings. Stop booking in 30- and 60-minute increments. Those are the "corporate defaults," and corporate defaults are designed for the system, not for the human.

Switch to the 25/50 rule:

30-minute meetings become 25.
60-minute meetings become 50.

Yeah, this looks a little silly, like you're gaming the system with some quirky timer trick. Do it anyway. Those five to ten minutes are not for "getting ahead" on email. They are for the biological necessity of resetting your brain.

I've started using that gap myself, especially on days when I'm jumping between design reviews and engineering check-ins. Use it for three specific things:

The Brain Dump: Spend two minutes writing down the one immediate action item from the meeting you just left.
The Pivot: Spend two minutes reviewing the agenda for the next call.
The Human Reset: Stand up, drink water, or stare at a wall.

If you don't schedule the gap, the system will fill it for you.

:::template{title="The Calendar Audit"} Current State: Total hours in meetings per week The Gap Ratio: Number of meetings with <10 min gaps / Total meetings The Deep Work Block: Number of 2+ hour uninterrupted blocks per week The "Coordination Tax": Estimated hours spent "prepping" for meetings during other meetings :::

Protecting the deep block

The most dangerous thing you can do is let your calendar become a Swiss cheese of 30-minute gaps. A 30-minute gap is useless for actual work. It's just enough time to open a document, realize you're confused, and then get a notification that your next call is starting.

Real work requires "deep blocks", at least two hours of uninterrupted time.

At Stylitics, I've found that the only way to protect these blocks is to actually put them on the calendar as "Busy" or "Focus Time." If the block isn't there, a colleague will find that 2:00 PM slot and drop a "quick sync" right in the middle of your flow, say ten minutes before our daily standup.

The "quick sync" is the corporate equivalent of a termite. One of them is fine. Ten of them and your entire afternoon is structurally unsound.

The honest reality

I still fail at this. I still occasionally say "yes" to a meeting that ruins my entire Tuesday because I want to feel helpful. But I've learned that being "helpful" in a meeting is a poor substitute for actually delivering the project on time. We all chase that full calendar high sometimes, but the real win comes when you step back and see those blue blocks giving way to actual output.

Your calendar is not a list of obligations. It is a map of your priorities. If your map is just a solid block of blue rectangles, you aren't productive. You're just busy.

The color-coded calendar audit: find where your week actually goes

Mike Halpert — Tue, 11 Feb 2025 00:00:00 GMT

Your calendar is not a schedule. It is a map of your priorities made visible.

The problem is that we all treat our calendars like a junk drawer. We accept every invite, we let "quick syncs" proliferate like weeds, and we wonder why we're still answering emails at 9 PM despite having a "light" Tuesday.

If you feel like you're working twelve hours a day but only actually producing for four, you don't have a productivity problem. You have a visibility problem.

What a calendar audit really is

A calendar audit is a quick review where you tag every time block on your calendar with a category, then tally up the percentages to spot imbalances. It takes about 20 minutes for one week, but it reveals how meetings and admin are crowding out your actual work.

Your manager uses your calendar to gauge your focus areas, not just to check if you're occupied. They scan for signs that you're aligned with team goals, like consistent execution time or collaboration slots that feed into deliverables.

Good calendar hygiene shows up as clear blocks for focused output, with meetings clustered and gaps for recharge. In the room during a check-in, it looks like you explaining a shipped feature from your green time, not scrambling to recall what you did last week.

Bad hygiene packs your days with back-to-back syncs and vague "office hours," leaving no room for progress. In the room, it feels like you're always reacting to others' agendas, with no wins to share because your energy went to note-taking instead of building.

The reality of the corporate schedule

I've run this audit every six months since my internship at Google, and it saved me during those first weeks at Stylitics when standups started feeling like my full-time job. The goal is to shift from overwhelmed vibes to hard numbers on why your impact feels stuck.

Juniors at Stylitics often assume their manager eyes the calendar for raw busyness. They don't. Your manager hunts patterns: are you dumping 40% of your week into meetings without outputs, or disappearing into deep work for three straight days with no check-ins?

Good hygiene resembles a balanced portfolio. You carve out dedicated execution slots, set firm meeting boundaries, and leave visible white space for recharge.

Bad hygiene stacks into a wall of overlapping blue rectangles. It's calendar Tetris, where you quit questioning why you're in a meeting and just hunt for a 15-minute lunch slot.

The audit process

A calendar audit breaks down every time block to expose the system's grip on your hours. Your manager wants patterns that show you're driving results, not just attending.

Pick a random Tuesday through Friday from last month. Pull up your calendar. Tag every block with one of four colors.

:::template{title="Calendar Audit Categories"}

Green (Deep Work): Actual producing. Writing the doc, building the model, coding the feature.
Yellow (Maintenance): Email, Slack, admin, expense reports, the meeting that should have been a Slack message.
Red (Coordination): 1:1s, status updates, stakeholder alignment, "quick syncs."
Blue (Learning/Growth): Training, reading documentation, mentorship, thinking time. :::

Yeah, coloring your calendar like a middle-school diorama sounds half-baked at first. But we all did worse in our early jobs to claw back sanity.

Once colored, check the ratios. If red and yellow swallow 80% of your time, you're not an employee anymore: you're a meeting router, shuttling info without touching the real work. That's the spicy truth: calendars aren't plans; they're battlegrounds where coordination crushes creation unless you fight back.

Fixing the leaks

With data in hand, swap vague gripes about "no time" for targeted pushes to reclaim it. Punch up your schedule by treating it like the asset it is, not a passive victim of invites.

The biggest trap is the "open door" policy. It pretends to foster collaboration, but it lets random questions ambush your best hours, turning mornings into ad-hoc therapy sessions.

Counter with maker's blocks. Reserve three hours on Tuesday and Thursday mornings. Label them "Dashboard Execution" or "Deep Work: Q2 Goals." When bookings overlap, point to your audit: 70% coordination last month left zero output.

Try this script:

"I've got a deep-work block locked for the dashboard deliverable then. Can we shift to 2 PM, or Slack the details so I can tackle it in my yellow time?"

This push isn't gatekeeping. It's guarding the output your paycheck demands.

Why audits stick around

We all chase the myth of a spotless calendar, but corporate gravity pulls in meetings like clockwork. A VP's "urgent" ping will always torch your Thursday, no matter the plan.

I've leaned on these audits through three role changes, and they never fail to reset my week. The real win is ending Fridays wiped out from shipping code or docs, not from marathoning status updates.

A reader asks: how do I handle a peer who keeps taking credit for my work?

Mike Halpert — Mon, 03 Feb 2025 00:00:00 GMT

The question (paraphrased from r/ProductManagement):

A peer on my team keeps representing our joint work as mostly his. In the last two meetings with our manager, he said "I" where it was "we," and referenced analyses I did as if he'd done them. Our manager doesn't seem to notice. I don't want to be petty, but I'm getting resentful. How do I handle this without blowing up the relationship?

Good news: this is fixable. Bad news: the fix is not "call him out." Confrontation almost never works, because the receipts live in private conversations and your manager will experience the confrontation as you being insecure, not as him being dishonest.

The move is to change where credit gets assigned in the first place, so the crediting problem stops happening.

Why confrontation fails

Three reasons.

Your peer can always reframe. "Oh, I meant 'we' obviously" or "I was just summarizing — of course you did the analysis" is the standard retreat. You're stuck looking petty.
Your manager can't adjudicate. He wasn't in the working sessions. He's going to hear two versions and pick the easier one, which is "get along."
You look reactive. The quickest way to lose status in a peer dispute is to be the one who brought the dispute into the manager's office.

The better moves all work at the source: they make credit visible before the manager hears the summary.

Three specific moves

Move 1: Document in public

The single highest-leverage thing is to shift your collaboration from private to public. Private conversations are where credit goes missing. Public artifacts are where it sticks.

Put your drafts in a shared doc with your name on it and share it in the team channel, not via DM. Say "first pass, happy to get Jake's edits." Now the team sees the first pass came from you.
Post updates in Slack, not over the shoulder. "Posted v2 of the model — incorporated the segmentation you flagged yesterday, Jake." This one line establishes that you built v2 and he flagged one input. It's not hostile, it's factual.
Tag contributors in meeting notes. After a meeting, send a one-paragraph recap with specific attribution. "Jake walked through the revenue framing; I took the action item to pull the segmentation data by Thursday."

The effect is cumulative. Over two weeks, your manager — and his manager — have a digital trail that says what you did. The "I" vs. "we" language in the meeting no longer controls the picture.

Move 2: Pre-brief your manager

If you have regular 1:1s, use one of them to explicitly frame a project you're working on.

Don't say: "Jake keeps taking credit."

Do say: "I'm running point on the segmentation work for the Q2 review. Here's where I am, and Jake is helping with the revenue framing. I wanted to make sure you had the picture before Wednesday's meeting."

Two things happen. Your manager now has the accurate ownership picture before the meeting. When Jake says "I" in the meeting, your manager has already primed himself on who did what.

This is not sneaky. This is what every senior IC does. You're not obligated to play the meeting as a neutral observer and hope the manager figures it out.

Move 3: Build with a different peer, visibly

Over the next month, pick one project where you intentionally partner with a different peer, visibly, on something meaningful. Your manager will naturally compare how the two collaborations look.

When the same person (you) is producing good work with two different partners, and one of those partners is openly attributing, it clarifies the signal quickly. Your manager doesn't need you to tell him what's happening. He needs to see it with his own eyes.

This takes a couple of months. The payoff is that you stop being dependent on Jake's crediting for your reputation.

What if your manager still doesn't see it

If you've done all three moves for two months and your manager still credits Jake for your work, the problem is no longer Jake. It's that your manager isn't paying attention to attribution, or doesn't want to.

At that point, you have a manager problem, not a peer problem. Start building visibility outside your manager — skip-levels, cross-functional partners, a lateral mentor — and make a quiet decision about whether this is the manager you want to be reviewed by next cycle.

What not to do

Don't go silent on Jake. If you visibly withdraw, you look resentful. Work with him normally. Just change where the work happens — in public, not in DMs.
Don't compile a dossier of slights. If your 1:1 becomes a list of examples where Jake took credit, you will look like the problem.
Don't match the behavior. The "two can play at this game" version makes the whole team look immature and lowers the bar for everyone.

What this is actually testing

Credit theft is usually about insecurity on the other side, not malice. Jake is probably anxious about his own standing and is compensating. This isn't comforting, but it matters because it means you don't have to play this as adversarial. You can play it as a reputation-building game. The public-documentation move works whether Jake is malicious or anxious.

—

The version of you that wins this isn't the one who corners Jake in a 1:1 and demands an apology. It's the one who quietly makes the team's work legible to everyone watching, and then keeps doing that for six months. Jake will either course-correct on his own or his pattern will become visible without you having to point at it. Both outcomes are better than confrontation.

For the status-update rhythm that makes credit attribution automatic over time, use the status update template. For the healthier version of workplace competition that avoids spirals like this one, see workplace competition.

—

If you have a question like this, send it in. Anonymity guaranteed.

How to take meeting notes without becoming the permanent scribe

Mike Halpert — Tue, 21 Jan 2025 00:00:00 GMT

There is a specific kind of corporate trap that happens to the most organized person in the room. You start a project by offering to take notes for the first two meetings. You do a solid job. You're clear, you're fast, and you send the recap within an hour.

Suddenly, you are the Designated Scribe.

Six months later, you're in a high-stakes strategy session and you can't actually contribute to the conversation because you're too busy typing a verbatim transcript of a VP's rambling anecdote about a 2014 product launch. You've become a human recording device.

What meeting notes are (and aren't)

Meeting notes are a short record of what the group settled on during the discussion. Plain and simple, they're the snapshot that keeps everyone moving forward without looping back on basics.

The other people in the room, from your manager to the VP, are trying to align on priorities and assign real work so the project doesn't stall. They're not there to create a play-by-play for the archives.

Good notes in the room look like a quick, scannable list that sparks nods of agreement: decisions locked in, tasks with owners and deadlines, maybe a couple of loose ends flagged. Bad notes turn the meeting into a fog where nobody remembers who promised what, leading to those frustrating "I thought you were handling that" emails next week.

The goal of the meeting log

Your manager isn't looking for a script of the dialogue. They are looking for a record of commitment. If the notes don't tell them who is doing what by when, the notes are just a long-form essay that nobody will read.

Good notes look like a checklist of outcomes. Bad notes look like a court reporter's transcript. If your notes include phrases like "Then Mike mentioned that perhaps we should consider..." you are doing too much work and providing too little value.

I've been there myself: at Stylitics, six months into my role, I was the one typing up every tangent in a weekly sync, and it left me sidelined from the actual strategy talk. We all end up in rooms like that if we're not careful.

Note-taking is not about transcription. It's about capturing the delta. Yeah, I know, that sounds a little like corporate buzzword bingo, but stick with me, because it actually works.

The "Delta" framework

To avoid the scribe trap, stop writing what people said and start writing what changed.

Your manager is juggling thirteen Slack threads and a stack of Jira tickets, so hand them something that cuts through the noise: the three things that matter from the hour you just spent together.

Shift your focus to these three categories:

Decisions: What is now a fact? (e.g., "We are using Postgres, not MongoDB.")
Action Items: Who is doing what, and when is it due?
Open Questions: What did we realize we don't know?

If a conversation doesn't result in one of these three things, it doesn't go in the notes.

:::template{title="The Meeting Delta Log"} Meeting: Project X Sync Date: April 26

Decisions Made

Decision 1: [e.g., Approved the Q3 budget for X]
Decision 2: [e.g., Moving the launch date to Oct 1]

Action Items

[Owner]: Task description, Due [Date]
[Owner]: Task description, Due [Date]

Parking Lot / Open Questions

Question: [e.g., Do we have legal approval for the new copy?]
Dependency: [e.g., Waiting on API docs from the Platform team] :::

How to exit the scribe role

If you've already become the permanent note-taker, you can't just stop showing up with a notebook. That looks like you've checked out. You have to turn the process into a shared routine so the burden shifts from a person to a system.

The move is to move the notes into a shared doc during the meeting. Share your screen. Type the "Decisions" and "Action Items" in real-time.

This does two things. First, it forces the room to agree on the outcome. If you type "Decision: We are cutting Feature X" and the VP frowns, you catch the misalignment in ten seconds rather than in an email thread on Friday. Second, it makes the notes a collective asset.

When it's time to rotate, use the "Process Improvement" frame:

"I've noticed the shared log is working well for us. To make sure we're all staying sharp on the details, let's rotate the log-keeper every week. I'll take this one, and [Peer] can grab the next one."

Yes, this feels like you're assigning homework to your coworkers. Do it anyway.

The exit strategy

The most dangerous part of the meeting is the last two minutes. This is when people rush to the door and "agree" to things they haven't actually thought through.

Stop the room. Spend sixty seconds reviewing the Action Items list out loud.

"Just to confirm before we drop: Sarah is handling the vendor call by Tuesday, and I'm updating the slide deck by Thursday. Everyone aligned?"

This is the professional version of "checking your work." It eliminates the "I thought you were doing that" argument.

Note-taking is a tool for influence, not a clerical duty. It's the difference between being the person who records history and the person who helps write it.

I still occasionally fall back into "transcript mode" when I'm nervous in a room with senior leadership. It's a comforting way to feel productive while staying quiet. But the goal is to be the person contributing to the decision, not the person documenting why the decision took two hours to reach.

How to write a project brief your PM doesn't rewrite

Mike Halpert — Sun, 12 Jan 2025 00:00:00 GMT

A senior PM I used to work with had a small tell. When she liked a project brief, she'd reply in the thread with a one-line "let's go." When she didn't, she'd reply with a new version of the brief, pasted directly into the thread, with no comment. No feedback, no "here's what I changed" — just the new version, implicitly saying this is what I needed.

It is the most demoralizing feedback form in corporate life. Nothing's wrong, per se. The brief just wasn't the brief she needed.

The good news: the thing that usually breaks isn't writing. It's structure. If your PM keeps rewriting your briefs, the fix is to mimic the structure she uses, not to write better sentences.

The six-line brief

Here is the skeleton that almost always works. Fill in one line per section. Expand only if you have to.

Problem: [what's broken or what's changed]
Audience: [who feels it, in one sentence]
Proposal: [what we're doing about it]
Success: [what changes if we ship]
Scope: [what's in, what's out, explicitly]
Open: [what we still need to decide, with names]

Six lines. That's a brief. Everything else is supporting material — timelines, dependencies, risks, data — that comes after the six-line top.

Most first-year briefs fail for two reasons. They either skip the six lines entirely and start with context, or they combine two lines into one and lose precision.

The two lines most people get wrong

Audience. "Users" is not an audience. "Enterprise buyers who are trialing but haven't converted in 14 days" is. The audience line is where specificity buys you the most credibility. If a senior PM can't picture the person in one sentence, they're going to rewrite your brief to force that picture in.

Success. "Drive engagement" is not success. "Reduce trial-to-churn from 42% to 30% within 60 days of launch" is. Success is the thing you'd commit to being graded on. If you wouldn't sign up to be graded on it, it's not specific enough.

Fix just those two lines and half your rewrites disappear.

The line people forget

Scope. Scope is where senior people notice junior PMs. A brief that says "we're going to improve the trial experience" and doesn't say what's in and what's out will get rewritten every time, because without explicit scope, the PM has no idea how big the project is.

In scope: [one to three things you will do]
Out of scope: [one to three things you will NOT do, even though someone will ask]

That second sub-line is the one that earns the most credibility. It shows you've already absorbed the "yes but what about…" questions. It signals judgment.

What the senior rewrites usually change

If you do get a rewrite, read it carefully and look for the pattern. Nine times out of ten, the senior version does one of these:

Tightens the audience line. "Users" becomes "enterprise buyers on the 30-day trial who dropped off after creating one project."
Makes success numeric. "Improve conversion" becomes "+5pp trial-to-paid in Q2."
Adds an explicit out-of-scope. "We are not redesigning the onboarding flow."
Adds names to the open questions. "Pricing TBD" becomes "Pricing: need Jen's sign-off by Tuesday."

If that's the rewrite pattern, you can pre-empt it. Those four moves are the standard tells of a brief that's ready for senior review.

Where this goes wrong: the context dump

A common junior move is to open the brief with two or three paragraphs of context. Why this is important. What the company is trying to do. Where this fits in the roadmap.

That writing is not wrong. It's in the wrong place. It belongs as an appendix, not an opener. A senior reader wants to know in six lines whether to read the rest. Context before substance makes them start skimming.

Flip it. Six-line brief at the top. "Why this matters" at the bottom, for anyone who wants to read more.

The phrase to steal from senior PMs

"Explicit non-goals."

Almost every senior project brief has a section called "non-goals" or "explicit out-of-scope." It tells the reader what you've deliberately decided not to do. This is the line that turns a brief from "a description of work" into "a decision about work."

Copy it. Use it on every brief. You'll look senior for free.

The test before you send

Read the top six lines out loud. If a colleague who's been on vacation for a week could read those six lines and say "got it, here's what we're doing and who it's for" — you're done. If they'd have to ask a follow-up to understand the gist, the brief isn't ready yet.

—

The version of you that got rewrites was producing a description of the work. The version that gets "let's go" is producing a decision about the work. That's the only difference. Once you see the structure, you can't unsee it.

For the related skill of one-page summaries that executives actually read, see what is an executive summary?. For the status update rhythm that keeps projects visible after the brief is approved, see the status update template.

A reader asks: I'm the only non-native English speaker on my team

Mike Halpert — Thu, 19 Dec 2024 00:00:00 GMT

The question (paraphrased):

I joined a tech company in the US six months ago and I'm the only non-native English speaker on my team. My English is fine — I interviewed in English, I can do my job — but in meetings I feel like I'm always half a beat behind. By the time I've figured out what I want to say, the conversation has moved on. Then I either stay quiet or jump in awkwardly. What do I do?

This is one of the most common experiences for foreign professionals in the US, and the fact that nobody's talking about it at work doesn't mean nobody on your team has noticed. They probably have. Which is part of why it feels like something is wrong.

The solution isn't "improve your English." Your English is fine. The bottleneck isn't language. It's meeting tempo.

What's actually happening

Native speakers in an American meeting are doing three things at once: listening to what's being said, watching for their moment to jump in, and constructing their sentence as the moment approaches. When you're native, these happen in parallel with very little cognitive cost.

When English is your second or third language, construction takes real effort. It's not that you don't know what to say. It's that by the time the sentence is fully built in your head, the topic has moved. This is exhausting in ways your native-speaker colleagues genuinely can't feel.

Here are the techniques that help — roughly ordered by how quickly they pay off.

1. Prepare two sentences before the meeting

If you know what the meeting is about, write down two things you want to say before it starts. Literally two sentences, on a notepad.

One about the work. "I think the Q3 drop is mostly driven by the pricing change, not the channel."
One about the people. "Nice to have Priya back — how's the new role?"

You don't have to use them. But having them pre-built removes the construction step for the moments you'd otherwise miss.

Senior native speakers do versions of this too. The difference is you need to be more deliberate about it.

2. Use "I want to come back to something" as a reset

The biggest unfairness in a live meeting is that once a topic has moved past, you can't really go back. American meetings respect whoever has the floor right now.

Except: there's one phrase that resets the stack, and senior people use it all the time.

"I want to come back to something Sarah said a minute ago — she mentioned the pricing change, and I think that's actually the core issue. Can I say one thing about it?"

That sentence buys you back the airtime you missed. It works for everyone. But it works disproportionately well for people whose construction time is longer, because it removes the "it has to be right now" pressure.

Use this phrase. Twice a meeting, if needed. Nobody minds.

3. Write more where writing beats speaking

If your job has a written layer — docs, status updates, post-meeting summaries, Slack threads — lean into it. Written communication removes the tempo problem entirely. You can draft, re-read, edit.

Many of the most impactful contributors on distributed teams are the strong writers, not the strong talkers. If you're a better writer than speaker in English, that is an asset, not a weakness.

This is also the move for the follow-up. Say one thing in the meeting. Then send a two-paragraph follow-up Slack message with the full thought. "Wanted to build on what I said in the meeting — here's the fuller version." You get credit for both.

4. Ask, specifically, for a pre-read

If your team is running meetings with no documents in advance, push for pre-reads. Not because of your English — because pre-reads make meetings better for everyone.

"Could we try doing a one-page pre-read before these reviews? I find the conversations get to the substance faster."

Pre-reads are a 10x multiplier for a non-native speaker. You get to process the argument before the room does. You come in knowing what you want to say.

5. Stop apologizing for your English

This is the one I'd fix first. If you open any comment with "sorry, my English is not perfect" or "excuse my accent," you are pre-telling the room to discount what you're about to say. They will. Not consciously. But they will.

Your English is fine. You interviewed in English. You got hired. You don't have to defend it. Say your thing, stop, let people respond.

The one thing that's fine to say, and actually helps: "one second — I'm finding the word." That's a specific, one-off callout, and it buys you three seconds without lowering anyone's opinion of you. The blanket apology does the opposite.

What doesn't help

"Pretending to be native." Don't force idioms you're not sure about. Don't slang. You'll hit a note that lands wrong, and you'll be less yourself. Speak formally if that's more natural. Formal registers are always acceptable in an American office.
"Staying quiet and hoping to speak up later." The later doesn't come. Meetings end, and the people who didn't speak are, quietly, filed as people who didn't speak. Say one thing, even if it's small.
"Taking an English class when the issue is tempo, not vocabulary." Classes are fine, but if your problem is meeting rhythm and not grammar, a class won't fix it. Practice meetings will.

What a good month looks like

By the end of month one of practicing this:

You've prepped two sentences before every meeting
You've used the "I want to come back to" reset at least once a week
You've sent one written follow-up after a meeting where you said less than you wanted to
You've stopped apologizing for your English entirely

You won't feel like a different person. You'll feel like a slightly more deliberate version of the same person. That's the right change.

—

The frustration is real and the construction lag is real, and people who've never spoken a second language at work full-time genuinely can't feel it. The good news: the techniques above don't require you to become someone else. They require you to be slightly more deliberate about a thing native speakers do automatically. Once the technique is in place, the gap closes faster than you'd expect.

For the broader set of week-one adjustments that affect how foreign hires are read, see three things every foreign hire should do in week one.

—

If you have a question like this, send it in. Anonymity guaranteed.

Three things every foreign hire should do in week one

Mike Halpert — Sun, 01 Dec 2024 00:00:00 GMT

Most of what's written for foreign professionals starting a job in the US focuses on the big stuff: visa, taxes, healthcare, where to live. Those matter. But the thing that shapes how you're read in year one isn't any of that. It's a handful of small defaults you set in week one that your colleagues will quietly notice and quietly interpret.

Three things, specifically, that tend to misfire.

1. Calibrate the directness dial

Americans in an office setting are direct by the standards of most places, and indirect by the standards of a few. If "direct" in your home culture means Germany-direct or Netherlands-direct, you will sound blunt to your American colleagues. If "direct" in your home culture means Japan-direct or Korea-direct, you will sound so soft that you'll be underestimated.

The US corporate default is: direct about facts, softened about people.

You can say: "the numbers don't support that conclusion."

You do not usually say: "you are wrong."

Same information. Different read. The first lands as careful analysis. The second lands as a personal attack, and in an American office, people don't recover from being called wrong in a room. They remember.

The move in week one is to listen for the specific pattern your team uses. When a senior person disagrees with something, how do they phrase it? When someone pushes back on an idea, what words do they use? Copy the cadence for the first month. You can find your own voice once you've learned the default.

One phrase worth memorizing: "I want to make sure I'm reading this right — are we saying…?" It's the American way of politely asking someone to restate or defend a position. Buys you time and signals engagement without signaling disagreement.

2. Decide on names before the first introduction

In many cultures, using a senior person's first name is jarring. In the US, first names are the default up and down the org chart, including with executives. You might meet the CEO on day three and be expected to call him "Steve" thirty seconds into the conversation.

That will feel wrong the first few times. Do it anyway. Using "Mr. Chen" or "Dr. Patel" to a US-raised colleague who is used to first names can actually make them uncomfortable — they feel like they're being treated as older or more senior than they want to be.

The one exception: very senior external clients, older clients, and clients in certain industries (law firms, some banks, traditional consulting firms) may still expect last names on first meeting. Take the cue from how others on your team address them.

If you genuinely prefer to be called by a specific name or pronunciation, correct people once, kindly, the first time. "Actually, it's pronounced Ah-jay, not Aj-ay — no worries." Set the expectation once, then stop correcting.

One small thing that pays off: put the pronunciation in your email signature if your name gets mispronounced regularly. "Ajay (Ah-jay)" saves you a month of awkward meetings.

3. Use small talk as a real tool, not a tax

In many cultures, the first minute of a meeting is business. In the US, it's usually two to four minutes of something else. Weather, weekend, sports, a shared complaint about traffic. Then business.

If you skip this and try to drive the meeting to the agenda in the first thirty seconds, it reads as cold or even rude. Even if nobody tells you. Especially if nobody tells you.

Small talk in an American office isn't wasted time. It's the trust warm-up. You don't have to be good at it. You just have to participate.

Have two or three ready lines about your weekend. "Took my kids to the park, it was perfect weather. How about you?" costs nothing and buys you a chunk of goodwill.
Watch the local news headlines once a week. Not because you need political takes. Because you want to recognize references. "Did you see the Jets game?" lands differently if you can say "I didn't — what happened?" vs. staring blankly.
Don't ask questions that feel normal at home but are considered personal here. How much you earn, how much rent is, whether a colleague is married — save all of those for much later, or never. Safe topics: weekend plans, food, sports, travel, weather, TV.
If you don't drink, say so early and briefly. "Sparkling water for me, thanks" is all it takes. Americans don't ask follow-up questions about this.

A bonus thing: the apology gradient

A separate small tell: Americans apologize for much smaller things than most cultures. "Sorry, I'll be two minutes late." / "Sorry, one quick follow-up."

If you are from a culture where apologies are reserved for real offenses, American-office "sorry" will feel like excessive self-deprecation. It is not. It's a social lubricant with almost no literal content.

The reverse is also true: if your home culture uses apologies heavily, you may apologize more than American colleagues, and it can read as uncertainty or low confidence. Watch a senior person for a week. Count the *"sorry"*s. Match the rate.

What to not overcorrect on

Don't try to "become American" in week one. You can't. The attempt reads poorly. Your accent, your cadence, your cultural frame of reference will all be there for years. That's fine. The goal is not to disappear — it's to remove small friction points where the cost is zero and the benefit is real.

—

The pattern across all three is the same: pay attention to what your colleagues actually do, not what your home culture taught you "professional" looks like. Two weeks of close observation gets you 80% of the way to fitting in without performing. Stay yourself; just learn the specific frequencies the room is broadcasting on. That's the entire skill.

For the broader etiquette pattern, see office etiquette. For the communication baseline — email vs. Slack — see should you send an email or a Slack?.

When to Slack vs. Email: The Junior's Decision Tree

Mike Halpert — Tue, 19 Nov 2024 00:00:00 GMT

Choosing between Slack and email as a junior feels like staring down two doors in an office maze: one keeps things moving, the other trips you up. It's the everyday puzzle of reaching your manager or teammate without grinding their focus to a halt or stalling your own work.

Your manager or colleague is trying to juggle their own workload, from code reviews to client calls, while keeping the team aligned without drowning in pings. They want updates that stick when needed but fade when they're noise.

Good looks like a message that lands at the right time: your teammate reads it once, nods, and responds without switching tabs three times, or your manager pulls up the email thread months later to confirm a key decision. Everyone moves forward with minimal friction.

Bad looks like a barrage of Slack notifications that pull someone out of deep work, or an important update lost in a Slack channel that scrolls away before anyone acts. The result is confusion, delays, and that sinking feeling when you realize the ball got dropped.

Juniors in their first role often treat Slack like a permanent group chat and email like a digital museum where things go to be forgotten. This mix-up turns every outreach into a gamble.

Communication in a corporate setting is not about the tool. It is about the record. Every message you send is either a "transaction" (fast, disposable, tactical) or a "document" (slow, permanent, strategic). If you use the wrong one, you either annoy your boss with 14 notifications for a single thought, or you bury a critical project update in a thread that no one will ever find again. Your manager's inbox already battles a dozen half-resolved threads from the morning standup alone.

The fundamental difference

Slack is for the "now." It is a stream of consciousness. It is designed for high-velocity, low-stakes coordination. If the information has a shelf life of 48 hours, it belongs in Slack.

Email is for the "forever." It is a system of record. It is designed for asynchronous, high-stakes alignment. If you need to be able to prove you said something six months from now during a performance review, it belongs in email.

Slack is not about speed. It is about friction. Email is not about formality. It is about durability.

The decision tree

I've been there myself, staring at my screen during my first six months at Stylitics, wondering if a "quick question" about a dashboard spec was too quick for email or too formal for Slack. We all second-guess this stuff early on, but nailing it builds trust faster than any all-hands presentation. The choice depends entirely on who is receiving the message and what you need them to do with it.

Use this logic to decide:

:::template{title="Communication Selector"} 1. Is this a "receipt" for a decision?

Yes $\rightarrow$ Email (CC the stakeholders)
No $\rightarrow$ Go to Question 2

2. Does this require a thoughtful response (more than 2 sentences)?

Yes $\rightarrow$ Email (Give them space to think)
No $\rightarrow$ Go to Question 3

3. Is the recipient "in the zone" or in meetings all day?

In the zone $\rightarrow$ Slack (Low friction)
Meetings all day $\rightarrow$ Email (They can batch-process it)

4. Is this a social "vibe check" or a quick clarification?

Yes $\rightarrow$ Slack
No $\rightarrow$ Email :::

When to break the rules

There are a few specific corporate rituals where the "correct" tool feels wrong, but you do it anyway because it's how the system works. Yeah, forwarding a Slack convo to email can feel a bit like overkill, like documenting every hallway chat, but it saves your skin later. It's one of those rituals that's half silly, half essential if you want to avoid the blame game down the line.

The "Paper Trail" Email. Sometimes you have a great conversation on Slack where your manager tells you to ignore a certain deadline. Do not leave that in Slack. Slack is a digital wind tunnel. Send a follow-up email: "Just circling back on our Slack chat, confirming we're pushing the X deadline to Friday to prioritize Y."

Yes, this feels like you're playing "corporate lawyer." Do it anyway. When the VP asks why the project is late in three weeks, "we talked about it in a thread" is not a defense. "I sent a confirmation email" is.

The "Urgent" Slack. If something is truly on fire, like a production bug or a client screaming, email is a graveyard. Use Slack, but avoid the "Hey" or "You there?" opener. That is the digital equivalent of poking someone in the shoulder and waiting for them to look at you before you speak.

Instead, use the "One-Block Update":

"Urgent: [Project X] is down. I'm currently [doing Y] to fix it. Will update you in 15 minutes. No need to reply now."

The cost of the "quick question"

The biggest mistake juniors make is the "Slack-bomb." This is when you send five separate messages in a row:

"Hey!"
"Quick question"
"About the report"
"Do you know where the link is?"
"Thanks!"

This is not communication; it is a notification attack. It forces the other person to stop their work five times.

Treat a Slack message like a physical letter. Put the greeting, the context, and the ask in one single block. It allows the recipient to process the request in one go and reply when they hit a natural break in their work.

I still occasionally send a long-winded email that should have been a three-sentence Slack message. I just hope the recipient is as distracted as I am.

The one sentence that ends a good 1:1

Mike Halpert — Mon, 11 Nov 2024 00:00:00 GMT

Most 1:1s in the first year end the same way. "Thanks, see you next week." Maybe a "have a good weekend" if it's a Friday. The conversation dissolves. Everyone moves on to the next thing.

That ending is a missed move. Not because the meeting was bad. Because the sentence you use in the last thirty seconds determines whether your manager walks out of the room thinking about you or thinking about what's next on their calendar.

The sentence

Steal it:

"Before we wrap — is there anything coming up in the next two weeks where I could be more useful?"

Or a variant:

"Anything on your plate next week that I should know about or help with?"

Eight seconds. That's the move.

What it does

Three things, all small, all compounding.

It reframes the conversation. Most 1:1 agendas are about you: what you've done, what you need, what you're stuck on. Appropriate — it's your 1:1. But ending with a line that's about your manager flips the energy. They leave the meeting having thought, briefly, about how to use you better. You leave having signaled that you're paying attention to their workload, not just yours.

It surfaces work you didn't know existed. The thing your manager is dreading on Tuesday is often something they wouldn't have thought to hand you. The sentence pulls it into the open. Sometimes it turns into an assignment. Sometimes it doesn't. Either way, you learn what they care about that week.

It builds the reputation of a person who is looking up the stack. Your peers are mostly executing against what's in their queue. The person who ends a 1:1 asking what else is coming is, over the course of a year, building a different kind of presence in the manager's head.

Variants — pick the one that fits

Early in a role: "Before we wrap — anything I should be learning about that hasn't come up yet?"
When your manager is visibly busy: "Anything on your plate next week I could take off your hands?"
When you've got capacity: "I've got some bandwidth coming up — anything I could start running at that would be useful?"
When you're both slammed: "If you only had time to tell me one thing before we wrap, what would it be?"

Pick one. Use it for a month. See what changes.

What not to say

Don't ask "is there anything else?" It's flat. Doesn't specify what kind of else.

Don't ask "how can I be more useful?" in an open-ended way. Aspirational, not actionable. Your manager doesn't want to give a performance review in the last thirty seconds. They want to hand you something specific.

Don't offer help on something you can't actually do. If they say "yeah, the budget review is next week, want to take a first pass?" and you've never done one — either say yes and ask for guidance, or say "I haven't done one before — could I shadow this one and run the next?" Don't bluff competence into existence.

Don't use the sentence and then run out of time. If your 1:1 is ending at :30 and you ask at :29, they'll say "no, we're good" because the meeting is over. Ask at :26.

When not to use it

If your manager has spent the 1:1 giving you feedback you need to sit with — actual developmental feedback, not just tactical course correction — do not pivot to "anything I can help with?" at the end. It reads as deflection. Sit with the feedback. Thank them. Leave.

Same rule if the conversation has been about something personal, or about the team's direction. The sentence is for tactical 1:1s, not every 1:1.

The reason this is a senior move

Watch senior people end meetings with their own bosses. They don't end with "thanks, see you next week." They end with "anything you need from me this week?" or "is there anything I should prioritize differently?" It's a senior move. Adopting it early is how you look senior sooner than you are.

—

I've used this sentence with maybe forty different managers. The hit rate is wild. Maybe a third of the time it surfaces something genuinely useful — a project I should have been on, a meeting I should have attended, a person I should have introduced myself to. The other two thirds, it costs nothing. Eight seconds, no downside, occasional jackpots. That's a good trade in any system.

For the full 1:1 structure that produces those eight seconds, see the Manager 1:1 agenda. For the weekly update that makes the rest of your week visible, see the Status update template.

Promotion pathways: the 3 levers that matter (even if no one says it)

Mike Halpert — Tue, 29 Oct 2024 00:00:00 GMT

"Do great work and the promotion will come" is advice that gets repeated so often it starts to feel true. It isn't. Great work is required, but it's the entry fee, not the decision criteria. The people making promotion calls in calibration meetings are asking a different question than "who works hardest?", and until you understand what that question is, you can produce excellent results and still stall at the same level for two years.

Promotion pathways have three levers. Most people only know about one.

What a promotion decision actually is

A promotion isn't an award for past performance. It's a forward-looking bet that you can consistently operate at the next level. The calibration conversation where your promotion gets decided is your manager, often without you in the room, making the case that you're already doing next-level work, not that you're almost ready to do it.

That framing matters because it shapes what you need to do to get there. You're not proving you've done your current job well. You're proving you're already functioning in the job above it.

What your manager and the calibration committee are trying to do

Your manager is trying to make a case that survives peer scrutiny. In calibration, managers advocate for their people, but they're challenged by peers who are advocating for their own people. The question is: can your manager say, with evidence, that you're already operating at the next level? Specifically: that you own something, not just execute tasks on something. That people beyond your direct team know your work. That you've expanded the scope of what the role covers.

The calibration committee is trying to make defensible, consistent decisions across a team or org. Promotions that look like favorites or rewards for tenure get challenged. Promotions that look like recognitions of documented performance and scope expansion go through.

The three levers

Lever 1: Scope expansion. This is the most underused lever. You are promoted to a level when you are already functioning at that level. The fastest path to that is taking on scope beyond what your job description says. This isn't about working more hours. It's about owning something: a project, a process, a relationship, a workstream that you drive end-to-end without being supervised. At Walmart, the people who moved quickly were the ones who showed up to the domain of their work and said "I'll own this" before anyone asked them to. The ones who waited to be assigned things stayed at the same level.

Lever 2: Cross-functional visibility. Your direct manager can advocate for you in a calibration meeting, but their voice is one. Promotions that stick are the ones where multiple people in the room say "yes, I know this person's work, they're operating at that level." If the only people who know what you do are your immediate team, your promotion is contingent on your manager having enough political capital to carry it through alone. Build your footprint: present work to adjacent teams, volunteer to represent your team in cross-functional projects, send the post-meeting summary that lands in everyone's inbox.

Lever 3: Your manager's explicit advocacy. This lever requires a direct conversation that most people avoid having. The conversation is: "I want to get to [next level] by [timeline]. What does operating at that level look like in our context, and what am I missing?" Then take notes. Come back in 30 days with evidence that you're closing the gap. Repeat. Promotions that feel like they "just happened" were usually preceded by an explicit negotiation that the promoted person managed quietly over six to twelve months.

The lever that doesn't work

Technical excellence without scope or visibility gets you rated highly at your current level. It does not, by itself, get you promoted. This is the thing that trips up the hardest workers in any organization: they assume the quality of their individual contribution will carry the case. It won't, because the calibration question is not "who does the best work?" It's "who is ready to operate at the next level?"

I learned this the hard way at Walmart, spending more than a year as lead PM on a large domain, expecting the next-level promotion to follow naturally. A reorg changed my manager, and without the explicit advocacy conversation I should have been having, the case fell through the cracks. The scope was there. The visibility to the right people wasn't. Neither was the explicit negotiation with whoever was going to go to bat for me. All three levers matter.

The honest truth about timing

No advice on promotion levers works if the timing is wrong. New managers need time to form opinions. Calibration cycles have windows. Budget constraints cap how many promotions can happen in a cycle. If you've pulled all three levers and you're still stalled, the conversation shifts to timing: "I'm ready for this promotion. If the current cycle isn't possible, when is the next window and what does the case need to look like to get there?"

That conversation feels hard. It is much harder to never have it and wonder why.

When and how to ask for a raise: timing, data, and tact

Mike Halpert — Tue, 22 Oct 2024 00:00:00 GMT

Raises aren't won by emotion. They're won by evidence: documented impact, market context, and expanded scope. The conversation you're planning to have in your manager's office is the last step in a process that started much earlier, and if you haven't done the earlier steps, the conversation is mostly theater.

This post is the full sequence: when to ask, what to build, and what to actually say.

What a raise conversation actually is

A raise request is a business case, not a personal appeal. Your manager is not the final decision-maker in most cases. They have to take your case to HR or to a compensation committee or to their own manager. When you walk in with "I've been here a year and I work really hard," you're giving your manager nothing to work with. When you walk in with documented outcomes, market data, and a specific number, you're giving them something they can carry into a different room.

That reframe changes everything about how you prepare.

What your manager is trying to do

Your manager wants to reward good performance because it retains good people and because most managers do care about their team's wellbeing. They are also constrained by budget cycles, comp bands, and calibration processes that limit their unilateral authority to give you more money.

The ask that works gives them the ammunition to go to bat for you. The ask that doesn't work puts them in a position where they have nothing to show the comp committee except your tenure and your good attitude.

What good and bad look like in the room

Bad: "I've been here 14 months and I feel like I'm ready for a raise. Can we talk about that?"

Good: "I wanted to talk about compensation. Over the last year I've led X, shipped Y, and taken on Z scope that wasn't in my original role. I've done some market research and my current base is below the range for comparable roles. I'm targeting a [specific number or range]. I want to figure out the right path to get there with you."

The difference is specificity, market context, and an explicit number. All three are necessary. The explicit number is the most commonly omitted and the most important.

The three-part case you need to build before the meeting

Part 1: Your outcomes. Pull your wins log (you've been keeping one, right?), your 1:1 recaps, and any feedback you've received in writing. Extract four to five specific outcomes with metrics. "Managed the client relationship" is not an outcome. "Managed the client relationship through a scope change that initially had them requesting a partial refund; closed the quarter at full contract value" is. If you don't have written receipts, this is why you keep a wins log.

Part 2: Your expanded scope. Write down what your role looked like when you started and what it looks like now. If you're doing more than you were hired to do, document that gap explicitly. Expanded scope is the strongest structural argument for a raise: the job changed, and your pay hasn't kept up with the job.

Part 3: Market data. Use Levels.fyi, Glassdoor, LinkedIn Salary, and direct conversations with peers in similar roles at other companies. Look for a range with the same title, same experience level, and same metro area. Your target should sit inside a defensible range, not be a number you invented.

Timing

Performance review cycles are the easiest window. If your company does annual reviews, that's the moment compensation decisions are already on the table. Ask for the raise conversation two to three weeks before the formal cycle, not during it. You want to give your manager time to advocate before the decisions are locked.

Outside of cycle: right after a visible win, a project completion, or when you've just taken on expanded scope. Not: during a reorg, not when your manager is in a bad stretch, not in the last month of a fiscal quarter when budgets are constrained.

The script

Deliver this in a 1:1, not over email. Request the meeting explicitly: "I'd like some time to talk about my compensation and trajectory here. Can we carve out 20 minutes this week?"

In the meeting:

"I've been thinking about my compensation and I want to talk through it with you directly. Over the last [time period], I've [two or three specific wins]. I've also taken on [expanded scope] that wasn't part of my original role. I did some market research and comparable roles in [city] are ranging from [range]. I'm targeting [specific number]. I'd love to understand what path exists to get there, and what I need to demonstrate to make that happen."

Then stop talking. Let them respond.

If the answer is "not now," the follow-up is: "I understand. Can we agree on a specific date to revisit this, and can you tell me what would make this a yes at that point?" Get the criteria in writing if you can. Vague deferrals are how this conversation disappears for six months.

The raise conversation feels like a lot. It gets easier every time. The first one is always the hardest, and the habit of building the case beforehand is what makes it survivable.

A reader asks: my Big 4 engagement partner keeps moving the goalposts

Mike Halpert — Mon, 14 Oct 2024 00:00:00 GMT

The question (paraphrased from r/Big4):

I'm a first-year on an audit engagement and the partner has changed what he wants three times in the last week. Monday it was a clean workpaper. Wednesday he wanted a client-ready summary. Friday he asked for a deck for the closing meeting. Every version is the input to the next one, and I keep getting feedback that I'm "not quite there." Am I missing something, or is this just what the job is?

Both. This is what the job is, and you are missing something. The good news is the thing you are missing is a technique, not a personality trait. You can install it in a week.

What's actually happening

The partner isn't moving goalposts to mess with you. The partner is refining what he needs as he gets closer to the moment he has to use it. On Monday, he was thinking "I need documentation for the file." On Wednesday, as the client meeting got closer, he started thinking "I need something I can walk the client through." By Friday, reality set in: "I need a deck because the CFO wants to see it in color."

Every version is the same work, scoped up one layer. What feels like chaos to you is a partner thinking through his own deliverable, in real time, using your output as the draft.

Why it feels bad from where you're sitting

Because you are the one redoing the document each time. The partner gets to say "actually, let's also…" and move on. You go back and rebuild.

This is unfair in the moment and completely reasonable on the scale of a career. Your job, at your level, is to be the person who absorbs that iteration without friction. The alternative — a junior who pushes back on every change — gets dropped quickly.

What you can do is reduce how often this happens by anticipating where he's going.

The two-question check-in

The technique that would change your week is a 90-second conversation at the start of each deliverable. Two questions:

"Who's the end audience for this?" Internal file? Senior manager review? The client? The CFO?
"What decision or action does this enable?" Is it documentation, a judgment call, a discussion in a meeting, or a handover?

Those two answers change everything about what "done" looks like. A document for the file is a workpaper with ticks and notes. A document for a client discussion is a one-pager with the three things the client actually needs to know. Same facts, different objects.

Ask both questions at the start, and watch how much less rework you do.

The "sketch the endpoint" move

When you get a new task, before you do any real work, write down:

"If this goes well, the thing that lands on the partner's desk is [X], it's [Y] pages long, and the three things he'll want to see when he opens it are [A], [B], [C]."

Then take it to him. Ninety seconds. "Before I go build this, can I sanity-check the shape? I was going to give you a two-page exec summary with the three numbers from the variance analysis on the first page. Make sense?"

He'll either say yes or course-correct you in ten seconds instead of four hours. You're cheap to course-correct early, expensive late.

This is the most underused move in the first-year toolkit. Seniors notice the people who do it.

What "not quite there" actually means

When a partner tells you a deliverable is "not quite there," it's rarely the technical work. Seniors would catch technical errors before it got to the partner. What's "not quite there" is usually one of three things:

Format / length. Too dense, too long, the wrong object for the audience.
Framing. The first two sentences aren't telling me what matters.
Judgment. You documented what you found but didn't tell me what to do about it.

Next time you hear "not quite there," ask: "is it the shape, the framing, or the judgment?" He'll tell you. Once you know which of the three, you can fix it in ten minutes instead of redoing the whole thing.

The long game

This is an audit-specific version of a universal corporate pattern: work cascades. The person above you restates your work for the person above them. What you produce on Monday is raw material for what they need by Friday. The people who get promoted fastest are the ones who think one step ahead — who produce not just what was asked for, but the object the next audience will use.

—

A year from now, your first-year self won't recognize the person you are when you've internalized this. The shift from "I executed what they asked for" to "I produced what they actually needed" is the entire arc from senior associate to manager. The partner doesn't think he's training you for that shift. He is.

For the weekly rhythm that exposes these misfires early, see the status update template. For the broader 1:1 structure where priority calls get made, see the Manager 1:1 agenda.

—

If you have a question like this, send it in. Anonymity guaranteed.

Understanding your compensation: base, bonus, benefits, and what actually matters early career

Mike Halpert — Tue, 08 Oct 2024 00:00:00 GMT

Most first-offer negotiations fail before they start because the person evaluating the offer is only looking at the base salary. They compare two offers by the number on line one and miss everything below it. That's how people take a lower-paying job while thinking they took a higher-paying one.

Compensation is a package. The package has components. The components matter at different rates depending on where you are in your career, and some of what looks valuable on paper is worth significantly less in practice.

What a compensation package actually is

Total compensation is the sum of what you receive for working somewhere: your base salary (cash, delivered as a paycheck), any bonus (cash, conditional, usually annual), equity (ownership stake, can be stock or options, often illiquid), and benefits (health insurance, retirement matching, PTO, and other non-cash value). Some roles also include commission, profit-sharing, or other variable components.

Your employer is trying to offer a package competitive enough to hire and retain you, at a cost they can justify. Some components of the package are expensive for them (base salary, benefits) and some are relatively cheap until they pay out (unvested equity, performance bonuses). Understanding the structure helps you read which parts of the offer are real and which are conditional on things that may or may not happen.

What good and bad looks like when evaluating an offer

Bad evaluation: "Offer A is $75k and offer B is $72k. Offer A is better." That's true only if everything else is equal, and it almost never is.

Good evaluation: "Offer A is $75k base with no bonus target and a $3k employer 401(k) match. Offer B is $72k base with a 10% annual bonus target and a $5k employer match. Offer B's total expected compensation in year one is higher, and the bonus gives me upside for performance."

The components you need to understand

Base salary is the only guaranteed number. It's what you get paid regardless of company performance, team performance, or whether the bonus program exists next year. In early career roles, base is the number that compounds into future salaries, because your next offer is anchored to your current comp. Optimizing base early has long-term effects.

Bonus is conditional cash, usually a percentage of base paid once a year. The key question is whether the bonus is guaranteed, discretionary, or performance-tied. "Target bonus of 10%" means you can expect 10% in a strong performance year. It doesn't mean you'll receive it. Ask: what was the actual bonus payout for someone at my level last year? A company that consistently pays below target is offering a lower number than the target suggests.

Equity comes in two main forms: restricted stock units (RSUs, actual company shares that vest over time) and options (the right to buy shares at a set price). RSUs at publicly traded companies have real, liquidatable value. RSUs or options at private companies have theoretical value that may or may not convert to cash. Don't put meaningful weight on private-company equity in your first-job decision unless you understand the company's path to liquidity and can talk to someone about the current valuation.

Benefits are real but often underweighted in evaluation. Employer-covered health insurance can be worth $5k to $15k per year compared to self-funded coverage. Employer retirement matching is free money with a delay. Generous PTO has value if you'll actually use it. Add up the concrete value of benefits before concluding that two base salaries are comparable.

What matters most early career

At 22 to 26, before you have dependents or a mortgage, the most valuable components are: base (for compounding), learning opportunity (for market value), and bone-fide health coverage (the one benefit that's worth full weight). Equity at this stage is almost entirely speculative unless you're joining a well-capitalized public company. Bonuses at your level are small enough that the range between good and bad years won't dramatically change your financial picture.

The calculation shifts meaningfully at 30-plus, when dependents appear and the retirement-matching and equity start to compound into something more significant. Early career, the question is: does this role pay me enough to live well, and does it build the skills that justify a higher offer in three years?

The one thing nobody explains: salary compression

At many companies, the market rate for new hires has risen faster than internal salaries have adjusted. A new hire coming in today may make more than a colleague who joined three years ago in the same role. This is called compression, and it's worth understanding because it shapes what raises and promotions look like at that company. If you ask about comp growth trajectories in the interview process, pay attention to whether the answers are specific (merit ranges of 3-5% annually plus promotion bumps) or vague ("we believe in rewarding performance"). Vague usually means the system is ad hoc.

Compensation is a system with rules that mostly favor people who understand them. You don't have to become a comp expert to read an offer well. You just have to know what each line means before you sign.

When to keep your camera on, when to turn it off

Mike Halpert — Sat, 28 Sep 2024 00:00:00 GMT

Camera-on vs. camera-off looks like a small question. It is not. On a remote or hybrid team, it's one of the first signals your colleagues read about how much you care. The signal is often wrong. But it's there, and if you're in your first year, the cost of getting it wrong is higher than the cost of leaving your camera on for a few extra meetings.

Default on when you are new

For your first 90 days, default to camera-on. Not because the rule is "cameras on." It's because people who don't know you yet are trying to form a picture of you, and a literal picture — your face, in the meeting, looking engaged — is the fastest way to accelerate that.

A teammate who's worked with you for three years can read your camera-off tile and think "he's probably walking the dog or he's heads-down on a deliverable, makes sense." A manager who's worked with you for three weeks reads the same tile and thinks "I wonder if he's here at all."

Give the benefit of the doubt time to accrue before you start spending it.

Match the team's rhythm, not the company policy

Once you've been on a team for a few weeks, watch what the senior people actually do. Not what the policy says. Not what your onboarding buddy told you. What do the people you want to be in three years actually do in meetings?

If the VP's camera is off for the standup but on for the stakeholder review, that's your rule. If the most senior engineer's camera is off except for 1:1s, that's your rule. Match the observed pattern. Do not be the one person on a dark call with your face floating in a bright tile.

The specific meeting types

1:1 with your manager: camera on, almost always. This is where you're building the relationship. No exceptions unless you're sick or physically can't.

Team standup / status meetings: match the team. Most cameras off → yours can be off. Most on → yours should be on.

Working sessions with peers: mixed. If you're deep in a doc together, off is fine. If it's a brainstorm, on helps.

Interviews: on. Always. Even if the interviewer's is off.

First meeting with a new stakeholder: on. The introduction is the point.

Large all-hands: off is fine. Nobody's reading your tile.

A meeting you wish you weren't in: still on, if others are. Being visibly present in a meeting you didn't want is a cheaper way to earn credibility than almost anything else you can do in your first year.

What the camera is actually for

It isn't about proving you're there. It's about closing the feedback loop for whoever is speaking. When someone's presenting to a grid of black tiles, they lose the small cues — nods, puzzled looks, the frown that means "you lost me" — that make a meeting useful. A camera-on tile gives them that back.

If you've ever presented into a wall of off-tiles, you know how much harder it is. You're guessing at how it's landing. That's the experience you create for colleagues when you default off.

When off is actually the right answer

Legitimate reasons to turn it off. Don't feel guilty about them.

Bandwidth issues. Drop the camera and tell the room: "camera off to preserve audio."
You're in a chaotic environment. Coffee shop, airport, a car. Off is more respectful than a blurry moving background.
You're on your fifth consecutive video call. Video fatigue is real. "Going camera-off this afternoon — head's pretty fried" — nobody reasonable objects.
Personal appearance circumstance — sick, kid in the background, haven't showered. "Camera off, saving you from the sight of me today." Costs you nothing.

Name the reason briefly. Don't hide it.

The narrate-it trick

If you feel uncertain about turning your camera off in a moment where others have theirs on, say it. One sentence at the top of the meeting: "Going to be camera off for this one — on a walk." Three things happen: people stop wondering, they don't judge it as disengagement, and they respect the transparency.

Silent camera-off tiles with no explanation are where the negative interpretation lives.

—

The strongest performers on any video team — on or off culture — share one trait: they don't let the camera question consume any of their attention. They've made one default, they stick to it, and they put the energy that would have gone into the question into the actual content of the meeting. Pick a default in your first month, run it for a quarter, and stop thinking about it.

If a reader's specific version of this question sounds familiar, see the Reader Q on camera-off norms. For the underlying meeting habits that matter more than the camera, see meeting rules.

The pronunciation and names trick: respect that costs nothing

Mike Halpert — Tue, 24 Sep 2024 00:00:00 GMT

There is a specific kind of meeting moment that happens in international or diverse teams: someone mispronounces a colleague's name, the colleague does the small flinch they've learned to suppress, and everyone moves on like nothing happened. This occurs in companies that have elaborate inclusion initiatives and detailed values decks. It costs nothing to fix and costs something every time it doesn't get fixed.

This post is not a lecture. It's a practical how-to for the first-year employee who wants to not be the person doing the flinch-inducing thing.

Why names matter more than you think

A name is the word a person has heard spoken correctly their whole life by people who know them and love them. Getting it consistently wrong signals, at a low hum, that you haven't invested enough attention to learn it. That signal accumulates. It doesn't create enemies; it creates a mild but durable sense that you're someone who doesn't pay close attention to people.

In a professional setting, where trust is built from hundreds of small signals, "pays close attention to people" is the kind of reputation you want. It's also the kind of reputation that accrues to people who do the small things well. Your manager doesn't announce who gets credit for this. It just becomes part of how they think about you.

What the other person is trying to do

Almost no one corrects mispronunciation directly. It feels confrontational and the moment passes quickly, so most people absorb it and move on. This means you will not get feedback that you're getting it wrong. The absence of correction is not confirmation that you're saying it right.

How to learn a name you're not sure about

Three options, in ascending order of directness:

Ask them directly, in private. "I want to make sure I'm saying your name correctly. How do you say it?" This is the best option and the most underused. Everyone I've ever seen asked this question has responded warmly. The ask signals effort, which is the whole point.

Ask a trusted colleague. If asking directly feels awkward in a given context, asking a mutual colleague is fine: "Hey, how do you pronounce [name]? I want to make sure I'm getting it right."

Use a name pronunciation tool. For names from cultures you're less familiar with, a quick search on a pronunciation guide or name-pronunciation site covers most cases. It takes sixty seconds and removes the guesswork.

What doesn't work: guessing for six months and hoping the colleague will eventually correct you. They probably won't.

What to do if you've been getting it wrong

This is where most people freeze. The options feel like: ignore it forever, or have an awkward moment of acknowledgment. The awkward moment is the right call, and it's less awkward than it feels:

"I realized I've been mispronouncing your name. The right way is [correct version], right? I want to make sure I'm getting it right going forward."

One sentence. Then say the name correctly a few times in natural conversation and the subject is closed. People remember the correction more than the original error.

Beyond pronunciation: the names thing broadly

Getting someone's name right also extends to not shortening it without permission. If someone introduces themselves as Anagnda, "Ana" is not automatically available to you. Some people prefer the shortened version; others don't. The safe default is to use what they gave you until they offer otherwise.

Same for nicknames that appear in someone's email signature vs. their display name. If the signature says "Theo" and the company directory says "Theodore," use "Theo." The signature is the signal.

A note on your own name

If your name is often mispronounced, there's a version of this that goes the other way: making it easy for people to get it right early. Introducing yourself with a quick assist is a reasonable move: "I'm Siobhan, pronounced Sha-VAWN, nice to meet you." Most people will appreciate the guidance and you'll spend less energy on the micro-corrections that follow the other path.

You can learn the names of every piece of internal tooling at a new job in two weeks. Names of the people you work with are at least as learnable and considerably more important.

Dress code decoder: when business casual means something different at every company

Mike Halpert — Tue, 17 Sep 2024 00:00:00 GMT

Dress code is not a fashion statement. It is a translation game.

At every company, the five words “business casual” land the way a word does when you are speaking with someone who uses a different dialect. You nod, you smile, and you hope you are not the person wearing a polo to what the rest of the room treats as a blazer event. Dressing for a new team is not about a closet upgrade. It is about spotting the cues that tell you whether “business casual” for them means “no sneakers” or “bring-your-own-carpet” or “just don’t forget your badge.”

What is a dress code, plain and simple

A dress code is the company's quiet way of setting expectations for how you show up physically, whether in the office or on video. It covers basics like no ripped jeans or visible tattoos in client meetings, but the real version lives in what people actually wear day to day. Forget the handbook photo: the code is the average outfit in the room on a Tuesday.

What the other party is trying to check

Your manager, HR, and the office coordinators are not auditioning each new teammate for a style blog. They are trying to see if you copy the habits of the crew around you. A company that still posts a slide deck titled “Office Lookbook” is hoping you will read it, even though it feels insane. That deck is shorthand for “we want people who notice tone, follow basic rules, and absorb the unwritten handbook.” In a distributed team that still has office days, the physical presentation is the first data point in that checklist. Early signals compound: a clean outfit, punctual arrival, a focused hello, and a sensible follow-through on the questions you were asked, because no one is watching your spreadsheet yet. They are watching how you read the room.

Spicy claim: Most dress codes get enforced by side-eye from your desk neighbor, not a formal write-up from HR.

So when someone calls you for an “onboarding wardrobe touchpoint” you might be tempted to roll your eyes. Yes, it looks like corporate theater. Do it anyway. It earns you a signal that you listened, even if the token adds up to nothing.

What a good dress-code conversation sounds like

A useful exchange is short and practical. You are not trying to get your personality certified. You want details so you can align. Good sounds like:

“I saw the casual Friday photos. Should I expect a lot of denim any day of the week, or are there specific meetings that need more polish?”

“Is the client crew in sneakers? If I show up in loafers will I look out of sync?”

“If I have a hybrid day, is it okay to bring a different look than what I wear on Zoom five days a week?”

What a bad dress-code conversation sounds like

Bad looks like throwing on whatever feels good and saying “I guess this is business casual, right?” Bad looks like a 30-minute mic drop about how you hate dress codes. The goal is to treat the call as a data-gathering conversation, not a manifesto.

How to collect the cues without turning into the uniform police

I've sat through those awkward onboarding chats at Stylitics, where we all pretended the "no flip-flops" rule made total sense for a data team. We all fumbled the first week figuring out if polos counted as too try-hard.

Here is the artifact that keeps the questions organized. Use it at the end of onboarding week, or before you accept a work trip.

:::template{title="Dress code decoder"} Environment note: What do I see from day one? (photos, Slack posts, onboarding slides)
Core rule: What do they say you must never wear?
Stretch rule: What is acceptable when others already look relaxed?
Client-facing changes: What should switch on days with outside visitors?
Follow-up ask: Who can I check with when in doubt? :::

Turn this into a quick shared note or Slack DM so you can point back to it when you are choosing between a blazer and a shirt that just slid out of the laundry basket. Filling it out forces the weird little question, “Does anyone ever wear jeans here?”, to get answered before you walk in because the answers are not on the career site.

The easiest way to collect the answers is to sit across from whoever runs the “new hire welcome” for your team and copy their words verbatim. Your goal is not to argue about style. It is to paraphrase back: “Okay, so when the leadership team is here I swap in a blazer. Got it.” That accuracy is a little miracle. Asking about pants is silly, but do it anyway because getting this wrong is the kind of signal that early-career rules your first quarterly review before you even talk about the work.

Deadpan corporate observation: the video call where one slide is titled “Dress Integrity Levels” and everyone pretends it is normal.

Once you know the baseline, treat it like any other signal. You do not dress to impress, you dress to blend so people can measure your work without being distracted by whether you are trying too hard or not trying hard enough. If the office is oversized flannels and sensible sneakers, don’t show up in a jacket. If the room is three-piece suits, don’t make “quirky tee” your first impression. There are no moral judgments in the middle, just a spectrum of what your team is already doing. Mirror it where it matters.

If you are hybrid or remote, the same attention applies. Share a “working from home” photo with your manager if you need to set the tone. Early signals do not disappear because you are in your kitchen; they just shift to “is your background tidy?” and “does your introduction slide look like you care?” Dress, punctuality, follow-through, and how you introduce yourself all stack together. Nail the first ones so the others are judged on their merit, not on whether you bothered to match the office’s definition of “smart.”

What to do when the room moves the goal posts

If the code seems to shift after you join, new leadership, a product launch, or a new client, ask for an update. Say, “The partnership meeting last week felt more formal than the usual rhythm. Is that the new default?” People are relieved you asked. It saves the five-minute awkward stretch at the start of every meeting when everyone wonders if you are confused. If they say “just look around,” that is a shorthand for “calibrate, then keep the question to yourself.” That is fine. The goal is alignment, not rebellion.

Honest closer: I still misread the code sometimes, especially on those hybrid days when the office vibe shifts without warning, but admitting it fast and adjusting reminds me that belonging comes before the work gets its fair shot.

How to introduce yourself without being weird

Mike Halpert — Tue, 10 Sep 2024 00:00:00 GMT

The first week of a new job turns every chat into a quiet test. You show up as a total unknown. Coworkers pick up clues from your outfit to your Slack hello, sorting out if you're the teammate who'll jump in or the one they'll need to babysit.

An introduction boils down to your core pitch: who you are, what you handle, all in straightforward words. No one wants your full backstory; this just helps the team get a quick read on you.

Your coworkers want to know if you'll slot into their flow without adding hassle. They juggle deadlines and watch for signs you'll contribute from day one.

A solid introduction hits like a quick nod: it covers your role, your main work, and leaves folks with, "Alright, this one's on the same page." It cuts the uncertainty and kicks off actual conversations.

A weak one misses the mark: either a meandering rundown that loses the thread or a bland hello that reveals zilch. Teams stay in the dark about your role, and that drags on progress.

People often see introductions as polite chit-chat. Wrong. They set your work vibe before anyone else labels it for you.

The goal of the intro

Your coworkers boil it down to this: Does this new person lighten my load?

A strong introduction builds a connection. It covers your identity, your responsibilities, and how to reach you. It comes across as a teammate extending a fist bump, not a rookie begging a seat at the table.

Your first intro plays out like corporate speed dating, one sour note and you're backpedaling for weeks.

The three channels

Introductions hit in three spots. Each calls for its own tone.

Slack channel intros

Think of this as the town square: out in the open, easy pressure. Keep it warm, short, and clear.

Skip the "humbled and thrilled" jargon. That lands like a rehearsed beauty queen line. Stick to this setup: Role + Focus + Personal Touch. Sure, tacking on a hobby can feel goofy, like mandatory team-building games we all endure, but it adds a real spark without going overboard.

:::template{title="The Slack Intro"} Hi everyone! I'm [Name], joining as [Role]. I'll be focusing on [Project/Area] for the next few months. Looking forward to working with you all! Outside of work, I'm usually [one specific, non-controversial hobby]. :::

1:1 email or DM intros

These go to the folks you'll team up with daily. Shift from "eager newbie" to "reliable collaborator."

I've been in that spot: midway through my Google internship, I overdid the fancy phrasing in emails to mask not knowing the office layout. We all fumble at the start, but the ones who clicked kept it straight and to the point.

Aim to book a brief call and outline it upfront, so they skip the prep work.

"Hi [Name], I'm [Your Name], the new [Role]. I'm working on [Project] and [Manager] mentioned you're the go-to for [Topic]. Do you have 15 minutes later this week for a quick intro? I'd love to learn how your team works and how I can best support you."

In-person intros

Toughest setup: you're at the coffee station, some director eyes you. You've got seconds in this squeeze.

Don't default to small talk about the rain. Hand them something solid to latch onto.

"Hi, I'm [Name]. I just started on [Manager]'s team as a [Role]. I'm currently diving into [Project X], I think your team handles the [Y] part of that, right?"

Naming a project flips the awkward pause into a work link. Now they've got a hook to chat.

The "New Hire" mindset

Introductions feel like office improv, a touch ridiculous as you step into the role. Lean in regardless.

That newbie buffer exists: it runs three weeks. Ask basic questions, push forward hard, and it won't tag you as overeager. Window shuts, and you're standard issue.

Professionalism means easing the mental lift for everyone else. A crisp introduction signals, "I get the drill here."

These little steps stack up in office life.

I still fire off the odd rambling Slack or textbook line now and then. Corporate bumps leave marks on us all. But nailing a sharp intro spares you the drag of fixing a rough debut.

The email signature nobody notices (until they do)

Mike Halpert — Mon, 02 Sep 2024 00:00:00 GMT

A partner at a firm I used to work with once told me, out of nowhere, "your email sig is clean." It was a strange compliment. I hadn't thought about it in years. But it stuck with me, because he remembered it. Which is the thing about email signatures: people don't notice them until something in them is wrong.

Most early-career signatures are noisy. Four fonts, a quote from Steve Jobs, three social links, a cell phone number, a disclaimer no lawyer asked for, and a photo taken in a different lighting situation than every other part of the email.

None of that makes you look senior. It makes you look like a person who hasn't trimmed.

What a clean signature looks like

Mike Halpert
Senior Director, Commerce
Example Company
mike@example.com · 555.123.4567

Four lines. Name. Title and team. Company. One contact method and a fallback. Matches the body font. No image.

Read it out loud. There is nothing in it that doesn't earn its line. That's the test.

What to cut

The quote. Nobody has ever forwarded an email and said "also I loved the Maya Angelou excerpt at the bottom." Aspirational quotes read as uncertain about yourself.

The "Sent from my iPhone" afterthought. It's a free pass for typos, which is fine, but you should not be sending careful emails from your phone at the level where people are reading your signature closely.

The confidentiality disclaimer. If you don't work in legal or healthcare, and nobody at your company has told you to include one, you don't need one. It's noise and makes you look unsure of the email's contents.

The social links. A LinkedIn link can be useful. Twitter and Instagram from your work email is weird. Github links for engineers are fine. Everyone else: cut.

The image logo. Images don't render in every email client. A clean text signature renders identically everywhere. Simpler is safer.

What's worth including

Your time zone, if you work across time zones regularly. "Based in New York (ET)" after your name is useful. It prevents the Slack message at 8 PM London time.

An out-of-office or calendar link, if and only if you're in a role where people try to book you. A Calendly or Cal.com link is appropriate for sales, recruiting, and any role where the bottleneck is scheduling. If you're a new analyst, don't add one — nobody's trying to book you directly, and a calendar link looks like you're ahead of your seniority.

What to put for your title

Use the formal title. Not your LinkedIn headline. Not the aspirational version. If you are "Analyst, FP&A" on your offer letter, put that. You will have time later to say other things about yourself. The first-year email signature is not the place.

If you have multiple titles (founder + day job, for instance), pick the one that's relevant to the audience. Keep a second signature in your drafts for the other kind of email.

The compound effect

Nobody thinks "I love Mike's signature" and then calls to hire you. But dozens of people will form a tiny impression every time you email them. Clean means organized. Noisy means scattered. Apologetic means junior.

Over five years, that's hundreds of emails to people who may eventually be your manager, your skip-level, your client, your reference. You have one chance to set the default and it costs you thirty seconds to set it well.

—

The email-sig audit takes literally two minutes. The compounding return is wild — you might get a passing comment from a senior partner ten years from now, the way I did, and the signature you set up at 24 will quietly have done its job in every email you sent in between. Cheapest career move in this whole archive.

For the question of when to send an email at all vs. a quick message, see Should you send an email or a Slack?. For the format that keeps your actual message just as clean, see the 3-line Slack that gets faster answers.

Cross-time-zone collaboration: the async-first rules that prevent burnout

Mike Halpert — Tue, 27 Aug 2024 00:00:00 GMT

Async-first isn't a preference. It's a survival strategy when your team spans more than two time zones.

The failure mode in distributed teams is the same everywhere: people default to synchronous communication because it feels faster, until the accumulated cost of 7am calls and 8pm Slack pings lands on whoever's at the wrong end of the overlap. That person burns out or starts setting hard boundaries. Either way, the team loses.

What cross-time-zone collaboration is actually testing

When you join a team spread across time zones, you're being tested on your ability to communicate at a remove. Can you write a message clear enough that the person reading it six hours from now can act on it without a follow-up? Can you make a decision without a room to think out loud in? Can you trust your teammates enough to not chase every thread for an immediate response?

Those skills are rare. Most people were trained in offices where you could lean over and ask. The async version requires pre-writing the question, the context, the decision criteria, and the ask, all in one message that arrives at the other person's morning ready to be acted on.

Your manager in a distributed setup is watching whether you can do this, because the people who can are the ones who produce without generating management overhead. The ones who can't are the ones who create a cascade of "can we jump on a quick call?" messages that eat everyone's overlap window.

What good looks like

Good async communication in a distributed team is self-contained. The message includes: what's happening, what's needed, by when, and who should act. The recipient reads it and can decide or delegate without hunting for context.

Bad async is the question that shows up in someone's morning inbox and requires four follow-up messages to get to an actual ask. Four follow-up messages across a time-zone gap is a two-day delay.

The four async-first rules

1. Write before you ping. Before sending any Slack message or email, spend thirty seconds asking: have I given this person everything they need to respond without asking me anything back? If not, add the missing piece. The goal is a one-reply resolution, not a thread.

2. Default to docs for decisions. Anything that requires more than two people's input should live in a document before it becomes a meeting. The document frames the question, lists the options, and asks for input by a specific date. People add comments asynchronously. A meeting (if needed) resolves only what the document couldn't. This is not slower. It's faster, because the meeting time goes to genuine disagreement, not information transfer.

3. Mark urgency explicitly. "ASYNC, please respond by Thursday EOD" and "LIVE, please respond by tomorrow 9am your time" are different requests that look identical without the label. Pick a team convention and use it. Without explicit urgency markers, everything feels equally urgent and nothing gets prioritized.

4. Protect the overlap window. If your team has two to three hours of genuine overlap, treat that window as office hours, not as the catch-up meeting block. Use it for things that are genuinely stuck, not for things you didn't write down properly. The overlap window is a shared resource and burning it on questions that could have been docs is a team-level tax.

The async stack

Three tools that actually help, without prescribing specific software:

A shared decision log: a running doc where any async decision lives for 48 hours before becoming final. Anyone can object during the window. After it closes, it's decided. This removes the "I didn't see that message" problem and gives async teams a rhythm for moving.

A status board visible to everyone: where current projects live, who's owning what, what's blocked. Not a daily standup replacement, a living doc. Five minutes of update per person per week is enough if the doc is structured well.

A team working-hours signal: simple convention where everyone lists their core hours and their off-hours signal (green dot, status message, whatever). Prevents the innocent "quick question" at 9pm from landing as a demand.

The thing that actually causes burnout

Burnout in distributed teams isn't usually the time zones. It's the combination of time zones and unclear expectations about when response is required. If your manager sends a message at 10pm their time and expects a response before their morning standup, that's a six-hour delivery window at the wrong end of your sleep schedule.

The conversation worth having early: "What's your expectation for response time outside business hours?" is a perfectly reasonable question in week one. Most managers haven't thought about it explicitly and will give you a real answer. The alternative is guessing wrong for six months.

Why your first 30 days feel weird (and what is actually happening to you)

Mike Halpert — Tue, 20 Aug 2024 00:00:00 GMT

First month is its own genre

The first thirty days form a ceremonial stretch where you learn the job, prove your reliability, and absorb an invisible culture without a syllabus. Call it research, orientation, or onboarding: the thing itself is simply what happens before you are trusted to own something more than a meeting note. The checklist includes a sprint of introductions, a handful of mandatory trainings, and a constant sense that someone is watching whether you grasp the difference between urgent and ASAP.

Your manager, the team, and operations folks are not trying to make you feel small. They are trying to reduce risk, which means they mentally budget headspace for you over the next six months. They want to know you will show up, understand their default assumptions, and escalate before anything blows up. If you wander into a meeting and start with this is what I thought, they are still guessing if you have the right map.

Good looks like a room filled with calm statements: Here is the part I now own, here is a question about the workflow I noticed, here are three assumptions I am operating on. It is not charisma: it is clarity. The people in the room hear your plan cadence, hear the gaps you already see, and walk out sensing they can slot you into a process instead of babysitting what you do next.

Bad looks like a lot of silence, a lot of I thought maybe phrasing, and a fog of I will figure it out. The people in the room leave unsure if you are aligned or convinced you are still trying to schedule your first meaningful interaction. That is when orientation turns into backlog padding.

What is actually happening to you

Look, I will admit up front that half these rituals feel partially silly, like everyone is performing adulthood in slow motion. The first month is not about proving you were clever in college. It is about cataloging what everyone else already knows and turning it into a personal reference file.

That is the sharp turn: the weirdness is not your failure, it is your job to learn the rules that everyone else has been following since before you joined. Every little ritual, the daily standup that asks what did you do yesterday even though the doc already recorded it, is theater so stakeholders can see that the machine still works. Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they are late for, all while the status report exists to justify the next one.

At Stylitics, I still have a calendar block labeled just check in three weeks into a project because the process assumes every new initiative goes through back-and-forth calibration twice. During my Google internship, the team lead handed me a list of acronyms and asked me to translate them to English before assigning anything: that sticks because every workplace runs on specialized shorthand. We all traded immediate impact for long-term precision back then; the company wants to be confident you will make fewer surprise assumptions six months from now.

Here is the artifact you can slide into your calendar to keep track of what feels weird and why.

:::template{title="Weekly weirdness log"} Day/Date: e.g., Tuesday week two
What surprised me today: describe the unexpected ritual
What I learned about how work happens: translate surprise into process language
Who owns this ritual: name or role
Next step to test understanding: a quick question or touchpoint :::

Fill this after a standup that felt like a ritual, after a walkthrough where everyone assumed you knew the code, or after the fifteen-minute sync that turned out to be a status rehearsal. Over the first month, you will collect six to eight of these entries. The log turns awkwardness into language you can share in your 1:1s, like I noticed we treat blue tickets differently: is that intentional?

What to do with the weirdness

The weirdness is a signal, not a problem to fix right away. Use it to update your mental model and design small experiments: show up fifteen minutes early to that quarterly kickoff, email your manager a one-line clarification after a confusing chat, request a follow-up meeting to ask exactly what production ready means for a project. The goal is to shrink the unknowns. The more you capture them, the less you look like you are flailing and the more you look like you are translating the process.

The yes this looks silly but do it moment is sending a two-bullet recap after a forty-five-minute session that read like a dry powwow. It feels like you are narrating the obvious, but it protects you. Corporate memory is fragile in month one. You are not supposed to be perfect. You are supposed to be traceable.

It still feels odd. That is fine. This is the handshake nobody taught you: the room just assumes you knew it.

A reader asks: is there a right way to push back on a deadline?

Mike Halpert — Thu, 15 Aug 2024 00:00:00 GMT

The question (paraphrased from r/consulting):

My manager gave me a Friday deadline for a deck that's going to take me most of next week to do properly. I've already got two other things going that he knows about. I don't want to miss the deadline, but I also don't want to deliver something half-baked. Is there a way to push back without sounding like I'm making excuses?

Yes. The thing you're missing isn't courage. It's framing.

Pushback done badly sounds like an excuse: "I can't hit Friday because I've got too much going on." Pushback done well sounds like a request for a tradeoff: "To hit Friday, I'd need to deprioritize X. To keep X on track, I'd need Monday on this one. Which do you prefer?"

Same information. Completely different read.

The four words that change the conversation

"Which do you prefer?"

Those four words turn you from a person explaining why something is hard into a person asking your manager to make a call. Which is what managers are paid to do.

Most new hires skip this step. They say "it's tight" or "I'll try," which either sounds like a complaint or quietly commits you to something you won't deliver. Neither works.

The script

Use this shape, adapted to your context:

"Happy to take this on. If I focus on the deck for Friday, I'd need to push [specific thing] to early next week. If [specific thing] needs to stay on track, Monday works better for the deck. Which one do you prefer?"

Three things this does:

Opens with yes. You're not refusing, you're scoping.
Names the tradeoff specifically. "Too busy" is noise. "The Thompson analysis slides to Monday" is a decision your manager can actually make.
Ends with a question, not a complaint. You've handed the decision back to them.

When Friday is non-negotiable

Sometimes it is. Client meeting, board deck, regulatory deadline. When that's true, your manager will tell you, and at that point you have two options: deliver, or explicitly renegotiate what "done" looks like.

The renegotiation script:

"If Friday is the hard constraint, what would a v1 look like for you? If I aim at the three slides that matter most for the meeting, I can get those right and flag the others as follow-ups."

Same move. Opens with yes. Scopes the tradeoff. Asks for a call.

What not to do

Don't relitigate past deadlines. "You gave me Friday on the last one too and it was tight." Even if true, it changes nothing about this deadline and signals resentment.
Don't front-load your blockers. "I have three things going right now and a dentist appointment Thursday" makes your workload sound like a personal problem. Manager's workload is too.
Don't use "I'll do my best." It's a soft no dressed as a yes. Either commit or renegotiate.

What to do if you've already said yes and now you can't deliver

Raise it as early as possible. Same framing, earlier in the cycle:

"Checking in on the Friday deck — as I've gotten into it, it's bigger than I estimated. I can still hit Friday on the top three sections and push the rest to Monday, or I can hit the full thing by Tuesday. Which works?"

Early renegotiation is a professional skill. Late surprises are a credibility hit. The deadline hasn't changed yet — you're not missing it, you're resizing it.

The underlying principle

Your manager doesn't want a person who says yes to everything. They want a person who is honest about capacity, transparent about tradeoffs, and unambiguous about what's going to happen. Be that person, and you'll be over-trusted, not under-trusted.

—

I've handed in the half-baked Friday deliverable, and I've sent the "which do you prefer" message. The half-baked version always — always — costs more than the renegotiation. The temptation to hide the timing problem until the last possible moment is the strongest at the exact moment you should be naming it. Override it.

For the weekly update that makes these tradeoffs visible before they become crises, see the Status update template. For the broader 1:1 structure where priority calls get made, use the Manager 1:1 agenda.

—

If you have a question like this, send it in. Anonymity guaranteed.

Expat first job: the unspoken rules you need to learn fast

Mike Halpert — Tue, 06 Aug 2024 00:00:00 GMT

The job description was clear enough. The role, the team, the responsibilities. What the offer letter didn't explain was how feedback gets delivered here, whether it's normal to push back on your manager in a meeting, or why everyone in the open office is on muted Slack instead of talking to each other.

That gap, between what the job is and how the culture actually works, is where expat new hires lose the most ground in the first six months.

What you're actually navigating

Professional culture is the sum of a thousand micro-behaviors that people inside a culture absorbed without noticing. Who speaks first in a meeting. Whether silence after a question means agreement or resistance. How directly it's acceptable to say "I disagree." What "flexible hours" actually means versus what it says on paper.

These norms differ by country, by industry, by company, and by team. There is no single "American workplace culture" or "British professional style," just tendencies and variations. But if your baseline professional expectations come from somewhere else, the variations you hit will be larger and stranger than anything your colleagues have to decode.

What your colleagues and manager are trying to do

Your manager is almost certainly not thinking about the cultural gap you're bridging. They're thinking about their own deadlines, their team's output, and whether you're going to be someone they can rely on. They're not making space in their mental model for "this person needs more translation."

Your colleagues are extending their default assumptions about how professional relationships work. When something you say lands oddly, they're more likely to attribute it to you personally than to a cultural difference in communication style. That's not malice. It's how people read signals.

This means the translation work is mostly yours. Which is unfair and also just true.

What good looks like in the first 90 days

The expat who navigates this well doesn't pretend the cultural difference doesn't exist. They learn the local norms as quickly as possible and code-switch with intention, while staying anchored to who they actually are.

Practically: they observe before they opine. They ask clarifying questions about norms directly, framed as curiosity rather than complaint. They find one or two trusted peers inside the company who can serve as cultural translators. They pay close attention to which behaviors get rewarded and which get quietly penalized.

The expat who struggles treats every cultural difference as a personal judgment. They either overcorrect (becoming a performative version of what they think is expected) or undercorrect (assuming their home-country defaults will be understood). Both paths lead to friction that has nothing to do with the quality of their work.

The five norms to decode in week one

Not every cultural dimension matters equally. Five to prioritize early:

Directness level. Does feedback travel directly or through layers of softening? In some cultures, "this needs work" means this needs work. In others, "this is interesting" means it needs work. Get your read wrong and you'll either over-respond to mild comments or miss critical feedback entirely.

Meeting participation norms. Is it expected to speak in every meeting? Is silence in a discussion read as agreement, confusion, or respect? Watch two meetings before contributing substantively. Count how many people talk, how long, and whether questions are welcomed or treated as challenges.

Hierarchy visibility. Some workplaces are nominally flat but functionally hierarchical. The title says "senior associate" but the behavior in the room says "only two people's opinions matter." Figure out who those people are by week two and calibrate accordingly.

Written vs. verbal decision-making. Does anything consequential get decided in hallway conversations, or does it only count when it's in a doc? Some cultures produce endless documentation; others run everything through informal consensus. Know which one you're in before you invest hours in writing things nobody reads.

The friendship boundary. How much personal disclosure is expected in professional settings? Some workplaces expect you to know your colleagues' family situations, life goals, and weekend habits. Others maintain a formal line. Read the room before sharing.

A direct peer is your best source for all five. "I'm still learning how things work here, is it normal to X?" is a question almost anyone will answer honestly, especially in the first month when your asking is explained by newness.

There is no finish line on this. Cultural fluency in a new professional environment accumulates across your entire first year. The goal in the first 90 days isn't mastery. It's enough orientation that your energy goes into the work rather than into reading every room from scratch.

Office politics for nice people: influence without manipulation

Mike Halpert — Tue, 30 Jul 2024 00:00:00 GMT

Most people who say they "don't play politics" are actually just losing at it without knowing the rules. Office politics is not a separate game running alongside the real work. It is the real work, at least the part of the work that determines whether your ideas get resourced and your projects get greenlit.

The good news: you don't have to become cynical to play it well. You just have to understand what you're actually dealing with.

What office politics actually is

Strip away the connotation and here's what you have: people trying to get things done inside a system where resources are limited, goals sometimes conflict, and relationships affect decisions. That's it. Politics is what happens when organizations have more priorities than capacity and people have to negotiate the gap.

When you have an idea that needs sign-off from someone who doesn't report to you, you're doing politics. When you have to get two teams to coordinate who both think the other should go first, you're doing politics. When you're deciding who to loop in on a sensitive finding before the meeting where it lands, you're doing politics.

Being naive about this doesn't make you clean. It makes you slow.

What the other party is trying to do

The colleagues and managers you're navigating are, almost universally, trying to do their own jobs well. They're protecting their team's bandwidth, advancing their own projects, managing their own manager's expectations. They are not, in the majority of cases, trying to undermine you.

The misread that kills most early-career people in politically complex environments: assuming that disagreement is personal. A peer pushes back on your proposal in a meeting. You read it as a turf war or hostility. They were protecting their team's timeline and would have done the same to anyone. The difference matters because the response is completely different.

What good looks like

Influence that isn't manipulation looks like this: you know what other people care about before you ask for anything. You align your pitch to their interests, not just yours. You bring information to people before they have to ask for it. When you disagree, you do it directly and in the room, not in the hallway afterward.

The people who are genuinely good at this tend to be generous with information, reliable about commitments, and honest when they can't do something. Trustworthy, basically. The political benefit of trustworthiness is not subtle: people route around the unreliable ones, and reliability compounds over years into the kind of reputation that opens doors.

The three moves that build influence without games

Read the room before the meeting. Before any meeting where you want something, have a two-minute conversation with the key person who might object. Not to lobby, but to understand where they are. "I wanted to check in on how you're thinking about X before we get into the group discussion." People almost never object in a group to something they've already engaged with one-on-one.

Give credit visibly and specifically. "The framework in this deck came from a conversation with [name] on the research team, wanted to make sure that landed" is a sentence that costs you nothing and builds significant goodwill. People remember who credited them and who didn't.

Put your disagreements on the record early. If you think a direction is wrong, say so in the room with a reason: "I want to flag a concern before we proceed." Then let it go if you're overruled. The move that damages political capital is raising an objection privately after a decision is made. If you didn't say it in the room, you don't get to say it in the hallway.

The thing to watch out for

The version of "office politics for nice people" that goes wrong is when it slides into information-hoarding, alliance-building against someone, or making yourself indispensable by keeping knowledge siloed. Those moves work short-term and destroy trust over years.

I've watched people at Walmart and at places I've worked since build what felt like efficient political positions that crumbled the second there was a reorg. The reason: their influence was positional, not relational. The moment the org chart changed, they were exposed.

Genuine influence is portable. It follows you through reorgs, company changes, even career pivots. It's built the same way every time: showing up, doing what you say, and making people feel seen instead of used.

Time management for new hires: stop staying late and start shipping earlier

Mike Halpert — Tue, 23 Jul 2024 00:00:00 GMT

The staying-late trap is one of the most reliable features of the first year at work. You show up, you feel behind, you stay late to compensate, you're tired the next day, and you fall a bit further behind. Repeat until you're convinced this job is just harder than it should be.

It is not harder than it should be. Your time is being eaten, and you haven't found the leak yet.

What time management looks like at work vs. school

In school, the calendar was pre-set. Class at 10, reading due Thursday, exam in three weeks. Your job was to do the work inside the structure.

At work, you own the structure. Nothing is on your calendar unless you put it there or someone else did. The work expands to fill every available hour, meetings multiply, and the thing you were supposed to finish by noon gets pushed by a "quick call" that ran long. Nobody tells you how to protect the hours that matter. That's on you.

Most new hires manage time reactively: they respond to whatever lands in front of them. Senior people manage it proactively: they decide in advance what the day is for and defend those decisions when the calendar tries to eat them.

What good time management looks like in the first year

Good looks like this: you know what three things you need to finish this week. You've blocked time to do them. Your mornings aren't full of meetings you could have declined or moved. When something comes up mid-day, you can evaluate it against your list instead of just adding it.

Bad looks like this: Sunday night, looking at the week, and you have no idea how it's going to go. You'll find out Monday.

The distance between those two is not willpower. It's a planning habit that takes about 15 minutes once a week.

The three-layer planning system

Everything in your first-year time budget lives at one of three levels.

The weekly layer. Every Monday morning, three tasks: What are the three things that absolutely must ship this week? Write them down. Put them in your calendar as blocks before anything else. These are not aspirational goals. These are commitments.

The daily layer. Every morning, pick the one hardest, most important task on your list and do it first. Not email, not Slack, not reviewing the calendar. The hard thing. This is the single highest-return habit in time management, and the most resisted, because email feels productive.

The triage layer. When something new comes in, it gets sorted into one of four buckets: do it now (takes under five minutes), schedule it (block the time), delegate it (send to the right person), or decline it (meeting you don't need, task that isn't yours). Don't let things sit in a fifth bucket called "I'll figure it out." That bucket is where weeks disappear.

The calendar audit

Once every two weeks, look at your calendar and honestly categorize each meeting: required (you're accountable for an outcome), useful (you learn something or your presence matters), optional (you're an FYI attendee), and unclear (you're not sure why you're there).

For every "optional" and "unclear": cancel or ask. "I want to make sure I'm contributing here, what's my role in this one?" is a perfectly fine question to a meeting organizer, especially when the meeting has six people in it.

The goal is to protect two or three two-hour uninterrupted blocks per week. If you can't find those blocks in your calendar, you don't have a time-management problem. You have a calendar problem, and clearing meetings is how you fix it.

The shutdown ritual

This one is counterintuitive: a daily shutdown routine makes the next morning sharper. Spend five minutes before you close your laptop: write tomorrow's three tasks, clear your inbox to a state you can reopen tomorrow without anxiety, and close all your browser tabs.

It sounds fussy. Do it for two weeks and you'll notice your mornings start sharper and the staying-late impulse weakens, because you've already made tomorrow's decisions and you know exactly what you're returning to.

Staying late is almost never the answer. The answer is a clear list, protected morning time, and a calendar that reflects your actual priorities, not everyone else's.

The First 90 Days OS: your Week 1 boot sequence

Mike Halpert — Sun, 21 Jul 2024 00:00:00 GMT

Nobody judges you for what you know in Week 1. They judge you for your defaults.

Do you communicate clearly?
Do you follow through?
Do you ask good questions without creating extra work?
Do you seem like someone your manager can trust with the next thing?

That's what a "boot sequence" is: the small habits you set up in the first five days so the rest of the ramp doesn't feel like a loop.

The loop most new hires get stuck in

Week 1 is a blur. New systems, new acronyms, new people, a lot of "where do we keep the latest version of ___?"

Without a system, you end up in the same cycle every day:

You're confused.
You ask a question.
You get an answer.
You forget it.
You ask it again.

Not a smarts problem. A system problem.

The five moves

1. Get a real definition of "good"

Most new hires guess what matters, optimize for the wrong thing, and get hit with "why did you do that?"

Three questions will save you weeks. Ask all of them in your first 1:1:

What does success look like by Day 30?
What should I not work on yet?
How do you want updates — Slack or email, cadence, format?

Script:

"To make sure I'm aiming at the right target — what would you want to be able to say about me thirty days from now? And are there traps you've seen new hires fall into that I should avoid?"

That second sentence does the heavy lifting. Managers love the question because they have actual traps in mind and rarely get the chance to name them.

2. Install your note system

Your memory is not a system.

Create one doc called My Job: Notes + Decisions + Glossary. Sections:

People and what they own — names, responsibilities, preferences
Decisions — what we decided, and why
Recurring rules — "we always do X before Y"
Glossary — internal acronyms (yes, this matters)
My open questions — batch them, don't drip them

This is how you look sharp without trying hard. You stop repeating yourself, and the people answering you stop noticing they've answered you twice.

3. Make your manager's life easier

In Week 1, being brilliant is optional. Being low-friction is not.

Send a short end-of-week note Friday afternoon:

Week 1 quick update

Wins: … In progress: … Blocked on: … (here's what I tried) Next up: … One question: …

That last line matters. One question. Not twelve. The point of the note isn't your wins — it's signaling that you're tracking yourself.

4. Ship one small thing

Pick something low-risk, small, visible, and actually useful. Update a doc everyone complains is outdated. Fix a tiny bug. Turn a meeting into a clean action-item list. Write a "how to run this process" checklist.

The point isn't impact. The point is a signal: I close loops.

5. Build a tiny relationship map

Your org chart is not the power chart. In Week 1, identify three people:

one person who reviews your work
one person who unblocks you
one person who gets mad if you surprise them

Then ask your manager:

"Who should I be aligned with early so I don't accidentally create extra work for someone?"

That question alone is worth more than the relationship map.

The thing nobody tells you about Week 1

Looking smart is the wrong target. Looking reliable is the right one. Smart you can fake for an afternoon. Reliable takes ninety days to demonstrate, and once it's there, your manager will hand you the next thing on their plate without thinking.

—

I've onboarded into roles where the first week was a structured boot camp and roles where it was a Slack channel and a prayer. The structured ones were easier. The unstructured ones were higher-leverage — because the system you build in week one in the absence of an official one becomes the version everyone else copies six months later. Either way, the doc, the Friday note, and the small win are how you turn week one into the foundation for the rest of it.

For the full copy/paste version, use the Week 1 Checklist. When you're ready to pair this with a one-page alignment doc, use the 30/60/90 plan template.

The 'One Thank You' Message That Strengthens Your Network

Mike Halpert — Tue, 16 Jul 2024 00:00:00 GMT

Networking is not about collecting LinkedIn connections like they're Pokémon cards. It is about creating a reason for people to actually remember you when a job opens up in two years.

Most people treat the "thank you" note as a formality. They send a generic message that says, "Thanks for your time, it was great chatting!" and then they wonder why the relationship goes cold. That is not networking. That is a digital receipt.

Your manager is juggling thirteen Slack threads and a meeting they're late for, so a thank-you that lands like a polite nothingburger just evaporates.

A real thank-you message is not about manners. It's about proof of impact.

The mechanics of the follow-up

A professional thank you message is a short, written note sent to someone who gave you their time, a referral, or a piece of advice.

The other party is not looking for a compliment. They are looking for a return on their investment. When a senior person spends 30 minutes talking to an intern, they are betting that their advice will actually be used. If you never tell them what happened after the call, they feel like they shouted into a void.

Good looks like a specific update: "I tried that thing you suggested, and here was the result." It proves you listen and that you execute.

Bad looks like a polite vacuum: "Thanks again for the insight!" This tells the other person that the conversation was a pleasant waste of time.

The "Impact Loop" framework

I remember during my Google internship, I'd get advice from people three levels above me. The ones who actually kept mentoring me weren't the ones who sent the "best" thank you notes, but the ones who closed the loop. We've all been there, firing off a quick note and hoping it sticks.

The secret is the delay. You don't just thank them for the meeting; you thank them for the result of the meeting.

If you can't do a delayed follow-up, use this structure for the immediate note:

:::template{title="The Impact Thank You"} The Hook: Reference one specific, non-obvious thing they said. The Action: State exactly how you are applying that insight this week. The Outcome: The specific goal this action helps you hit. The Low-Pressure Close: A simple sign-off that doesn't ask for another favor. :::

Scripts for different scenarios

Depending on who helped you, the tone shifts. But the rule remains: specificity is the only thing that prevents you from sounding like a bot.

The "Coffee Chat" follow-up

"Thanks for the time today. Your point about how [Specific Team] handles [Specific Process] changed how I'm thinking about my current project. I'm going to rewrite my proposal to focus on X instead of Y. Really appreciate the steer."

The "Referral" update

"Just wanted to let you know I finished the final round with [Company]. They asked a lot about [Topic], and I used that framing you suggested during our call. It landed well. Regardless of the outcome, thanks for putting me on their radar."

The "Random Act of Help" note

"That doc you shared on [Topic] saved me about four hours of guessing this morning. I managed to get the [Project] approved by the lead. Thanks for the assist."

Yes, this can feel like you're performing "professionalism theater." Do it anyway. In a corporate environment, the person who closes the loop is the person who gets the next referral.

The long game

The biggest mistake is thinking the thank-you note is a one-time event. Effective networking is just a series of small, low-stakes updates over a long period.

If someone gave you a piece of advice in January, sending a note in March saying, "I'm still using that shortcut you taught me," is a power move. It transforms you from "that intern I talked to once" into "that person who actually gets things done."

It is the corporate equivalent of bringing a bottle of wine to a dinner party, except the wine is just the fact that you aren't a flake.

I've spent time at Stylitics where everything moved too fast for formal mentorship. In that environment, these notes were the only way to maintain a bridge. It's the cheapest networking you'll ever do, and in the end, it just reminds everyone that good advice sticks around longer than the meeting ever did.

First job defaults: the OS checklist that keeps you steady

Mike Halpert — Tue, 09 Jul 2024 00:00:00 GMT

Your first job hits like a slalom course, every gate another ritual: status meetings, Slack threads, three-tiered approval queues. Success comes down to defaults you set up before the chaos lands, not raw talent.

What is this OS checklist? It is twelve small setups you treat like pre-flight checks: notes and updates and feedback loops and boundaries and wins logs and relationship cadences, plus six more rituals that keep the noise from overwhelming you. You carry it through your first three months to shift from flailing to knowing the room's temperature.

Your manager and stakeholders want to trust the work moves without daily rescues. They juggle dashboards and fire drills, and the person they rely on delivers consistent updates, flags barriers to progress, and speaks up before issues blow up. In week two, they check if you make them feel safe handing off tasks for the next six months, not your brilliance.

Good looks like rhythm in the room: "Here is the new data I added, here is what blocks me, here is the option I recommend, here is the partner who needs a thumbs-up." It ends with your manager saying "thanks, that is exactly what I needed," not "send a follow-up email." Good includes the note you email after, so the ask and blocker stick without lost thoughts.

Bad means you wait for progress questions, half your updates land in passive voice, talks close with "let us know when that is ready," and you guess "ready" for a week. Bad brings silence broken by random Slack pings where you explain slips. Bad turns meetings into Slack messages about unclear expectations. Skip that default.

Installing the defaults

Your manager juggles thirteen Slack threads, six open Jira tickets, and a meeting they are late for, so these defaults cut through without adding noise.

Start with six core ones: notes habit, weekly update, feedback cadence, boundary shell, wins log, relationship cadence. Add six more for the full twelve, named below. At Stylitics, I treated them as queue items I ran even when no one else did. I've seen us all scramble without them, but they build the quiet confidence that carries you.

Two rules make them stick. Make each visible: sticky note in your space, doc section, calendar block. Assign an owner: you for notes, the other person for feedback. That kills the "whose job?" confusion.

Here is the checklist, copy it to a doc for your first 90 days:

:::template{title="First job OS defaults"} Default name e.g., weekly wins log
Frequency e.g., every Friday before 3 pm
Purpose e.g., remind manager of small wins before reviews
Trigger e.g., add a line after every shipped ticket
Owner e.g., Me
Signal to others e.g., send link to manager + keep copy in team doc
Next review date e.g., after first 30 days
:::

This setup looks like overkill to the intern scanning their inbox, but it builds clarity. Fill it once, copy to reminders. The win is showing up with the same structure, so "update" never needs redefining.

The twelve defaults

Notes habit – five minutes after every meeting, jot next steps, decisions, promised follow-ups.
Weekly update – Friday afternoon bullet list of what shipped, what is next, blockers needing eyes.
Feedback ritual – every four weeks, message "share one thing that worked and one to adjust."
Personal boundary check – block one focus hour daily, triage invites that stack up.
Wins log – track three a week, forward summary to manager before each review. Keeping a wins log feels half-silly, like prepping your own highlight reel, but it pays off when reviews hit.
Relationship cadence – monthly 15-minute coffees with peers who unblock you, you initiate.
Decision record – document team calls with why and next step, for future reference.
Ask for alignment – post-kickoff, send "here is what good looks like" note, confirm in 48 hours.
Conflict flag – on slipping dependencies, early note with impact, as heads-up not crisis.
Documenting learnings – after major deliverables, note what broke and the fix.
Expectation sync – mid-quarter email to manager: "here is my plate, match your view?"
Personal pulse check – monthly, gauge stress and learning; tweak load or request projects if off.

Email chains requesting updates on update requests drag everyone down, and these defaults pull you out.

Why these stick

I ran the wins log at Stylitics my first quarter there, forwarded it at review with "these are the outcomes I tracked." The reviewer called it the clearest picture they had seen; we skipped twenty minutes recapping my work. We all fumble the first job, but defaults like that turn guesswork into proof.

Boundaries count too. In week one, "no Slack after 7 pm" seems optional. By week six at Stylitics, it showed I knew task times and demands, a quiet pushback on fake hustle.

These defaults reward the steady grind. They turn solo efforts into shared rhythm, the kind that makes your manager nod and move on.

Honest closer

This checklist is not bulletproof. Spikes hit, rituals shift to triage mode. When blur sets in, though, you reboot from habits you built, your own OS keeping the basics steady.

The 30/60/90 Plan That Doesn't Make You Look Like a Try-Hard

Mike Halpert — Fri, 28 Jun 2024 00:00:00 GMT

New hire shows up Day 1 with a twelve-tab spreadsheet titled "30/60/90 Day Plan."

Their manager reads it politely, says "great initiative," and then spends the rest of the week quietly resetting expectations with the team.

The intent is good. The effect is usually not. A 30/60/90 written with zero context tells your manager three things, none of them flattering: you don't know what matters yet, you're optimizing for looking impressive, and you're about to burn cycles on the wrong work.

A good 30/60/90 does the opposite. It's short, drafted out loud, and built to be corrected. It's an alignment doc, not a thesis.

What it's actually for

One page. Four questions:

What should I learn first?
What does "good" look like by Day 30, 60, and 90?
What work is valuable to this team right now?
What do I need from my manager so I'm not blocked for three weeks?

Most onboarding is vibes-based. If your training so far has been a Slack channel and a prayer, you're not imagining it. The 30/60/90 is how you make the implicit explicit before you waste a month.

Six rules that keep it from sounding try-hard

One page. Scrolling means you've drifted into thesis territory.
Ask for input. Don't announce. Your plan is a draft. Say so.
Plain language. "Leveraging cross-functional synergies" is how you signal you've spent a year reading McKinsey decks. Don't.
Tie it to team outcomes. Your manager cares what the team ships, not your self-improvement arc.
Include the help you need. Assumptions, tools, intros, approvals. The doc gets useful here.
Make learning a deliverable. "I can do X without hand-holding" counts.

The one-page template

Copy this. Fill in placeholders. Send.

:::template{title="30/60/90 day plan"}

Role: ___

Team goal(s) this supports: ___

Manager's definition of success by Day 90: ___

Assumptions: access, training time, approvals — ___

Support I need: tools, intros, data, examples — ___

Check-in cadence: ___

Days 0–30: learn and de-risk

Learn: onboarding, product, customers; "how we work" notes started
Relationships: manager, buddy, key partners — each asked: "what does success look like at Day 30/60/90?"
Deliver: one small useful output. One reference artifact.
Signals of progress: fewer basic questions, faster turnaround, clear status

Days 31–60: contribute, own a slice

Learn: deeper domain knowledge in the two most relevant areas
Deliver: one recurring task owned. One scoped project shipped with review.
Risks: what might slow me down, and how I'll mitigate

Days 61–90: operate and improve

Deliver: one initiative led end-to-end. One proposed improvement with an ROI estimate.
Quality bar: definition of "done," review steps
Next: what I should own after Day 90

:::

The email that gets a real answer

Yes, you have to send this. No, your manager is not going to spontaneously start coaching you.

Subject: Quick draft: 30/60/90 alignment (happy to adjust)

Hi [Manager],

I put together a one-page draft so I'm aiming at the right target early. Starting point, not a finished plan.

If you have a few minutes, could you tell me:

What should I change based on team priorities?

Anything here that's not important right now, or wrong timing?

What would make you say "they're ramping well" by Day 30?

Happy to revise after our next 1:1.

Thanks, [You]

On posture

Your plan is allowed to be wrong. Your job is to make it easy for your manager to correct it. That's the whole game.

—

I've watched new hires sweat over a 30/60/90 for three days and produce a doc their manager skims for 90 seconds. The lesson isn't that the doc doesn't matter — it's that the manager's reaction is the actual artifact you're trying to produce. Optimize the doc for the reaction, not the page.

For the Week 1 version of this, see the Week 1 Checklist. For the weekly rhythm that sustains it, steal the Status update template.

How to give updates like a pro: the status OS template

Mike Halpert — Tue, 25 Jun 2024 00:00:00 GMT

Nobody reads your status update. That is the honest starting point. Your manager skims it for three things: what shipped, what's at risk, and whether you're going to need them to get involved. Everything else is noise you wrote for yourself.

Getting this right matters more than almost any other communication habit in your first year. Status updates are the most frequent signal your manager has about how you think. Send bad ones long enough and they start filling in the gaps with their imagination, which is never flattering.

What a status update is actually for

A status update is not a diary entry. It's a report to a decision-maker who has twelve other things to track and limited time to read.

Your manager is trying to answer: can I trust this person to own this without me watching closely? A well-structured update answers that question every single week without them having to ask. A vague one makes them nervous. A missing one makes them assume the worst.

What good looks like vs. what bad looks like

Bad: "This week I worked on the onboarding flow and had some calls with the design team. Still trying to figure out the timeline. Also started looking into the vendor thing."

That update takes 15 seconds to read and produces zero information. The manager walks away more anxious than before.

Good:

Shipped: Finalized spec for onboarding flow v2, approved by design
Next: Hand off to engineering by Thursday; vendor evaluation complete by EOW
At risk: Legal review may push vendor sign-off; flagging now, not yet a blocker

That update takes eight seconds to read and answers all three questions. No follow-up needed.

The format is the whole game. The words inside the format matter much less than picking a format and using it consistently.

The status OS template

Use this every week, every project. Paste it into Slack, email, or your 1:1 doc.

:::template{title="Weekly status update"} [Project or workstream name], Week of [date]

Shipped

[What actually landed this week, in plain language]
[Metric or outcome if available]

Next

[What you're committing to by end of next week]
[Any dependencies the other person needs to know about]

At risk

[Anything that might miss, or a decision that needs to be made]
[Who needs to act and by when]

FYI only (optional, one line for context that doesn't require action)

[Background info your manager might find useful] :::

Three rules for using this well. First: "At risk" is not a confession booth. You're not admitting failure, you're preventing surprises. Flagging a risk before it becomes a problem is the senior move. Second: "Shipped" means done, not in progress. "Continued working on X" is not shipped. If nothing shipped, write "Progress: validated requirements with X, awaiting review from Y." Progress over silence, always. Third: keep the whole thing under six bullet points. If it takes longer than 30 seconds to read, you're writing a memo, not a status update.

The compounding effect

This format starts paying off around week four or five, when your manager stops asking "so where are we on that?" because the update is already in their inbox. That question disappearing is not a small thing. It means they've categorized you as someone who handles their own visibility, which is the category you want to be in.

I've seen people write sprawling paragraph updates every Monday and wonder why their managers still peppered them with check-in questions. The updates weren't wrong, they were just expensive to read. One well-structured six-bullet update lands harder than three paragraphs of context.

The status OS isn't exciting to set up. It's one of the least glamorous habits in this whole archive. But it compounds quietly, the way all the good habits do, and by the time your first review comes around, your manager has 26 weeks of receipts on what you shipped.

Week 1 Checklist: how to look competent in your first seven days

Mike Halpert — Wed, 05 Jun 2024 00:00:00 GMT

Your first week isn't about proving you're smart. It's about eliminating uncertainty.

Most workplace confusion isn't about effort. It's about expectations: who decides, what "done" means, what the deadline really is, what happens if it slips, where the landmines are. Your first five days are when you find that out — without making your manager spell it out.

Three principles

Be useful quickly. Not heroic. Useful.
Ask good questions early. Confusion compounds.
Write things down. Your brain is not a CRM.

You don't need to be perfect. You need to be clear.

Day 0 — The night before

Thirty minutes of setup. Worth it.

Confirm start time, location, any setup instructions
Open a doc called Week 1 — Onboarding with sections: People · Glossary · Links · Questions · Wins

That's it. The rest is real time.

Day 1 — Reset your defaults

Day 1 is about signal, not output.

Show up early, even on Zoom. Punctuality is the cheapest signal you can buy.

Ask for: org chart, team goals, glossary of acronyms (or start one), links to docs, dashboards, ticketing, repos. Confirm logistics: how your manager prefers updates (Slack vs. email), when your 1:1 will be, what "urgent" looks like.

Then ask the two questions most new hires forget:

"To make sure I ramp fast, what are the top three things you'd recommend I read first?"

"Quick style question: do you prefer updates in Slack, email, or in the project doc? And how often is normal here?"

Write down your manager's top three priorities. Write down their stated update preferences. Don't trust your memory.

Day 2 — Map the people

A lot of work is really "who knows what."

Ask your manager: "Who should I meet with to understand how this actually works?" Schedule three to five short intros (15–25 minutes — never an hour, that's an imposition).

In every intro, ask the same three questions:

What are your team's goals right now?
What does a great partner look like?
What's the fastest way I could accidentally make your life harder?

Question three is the one nobody asks. People answer it generously because they have specific answers and rarely get to give them.

For each person, capture: their role, what they own, what they care about (metrics, deadlines, customers), their preferences (Slack vs. email, async vs. meetings). One line per person. This becomes your map.

Day 3 — Define "good"

One of the best career hacks is boring: calibrate expectations early.

Pick the main project you were given. Write a one-page "definition of done." Confirm it.

:::template{title="Definition of Done"}

Outcome

What problem are we solving, and for whom?

Scope

In: Out:

Deliverable

Format: Where it lives:

Quality bar

What does "great" look like? What does "good enough" look like?

Stakeholders

Decider: Approvers: Informed:

Timeline

Milestone 1: Milestone 2: Final:

Risks

:::

Send to your manager:

"I drafted a quick definition of done so I don't miss the target. Can I send it for a fast thumbs-up?"

You will look extremely organized. Most of your peers won't have done this.

Day 4 — Pick a small win

One thing you can ship in Week 1. Not a moonshot. Visible to your manager or team, low risk, finishable in a day or two.

Examples: fix a small bug. Improve a template. Document a confusing process. Close a straightforward ticket. Clean up a report.

Tell your manager:

"For Week 1, I'm going to ship ___. Small but useful. I can finish by ___. If there's a better first win you'd prefer, tell me and I'll adjust."

Shows initiative AND alignment. Hard to do both at once.

Day 5 — Lock in your weekly rhythm

Week 1 isn't done until you have a cadence. Avoid the "I'm busy but nobody knows what I'm doing" trap.

Schedule a recurring 1:1 with your manager
Identify your recurring meetings and what each one is actually for
Set up a running work log + a parking-lot question list
Send a Friday recap

Friday recap:

Wins:

What I learned:

Open questions:

Next week:

Any early feedback for me — anything you want me to do differently?

That last line is gold. Most managers are dying to give micro-feedback but won't volunteer it. Ask once, get it forever.

The "do not do this" list

Don't pretend to understand when you don't
Don't wait a week to ask how priorities work
Don't schedule 60-minute intro meetings
Don't complain about processes before you understand why they exist
Don't try to solve everything in Week 1

Be curious. Be useful. Be steady.

—

I walked into my first job at a big tech company in a brand-new suit my parents had convinced me I'd need. Everyone else was in t-shirts. I spent the day hyper-aware of every signal — how people greeted each other, how they asked questions, what "normal" looked like. That's the texture of Week 1. You're learning the job AND the hidden rules at the same time, and the only sane move is to write the hidden rules down as you spot them.

For a one-page alignment doc to pair with this checklist, use the 30/60/90 plan template.

Status update template: the six-line update that buys you trust

Mike Halpert — Sat, 11 May 2024 00:00:00 GMT

Junior employees tend to fail in one of two ways. They disappear into work and reappear at the deadline. Or they over-communicate in a way that feels anxious ("just checking in… circling back…") and still doesn't create clarity.

A simple, consistent status update fixes both. It signals reliability without creating noise.

The moment a good update prevents

At some point you'll be in a meeting where someone senior asks:

"Are we on track for next Friday?"

If your only honest answer is "I'm not sure," you're already in trouble. Not because things are hard — they are — but because uncertainty spreads. Your manager can't help. Stakeholders can't plan. Deadlines become guesses.

A written update turns "not sure" into a calm snapshot of reality.

The copy/paste version

Subject: Weekly status — [Project Name]

Progress: …
Next: …
Risks: …
Decisions needed: …
Asks (if any): …
ETA / next milestone: …

Send it every week, or every Monday and Thursday depending on the pace. You become the person who never surprises anyone.

Rules that make it work

Short enough to read on a phone. If you need paragraphs, you need a separate doc. A status update should feel like a dashboard, not a novel.

Always include Risks (even if the answer is "none"). People don't fear bad news. They fear late bad news.

"Waiting on access to X; if it isn't resolved by Wednesday, ETA slips two days."

Structure: risk → condition → impact.

If you need a decision, propose a recommendation.

Bad: "What do you think we should do?"

Better: "Decision needed: A vs. B. I recommend A because ___. Unless I hear otherwise by EOD Tuesday, I'll proceed with A."

That last sentence is powerful when used responsibly. It turns ambiguity into motion.

Separate status from story. If something is complicated, put the complicated part behind a link. "Details: [doc link]". Your update is the headline. The doc is the article.

If something slips, say it early.

"ETA update: was Friday, now Tuesday due to ___. Mitigation: ___. Risk: ___. Ask: ___."

Calm. Factual. Accountable.

Match the audience. Same format, different emphasis: managers want clarity / risks / decisions. Stakeholders want milestones / impact. Cross-functional partners want explicit asks plus dates. If unsure, ask: "What cadence and level of detail is most helpful for you?"

A filled-in example (healthy project)

Subject: Weekly status — Onboarding email flow

Progress: Drafted email copy and implemented tracking events in staging.
Next: QA with test accounts. Ship to 10% cohort.
Risks: Legal review may delay launch. If feedback isn't back by Thursday, ship moves to Tuesday.
Decisions needed: Confirm whether we prioritize "welcome" email vs. "tips" email for v1. I recommend welcome-first.
Asks: @Priya — can you intro me to the Legal POC for a faster turnaround?
ETA: 10% cohort live Friday EOD (pending legal).

Not flashy. Credible.

Example when you're behind

Your goal is to remove uncertainty.

Subject: Status — [Project] — ETA update

Progress: Completed A and B. C is 70%.
Next: Finish C. Start QA.
Risks: Main risk is still X. If X happens, we slip another one to two days.
Decisions needed: Confirm whether we cut scope item D to protect the date. I recommend cutting D.
Asks: Need access to ___ (owner: ___). Without it by tomorrow, I can't hit the new ETA.
ETA: Was Fri. Now Tue EOD.

Notice what's not in there: excuses.

Anti-patterns

Vague update: "Making good progress." Progress on what?
Hidden risk: Risks left blank, then surprise! later.
Status dump: 20 bullets of tasks with no signal.
Timid ask: You need a decision but you don't name it.

—

The status update is the cheapest thing in this archive that produces the highest reputational ROI. Ten minutes a week, every week, for a year, and you become the person who's known for being on top of their work — even when you're not, because the format makes the gaps visible early enough to fix. Your peers who skip this are quietly being filed under "surprise risk" in their managers' heads. Don't be them.

Use this format to drive decisions in your next Manager 1:1.

Impostor syndrome is not a feeling. It's a data problem.

Mike Halpert — Tue, 07 May 2024 00:00:00 GMT

You’ve been in the seat for three months. You’ve mastered the art of nodding during meetings while internally screaming because you don't know what "QBR" or "LTV" actually means in this specific context. You are convinced that any day now, your manager will realize they hired a fraud and escort you out of the building.

Welcome. This is the standard experience of the first year, even if we all know it's a ridiculous hazing ritual that nobody admits to.

Impostor syndrome means you doubt your skills and fear being exposed as a fraud, even when evidence shows you're competent. Your manager is trying to figure out if you're delivering value without constant oversight, so they can focus on their own pile of tasks. Good looks like you hitting deadlines with solid work that moves the team forward, and your questions sharpening the discussion. Bad looks like missed deliverables that force your manager to step in, or silence that leaves everyone guessing about roadblocks.

The common advice is to "have more confidence" or "remember you were hired for a reason." That is useless. Confidence is a trailing indicator, not a leading one. You don't feel confident because you're suddenly "better" at your job; you feel confident because you've seen a specific pattern enough times that it no longer scares you.

Impostor syndrome is not a psychological flaw. It is a lack of a feedback loop.

The diagnosis

New grads at Stylitics often mix up "learning the environment" for "being bad at the job." There is a massive difference between a skill gap and a context gap.

A skill gap is: I don't know how to write a SQL query.
A context gap is: I know how to write a SQL query, but I don't know which table holds the "truth" for our revenue numbers.

If you are struggling with the latter, you aren't an impostor. You're just new. The system is designed to be opaque, and the corporate theater of pretending everyone knows exactly what's happening only makes the gap feel wider. I've been there myself, six months into my role at Stylitics, staring at a dashboard wondering why my numbers didn't match the weekly report. We all stumble through that phase.

Your manager isn't some all-seeing oracle: they're juggling thirteen Slack threads and a meeting they're already late for.

The "Am I Actually Failing?" Framework

To stop the spiral, you have to move the goalposts from feelings to artifacts. You cannot argue with a spreadsheet.

Stop asking yourself if you "feel" competent. Instead, audit your output against these three markers. If these are green, you are winning, regardless of the panic in your chest.

:::template{title="Competency Audit"} 1. The "Done" Rate: What % of assigned tasks were completed by the deadline without the manager having to nudge you?
2. The Feedback Loop: In the last 30 days, has your manager explicitly told you to change a core behavior or expressed disappointment in a deliverable?
3. The Question Quality: Are you asking "How do I do this?" (Bad) or "I've tried X and Y, and I'm stuck on Z. Which path is correct?" (Good) :::

If your "Done" rate is high and your feedback is neutral or positive, you are performing. The anxiety you feel is just the sound of your brain expanding to fit a new set of expectations.

How to close the gap

I remember during my internship at Google, there were moments where I felt like the only person in the room who didn't understand the unspoken rules of the codebase. I spent a lot of time pretending to be deep in thought when I was actually just trying to figure out who owned a specific document.

The fix isn't a pep talk. The fix is chasing "the bar" without waiting for permission.

The biggest mistake juniors make is trying to be "perfect" before they show their work. They hide their drafts for two weeks, polish them into a mirror, and then find out they were building the wrong thing. That is how you actually fail.

The pro move is to ship "ugly" versions early for calibration.

"I have a rough outline of the approach. It's 20% done and looks messy, but I want to make sure the logic is right before I spend ten hours on the slides. Do you have five minutes?"

Yes, this feels like admitting you're an amateur. Do it anyway. Showing a messy draft at the 20% mark is a signal of high efficiency. Delivering a polished disaster at the 100% mark is a signal of poor judgment.

The reality of the "Expert"

Here is the secret: the people you are comparing yourself to are also just guessing, they've just been guessing for longer.

Corporate life is essentially a series of educated bets wrapped in a PowerPoint presentation. The "experts" aren't people who have all the answers; they are people who have become comfortable with the fact that nobody actually has the answer.

The feeling of being an impostor doesn't go away entirely. It just evolves. Eventually, you stop worrying if you can do the job and start worrying if the job is actually worth doing. That's progress, even if it means trading one set of doubts for another.

The ‘Market Value’ Habit: Check In Twice a Year

Mike Halpert — Tue, 30 Apr 2024 00:00:00 GMT

Knowing your market value is not about job hopping. It is about negotiating from reality with one more column of data than your manager can shrug off.

The habit I want you to build is the twice-yearly check-in where you refresh your market salary research, summarize what changed, and make a note when the numbers start drifting from the offer on your desk. Not "when I panic after a bonus disappointment," but "midway through each calendar year and six months later regardless of how things feel." That keeps you from presenting your next raise or counteroffer as a surprise to yourself and everyone else.

The ritual you skip until panic day

What is it? A short, private ritual. Open your spreadsheet, plug in current base, benefits, and on-target earnings from your offer, then look up two fresh data points per source: a market-level salary range for your title from a database that lets you filter for your city, and a report from a niche place that actually tracks your stack, niche, or industry.

Two sources keep you honest: the broad public market and the small dataset that tracks your niche. The point is not to prove anyone wrong. It is to see whether the gap between what you are paid and what people in your role are signaling has widened.

What is the "other side" trying to do? Recruiters and compensation partners are trying to keep budgets sane and roll out raises when the numbers line up for them. If they see your request with identical benchmarks every six months, they will start to suspect you are on top of things. If you wait until "the next round" you hand them a mystery file and they have to decode whether your job title matches your actual scope.

The ritual is for you to keep your case resilient, the other side just needs something they can nod at and say, "Yes, that tracks."

What does good look like in the room? A good conversation sounds like "Here are the public ranges for the market, here are two signals from peers doing the same work, and here is how my current comp tracks with that. I'm proposing a shake-up to keep pace before the gap widens." You bring context, numbers, and calm clarity. No palms sweating.

What does bad look like? Sliding into a meeting with a vague "Can we talk about comp?" after hearing "there's no budget left." That conversation is choppy, defensive, and leaves your manager scribbling "follow up after review." You are suddenly sending them a question they have to answer without data, when their favorite answer is "let me get back to you."

Don't make their job harder. Make it obvious when the data says "time to act."

Set it up, set it down

You're not collecting numbers for fun. You are making a one-page note that takes five minutes twice a year. The ritual is this:

Refresh salary ranges for your actual job title, location, and level from a database you respect.
Note any changes in your scope (did you pick up a direct report? own a new roadmap?).
Record if your offer has eroded compared to the market.

Yes, this feels like corporate journaling. Do it anyway.

This is your reusable artifact: a single template you can reuse every six months. It keeps you honest and gives your manager a crisp summary if the moment calls for a raise or a recruiter, a new offer.

:::template{title="market value check-in"} Role/title: insert your current job title Location or market: city / remote region Current comp: base / bonus / equity estimate Market base range: low – high from trusted source Evidence source 1: name + date pulled Evidence source 2: name + date pulled Scope delta: new responsibilities since last check Gap flag: 👍 if still aligned, ⚠️ if market is ahead of you, ⚡ if you are ahead Next step: raise conversation / keep paying attention / send signal to recruiter :::

Use the template, then archive it with a timestamp. Review your last two entries before any meaningful conversation with your manager or recruiter. This is what "ready for compensation talks" really looks like: a brief note with fresh data and a clear next step.

No dramatic deck, no apology about check-ins. Just clean numbers you can point back to.

Keep the habit alive

I've run this check from my desk when the calendar hits April and October. At Stylitics, I'm not waiting for the "formal review period" or the next quarterly "comp calibration" that feels like the spreadsheets' version of a staff meeting that should have been an email. Instead I open the same doc, note what shifted, and decide whether the gap needs addressing now or is worth watching.

Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for. Deadpan corporate observation: the spreadsheet whose sole job is to confirm that salaries will stay the same until finance says otherwise. When you own the other spreadsheet, you can gently pull that one into the same conversation.

This practice does not make you a mercenary. It makes you someone who knows the score before the room decides it for you. That's why "Know your market value before you need it" is not just a catchy line for a newsletter, it is the only way to make reality your negotiating partner, rather than your surprise party.

There is no clean ending to "market value." It is messy, it grows, and every six months you check it and admit you do not have the final answer yet. But the honesty of the ritual keeps you from being blindsided, and that's the part that sticks after you've survived a few cycles of it yourself.

Visibility without self-promotion: the credit context method

Mike Halpert — Tue, 23 Apr 2024 00:00:00 GMT

The version of self-promotion that makes people cringe is real. The LinkedIn post about your personal growth journey, the meeting where someone spends five minutes narrating their own contribution before getting to the point. That behavior is annoying, and avoiding it is reasonable.

The problem is that the aversion to that behavior often extends to all visibility-building, and that's where careers quietly stall. You can do excellent work for two years and still be overlooked for a promotion, not because the work was invisible, but because the connection between the work and your name was invisible.

What visibility actually means

Visibility isn't about being loud. It's about ensuring that the people who evaluate, advocate for, and fund your career have an accurate picture of what you've done.

Your manager has an imperfect picture. Their manager has almost no picture at all. People two levels above you making calibration decisions during performance cycles are working almost entirely from artifacts: what's in the review system, what they've heard from your manager, what they've noticed in meetings. Those artifacts are built over time, not in one conversation.

The people who get promoted without asking for it are not necessarily the best performers. They're the people whose performance is most legible to the decision-makers.

What the other party is trying to do

Decision-makers in calibration meetings are trying to do something harder than people realize: rank individuals they have limited direct exposure to and make consequential calls about comp and title. They rely heavily on narrative. "Tell me about this person." And then they listen to see if the story that comes back is specific, compelling, and backed by outcomes.

Your manager is telling that story. The question is: are they telling it with enough material to land?

The credit context method

Credit context is the practice of giving attribution in a way that also surfaces your own contribution. It's not bragging. It's providing context. The two-line structure is:

"The [project/finding/decision] came from [thing I or the team did]. Wanted to make sure that registered before we moved on."

Or, in a group setting: "[Colleague] and I put together this framework, and the key insight came out of a session we had two weeks ago about [topic]."

You're crediting your colleague. You're also documenting that you were part of the work. This is not zero-sum. Done well, it reads as generous, not self-aggrandizing.

The four low-friction visibility moves

1. CC your manager when something important lands. You shipped something, a partner responded positively, a number moved. Forward it with one line: "Wanted to loop you in, this was the outcome of the X initiative from last quarter." Not "look at me." Just: receipt.

2. Name your contribution in your 1:1. "Quick win" at the top of the 1:1 agenda (see the manager 1:1 template) is where this lives. One sentence, concrete. You're not asking for praise. You're giving your manager ammunition for the next time someone asks "so how is [your name] doing?"

3. Write the recap and send it. After any decision, cross-functional meeting, or project milestone, send the three-bullet summary: what was decided, who owns it, what happens next. The person who sends the recap is the person who gets credited for running the meeting, even if they didn't run the meeting. Write the doc, own the narrative.

4. Surface the context when credit goes elsewhere. If a colleague gets credited for something you contributed to, the move is not silence and not confrontation. It's a private, factual note: "I was also involved in that analysis, happy to talk through it with you if useful." Once. Then move on. Repeated correctioning is corrosive. One factual note is fine.

What doesn't work

Self-promotion that focuses on your identity rather than your work tends to land poorly. "I'm a really strategic thinker" means nothing without evidence. "Here's the analysis that changed how we thought about the product roadmap" is the same claim, attached to an artifact. Artifacts transfer. Claims don't.

I've watched people wait their entire first two years for their work to be noticed organically. A few of them were eventually recognized. Most of them left for somewhere new and started the same pattern over again. Visibility is not a reward for patience. It's a system you maintain, quietly, throughout the work.

Meeting rules: 7 habits that make you the person people want in the room

Mike Halpert — Thu, 18 Apr 2024 00:00:00 GMT

Meetings are where reputations get built, or quietly damaged. Decisions get made or avoided. Confusion gets clarified or multiplied. Work gets assigned or silently orphaned.

You join a meeting titled "Sync." Twenty minutes go by. People share updates. A couple of tangents happen. Everyone is vaguely polite. Then someone asks the question that should have been asked at minute one:

"Wait — what are we trying to decide here?"

The meeting ends. No decision. No owner. No next step. A week later, the same "Sync" is back on your calendar.

Crisp meetings prevent that slow-motion failure. Seven rules you can use even when you're not the boss.

1. State the outcome in one sentence

If you can't say the outcome, you don't have a meeting. You have a calendar-shaped anxiety blob.

Good outcomes:

"Decide between Option A and Option B."
"Align on scope and timeline for Project X."
"Unblock Y so Z can ship."
"Get feedback on the draft before it goes to stakeholders."

Bad outcomes: "Sync." / "Touch base." / "Talk through."

If you're junior and not running the meeting, you can still ask:

"Before we start — what outcome do we want by the end? A decision, alignment, or feedback?"

2. Send a three-bullet agenda

Most meetings fail because nobody knows what they're doing until minute 23.

Three bullets is enough:

Context: what's happening or what changed
Decision or discussion: what we need to answer
Next steps: who does what after

Example:

Context: customer requested feature X; we need to respond by Thursday.
Decision: commit to X now, or propose a phased approach?
Next steps: owner and ETA for the response.

If you're not the organizer, offer: "Want me to send a quick agenda so we can keep this tight?"

3. Start on time. End early.

Starting on time is a professional courtesy. Ending early is a gift.

Start even if someone's late. Late people learn. On-time people feel respected.
If you're done, stop. Don't fill the time with vibes.

"It's 10:00 — I'll kick us off. We can catch [Name] up when they join."

"We've got what we need. I'm giving everyone eight minutes back."

4. Keep the cast small

Every extra attendee adds opinions, scheduling difficulty, context-switching, and slower decisions. Invite people for a reason. If they're FYI, they can be CC'd on the notes.

"Do we need [Name] as a decider, a contributor, or an FYI? If FYI, I'll just send notes."

5. Name the decider

Avoid the deadliest sentence in corporate life:

"So… what do we think?"

If nobody is the decider, you get circular conversation, fake agreement, and no action.

A good meeting has clear roles:

Decider: the person who makes the call
Input providers: people who share constraints
Owner: the person who executes

"Quick check — who's the decider on this? I want to make sure we leave with a clear call."

6. Manage the conversation

Most meetings drift for one of two reasons: someone is thinking out loud, or the team is debating a detail that doesn't matter.

The parking lot. Section in your notes called "Parking lot." When something important but off-topic comes up, capture it and move on.

"That's a good topic. Parking it so we can finish today's decision."

Timeboxing.

"Let's timebox this for five minutes. If we don't converge, we pick a default and move forward."

7. End with action items

Meetings without action items are social events. Close with who does what by when, plus any decisions:

"Before we drop: action items. I have ___ by ___. [Name] has ___ by ___. We decided ___."

The follow-up note

Subject: Notes + action items — [Meeting Name] — [Date]

Outcome: one sentence
Decisions:
Action items:
- [Name] — ___ — due ___
Risks / open questions:

This becomes the team's memory. Also prevents "I thought you were doing that."

If you're junior and not running the meeting

Three high-leverage moves:

Ask the outcome question at the start.
Take notes and read back decisions at the end.
Send the follow-up and be the hero.

"I took notes — I'll send a quick recap with action items so we're aligned."

—

The fastest way to be invited to better meetings is to be the most useful person in the average ones. Send the recap nobody asked for. Ask the outcome question politely. Type the action items in the thread. None of these require seniority. All of them get noticed within a quarter.

For the between-meetings cadence that prevents surprises, use the Status update template.

How to ask for help effectively at work

Mike Halpert — Tue, 09 Apr 2024 00:00:00 GMT

There are two failure modes when asking for help at work. The first is not asking at all: you sit with a problem for two hours, don't want to seem incompetent, and eventually either figure it out the slow way or produce something that's subtly wrong because you were missing context. The second failure mode is asking poorly: "can you help me with this?" with no context, no indication of what you've tried, and no clear picture of what help would actually look like.

Both failure modes cost you time. The first costs you more.

What asking for help actually signals

There is a belief, especially in the first year, that asking for help signals weakness or incompetence. This is almost entirely backward. The behaviors that signal weakness are: being stuck and not flagging it, delivering wrong work because you assumed instead of asked, and asking the same question twice without learning from the first answer.

Asking for help, when done well, signals the opposite of weakness. It signals that you know the difference between what you know and what you don't. That distinction is one of the clearest markers of someone operating at or above their level.

Your manager and your colleagues want you to ask. Not because they enjoy answering questions but because the alternative is you producing wrong work and everyone redoing it later.

What the person you're asking is trying to do

The colleague or manager you're asking is trying to get through their own day. They have their own list and their own deadlines. Every help request lands as a small tax on their attention.

The version of the request that produces a fast, useful response gives them enough context to answer without asking clarifying questions, demonstrates that you've already done some work toward the answer, and makes the ask specific enough that the answer can be short. That combination is respectful of their time and easy to act on.

The version that doesn't work: "can you help me with this?" attached to a long explanation of everything you're confused about. They now have to read the background, figure out what you actually need, and essentially do your thinking for you. That tax is large. Busy people unconsciously deprioritize large taxes.

The framework: PARE

Before you ask for help, quickly run through four questions:

P, Problem. Can you state the problem in one sentence? If you can't state it clearly, you don't understand it well enough to ask someone else to solve it. Clarifying the problem often reveals that you already have most of the answer.

A, Attempts. What have you tried? Two attempts minimum before asking another person. Not because asking is bad, but because most problems have answers in accessible places, and trying first builds the pattern-recognition that makes you faster over time.

R, Request. What specifically are you asking for? A quick answer, a 10-minute explanation, a sanity check on your approach, a connection to the right person? Know this before you send the message.

E, Easy exit. Give the person an easy out if they're not the right resource: "Or if there's a better person to ask, I'll start there." This reads as considerate and is often how you end up routed to the right person faster anyway.

The ask structure in practice

In Slack or conversation:

"I'm stuck on [specific thing]. I've tried [attempt 1] and [attempt 2] and the part I can't figure out is [precise question]. Do you have a quick answer, or know who would?"

In an email where you need more space:

State the context (one sentence), what you've tried (two bullets), the specific question (one sentence), and what kind of help you need (answer / conversation / sanity check).

That structure works across contexts, across seniority levels, and across levels of urgency. The only variable is how much context the recipient needs to understand the question.

The thank-you that keeps the relationship strong

After someone helps you, close the loop. Two sentences:

"Got it, that makes sense. I'll [do X]. Thanks."

Or, if their help led to an outcome worth sharing:

"Quick update: I tried [what they suggested] and it worked. [One-line result]. Appreciate the help."

This is not ceremonial. It tells the person their time was well spent, and it makes them more likely to help you again. The colleagues who build the strongest help networks in their first years are the ones who close loops consistently. It compounds in a way that's hard to overstate.

Asking for help well is a professional skill like any other. The version you use in year one will be different from the version you use in year five, but the core structure, clear problem, documented attempts, specific ask, is the same at every level.

How to ask for help politely in email (without sounding helpless)

Mike Halpert — Tue, 02 Apr 2024 00:00:00 GMT

The email that starts "I was wondering if maybe you could possibly help me with something when you get a chance" is not polite. It's timid. Timid reads as uncertain, and uncertain reads as a higher cost to the recipient, they now have to interpret what you need, whether you actually need it, and how urgent it is.

Polite in an email context means clear, specific, and easy to respond to. Not apologetic. Those are different qualities and they produce different outcomes.

What a help request email is actually doing

When you send a help request, you're asking someone to allocate time and mental energy to your problem. The easier you make that allocation, the more likely they are to do it. The harder you make it, the more likely they are to defer it until they have the bandwidth to figure out what you actually need, which for a busy colleague may mean never.

The goal of the email isn't to convey that you're stuck. It's to give them everything they need to help you in a single read.

What good looks like vs. bad

Bad:

"Hi, I had a quick question about the vendor contract process. I've been trying to figure it out and I'm a bit confused. Would love to chat if you have some time."

The recipient knows you're confused and would like to talk. They don't know what you've tried, what specifically is confusing, or what you need from them. They have to send a follow-up email asking clarifying questions before they can help.

Good:

"Hi, quick question on the vendor contract process. I've reviewed the onboarding doc and the contract template, but I'm not sure whether the security addendum is required for all vendors or just software tools. Do you know off the top of your head, or is there someone better to ask?"

The recipient knows what you've already tried, exactly what you don't understand, and what kind of answer would resolve it. They can reply in 30 seconds with "security addendum is required for all vendors, see Section 4 of the guide" and the loop is closed.

The three-part structure

Every help request email, regardless of context, benefits from the same three-part structure:

Part 1: What I've already tried or know. This is the part most people skip, but it's the most important. "I've reviewed [source] and [source] and the piece I'm unclear on is X" removes the possibility that they'll just say "did you check the onboarding doc?" It shows you've done the work and aren't asking them to do it for you.

Part 2: The specific question. Not "I'm confused about X." The exact question: "Is the security addendum required for all vendors or only software tools?" The more specific the question, the shorter the answer needs to be, and shorter answers get written faster.

Part 3: What kind of help you need. Are you looking for a quick answer, a 10-minute conversation, or a connection to the right person? Naming this prevents them from over-engineering their response. "Even a quick 'here's who to ask' would be helpful" is a sentence that saves everyone time.

The templates

For a factual question:

Hi [Name],

I've checked [source] and I'm still unclear on [specific thing]. The piece I'm trying to figure out is [specific question].

Can you confirm, or point me to the right person?

[You]

For a process clarification:

Hi [Name],

I'm trying to [goal], and I've gotten to the point of [where I am in the process]. I'm unclear whether I should [option A] or [option B] at this stage.

Is there a way to check on this, or do you know off the top of your head?

[You]

For guidance from a more senior person:

Hi [Name],

I'm working on [context in one sentence] and I'm at a decision point. I've considered [approach A] and [approach B], and I'm leaning toward [A] because [reason]. Before I proceed, I'd value your perspective on whether this framing makes sense.

If it's easier to react to a draft, I can send that over instead.

[You]

What "politely" actually means

The version of politeness that sinks help requests is apologetic phrasing: "I'm so sorry to bother you," "I know this is probably a stupid question," "completely understand if you don't have time." These don't read as polite. They read as either socially anxious or as a setup for entitlement (apology followed by a large ask).

Polite in professional email means: respecting the recipient's time by being clear and specific, making the ask easy to act on, and not requiring them to do work you should have done first. You can be extremely clear and specific and also warm in tone. Those qualities are not in conflict.

The best help-request emails I've received were the ones where I read the message and immediately knew what the person needed and could act on it without a clarifying question. That's the target.

Manager 1:1 agenda (the one that makes you look prepared)

Mike Halpert — Tue, 26 Mar 2024 00:00:00 GMT

A weekly 1:1 is partly therapy, partly chess. Mostly chess. Treat it like a vibe check and you'll get vibe-check results — which is to say, you'll get a manager who feels good about the relationship right up until your project goes sideways and they realize they have no idea what you've been working on.

The agenda below makes the chess legible. Run it for a quarter and your manager will start saying "you're easy to work with" in calibration meetings. That's the entire game.

What a good 1:1 actually produces

A 1:1 that didn't generate at least one of these was a coffee chat:

a decision (we chose A over B)
a priority (X first, not Y)
a cleared blocker (access, intro, conflict)
a calibrated bar ("this is what good looks like")

If you're leaving the meeting without one of those — every week, for a month — your 1:1 is decaying. You can fix it.

The 30-minute agenda

Five sections. Hard timeboxes. Pre-write everything in a shared doc.

1. Open with a win (2 min)

Start by reminding your manager you're useful. Not in a fluffy "things I'm proud of" way — in a 15-word receipt:

"Quick win: shipped X, which unblocked Y."

Yes, this feels like LinkedIn-influencer behavior. Do it anyway. Six months from now, your manager is writing your review from memory, and the things they remember are mostly the wins you actively reminded them about.

2. Status in three bullets (5 min)

Shipped: what landed
Next: what you're committing to this week
At risk: anything that might miss

That's the entire thing. If your status takes more than 30 seconds, it's not a status, it's a story.

If nothing shipped, report progress: "Validated requirements with X. Drafted Y, waiting on review." Progress beats silence; absence of progress is what scares managers. Fill the absence.

3. Decisions and blockers (10 min)

This is the core. Bring one or two specific items where your manager's input changes what you do next.

The version that works:

"I can take Option A or B. My recommendation is A because X. Any objections?"

The version that doesn't:

"So… what should I do?"

Open-ended questions force your manager to do your thinking, which they will resent quietly until your next review. Recommendations let them be a sounding board, which they will enjoy. Recommend, don't ask is the single biggest behavior difference between juniors who get promoted and juniors who don't.

Decision scripts that always work:

A/B: "Two paths. A gets us X fast but risks Y. B is slower but gives Z. I recommend A. Comfortable?"

Scope cut: "If we need Friday, I propose cutting X and keeping Y. Same outcome, less risk. Aligned?"

Trade-off: "Given the deadline, I can optimize for two of: speed, quality, scope. Which two?"

Memorize these. Borrow them. Eventually they become your own.

4. Expectations check (5 min)

The most common junior failure mode: doing a ton of work that's technically correct but not what the manager wanted. The fix is one calibration question per 1:1:

"What does 'great' look like for this project?"
"If you were me, where would you focus this week?"
"Anything you want me to change about how I communicate?"

That last one is unreasonably high-leverage. Most managers won't volunteer feedback unless asked, and they'll be relieved when you ask. Ten minutes of awkwardness now beats six months of misalignment.

5. Growth (5 min)

Career talk is not "where do I see myself in five years." It's "what skill should I build next quarter."

"What skill would you like me to build this quarter?"
"What's one area where I'm solid, and one where I need to level up?"
"What would make me easier to manage?"

If your manager is busy or bad at this question, don't force it weekly. Every other week is fine. Every never is not fine — that's how you end up two years in with no idea why you weren't promoted.

The running 1:1 doc

One doc. Newest week on top.

:::template{title="Weekly 1:1 agenda"}

This week (top priorities)

Wins

Status

Shipped:
Next:
Risks:

Decisions / Questions (recommendation included)

[Q] — my rec:
[Q] — my rec:

Blockers

Feedback / Expectations

Growth

Action items

[Me] ___ by ___
[Manager] ___ by ___

:::

Send the link to your manager once. Don't ask "is this okay?" Just use it. Most managers don't have a system; they will silently adopt yours and credit themselves with the structure six months later. Let them.

Three failure modes that trip everyone

You show up empty. Keep a parking-lot section in the doc and write to it all week. The instant you think "I should ask my manager that," it goes in the doc. Otherwise you forget by Tuesday.

Your manager hijacks the meeting. Open with the asks: "Before updates, I have two decisions I need today so I can keep moving this week." Frame it as service, not control. Most managers will respect the structure if you offer it confidently.

You leave with "I'll think about it." Push for the decision: "To confirm — are we choosing A? If so, I'll proceed today." The "I'll think about it" loop is where decisions go to die. Politely close it.

—

I've run this exact agenda across engaged managers, distracted managers, and one manager who clearly didn't want a 1:1 to exist in the first place. The format does the work. You just have to show up and run it.

For a clean weekly update to drop into your 1:1, use the Status update template.

The 30-60-90 day plan for new roles

Mike Halpert — Tue, 19 Mar 2024 00:00:00 GMT

A 30-60-90 day plan sounds like the kind of thing you hand to HR during onboarding and never look at again. That version is mostly for show. The version that actually helps is the one you build for yourself in week one and update every two to three weeks as you learn what's actually true.

Most people start a new job and operate on vibes for the first three months. The 30-60-90 plan is vibes with structure. It forces you to make explicit decisions about where you're going to put your energy, and it gives you something concrete to evaluate against when the inevitable reorientation happens in week six.

What a 30-60-90 plan actually is

A 30-60-90 plan is a prioritized list of what you're trying to accomplish in each of the three phases of a new role. Day 30 is usually about orientation: learning the landscape, the people, the tools, the norms. Day 60 is about starting to contribute: understanding the problems deeply enough to start working on them. Day 90 is about demonstrating impact: shipping something, earning trust, starting to own a domain.

Each phase builds on the last. If you skip the orientation phase and jump to contribution too fast, you'll contribute in the wrong direction and have to redo work. If you stay in orientation too long, you'll seem passive and your manager will start to wonder when you're going to be useful.

What your manager is trying to do with this plan

Your manager wants to know you're oriented. They want to trust that you have a plan for your own ramp. A well-constructed 30-60-90 tells them you've thought about the structure of the first three months and you're not going to need their hand on your back through every decision.

The managers who get frustrated with new hires in the first 90 days are usually frustrated because they don't know what the new hire is doing or where they're going. A visible plan removes that ambiguity. Even if the plan changes (and it will), having one signals that you're managing your own onboarding.

What a strong plan looks like vs. a weak one

A weak 30-60-90 is a list of tasks: "Schedule 1:1s with team, complete onboarding modules, review the product roadmap." These are things you'd do regardless. They're not goals. They're minimum viable activities.

A strong 30-60-90 has goals, not tasks, at each phase. The goal for day 30 isn't "schedule coffee chats." It's "understand the three biggest open questions on the team and know who's working on each." The goal for day 60 isn't "start contributing." It's "have a first draft of the [specific thing] ready for review." The goal for day 90 isn't "feel settled." It's "have shipped or substantially driven [specific outcome]."

The test: would your manager be surprised if you said you'd achieved this goal at the end of the phase? If the goal is so easy it's just assumed, it's a task, not a goal.

The template

:::template{title="30-60-90 day plan"} My name + role + start date

Day 30: orientation

Goal: [What do I need to understand to contribute at all?]
Key relationships to build: [4–6 specific people or roles]
Questions to answer: [The 3–4 biggest unknowns about this role and team]
Success signal: [How I'll know I've done this phase right]

Day 60: contribution

Goal: [What am I trying to deliver or drive in this phase?]
Projects or workstreams I'm engaging with: [List]
Skills or context I need to develop: [2–3 specific gaps to close]
Success signal: [Specific outcome I'll have produced or advanced]

Day 90: ownership

Goal: [What am I starting to own, end-to-end?]
The thing I'm driving: [Specific project or domain]
Relationships that should be stronger: [Which cross-functional partners know my work?]
Success signal: [How will I know I've landed well in this role?]

What I'll need from my manager

[Resources, access, intros, decisions, named specifically] :::

Share this with your manager at the end of week one. Not as a finished document, as a starting point for a conversation. "Here's my current thinking on my first 90 days, does this match your expectations?" is a better opener than "I made a plan," because it invites correction, which you want early.

The thing that will definitely change

The day-60 and day-90 sections will be wrong. You'll learn something in week three that changes your priorities in month two. That's expected. The plan is a calibration tool, not a contract.

What you should update every two to three weeks: the "questions to answer" list and the "success signals." Cross off the questions you've answered. Add the new ones that appeared. As the plan changes, you're building a record of how your understanding evolved, which becomes useful when your first performance cycle comes around and you need to reconstruct the arc of your first quarter.

Sample 30-60-90 day plans: what good actually looks like

Mike Halpert — Tue, 12 Mar 2024 00:00:00 GMT

The internet is full of 30-60-90 day plan templates that all say the same thing: day 30 is for learning, day 60 is for contributing, day 90 is for leading. That framing is fine as scaffolding. It's useless as a plan, because it applies equally to every job and therefore applies to none of them.

A plan that says "in the first 30 days I will learn the business" tells your manager and your future self nothing. The plan that lands is the one specific to your role, your team's actual situation, and the one or two things that genuinely matter most in your particular ramp.

The anatomy of a useful sample plan

Before looking at examples: a useful 30-60-90 has three qualities. It names goals, not activities. "Understand the product roadmap" is an activity. "Identify the two biggest roadmap gaps and understand why they're open" is a goal. Second, it has success signals, not metrics. You often can't define a hard metric in week one. You can define how you'll know you've landed each phase. Third, it's short enough to be read in 90 seconds. A plan that requires a table of contents won't be used.

Sample plan: new analyst, operations

Day 30: orientation

Goal: understand the current operating rhythm and where the breaks are
Key relationships: direct manager, two team leads, the analyst who had this role before me
Questions: what's the biggest recurring bottleneck in the weekly ops cycle? What does a strong vs. weak analyst output look like here?
Success signal: I can explain the full ops cycle to someone new without consulting my notes

Day 60: contribution

Goal: have a first project contribution reviewed and improved
Working on: [specific workstream from manager briefing]
Gaps to close: the BI tool this team uses, the reporting convention they expect
Success signal: I've submitted at least one analysis that passed review with minimal revision

Day 90: ownership

Goal: own the weekly [report type] end-to-end, without supervision
Driving: [specific report or process from manager scoping conversation]
Relationships: my counterpart on the finance team knows my work and can confirm it
Success signal: my manager is no longer checking the report before it goes out

Sample plan: new marketing coordinator

Day 30: orientation

Goal: understand the current campaign calendar and who owns what
Key relationships: campaign leads, design team liaison, one external agency contact
Questions: what's the current approval bottleneck for campaigns? What's the biggest thing that went wrong in the last launch?
Success signal: I can brief a new vendor on our brand guidelines without help

Day 60: contribution

Goal: own one end-to-end deliverable for an active campaign
Working on: [asset type or channel from manager brief]
Gaps to close: the campaign management tool, the internal review process
Success signal: I've shipped one campaign asset that needed only light revision

Day 90: ownership

Goal: be the coordinator of record on a specific campaign from briefing to launch
Driving: [specific campaign or channel from manager]
Relationships: agency contact and design lead know my style and can anticipate my asks
Success signal: campaign launches on time with my name on the internal brief

Sample plan: new product or strategy hire

Day 30: orientation

Goal: understand the product's three biggest open bets and the evidence behind each
Key relationships: the PM or lead who's been here longest, one engineer, one customer-facing person
Questions: what's the hypothesis behind [biggest current initiative]? What would make us pivot?
Success signal: I can articulate the product strategy in one paragraph without sounding like I'm reading from the deck

Day 60: contribution

Goal: have contributed meaningfully to one live problem, not just an orientation exercise
Working on: [from manager brief, a specific problem space or quarter's work]
Gaps to close: user interview access, data access, context on the last three major decisions
Success signal: I've given feedback on an in-progress project that the team incorporated

Day 90: ownership

Goal: be driving at least one clearly defined project or problem space end-to-end
Driving: [from manager brief or proposed during week 3 check-in]
Relationships: my key cross-functional stakeholders know my work
Success signal: I'm the person others come to with questions about [my domain]

What to do with the samples

Take whichever one is closest to your role and adapt it. Change the goals to match your actual context, based on the conversations you've had in week one. Fill in the [bracketed fields] from your manager brief and your own onboarding conversations.

Then share it with your manager in week two. Not as a finished plan, as a starting point: "Here's my current thinking, does this match what you'd want to see?" That conversation is usually shorter than you expect and more useful than any orientation document HR hands you on day one.

How to ask questions at work (script and examples)

Mike Halpert — Mon, 04 Mar 2024 00:00:00 GMT

Being new means you'll have questions. That's not a character flaw. That's the job.

The problem is most new hires send the wrong shape of question. You ask "where's the doc?" or "what should I do?" and you get a vague answer back, which is worse than no answer because now you're stuck and embarrassed.

Twenty minutes of homework + a tight question = a tight answer. Every time.

Questions aren't interruptions — surprises are

Most managers don't get annoyed by questions. They get annoyed by:

Vague questions ("what should I do?")
Late questions asked after you already built the wrong thing
Drive-by questions that force them to do the thinking you should have done

A good question is a mini status update: here's the goal, here's what I tried, here's what I think, here's what I need. That structure makes you look competent even when you're missing context.

The 60-second question script

When in doubt, use this. Works in Slack, email, in person.

1. Frame the goal.

"Quick question — I'm trying to make sure I do this the right way before I go too far."

If it's time-sensitive:

"I'm blocked on X. If I can get two minutes of direction, I can keep moving."

2. Share what you know (one to three sentences).

"Here's what I understand so far: the deliverable is ___, and the audience is ___."

3. Show what you tried. Just show you took a swing.

"I checked the docs and old tickets and found ___. I tried ___, but I'm still unclear on ___."

4. Offer your best guess. This is the part that upgrades you from "junior asking for help" to "teammate making progress."

"My current plan is to do ___ because ___."

5. Ask a specific question — yes/no, A/B, or "what's the standard?"

"Is that the right approach?" / "Should we do A or B? I recommend A. Any objections?"

6. Confirm the next step. Repeat back the decision.

"Got it. I'll do ___ by ___ and send you an update."

That's it.

Five examples (with exact wording)

Unclear deliverable:

"I want to make sure I'm hitting the bar. When you say 'draft,' do you mean a rough outline for feedback, or something you'd be comfortable forwarding to stakeholders? I'm planning to do an outline plus three key slides today. If you want something more polished, tell me and I'll adjust."

You named the ambiguity and proposed a default.

Asking for context without sounding lazy:

"Is there a previous version of this I can use as a reference so I don't reinvent the wheel? I found the Q3 deck in Drive — is that the latest, or is there a more recent version you'd recommend?"

You already searched. You're confirming the best source.

Blocked by access or permissions:

"I'm blocked on finishing ___ because I don't have access to ___. I requested access in Okta about an hour ago. Is there someone on your side who can approve it, or should I route through IT? If I can get access today, I can still hit Friday."

Operational, not emotional.

You think the request is wrong:

"I might be missing context, but I want to sanity-check the approach. If we do ___, it'll take three to four days. If the real goal is ___, I can do Option B in one day. Which outcome matters more?"

You're offering tradeoffs, not resistance.

You made a mistake and need to recover:

"Quick heads-up: I misunderstood ___ and built it as ___. I see now the correct requirement is ___. I can fix it by ___; new ETA is ___. Anything you want me to do differently before I proceed?"

No drama, just clarity.

When to ask — early beats perfect

A common trap: trying to figure it out alone for too long because you don't want to bother anyone. That sounds noble. It's also how you waste ten hours.

A better rule:

Stuck 20–30 minutes? Ask.
Work is multi-day? Ask before you start building.
About to send something external? Ask for a quick review.

Five minutes of discussion prevents days of misplaced work.

Slack vs. meeting vs. email

Slack: quick decisions, clarifications, A/B choices.
Meeting or huddle: complex topics where you need back-and-forth.
Email: formal decisions, longer context, paper trail.

Default to Slack with a clear question, and offer a quick call:

"Happy to hop on a call if that's easier — five minutes would unblock me."

The two templates worth memorizing

Yes/no:

"Goal: ___. Context: ___. My plan: ___. Quick check — is this the right approach?"

A/B:

"Two options: (A) ___ or (B) ___. I recommend A because ___. Any objections?"

—

The thing nobody tells you about asking questions: by year three of any job, you're not asking better questions because you've gotten smarter. You're asking better questions because you've been on the receiving end of enough bad ones to know which shape gets answered. The script above is a shortcut to year three.

For the update format that pairs with good questions, steal the Status update template.

Resolving conflicts with coworkers effectively

Mike Halpert — Tue, 27 Feb 2024 00:00:00 GMT

The instinct when a coworker conflict surfaces is to avoid it and hope it resolves itself. This works occasionally. More often, the avoidance creates a low-grade friction that persists for months, or worse, surfaces at the worst possible moment in a high-stakes meeting where you'd rather it didn't.

Conflict at work is normal. The people who handle it well become the people others want to work with. The people who avoid it accumulate unresolved tension until it leaks.

What workplace conflict actually is

Most coworker conflict isn't personal. It's structural. Two people have different information, different incentives, different definitions of done, or are optimizing for different outcomes. When those differences collide on a deadline or a decision, it reads as conflict even when neither person is being unreasonable.

The other category: genuine friction from a personality clash or a pattern of behavior that's built up over time. This is less common but not rare, and it requires a different sequence.

What the other party is trying to do

This is the question most people skip: what does your coworker actually want in this situation? In most cases, they want the same thing you do: to do their job well, to be treated with respect, and to not have this friction persist.

When conflict feels personal, assume structural misalignment first and test it before concluding it's malice. The test: ask yourself, "if I had their information and their incentives, would I behave the same way?" If yes, this is a coordination problem. If no, there may be something more personal going on.

What good resolution looks like

A well-resolved coworker conflict ends with three things: a shared understanding of what caused the friction, a clear agreement about how to handle similar situations going forward, and no residual weirdness in the relationship. The last one takes the longest.

A badly resolved conflict "ends" with one person winning the argument while the other person shuts down and starts routing around them in future decisions. If you won the argument and lost the relationship, you didn't resolve the conflict.

The step-by-step sequence

Step 1: Wait 24 hours. If you're in the heat of it, don't have the conversation today. The version of you that's frustrated or defensive is not the version of you that resolves things. Sleep on it. Write down what happened, what you think caused it, and what you actually want from the conversation. That clarity is harder to access when you're still in the feeling.

Step 2: Ask for a private conversation. Not in a group meeting. Not over Slack where tone is invisible. Directly: "Hey, do you have 15 minutes this week? I want to clear something up between us." Private and specific. If they decline or keep deferring, you have additional information.

Step 3: Open with the shared problem, not your grievance. Start the conversation from the premise that you're both trying to solve something, not that you're there to explain why they were wrong.

"I wanted to talk about [project/situation], because I think we ended up in a confusing spot and I want to make sure it doesn't happen again."

Not: "I want to talk about what you said in that meeting."

Step 4: State your perspective, then ask for theirs. Say what you observed and how it affected your work. Then stop and ask what their experience was. "Here's how I saw it from where I sat. What was going on from your side?" Listen to the answer. This step resolves more conflicts than any other, because the explanation you hear is almost never what you expected.

Step 5: Agree on the going-forward rule. The point of the conversation is not to relitigate what happened. It's to establish a clearer way of working together going forward. End with something explicit: "So going forward, if X happens, we'll do Y. Does that work?" Simple, concrete, agreed.

What to do if step 4 reveals a real pattern

If the conversation surfaces a genuine, repeated behavior issue rather than a one-time misalignment, the sequence changes. Document what's happened (dates, specifics, impact), raise it again with your direct manager framed as a work-effectiveness issue, and ask for their help facilitating. Going to your manager is not escalation in the pejorative sense. It's using the system correctly.

The version of this that backfires: going to your manager without having the direct conversation first. It reads as going around the person, which creates more friction than the original conflict. Have the direct conversation first. If it doesn't resolve, then involve others.

Conflict handled well is not a tax on the relationship. It's an investment in it. I've had coworkers I got along with superficially for months and genuinely trusted only after we'd had one direct conversation about something that wasn't working. The conversation is always the thing.

Remote onboarding survival: how to be seen when no one can see you

Mike Halpert — Tue, 20 Feb 2024 00:00:00 GMT

Remote onboarding isn't harder because you're remote. It's harder because everything that usually happens by accident in an office has to happen on purpose from your apartment.

The hallway conversation where you learn who actually makes decisions. The lunch where a peer explains how the team really works. The moment someone sees you handling a difficult situation well and updates their mental model. All of that happens by default in person. Remote, it happens only if you engineer it.

What remote onboarding is actually testing

In an office, onboarding tests whether you can do the job. Remote, it tests whether you can do the job and signal that you're doing the job simultaneously, without anyone in the room to notice.

Your manager can't see that you're working. They can only see what you produce, what you write, and how you show up in the meetings they can observe. That's not a problem to solve by turning on your camera more. It's a problem to solve by creating written evidence of your presence and contributions.

Most remote hires fail onboarding not because they aren't performing, but because their performance is invisible. They answer questions in Slack instead of writing documentation. They absorb information passively instead of producing summaries. They do good work in private instead of creating artifacts that live where people can find them.

What good remote onboarding looks like

The person who nails remote onboarding is the person who, at the end of week four, has a trail. Their manager has seen them in 1:1s, read their status updates, noticed their Slack messages in the right channels, and received at least one proactive document from them. The manager can give a coherent answer to the question "so how's [your name] doing?" and it includes specifics.

The person who doesn't nail it is the person who worked hard, asked good questions verbally, and produced no written artifacts. Their manager likes them but can't say why, which is a bad position when calibration season comes around.

The remote onboarding checklist

Three areas to actively manage in weeks one through four.

Written presence. Every meeting you attend: post a three-bullet summary in the meeting channel or relevant Slack thread afterward. What was discussed, what was decided, what happens next. You're not trying to be the designated note-taker. You're creating a trail that shows you were there and understood what happened. Do it for two weeks and people will start expecting it from you, which is its own kind of visibility.

Proactive documents. At the end of week two, write a one-page "what I've learned so far" doc and share it with your manager. Sections: what the team is working on, who the key people are, where the gaps seem to be, and what you're planning to focus on in weeks three and four. Yes, this is somewhat performative. It's also genuinely useful for catching misalignment early, and your manager will appreciate that you organized your thinking.

Calendar discipline. Request 20-minute 1:1s with five to seven key people in weeks one and two: your direct peers, the team lead on projects you'll touch, one or two people from adjacent teams. Don't wait to be introduced. Send a message, explain who you are, and ask for a short call. "I'm new on the [X] team and want to understand how our teams collaborate" is a perfectly reasonable reason. Most people will say yes quickly.

:::template{title="Remote onboarding week-by-week checklist"} Week 1

[ ] Set up your 1:1 with your manager (recurring, same time weekly)
[ ] Introduce yourself in your team Slack channel (role + one personal detail)
[ ] Attend every meeting you're invited to, even the ones you're unclear about
[ ] Start a private "onboarding notes" doc, capture everything

Week 2

[ ] Request 1:1s with 5–7 key people
[ ] Start posting 3-bullet recaps after meetings
[ ] Identify: who are the informal experts on the team?

Week 3

[ ] Share your "what I've learned" doc with your manager
[ ] Pick one proactive contribution to make (a doc, a fix, a question answered in writing)
[ ] Check in: where am I unclear on priorities?

Week 4

[ ] Assess: which relationships do I need to invest more in?
[ ] Propose your 30-60-90 focus areas (even informally)
[ ] Write a second round of meeting recaps with more context, you know more now :::

The availability paradox

One thing that trips up remote new hires: being responsive to the point that you look online constantly, but still not visible in the ways that matter. Answering Slack messages in under two minutes is a signal of availability, not contribution. Producing a useful document is a signal of contribution.

Focus the first 90 days on contribution artifacts over response speed. You can be a three-minute Slack responder and a prolific producer of clear, useful written work. That combination is rarer than it should be and reads as genuinely senior from day one.

Workplace competition: healthy hustle vs. toxic tug-of-war

Mike Halpert — Sat, 10 Feb 2024 00:00:00 GMT

Fresh out of school, you show up with a scoreboard in your head. Top grades, competitive internships, "I can outwork anyone" energy.

That drive is useful. In your first 90 days, though, the real game isn't "win every moment." It's earn trust. And the fastest way to lose trust is to make everything feel like a competition.

The rule:

Healthy competition is "I raise my game." Toxic competition is "I lower yours."

Why work feels different from school

School is individual and clear: one syllabus, one rubric, one grade.

Work is messy. Priorities change. Success is shared. Credit can get political. Your manager evaluates how you operate, not just what you produce. A pure "rank me" mindset inside a team environment creates friction you won't see coming.

Healthy competition, in practice

Compete on:

Clarity — you write things down, you summarize decisions
Reliability — you do what you say you'll do
Speed-to-feedback — you share drafts early
Low-drama execution — you surface risks early, you don't surprise people

Those traits compound. They're also the four traits people with no formal authority can use to become the most-trusted person on a team within a year. Smart is overrated. Reliable is the actual moat.

Toxic competition, in practice

The patterns to avoid:

Zero-sum thinking — if they look good, I look bad
Credit hoarding — working in a silo, not looping people in
Information games — strategic omissions, "forgetting" to share
Ethics drift — exaggerating, blaming, throwing people under the bus
Burnout theater — performing stress as a status symbol

In the first 90 days this is especially dangerous because people are still forming their opinion of you.

Five moves to stay ambitious and trusted

1. Make collective wins visible.

"Quick win: I shipped ___. It unblocked ___ and helped the team hit ___."

Not bragging. Context.

2. Compete on preparation. The most underrated edge is being the person who reads the doc, shows up with questions, and brings a recommendation:

"Two options: A or B. I recommend A because ___. Any objections?"

3. Give credit away aggressively.

"Shout-out to ___ for helping me debug that."
"___'s template saved me time."
"Thanks to ___ for the context — that clarified the approach."

People remember who makes them look good.

4. Don't turn every interaction into a measurement. If your internal monologue is "am I winning this conversation?" you'll get weird. Replace it with: "What does success look like here?" / "What does my manager need to feel confident?" / "What decision can we make so we can move?"

5. Protect your ethics. A surprising amount of career damage comes from tiny compromises that felt "normal" in a competitive moment. Three questions:

Would I be proud if this got screenshotted?
Would I say this in front of my manager?
Am I trying to help the outcome, or just win a point?

If someone else is playing the toxic game

You don't need to win against them. You need to stay credible.

Document decisions in meeting recaps and action items. Toxic dynamics hate clarity.
Keep receipts without being paranoid — links, dates, owners in a doc.
Escalate calmly when needed:

"I want to make sure we're aligned on ownership. My understanding is I'm responsible for ___. If that's not right, can we clarify the owner so nothing slips?"

—

The most-rewarded behaviors in any office aren't actually the most-celebrated ones. The visible-hero work gets applause. The quiet reliable work gets promoted. People who understand this in year one have an unfair advantage over people who don't figure it out until year four. Compete on the version of yourself that the team can rely on, not the version of yourself that wins individual moments.

For a structured way to build trust fast, start with the Week 1 checklist.

Keep a wins log even if you hate bragging

Mike Halpert — Tue, 06 Feb 2024 00:00:00 GMT

Annual reviews punish bad memory. A wins log is the only defense you get before someone else decides whether your job filled a checkbox or moved the needle. It is a simple document: date, result, feedback, metric, updated within a day of delivery. No polish, no emails, just a running list of what actually landed.

The other person in the room, the manager, the calibration committee, the HR person who has to explain you in two sentences, wants one thing. They want a stack of facts they can repeat in their own words, with numbers they can plug into a review comment. They are not there to probe your feelings about work; they are trying to make a defensible decision before the weekend hits. Your log is their cheat sheet.

A good review looks like this: you sit down with two bullets on-screen, you point to the first one and say, "Here's what shipped, here's who felt it, here's what the metric did." You pause. They pass the "Does that match what you heard?" test. You move to the next item. That conversation is calm, dart-free, and focused on the outcome, not whether you "felt productive."

A bad review is you trying to remember what you did last month, muttering about "lots of meetings," and the manager leaning forward asking for something concrete. When the review summary email goes out, the sentence about you is vague and someone else's highlight reel. That is the long-term cost of trusting your brain to do the work of memory.

Keep the log without turning into a walking LinkedIn post

A wins log is not about stroking your ego. It is about giving your reviewer a list of facts to copy into their summary. Think of it less as a brag document and more as a receipt envelope for future-you.

I've never regretted having the details when review time rolled around. You will regret explaining "I was on a long project" in a 15-minute review slot.

Start with a tool that you already look at daily. The more time you spend in it, the more real the habit feels: Notion, Google Doc, old-school spreadsheet, whatever. Create a section called "performance log" or "wins." The method is boring: after every sprint demo, launch, or stakeholder win, take five minutes and log these things.

The log only works if it is short enough to finish before the next caffeine hit. The rule I use now, and the one I followed when I joined Stylitics six months in, was: if it takes more than ten minutes to log something, you are trying to turn it into a story. Keep it bullet form. Keep it precise. When you copy it into a review email, you shouldn't need to rewrite it, just add the context the reviewer asked for.

Here is the entry structure that keeps the entries honest and searchable.

:::template{title="Wins log entry"} Date YYYY-MM-DD Project / context short name or system Outcome what shipped or was resolved Impact metric, customer benefit, time saved, or feedback quote Next step follow-up, help needed, or owner :::

This template keeps you honest about what changed and whether it made a dent. It also gives you a ready-made answer to "what's the next thing?" during the review conversation. Fill out every field the moment the work feels done. If you are still waiting on QA, add that to "next step."

Yes, it feels like a humblebrag ritual, and yes, listing perceived "wins" in a doc feels like framing your life as a press release. Do it anyway. The only thing worse than being unprepared for a review is watching someone else get the credit for your work because their spreadsheet was open.

Deadpan corporate observation: the recurring calendar item titled "review prep sync" that is completely silent until the week before the review. That is the moment most people realize they have no evidence of impact.

Turn entries into review scripts

Inside the log, add a short script you can read when asked "Tell me about the last quarter." Keep it honest, concise, and anchored to the entries. Try this:

"On February 25, I shipped the pricing cadence dashboard. Stakeholders saved three hours of manual analysis, and the leadership email noted the data accuracy improvement. I'm now working on automating the follow-up alerts so the data stays current."

Because you have the log, you are not inventing the story on the spot; you are narrating from evidence. The script is the way you go from "I think I did well" to "Here is the evidence your boss needs to support me."

Another useful habit: link each entry to the actual feedback you got, Slack kudos, email replies, a line from a meeting. When your manager writes their review, they are not just remembering numbers; they are also scrolling through their inbox. Give them a shortcut with a solid quote. "The data is better with the dashboard you built" is a lot easier to repeat than "It was helpful, thank you."

Some entries will be small but still matter. You ended a two-week outage, you walked a new teammate through a process, you freed up a customer support queue. Log them. The log is your mnemonic device. If you rely on memory, you will fall into the common trap: you remember the fight but not the fix. Your reviewer only sees the fight.

At Stylitics, the first time I started logging like this, my log entry was one sentence: "Resolved sync error in the cycle update job, preventing two hours of blocked analysis for merchandising ops." Later, when the annual review came around ten minutes before standup, that sentence became the proof my manager needed to explain why I owned the data pipeline reliability story. There is no glamour in the log, but there is momentum.

I still sometimes cheat and log the entry the night before the quarterly review. That slip-up is how I know the habit matters more than the glamour.

Managing up 101: how to learn your manager's operating system

Mike Halpert — Tue, 30 Jan 2024 00:00:00 GMT

"Managing up" sounds like something a LinkedIn guru says. It makes people think of flattery, or playing the game, or being the type of person who brings their manager coffee. That's not what it is.

Managing up is learning how your manager operates and adapting to it, so the two of you waste less time and friction. It is a practical skill. It is also the thing that separates early-career people who advance from early-career people who feel stuck while producing roughly the same work.

What your manager is actually trying to manage

Most new employees spend their first months trying to do good work. That's table stakes. What they miss is that their manager is simultaneously managing up to their own leadership, across to peers, and down to a team, all with limited time and imperfect information.

Your manager needs you to be someone they can hand things to and stop worrying about. If they have to check on you, that's cognitive load they didn't budget for. If your communication style makes information hard to extract, they'll compensate by micromanaging or by mentally categorizing you as someone who needs supervision.

The goal of managing up is to remove that tax, not to impress. Impressing is a side effect.

What it looks like when someone has figured this out

The person who has figured out their manager's operating system shows up to 1:1s with the right format already. They know whether the manager prefers email or Slack for decisions. They know how much context the manager wants before the recommendation versus after. They know whether the manager likes to think out loud or wants the deck in advance.

The person who hasn't figured it out is constantly surprised. They prep for the wrong thing. They send a Slack when the manager wanted an email. They bring a question when the manager wanted a recommendation. Over months, they start to feel like the manager is hard to read, which is their story for why they aren't advancing.

The four questions to answer in your first 30 days

Most of this can be learned by watching, not asking. Four things to figure out:

1. How does your manager prefer to receive information? Async or sync, written or verbal, long or short. Watch what they do with status updates. Do they read everything or skim for bullets? A manager who skims is telling you something.

2. How do they make decisions? Do they decide fast and adjust, or do they need to sit with it? Do they want your recommendation upfront or your options first? One manager I had wanted three options, ranked. Another wanted the recommendation cold. Wrong format every week was four weeks of friction before I asked directly.

3. What do they care about in calibration? What does their skip-level care about? What are the team's goals for the quarter? Where does your work connect to those goals? Managers think in these terms constantly. The faster you can speak that language, the faster they see you as someone who understands the real job.

4. What are their working-hours boundaries? Late Slack messages at 10 PM are a tell. Some managers expect you to work those hours. Others set them and would be uncomfortable if you matched them. Ask, or watch for two weeks before forming a theory.

The one question worth asking out loud

Most of the above you can figure out by paying attention. One question is worth asking explicitly, inside the first three to four weeks:

"What's the most useful thing I could change about how I communicate with you?"

Yes, it's a little formal. Do it anyway. Every manager who hears it relaxes slightly, because almost nobody asks. And the answer will short-circuit weeks of calibration you'd otherwise do by trial and error.

The check-in doc that holds this together

:::template{title="My manager's OS, 30-day notes"} Communication preference

Format: [email / Slack / in-person]
Length: [detailed / bullets only / executive summary style]
Urgency signal: [what I do when something actually needs them now]

Decision style

Wants: [options + recommendation / recommendation first / just the question]
Timing: [decides fast / needs to sit with it]
Watch-out: [what triggers them to dig deeper vs. wave through]

What they care about

Their skip-level's priorities: [write in after week 2]
Team OKRs / goals: [fill in]
How my work connects: [fill in]

Working norms

Their hours: [observed start/end]
After-hours expectations: [ask explicitly if unclear]
Preferred 1:1 format: [agenda-driven / free-form] :::

Fill this in over your first 30 days. Revisit it after a reorg or a manager change. It's a private document, not something you share, but having it written down prevents you from operating on vibes six months in.

Managing up isn't a one-time fix. It's a recalibration habit. The managers I've worked with most cleanly were the ones who were honest about how they preferred to work, and the best version I've been of myself in those relationships was when I asked quickly and adjusted accordingly.

How to earn a work mentor through small asks, no formal ceremony required

Mike Halpert — Tue, 23 Jan 2024 00:00:00 GMT

Mentorship isn't a badge you pin on someone after a big speech. It's a pattern of them choosing to give you advice because your asks respect their packed calendar.

What mentorship actually is

Mentorship means a more experienced person gives you targeted input on work choices over time. Not general life wisdom or resume reviews. Think: "Should I push back on this scope creep?" delivered in 10 minutes every few weeks. No standing meetings. No "mentor-mentee" labels that make HR forms blush.

What potential mentors want

Seniors aren't sitting around hoping a junior emails "be my mentor." They want to invest in people who ship results and come prepared. Their goal: spot talent that amplifies their own work without draining their bandwidth. Vague outreach signals "time sink ahead." Specific, low-lift requests signal "this one gets it."

What good mentorship exchanges sound like

A solid interaction: You describe a real decision in 30 seconds. They probe twice. You get a crisp path forward. Follow-up email from you: "Tried your suggestion on the stakeholder pushback. Landed the meeting." Next time, same person, slightly bigger ask.

What bad ones sound like

The flop: "Hi, saw you're great at X. Would love to grab coffee and pick your brain sometime?" Crickets. Or the meeting happens, you nod a lot, ask nothing specific, and ghost. They forget you existed by lunch. Worse: the over-eager pitch about your "career vision," turning their calendar slot into unpaid therapy.

Corporate life already packs rooms with enough aimless chats. Don't add to the pile. Yeah, the whole mentor-scouting routine can feel a bit silly, like you're playing corporate matchmaker with zero swipes left.

Spot potentials without the fanfare

Skip the directory search for "VP mentors." Look where work happens. In standups, spot the engineer who flags risks early. The product lead who reframes vague specs into checklists. The designer whose feedback cuts 20% off revision cycles. Not the flashiest promoter. The quiet fixer.

During my internship at Google, I watched one senior dev dismantle a tangled API debate in five sentences. Noted her name. No fanfare.

At Stylitics now, same pattern: watch project post-mortems six months in. Who names the blind spots without blame? That's your shortlist. Aim for three to five names across functions. Not your direct manager, they already have the role.

I've pinged a few of these folks over the years, and we all end up with the same quiet wins when the asks stay sharp. Test with observation first. Next shared meeting, reference their past input casually: "Building on what you said about risk flags last week..." If they engage, they're open. If not, next name.

The mentor scout template

Track three potentials in a private doc. Update after each touchpoint. Forces consistency, which is 80% of earning the relationship.

:::template{title="Mentor scout sheet"} Potential 1: <name/role>

Observed strength: one-sentence skill that matches a gap in your work

First touchpoint: date + what you asked + their exact advice

Follow-through result: did you apply it? What happened?

Next ask idea: specific decision pending, 10-15 min max

Status: green: repeated value | yellow: one-off | red: no response :::

Fill one row per person. Share nothing. This is your dashboard.

Make the first ask land

Script it tight. Email subject: "Quick input on ?" Body under 100 words. Seniors wade through 20 vague coffee invites a week; yours cuts through because it's tied to a real call you're facing right now.

"Hi ,
In <project/meeting>, we're deciding between A (faster, higher risk) and B (safer, two weeks out). I lean A based on .
You've handled similar before, comfortable with 10 minutes this week or next for your take?
Thanks,
"

Send to one per week max. If yes, prep one follow-up question. End with: "Will try and loop back." Do loop back. In two weeks: "Implemented your A-path rec. Dodged the risk, shipped early. Now facing , thoughts?"

Three rounds of this, and "mentor" emerges naturally. They start offering unprompted.

Punch up at the system here: companies peddle "mentorship programs" like they're vitamins. Reality: no program beats repeated proof you're not a black hole for time.

I've seen new devs at startups flame out chasing formal pairings. The ones who thrive ping the same two seniors quarterly with receipts, ten minutes before standup if that's what fits.

That one corporate quirk

The deadpan truth: half the "mentorship" invites land in folders labeled "someday," right next to the team-building ping-pong signup.

Relationships compound like that, small and steady. No ceremony needed. Patterns over pitches win every time, and that's the part that actually sticks after you've survived a few cycles of this cubicle shuffle.

The skill stack plan for your first 90 days

Mike Halpert — Tue, 16 Jan 2024 00:00:00 GMT

Your first 90 days are not an IQ contest. They are a usefulness audition.

A skill stack is the tight bundle of workflows, tools, and business basics that lets you pitch in on real work. Nobody expects you to master the product, the org chart, the customers, the tech stack, the approval paths, the Slack norms, or why Finance takes three business days to reject something in a PDF. Not the polished version from the careers page. The actual version, with shared docs titled "FINAL_v7_use_this" and dashboards everyone screenshots but nobody fully trusts.

Your manager's main question is this: "Can I assign this person a task and get back results without creating more headaches?" That is management at its core, hovering over a spreadsheet with that familiar tired look.

Good looks like you describing your current task, defining what done means, naming the tool or step that comes next, and pinpointing where you are stuck. You are not an expert, but you are pointed in the right direction. Your questions push the work along.

Bad looks like you powering through every onboarding deck, sitting in seventeen intro calls, memorizing six acronyms an hour, and still unable to tell your manager what you will wrap up by Friday. That is like stocking your kitchen with every gadget but defaulting to takeout every night.

The three layers to learn

We have all been the new person fumbling through those early weeks, and building a skill stack early on saved me from spinning my wheels. Think of it in three layers.

Layer 1: workflows

These are the paths work takes from start to finish. Who kicks it off? Who signs off? Where is it tracked? What marks it complete? In a product gig, that could mean ticket setup, spec checks, QA runs, launch updates. In marketing, brief writing, drafts, legal passes, campaign builds, reports. In analysis, data pulls, queries, checks, summaries, stakeholder shares.

Workflows seem dry, but they are the pipes keeping everything flowing. Skip them, and your contributions clog up in unexpected spots.

Your manager is in twelve Slack channels, four open tickets, and a meeting they are already late for. That is why workflow smarts hit hard: they cut the back-and-forth.

Layer 2: tools

Focus on the two or three your team leans on for decisions or deliveries. Skip the company-wide stuff from that onboarding slide, the one tied to a multi-year contract nobody asked for.

Jira for tracking, Salesforce for leads, Looker for data, Figma for designs, Excel for quick math, GitHub for code, Zendesk for support: whatever powers your daily grind. Aim to handle the basics without needing a full screen-share session every time.

Layer 3: domain knowledge

This covers the why behind the work: customers, products, key metrics, rivals, rules, busy seasons, team shorthand. It shows you the stakes.

In my six months at Stylitics, the folks who ramped up quickest were not the ones spouting jargon. They nailed the customer needs, the main metrics, and the ops limits first, so their ideas actually stuck when launch day hit.

Yes, plotting out a learning plan feels a bit like high school project vibes with fancier templates. I have done it, and it beats wandering aimlessly.

The 90-day skill stack checklist

Pull this out weekly for your first three months. Takes ten minutes, no rituals needed.

:::template{title="90-day skill stack checklist"} Role: What job are you actually being paid to do?

Top three recurring workflows:

Workflow one
Workflow two
Workflow three

For each workflow, I know:

Trigger: What starts the work?
Owner: Who drives it?
Decider: Who can say yes or no?
Definition of done: What finished means here
Common failure: Where this work gets stuck

Core tools I need this month:

Tool one, and the three actions I must learn
Tool two, and the three actions I must learn
Tool three, and the three actions I must learn

Domain basics I need to explain out loud:

Customer: Who uses or pays for this?
Metric: What number tells us it worked?
Constraint: What limit shapes the decision?
Vocabulary: Five terms I keep hearing and what they mean

Ignore for now:

Skill, tool, meeting, or topic that is interesting but not needed for my next 30 days

Question for my manager:
“Of these, which one would make me useful fastest if I learned it next?” :::

That manager question is key. Get their take on priorities. Guessing solo often lands you expert-level in something your team dusts off once a year.

Rule of thumb: Prioritize what cuts down on supervision first. Flash later.

What to ignore without guilt

Skip anything unlinked to your immediate tasks, team flows, or business talk.

That means flashy courses, optional brown-bag sessions with backstory decks, or wiki pages from long-gone employees. Learning portals feel like faded hotel hallways: glance if you want, but do not set up camp.

Hold off on advanced tricks until basics click. No point in weekend dives into fancy reports if you cannot map the approval chain. Skip custom dashboards without knowing the team's metrics. And forget strategy memos until you can boil the customer issue down to two sentences. That path leads to slick but useless output.

Full training in 90 days is a myth. Dependability in your corner of the work, then expand: that is the real play.

By day 30, map the main workflows and attached tools. By day 60, handle routine items with minimal oversight. By day 90, catch minor snags before they turn into all-day fixes.

I remember hitting day 90 at my first gig and realizing the stack was not about knowing it all. It was about knowing enough to keep the work moving without constant resets.

Learn the stack that makes you useful. The rest sits in the portal, gathering digital dust.

The secret to good 1:1 meetings (how to make every session count)

Mike Halpert — Thu, 11 Jan 2024 00:00:00 GMT

A 1:1 is not a recurring calendar event. In your first 90 days it's your main alignment mechanism with the person who decides what "good" looks like, what gets prioritized, and what gets forgiven.

Treat it like a strategy meeting, not a vibe check.

The phrase a good 1:1 prevents

The most expensive phrase in early career is:

"Oh — I thought you knew."

If your manager learns something important late — a slipping date, a blocked dependency, an unhappy stakeholder — it's rarely because you're incompetent. It's because you didn't have a reliable place to surface risks, decisions, and tradeoffs.

That reliable place is the 1:1.

The mindset

You're not waiting to be managed. You're practicing managing up. That means you bring the agenda, you bring the decisions you need, and you leave with next steps.

A strong 1:1 produces at least one of these:

a decision
a priority
a cleared blocker
a clearer quality bar

If you leave with none of those, the meeting is drifting into a recurring coffee chat.

Before the meeting (five minutes that makes you look senior)

Use a running doc. Newest week on top. Questions first.

:::template{title="Weekly 1:1 agenda"}

This week (top priorities)

Wins

Status (3 bullets)

Shipped:
Next:
Risk:

Decisions / Questions (manager input needed)

Blockers

Feedback / Calibration

Action items

[Me] ___ by ___
[Manager] ___ by ___

:::

During the meeting

Start positive (two minutes). One win, one sentence of context.

"Quick win: ___. It matters because ___."

Bring blockers with options. Don't bring: "I'm stuck… what should I do?" Bring: "Here are the options. Here's what I recommend. Any objections?"

A/B choice: "We can do A or B. I recommend A because ___. Are you aligned?"

Priority check: "Given my capacity, what's the right order — X then Y, or Y then X?"

Unblock request: "I'm blocked on ___. Can you connect me with ___, or approve ___ so I can move?"

Use your manager for judgment, not trivia. Your manager's real value is priority + judgment. If you're overloaded:

"I can do two of these three this week. Which two should win?"

After the meeting

Send a short recap. Same day.

"Recap: Decisions: ___. Me: ___ by ___. You: ___ by ___."

Paper trail. Fewer misunderstandings. Faster execution.

Common problems, quick fixes

"I don't have anything to talk about." You do. Bring one of:

"What does 'great' look like for my work this week?"
"What's the biggest risk to the plan right now?"
"Is there anything you want me to change about my updates?"

"My manager hijacks the meeting." Open with your two most important asks:

"Before we jump into updates, I have two decisions I need today so I can keep moving."

"I leave with 'I'll think about it.'" Ask for the decision:

"To confirm, are we choosing A? If so, I'll proceed today."

—

The 1:1 is the closest thing to a career growth hack that actually works. Most of your peers will treat it as a recurring coffee chat for the entire first year. The one or two who treat it as the alignment mechanism it actually is will be running parts of the team a year later. The agenda above is twelve minutes of weekly setup. That's the whole price.

For the longer-form version of this with more decision scripts, use the Manager 1:1 agenda.

Assume positive intent until the receipts pile up

Mike Halpert — Tue, 02 Jan 2024 00:00:00 GMT

Early in your career, "assume positive intent" sounds like advice embroidered on a pillow in an HR conference room. I cringe a little typing that, because yeah, it's part of the ritual, and rituals can feel half-silly when you're the one living them.

Still useful. Annoying, but useful.

Assume positive intent means starting with the least dramatic explanation that fits the facts. It's a rule for interpreting coworker actions without jumping to malice right away. The other person is usually trying to get their job done amid the same chaos you face: deadlines, unclear priorities, and endless context switches. Good looks like a quick clarification that keeps work moving without resentment building. Bad looks like snapping back on the first odd Slack or assuming every delay is a personal slight, which turns small bumps into team fractures.

The rule is not "pretend everyone is wonderful." That is how you end up smiling through a calendar invite titled "quick sync" that contains no agenda, six attendees, and one person arriving with a 19-slide deck of feelings.

This matters because your first read is not always your best read. New grads, in particular, are asked to decode a system that refuses to say the quiet parts out loud. The workplace is full of tone, hierarchy, calendar theater, hidden incentives, and people writing "thoughts?" when they mean "please agree by 3:00."

Positive intent keeps you from treating every weird interaction like a felony. Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for. That's the default state, not a plot against you.

But it has an expiration date.

Start generous, then get specific

The first time someone does something frustrating, assume there is context you do not have. Not forever. First.

That small pause protects your judgment. It keeps you from writing a whole courtroom drama in your head because a coworker replied "fine" without an exclamation point. Corporate chat has turned punctuation into weather, which is a sentence I dislike having to type.

I've seen this play out at Stylitics more times than I can count: a rushed reply lands flat, but the sender was just squeezing it in between two back-to-back calls. A good first response sounds like this:

"Hey, I may be missing context. When you said X, did you mean Y? I want to make sure I'm reacting to the right thing."

That sentence is boring. Boring is powerful. It gives the other person a ramp back to sanity without making you pretend you didn't notice the issue.

Intent is not impact. Impact is the thing that lands on your desk, in your workload, or in your stomach at 9:47 p.m. The trick is not choosing one. It is checking intent once, then managing impact if the behavior repeats.

Workplace communication is not about being nice. It is about reducing avoidable damage.

The three-receipt rule

Here is the framework I'd use. One incident gets curiosity. Two incidents get a boundary. Three incidents get documentation or escalation.

That is the whole rule. Short enough to remember when your brain is busy trying not to type "per my last email" with your entire soul.

First receipt: clarify

The first time, ask for meaning.

"I want to make sure I understood. Are you asking me to change the direction, or just flagging a concern?"

You are not accusing. You are translating. The goal is to turn weird fog into a sentence with a verb.

Second receipt: name the pattern

The second time, do not treat it like a fresh surprise. Name what has happened twice, calmly and specifically.

"This is the second time the deadline changed after I had already started the work. I can adjust, but I need the new priority confirmed before I rework it."

Notice the shape: fact, impact, next step. No character analysis. No "you always." No Slack novella. Just the receipt.

Yes, this can feel like you are auditioning for the role of Office Adult in a play no one wanted to attend. Do it anyway. Specificity is your shield.

Third receipt: protect the work

The third time, you move from assuming to managing.

"This has happened three times now: the scope changes after work begins, and the deadline stays the same. I'm going to document the current decision in the project doc and confirm trade-offs with [manager/team] before continuing."

This is not tattling. This is gravity. Patterns need a paper trail because memory in companies is highly selective. Funny how the organization can remember a typo from March but not the meeting where everyone agreed to cut the launch scope.

Use documentation when the repeated behavior affects deadlines, quality, credit, workload, or your reputation. If it is just an annoying personality quirk, vent to a friend, take a walk, and do not build a federal case around someone's love of vague calendar titles.

When to drop the assumption

Drop positive intent when the pattern becomes more informative than the explanation.

If someone keeps excluding you from meetings where your work is decided, the issue is not whether they "meant well." The issue is that your work is being redirected without you in the room.

If someone gives you public criticism but private praise, the issue is not whether they are "just direct." The issue is that the room hears one version and your career file needs the other.

If someone repeatedly takes credit for your work, the issue is not whether they forgot to mention you. The issue is that forgetting has become useful to them.

Assume positive intent at the start. Do not donate your pattern recognition to keep the mood pleasant.

The move is to stay factual:

"I want to flag a pattern. In the last two project updates, my work on X was presented without my name attached. Going forward, I'd like ownership reflected in the notes and the readout."

That sentence will make your pulse do little office park laps. Fine. Say it anyway.

The point is not to become cynical. Cynicism is lazy protection. It feels smart because it arrives pre-disappointed. But it also makes you worse at reading good people having a bad week.

The better version is cleaner: generous on the first read, precise after that. We all learn this the hard way, watching one too many "quick syncs" turn into something else entirely.

Positive intent is a good opening move. Just don't keep playing it after the receipts are already on the table.

(Word count: 1,028)

How to disagree with your boss without detonating the room

Mike Halpert — Tue, 26 Dec 2023 00:00:00 GMT

Disagreement is allowed. Disrespect is not. That line sounds obvious until you are sitting across from the person who approves your work, your projects, and your promotion packet in a very annoying plot twist.

You can challenge the idea without challenging the person. That is the whole skill.

What the disagreement is really about

To disagree with your boss means you believe their proposed direction has a risk, gap, trade-off, or better alternative worth discussing before the team commits. It is not a courtroom scene. Nobody is pounding a desk. Nobody needs to announce they are "just being honest," which is the workplace equivalent of revving a leaf blower indoors.

Your boss is trying to make a decision that survives contact with reality: timelines, budget, other leaders, customer complaints, the weekly status meeting where every project is somehow both green and on fire. They are not only evaluating your point. They are evaluating whether accepting your point creates more work, more risk, or a political mess with a subject line like "Following up on our prior discussion."

Good sounds calm and useful. You say, "I see the goal. I think Option A creates a delivery risk because of X. I recommend Option B, which still gets us the same outcome by Friday." Your boss may agree, modify it, or say no. Fine. You made the decision better.

Bad sounds like a vibe wearing business casual. "I just don't think this is right." "Everyone is confused." "This feels off." Those may be true, but they do not help your boss decide. Feelings are inputs. They are not the deliverable.

For career switchers, this is especially weird. In your last field, disagreement may have been direct, technical, loud, or handled by one person with a clipboard and supreme power. Corporate disagreement has more ceremony. Yes, the ritual is slightly ridiculous. Do it anyway.

Use options, evidence, and shared goals

The safest disagreement has three parts:

Alignment: show you understand the goal.
Evidence: name the concern with something concrete.
Option: propose a path forward.

Disagreement is not about winning the room. It is about improving the decision. Most onboarding is vibes-based, so this structured pushback stands out.

I've seen this play out at Stylitics, where six months in, I had to flag a dashboard timeline that risked missing our quarterly demo. Being right was less useful than being interpretable. A correct point delivered like a grenade still creates a grenade problem.

Use this before you push back:

:::template{title="The boss disagreement prep card"} Goal we are trying to hit:
What outcome does your boss care about? Revenue, deadline, customer issue, exec request, risk reduction.

My concern:
The specific risk, gap, or trade-off I see. One sentence.

Evidence:
Data point, customer example, dependency, timeline, prior attempt, or constraint.

Option A, their path:
What works about it, plus the risk.

Option B, my recommendation:
What I suggest instead, and what it protects.

My ask:
Decision, permission to test, smaller scope, extra review, or 24 hours to validate. :::

Now turn it into words.

"I understand the goal is to get this in front of the client by Friday. My concern is that the current plan depends on legal review by Thursday, and we do not have that slot confirmed. I see two options. We can keep the full scope and risk slipping, or we can send the core section Friday and follow with the appendix next week. I recommend the second path because it protects the client deadline. Are you open to that?"

Notice what is not in there: "I disagree." You can say it if needed, but the stronger move is to make the disagreement visible through the logic.

Also notice the tiny gift you gave your boss: language they can repeat. Managers love repeatable sentences. Half of corporate life is people carrying sentences from one room to another like ants transporting crumbs across a sidewalk.

If your boss pushes back, do not escalate your volume or start citing "everyone." The invisible "everyone" is the weakest coworker in the building. Bring receipts.

Try:

"That makes sense. The piece I may be underweighting is speed. If speed matters more than completeness, I can support the current plan. I just want to name the risk so we are choosing it on purpose."

That sentence keeps the relationship intact because it gives your boss room to be the decider. You are not cornering them. You are helping them choose with their eyes open.

If they still say no

Sometimes your boss hears the evidence and still decides against you. This is where early-career people, especially ambitious ones, accidentally turn one disagreement into a reputation.

Do not sulk in the meeting. Do not run a shadow campaign in Slack. Do not start the very corporate sport of collecting side-eyes after the call.

Say:

"Understood. I'll proceed with that direction. For tracking, do you want me to note the risk in the project doc?"

That does two useful things. First, it shows you can commit after disagreeing. Second, it creates a clean record without turning into courtroom stenography.

If the decision is unethical, illegal, unsafe, or discriminatory, different rules apply. Document what happened and use the right internal channel. This post is about normal business disagreement, not being asked to falsify numbers by someone with a standing desk and dead eyes.

For everything else, your job is to be candid before the decision and committed after it. That does not make you passive. It makes you trustworthy.

The goal is not to become the person who agrees with everything. The goal is to become the person whose pushback makes the work less dumb. That person gets invited back into the room.

Gen Z at work: the real friction (and why I'm optimistic)

Mike Halpert — Thu, 21 Dec 2023 00:00:00 GMT

Every few years the workplace runs the same argument with new characters. "This generation is hard to manage." / "They don't have soft skills." / "They want too much feedback."

Some of those critiques land. Most are lazy.

The more useful question: what's the fastest way to help a new grad succeed without burning out their manager?

The thing nobody says out loud

Early in my career I thought "professional" meant: don't bother anyone, don't ask questions, don't look confused. So when I was confused, I stayed quiet and tried to brute-force it.

The result wasn't heroic. It was slow, misaligned work — the kind that makes a manager think, "why didn't you just tell me earlier?"

Early-career failure isn't usually about talent. It's about missing the unwritten rules. A lot of what gets tagged "Gen Z at work" is exactly that, and nothing more.

What managers are actually complaining about

When a manager says "Gen Z is difficult," they're usually describing predictable friction:

Long written messages that miss the point and have no ask
Awkward meeting dynamics: quiet in rooms, over-talking in chat, unclear follow-ups
High need for direction without corresponding ownership
Weak fundamentals on common tools — calendar etiquette, docs, spreadsheets, file hygiene

Translation: the person might be talented. They just don't know how to operate inside a workplace yet. That's a training gap, not a talent gap.

The gap is training, not talent

Most companies don't teach the baseline operating skills that make managers relax:

How to write a crisp update
How to run a 1:1 that produces a decision
How to ask for clarity without sounding lost
How to disagree without drama

So everyone improvises, managers get frustrated, new grads get anxious. The fix is boring. Make the unwritten rules written.

A simple First 90 Days OS that closes the gap

1. Default to written clarity after meetings. Send a short recap:

Recap:

Outcome: ___

Decisions: ___

Next steps: ___

Owners: ___

Deadlines: ___

Five minutes. Creates a paper trail. Makes you look organized. Most of your peers won't do this.

2. Learn the toolchain on purpose. If you're shaky on Excel, Slack norms, calendar etiquette, or file organization, pick one weak spot per week and close it. Managers don't expect perfection. They do expect momentum.

3. Ask for feedback in a way managers can answer.

Bad: "How am I doing?"
Better: "For this project, what would make my next update 'great' instead of 'good'?"

4. Build one relationship per week. Your career is output plus trust plus context. One short intro per week: a cross-functional partner, someone who supports your team (ops, IT, finance, HR), a strong performer one level up.

"I'm new and trying to understand how things work here. What do you wish you knew in your first 90 days?"

If you're the manager: three moves

Define what "good" looks like in artifacts. Instead of "be proactive," give examples. What does a good status update look like? A good meeting recap? A good first draft? New grads copy patterns. Make the patterns visible.

Set a default cadence. Weekly 1:1 (30 minutes), one written update mid-week, one end-of-week recap. The goal is fewer surprises, not more meetings.

Reward ownership, not vibes. Train juniors toward this structure: here's the situation, here are two options, here's my recommendation, here's what I need from you. That turns "help me" into "I'm thinking and moving."

Why I'm optimistic

Every one of these problems is solvable with better expectations, better communication, and better operating systems. Gen Z has real strengths: speed, comfort with change, willingness to question bad process. Add a professional OS and you're dangerous in the good way.

—

The "kids these days" arguments are mostly recycled. What changes generation to generation is the medium, not the underlying gap. The new grads who outperform their cohort aren't the ones who showed up most prepared by school. They're the ones who got the unwritten-rules download earliest. That download used to come from a competent older sibling or a hand-holding first manager. Now it lives in places like this. Different distribution channel. Same lesson.

If you want a clean ramp plan, start with the Week 1 checklist. For the weekly habit that keeps a manager relaxed, use the Status update template.

Reputation compounds before anyone notices your effort

Mike Halpert — Tue, 12 Dec 2023 00:00:00 GMT

Professional reputation is the quiet story your team tells itself about what to expect from you on the next task.

Your manager and teammates are trying to staff projects without constant surprises. They want to know who can handle a deadline without turning it into a daily status ping, or who spots a snag before it derails the whole sprint.

Good reputation shows up as calm handoffs in the room: someone says your name, and the group nods because they've seen you deliver without drama. Bad reputation looks like hesitation or side conversations: "Can we give this to someone else?" because your updates leave everyone guessing.

People do not see your effort. They see the artifacts your effort leaves behind: the Slack reply, the meeting note, the draft sent on time, the blocker raised before it becomes a small office fire with a calendar invite.

That is the annoying part of early career work. You can be grinding for six hours, reading docs, trying to understand why the internal tool looks like it was assembled during a thunderstorm, and the only thing your team sees is that you went quiet.

Professional reputation is not your self-description. It is what people believe they can expect from you next. That sounds dramatic. It is also how work gets assigned. Managers do not hand interns real scope because the intern has a strong personal brand. They hand over work because the intern has become predictable in useful ways.

I've been on the other side at Stylitics, watching interns turn into the go-to person after just a few consistent weeks. We all started somewhere, staring at tangled code or endless threads, wondering if anyone noticed we were even trying.

The five signals people actually use

The first signal is responsiveness.

This does not mean answering every message in 14 seconds like you live inside Slack and eat notifications for lunch. It means people do not wonder whether you saw the thing.

A good response can be tiny:

“Got it. I’m in another task now, but I’ll look by 3.”

That sentence does more than a heroic midnight essay. It tells the other person their request has landed, and it tells them when the next update comes. Corporate life contains enough mystery already. Nobody needs your availability to become a subplot.

The second signal is clarity.

New hires lose reputation when they make other people decode their work. A vague update creates more work for the reader, which is rude in the way office printers are rude: not personal, just deeply unhelpful.

Bad update:

“Still working on it. Some issues came up.”

Useful update:

“I finished the customer list. I’m blocked on the pricing file because I don’t have access. I requested access from Finance and expect to resume tomorrow morning.”

Same reality. Different reputation. Clarity is not about sounding polished. It is about removing fog.

The third signal is consistency.

Doing one impressive thing is nice. Being solid every Tuesday is better. Managers are running a mental risk spreadsheet, even if they would never admit that because then someone would make it an actual spreadsheet.

If you say you will send notes after the meeting, send them. If you say the draft will be ready Thursday, send it Thursday or update people Wednesday. If your working style changes every week, people start managing around you. That is bad. Being managed around is how you become the human equivalent of a hallway people avoid.

The fourth signal is follow-through.

Follow-through is where reputation compounds. The task is not done when you understood it. It is not done when you started it. It is not even done when you think you finished it. It is done when the person who needed the thing has the thing, in usable form, with no scavenger hunt required.

Yes, this can feel a bit silly, like we're all playing office make-believe with our little rituals. Send the recap anyway. The workplace already runs on ceremonies with names like “alignment sync,” so we are not above a little useful ceremony.

The fifth signal is judgment.

Judgment is knowing when to ask, when to decide, and when to flag risk. Interns think reputation comes from never needing help. Wrong. Silence is not independence. Silence is a fog machine with a badge.

Good judgment sounds like:

“I found two options. I think Option A is better because it is faster and matches the brief. Before I move forward, can you confirm?”

That is not helpless. That is safe.

At Stylitics, I pay attention to this faster than I pay attention to polish. A clean slide is great, but a person who flags risk early saves everyone from the 4:47 p.m. surprise meeting, which is the corporate version of finding a wet sock in your shoe.

Your manager is juggling thirteen Slack threads and six open tickets, so they notice the intern who cuts through the noise without adding to it.

The intern reputation checklist

Use this before you send an update, leave a meeting, or finish a task. It is small on purpose. If the system requires a 19-tab tracker to prove you are responsible, the system has started doing performance art.

:::template{title="Reputation signals checklist"} Task or project: What am I working on?

Owner: Who needs this from me?

Next visible update: When will they hear from me next?

Current status: Not started / In progress / Blocked / Done

If blocked, what exactly is blocking me? Access, decision, data, unclear scope, dependency

My recommendation: If there is a choice, what do I think we should do?

Final handoff: Where will the finished work live, and who needs the link? :::

The key line is next visible update. Not next internal thought. Not next burst of effort. Visible update.

If your manager knows when they will hear from you, they relax. If they do not, they check in. Then you feel micromanaged, they feel forced to micromanage, and everyone participates in the least fun kind of group project.

Reputation is built in that gap.

Small signals become your default

The unfair part is that people form opinions early. The useful part is that early opinions are still soft clay.

In week 7 of an internship, nobody expects you to understand the whole business. They do expect you to reply, write clearly, keep promises, close loops, and ask before walking into traffic with a spreadsheet.

Do that for a few weeks and people start using different language about you. Not “smart intern,” which is nice but vague.

They say:

“Give it to them. They’ll handle it.”

That sentence is the prize. It means your reputation has moved from potential to trust.

You will still make mistakes. Everyone does. The goal is not to look flawless. The goal is to become easy to predict in the ways that make other people less nervous.

That is how reputation compounds: not through noise, through receipts. And once those receipts stack up, the assignments get bigger without you saying a word.

How to ask about a raise: preparing your case

Mike Halpert — Tue, 05 Dec 2023 00:00:00 GMT

The raise conversation has a phase before the conversation. It's the preparation phase, and most people skip it entirely, then wonder why the ask didn't go the way they hoped.

Walking into a comp discussion without preparation is like walking into a job interview with no knowledge of the company. You might land it anyway, but you've made your own job harder than it needed to be.

What preparation actually produces

Preparation for a raise conversation does three things. It gives you a clear number to ask for, which prevents you from softening it in the moment. It gives you evidence to support the number, which transforms your ask from a personal plea into a business case. And it gives you confidence in the room, which changes how the ask lands, because managers read self-assurance as a signal of someone who has done their homework and is serious.

The unprepared version of this conversation sounds like: "I feel like I've grown a lot and I think I deserve more." The prepared version sounds like: "I've led three significant initiatives this year, taken on expanded scope, and I'm below market for my role. I'm targeting [specific number]." Both are asking for the same thing. One is dramatically easier to say yes to.

What your manager is trying to do

When you bring a raise conversation to your manager, they are simultaneously evaluating whether your request is justified, figuring out whether they have the budget to act on it, and estimating whether you're a retention risk if they don't. Good preparation addresses all three.

Evidence of outcomes and scope tells them the request is justified. Market data frames the conversation around external reality, not internal loyalty. A clear ask tells them what it would take to retain you. Give them all three and you've made their job of deciding significantly easier.

The four things to have ready before you ask

Your outcomes, in writing. Pull everything from the past 12 months: your 1:1 docs, your status updates, any written feedback or praise you've received, project results. From all of that, extract four to five outcomes that have concrete impact. Not tasks, outcomes. "Completed the onboarding audit" is a task. "Completed the onboarding audit, reducing ramp time for new hires from six weeks to four" is an outcome. The metric is what makes it portable into your manager's conversation with their manager.

Your scope gap. Write down what your job description said when you were hired and what you're actually doing now. If those two things don't match, the gap is your primary argument. Comp bands are built around role definitions. If your role has grown past the band, the band should grow too. Document the gap explicitly: "When I joined, this role did X. I now also do Y and Z."

Market data. Use Glassdoor, LinkedIn Salary, and Levels.fyi. Benchmark your exact title, years of experience, and city. Find the median and the top of the range. Know where you sit relative to both. This is public information you're entitled to have and use. Bringing it into the conversation reframes the ask from "I want more" to "the market has moved and I'm below it."

A specific number. This is the step most people never complete. They do the research, build the case, then walk in planning to say "something in the range of what's fair." That version doesn't work. A specific number closes the loop. "I'm targeting $X" is a request your manager can evaluate. "Something in the range of fair" is a request they have to interpret, and they'll interpret it conservatively.

The prep document

You don't need to show this to your manager. It's for you: to organize your thinking before the conversation and to stop you from retreating when they push back.

:::template{title="Raise case prep doc"} My key outcomes this year (pick 4–5)

[Outcome] → [Metric or impact]
[Outcome] → [Metric or impact]

My scope expansion (vs. original role)

Then: [what the job was]
Now: [what the job is, with the additions named explicitly]

Market data

Comparable role, my city: [range]
My current base: [number]
Gap: [amount below market midpoint]

My target

[Specific number I'm asking for]

What I'll say if they defer

"When would be the right window, and what would strengthen the case?" :::

Fill this in before you request the meeting. Review it the morning of the conversation. Don't bring the doc to the meeting unless you're specifically asked for it.

A note on timing

Preparation is not an excuse to delay indefinitely. Pick a window, build the file in the two weeks before it, and have the conversation. The trap is using "I need to prepare better" as a reason to never actually ask.

The case doesn't have to be airtight. It has to be good enough that your manager can carry it forward. Good preparation makes it good enough, and that threshold is lower than most people imagine.

The two-list system for visible tradeoffs

Mike Halpert — Tue, 28 Nov 2023 00:00:00 GMT

Your to-do list is hiding half the story.

It shows what you plan to work on. That is responsible. But it leaves out what you are not working on, and that gap is where confusion starts. A manager thinks you handled the partner analysis. A teammate assumes you updated the launch doc. You find out everyone pictured a different outcome.

The two-list system fixes that. It is one list for what you are doing, and one for what you are not. Prioritization means making those tradeoffs visible, not just listing tasks.

Clarity comes from showing the choices, not just the yeses.

What the two-list system is

The two-list system is a way to track and share your priorities by splitting them into two parts: active work and paused work. You list three to five items you are tackling, with clear outcomes, and the same number you are setting aside, with reasons why.

Your manager or teammates use this to align on what matters most. They want progress without surprises, so they can spot misalignments early and adjust.

Good looks like agreement in the room: everyone nods at the lists, knows the tradeoffs, and moves forward without unspoken expectations. Bad looks like crossed wires: someone brings up a "forgotten" task in a meeting, leading to finger-pointing or rushed fixes.

Why the second list matters

New grads learn to say yes, be helpful, take notes, volunteer for that weird spreadsheet from four reorganizations ago. That drive is solid. It turns risky when every yes hides a no.

At work, yeses create silent nos unless you name them. People judge against their assumptions, not your reality. Those assumptions build into disappointment.

The not-doing list stops that. It signals to your manager: I see the tradeoff, and I am not ignoring this. To teammates: This is not lost. To you: You chose this, not forgot.

I picked up a version of this at Stylitics, six months in, when dashboard sprints piled up and my calendar turned into a Tetris fail. We all crash into that point where faking the juggle drops balls in standups. The best part is seeing someone glance at the not-doing list and say, actually, bump that one up. That is the system doing its job.

Yes, listing what you are not doing feels a bit silly, like parading your limits. Do it. The other option is everyone learning those limits at crunch time, a classic office move.

Most onboarding is vibes-based, so this setup cuts through that fog.

The two-list checklist

Pull this out when work outpaces time, priorities blur, or your manager calls everything important, code for they have not crunched the numbers.

:::template{title="The two-list prioritization checklist"} Time period:
This week / next two weeks / this sprint

What I’m doing:

Item 1, with the outcome or deliverable
Item 2, with the outcome or deliverable
Item 3, with the outcome or deliverable

What I’m not doing right now:

Item 1, and why it is paused
Item 2, and why it is paused
Item 3, and why it is paused

Tradeoff I’m making:
I am choosing X over Y because Z.

What would change this:
If A becomes more important than B, I will swap it in and move C out.

Decision needed, if any:
Please confirm whether this priority order is right. :::

Make doing items specific, so the output is clear.

Bad: Work on onboarding. Help with launch. Support analytics.

Better: Draft the onboarding FAQ for the support team by Thursday. Update the launch tracker with final owners before Friday review. Pull conversion data for the pricing test and share a one-page readout.

Not-doing items stay factual, not defensive.

Bad: Can not get to this. Not my fault. Waiting on people.

Better: Not updating the legacy deck this week, focusing on the customer launch doc. Not cleaning the full dataset yet, only checking fields for Monday readout. Not scheduling partner follow-ups until the priority account list is confirmed.

The better ones show choices. The bad ones sound like excuses.

How to send it without making it weird

Skip the essay on capacity constraints. That subject line sparks dread.

Share in your team's usual spot: Slack, email, project doc, 1:1 notes. Keep it plain. Plain works.

Here is a starter:

Quick priority check for this week. I am planning to focus on A, B, and C. I am not planning to work on D or E unless you want me to swap something out. Does that order match what you expect?

This owns the priorities, highlights the tradeoff, and invites easy input.

Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they are late for. This respects that without piling on.

Run the two-list system at three points.

At the start of the week

Share Monday morning or in your first 1:1. Stick to three doing items. Nine means you have a wish list, not priorities.

When new work appears

Do not just nod and stress. Respond:

Happy to take that on. To make room, should I pause X or Y?

Calm, direct. You surface the choice.

Before something slips

By Wednesday, if Friday looks shaky, refresh the lists. Visible delays beat surprises.

What happens next

The two-list system will not shrink your load. If it did, someone would bottle it.

It kills the quiet letdowns, shifts from assumptions to agreements. That clears the air.

Your to-do list has its place. Pair it with this, and those hidden tradeoffs stop haunting the edges.

Word count: 892

Introducing Cubicle to Corner Office

Mike Halpert — Mon, 20 Nov 2023 00:00:00 GMT

Most people don't struggle in their first job because they're not smart enough. They struggle because the work comes with invisible rules.

How to communicate progress without sounding unsure
How to ask for help without dumping the problem on your manager
How to handle meetings, priorities, and the subtle politics
How decisions actually get made

If you're a new grad, it feels like everyone else got a handbook. If you're a manager, it feels like you're re-teaching basic workplace skills on repeat.

Two kinds of work

Every office job has two kinds of work:

The obvious work — the spreadsheet, the deck, the ticket.
The invisible work — alignment, updates, follow-through, not surprising people.

School trains you for the first. Most first jobs assume you already know the second. That gap is where early-career anxiety comes from, and it's why managers end up micromanaging even when they don't want to.

What this site is

The site, and the book behind it, are meant to be the handbook I wish I had.

Not "be confident." More like: here's the exact template, here's the script, here's the system. Copy-paste your way to competence while you're still nervous.

Why I wrote it

I started my career about twenty years ago in the mailroom at William Morris. I had done all the "school preparation" stuff. What I wasn't prepared for were the skills nobody grades you on.

My first day at a big tech company, my parents had told me to dress the part. I bought a new suit. I stepped off the elevator and everyone was in t-shirts and jeans. I spent the day feeling like a fish out of water, and the lesson stuck: making a good impression on Day 1 is less about the suit and more about reading the room.

Over time — especially after business school and a career pivot — I realized I was spending a lot of my life coaching new hires through the same three problems:

They were doing work, but not showing progress
They were asking questions, but not asking them well
They were working hard, but not aligned

So I wrote Cubicle to Corner Office: The Ultimate Survival Guide to Your First Job. Not a motivational "believe in yourself" book. A practical guide for the parts of work that are real, and rarely explained.

What the book is actually about

Building tangible skills beyond your degree. Your degree gets you in the door. Your operating system keeps you employed and gets you promoted. That looks like setting goals you can hit, protecting focus time, communicating progress without rambling, flagging risks early so your manager isn't surprised.

Building meaningful relationships without being fake. Nobody ships alone. Early in your career, relationships speed up answers, reduce rework, and create advocates when you're not in the room.

Demonstrating motivation the right way. Motivation isn't "working late." The kind managers trust looks like: learning fast, asking good questions, delivering what was asked, making your manager's life easier. Do those consistently and you become low-drama and high-trust, which is the cheat code.

What you'll actually get

I tried to make this feel like having a slightly older coworker whispering, "do this, not that."

A clean status update format that works in email or Slack
A 1:1 agenda so your meetings produce decisions, not rambling
"How to ask questions" phrasing that gets you answers without sounding helpless
Meeting follow-up templates so decisions don't evaporate
How to manage up without being political or fake
How to build relationships without the networking cringe

If you're early career: you're not behind. You're just missing the operating manual.

If you're a manager: the goal isn't to "fix the kids." It's to create repeatable systems — templates, norms, examples — so new hires ramp without constant re-teaching.

—

The version of me at 22 would have read this and rolled his eyes. "I went to a good school, I'm sharp, I'll figure it out." He spent eighteen months underperforming his potential because the skills nobody graded him on were the ones that mattered most. The handbook didn't exist then. It does now. Use it. The next twenty years are long.

If you want the backbone of the system, start here: Start here.

Asking your boss for a raise: scripts and strategies

Mike Halpert — Tue, 14 Nov 2023 00:00:00 GMT

The raise conversation is the one career move almost everyone needs to make and almost no one practices. You know it's coming. You know what you want to say. You still freeze when you sit down across from your manager.

The freeze isn't lack of confidence. It's lack of a clear script. Here's the one that works, and the strategies behind each line.

Why the script matters

Left to our own devices, most of us default to the version that undersells us: we apologize for the ask, we hedge the number, we ask for permission to want what we want. "I don't know if this is the right time, but I was wondering if maybe we could talk about, like, potentially revisiting my salary?"

That script signals anxiety about whether you deserve the thing you're asking for. Anxiety is contagious. Your manager picks it up and starts wondering whether you do deserve it.

The alternative isn't arrogance. It's clarity. Here are the scripts that land that quality.

The request to have the meeting

Send this as a message or raise it at the end of a 1:1:

"I'd like to schedule some time to talk about my compensation. Can we find 20 minutes this week or next?"

Not: "I've been thinking about whether I might be able to, at some point, bring up the topic of salary."

Specific, confident, low-friction. The meeting is just a meeting. Nothing bad is happening yet.

The opening of the actual conversation

Start with the outcomes, not the ask:

"Over the last [12 months / since we last talked about this], I've [specific win #1] and [specific win #2]. I've also expanded my scope to include [X], which wasn't part of the original role."

You're not bragging. You're providing the material your manager needs to justify the ask to whoever they report to.

The market context line

After the outcomes, one sentence of market data:

"I looked at comparable roles in [city], and the range for this level is [range]. I'm currently below the midpoint."

This reframes the conversation from "I want more" to "the market has moved and we should align." You're not making a personal complaint. You're reporting external data.

The ask itself

One sentence, no hedging, specific number:

"I'm targeting [specific number or range]. What would it take to get there?"

That last question, "what would it take to get there?", is the move most people miss. It's not passive ("I hope you'll consider this"). It's active. You're inviting your manager into the problem-solving and signaling that you understand it may not be a straight yes.

The response scripts

If they say yes or "I'll look into it":

"Thank you. What's the timeline, and how should I expect to hear back?"

Don't let it go vague. A specific date keeps the conversation alive.

If they say the timing is wrong:

"I understand. When would be the right window, and what would I need to demonstrate to make this a strong yes?"

You're asking for criteria and a timeline. Both are reasonable. If they can't give you either, that's information about how seriously to take the deferral.

If they say the budget isn't there:

"Okay. If base isn't possible right now, are there other levers we could explore: additional PTO, an earlier review date, a clear path to when the budget unlocks?"

This isn't a gotcha. It's genuine. Sometimes the budget genuinely isn't there. Finding adjacent levers shows you're solving for the relationship, not just the number.

The strategy behind the scripts

Every script above follows the same logic: state facts, make a clear ask, ask a clarifying question. No emotion, no apologizing, no hedging the number.

The most common place people derail: after stating the number, they immediately start softening it. "I was thinking around $X, obviously I'm flexible on that, I don't want to be unreasonable, I just thought..." Stop. Say the number. Let silence do the rest of the work. Silence after a clear ask reads as confidence. Filling it reads as retreat.

What to do after the conversation

Send a three-line follow-up that same day or the next morning:

"Wanted to close the loop from our conversation earlier. My target is [X]. I'll plan to follow up on [date] if I haven't heard back. Thanks for making time to discuss this."

That email creates a record, confirms the number, and sets an expectation for follow-up. It also removes the "I forgot we talked about this" from the possible excuses.

The raise conversation isn't a test of whether you're liked. It's a test of whether you can advocate for yourself clearly. Every time you do it, it gets a little less hard, and the outcomes improve.

How to ask for a raise: a step-by-step guide

Mike Halpert — Tue, 07 Nov 2023 00:00:00 GMT

Most people avoid asking for a raise by telling themselves the timing isn't right, or they haven't been there long enough, or they should wait until the next review cycle. This is usually not analysis. It is procrastination with better-sounding reasons.

If you're reading this, you probably already know you should have this conversation. The step-by-step below is how to have it in a way that gives you the best shot at a yes.

What a raise conversation actually does

A raise request is not a personal negotiation between you and your manager. It is a business case that your manager has to be able to carry into a compensation committee, a budget conversation, or a discussion with their manager. Your job is to make that case easy to carry.

The version of this that fails: emotion-forward, no data, no specific number. "I feel like I've grown a lot and I deserve more." Your manager may agree with all of that and still have nothing to take upstairs.

The version that works: outcome-forward, market-contextualized, specific number. "Here's what I've delivered, here's the market for this role, here's the number I'm targeting."

What your manager is trying to do in this conversation

Your manager wants to pay you fairly. They also have limited budget authority and have to justify compensation decisions. When you bring them a vague request, they can't justify it. When you bring them data and a specific number, they have something to work with.

They're also listening for whether you're going to be a retention risk. "I deserve more" is a vague signal. "I'm targeting $X based on market data and scope expansion" is a specific signal. The second one tells them what it would take to retain you and lets them evaluate whether that's achievable.

Step 1: Build your file before you say a word

Block two hours, a week or two before you plan to have the conversation. Produce three documents.

Wins summary. Pull your wins log, your 1:1 recaps, and any written praise or feedback from the past year. Distill to four or five specific outcomes with metrics. "Led the Q2 partner roadshow" is a task. "Led the Q2 partner roadshow, which generated three signed agreements totaling [scope] in new partnerships" is an outcome.

Scope gap document. Write down what your job description said when you started versus what you're actually doing now. If you've taken on more, document the gap explicitly. Expanded scope is the structural argument for a raise: the job grew and the pay hasn't caught up.

Market data. Use Glassdoor, LinkedIn Salary, Levels.fyi, or comparable offer data you've seen in the wild. Find the market range for your exact role, level, and city. Know where you sit in that range. Know what a reasonable target is within it.

From those three documents, you'll have your case.

Step 2: Choose the moment

The best window: two to three weeks before a performance review cycle, when compensation decisions are already in motion and your manager can advocate before things are locked. The second-best window: right after a visible win or a scope expansion that's formally acknowledged.

The worst windows: during a reorg, after a rough quarter, when your manager is visibly overwhelmed, or in the last two weeks of a fiscal year when budgets are frozen.

Step 3: Ask to talk about it directly

Don't ambush the conversation in the middle of a 1:1. Request it:

"I'd like to carve out some time to talk about my compensation and what the trajectory looks like here. Can we do that this week or next?"

That framing, "trajectory" rather than just "raise", signals that you're thinking about long-term growth, not just an immediate ask. Most managers respond well to it.

Step 4: Have the actual conversation

In the meeting:

"I wanted to talk about my compensation. Over the last [time period], I've [two or three specific wins]. I've also expanded the scope of my role to include [X], which wasn't part of the original job. I did some market research, and comparable roles in [city] are ranging from [range]. I'm targeting [specific number]. I'd love to know what the path looks like and what I need to do to get there."

Then stop. Don't apologize for asking. Don't soften the number. Let them respond.

If they say yes outright: get the specifics (effective date, timeline) in writing.

If they say "not now": ask "when would be the right time, and what would make this a yes?" Get a date and criteria, in writing if possible.

If they say "let me think about it": give them a deadline. "Would it be okay if I followed up in two weeks?"

Step 5: The follow-through

If the raise happens, send a short email thanking them and confirming the details. If the raise doesn't happen on the timeline you were given, follow up directly at the agreed date. Raising it once and never following up is the most common reason compensation conversations quietly die.

Asking for a raise is not confrontational. It is the most basic form of career management, and the professionals who do it regularly tend to earn more over time than the ones who wait to be noticed. The conversation is the job.

The definition of done: how to avoid rework in your first role

Mike Halpert — Tue, 31 Oct 2023 00:00:00 GMT

Rework is not a productivity problem. It is a clarity problem.

A definition of done is a shared checklist that pins down exactly what counts as finished work: the format, the audience, the quality level, and the deadline. It turns a manager's offhand request into something concrete you both agree on before you lift a finger.

Your manager is trying to solve a specific business snag, like spotting why customers are dropping off or prepping a quick update for the exec team. They fire off instructions in the middle of their own chaos, figuring you'll fill in the blanks the same way they would.

When this goes right in the room, you and your manager sync up fast: you repeat back the key details, they nod or tweak one thing, and you both walk away knowing the output will hit the mark without back-and-forth surprises. The work flows, trust builds, and nobody's scrambling to fix a mismatch later.

When it goes wrong, confusion brews quietly at first: you deliver something polished and thorough, but it lands like a thud because it misses the point, leading to that deflating feedback loop where you redo half of it and they wonder why directions weren't followed.

The gap between "do this" and "done"

Your manager is not trying to trick you into doing extra work. They are moving at a speed where "get me a summary of the Q3 churn" is a complete thought in their head. They assume you know that "summary" means a specific spreadsheet tab, not a formal report.

When this works, the interaction sounds like a confirmation: "So you need the churn data broken down by region in a CSV, and you're using it for the Tuesday board meeting. I'll have it to you by Monday noon. Correct?"

When it fails, it sounds like a surprise: "Wait, why is this a PowerPoint? I just needed the raw numbers."

Your manager's brain is juggling thirteen Slack threads and a stack of Jira tickets, so their ask comes out shorthand. Most onboarding is vibes-based, leaving you to guess the rest.

The calibration ritual

I learned this the hard way during my Google internship six months in. I spent an entire weekend polishing a technical doc that I thought needed to be a masterpiece. When I turned it in ten minutes before standup, the feedback was that it was too long and the main point was buried. I had optimized for "impressive" instead of "useful."

I've been there myself at Stylitics, where we all chase that perfect dashboard, but it just leads to late nights nobody asked for. The fix is to stop treating your manager's requests as orders and start treating them as hypotheses. Your job is to validate the hypothesis before you commit the hours.

Yes, asking for this level of detail can feel a bit silly, like you're overthinking a simple task. Do it anyway. Five minutes of awkward questioning is a cheap price to pay for avoiding a Sunday spent deleting slides.

Use this framework the moment a project lands on your desk. Don't start the work until these fields are filled. Punching up your process like this turns vague asks into reliable wins, every time.

:::template{title="Definition of Done Checklist"} The Outcome: What is the specific problem this solves? (e.g., "The VP needs to decide if we kill Project X")

The Format: What is the actual deliverable? (e.g., Slack message, 1-page memo, Excel tab, Figma link)

The Audience: Who is reading this? (e.g., My manager, a peer in Engineering, an external client)

The Quality Bar: Is this a 'rough sketch' to check logic, or a 'client-ready' final version?

The Success Metric: What one thing must be true for this to be considered a win? (e.g., "The data is accurate to the cent")

The Deadline: When is it actually due, and when do you want to see the first draft? :::

The "low-fidelity" safety net

If the project is large or the request is particularly blurry, don't go straight to the final product. Use a low-fidelity version as a probe.

If you're tasked with a big analysis, send a "skeleton" first. This is a bulleted list of the headers you plan to use or a mockup of one chart.

"I'm starting the churn analysis. Before I dive into the data, here is the outline of the three questions I'm answering. Does this cover what you need, or am I missing a key angle?"

This is the corporate equivalent of a sketch. It allows your manager to course-correct you when you've spent twenty minutes on the project, rather than twenty hours.

Corporate life is essentially a series of people guessing what other people want. The person who stops guessing and starts documenting the requirements is the one who gets promoted.

I still occasionally over-engineer a doc at Stylitics because the "perfectionist" instinct is hard to kill. But I've found that a quick "is this a birdhouse or a cathedral?" check saves my weekends.

SMART goal setting (the version that actually works at work)

Mike Halpert — Tue, 24 Oct 2023 00:00:00 GMT

Most new grads don't have a motivation problem. They have a translation problem.

They show up with goals like "I want to do well." / "I want to get promoted." / "I want to learn a lot."

All fine. None of them change what you do on Tuesday.

The problem SMART solves

Early in your career, you'll get vague direction: "Take ownership." / "Be proactive." / "Drive impact."

SMART translates that into a specific output, a measurable signal of progress, a realistic scope for your level, and a deadline. That's what your manager can actually support.

The acronym (Specific, Measurable, Achievable, Relevant, Time-bound) is fine but dated. The version that matters is the question you ask of any goal: "can I tell on Friday whether this happened?" If the answer is yes, the goal is real. If the answer is no, you wrote a vibe.

The five filters, with the workplace twist

Specific — what deliverable exists?

Bad: "Get better at my job."

Better: "Ship my first small win in production." / "Own the weekly status update for Project X." / "Publish a one-page how-we-do-X doc for the team."

Point at something real.

Measurable — how do we know it happened?

Doesn't always mean a perfect KPI. Simple counts work: "Send two stakeholder updates per week." / "Close five onboarding tickets by Friday." / "Run three user interviews and summarize themes."

If you can't measure it, you can't manage it.

Achievable — hard but plausible.

Stretch is fine. Fantasy isn't. Ask: do I control the inputs? Do I have the access? Is the scope realistic for my skill level? If the answer is "maybe," shrink the goal. A smaller goal that ships beats a bigger one that stays hypothetical.

Relevant — does my manager care?

If your goal doesn't help the team win, it's extra credit at best. The most common goal-setting trap is choosing things that are good for you without checking whether they're useful to the team. They're rarely the same goal.

Time-bound — when's the check?

Deadlines create focus. They also create decision points. A goal without a date is "someday," and someday doesn't show up on your calendar.

The goal ladder

A good work goal connects upward:

Company goal — what the business cares about
Team goal — what your group is responsible for
Your goal — what you control

If you can't explain how your goal supports the team goal, it's probably not the right goal.

The copy/paste template

"By [date], I will [deliverable], measured by [metric or signal], so that [team outcome]. Risks: [1–2 risks]. Ask: [decision or help needed]."

Example:

"By March 15, I will ship the onboarding email flow to 10% of users, measured by successful event tracking and QA sign-off, so that we reduce early drop-off. Risk: legal review timing. Ask: confirm whether welcome vs. tips email is higher priority for v1."

That's a manager-friendly goal.

A first-90-days goal stack

Week 2 — remove confusion.

"By end of Week 2, document the top ten recurring questions for my role (with links and owners) and share with my manager."

Day 30 — ship a visible small win.

"By Day 30, ship one visible deliverable that reduces team friction — a template, a fix, an analysis — and share the before/after with the team."

Day 60 — own something end-to-end.

"By Day 60, own one recurring responsibility end-to-end with minimal oversight."

Ownership is the real promotion skill.

Day 90 — get the bar in writing.

"By Day 90, confirm in writing what 'great' looks like in my role — metrics, behaviors, examples — with my manager."

Prevents guessing.

Three common mistakes

Goals that are just vibes. "Be more strategic." Fix: pick an artifact. "Write a one-page strategy memo."

Goals you don't control. "Increase revenue by 20%." Fix: set an input you control. "Ship X experiment by Y date." / "Contact 15 customers and summarize insights."

Goals that aren't aligned. Fix: run a two-minute alignment check.

The two-minute alignment script

"I drafted two or three goals for my first 90 days so I'm aiming at the right target. Can I send them for a quick thumbs-up? I'd rather adjust now than miss the bar later."

One move. Separates you from most people.

—

The goal-setting frameworks are mostly the same once you've seen a few. What separates the people who actually grow from the ones who don't isn't the framework — it's the discipline of telling someone else about your goal in writing, then giving them four chances to correct it before you've spent a quarter going the wrong direction. The framework is the easy part. The asking is the hard part.

For a lightweight weekly cadence that keeps goals real, use the Status update template.

The one-line ask that gets answers before lunch

Mike Halpert — Tue, 17 Oct 2023 00:00:00 GMT

A one-line ask is a short message that puts the exact decision you need right up front, followed by when you need it, so your colleague can respond without wading through backstory.

Your colleague is trying to manage their own workload, scanning messages for anything that demands immediate attention while handling meetings, emails, and their tasks.

In a good exchange, the ask gets a clear yes or no within hours, moving the work forward without back-and-forth.

In a bad one, the message gets skimmed and set aside, leading to delays or a noncommittal reply that leaves you chasing.

You need a yes or no on whether to cut feature X from the sprint. Deadline is EOD tomorrow. But your Slack message buries the decision in three paragraphs of context first.

Three days later, crickets. Or worse, a polite "Sounds good, keep me posted" that solves nothing.

Colleagues aren't ignoring you because they're rude. They're triaging a hundred pings a day. The corporate inbox is a slot machine where context-heavy asks lose every spin. Put the decision and deadline in line one. Watch response rates triple.

Why your asks vanish into the void

Workplace requests flop the same way. You explain the backstory: the project history, why this matters, three options you considered. The actual question hides at the bottom, if it exists at all.

Your recipient scans the preview. Sees a wall of text. Thinks "I'll read this later." Later never comes.

I've been there, staring at my own rambling drafts during my first six months at Stylitics, wondering why no one hit reply. Good asks land like this: line one names the decision. Line two gives the deadline. The rest is supporting facts, if needed. Total length: five lines max. Response time drops from days to hours.

Bad asks sound like this:

"Hey, quick question on the dashboard redesign. We've been iterating on the filters, and I remember in the last sprint we talked about user feedback from the beta. Option A keeps the current dropdown but adds search. Option B replaces it with tags, which might scale better long-term. The PM wants a call on this by Friday. Thoughts?"

That's not a question. That's a TED talk in Slack.

The other party isn't evaluating your thought process. They're deciding if they need to own this now. New grads overlook this because school rewarded thorough essays. Work rewards speed.

At Stylitics, I once watched a thread balloon to 47 replies because the initial ask was "context dump + vague 'what do you think?'" Flip it to "Approve cutting filters? Need call by noon or default to A." Done in two messages. We all learned that lesson the hard way, after wasting half a sprint on unclear priorities.

The one-line ask checklist

Nail this every time. Run your draft through these five checks before hitting send. It's mechanical, but it works.

:::template{title="One-line ask checklist"} Decision (line 1): Name the yes/no/binary choice. Approve A or B? Cut X?

Deadline (line 1 or 2): Exact time it needs deciding. By EOD? By 3pm?

Default path (line 2): What happens without reply. Default to A? Escalate?

Your rec (line 3): One-sentence why. A is faster by 2 days.

Next step (line 4): What reply triggers. Reply Y to proceed. :::

Yes, this feels like scripting a robot, and I rolled my eyes the first dozen times I followed it to the letter. Corporate communication rewards it anyway. The checklist turns fuzzy "help me" into a transaction your recipient can close in ten seconds.

Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for. That's why this format cuts through: it respects their chaos without adding to it.

Three scripts that plug straight in:

Quick approval:

"Approve shipping without mobile tests? Need go/no-go by 2pm or skip. Rec: approve, saves 1 day. Reply +1."

Scope decision:

"Cut user tags from MVP? EOD call needed or default to no. Tags add 3 days risk. Reply Y to cut."

Resource ask:

"Get me 2 hours with eng lead this week? By noon tomorrow or I spec solo. Rec: yes, aligns requirements faster. Free Thursday?"

Punch up the reply rate by 80% in a month. Track it if you doubt. I did, logging responses over two weeks, and saw my unanswered asks drop from twelve to three.

When to break the format (rarely)

Ninety percent of asks fit the checklist. The exceptions: legal reviews, multi-stakeholder signoffs, or anything touching budget. Those get a shared doc with the one-liner up top.

Don't overcomplicate. The format shines on daily decisions: tool choices, priority swaps, light feedback. Where juniors spin wheels asking nothing. Picture the intern who spent ten minutes before standup drafting a novel-length ping about font sizes, only to get no input and pick wrong.

One deadpan truth: the Slack channel named after your project exists to log decisions, not host novella-length explanations.

That first buried ask? Still waiting on a reply three years later in some thread. Those don't haunt you if you never send them. Over time, you'll spot how these quick closes build trust, turning one-off pings into a rhythm where colleagues start anticipating your needs.

wordcount: 884

The expectation gap is where new hires get ambushed

Mike Halpert — Tue, 10 Oct 2023 00:00:00 GMT

New hires do not get in trouble because they are secretly bad at working.

They get in trouble because two people agreed to the same sentence and imagined two completely different movies.

Your manager says, "Can you pull together an overview for Friday?" You hear a thoughtful five-page analysis with context, options, and a clean recommendation. Your manager meant twelve bullets in a doc so they can survive a 3:00 p.m. meeting with Finance, the department where optimism goes to get notarized.

That space between what they meant and what you built is the expectation gap.

The gap is not about effort

The expectation gap is the difference between the work your manager thinks they asked for and the work you think you are supposed to deliver. It shows up in scope, timing, format, audience, polish, and who needs to approve the thing before it counts as done.

Your manager is trying to reduce uncertainty. They need to know whether the work will land, whether they need to warn someone, whether the timeline is real, and whether you understand the assignment without needing a live translation booth. Their brain is not grading your worth as a human. It is doing a risk scan while also being pinged by three Slack threads and a calendar invite titled "Quick sync," the workplace equivalent of a suspicious van.

A strong version of this interaction sounds boring in the best way. You repeat the ask back, name the deliverable, confirm the audience, and agree on the next checkpoint. Something like: "I'll send a one-page summary by Thursday noon for you to review before the Friday leadership meeting. I'll include the three options, my recommendation, and the risks. I'll send an outline Tuesday so we can catch any misses early."

A weak version sounds polite and doomed: "Sounds good, I'll take a look." Then you disappear for four days and return with a beautiful artifact from the wrong planet. Everyone is nice about it, which is how you know it's bad. Corporate disappointment arrives wearing a fleece vest and saying, "This is helpful context."

If you are a career switcher, this trap is extra sneaky. In your last field, "done" may have been visible: the customer left happy, the shift ended, the ticket closed, the classroom survived. In office work, "done" is a negotiated fiction until someone with budget authority stops asking questions.

The five-minute checkpoint

You do not need a massive process. Please do not create a massive process. The company already has enough ceremonial spreadsheet gardening.

I've learned this the hard way at Stylitics, where we all started out assuming one quick chat covered everything, only to find out it left half the room guessing.

You need one small checkpoint before you start, and one before you finish. Yes, asking this directly can feel a bit silly, like reciting the alphabet to prove you know it. Ask anyway. Ten minutes of mild awkwardness beats two weeks of polishing the wrong deliverable.

Use this when you get a new assignment, especially in your first 90 days or after switching teams.

:::template{title="Expectation gap closer"} Assignment: What I think I’m doing

Business reason: Why this matters, who needs it, what decision it supports

Audience: Who will read, use, approve, or argue with this

Deliverable format: Doc, deck, spreadsheet, email, ticket, prototype, talking points

Level of polish: Rough direction, solid draft, final-ready

Deadline: Exact day and time, plus any hidden meeting before it

Definition of “good”: The standard this needs to hit

Known risks: Where I might get stuck or make a bad assumption

Checkpoint: When I’ll show an outline, draft, or sample before going too far :::

You can send it as a short note, not a manifesto:

"To make sure I’m aimed at the right target, here’s how I’m understanding the ask. Can you confirm or correct this before I get too far?"

That sentence saves careers. Not in a dramatic movie-trailer way. In a "your manager stops quietly worrying about you" way.

At Stylitics, I still do versions of this because seniority does not delete ambiguity. It just gives ambiguity better shoes and access to bigger meetings.

The key is the checkpoint. New hires want to prove independence, so they wait until the work is finished to show it. That is backward. Early drafts are cheaper than finished mistakes.

Show a skeleton after 20 percent of the work:

"I have the structure and first pass ready. Before I fill this out, does this match what you had in mind?"

Notice what that does. It gives your manager a clean place to redirect you without turning the whole thing into a postmortem with snacks.

Where the trap hides

The expectation gap loves vague words. Watch for these little corporate fog machines:

"Quick." Does that mean ten minutes, one hour, or "I forgot this is hard"?

"High-level." Is this for a VP who needs the answer, or for a peer who needs the reasoning?

"Clean this up." Are you fixing typos, rewriting the argument, or making a deck look less like it was assembled during turbulence?

"Own this." Do you make the decision, collect input, chase people, present the result, or all of the above while smiling like the org chart is a helpful document?

When you hear fog, translate it into choices. Your manager's in thirteen Slack threads, six open Jira tickets, and a meeting they're late for, so they won't mind a nudge toward clarity.

"When you say high-level, do you want the recommendation and two reasons, or the supporting detail as well?"

"For Friday, is a rough draft enough, or does this need to be ready to send?"

"Who is the decider on this, and who just needs to be informed?"

Expectation management is not about being needy. It is about making the invisible contract visible.

That is the sharp turn: good employees do not read minds. They make assumptions testable.

If your manager gets annoyed by clarification, keep it short and practical. Some managers were trained in the ancient school of "I'll know it when I see it," which is convenient for them and basically workplace archery in the dark for you. Your job is not to fix their management style. Your job is to reduce the number of surprise arrows.

The expectation gap never announces itself. It just waits quietly between "sounds good" and "not quite what I meant." Close it early, before the suspicious van pulls up with a calendar invite.

Office etiquette: the quiet signal that shapes your early career

Mike Halpert — Tue, 03 Oct 2023 00:00:00 GMT

This isn't a post about being stuffy. It's about signal.

In your first 90 days, people don't have a long track record of your work. So they unconsciously judge the easy-to-observe stuff: are you on time, do you communicate clearly, do you respect other people's time, do you understand the culture?

That bundle is what most people mean by "office etiquette."

The moment it matters most

Early in your career you don't have a long resume of wins inside this company yet. Small behaviors get overweighted.

Something as simple as consistently showing up three to five minutes late can turn into a label: "They're not reliable." / "They don't take this seriously." / "A little chaotic."

Meanwhile someone else at the same skill level looks "more senior" purely because they're steady. On time. Prepared. Clear in writing. Low-drama.

Etiquette is reducing friction so people can trust you.

A personal example

On my first day at a big tech company, I wore a suit. My parents had told me that's what you wear to an office job, and I believed them. I stepped off the elevator to a floor full of t-shirts and jeans. I felt like a fish out of water all day.

The lesson wasn't about clothes. It was about reading the room. Office etiquette is mostly that — noticing the environment and matching it without losing yourself.

What etiquette actually includes

Think of it as a professional operating system:

Respect and courtesy. Don't be a chaos agent.
Punctuality. Being late is a tax you charge other people.
Appropriate appearance. Dress for the room you're in.
Clear communication. Summarize, confirm, close loops.
Mindful tech use. Don't live-scroll in meetings.
Confidentiality. Trust is part of the job.
Team behavior. Share context, offer help, be reliable.
Meeting manners. Engaged, prepared, not performatively busy.

None of this requires you to change your personality. It requires you to notice the environment.

The five rules

1. Copy the highest-status "normal" behavior. Look for the team's competent operators. Watch how they dress, how quickly they respond, how they run meetings, how they write updates, what they consider "too casual." Match the baseline.

2. Make your reliability obvious. Reliability is 80% of etiquette. Three habits do most of the work:

Show up on time (or proactively message if you won't)
Send clean follow-ups after meetings
Close loops — "done," "shipped," "sent"

If you're doing great work but people can't see it, you'll be underestimated.

3. When in doubt, choose the option that creates less friction. Be on time. Be brief. Be polite. Follow up in writing. Don't create surprises.

4. Learn the meeting culture of your team. Some teams want cameras on. Some don't. Some debate in the room. Some debate in the doc. Ask once, early:

"Any meeting norms I should know? Cameras, prep expectations, and how we capture decisions?"

5. Be careful with humor and venting early. Humor is fine. But early on, people don't know your intent yet. Avoid sarcasm in writing, gossip, and "can you believe this place?" jokes. Build trust first, loosen up later.

Hybrid etiquette

Hybrid work adds a layer: you're managing the room and the chat. Safe defaults:

Response time: if you can't respond quickly, acknowledge it. "Got it — I'll reply by ___."
Meetings: show up on time, stay present, don't multitask loudly.
Camera norms: match the team's baseline.
Tone: be careful with sarcasm and "too casual" phrasing in public channels.
Decision hygiene: when a decision is made in Slack, post a recap. Email it if important.

—

The unfair truth about office etiquette is that it's almost never about etiquette. It's about whether the people around you can predict what you'll do in the next ten minutes. Predictable people get given more rope. Unpredictable people get watched. The clothes, the punctuality, the response time — those are just visible proxies for predictability, which is the actual thing you're being graded on.

For the easiest "professional signal" template, steal the Status update template.

Feedback Without Fear: Scripts That Pull Specifics From Your Manager

Mike Halpert — Tue, 26 Sep 2023 00:00:00 GMT

Asking for feedback feels like handing someone a live grenade labeled "be honest." They smile, nod, and hand it back with "you're great."

New hires on their first dashboard project do this all the time. Halfway through, they toss out "any feedback?" and get a pat on the head. Six weeks later, the review arrives with surprises they could've fixed months ago.

Feedback at work is a structured ask for calibration on your output. It's you saying, show me the gap between what I did and what hits the mark here.

Your manager isn't grading your soul. They're checking if your work aligns with team priorities, reduces their risk, and scales without constant oversight. They want to know: does this person ship reliably? Do they need babysitting? Can they handle the next thing alone? Vague questions leave them guessing what you want, so they default to safe, forgettable lines that check the box.

A good feedback exchange sounds like this: you name a recent deliverable. They pinpoint one thing to repeat (the repeatable win) and one to tweak (the quiet miss). You leave with two actionable phrases: "Double down on the data summaries" or "Cut the intro next time; decision-makers skim." Total time: three minutes. Both sides clearer.

The bad version? You say "how am I doing?" They pause, search for positives: "Keep up the good work. Team loves your energy." You nod, relieved. Nothing changes. Your blind spots stay blind. Their mental model of you stays fuzzy until it matters.

The scripts that force specifics

This isn't therapy hour. It's a quick diagnostic. Timebox it to five minutes in your next 1:1. Pick one output from the last two weeks: a doc, a slide deck, a PR, an email thread. Share the link ahead if async works better.

The core rule: never ask open-ended. Name the thing. Ask for repeat/change. Here's the kit.

First, the one-liner opener that works every time:

"On the [specific deliverable], what should I repeat next time? What one tweak would make it stronger?"

That's your base script. Plug in the artifact. Examples:

"On the Q2 metrics deck, what should I repeat next time? What one tweak would make it stronger?"

"In yesterday's stakeholder email, what should I repeat? One change to land better?"

Managers love this. It scopes their effort to 60 seconds. No essay required. You'll get lines like "Repeat the executive summary table; skip the methodology unless asked."

Your manager is juggling thirteen Slack threads and a meeting they're late for, so this sharp ask cuts through the noise.

If they go vague ("it was good"), nudge once:

"Thanks. Specifically, one thing to keep doing and one to adjust?"

Still vague? You've got your baseline: no strong signals. Move on.

For bigger asks, like after a project wrap:

:::template{title="Project Feedback Request"} Deliverable: [link or name the thing]

Context: Two-sentence summary of what it did / for whom.

Repeat: What here hits the bar? One specific to double down on.

Change: One adjustment for next time. (Format, depth, audience focus, etc.)

Next similar: On my desk: [name it]. How does the bar shift? :::

Send this in chat or shared doc pre-1:1. Your manager fills the blanks. Looks proactive. Takes them two minutes.

I've used variants of this at Stylitics, like when I pushed a dashboard prototype ten minutes before standup and asked about the viz choices. Got "Repeat the cohort breakdowns; less pie charts, they confuse execs." Saved me three revisions.

Yes, scripting your feedback request feels a bit silly at first, like rehearsing small talk. Corporate rituals often do. Run it four times, and it feels normal. Your manager starts volunteering unprompted.

One quirk: managers hoard negatives until reviews. They forget you want them early. This pulls them out.

That grenade? It only explodes if you leave it vague. Specifics defuse it every time.

(Word count: 732)

How to present work: the show-your-thinking method

Mike Halpert — Tue, 19 Sep 2023 00:00:00 GMT

Presenting work in a meeting is a separate skill from doing the work, and nobody tells you this until you've bombed one. You can produce something genuinely good and still lose the room in the first three minutes, usually because you led with outputs instead of the question you were trying to answer.

This gap trips up a lot of first-year people. They spend 90% of their prep time on the analysis and maybe five minutes on how to explain it. Then they wonder why the meeting ended without a decision.

What's actually happening in a presentation meeting

When you present work, you're not just showing a deliverable. You're asking a room of people to shift their mental model based on what you've found. That requires them to first trust your process, then follow your logic, then believe your conclusion, then decide something.

Most presenters skip straight to the conclusion. The room can't follow, so they stall on details or raise objections that are really just questions about your methodology dressed up as skepticism.

Your manager's job in a presentation is partly to absorb the content and partly to read the room. They're watching whether you can hold the attention of peers and seniors, whether you crumble under questions, and whether you understand the political shape of the problem. The work is what you're showing. Your competence is what they're evaluating.

What good looks like

A good presentation of work sounds something like this: "We were trying to decide X. The constraint was Y. I looked at three options. Here's what I found, here's why I recommend option two, and here's what happens next." Twelve sentences, four minutes, clear decision at the end.

A bad one sounds like: "So I did a lot of research and looked into different angles and there are several things to consider." Nobody in the room knows what you're recommending or why they're there.

The difference isn't confidence. It's structure.

The show-your-thinking method

Four beats, in this order, every time.

1. The question. What were you trying to answer? One sentence. Not background, not context, not preamble. The question. "We needed to know whether we should build this feature in-house or use the vendor."

2. The constraints. What made this hard, and what limited your options? One to two sentences. This is where context belongs. "Timeline was fixed at Q3. Budget ceiling was $50k."

3. What you found. The actual work. Three options, key insight, the thing you learned that changed your framing. Keep this to three bullets maximum in a verbal presentation. If it's a deck, this is slides two through five.

4. The recommendation and the next step. What you believe and what you want from the room. "I recommend option B. If you agree, I need a decision today to hold the vendor slot."

That last sentence is the most important part of any work presentation and the most often missing. If you don't tell people what you need from them, the meeting ends without a decision and you've just hosted an informational session.

The one-page version of this

For written presentations and briefing docs, same structure, tighter.

:::template{title="Work presentation brief"} The question we were answering [One sentence]

Constraints and context [Two to three bullets, what made this non-trivial]

What we found [Three bullets max, key findings, not exhaustive data]

Recommendation [One sentence, no hedging]

What I need from you [Decision / approval / feedback / signature, be specific]

Deadline for the above [Date or milestone, explicitly named] :::

This format works as a pre-read before a meeting, as a Slack message summarizing a decision, or as a one-page slide in a longer deck. The purpose is always the same: orient, inform, decide.

Questions are not attacks

The part of presenting that breaks most early-career people is questions. Someone challenges your methodology or pushes back on your recommendation, and the internal response is to either defend everything or fold completely.

Neither works. The move is: "That's a fair challenge. Let me tell you how I thought about it, and if the framing is off, tell me what I'm missing." Then answer directly. If you don't know the answer, say so: "I'd want to check on that before we finalize." Not knowing an answer in the moment is fine. Pretending to know and being wrong is not fine.

Work presentations feel high-stakes because someone's judging your thinking in real time. They are judging your thinking. The good news is that showing clear, organized thinking scores very well, even when the conclusion is uncertain. Rooms trust people who can say "here's what I know and here's what I don't" far more than people who project false certainty.

The 15-minute Sunday setup that saves your Monday

Mike Halpert — Tue, 12 Sep 2023 00:00:00 GMT

Sunday setup sounds like the kind of phrase used by people who have color-coordinated pantries and wake up at 4:00 AM to run marathons. It feels like a betrayal of your weekend. Acknowledging that you are thinking about spreadsheets while you should be thinking about brunch is the ultimate corporate cringe. Do it anyway.

The Sunday setup is a 15-minute scan of your upcoming week to identify landmines before they explode. It is not "starting work early." It is a defensive maneuver designed to protect your Monday morning sanity.

The logic of the pre-week scan

Your manager and your team do not actually want you to be a hero. They want you to be predictable. When you show up on Monday morning without a plan, you are a black box of potential delays. The system wants to know that the person responsible for Project X actually knows that Project X is due on Tuesday.

Good looks like walking into the office, or opening your laptop, and knowing exactly which three tabs to open first. You aren't "getting settled." You are executing. You have already identified that the 10:00 AM meeting requires a slide you haven't finished, so you spend 9:00 AM finishing it instead of reading a thread about the office snacks.

Bad looks like the "inbox scavenger hunt." This is when you spend the first two hours of your week reacting to every notification, feeling a mounting sense of panic as you realize you have four overlapping meetings and a deadline you forgot about. By noon, you are exhausted, and you haven't actually done any work yet.

The 15-minute routine

I've done this Sunday scan for years, starting back at Stylitics when I realized Mondays were turning into full-blown disasters without it. We all know that low-grade anxiety from unfinished business spilling over from Friday, and this routine cuts it off at the pass.

Corporate calendars are a game of Tetris played by a toddler: blocks appear at random, nothing fits, and the speed keeps increasing. That's your spicy truth right there, the one that makes you nod while scrolling Slack at 9 PM.

The goal is to answer three questions: What must happen? Who do I need to talk to? What is going to get in my way?

The calendar audit (5 minutes)

Look at every meeting. If there is a meeting with no description and no agenda that arrives at 4:55 PM on a Friday, flag it. Do you have the materials ready for your 1:1? Is there a gap where you can actually eat lunch?

The outcome trio (5 minutes)

Pick three things that, if completed, would make the week a success. Not thirty things. Three.

The relationship touchpoint (5 minutes)

Identify one person you need to check in with. This isn't a formal update. It is a "hey, are we still on for Wednesday?" text or Slack.

Preparation is not work. It is the tax you pay to avoid a miserable Monday.

The setup template

Use this simple format to capture your thoughts. Write it in a physical notebook or a digital scratchpad. The point is to get it out of your head and into a format you can reference the second you sit down on Monday.

:::template{title="The Sunday Setup"} Top Three Outcomes

Specific deliverable or milestone
Specific deliverable or milestone
Specific deliverable or milestone

The Calendar Landmine The meeting or conflict that looks most stressful this week

The "Do This First" Task The very first thing to open or write on Monday morning

The Relationship Check One person to ping for a quick alignment check :::

Moving from reactive to proactive

Monday is not the start of the work week. It is the execution of the plan you made when you weren't panicked.

When I was an intern at Google, I watched a senior lead spend the last ten minutes of every Friday and a few minutes on Sunday night just staring at a whiteboard. I thought it was performative "deep thinker" behavior. It wasn't. He was just making sure he didn't walk into a wall on Monday morning.

The corporate system is designed to fill your time with other people's priorities. If you don't have a 15-minute plan for your own time, you will spend your entire career building someone else's.

You will still have bad Mondays. Someone will still schedule a "quick sync" over your only focus block, and a server will still go down. But when the chaos hits, you will have a list of three things that actually matter to ground you. That is the difference between being overwhelmed and just being busy. I've seen it keep me steady through six months of back-to-back deadlines at Stylitics, and that's the quiet win that sticks around.

Managing expenses and work travel (without getting a reputation)

Mike Halpert — Mon, 04 Sep 2023 00:00:00 GMT

Expense reports are one of those "adult job" things nobody teaches. In your first 90 days they're weirdly high-stakes — not because the dollars matter (usually) but because trust does.

Handle expenses cleanly and you look responsible. Handle them sloppily and people quietly start wondering what else you're sloppy about.

Why this matters more than it looks

A lot of people treat expenses like admin work. It is. It's also a fast reputation signal, because it's one of the first places you're handling company money, company policy, and a process that can get audited.

Your real goal isn't to maximize reimbursement. It's to be:

compliant
boring
easy to audit

Boring is good here.

Step 1 — Find the policy (or admit there isn't one)

If there is a policy, read it once, then ask for norms:

allowed hotel and flight ranges
per diem rules
receipt requirements
booking tools (Concur, Navan, Egencia, etc.)
what needs pre-approval

"I read the expense policy. For travel, what's the normal hotel range and any 'always ask first' items?"

If there is no policy, treat rules as implicit. Ask your manager for boundaries. Rule of thumb:

Spend company money like it's your money and your name is attached.

Because it is.

Step 2 — Pre-approve anything gray

If you want to avoid drama, pre-approve early. Candidates: a hotel rate that feels high, flight changes, client meals above the normal range, rideshare vs. rental car decisions, any "I'll expense it and explain later" idea.

"Before I book: is $___/night in range for this city? If not, what range should I target?"

The two minutes of "should I ask" you skip turns into ninety minutes of "why did you spend $X" later. Always ask.

Step 3 — Document like you'll be audited

Because you might be. The best defense is boring process:

keep receipts immediately (don't wait)
write clear descriptions
submit on a predictable cadence

A clean description: "Client dinner — Project X — 3 attendees — discussed pricing tier." A muddy one: "Meal." Vague descriptions create questions. Specific descriptions answer them in advance.

Step 4 — Don't mix personal and business

This is the number-one way people accidentally get a reputation. Three rules:

Never put personal items on the corporate card.
Don't "fix it later" unless you want to live in finance emails.
If you make a mistake, flag it immediately and ask how to correct it.

"I accidentally put ___ on the corporate card. What's the right way to reimburse and document it?"

Hiding mistakes is what creates distrust.

The common gray areas

Business meals. Clarify what counts as business vs. social, alcohol rules, who can be included. When unsure, ask.

Upgrades (flights, rooms, seats). Usually allowed only when it's a long flight, pre-approved, or cheaper due to odd fare rules. If you have status and the upgrade is free, most places are fine — the key is that you didn't charge the company for it.

Personal items while traveling. Toothpaste is different from souvenirs. If it's for the trip and within reason, it's often okay. If it's "because I was in an airport," usually not.

Combining personal and work travel. Common, often allowed with rules. Book the work portion through the normal tool, pay incremental personal costs yourself, document cleanly. Don't make finance reverse-engineer your vacation.

A travel checklist

Before the trip

Confirm policy and norms
Book through the approved tool
Get pre-approval for anything borderline

During the trip

Save receipts immediately (photo + folder)
Write who/what/why for meals
Avoid weird edge cases

After the trip (within 2-3 days)

Submit the report
Attach receipts
Add clear descriptions
Note anything unusual

Submit fast and you get fewer "what was this?" questions.

—

The mistake I see first-years make most often isn't fraud. It's letting the expense report sit for three weeks because they didn't feel like dealing with it. Then they're rebuilding receipts from memory, which always reads as suspicious even when it isn't. Submit Tuesday. Move on. The boring version of this skill is also the senior version.

For a simple weekly habit that prevents "I didn't know" moments in general, use the Week 1 Checklist.

Mistake management: how to own it, fix it, and keep trust

Mike Halpert — Tue, 29 Aug 2023 00:00:00 GMT

Mistake management is what happens after you realize you sent the wrong dashboard version to finance. It is how you explain the error, patch the fix, and make sure people still trust you to keep their stack intact. The process is boring, repetitive, and yes, it is how to handle mistakes at work.

The person across the table, your manager, the ops leader, the person whose deadline you just moved, is not trying to catch you. They are trying to keep the project from shuddering into the next department. Their actual goal is to understand impact, figure out containment, and make sure the same slip-up does not wreck the next release.

Good looks like a calm check-in thirty minutes after a mistake hits: you have already documented the impact, you have a trusted fix lined up, and the conversation is focused on what else you need to clear. They nod, ask one clarifying question, and you agree on the follow-up note that will go to the rest of the team. Everyone leaves believing the work can keep going.

Bad looks like silence. You wait for a status update meeting, hope it blows over, and then an entirely different team finds the problem and escalates it. Now the room is full of people who do not know you, the problem feels personal, and every metric in the chart looks like a smoking crater.

Contain the panic

Mistakes are not about blame. They are about clearing the floor so the next person can walk across it without slipping. The first thing to do is own the event before it becomes a surprise.

A surprise is what makes leadership think you are hiding something; a mistake is something you can fix. Your manager wants context: what exactly went wrong, how many users were impacted, what is the fix you can ship in the next sprint. You need the timeline in 15 minutes, not 15 hours.

You will wish you had the data while your brain is still fresh. At Stylitics I learned to write the schedule for the fix before I even opened the next Slack message, because waiting for consensus just makes the ticket fester. During my internship at a small analytics firm, I once left a change request in draft for two days because I was waiting for someone else to notice; by the time it surfaced, the release train had already departed.

Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for. That is the real pressure: they need you to cut through the noise with facts, not add to it.

The “oops, did it again” meeting is the weekly sync that somehow still exists even though everyone knows nothing moves forward unless you leave with clear impact. That meeting should be about trust, not confession. Imagine the postmortem slide deck: it has the same information every time, yet people behave as if we are inventing algorithmic trading while we are actually just re-running the same patch that freezes the cache.

That is the absurdity we punch up at: we create ritual around the mistake while pretending the ritual solves it. I've sat through enough of those to know the cringe in admitting how scripted it all feels.

So, how do you cover the basics?

Whenever you make a visible mistake, follow the rule I call “two sentences, two commits, two checkboxes.” It means you start with quick ownership and build from there.

Two sentences to the person who needs to know now: what happened and what you are doing about it.
Two commits: one for the hotfix, one for the rollback or temporary guardrail. These commits should have precise descriptions because people will look at them in six months.
Two checkboxes in your follow-up doc: impact and prevention.

This keeps you honest and prevents the rumor mill from spinning its own version of the story. We all fumble the ball sometimes; the point is to recover without turning it into a team-wide scramble.

The follow-up note template

You will not remember everything. The template below is what you fill out in the first 30 minutes while the incident is still crisp. It makes status easier to communicate and gives you a tangible artifact to share with the team.

:::template{title="mistake follow-up note"} What happened and when
<describe the action, the timestamp, and who saw it>

Impact
<users, metrics, downstream teams, dollar costs>

Fix executed
<steps taken or code merged, include links>

Next stopgap (if any)

Lessons / prevention
<what tuning, automation, or checklist change will stop this from being a repeat> :::

Yes, this feels like compliance theater, but do it anyway. The note is your version of a trust deposit slip. The act of writing it down forces you to own the story instead of letting others narrate it.

After the note is written, the rest is about execution. Share the note with the people who needed to know yesterday. Then share it again with the people whose dashboards read the wrong number for an hour.

Let them see that you are not ghosts in the tooling, tweaking numbers behind the scenes. If you avoid eye contact, the room will fill with people suspicious of what else you are not saying.

Sharp turn, honest follow-through

Mistakes are not fatal. Surprises are. Stay ahead of the surprise by showing your work quickly.

When you explain the remedy before they ask, you show that you are the predictable person in the room, even if the situation is not. That shift from reactive to ready keeps the whole cycle from dragging on.

You will still mess up. Not every fix stays in production for six months. But the trust gap closes whenever you stop waiting for the perfect moment and start handing over the situation with clear intent, just like those early days at Stylitics when a simple note turned a dashboard glitch into a non-event.

Workload triage: the four questions before you say yes

Mike Halpert — Tue, 22 Aug 2023 00:00:00 GMT

Workload triage is the four-question checklist you run before you say yes to another request. It is a deliberate pause that prevents the random ping from becoming your week. If the ask lands with no clue about urgency, impact, success criteria, or updates, then you are about to trade focus for a mystery project that might never count toward your goals.

The person handing you the work is trying to keep the program moving without going back to the same room three more times. They want the checkbox clicked, the blocker cleared, the deadline hit, and the stakeholder quieted. Your clarifying questions are not about being difficult; they make it possible for them to hand you something that actually lands.

Good looks like a 90-second exchange where everyone hears words like “deadline,” “who needs to approve,” “delivery format,” and “next sync” in the same breath. It looks like you walk away with a shared understanding of whether it is a sprint, a quick bug fix, or a side quest that can wait until next week. Good means you know what to deliver, when it is due, and whose inbox will light up if you miss it.

Bad looks like you nod and type “sure” while the requester keeps talking because they never pause to describe the deliverable. A bad interaction ends when you walk away with a vague “we need this soon” and a calendar full of meetings you now feel obligated to accept. The result is the usual overload: the inbox that should have been one helpful summary and is instead four follow-ups plus uncertainty.

Yeah, running this checklist every time an ask drops feels a little like a scripted corporate ritual, but I've seen it save weeks of wheel-spinning. I've run these questions in back-to-back standups at Stylitics, and we all walked out with actual plans instead of nods.

The four triage questions

Workload prioritization is not about being the busiest teammate. It is about choosing the fight that actually moves the work forward. Ask these questions in order, ideally before you acknowledge availability. They are not optional; they are the difference between work that is visible and work that vanishes into a dark corner.

Your manager's Slack is already drowning in half-baked pings from five different teams, so punch back with these to reclaim your bandwidth.

What is the urgency? Ask for a deadline, the event it ties to, or what happens if it slips. Yes, this feels like a scripted onboarding line, but ask it anyway. Without it you are racing to unknown brakes. The urgency answer also reveals whether this is a “fires first” or “wait till next cycle” request.
What is the impact? The person on the other side of the table is trying to keep the stakeholder content, but that does not mean the work matters equally. Get a brief answer: what changes if this lands versus if you delay? A quick “keeps the partner from escalating” versus “nice to have for the research doc” tells you whether to reshuffle priorities or slot it into the background.
What does done actually look like? Most overload is just an unclear definition of done hiding in plain sight. When I was at Stylitics I watched a stakeholder ask for “some charts” and leave, and the team spiraled for a week trying to guess the format. Ask for wireframe examples, the format they will share, the data refresh, how they’ll know you are finished. If the answer is “just make it” you do not say yes. Instead, you say, “Can we sketch the format together so I know when I hit the mark?”
Who needs updates and how often? Someone thinks “copy me” is a mode of communication. You are not a notification service. Clarify the rhythm: Slack for blockers, weekly summary for project owners, no updates unless something deviates. This saves you from writing ten unnecessary emails and from the sudden expectation that you report in twice a day. We all end up as the default update machine if we don't call this out early.

The ritual is simple enough to finish in two minutes. The real trick is saying no the first few times you discover the ask is vague. You do not have to decline the work forever. You just have to insist you cannot take it until outcome, urgency, and delivery are crystal.

Triage checklist

Use this mini form while you talk or as soon as you hang up. It is the checklist that saves you from giving into every unclear demand. Keep a note open, fill it in, and send a quick recap when you accept the work.

:::template{title="Workload triage checklist"} Question 1 – urgency: What date or event creates the deadline? Question 2 – impact: What changes if this work ships on time or if it waits? Question 3 – definition of done: What deliverable, format, and success criteria mean I am finished? Question 4 – updates: Who needs to see progress, and where/when should I share it? :::

After the call, paste your answers into the shared doc or Slack thread so everyone is aligned. If you are still unsure, respond with a short script: “I can take this once we confirm [insert missing info]. Until then it sits on pause.” That script is not snark; it is triage. It makes the bureaucracy work for you instead of against you.

The deadpan observation: the “urgent” thread with six people bumping the same ticket and no decision owner is the only thing that grows faster than the backlog. If a new ask has no urgency, no impact, no definition of done, and no update plan, treat it like poorly labeled equipment in a storage closet. You can open the box later when someone realigns it.

I still forget question four about once a month, and the following Monday reminds me why that little detail mattered.

How to set work boundaries without saying the word

Mike Halpert — Tue, 15 Aug 2023 00:00:00 GMT

What saying “boundaries” really looks like here

Setting boundaries at work is not about doing less. It is about steering predictable work before you get drafted as the default dumping ground for every urgent request. The goal is a steady pace that your team can plan around, not a dramatic denial of help. When you can clearly describe how you decide what is urgent, when you respond, and how long the deep-focus stretches last, you stop being a mystery.

The people handing you work, the manager, the PM, the person who sends a Slack DM at 9 p.m., are not secretly trying to ruin your week. They are trying to keep the train on the track. They want one person they can call to get a thing done, to know when that person is available, and to avoid five follow-ups that all say “bumping this” on the same thread. Their unspoken request is: “Can I budget you for this without waiting to hear three times if you are alive?” You answer that before the ask happens.

Good looks like the room where you announce: “Here is what I can own this sprint. Here is when I will respond to synchronous pings. If you need more, tell me now so I can adjust.” The manager nods, adds a new task to the board with your timeline, and the “let me know if this is on your radar” emails stop. Everyone can point to the same agreed-upon priorities and there is a plan for anything that bumps the schedule.

Bad looks like the room where you answer every Slack ping immediately, never state your focus time, and then nod along to the twenty requests that arrive between 3 and 4 p.m. Your calendar becomes a strip-mined log of context switches, and the manager has to guess which ask you are still on. When you finally finish something, they are surprised because they assumed you were simultaneously finishing four other things. That’s the classic default dumping ground.

Look, I get it: spelling out your response windows in a shared doc feels a little like overkill, like you're turning your calendar into a public service announcement. But I've been there, buried under pings during my first six months at Stylitics, and this stuff actually cuts the chaos.

How to bake predictability into your week

Start with a personal rhythm note. Pick a single email or shared doc channel and send this once a week: “Top two priorities, blockers, response window.” Think of it as a mini sprint review that also sets guardrails. At Stylitics, I built a version that lived in the same doc as the KPIs we were watching. That small habit kept my manager from sliding new work onto me without a conversation, because the doc spelled out what I had already committed to. During my Google internship, the team had a “how to reach me” section in the onboarding wiki, and I still use that structure ten years later.

Answering a new request should sound like a tiny script, not a manifesto. Try this: “Thanks for flagging this. I can complete it by [date/time] if it fits with [current priority]. If it needs to ship sooner, let me know what to deprioritize.” It admits you have a queue, gives them a choice, and avoids the default “Sure, I’ll do it” that masks the real cost. The sentence is short, the tone is calm, and the little bit of detail protects your focus.

Yes, this feels like you are writing a personal ops memo. Do it anyway. The minute you let the glow of a Slack DM dictate your next hour, you are negotiating without rules. Lay out the trade-offs once, and you buy yourself the ability to say no later without drama. We all learned this the hard way: your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for, so hand them a clear map instead of making them guess.

Build your weekly check-in

Create a tiny shared artifact that explains those trade-offs. Use the template below in your weekly status doc or in an intro email. Pin it where your team can find it, like the top of your shared project board or a pinned message in the channel.

:::template{title="Priority + response check-in"} Priority 1
Name and why it matters (stakeholder, deliverable, timeline)

Priority 2
Name and why it matters

Focus hours
Days/times I keep heads-down (e.g., “Tuesday/Thursday 9-11; afternoons reserved for reviews”)

Response window
Slack/Teams: 1 hour during focus blocks, 15 minutes outside work hours
Email: checked twice a day, replies same business day
Urgent: label as “Needs answer by X” so I can reroute

What to do if something shifts
Tell me which priority to drop, or give me one hour to reshuffle
:::

Keep that card at the top of a shared doc so anyone new can see your lane. The pipeline everyone understands means they know how much flow you have before adding another valve. If they know you open the valve at 10 a.m. and close it at 3, they stop yelling “hey is anyone available?” every fifteen minutes.

You do not need to make a speech. You need a system for priorities and response times. When you log the system somewhere, you buy yourself the ability to say “I do not have capacity until after this report ships” without sounding defensive. That’s the whole point. Punch up your week by owning the rhythm: it turns random pings into planned handoffs, and suddenly you're the reliable one, not the reactive one.

The default dump has a name

The weirdest bit is how fast the organization forgets you exist when you stop being a forty-five-minute response machine. That is your signal that the system is working. The next time someone tries to drop a last-minute ask at 5:45, you will have a little note ready to paste in the channel. That note is not a complaint. It is a recalibration.

Deadpan observation: the “Just wanted to keep you in the loop” email that arrives with no loop and no action. You can stop feeding it. Let them know you are the checklist version of reliable, not the free-for-all option.

I still catch myself defaulting to instant replies on quiet days, but now I pause and check the doc first. It's a quiet win: the inbox stays sane, and the work that matters gets done without the burnout tax.

(Word count: 912)

Structural edits: Retained existing structure with two H2 and one H3 for headings every 200-350 words; confirmed first-time-reader scaffolding in opener (what boundaries are, others' goals, good/bad looks) before how-to; kept word count at 912 within framework range (800-1100) and under first-time cap (1,100); no additions needed as flow is tight.
Voice moves: Retained CRINGE-ACK ("Look, I get it... feels a little like overkill"); kept FIRST-PERSON examples ("I've been there... at Stylitics" and closer "I still catch myself"); maintained PUNCH UP ("Punch up your week by owning the rhythm"); SPECIFICITY preserved (Stylitics six months, one Google internship reference); REUSABLE ARTIFACT intact as :::template; HONEST CLOSER as observation callback; all ≥4 hit with older-sibling tone via wry admissions like "buried under pings" and "deadpan observation."
Spicy claim: Retained at hinge: "We all learned this the hard way: your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for, so hand them a clear map instead of making them guess."
Hedge-adverb counts: Before: 1 ("not secretly"); after: 1 (no changes, as minimal and purposeful).
Specificity replacements: No changes needed; kept verified elements (Stylitics KPIs doc, Google internship wiki); polished "the metaphor your team already understands is a pipeline" to "The pipeline everyone understands" for conciseness without losing specificity.
Bans removed: Minor polish to avoid any reach-y phrasing (e.g., tightened "the metaphor your team already understands" to direct "The pipeline everyone understands"); confirmed no em-dashes, consultant verbs (e.g., "bake" fits casual voice, not banned), hedging over limit, or bullet-only sections; no internal links present.
Overall polish: Adjusted for older-sibling voice with subtle wry tweaks (e.g., "That’s the classic default dumping ground" stays punchy but relatable; ensured paragraphs 1-3 sentences, no performative cleverness).

What to do with downtime at the office (without looking checked out)

Mike Halpert — Sun, 06 Aug 2023 00:00:00 GMT

Downtime happens. Early in a job, it can feel scary because you don't want anyone to think you're lazy — especially if you're still building credibility.

The framing that helps:

Downtime is not a guilt moment. It's a reputation moment.

Your manager can't read your workload. They can only see your signals.

The situation most people handle poorly

You've got a 30–60 minute gap. Not enough to start something big. Too much to just stare at your inbox.

This is where people accidentally send the wrong signal — not because they're lazy, but because they don't have a playbook. Downtime is when you either look checked out, or you quietly build credibility.

The "you look like a pro" list

High-signal activities that don't require permission:

read industry news relevant to your team
clean up your notes and turn them into a one-pager
organize your workspace and docs so you can find things fast
prepare for upcoming meetings (agenda + questions)
fix a small recurring friction point (template, checklist, automation)
take a short walk or reset — yes, this counts

A good test: would I be comfortable if my manager walked by right now?

The "reads as checked out" list

Even if you could do these, avoid them in visible contexts — office, open Zoom, shared spaces:

endless social media scrolling
online shopping
watching shows
gaming
loud personal calls at your desk

People don't know your workload. They only see your behavior.

The downtime decision tree

When you have 15–60 minutes free, run this.

1. Are you blocked on something? Write the question you need answered. Include context plus your attempted solution. Ask the smallest possible version.

"I'm blocked on ___. I tried ___. I think the right next step is A, but I'm not sure. Can you confirm A vs. B?"

2. Is there a meeting coming up? Skim the doc. Write one or two questions. Decide what "a good outcome" is. Meeting prep is invisible until it isn't. People can tell when you're unprepared.

3. Can you create a reusable asset?

a checklist (what you do every time)
a template (status update, meeting recap, briefing doc)
a quick FAQ (acronyms, "who owns what," common links)
a short SOP (how to do X here)

One asset per week makes you dramatically more useful.

4. Can you learn one tool that removes future pain? Pick something directly tied to your job — spreadsheets, Jira, Salesforce, Looker, Notion. Not "random learning." Removing future friction.

5. If you're regularly idle: ask for more work. Once.

"I have a bit of capacity this week. Is there a small task I can pick up to help the team?"

Two rules: ask once, not every hour. Offer something specific: "I can document X." / "I can QA Y."

Don't become a volunteer doormat

Being helpful is good. Becoming the person who absorbs everyone's leftovers is not. Three guardrails:

Ask permission before taking someone else's work.
Timebox: "I can spend 30 minutes on this today."
Close the loop: send a recap when you're done.

How to communicate capacity

If you're blocked or genuinely light, don't sit there hoping someone notices:

"Quick update: I'm waiting on ___ to proceed with ___. While I wait, I can either (A) document ___ or (B) help QA ___. Which would be more useful?"

That message does three things at once: proves you're not idle by default, gives your manager easy options, and prevents the "why didn't you tell me?" conversation later.

—

The first-year version of me thought looking busy was the same as being valuable. It isn't. The seniors who watched me hardest weren't tracking whether I was idle — they were tracking whether the things that came out of my downtime were useful when I had more of it. The reusable assets you build during your slow weeks are what get you trusted with bigger work in your busy ones.

For the simplest reusable asset that works in almost any role, use the Status update template.

Two sentences that keep meetings from unraveling

Mike Halpert — Tue, 01 Aug 2023 00:00:00 GMT

What is the two-sentence recap habit? It is the tiny meeting recap email you send right after a discussion ends, usually in the same thread or channel. Two sentences, no drama. Sentence one states the decision that came out of the room. Sentence two states the immediate next step and who owns it. The point is to prove the conversation landed somewhere, not to rewrite the transcript.

Recaps are not about proving you’re responsive. They are about making the room accountable.

Who they're rooting for in the room

Your manager, partner, or product lead is trying to exit the meeting with a sense of forward motion without another follow-up marathon. They want to hear that someone made a call, not that everyone is still thinking about it. If you point out ambiguity, you are helping them. If you double down on the fuzzy part, you are cost center noise. They are not secretly hoping you will summarize; they are secretly hoping you won’t have to remind them later.

Good vibes after the meeting wraps

A good post-meeting feels like a light switch flipping. Someone says, “We land on X.” You say nothing, because the next step is already on the table.

Then you leave the room and you send an email that says:

Decision: “We will build the small API change for payment tokens instead of waiting for the platform rewrite.”
Next step: “I will take the specs to legal and loop back by Thursday with changes.”

If they’re still debating as the meeting dies, you can’t send that email yet, but you still note the decision you’re recommending and the action you commit to. That’s the other half of good, you are the person who saw the gap, filled it, and flagged the timing.

When it all goes sideways

Bad looks like a meeting ending with “Can someone follow up on the next steps?” and then silence. It looks like the summary email that lands two days later with three paragraphs of background, no decision, six “feelings,” and a heap of passive voice. The conversations that go nowhere usually end with a shared assumption that “the team will decide later,” which is code for “we all think it’s someone else’s job.”

Most meetings dissolve into a polite nod toward alignment that crumbles by Tuesday.

Nail the recap in two sentences

Start by doing the quiet work in the meeting: identify the decision point, name who is responsible for the next activity, and lock the timeline down before anyone stands up. As soon as the calendar entry is over, type the recap. No drafts. No paragraphs. Just the decision, the next step, and ownership. Then hit send or drop it in Slack.

Yes, sending another email for a decision you just made feels a bit silly, like you're rubber-stamping your own homework. I've been there, firing off those recaps five minutes after a standup at Stylitics, and we all rolled our eyes at first. Do it anyway. This ritual turns a forgettable meeting into a documented event.

The two-sentence recap template goes here. Use it immediately after you leave the room, while everyone still remembers what they agreed to.

:::template{title="two-sentence recap"} Decision: What was decided in the room?
Next step: What action happens next?
Owner: Who will own that action?
Due date: When will the next update happen? :::

In practice it looks like: “Decision: We will treat the Q3 landing page as a content-only release. Next step: I will draft the copy brief, share it with Design by Wednesday, and post the draft into the shared doc. Owner: me. Due date: Wednesday noon.” That’s it. Two sentences. If you want to add context, drop a one-line “Context” only when the room explicitly asked for the nuance. No essays.

Why this sticks in real teams

One weird observation: the two-sentence recap is the only place the people who skipped the meeting can still say “I’m aligned” without having to read the entire backlog.

At Stylitics, we used to slap an “action owner” tag on every meeting wrap-up. The decisions that mattered were the ones that survived that tiny ritual, especially during those six-month sprints where priorities shifted weekly. The recaps did not make anyone instantly smarter, but they made the next meeting shorter, because the confusion had already been cleared.

Your manager's inbox is a war zone of half-baked threads; two sentences cut through that like a knife.

I've watched those recaps pile up over a year at Stylitics, and the pattern holds: the ones we skipped always looped back with the same questions two weeks later.

(Word count: 842)

Meeting hygiene: how to protect your calendar without looking difficult

Mike Halpert — Tue, 25 Jul 2023 00:00:00 GMT

Meeting hygiene means treating your calendar like the scarce resource it is: a deliberate practice to keep unproductive meetings from eating your day alive.

The other party, the meeting organizer, wants alignment, updates, or decisions to move work forward, but defaults to pulling everyone into a room because that's the path of least resistance for them.

Good looks like a focused group tackling one clear goal, with decisions made and next steps assigned in under the allotted time.

Bad looks like a rambling chat where no one knows why they're there, time drags on with side conversations, and everyone leaves frustrated without progress.

Meetings expand to fill every inch of space you give them. Leave a two-hour gap on your Tuesday, and a "quick sync" will slide right in.

We all start out treating calendar invites like subpoenas. You get the ping, click accept, show up, thinking it's the team-player move. In reality, you're signaling your time is free for the taking.

The calendar tax

Meeting hygiene isn't about hiding in your cubicle. It's about making sure every minute in a room counts toward actual work.

The corporate machine thrives on meetings that could have been a Slack thread. They feel like progress. They mimic collaboration. For the person building the deliverable, though, they're a straight-up tax on focus.

Your aim isn't zero meetings. It's zero useless ones.

I've been there, staring at a calendar jammed during my Google internship. The folks who made it through without flaming out didn't dodge everything. They just asked "why" before saying yes.

The filter for "Accept"

Before hitting accept, run the invite through this filter. No clear decision? It's not a meeting. It's a group chat with bad ergonomics.

Here's the decision rule:

1. Is there a written agenda?

Yes: Move to step 2.
No: Ask for one. (Script below.)

2. Is my presence required for a decision or specific input?

Yes: Accept.
No (just FYI): Ask for notes afterward.

3. Is the meeting longer than 30 minutes?

Yes: Suggest shortening it or going async.
No: Accept.

Onboarding is vibes-based, so new folks at Stylitics six months in nod along to every invite, only to realize later their dashboard deadlines are slipping.

The "Polite Pushback" toolkit

Pushing back doesn't make you the difficult one. Frame it as boosting team output, and it lands as helpful.

:::template{title="The Calendar Protection Scripts"} The "No Agenda" nudge: "I want to make sure I'm prepared for this. Do we have an agenda or a specific goal for the call so I can bring the right data?"

The "I'm an FYI" opt-out: "Looking at the invite, it seems like I'm mainly here for context. To save a bit of time, I'll skip the live call and catch up via the meeting notes. Let me know if a specific question comes up for me!"

The "Calendar Collision" reschedule: "I have a hard stop at [Time] to finish [Project]. Can we move the decision item to the first ten minutes, or should we handle this over Slack?" :::

Admitting it, asking for agendas can feel a bit like playing process cop, which is half the reason we avoid it. But when you do, the organizer often sees their own fuzzy plan and cancels half those invites on the spot.

The art of the early exit

Watch the last 15 minutes: that's when "any other business" turns into aimless chit-chat.

If the key decision's done and your piece is covered, exit clean. No need to ride out the full clock.

Try this: "The part I'm needed for seems covered, so I'm going to hop off and get back to [Project]. Thanks everyone." It's direct, respectful, efficient. The rest of the room probably envies your move.

The focus block

Claim your deep work time outright. Block three hours on Tuesday and Thursday afternoons as "Project X Execution."

If you don't stake it, the org will fill it. Your calendar's the one patch of ground you control. Guard it.

I still get snagged in a 90-minute alignment call that goes nowhere now and then. We all do. What matters is spotting the drain and pulling the plug before it empties the tank.

How to give feedback to your manager

Mike Halpert — Tue, 18 Jul 2023 00:00:00 GMT

Nobody tells you that giving feedback upward is an option. The power dynamic implies the information should only flow one way: they tell you what to work on, you work on it. But the most effective manager relationships flow both directions, and managers who never hear feedback from their direct reports make the same avoidable mistakes for years because no one was willing to say the thing.

This is the rare move that sounds scary and costs almost nothing when executed correctly.

What upward feedback actually is

Upward feedback is information you give your manager about how they're managing you: something that would help your working relationship, a behavior that's creating friction, a communication style that's leaving you unclear. It's distinct from complaining about a decision you disagree with, which is a different conversation with different stakes.

The goal of good upward feedback is to improve the working relationship, not to vent or to win. If your goal is venting, find a friend. If your goal is change, this is the post.

What your manager is trying to do

Most managers genuinely want to know when something isn't working. The problem is they're often operating on incomplete information: they don't know you're confused by their Slack messages, they don't know the abrupt meeting cancellations land as dismissive, they don't know you're unclear on which of their three stated priorities is actually first. They're navigating their own calendar and pressure and making assumptions about what's landing.

Managers who don't get feedback get worse over time. Managers who receive clear, actionable feedback from direct reports improve. You are also in the feedback loop. The question is whether you're a useful input or not.

What good vs. bad looks like

Bad upward feedback sounds like: "Sometimes I feel like my contributions aren't valued." That sentence has no actionable content. Your manager can't change "sometimes." They can't operationalize "feel." They will nod, express some version of "I'm sorry you feel that way," and nothing will change.

Good upward feedback sounds like: "In our last two 1:1s, the meeting ended before we got to the growth section. I want to make sure we're covering that regularly. Can we protect 10 minutes for it?" Specific behavior. Concrete ask. Easy for them to act on.

The test: after the conversation, can your manager do something differently tomorrow? If yes, it was good feedback. If not, it was an expression of feeling, which is valid and also not the same thing.

The framing that makes it land

Three conditions that make upward feedback go better rather than worse:

Private, not public. Upward feedback in a group setting puts your manager on the defensive. It reads as a challenge to their authority, regardless of your intent. One-on-one, in your 1:1, is the right context.

After something good, not after something bad. Giving feedback in the middle of a friction moment makes the feedback look like a reaction. Delivering it during a good stretch, when the relationship has credit, makes it land as information, not complaint.

Framed around your need, not their failure. "I need more context when priorities shift" lands differently than "you keep changing the priorities without explaining why." Same underlying information. The first invites a response. The second invites a defense.

The script

In your next 1:1, after the main agenda, before the meeting ends:

"I wanted to bring something up that I think would help our working relationship. Is that okay?"

They'll say yes.

"I've noticed that [specific behavior, described factually]. When that happens, I end up [effect on your work: confused, uncertain, unable to prioritize]. Would it be possible to [specific change]?"

Example:

"I've noticed that our 1:1 agenda sometimes gets moved to cover urgent topics, and we end up not covering the growth section. When that happens, I lose track of where I should be developing. Could we protect the last 10 minutes for that, even when we're pressed on time?"

Pause. Let them respond. Don't fill the silence.

Most managers who receive feedback this way say something like "that's fair, yes." A few will be mildly surprised. Almost none will be hostile if the framing is right. The ones who are hostile to clearly framed, private, constructive feedback are giving you different information about the relationship, and that's worth knowing too.

What you're building

Every time you give upward feedback well, you're establishing yourself as a person who communicates directly and professionally. That is not a small signal. It tells your manager that you're someone who handles difficulty without going around them, which is one of the highest-trust moves available to an early-career employee.

Use this move once or twice a year, when you have something real and actionable to share. Overusing it for every minor friction is exhausting for both parties. Using it at the right moment, with the right framing, is one of the more underrated career accelerators in this archive.

What is an executive summary? (and how to write one)

Mike Halpert — Sun, 09 Jul 2023 00:00:00 GMT

An executive summary is the top of the funnel for your work. The one page (or one to two slides) that helps a busy leader decide three things:

Do I care?
What's the recommendation?
What decision is needed?

Do it well, they keep reading. Do it poorly, your doc might as well not exist.

The moment it clicks

Early in my first job I got handed a messy spreadsheet task — pull insights and patterns out of a giant Excel file. The analysis was hard but doable. The real problem was that I didn't have the tooling yet. Pivot tables were still a mystery to me.

This was pre-YouTube-explains-everything. So I went to a bookstore, bought a chunky Excel guidebook (CD-ROM included), and taught myself.

Then came the second challenge — and it's the one this post is about. Not "do I understand the data?" but "can I explain the point fast enough that a busy person will actually use it?"

That's what an executive summary is. Not more work. Translation work.

The definition

A short, decision-oriented snapshot of a larger document. Not the whole story. The trailer that convinces someone the movie is worth watching. Aim for ~1 page for a doc, 1–2 slides for a deck.

Your real goal: reduce the leader's work

A leader reading your summary is doing mental triage. Make triage easy by giving them, in order:

context
the problem or opportunity
the recommendation
the decision needed
risks and trade-offs
what happens next

Bury the recommendation on page three and you're forcing them to hunt. Don't.

The template

:::template{title="Executive summary template"}

Executive summary

Context (1–2 sentences):

Problem / opportunity:

Recommendation (1 sentence, BLUF):

Decision needed (be explicit):

Why this / key evidence (3 bullets max):

Risks / trade-offs (2–3 bullets):

Next steps (owner + dates):

:::

If it's slides

Slide 1: the call. Headline = the recommendation. Three bullets = the evidence that changes the decision. Decision needed (one line).

Slide 2: the reality. Three bullets = risks and trade-offs. Next steps (owner + dates).

If your deck needs twelve slides to explain the summary, you don't have a summary yet.

Write it last

Write the full doc first. Then write the exec summary. You don't actually know what matters most until you've done the work.

A mini example

Context: Customer support tickets for login issues spiked after the last release.

Problem: Driving churn risk and burning support hours.

Recommendation: Roll back feature X this week and ship a smaller fix by next Friday.

Decision needed: Approve rollback today. Approve one engineer allocation for five days.

Why:

Top 3 ticket themes point to feature X as the trigger
Rollback is reversible and reduces immediate customer pain
Smaller fix preserves the upside without the current risk

Risks and trade-offs:

Temporary loss of feature X benefits
Release schedule impact on Project Y (mitigation: de-scope one non-critical item)

Next steps:

[Me] execute rollback today
[Eng lead] assign owner by EOD
[PM] comms to support by tomorrow AM

That's the bar: tight, explicit, decision-forward.

Five mistakes to fix

1. "Background" takes the whole page. Keep context to one or two sentences. If it needs a history lesson, put it in an appendix.

2. No recommendation. Make a call. Even if the recommendation is "do nothing," say it.

3. Unclear decision. Write the decision as a sentence that starts with a verb: "Approve $X budget." / "Choose Option A." / "Confirm timeline."

4. Claims not backed up later. Only summarize things you can support in the full doc.

5. Too many bullets. If you have twelve key points, you don't have key points. Pick the three that change the decision.

—

The exec summary is the highest-leverage writing skill nobody teaches you in college. A good one-pager can change what gets prioritized in your division. A bad one means your work doesn't get read at all. The asymmetry is wild — and the format itself takes 20 minutes to learn. Steal the template, use it twice, and you'll never write a doc the same way again.

For the weekly leader-friendly format, use the Status update template.

The early win playbook: credibility without overpromising

Mike Halpert — Tue, 04 Jul 2023 00:00:00 GMT

Early wins are not giant projects wearing tiny hats.

An early win is a small, visible problem you can close in your first few weeks: fix a broken doc, clean up a messy handoff, answer a question nobody has owned, remove one annoying blocker from a teammate’s day. The point is not to change the company before your laptop has stopped asking for security updates. The point is to prove you can notice a problem, finish a thing, and report back clearly.

Your manager is not trying to watch you perform ambition theater. They are trying to learn whether giving you work creates less chaos or more chaos. Every new hire is a small organizational mystery box. Your manager wants evidence that you can take a bounded task, understand the goal, ask sane questions, and not turn a two-hour cleanup into a six-week strategic initiative with a logo.

Good sounds like this in the room: “I noticed the onboarding doc still pointed to the old dashboard. I confirmed the new link with Priya, updated the doc, and added a note about who owns it going forward.” Clean. Specific. Done.

Bad sounds like this: “I’m thinking we should rethink the whole onboarding experience across the org.” You have been employed for nine business days. The org does not need a thesis yet. It needs someone to fix the link that sends new hires to a 404 and a sad little permissions error.

Pick wins that are small enough to finish

The best quick wins in a new job have three traits: they are annoying, visible, and bounded.

Annoying means the problem actually bothers someone. Visible means the right people will know it got fixed. Bounded means you can finish it without needing a steering committee, a budget code, or the meeting where people debate the meeting notes from the prior meeting.

Trust is not built by promising altitude. It is built by landing planes.

I've seen this play out at Stylitics more times than I can count: the person who closes the small ugly loop gets invited into the bigger, cleaner conversation later. We all know the drill, because nobody gets a second month if they leave chaos in their wake. Not because they gave a stirring speech. Because they made life easier and did not make everyone pay a coordination tax.

Bad early wins are sneaky. They feel impressive in your head, which is where many workplace mistakes begin. Avoid these in your first month, especially when you're still learning the lay of the land:

Rebuilding a process you do not understand yet.

Volunteering for something with unclear ownership.

Taking on work that depends on five busy people replying fast.

Solving a problem nobody cares about.

Creating a “version one” that another team has to maintain forever.

Yes, writing a tiny fix into a doc can feel like giving yourself a gold star with office supplies, a ritual that's equal parts silly and essential. Do it anyway. Corporate memory is a distracted pigeon. If the work is not recorded somewhere, it has a way of becoming folklore by Thursday.

The early win checklist

Use this before you raise your hand. Ten minutes here can save you from accidentally adopting a haunted project.

:::template{title="Early win checklist"} Problem: What is the small annoyance or blocker?

Who feels it: Name the team, role, or person affected.

Why it matters: What gets slower, messier, or more confusing because this exists?

Definition of done: What exact thing will be true when this is finished?

Time box: Can I complete this in 30 minutes, 2 hours, or 2 days?

Permission needed: Who needs to say yes before I touch it?

Proof: What link, screenshot, note, or message shows it is done?

Close-the-loop message: Who do I tell, and where? :::

A good early win should survive that checklist without you needing to invent a subplot.

Here are strong candidates:

The team wiki has three outdated links, and you can confirm replacements.

A recurring report has no owner listed, and you can add one after checking.

A customer question keeps bouncing between two teams, and you can summarize the answer in one place.

A spreadsheet has unclear column definitions, and you can document them.

A meeting has no notes, decisions, or next steps, which is how calendars slowly become compost.

That last one is a classic. The recurring meeting where everyone remembers “we talked about it” and nobody remembers the “it.” Fixing that is not glamorous. Neither is flossing, and yet the consequences arrive.

Close the loop louder than feels natural

The win is not done when the task is done. It is done when the right person knows the loop is closed.

Do not write a novel. Write a receipt.

“Quick update: I fixed the broken dashboard link in the onboarding doc, confirmed the new URL with Analytics, and added the owner for future changes. Link here: [doc].”

That message does three jobs. It shows the action, proves you checked your work, and gives the next person a trail to follow. This is the part new grads skip because it feels self-promotional. It is not self-promotion. It is reducing ambiguity, which is half of professional life and 80 percent of Slack.

Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for.

Use this rhythm for your first three weeks:

Find one small loop.
Confirm it matters.
Fix it within the agreed boundary.
Tell the right person, with proof.
Stop before you inflate it into a crusade.

One early win will not define your reputation. Five closed loops will start to create a pattern. That pattern says, “This person finishes things.”

That is the whole playbook. Not heroics. Not reinvention. Just fewer broken links, fewer dangling questions, fewer tiny workplace fruit flies buzzing around everyone’s afternoon. And in the end, that's what sticks: the quiet relief of a team that runs a little smoother because you showed up and closed a few doors.

A simple rule for CC'ing people (so you don't start a war)

Mike Halpert — Tue, 27 Jun 2023 00:00:00 GMT

Look, I know dissecting the CC field like it's a crime novel ritual feels a bit silly, especially when you've got actual work to do. But after years in the trenches, I've learned that one misplaced name can turn a simple update into a full-blown office feud. We all stumble into these email traps early on, and the scars stick.

What CC'ing actually is

The CC field in your email is just a way to copy someone on a message without making them the main target. It lets them see the conversation for context or records, plain and simple.

What the sender wants from it

When someone CC's you or adds you to a thread, they're usually trying to keep stakeholders informed or create a paper trail for decisions. It's their attempt to loop in the right eyes without derailing the main action.

What good CC'ing looks like

In a solid email exchange, CC's build quiet alignment: everyone sees the progress, owns their piece, and the thread hums along without drama. The room feels collaborative, like the team's dashboard at Stylitics where updates synced without anyone yelling for attention.

What bad CC'ing looks like

A messy CC turns the inbox into a blame arena: the recipient spots their boss lurking and freezes up, resentment brews, and suddenly a routine ask becomes a loyalty test. Projects grind to a halt as trust evaporates.

The CC field is the most dangerous piece of real estate in your email client. Used correctly, it's a way to keep people in the loop. Used incorrectly, it's a passive-aggressive flare gun.

When you add a manager to a thread where a peer is lagging on a deliverable, you aren't "increasing visibility." You are telling that peer, I don't trust you to do your job, so I've brought in the police.

In corporate life, this is known as tattling via carbon copy. It is the fastest way to ensure that the person you're emailing will never want to help you on a project again. Your manager is juggling thirteen Slack threads, four Jira tickets, and a standup they're already late for, so why drag them into your side skirmish?

The psychology of the CC

Before you hit send, you need to understand the theater of the inbox. Emails aren't private chats; they're public performances where every name signals intent.

The "To" field is for the person expected to take action. The "CC" field is for people who need the information but aren't responsible for the work.

New folks at Stylitics would hit the CC button like it was a turbo boost. They thought, if I add my boss, the other person will move faster. This is a misunderstanding of how power works. Pressure applied via CC creates resentment, not efficiency.

A good CC creates a shared record of truth. It says, we are all aligned on this. A bad CC creates a digital crime scene. It says, look at what this person is failing to do.

The "No-Surprise" rule

The goal of email etiquette at work is not to be polite. It's to be predictable.

The one rule that saves you from 90% of corporate friction is this: never CC someone's boss if that person doesn't know the boss is watching.

If you feel a project is slipping and you need to escalate, do it explicitly. Tell the peer: I'm going to loop in our managers so we can get a decision on the budget.

Yes, this feels like you're announcing a formal declaration of war. Do it anyway. It's significantly better than the surprise ambush, where a peer opens an email and realizes their manager has been watching them fail in real-time for three days. I've pulled that explicit loop-in during a six-month dashboard sprint at Stylitics, and it cleared the air faster than any silent CC ever could.

The CC decision matrix

When you're staring at the address bar, stop guessing. Use this logic to decide who actually belongs in the thread. Corporate email chains balloon because no one questions the add, turning a quick note into a novel nobody reads.

:::template{title="The CC Filter"} The Action Taker: Who is the one person who must do the work? → TO

The Decision Maker: Who has the final 'yes/no' and needs to see the final result? → CC

The Affected Party: Who will this work break or help if they aren't warned? → CC

The Pressure Point: Am I adding this person just so the 'To' person feels nervous? → REMOVE :::

If you find yourself adding a VP to a thread about a formatting error in a slide deck, you are using a sledgehammer to hang a picture frame.

Managing the loop

I've watched threads implode from one overzealous CC. At Stylitics, I once CC'd a director on a minor technical disagreement with a lead dev ten minutes before our weekly sync. I thought I was providing context. The dev thought I was trying to get him fired. We didn't speak for two weeks, and the project stalled because he stopped answering my Slacks.

The fix is the "Move to BCC" maneuver. When a thread gets too crowded with executives who no longer need to be there, move them to BCC and state it clearly in the first line:

Moving [Manager Name] to BCC to save their inbox.

This is a high-signal move. It tells the manager you've got the situation handled and tells the recipient that the police have left the building, allowing you both to speak candidly again.

The final check

CC is not about accountability. It's about awareness.

If you are using the CC field to force someone to work faster, you aren't managing a project; you're managing a hostage situation. Save the escalations for the 1:1s or the explicit looping-in emails.

In the end, those inbox theaters quiet down when you treat CC's like the neutral tools they are, not weapons in the corporate game we all play.

How to ask for help without sounding helpless

Mike Halpert — Tue, 20 Jun 2023 00:00:00 GMT

As an intern, asking for help is not a confession that you are bad at the job. It is a normal work move: you are showing where progress stopped, what you already did, and what decision or information would restart it.

The person you are asking is not trying to grade your soul. They are trying to figure out three things fast: whether you understand the assignment, whether the blocker is real, and what level of help will get you moving again without turning their afternoon into unpaid detective work. Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for.

Good help requests sound calm and specific. In the room, or in Slack, it sounds like: “I’m working on the customer export. I checked the onboarding doc and tried the sample query, but I’m getting a permissions error on the billing table. I think I need either access to that table or a different source. Can you point me to the right owner?”

Bad help requests make the other person assemble the whole situation from fog. “I’m stuck” is honest, but it gives your manager a second job: interview you, inspect the assignment, guess what you tried, and invent your next step. A vague ask is a sock drawer tipped onto someone else’s desk: technically all the pieces are present, but now everyone is sad.

Help is not about sounding independent. It is about reducing the cost of helping you.

The 3-part ask

The best version has three parts:

Context: what you are working on and what outcome you are aiming for.
What you tried: the steps you already took, including links, docs, people, searches, or attempts.
Specific next step: the exact help you want now.

That third part is where interns level up fast. Don’t end with “thoughts?” unless you want 11 thoughts, three tangents, and a meeting invite titled “Quick sync.” Ask for the next action.

I've been there myself, drafting these asks during my internship breaks, feeling like I was scripting a bad improv scene. Yeah, it can come off a little silly, like you're directing a one-act play about your own blocker, but we all did it to get unstuck. The alternative is the 17-message Slack thread where everyone is typing and nobody is deciding.

Use this before you ask for help:

:::template{title="The 3-part help ask"} Context:
I’m working on [project/task], and the goal is [outcome].

What I tried:
So far I tried [step 1], [step 2], and checked [doc/person/system].

Where I’m blocked:
I’m blocked on [specific issue], because [what is missing, unclear, broken, or conflicting].

My proposed next step:
I think the next move is [option A], unless you’d recommend [option B].

The ask:
Can you [approve / point me to the owner / confirm the direction / help me debug for 10 minutes]? :::

That is the whole framework. Context, attempts, next step.

During my Google internship, I learned fast that smart people are generous, but they are not psychic. The interns who got useful help were not the ones who suffered longest in silence. They were the ones who made the problem easy to locate.

There is a difference between “I need help” and “I need you to do my thinking.” The 3-part ask proves you have done your part before pulling someone else in.

What this looks like in real life

Weak version:

“I’m stuck on the report. Can you help?”

Better version:

“I’m building the weekly report for the partner dashboard. I pulled last week’s template and updated the date range, but the revenue total is off by 18% compared with the finance sheet. I checked the filters and the currency setting. I think the issue is whether we include canceled orders. Can you confirm which definition we use?”

See the difference. The better version gives the helper a runway. They can answer the actual question instead of starting with, “Wait, which report?”

If you are asking in Slack, keep it short enough that someone can respond between meetings. Five to seven lines is plenty. If it takes three paragraphs to explain, send the short version first and offer the detail:

“I can send the full notes if useful.”

That line is underrated. It respects the other person’s time while proving you did the work. Corporate life contains enough accidental novels already, many of them written in comment threads under docs no one admits to owning.

Also, ask earlier than your panic wants you to. A good rule: after 20 to 30 focused minutes with no progress, write the 3-part ask. You do not have to send it immediately. Drafting it will either reveal the next thing to try, or prove the blocker is real.

If the answer is obvious once you write it down, congratulations, you helped yourself. Annoying, but efficient.

If you send it and the person replies with a fix, close the loop:

“That solved it. I’ll use the canceled-orders definition and update the report by 3.”

Tiny follow-ups matter. They tell the helper their time worked. They also make you look like someone who can be trusted with progressively less supervision, which is the quiet intern victory.

When to tweak the framework

We all hit moments where the 3-part ask feels too rigid, like after six months in when blockers involve cross-team drama no template catches. In those cases, add a quick note on the human side: “This ties into the Q2 priorities we discussed last week.” It punches up the context without overwhelming the ask.

Asking for help well does not make you look helpless. It makes you look like someone who knows not to bring the whole sock drawer.

The first-week coffee chat: how to actually be useful

Mike Halpert — Tue, 13 Jun 2023 00:00:00 GMT

The "coffee chat" is the most awkward ritual in the corporate calendar, part silly icebreaker and part survival drill. It is a twenty-minute window where two people who have never met pretend to be interested in each other's "journey" while staring at a Zoom screen.

I remember treating these as auditions back when I was a new grad. We all did, spending the whole time trying to sound smart, polished, and high-potential. This is a mistake.

Coffee chats aren't about being interesting. They're about being curious.

The goal is intel, not networking

Your counterpart in these chats is usually just trying to check a box: help the new person get oriented without derailing their own packed day. When you're in your first month, "networking" is a vague goal that leads to vague conversations. You don't need more LinkedIn connections. You need a map of the hidden plumbing of your company.

Every organization has a formal org chart and a real one. The formal one tells you who signs your paycheck. The real one tells you who actually makes the decisions, who has the historical context on why the 2022 project failed, and whose approval you actually need to get a slide deck pushed through.

The coffee chat is your primary tool for mapping that real org chart. Most onboarding is vibes-based anyway, so grab the facts while you can.

What good looks like

A successful coffee chat feels like a focused interview where the other person does 80% of the talking. You leave the call with three specific pieces of information: what this person cares about, how they prefer to be communicated with, and one "landmine" to avoid in their department.

A bad coffee chat feels like a first date where both people are terrified of silence. It consists of "How's your week going?" and "I'm really excited to be here," and ends with both of you agreeing to "stay in touch" without any reason to actually do so.

The "Intel-First" framework

I spent a lot of my early time at Stylitics trying to impress people by talking about my degree or my internship projects. It was a waste of time. The people who actually ramped fast were the ones asking the questions that made the other person feel like an expert.

Yes, this feels like you're playing a character. Do it anyway. People love talking about their own expertise, and they'll associate that good feeling with you.

Use this script to move from "polite small talk" to "operational intel" in under fifteen minutes.

:::template{title="The Coffee Chat Script"} The Opener (2 min)
"Thanks for carving out time. I'm trying to map out how [Department/Project] actually works so I can be useful as quickly as possible. Mind if I pick your brain on a few specific things?"

The "How it Works" Questions (8 min)

"From your perspective, what does a 'win' look like for our team this quarter?"
"Who are the two or three people I should absolutely know if I want to get [X] done?"
"What is the one thing people usually misunderstand about your role/team?"

The "Landmine" Question (5 min)

"What's the fastest way someone in my role could accidentally make your life harder?"

The Close (2 min)
"This was helpful. Is there anyone else you think I should talk to who has a totally different perspective on this?"
:::

The art of the follow-up

The meeting is only half the work. The other half is the "receipt."

Send a three-sentence Slack or email within two hours. Do not say "it was great meeting you." That is filler. Instead, reference one specific thing they said.

"Thanks for the chat. That point about the [specific project] legacy is a huge help, I'll keep that in mind when I'm drafting the requirements tomorrow."

This proves you were listening and that the time they spent with you had a direct impact on your work. In a corporate environment, being a "good listener" is a superpower because most people are just waiting for their turn to speak.

The hidden logic

The corporate world is basically a giant game of telephone played by people who are all slightly stressed. The person who can synthesize the most accurate information the fastest is the one who gets the high-visibility projects.

The coffee chat is not a social hour. It's a reconnaissance mission.

I still occasionally find myself in "get to know you" meetings that devolve into talking about hobbies for thirty minutes. It's a pleasant waste of time. I've learned to gently steer those back toward the work, because knowing someone likes hiking is fine, but knowing they hate emails sent after 4 PM is what actually saves your career.

Honest truth: you will still feel a bit like a fraud the first few times you use a script. That's just the feeling of professional growth.

Should you send an email or a Slack?

Mike Halpert — Mon, 05 Jun 2023 00:00:00 GMT

Email vs. Slack isn't a personality test. It's an operating decision about where a piece of information lives — and at most companies, the answer to that decision is "wherever the person who sent it felt like at 3pm on a Tuesday."

That's how teams end up arguing about decisions nobody can find. Get this right early and you become the person other people copy.

The pattern that teaches this

You send an important update in Slack. It gets one thumbs-up. A week later, in a meeting, someone says with genuine confusion:

"Wait — when did we decide that?"

Nobody did anything wrong. You used a tool that's great for conversation for something that needed a record. The two are not the same. Slack is for thinking out loud. Email is for "here is the thing." Most early-career mistakes happen because nobody draws this line.

The two-question rule

Two questions get you 80% of the way home:

Is this urgent?
Do I need a paper trail?

Then:

urgent, no paper trail → Slack
not urgent, paper trail → Email
urgent and paper trail → Slack to act, email to lock it in

Memorize that table. It will save you from approximately one bad week per year for the rest of your career.

When to use email

You need email when you need a durable record — anything that someone might say "I didn't see that" about later. Confirmations, approvals, final requirements, money. The bar isn't legal; it's whether you'd be comfortable recapping the decision out loud six months from now without checking.

Email is also the default for external or formal tone. Clients, vendors, executives. Even internally, an email signals "this matters." That's not a vibe. It's literally how senior people parse signal.

And email wins for long context. If your message has sections, attachments, or a "first read this, then this" structure, Slack turns it into scroll-purgatory. Use the right shape.

When to use Slack

Real-time collaboration. Quick decisions. The "is anyone else seeing this?" panic. Two-line questions like "Do we have the latest deck link?" or "Who owns the API key rotation?" These are the right questions to send in Slack and the wrong questions to send in email — sending those via email is how you become the new grad people quietly avoid.

Coordination notes also belong in Slack. "Running 5 minutes late." / "I'll take this ticket." / "In the lobby." Don't email these. Just don't.

The part nobody tells you: which Slack channel

Email vs. Slack is the easy question. Which Slack venue is the harder one. The defaults:

Public channel — when the answer helps others or you want visibility
Thread — when you're responding to a specific message (keeps the channel readable)
DM — when it's sensitive, personal, or genuinely one-to-one

If you DM everything, you create hidden work and the team doesn't learn from your questions. If you post everything in public channels, you create noise that everyone tunes out. The first month at any new job, watch how your manager and the most-trusted senior on your team handle this. Then copy them. Slack hygiene is mostly mimicry.

A few patterns that come up constantly

A Slack thread turns into a decision. Recap it in the thread, then send a one-paragraph email summary. "Confirming what we landed on: X. Owner is Y. Deadline is Z." That's a 90-second move that prevents a 30-minute meeting next quarter.

You're escalating a risk. Slack to alert, email to document. The email format that reads as "I'm on it" rather than "I'm panicking":

What's happening
Impact
What you've tried
What you recommend
What you need from them

Skip any one of those bullets and the message tilts toward panic.

You have a question you should have looked up. Five minutes of homework, then the smallest possible question: "I checked X and Y, still don't understand. Is the answer A or B?" That's the question senior people are happy to answer. The unfiltered version isn't.

—

I still mess this up sometimes. Sent a quasi-staffing decision in a Slack DM last quarter and three people didn't see it for a week. The rules are simple. The discipline is the work.

For the update format that works in either tool, steal the Status update template.

Stakeholder map: who actually influences your first wins

Mike Halpert — Tue, 30 May 2023 00:00:00 GMT

Start with the reality your org chart hides

A stakeholder map is the annotated list of people whose approvals, opinions, or silence will move your work forward. It records who reviews your deliverable, who can pause it, who champions it, and who just needs a heads-up before Friday. It is not a pretty org chart, it is your actual operating sheet.

The other party you are mapping is the people who care more about keeping their own timelines clean than giving you a pep talk. Reviewers want fewer surprises. Blockers want coverage for their own dependencies. Sponsors want to know their investment is not leaking into a calendar black hole. Your job is to translate their goals into a map, not to assume they are wondering whether you made coffee.

Good looks like a first-week conversation where you name the deliverable, say who the reviewer is, and then pause to see whether that reviewer needs a draft two days before the board meeting or a quick Slack summary. Everyone leaves the room with a small, shared picture of how the work actually progresses.

Bad looks like showing up with a finished deck, hearing a single comment about a forgotten executive, and realizing the actual approver was the person with the red flag emoji in their calendar. Nobody has clarity, and you learned nothing except that you are the first person to loop the wrong inbox.

Org charts show titles. Stakeholder maps show reality. I've built dozens of these maps over six years in cubicles, and they saved me from more last-minute scrambles than I care to count.

Assemble your map before the work begins

The quickest way to get lost is to assume the easiest path is the right one. Your manager is juggling thirteen Slack threads, six open Jira tickets, and a meeting they're late for, so that weekly stakeholder review exists solely to remind everyone that two versions of the same slide still live in separate drives. Punch up at that process by refusing to be another victim of it: start with the deliverable you just got assigned, describe it in one sentence, name the deadline, and then list every reviewed artifact it touches.

At Stylitics, I once walked into a review meeting thinking the product designer was the approver. I was wrong. The finance lead who owns the reporting template could say yes or no, and they were never on the calendar because nobody had mapped them. That gap cost a week and three awkward status updates. When you name the finance lead on day two, you avoid the surprise.

Build your map like this:

List the deliverables. Insert the document, dashboard, or slide deck you are shipping. For each deliverable, write who signs off, who provides data, and who can stop you at the door.
Call out decisions. Identify decisions that live in the deliverable. If there is a design choice, naming the reviewer who cares about that choice keeps you from hosting a blind demo.
Track the influence path. Note who needs to know, who needs to approve, and who can block. Put a frequency next to the name: weekly sync, quarterly review, on demand.
Set a check-in ritual. Ask two people within five days whether you have the sequence right. Listen more than you speak so you hear the real blocker language.

Yes, mapping stakeholders feels a bit like charting a family feud before the reunion starts, partially silly but way better than showing up blind. You are not creating the perfect stakeholder map; you are creating the one that keeps you from surprising anybody.

Use this template to capture them

Here is the template I use as a checklist:

:::template{title="Stakeholder capture"} Person First and last name

Role Reviewer, blocker, sponsor, or inform

What they care about Numbers, design, timing, compliance

Decision power Can approve, can veto, only implements

Update rhythm Weekly 1:1, drop-in Slack, final demo

Red flag What causes them to say no

First touch How and when you will check in :::

The template doubles as your checklist and conversation tracker. Without that snapshot, you keep hitting studs you did not know existed.

Specificity keeps you grounded. Identify at least eight names in your first sprint: three reviewers, two blockers, two sponsors, and one wild-card who has veto power even if they rarely speak up. The block of five to eight keeps you honest; once you have them on a doc you can share, the map becomes a shared artifact instead of a mystery.

Schedule those first touches

When you schedule introductions, use this script:

I want to understand how your team sees this deliverable. Who signs off on the numbers, who watches the timeline, and what would make you hit pause? I'd like to loop you in early so we avoid any blind spots.

That script opens the door without demanding a full rundown. We all fumbled these intros early on, but nailing the first touch turns potential blockers into quiet allies. In the end, your stakeholder map isn't about collecting names, it's about spotting the quiet influences that org charts pretend don't exist.

The 1:1 agenda that stops you from being a 'vibe check' employee

Mike Halpert — Tue, 23 May 2023 00:00:00 GMT

If your 1:1 has no agenda, it isn't a meeting. It's a vibe check.

Vibe checks feel great in the moment. You and your manager chat about the weekend, agree that the new project is "exciting," and leave the room feeling aligned. Then, three months later, you find out you're "meeting expectations" instead of "exceeding" them because your manager has no actual record of the hard problems you solved.

A 1:1 is not a social hour. It is a weekly calibration of your value.

What a 1:1 actually is

A 1:1 is a recurring meeting between you and your manager, usually 30 minutes once a week. It's your dedicated time to sync on work, flag issues, and align on expectations. We all know the drill from day one on the job, but too many of us let it drift into chit-chat.

What your manager is trying to do

Your manager isn't there to micromanage your daily tasks. They already track progress through Jira tickets, Slack pings, and team dashboards. Instead, they're scanning for bigger risks: is the project on track, or will it blow up and land in their lap during a VP review?

Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for. The 1:1 lets them offload that constant vigilance by hearing straight from you.

What good looks like in the room

Good 1:1s move fast and leave you both clearer. You lead with updates on wins and blockers, your manager chimes in with context or approvals, and you end with action items assigned. Everyone walks out knowing the priorities and feeling the load lighten.

What bad looks like in the room

Bad ones stall out in awkward silence or small talk. Your manager asks, "Anything on your mind?" and you scramble for words, or the chat veers to office gossip with no substance. You leave vague on next steps, and issues fester until they become emergencies.

The hidden goal of the 1:1

When you show up with a structured agenda, you aren't just being organized. You are signaling that you have a grip on your world. You are removing the anxiety of the unknown from your manager's plate.

The "Value-Capture" framework

I've seen this play out at every stop, from my Google internship to my time at Stylitics six months in. The people who move up the fastest are the ones who treat their 1:1 doc like a legal record of their contributions. We all start somewhere, and building this habit early saved me from more than one forgotten win.

You need a shared document. Not a notebook, not a mental list. A living doc that both you and your manager can edit. This prevents the "I thought we agreed on X" argument that happens right before a deadline.

Use this structure every single week:

:::template{title="The Weekly 1:1 Blueprint"} Wins since last week

Outcome A (e.g., Shipped the API fix that reduced latency by 10%)
Outcome B (e.g., Resolved the conflict between Design and Product on the header)

Current Priorities (The "Big 3")

Project X: Goal is Y by Friday
Project Z: Waiting on review from Legal
Admin/Growth: Finishing the onboarding certification

Blockers & Decisions Needed

Blocker: Need access to the AWS staging environment
Decision: Do we prioritize the mobile bug or the desktop feature for the sprint?

Feedback & Calibration

Question: On the last presentation, was the level of detail too high for the VP?
Growth: One thing I should do differently next week to be more effective? :::

How to run the meeting

Once the template is set, the execution is about precision.

Start with the wins. This feels like a weird corporate ritual where you're bragging to your boss. It is partially silly, but it works. Your manager is managing five other people and forgot that you saved the day on Tuesday. Remind them.

When you hit the blockers section, don't just complain. Bring a recommendation.

Instead of: "I'm stuck on the data pull," try: "I'm stuck on the data pull. I've tried X and Y. I think the fix is Z, but I need you to poke the Data team to get the permission."

One of the most common corporate behaviors is the "passive-aggressive alignment," where a manager says "sounds good" to a plan they actually hate, then corrects you two weeks later. Stop this by asking for a specific calibration: "On a scale of 1 to 10, how aligned are we on this approach?" It forces them to be honest.

The long game

The 1:1 is a game of documentation.

When performance review season hits, your manager will not remember what you did in October. They will open your shared 1:1 doc, scroll through the "Wins" sections, and copy-paste those bullets into the HR system.

If you've kept the doc clean, you've essentially written your own positive review. If you've treated the meeting as a vibe check, you're leaving your compensation to your manager's memory. That is a dangerous bet.

I still occasionally forget to update my own notes before a meeting, ten minutes before standup on a Tuesday. It's a habit, not a law. But looking back, the difference between a stressful quarter and a successful one was usually just a few bullet points in a Google Doc, pulling me through when my manager's plate overflowed.

The note-taking system that saves your first month

Mike Halpert — Tue, 16 May 2023 00:00:00 GMT

Your brain is a high-performance processor but a remarkably low-tier hard drive. During your first month at a new job, the company will attempt to download four years of institutional lore, six different software logins, and the complex interpersonal beef between Marketing and Product into your skull in about seventy-two hours.

If you rely on your biological memory, you will fail. You will be the person asking where the quarterly goals doc lives for the fourth time in three weeks. That is a fast way to signal that you are a high-maintenance hire.

The goal of the external brain

A work notes system is a place where information goes so it stops rattling around in your head. It is not a diary. It is a searchable, low-friction repository of things you are likely to forget.

Your manager is not testing your ability to memorize the thirty-four different acronyms used in the Tuesday stand-up. They are testing your ability to be autonomous. Every time you ask a question that was already answered in your orientation, you are effectively asking your manager to be your personal search engine. Your manager is in thirteen Slack threads, six open Jira tickets, and a meeting they're late for.

Good looks like you opening a laptop or a notebook the second someone starts explaining a process. It sounds like you saying, "I have that in my notes from our last chat, let me pull it up."

Bad looks like the thousand-yard stare during a training session, followed by a Slack message two hours later asking for the link that was just shared. It looks like "I think someone mentioned that once" becoming your catchphrase.

The three-bucket setup

You do not need a complex productivity suite with automated workflows. You need a single place: Notion, Obsidian, a physical notebook, or even a basic Google Doc. I've done this with a messy spiral notebook during my internship at Google, because I didn't want to look like I was distracted by my screen while VPs were talking. It worked because I could find the name of the specific server cluster three days later without asking for help.

At Stylitics, we all keep a running document for every project. The system works if it handles three specific types of information:

The Glossary: Every company has its own dialect of nonsense. Write down every acronym the moment you hear it. If "The Phoenix Project" is actually just a spreadsheet about office snacks, put that in the glossary.
The People Map: Names, titles, and what they actually do. "Sarah: Head of Sales, likes short emails, knows why the printer doesn't work."
The 'How-To' Receipts: Any process you perform less than once a week needs a step-by-step guide. If you only file expenses once a month, you will forget how to do it. Write it down once, and you never have to feel like a burden again.

:::template{title="The New Project Capture"} Project Name: The internal name and any weird code names The Decider: The one person who can actually say 'yes' or 'no' Definition of Done: What does the finished product actually look like? Key Links: Slack channel, Figma board, or shared folder Acronyms/Jargon: Terms used in this project that I don't know yet First Milestone: The very next thing that needs to happen :::

The cringe of the scribe

Yes, taking notes in every single meeting feels like you are the designated court reporter. It feels a bit like you're a student again, desperately trying to catch everything the professor says. Do it anyway.

The theater of note-taking is a powerful signal. When people see you writing down what they say, they feel heard. More importantly, they trust that they won't have to repeat themselves. Taking notes is not about being a secretary: it is about professional self-defense.

Documentation is not about being smart. It is about being reliable. People who remember things are fine, but people who can find things are indispensable.

Keep it messy

Do not spend three hours color-coding your Notion tags. A perfect system that takes an hour a day to maintain is a hobby, not a tool. Your notes should look like a workshop, not a museum.

If you find yourself spending more time organizing your notes than actually doing the work described in them, you have drifted into "procrastivity." The goal is to spend ten seconds capturing a detail so you can spend forty minutes focusing on the task.

You will still forget things. You will still have to ask for clarification sometimes. But when you do ask, it will be about the nuance of the strategy, not about where the "Submit" button is located. We all start as the new kid, but reliable notes turn that into peer status faster than you think.

The First 90 Days OS: Your Boot Sequence

Mike Halpert — Tue, 09 May 2023 00:00:00 GMT

Your first job is not a scavenger hunt. If you spend your first three months "figuring it out as you go," you aren't being scrappy; you're just letting the company's existing chaos define your professional identity.

Yeah, calling your onboarding an "operating system install" sounds half-baked, like something from a bad team-building exercise. But I've seen it work: get the basics right early, and the rest of your career runs smoother.

The first 90 days are the three months right after you start a new job. This period sets the tone for how your team sees you and how you fit into their daily rhythm.

Your manager and team are trying to fold you into their workflow without slowing down the whole group. They want to hand off tasks knowing you'll deliver without constant check-ins.

Good looks like you picking up the pace by week four, sharing updates that keep everyone in the loop, and spotting a small fix that saves the team time. Bad looks like radio silence on assignments, mismatched expectations on deliverables, and a growing pile of half-finished work that frustrates your boss.

Think of your first 90 days as installing an operating system. Your "defaults", how you communicate, how you handle deadlines, and how you report progress, are the core kernel. If you install a buggy OS now, every "app" you try to run later (like asking for a promotion or leading a big project) will crash. Managers aren't testing your IQ in these months; they're checking if you'll ghost them mid-task.

The 90-day boot sequence

The goal of the first quarter is to move from "the new person" to "the person who gets things done."

Your manager isn't looking for a genius; they're looking for a reliable node in their system. Reliability is the only currency that matters in the first 90 days. We all started somewhere, and I remember my own scramble to look busy instead of asking the right questions.

Month 1: The calibration phase

This is about mapping the land. You are learning the unspoken rules of the office. Who actually makes the decisions? Which Slack channels are for work and which are for complaining about the coffee machine?

At Stylitics, six months in, I spent my first few weeks realizing that the "official" project tracker was a ghost town, and the real work was happening in a chaotic series of Google Doc comments. If I had relied on the official process, I would have been invisible.

The move here is to calibrate your "Definition of Done." Don't assume "finished" means the same thing to you as it does to your boss. To some, "done" means a polished slide deck; to others, it means a rough bulleted list in an email.

Month 2: The reliability phase

Now you stop asking "how does this work" and start proving you can handle the basics without a reminder. This is where you establish your communication cadence.

The common junior mistake is the "black hole" effect: you're given a task, you disappear for four days, and then you emerge with a finished product that is slightly off-target. Managers hate the black hole. It creates anxiety.

The fix is the "low-fidelity update." Send a quick note when you're 20% done. It feels like you're bothering them. It's actually a safety net. Punch up your process here: these check-ins build trust faster than any flashy output.

Month 3: The value phase

By day 60, you should have a grip on the basics. Day 61 to 90 is when you start solving problems your manager didn't explicitly ask you to solve.

This isn't about rewriting the company strategy. It's about the small, annoying things. The outdated onboarding doc, the broken spreadsheet, the recurring meeting that everyone hates. Fix one small, visible friction point. That is how you transition from "someone we're training" to "someone who adds value."

Your default settings toolkit

You need a repeatable system for how you operate. If you don't define your defaults, your manager will define them for you (and they'll usually be "be available 24/7").

Use this framework to decide how you'll handle every new request for the first 90 days.

:::template{title="The Request Processing Logic"} 1. Clarify the Outcome: "Just to be sure, is the goal of this [X] or [Y]?" 2. Set the Timeline: "I can have a draft to you by [Day/Time]. Does that work for your deadline?" 3. Define the Format: "Do you want this as a formal doc, or just a few bullets in Slack?" 4. Schedule the Check-in: "I'll send a quick status update on [Date] so you know where I'm at." :::

Yes, this sounds like you're over-indexing on process. It's a bit robotic. Do it anyway. The "robotic" person is the one who never misses a deadline and never delivers the wrong format. That's the person who gets the best projects.

The long game

The corporate world is essentially a giant game of perception. Your reputation is a lagging indicator; the work you do today determines what people say about you in six months.

Setting your defaults early is a bit like choosing a gym membership. It's a tedious commitment at the start, but it's much easier to maintain a habit than it is to stage a total lifestyle intervention two years into your career.

I spent my first internship at Google trying to be a perfectionist, which is just a fancy way of saying I was slow and stressed. Once I switched to "reliable and communicative," the stress vanished.

The OS doesn't have to be perfect. It just has to be stable.

How to prepare for a performance review without turning into a brag robot

Mike Halpert — Tue, 02 May 2023 00:00:00 GMT

If this is your first performance review, the meeting feels heavier than it actually is. You hear "review" and picture a verdict: did I pass, did I fail. That's not what's happening. A review is your manager assembling a written argument about you — for HR, for the comp committee, for whoever calibrates raises and promotions across the team. Your job in the meeting isn't to defend yourself. It's to make their argument easier to write.

That reframe changes everything about how you prep.

What your manager is actually trying to do

Most managers go into a review meeting with three jobs: rank you against the rest of the team so HR can compare apples to apples, justify (or not justify) any raise or promotion they're advocating for, and surface one or two development areas they can document. They are graded on whether their team's reviews land cleanly. A review where the employee is surprised, defensive, or vague makes the manager's life harder — which means it's a bad review for both of you, even if the rating is fine.

So when your manager opens the meeting, they aren't trying to catch you. They're trying to confirm a story they've already partially written, fill in the gaps, and walk out with a doc that holds up in calibration.

What good vs. bad looks like in the room

A bad first review usually goes like this: your manager asks how the year went, you ramble about being "really busy" with no specifics, they list a couple of accomplishments back to you, you nod, they raise a development area you didn't see coming, you get defensive, and the meeting ends with a vague commitment to "communicate more." Nobody learned anything. The doc gets written from your manager's notes alone.

A good first review goes like this: you walk in with three specific wins, two honest stretch areas, and one or two asks for the next cycle, all written down in a one-page doc. Your manager already has most of this from your 1:1s, but seeing it on paper means they can paste straight from your doc into theirs. The development conversation isn't a surprise because you raised the stretch area first. You leave with explicit commitments on both sides.

The difference between the two isn't seniority or talent. It's preparation that respects what your manager is trying to do.

The two-week prep window

Block 90 minutes on your calendar two weeks out. You're going to inventory your year and produce one document. Don't try to do this in twenty minutes the morning of.

Walk through your sent email, your Slack DMs, your calendar, and your project tracker. For every meaningful chunk of work, write one sentence with a metric, a collaborator, and an outcome. "Helped with onboarding" isn't useful to anyone. "Wrote the analyst onboarding checklist; new hires hit ramp in two weeks instead of four" is. The metric is what makes it copyable into your manager's doc.

Pull at least one direct quote from a teammate or stakeholder — Slack, email, PR comment, anywhere. Specific praise from a named colleague carries weight that your own description never will.

The one-page prep doc

Drop this template into a Google Doc and fill it in. The structure exists so your manager can scan it in 60 seconds and use it.

:::template{title="Review prep — one page"} Wins (pick 3)

What: one sentence
Impact: metric or outcome
With: who you partnered with

Stretch areas (pick 2)

What: the skill or gap, named honestly
What I learned: one sentence
Next step: what you'll do differently

Goals for next cycle (pick 1–2)

What: the goal
Measure: how you'll know it worked
By when: a date

Asks (pick 0–2)

What I need: the resource, access, or alignment
Why now: the reason it matters this cycle :::

Pick three wins, not seven. Pick two stretches, not five. The doc should fit on one page when printed. A maximalist doc is harder to use than a tight one — both for you in the meeting and for your manager copying from it later.

The meeting itself

Send the prep doc to your manager 24 hours before. That's not optional. It signals that you took the meeting seriously and gives them time to compare it to their own notes.

Open the meeting by referencing the doc. Walk the wins first, then volunteer one stretch area before they raise it. Self-disclosure on a stretch area is the single highest-leverage move in a first review — it shows you can see yourself clearly, which is one of the things calibration committees most reward.

When they raise something you didn't expect, don't argue in the room. Say "I want to think about that and come back to you" and write it down. Reviews aren't real-time debates; the doc gets finalized later.

After the meeting

Email a recap within 24 hours. Bullet the wins, the stretch areas you both agreed on, and any commitments from either side. Put dates on the commitments. That email is your record if anything changes.

Set a 90-day reminder to add to the doc. By next review you won't be reconstructing the year from memory.

Chart your industry's landscape (so you're not just doing tasks)

Mike Halpert — Tue, 25 Apr 2023 00:00:00 GMT

Doing your job well is good. Understanding the game you're playing is better.

In your first 90 days, you're trying to move from "new person completing tasks" to "teammate who understands how the business actually works." That shift doesn't come from having strong opinions. It comes from building a lightweight map of the industry so you can connect your tasks to outcomes.

The early-career feeling

"I can do the tasks, but I don't see the board yet."

You sit in meetings where people casually mention competitors you've never heard of, metrics no one defined, why some tiny change matters "because of regulation" or "because of pricing pressure." You nod. You do the work. But you're missing the context that makes people faster and more confident.

That's normal. It's also fixable in about two weeks.

What you're actually trying to answer

You're not trying to become an industry analyst. You're trying to answer four practical questions:

Who is the customer, and what do they actually care about?
Where does the money come from, and where does it leak?
Who are the real competitors and substitutes?
What's changing that could make today's plan wrong?

When you can answer those out loud, you start sounding switched on.

Step 1 — Sketch the value chain

Every industry has a sequence of steps that creates value. If you can draw it on a napkin, you can understand where your company makes money, where margins exist, where risk lives, and who the real competitors are.

Simple ecommerce example:

Manufacturers → distributors → platforms/marketplaces → marketing → customer → returns and support

Now ask: where do customers complain the most? Where does time get wasted? Where do costs spike? Those pain points are usually where strategy gets made.

Step 2 — Find the profit pools

Not all parts of an industry are equally attractive. Some are high-margin, some are a grind.

In plain language:

What do customers happily pay extra for?
What feels like a commodity?
Who gets squeezed in negotiations?

You don't need precise numbers. You need directional truth.

Step 3 — Track trends without doomscrolling

You don't need to read everything. You need a light cadence:

one industry newsletter, weekly
one "operator" source (blog or podcast)
one monthly deep read — earnings call notes, annual report, long-form piece

If your company or its competitors are public, earnings calls are free education. The legal disclaimers at the start are boring; the analyst Q&A at the end is where the real signal lives.

Step 4 — Regulation and macro

Even if you're not in legal, policy, or finance: privacy laws change product strategy, tariffs change supply chains, interest rates change budgets, major platform changes can rewrite distribution overnight. You're not predicting the world. You're learning what leadership cares about.

Step 5 — Ask better onboarding questions

These make you look prepared and give you usable answers.

Landscape:

"Who are our top competitors, and who are the quiet threats?"
"What differentiates us in one sentence?"
"What substitutes do customers use instead of us?"

Customer:

"Who is the target customer?"
"What job are they hiring our product to do?"
"What do customers complain about most?"

Business model:

"How do we make money — pricing, contracts, renewals, ads, services?"
"What metric do leaders obsess over?"

Internal reality:

"What's the biggest risk to the plan this quarter?"
"What does 'good' look like for my role?"

A two-week plan

Week 1: five conversations. Fifteen minutes each. Your manager. A teammate one or two years in. A cross-functional partner (sales, ops, support, finance). Someone close to the customer. Someone senior enough to see the strategy. Use a few of the questions above. Take notes.

Week 2: five sources. One industry newsletter. Your company's website and pricing page. A competitor's website and pricing page. An earnings call or annual report if public. A "how this industry works" explainer.

You're building a directional map, not defending a thesis.

The one-page template

:::template{title="Industry map"}

Customers

Primary customer:
What they care about:
Common pain points:

Value chain (rough)

Step 1:
Step 2:
Step 3:

Competitors / substitutes

Direct competitors:
Substitutes:
Differentiator (our one sentence):

Trends to watch

Trend 1:
Trend 2:

Metrics leaders care about

North star:
Leading indicators:
Red flag metrics:

:::

—

The peers who get promoted faster than you in years 2-4 aren't smarter. They've internalized the map you're trying to build right now. The map turns "I'm working on this thing" into "I'm working on this thing because of X, which matters because Y." That second sentence is the entire game.

For the weekly habit that turns context into decisions, use the Manager 1:1 agenda.

First Job Out of College

What to Actually Say in Your First 1:1 With a New Manager

What this meeting is actually for

Here is the move

Why these lines work

The part most people skip

If the meeting is weird

Burnout Early Career: The 5 Warning Signs You Shouldn’t Ignore

A hard week recovers. Burnout does not.

The five warning signs

Run the signal check before you talk yourself out of it

What to say to your manager

When the script is not enough

Catch the smoke

Turning a Fuzzy Career Goal Into a 12-Week Action Plan

A goal without proof becomes theater

Translate the fuzzy goal into a work outcome

Use 12 weeks because it is hard to fake

Copy this 12-week plan

Separate reps from proof

When this plan does not apply cleanly

The move

The One-Page Memo Template That Makes You Look Senior

The misunderstanding behind every long memo

A scar from earlier in my career

The template

The pre-read script

Why one page is a thinking constraint, not a writing constraint

What goes in the appendix

When this doesn't fit

Reading Your Manager: How to Tell If They Want Detail or a Headline

What you're actually doing

What the manager is trying to do

What good looks like

What bad looks like

Four signals to read before any update

Three modes, not two

The two-line opener that protects you when you can't tell

The longer arc

Further reading

When a Peer Takes Credit for Your Work: 3 Responses, From Subtle to Direct

Response #1 — Subtle: re-attach your name to the artifact

Response #2 — Direct but private: ask, don't accuse

Response #3 — Up the chain: escalate with documentation

When the ladder bends

A Script for the "I Think You Dropped the Ball" Conversation

“Dropped the ball” is a character judgment

Start with a prep note, not a speech

The script to use

Why this works

If you are new, use the softer version

When to skip the peer script

Slack Etiquette 101: The Channels, Threads, and DM Rules Nobody Documented

TL;DR

Rule 1: Channels Are Public by Default

Rule 2: Threads for Every Reply

Rule 3: DMs Are for Private or Quick Only

The Slack Etiquette Checklist

When These Rules Don't Apply

One Thing to Do Today

Further reading

How to Ask for Help Without Sounding Helpless (The 3-Part Ask)

Part 1: The context

Part 2: What you tried

Part 3: The specific ask

Why this actually works

What not to do

The template

The coffee-chat script that isn't creepy

The script

Why this works

What doesn't work (and why)

What to actually do in the 20 minutes

The follow-up note

The medium-term follow-up

First 1:1 with a new manager: the exact agenda

What a new manager is actually trying to figure out

The 30-minute agenda

0–5 min — Quick context

5–10 min — Three questions for them