How to introduce yourself to a new team in writing

A good intro message says what you will be working on, when you are around, and what you need from people this week. Three things. Most intros give a career summary instead and answer none of them.

It is a small piece of writing with strange leverage. It is the first sample of your thinking that the whole team sees at once, and it quietly sets what people expect from every message you send after it.

Nobody is reading it for your history

Your new colleagues read an intro to work out one thing: what changes for them.

They want to know whether you take something off their plate, and whether you are in their meetings now. A list of former employers answers neither. Nobody in that channel got a vote on hiring you. The decision is done, and reopening the case for it is a strange way to say hello.

Keep the background to a line or two. More than that starts to read as a pitch, which is the one tone you do not want on day one.

I learned this from the other side of it. The first thing I wrote publicly about Unvent led with how I built it and why. It sank. Nobody was rude about it. It simply produced nothing, which is worse than being argued with. The version that got replies opened with something people already did most days, which was firing off a message and then wishing they had said it differently.

Same product. Same person writing it. What changed was the subject of the first sentence.

In the version that failed, the subject was me. In the version that worked, the subject was the reader's Tuesday. Your intro has that problem in a smaller frame. You get roughly one sentence where everyone is definitely still reading, and you can spend it on your last job or on their week.

Describe the work people can hand you

Describe your job as the work people can hand you. The title on your offer letter can wait.

"Platform Engineer II" gives your team nothing they can act on. "I look after the deploy pipeline and the on-call tooling, so if a deploy is stuck, send it to me" tells them exactly when to type your name. A title claims seniority. A scope line claims usefulness, and only one of those gets tested in your first week.

Use the words the team already uses. Every company has a private vocabulary for its own systems, and you probably learned the official version in onboarding. If everyone in chat calls it the billing box, call it the billing box and you sound local. Use the name from the onboarding deck and you sound like a visitor.

Make replying cheap

An intro should hand people the small practical facts they would otherwise have to ask for one at a time.

• Your name as you want it written, and how to say it if it tends to get mangled.
• One line on what you will own, in the language the team already uses.
• The hours you are usually online, with a time zone attached.
• Where to reach you for something quick, and where for something that needs a real answer.
• One thing you would like this week, like access to a system or a walkthrough of it.

The time zone matters more than it looks. A lot of the daily friction on a distributed team is people quietly guessing at each other's clocks, which is why writing across time zones ends up being its own skill. Put the number in and skip a week of guessing.

End with one real question

Finish with a single specific question, because an intro with nothing to answer collects acknowledgements and stops there.

A wave costs nothing to send. I have defended the small emoji elsewhere and I would again, since as an acknowledgement it does honest work. It still leaves you in a channel where six people have noticed you and none of them has spoken to you.

So ask something small enough to answer in one sentence and interesting enough to be worth the reply:

• Which document here lies the most?
• What does everyone know that nobody has written down?
• What would you fix first if you got a free afternoon?

You get replies, and you get the map onboarding never includes. Where you put the question matters as much as the question, which is most of what makes the last line of a message the part that does the work.

Match the room before you decorate it

Match the team's existing level of formality in your intro first, then add your own voice on top of it.

Read the last twenty messages in the channel before you write. If people there send lowercase fragments, five paragraphs with headers arrive like a costume. If they write full sentences and greet each other by name, a two-word "hey all" reads as careless. This is week one. You have no read yet on which of your habits land here.

Warmth also runs about a notch cooler in text than you intended, which catches out friendly people constantly and is why your chat messages read angrier than you think. Compensate by one notch. One human line is plenty: something you actually like doing, rather than a fun fact produced under pressure. Fun facts are a tax on everyone in the room, including the person paying it.

Then post it once, in the channel the team already uses. The day-one instinct is to cover everything: the team channel, then the wider announcement channel too. It feels thorough. On the receiving end it looks like somebody announcing themselves twice. Keep direct messages for people with a reason attached, like whoever is about to hand you a project. An org chart is not a reason.

The introduction that counts is in week two

People form their working opinion of you from your ordinary messages, and those start the morning after the announcement.

Your first question in a channel says more about you than the intro did. So does your first "I do not know yet." Those arrive when something is at stake, which is when people are paying attention anyway.

So write the short one, and put a real question at the bottom of it. Then go and answer somebody else's question properly, in a thread nobody was watching. That is the introduction people keep.