I once found out about a decision in a very ugly way.
I exported a spreadsheet to CSV, imported it into a project, and handed it to my AI agent to build me a slide out of the data. The slide came back wrong.
Not broken, just wrong: the numbers on it did not match the plan our whole group had agreed on weeks earlier.
My first thought was that I had messed up the import. My second thought was that my AI agent was hallucinating, which by now is most people's second thought about everything.
It was neither.
The data was right, the AI agent was right, and the slide was an accurate picture of a decision somebody had made on their own and never mentioned to the rest of us.
I trusted a LLM less than I trusted my colleagues, and the LLM turned out to be the reliable one that day.
The reason that stuck with me is that nothing about it was a skill problem. Everybody involved was good at their job.
Somebody made a call, had a reason, and the step where you tell everyone else fell off the list. That is what most team problems look like from the inside. Not incompetence. Information that existed in one head and never moved. You will spend your career being judged on how well you write and how well you explain, and almost nobody gets taught either.
So here are the ten rules I would give a student joining their first real team.
1. Say the point first, then the explanation
The most common junior habit is telling the story in the order it happened. You start with what you were doing on Monday, walk through everything you tried, and put the actual news in the last sentence.
By then the person reading has skimmed to the bottom, guessed, and guessed wrong.
Put the conclusion in the first line. Then the detail, for whoever wants it.
"The deploy is failing on staging since this morning. I think it is the new environment variable, I need twenty minutes with someone who has access to the keyvault."
That is a complete message.
The person reading it knows what happened, what you think, and what you want from them, before they decide whether to open the thread at all. Compare it to three paragraphs that end with "so I was wondering if maybe someone could take a look?".
This is not about being blunt. It is about respecting that the person on the other side has 40 unread messages and yours is one of them.
2. Never send "Hi" and then nothing
You know this one. A message arrives that says "Hi".
That is the whole message. Somebody is typing, or worse, not typing, and you are now sitting there with your work paused, waiting to find out what you have been volunteered for.
Then you answer "hi, what's up?" and wait again.
Two people are now blocked on a conversation that has not started. There is a website called nohello.net that exists purely to explain this, which tells you how common it is.
It feels polite but it is not.
You have taken the ten seconds it would have cost you to work out what you actually want, and handed it to somebody else as an unknown interruption sitting in their day.
They cannot go back to what they were doing, because there is a question coming and they do not know how big it is.
Greeting and question in one message. "Hi, do you have 5 minutes today to look at why the staging build fails? No rush, tomorrow works." Nobody has ever been offended by that.
The same category: "can I ask you something?", "are you free?", "quick call?" with no subject.
Say what it is about and roughly how long it will take, and let the person decide when. And if you are sending a meeting invite, put the reason in it.
An invitation with no agenda is the same message as "Hi", except it also took an hour of somebody's calendar.
3. Write for the person who was not in the room
When you report a problem, you are sitting on a pile of context that nobody else has.
You know which branch you are on, which environment you were testing, which customer complained, and what was said on yesterday's call. Whoever opens your message knows none of that.
Most of writing well at work is handing over the parts that only exist in your head.
"It does not work" is not a report.
What does not work, since when, on which machine, environment, device model, browser, what did you expect to see, what did you see instead, and what is the exact error log. Paste the error. Do not describe the error. Link the file, link the message you are replying to, link the ticket.
This matters more every year, because most of your communication is now read hours later by somebody who cannot tap you on the shoulder to ask what you meant. Every missing detail is hours long round trip.
The habit that fixes it is, before you send anything, read it once as somebody who just came back from two weeks off.
4. Repeat back what you understood before you start
You get a task in a meeting. It sounds clear.
You go build it for 3 days, and on Thursday it turns out that everybody meant something slightly different and you built the slightly different thing.
The fix takes 10 seconds.
Before you start, write one short message: this is what I understood, this is what I am going to do, this is when I think it will be done, tell me if that is wrong.
9 times out of 10 you get a thumbs up and nothing changes. The tenth time saves your week.
Of everything on this list, this is the one habit I would want a new colleague to have.
It also does something for bonus points.
It tells the person who assigned the work that they can hand you things without following up, which is most of what people mean when they call somebody reliable.
5. Ask questions somebody can actually answer
"Does anyone know how this works?" is not a question. Nobody can answer it, so nobody does, and then you conclude that people are unhelpful.
A question people can answer has 4 parts: what you are trying to do, what you tried, what you expected, and what happened instead. Put all four in one message.
Half the time you will find the answer while typing the third part. That is rubber duck debugging, it has a name because it happens to everyone, and it is nothing to be embarrassed about.
The other half of this rule is timing.
Most students I have talked to are scared of asking too early and looking incapable, so they sit on it for 2 days.
An hour of being stuck is normal and nobody will remember it. Two days of silence followed by "I could not figure it out" is the thing people remember.
Pick a limit before you start, 45 minutes, an hour, whatever fits the task. When you hit it, ask. Stuck for an hour is a question. Stuck for two days is a status report, and a bad one.
6. Bad news does not age well
Something is going to slip. That part is not interesting, it happens to everybody, on every project, forever.
What people actually judge you on is when they hear about it. Say it on Tuesday and there is still time to move something, drop something, or get you help.
Say it on Friday afternoon, and there is nothing anyone can do except be annoyed with you.
The instinct is to wait until you have a solution, because arriving with a problem feels like failing in public. You are not being brave, you are quietly spending time that belongs to other people.
A problem raised on Tuesday is a plan. The same problem on Friday is an incident.
And when you raise it, bring what you know: what is blocked, what you have tried, what you think the options are, what you need. Not a solution, just the shape of the problem.
7. Match the channel to the message
Chat is for quick things. A document is for decisions. A call is for discussion.
The reason to care is that most of the worst arguments I have seen at work were reasonable people who used the wrong channel.
Written text has no tone. Yours will be read in the mood of whoever opens it, and the shorter you write, the more room they have to fill in a tone you never meant.
The practical rule: when a thread has gone three rounds without getting closer, stop typing and get on a call. Ten minutes of voice will finish it.
Then, and this is the part people skip, go back to the thread and post the two lines about what you agreed. The people who were reading and not typing are still waiting to find out how it ended.
8. If it changes something the group agreed on, it is not yours to decide alone
Now the rule from my slide story.
Groups do not agree on things for fun. An agreement is a constraint, and every decision after it gets made inside that constraint. People turned down good options because of it. Somebody said no to something they wanted because of those rules.
Change it quietly and you have not changed one thing, you have invalidated every decision the rest of the group made underneath that.
There is a second effect that people underestimate.
Everybody compares.
Not out of pettiness, they compare because it is the only way to know whether the rules are the same for everyone.
And "nobody complained" is not agreement. When nobody pushes back on something that affects them, the likeliest explanation is that they never saw it.
Announce it, it is a change and it is over in 10 minutes.
If somebody finds it, it becomes a question about what else got decided that way, and that question spreads to things you did nothing wrong on.
9. Answer within a day, even when the answer is "not yet"
Do not ghost people inside your own company. I do not care how busy you are, and I say that as somebody who is busy.
Almost nobody does it on purpose. You read the message, you want to give a proper answer, you decide to reply when you have 20 free minutes, and those 20 minutes never arrive.
A week later the message is old enough that replying feels awkward, so you do not. From the outside that looks exactly like being ignored, and there is no way for the other person to tell the difference.
Meanwhile they are stuck. They do not know if you saw it, if it is even your area, if you disagreed, or if they should ask somebody else.
So they either wait and lose days on something you could have unblocked in one line, or they start asking around, and a simple question quietly turns into a small political event about who is not responding to whom.
One working day.
That is the rule. Not one day to solve it, one day to reply.
And the reply can be almost nothing: "Saw this. I cannot get to it before Thursday. If that is too late, tell me and I will find somebody else."
Three parts: I have seen it, here is when, here is your escape path if my timeline does not work for you. It takes 15 seconds and it turns an unknown into a plan.
This matters most with people junior to you.
If you ever end up mentoring somebody, it is the rule to remember. A student or a new colleague will not chase you twice. They will assume they asked a stupid question, or that they are not worth your time, and they will stop asking.
You will not notice you lost that channel, because what you lose is the messages they never sent.
10. Close the loop
Most threads about a problem never get a last message. It gets fixed on a call, or in a DM, or by somebody quietly editing a file, and the thread where 12 people watched it happen just stops.
So half the team is still working from the broken version and the other half thinks it was dropped. You solved the problem and kept the confusion.
This is the same rule at every scale. Somebody helps you, tell them what worked.
A decision changed back, post it in the same place you posted the first version. What changed, who decided, when it applies. You never know if someone will search for that exact issue or information after 2 years.
It takes 30 seconds and it is the difference between a team that trusts its own channel and a team where everyone keeps a private copy of the truth.
What to do in your first week on a team
Find out where decisions actually get announced. Every team has a place where the group really reads.
Then pick 2 rules off this list and do them on purpose until they stop feeling like effort.
If you want my recommendation: rule 4 and rule 6. Repeating back what you understood, and saying early when something is going to slip.
Those two alone will put you ahead of people with more years than you, because most people never do either.