Remote Work, Communication and Working With Managers

In an office, a lot of communication is free. You see that a teammate looks stressed. You hear a hallway talk. You catch your manager at the coffee machine. In a remote team none of that happens. If you do not write it down, it did not happen. This lesson teaches the habits: asynchronous (async) communication, writing updates, one-on-ones, "managing up" (helping your manager help you), handling disagreement, and asking for feedback. You get complete message templates you can copy.

This is lesson 8 of 9. Before it: salary and offers. After it: the mock interview and your one-week plan. For the manager's side of the same topics, read Team Lead lesson 8 on 1:1s and feedback, Team Lead lesson 10 on status updates and meetings, Team Lead lesson 5 on writing things down, and Team Lead lesson 17 on culture and safety.

Words used in this lesson

• Asynchronous (async) means people do not need to be online at the same time. You write, they read and answer later.
• Synchronous (sync) means live: a call, a meeting, a quick chat conversation where both people are present.
• Status update is a short message that says where your work stands.
• Blocker is something that stops your work and that you cannot fix yourself.
• One-on-one (1:1) is a regular private meeting between you and your manager.
• Managing up means helping your manager do their job well by giving them what they need, so they can help you.
• Escalate means to bring a problem to someone with more power to solve it.
• Disagree and commit means you say your honest view, and then after the decision is made, you support it fully.
• Time zone overlap is the hours when two people are both in working hours.
• Handover is a document or talk that passes your work to someone else.
• Psychological safety is the feeling that you can say a mistake or doubt out loud without being punished.

Why interviewers ask about this

Look at the focus areas in the Tech Interview Handbook's behavioral rubrics page: proactivity, working in an unstructured environment, conflict resolution and empathy, growth, and communication. Remote work and manager questions test almost all of them:

• "How do you stay in touch with your team when you work remotely?" tests communication and proactivity.
• "Tell me about a time you disagreed with your manager." tests conflict resolution and empathy.
• "How do you like to be managed?" tests self-knowledge and growth.
• "How do you handle unclear tasks?" tests the ability to work in an unstructured setting.

Good answers are specific. "I communicate well" is empty. "I write a short update every Monday with three lines: done, next, blocked" is real.

Async communication: the basic rules

One company's public handbook (37signals, which I read) describes its way: collaborate as if most things you ask will be answered eventually, but not this second. Their first choice is to post a message, a task or a document, so the other person can read it when they have a gap in their day and not in the middle of deep work. Live tools (a call, a screen share) exist for the cases where writing is too slow, and they say those cases should be rare. This is one company's culture. Other teams use more meetings. But the ideas are useful anywhere:

1. Write so the reader does not need to ask you a follow-up. Include context, the question, what you already tried, and what you need by when.
2. Put the main point first. Not the story. "I need a decision on X by Thursday" before the history.
3. One topic per message. Mixed messages get half-answered.
4. Say what kind of reply you want. "FYI, no reply needed", "please approve", "I need your opinion".
5. Use the right place. A decision goes in a document or ticket, where people can find it later, not only in a chat thread that scrolls away.
6. Be kind in text. Words without a tone can sound harsh. Add a short friendly line. Avoid sarcasm.
7. Do not expect an instant reply, and do not make your urgent thing look like everyone else's. If it is truly urgent, say "urgent" and why, and use the channel your team agreed for emergencies.

Bad and good: asking for help

A bad message (very common):

hey

(The person then waits for "hi" and then "can I ask a question?" and so on. It wastes both sides' time.)

A good message:

Hi Dana, I'm stuck on the invoice export (ticket 412).Problem: the CSV is empty when the customer has more than 500 rows.What I tried: I checked the query (it returns rows), and the exportfunction (it works for 100 rows). I think the paging in export.tsis wrong, but I'm not sure.Question: do you know if the export is supposed to handle paging, oris it a known limit?I'm moving on to ticket 415 meanwhile. If you have 10 minutestomorrow morning I'd love to look at it together.

Why it is good: the reader has all context. It shows you tried. It says what you do while waiting (you are not blocked). It offers a live slot. A reply can be one line.

Rule of thumb: the 30-minute rule for being stuck

I use this: if I am stuck for 30 minutes with no new idea, I write the question in a message (the act of writing often solves it). If it does not, I send it. Not asking for hours is a bad habit, and so is asking after two minutes. Adjust the numbers to your seniority and your team's expectations. This is my rule of thumb and not a research finding.

Writing good updates

An update tells the team and your manager where things stand without a meeting. The 37signals handbook describes two such check-ins: a short post every afternoon about what you worked on (with some context about why), and a plan every Monday for the week. You may not have those, but you can do the same on your own.

Template: weekly plan (Monday)

Week of 12 October, plan from JordanGoals this week:1. Finish the invoice export fix (ticket 412). Done when: exports work for 5,000 rows.2. Review two pull requests from Sam.3. Write the design note for the new reports page (draft only).Risks / needs:- For goal 1, I need access to the staging database. I asked IT on Friday.Not doing this week: the refactor of the settings page (moved to next week).

Template: weekly summary (Friday)

Week of 12 October, summary from JordanDone:- Invoice export fixed and released (paging bug). Customer reports should stop.- Reviewed 2 pull requests.Not done:- Design note for reports page: draft is 60 percent. Finishing Monday.Learned / notes:- The paging bug came from the same helper used in 3 other places. I added a ticket to check them (ticket 430).Next week: finish the design note, start the reports page.

Template: short status for a task that is late

The best time to say a task is late is as early as you know, not on the due date. A good message has: what is the status, why, the new date or range, what you need, and the options.

Subject/Title: Reports page, risk to Friday dateStatus: about 70 percent done. The API is ready, the page works fornormal data.Problem: I found that the date filter is wrong for users in other timezones. Fixing it properly needs changes in two places.New estimate: Tuesday or Wednesday next week (a range, not a promiseuntil I finish the test).Options:  A) Ship Friday without the date filter (users can still see the report, just no filter).  B) Wait until Tuesday/Wednesday and ship everything.My recommendation: A, then ship the filter next week.Need from you: a decision by Thursday noon.

This follows the same shape as the team lead lessons on estimates and status updates: a state, a range with named unknowns, options, and a clear request.

Writing for decisions: the short note

When something needs a decision or has trade-offs, a short note is better than a long chat. Five parts:

1. Context. One or two sentences.
2. The decision needed. One sentence.
3. Options. Two or three, each with pros and cons.
4. Recommendation. One sentence with a reason.
5. Deadline and who decides.

Example:

Decision: how to store user avatarsContext: users can upload a picture; today we store the file on the app server.Need: pick a storage option before we add a second server (end of month).Options:  1) Keep files on the server. Simple, but a second server cannot see the files.  2) Use object storage. Small cost, works with many servers, needs a code change (2 days).  3) Store in the database. Easy to back up, slows the database for big images.Recommendation: option 2. It solves the real problem and the cost is small.Decide by: Friday. Decider: Dana (tech lead).

For the bigger version of this habit (design docs and RFCs) see Team Lead lesson 5.

Meetings in a remote team

Fewer, better meetings. A few simple habits:

• Have an agenda and send it before. If there is no agenda, ask for one.
• Take notes and share them with decisions and owners. "Who does what by when."
• Camera and mute: follow your team's habit. Use mute when not speaking.
• Time zones: write times with the zone, for example "15:00 UTC" or in the other person's zone. Don't assume.
• Overlap hours: if the team is spread over many zones, protect a few hours of overlap for live talks and do the rest in writing.
• Do not interrupt on a video call. Delay makes it worse. Pause a little longer before you speak.
• Record or note decisions for people who could not come.

One-on-ones

A 1:1 is your regular time with your manager. It is your meeting as much as theirs. Many people waste it on status updates they could write. Use it for the things that are hard to write: priorities, concerns, feedback, growth, and how you are doing.

What to prepare (agenda template)

Keep a shared document with one section per meeting. Before each 1:1, add your points:

1:1 with Dana, 14 October1. Quick wins since last time (2 min)   - Export fix released; customers say it works.2. Where I need help or a decision (10 min)   - Priority between the reports page and the settings refactor.   - I am waiting for access to the staging database (2 weeks).3. Feedback (10 min)   - Anything I should start, stop or continue? I'd like feedback on the way I review pull requests.4. Growth (5 min)   - I want to lead a small project in the next quarter. What would you need to see from me?5. How I'm doing (3 min)   - Workload is high this week because of the incident; I may need to move one task.Actions from last time:   - [x] Dana: ask about training budget.  - [ ] Me: send design note.

Habits that help:

• Same time each week or two weeks. If your manager cancels often, ask kindly to keep it. It is a signal about priorities.
• Take notes and write down actions with owners.
• Raise problems early. A 1:1 is the place to say "I'm concerned about the deadline" while there is still time.
• Ask for feedback every time, not only at review time.

If your manager runs no 1:1s at all, ask: "Could we set up a 30-minute meeting every other week so I can check in on priorities and feedback?" Most managers say yes.

Managing up

"Managing up" sounds like politics, but it just means: make it easy for your manager to help you and to make good decisions. Your manager has many people and limited time. What do they need from you?

1. No surprises. The worst thing a manager hears is bad news from someone else. Tell them first, even if it is small. A short message "heads up, this might slip" is enough.
2. Clear status. They should be able to answer "how is X going?" in 10 seconds because you told them.
3. Problems with options. Not "this is broken" but "this is broken; here are two options and my recommendation".
4. Clear asks. "I need your decision by Thursday" or "I need you to talk to the other team".
5. Understanding of their goals. Ask: "What are your top three priorities this quarter? How can my work support them?" Then connect your work to those.
6. Your preferences. Tell them how you like feedback (written or spoken, direct, in the moment or in the 1:1), how you work best (long focus blocks), and what you want from your career.

Script: bringing bad news (complete, spoken or written)

Suppose you broke something in production (made-up). Say it quickly, calmly, with facts and a plan.

Dana, I need to flag something. About 20 minutes ago my release changedthe way we calculate tax, and for some invoices the total is wrong.It affects about 40 invoices so far.I've rolled back the change, so new invoices are fine.Next: I'm listing the affected invoices now, and I'll write a scriptto fix them. I'll send you the list and a plan within an hour.I'll also write a short post-incident note, and add a test for thiscase so it cannot happen again. Do you want me to tell support, or will you?

Why it works: facts, impact, what you did, what you do next, a time, and a clear question. No blame, no excuses, no hiding. See Team Lead lesson 4 on incidents for the team view.

Script: pushing back on a request (when you are overloaded)

Hi Dana, thanks for thinking of me for the new dashboard.Right now I'm committed to three things: the export fix (due Friday),the reports page (due the 28th) and two code reviews. If I take thedashboard, I think something has to move. Which would you prefer:  A) I do the dashboard first and the reports page slips by one week.  B) I do the dashboard after the 28th.  C) Someone else takes the dashboard.I'm happy to help with whichever one you choose.

This is not "no". It is a choice shown to the person who owns priorities. It says what you can do, and it makes the trade-off clear.

Script: asking for an extension on a task

Hi Dana, I want to flag that the reports page might not be ready onFriday. It is about 70 percent done, and I found the date filter bugthat needs changes in two places. I'd like to ask for until nextWednesday to finish and test it. If Friday is firm, I can shipwithout the filter and add it next week. Which would you prefer?

Script: asking for feedback (to your manager or a colleague)

Asking for feedback is a growth habit, and a typical interview question too ("how do you handle feedback?"). Make it specific. "Any feedback?" gets "No, you are fine". Specific gets real answers.

To a manager (written):

Hi Dana, in our next 1:1 I'd like 10 minutes on feedback. Two thingsin particular: (1) how I explain technical decisions in design reviews(I felt I talked too long on Tuesday), and (2) whether my pull requestsare the right size for reviewers. What should I start, stop or continuedoing? A few examples would help me a lot.

To a colleague after a project (spoken):

After a rejected interview (to a recruiter):

Subject: Feedback request, Backend Developer interviewHi Priya,Thank you for letting me know, and for the chance to interview. Ilearned a lot from the process.If it's possible, I'd really appreciate any short feedback on where Icould improve: for example in the coding round or the way I explainedmy past projects. Even one or two sentences would help. I understandif it is not something you can share.Thank you again, and I hope we stay in touch.Best,Jordan

Many companies will not give detailed feedback (legal and time reasons). Don't argue, don't ask twice, and say thank you for what you get. Then treat every piece of feedback as data, even if it stings. If you get feedback you disagree with, do not defend it in that moment. Say "thank you, I'll think about it", and check it later with a calm head.

Handling disagreement

You will disagree with someone: a teammate about a design, or your manager about a deadline. Interviewers love this topic (see the conflict stories lesson). In remote teams, disagreement often turns bad because text hides tone. A few rules:

1. Assume good intent. Start by believing the other person has a reason.
2. Ask to understand first. "Can you tell me more about why you prefer option B?"
3. Separate the idea from the person. "I'm worried about the cost of this approach" not "you always pick complex solutions".
4. Move to a call when text heats up. If you have written three replies each, switch to a short call, then write a summary after. Do not argue by chat for hours.
5. Use data when you can. A small test or a measurement beats opinions.
6. Write the decision and the reason. In a ticket or a doc.
7. Disagree and commit. After the decision, support it. If you were wrong, you learn. If you were right, don't say "I told you so"; say "the risk we talked about happened. Here is a fix."
8. Escalate in the open and with warning. If you cannot agree, tell the other person: "We are not aligned. I'd like to ask Dana to help us decide. Is that okay?" Don't go around them.

Script: disagreeing with your manager (complete)

Dana, I want to share a concern about the plan to ship the reportspage on Friday. I understand the customer deadline is important.My concern is that the date filter is not correct for users in othertime zones, so some customers could see wrong numbers. I think wrongnumbers are worse than a late page.I would suggest we ship Friday without the filter and say so in therelease notes, then ship the filter next week.You know the customer situation better than I do. If you still preferto ship everything on Friday, I will support it and prepare a quickfix for the filter. I just wanted you to have this information beforewe decide.

Notice the pattern: respect the goal, state the risk with facts, offer an option, accept that the manager decides, and promise to support.

Script: giving a teammate hard feedback (short)

Sam, can I share something about the code reviews? I noticed that thecomments on my last two pull requests were mostly about style andcame after two days. I'd like to get faster feedback on the designearlier. Could we do a short call before I start big changes, andcould style stay with the linter? I'm happy to take on some reviews to help.

Remote habits that build trust

• Be reliable in small things. Reply when you said you would. Show up on time. Keep promises.
• Be visible, but not noisy. Share your progress. Write down what you learned. Answer others' questions.
• Over-explain in writing at first. New to the team? Say more than you think you need.
• Have a routine. Start time, end time, breaks. Tell the team your hours.
• Protect your focus. Use status messages and blocks in the calendar.
• Protect your rest. The 37signals handbook says they limit hours and take time off to make up for emergencies. Whatever your company says, decide your boundaries and say them: "I'm offline after 6 PM unless it's an emergency".
• Care about people. Short messages that say thanks, praise good work in public, say sorry when you make a mistake.
• Meet in person when you can. If your company has meet-ups, go. A few days together help months of remote work.

The first 90 days in a new remote job

A plan to tell in an interview ("how do you start in a new team?") and to use:

1. Week 1: set up tools, meet people, ask your manager: what does success look like at 30, 60 and 90 days? Write the answer down. (The 37signals handbook says a new hire gets expectations and frequent feedback in the first weeks; I do not know whether yours does, so ask.)
2. Weeks 2 to 4: ship a small change to learn the process. Write down every confusing thing in setup docs, and fix the docs.
3. Month 2: own one small area. Ask for feedback at the 30-day mark.
4. Month 3: take a clear, small project. Share a short summary of what you learned and what you would change.
5. Always: ask many questions in public channels so the answers help the next person.

Try it

Exercise. Your manager Dana asks in chat: "Is the reports page going to be ready Friday?" You know it is 70 percent done and a bug (time zones in the date filter) needs two more days. Today is Wednesday.

1. Write a reply of 6 lines or fewer.
2. Add the one-sentence ask you would put in your next 1:1 to avoid this surprise.

Sample answer.

1. "Short answer: probably not the full page. It's about 70 percent done. I found a time zone bug in the date filter that needs about two more days, so the full page would be ready Tuesday. Option A: ship Friday without the filter. Option B: wait until Tuesday. I recommend A. Can you let me know by tomorrow noon?" (Six lines: answer, status, reason, estimate, options, recommendation and ask.)
2. "Can we agree that when I see a risk to a date, I send you a heads-up message right away, even before I know the new date?"

Another test: say the answer to "How do you like to be managed?" in your own words in 30 seconds. A sample: "I like clear goals and then freedom to decide how to do the work. I like a weekly check-in, and I like direct feedback soon after something happens, written or spoken. I will always tell you early if something is going wrong."

Interview questions

Key takeaways

• Remote work means writing. If it is not written, it did not happen. Put the main point first, include context, ask a clear question.
• Short regular updates (Monday plan, Friday summary) make your work visible. Tell bad news early, with status, a range, options and a recommendation.
• A 1:1 is your meeting. Prepare an agenda, ask for feedback each time, and write down actions.
• Managing up is making it easy for your manager to help you: no surprises, options with problems, clear asks.
• Disagree with facts and respect. Say it once, then disagree and commit. Move heated chat to a call, and write down the outcome.
• Set your hours and keep them. Ask for specific feedback and treat all feedback as data.

What's next

The last lesson puts everything together: a full mock behavioral interview with scoring and a one-week preparation plan. For the manager's view of the same habits, see Team Lead lesson 8 and Team Lead lesson 10.