People

You can catch more flies with a spoonful of honey than with ten liters of vinegar.

–Anonimous, Spanish saying

Onboarding

Sadly, most companies fail on this topic. Sometimes the reason is lack of resources, and other times it is simply not giving onboarding the importance it deserves. In reality, this is crucial for your teams’ and your company’s future productivity.

Think about onboarding as a productivity accelerator. The sooner the new joiner understands the context, the product or service, and the expectations, the sooner they will become productive and integrated. Most companies have a probation period, but it is unfair to evaluate anyone who never had a real chance to understand the role and how to succeed.

Starting in a new company is like starting a new relationship: both sides need to get to know each other, align expectations, and feel some kind of “this was a good decision.” In companies, most of that impression is formed during onboarding, and you only get one chance to create it, so take it seriously.

As a new joiner, you should expect attention, information, and clarity, but you must also bring interest, curiosity, and a genuine effort to integrate.

As a company

When I say “company,” I mean HR, the manager, and the team working together. HR handles contracts, policies, and basic orientation. The manager owns expectations, performance, and integration into the team. The team supports the day-to-day, answers questions, and makes the person feel welcome.

The onboarding plan should be an integral and important part of your standard procedures; it has a preparation for the onboarding, an onboarding phase, and a post onboarding check. Let’s talk about it.

Preparation for the onboarding

This is the easiest part, yet many companies fail in the preparation. This should include:

• Hardware assets: It is unacceptable that a new joiner starts without the basic tools ready: computer, phone (if needed), access card, and a prepared workspace. Also assign someone to receive them on the first day.
• Welcome message: Before the starting day, the new joiner should receive a welcome message with specific instructions for the first day and a short overview of what to expect in the first week.
• Permissions: Ensure this person has an active account and the required access to email, chat, documentation tools, code repositories, and ticketing systems.
• Context Documentation: Prepare an org chart and initial documents to provide the first context: team structure, main stakeholders, and links to key documentation hubs.
• Select a Mentor: Designate a person with enough experience to be the buddy/mentor of the new joiner, answering basic questions and walking them through the company premises (or systems, in remote teams). When possible, choose someone with a similar cultural or language background to ease the first days.
• Day-one agenda: Share a simple schedule for the first day (who they will meet, at what time, and where or which links to use), so the new joiner does not spend the day guessing what to do.

Onboarding Plan

Learning and setup

The first week is the settling-in week, the time to make the first references, and consolidate the idea that it was a good decision to join the company. This is the time to explain the company’s mission, where this person fits in the team structure, the ways of working, and the communication channels. If there are decisions to make, like deciding between the options the company benefits offer, this is the moment to make them.

During the week, you should schedule meetings with this person’s manager or team lead to review the role expectations, how this person is going to be evaluated, and what the first expectations in terms of deliverables you have, if any. Review the tools the company issues and inform about the workflows, restrictions, and security rules the company has.

As soon as possible, introduce the new joiner to the assigned buddy or mentor, and encourage them to have a coffee to start in a less formal way and get to know each other. Buddies with cultural, language, or age similar to the new joiner will help with this step.

For remote or hybrid teams, over‑communicate: send calendar invitations for every session, share notes afterwards, and turn cameras on to help build early connection.

The following three weeks are the right time to move from context to actual production topics. Along with the team, have a more informal meeting where everyone can introduce themselves, explain what they are working on, and give a short historical context to understand where they come from and where they want to go. During this time, no significant production should be expected. It is primarily “understanding time” through shadowing experienced teammates and joining regular meetings to get up to speed.

During this time, someone in the team, ideally the mentor or buddy, should introduce a small real task. They will provide close support, review the work done, clarify what was not clear, and help fix possible mistakes.

By the end of these three weeks, the first month will be completed, and a quick check-in should happen with the manager. This is a critical part of the onboarding, but also of the people management in general, good, recursive, and constructive feedback.

Guided contributions

By this time, you should start having the perception of whether the new joiner fits in the team or if there are some issues. In any case, nothing is final, but this is a great moment to list your concerns or clarifications, to be commented on in the next 1:1. Do not wait until the end of the probation period to surface issues. Bring them early to your 1:1s so they can be addressed.

During this second month, the main goals are:

• Increase ownership with medium-sized tasks or a small project.
• Deepen training on tools, architecture, processes, or domain knowledge.
• Review progress against goals and adjust the plan if needed.
• Ask for feedback on onboarding so far and improve weak spots early.

The main objective of this phase is to get the needed information about the progress and the joiner’s feelings. Also, regular weekly meetings with the team to get feedback on how the integration is going are crucial, not to make a decision about the continuity, but to raise any issues as soon as possible so they can be mitigated and have the smoothest onboarding possible.

At the end of the period, again, the manager should have a complete feedback session with the employee to summarize the status of the process and ensure the company is fulfilling all the expectations. Pay attention to psychological safety: a new joiner who never asks questions or disagrees might be scared, not fully aligned.

Independence and ownership

The last part of the onboarding could be considered the take-off for the new joiner. Consolidation of the expectations for the role and level, integration into the team, commitment to the project and the company, and quality and value of the production. To be able to make it happen, it is essential to follow these steps:

• Give the person clearer independence and end-to-end responsibility.
• Confirm they understand priorities, quality standards, and team expectations.
• Do a formal 90-day review on progress, gaps, and next growth steps.
• Close onboarding with a plan for the next quarter, not just a “welcome done” moment.

By the end of this last onboarding part, the new joiner is not going to be a new joiner anymore, but a team member in all aspects. That is why it is so important to do a correct closing onboarding to avoid any confusion, uncertainty, or misunderstanding, and put them “to work”. In the 90-day review, avoid vague “you’re doing fine” feedback. Bring concrete examples of delivered work, collaboration moments, and remaining gaps, and agree on 2–3 development goals for the next quarter.

Benefits of a good onboarding

When an employee feels valued, supported, and listened to, this consolidates the feeling of belonging. I have often seen people thrown into teams with only a pile of documentation and no real guidance. They spend most of their time trying to guess what is expected, asking the wrong people for help, or following advice from colleagues who never had proper onboarding either. This quickly creates confusion and misalignment between what you, as the hiring side, expect and what the joiner thinks they should do. Done well, onboarding improves retention and reduces turnover.

You only have one chance to give a good first impression. Perceiving that you joined a structured and people-oriented organization starts shaping a long-term engagement from day one.

We could say there are two main benefits of proper onboarding. First, it reduces the time to productivity because clear, good information speeds up the time to real contribution. Second, it gives you better information about the fit of new team members. A professional who cannot progress through the onboarding plan will rarely succeed later, and this plan can also be designed to check the real cultural fit. But bear in mind that cultural fit does not mean “is like we all are here”; it means aligned values and ways of working, while still leaving space for diversity.

The cost of bad onboarding for IT teams is high: frustration, impostor syndrome, and a strong feeling of not belonging. A minimal but intentional onboarding is better than an improvised one.

Onboarding plan example

This can be a starting point for an onboarding plan. What this means is that this plan is expected to be customized to your company’s needs, not to be used as is.

30 days Goal: Learn the company, team, tools, and basic workflows.

• Understand the company mission, product, and IT team structure.
• Set up all accounts, permissions, devices, and required tools.
• Learn internal processes, ticketing, escalation paths, and security rules.
• Meet key stakeholders and teammates.
• Complete initial training and required compliance tasks.
• Shadow a teammate and observe common work patterns.
• Deliver one small, low-risk task with support.

60 days Goal: Start taking ownership of real work.

• Handle common tasks with less supervision.
• Learn deeper system knowledge, architecture, or support processes.
• Complete medium-complexity assignments.
• Join regular meetings and contribute ideas.
• Identify recurring issues and possible improvements.
• Ask for feedback from the manager and teammates.
• Show steady progress on speed, quality, and confidence.

90 days Goal: Work independently and deliver consistent value.

• Own end-to-end tasks or a small project.
• Resolve most routine issues without help.
• Understand team priorities, standards, and escalation rules.
• Contribute to process improvements or documentation.
• Demonstrate good communication and reliability.
• Review strengths, gaps, and next development goals with the manager.
• Agree on the next quarter’s priorities.

To complete this planning, consider adaptations based on:

• Role-specific skills.
• Systems and tools to learn.
• Stakeholders to meet.
• Training courses to complete.
• Metrics to track.
• Manager check-in dates.

To know whether your onboarding is working, track simple metrics like time to first merged PR or closed ticket, time to handling a typical task independently, and new joiner satisfaction after 30 and 90 days.

One page checklist for the manager

Before day one

• Hardware ready (laptop, peripherals, access card, VPN, phone if needed, desk or remote setup confirmed).
• Accounts created (email, chat, documentation, repos, ticketing, HR tools, SSO).
• Access permissions granted (code, dashboards, shared drives, calendars, VPN, internal tools).
• Org context doc prepared (org chart, team structure, main stakeholders, key documentation links).
• Buddy/mentor selected and briefed on role, expectations, and first‑week support.
• Welcome email sent (start time, location/links, dress code if relevant, high‑level first‑week overview).
• Day‑one agenda drafted and shared (who they meet, when, topics, meeting links).

Day 1 checklist

• Personally welcome the new joiner (on‑site or video) and walk them through practical basics.
• Confirm hardware works and all tools/accounts are accessible.
• Give a short intro to company mission, product, and where your team fits.
• Introduce them to the buddy/mentor and encourage an informal coffee/intro chat.
• Do a brief expectations talk: what the first week and first month will roughly look like.
• Ensure they join at least one team ritual (stand‑up, planning, or similar) to start observing.

First week (days 2–7)

Manager must check these are happening (can be delegated, but not ignored):

• New joiner understands company mission, product, and high‑level IT/team structure.
• All accounts, permissions, devices and tools are fully set up.
• They received or found documentation for processes, ticketing, escalation, and security rules.
• They have met key stakeholders and immediate teammates (1:1 or small group).
• Mandatory trainings and compliance tasks have been assigned and planned.
• Shadowing at least one teammate has started (join calls, grooming, PR reviews, support, etc.).
• A tiny, low‑risk real task has been agreed, with clear support and review from buddy or manager.

Manager 1:1 at end of week:

• Explain clearly how performance will be evaluated (role expectations, metrics, behaviours).
• Ask for early feedback on clarity, pace, and any blockers.

Remainder of first month (days 8–30)

Ongoing weekly manager actions:

• Check they are joining regular team meetings and understand their purpose.
• Ensure they keep shadowing different teammates to see varied work patterns.
• Confirm they have completed initial training and compliance items.
• Provide at least one structured feedback moment about their first tasks (what worked, what to adjust).

End‑of‑month manager check‑in (formal 30‑day review, even if light):

• Confirm 30‑day goal: basic understanding of company, team, tools, and workflows.
• Review what they learned: mission, org, main systems, ways of working.
• Review one or two small tasks completed (quality, collaboration, learning attitude).
• Ask how they feel about integration in the team and psychological safety (are they comfortable asking questions).
• Identify any gaps or concerns early; agree on focus for next 30 days.

Second month (days 31–60)

Guided contribution phase – manager weekly checklist:

• Assign medium‑sized tasks or a small project with clear ownership but available support.
• Plan deeper training on architecture, domain, or support processes as needed.
• Review progress against the onboarding goals (speed, quality, collaboration).
• Explicitly ask the new joiner for feedback on the onboarding so far and adjust weak spots.
• Run weekly team check‑in (even 10 minutes) to gather how integration feels from the team side.

Mid‑point (around day 45–60) focused 1:1:

• Discuss how comfortable they feel handling common tasks with less supervision.
• Review 1–2 medium‑complexity assignments: what they did well, where they needed help.
• Capture any concerns about fit, expectations, or team dynamics; bring them into the open.
• Adjust scope if needed (too much/too little) and clarify expectations for days 60–90.

Third month (days 61–90)

Independence and ownership phase – manager weekly checklist:

• Ensure they own end‑to‑end tasks or a small project with clear definition of done.
• Confirm they resolve most routine issues without help and know escalation rules.
• Check understanding of team priorities and quality standards (definition of ready/done, code quality, SLAs, etc.).
• Encourage them to contribute ideas to process improvements or documentation.
• Monitor consistency in communication and reliability (meeting commitments, raising risks early).

Prep for 90‑day review (collect in advance):

• Examples of delivered work showing impact and quality.
• Feedback from buddy and 1–2 teammates about collaboration and fit.
• Basic metrics where applicable (time to first PR/ticket, current throughput, quality signs).

90‑day review meeting (formal closure of onboarding):

• Confirm 90‑day goal: work mostly independently and deliver consistent value.
• Discuss strengths you’ve observed (technical skills, ownership, communication, learning speed).
• Discuss gaps with concrete examples and agree on how to work on them.
• Ask directly if the role and company match their expectations and if anything feels off.
• Define 2–3 development goals and priorities for the next quarter (post‑onboarding plan).
• Explicitly mark onboarding as “completed” and welcome them as a full team member.

Global “am I on track?” questions

Use these questions at 30, 60 and 90 days for yourself as manager:

• Do they understand what success in this role looks like in practical terms?
• Can they perform typical tasks at the expected level of quality and speed (for this stage)?
• Do they feel safe asking questions and raising concerns?
• Is the team involving them naturally in work and conversations?
• Are we seeing steady progress, even if not linear?

As a new joiner

When I say “individual,” I mean you as a professional taking ownership of your own onboarding experience. The company is responsible for providing structure and support, but you are responsible for asking questions, clarifying expectations, and making sure you get what you need to succeed.

Think of onboarding as a two‑way evaluation: they assess your fit, and you assess whether this is a healthy place to invest your time and energy.

Preparation for the onboarding

This is where you set yourself up to start strong instead of “just showing up and hoping for the best.” Before day one, you should prepare and, when needed, ask proactively:

• Role understanding: Re‑read the job description and any notes from interviews. Write down what you think your main responsibilities and first 90‑day goals are, so you can confirm them with your manager.
• Practical questions: If unclear, ask in advance about start time, location/links, dress code, who will welcome you, and whether you need to bring anything specific.
• Tools and access: Check if your laptop or equipment will be shipped, if you need to set up accounts before day one, and who to contact if something is missing.
• Context homework: If possible, review the company website, product docs, engineering blog, or public talks to understand the business, product, and tech stack.
• Personal introduction: Prepare a short intro about yourself (background, strengths, how you like to work) that you can reuse in team meetings and 1:1s.
• Expectations for support: Decide what you need from a buddy/mentor and manager (frequency of 1:1s, preferred communication style) so you can request it early.

You don’t need to be demanding; you just need to be explicit. Clarity helps everyone.

Onboarding Plan

Learning and setup

Your first week is about absorbing context and confirming that joining was a good decision. The objective is not to “prove your worth” through heroic output, but to build a solid understanding of the environment.

During this week, you should

• Ask for clarity: In your first 1:1, ask your manager how success will be evaluated, what your 30‑, 60‑, and 90‑day goals are, and what “good” looks like in this role.
• Map the landscape: Note the org structure, who your direct collaborators are, and which teams interact with yours regularly.
• Learn how work flows: Observe tools, rituals (stand‑ups, planning, reviews), and basic workflows (how tasks are picked up, reviewed, deployed, supported).
• Build relationships: Have short informal chats with your manager, buddy/mentor, and closest teammates. Focus on understanding how they like to work and communicate.
• Start small: Take on one tiny, low‑risk task with clear support. This is a learning vehicle, not an exam.

For remote or hybrid setups, over‑communicate from your side as well: keep your status visible, show up with camera on when possible, and share short written summaries of what you understood and what is still unclear.

The following three weeks (still month one) are “understanding time.” You should

• Shadow teammates: Join calls, read PRs, and observe how decisions and trade‑offs are made.
• Ask “why” questions: Why do we do it this way? What changed in the past? What is considered risky or unacceptable?
• Expand your network: Meet stakeholders outside your immediate team (product, QA, ops, support, etc.).
• Reflect regularly: Keep a simple learning log: key systems, key decisions, unknowns, and potential risks you see.

By the end of month one, request a quick check‑in with your manager (if not already scheduled) to exchange feedback: how they see your ramp‑up and how you are experiencing the onboarding so far.

Guided contributions

At this point, you and your manager should start validating fit in both directions. Nothing is final yet, but it’s the right moment to surface doubts early instead of waiting for the end of probation.

During the second month, aim to

• Take ownership of medium‑sized tasks: Ask for work that stretches you but still has support and clear success criteria.
• Deepen knowledge: Request deeper training or explanations on architecture, domain, and key workflows where you still feel weak.
• Make expectations explicit: Regularly ask, “Is this the level of ownership and quality you expect from me at this stage?”
• Give and request feedback: Ask your manager and teammates for specific feedback on your work and collaboration, and share structured feedback about the onboarding itself.

Your focus is to progress on both sides: your technical/role performance and your integration in the team. If something feels off (scope, communication style, culture), bring it to your 1:1s instead of hoping it disappears.

Near the end of month two, have a more focused conversation: what’s working, what isn’t, and what should change in the next 30 days for you to feel on track.

Independence and ownership

The last part of onboarding is your take‑off moment. The goal is to move from “new joiner” to “full team member” with clear responsibilities, trust, and a realistic plan for growth.

In the third month, you should

• Ask for end‑to‑end responsibilities: Seek ownership of a small project or clear work stream where you control the full lifecycle with appropriate support.
• Validate priorities and standards: Confirm you fully understand team priorities, quality standards, and “definition of done” for your work.
• Prepare for a proper 90‑day review: Collect examples of your work, situations where you added value, and areas where you still want support.
• Co‑create a next‑quarter plan: Don’t let onboarding just “fade out.” Align with your manager on what you will focus on in the next three months.

By the end of this phase, you should no longer feel like “the new person,” but like a contributing member with a clear roadmap. If the company does not offer a 90‑day review, propose one. It’s your career; you can ask for a proper closure of onboarding.

Benefits of a good onboarding (for you)

For you as an individual, good onboarding reduces anxiety, speeds up your value delivery, and gives you a realistic picture of whether this company deserves your long‑term commitment.

Done well, onboarding:

• Reduces the time to productivity: Clear expectations and structured learning allow you to contribute earlier with confidence.
• Builds belonging: Feeling welcomed, supported, and listened to from day one strongly influences your sense of belonging and motivation.
• Clarifies fit earlier: A transparent onboarding experience gives you better data to decide whether this environment aligns with your values and way of working.
• Protects your mental health: Having guidance and psychological safety reduces impostor syndrome and the “I’m lost and everyone else knows what they’re doing” feeling.

A minimal but intentional onboarding is better than an improvised one. If the company doesn’t have a strong process, your proactivity can still make your experience much better.

Onboarding plan example (individual view)

Use this as a starting point to self‑manage your onboarding. Adapt it to your role and company context.

30 days

Goal: Understand the company, team, tools, and basic workflows.

• Learn the mission, product, and where your team fits in the bigger picture.
• Get all tools and accounts working; note any blockers and escalate early.
• Understand how work is created, prioritized, executed, and reviewed.
• Meet key people you’ll work with regularly and learn how they like to collaborate.
• Shadow teammates and take notes on patterns: communication style, quality expectations, pacing.
• Deliver one small task with support and use it to calibrate expectations.

60 days

Goal: Start taking ownership of real work.

• Handle common tasks with less supervision and track your own progress.
• Volunteer or ask for medium‑complexity tasks that match your growth zone.
• Join regular meetings and contribute questions, ideas, or small improvements.
• Ask for explicit feedback from your manager and colleagues on your work and collaboration.
• Reflect on fit: are expectations realistic, is communication healthy, are you learning?

90 days

Goal: Work mostly independently and plan your development.

• Own end‑to‑end tasks or a small project with clear outcomes.
• Show that you can handle routine issues and know when to escalate.
• Contribute to improvements (documentation, processes, or quality).
• Have a structured 90‑day conversation about strengths, gaps, and next‑quarter priorities.
• Decide honestly if this company and team are a good place for your next 1–2 years.

You can keep a simple private document to track what you learned, what you delivered, and how you feel at each stage.

One page checklist for the individual

Before day one

• Clarify start time, location/links, and who you report to on day one.
• Confirm equipment and access plan (shipped, picked up, or prepared on site).
• Review the job description and write down your understanding of your role.
• Prepare a short personal intro (background, strengths, working style).
• List key questions: expectations, metrics, growth paths, team rituals.

Day 1 checklist

• Meet your manager (even briefly) and confirm basic expectations for the first week.
• Meet your buddy/mentor and agree how and when you will communicate.
• Verify that hardware, accounts, and basic tools work; note and escalate any gaps.
• Join at least one team ritual and observe how people interact.
• Ask where to find documentation and who to contact for common issues.

First week (days 2–7)

• Learn the mission, product, and org structure at a high level.
• Map your immediate collaborators and their responsibilities.
• Shadow at least one teammate and ask them to explain their work out loud.
• Complete mandatory trainings or compliance tasks on time.
• Deliver a small, low‑risk task with clear support and review.
• Have a short 1:1 with your manager to clarify expectations and ask for early feedback.

Remainder of first month (days 8–30)

• Join regular team meetings and ask clarifying questions about context and decisions.
• Shadow different teammates to see varied work patterns.
• Ask for at least one structured feedback conversation on your first tasks.
• Reflect on psychological safety: can you ask questions, admit not knowing, or disagree respectfully?
• Request a 30‑day check‑in if it is not already scheduled.

Second month (days 31–60)

Guided contribution phase – your weekly focus:

• Take ownership of medium‑sized tasks or a small project with clear goals.
• Request deeper training on architecture, tools, or domain areas where you feel uncertain.
• Regularly review progress against your onboarding goals with your manager.
• Give feedback on what is working and what is missing in the onboarding.
• Check how the team experiences your integration; ask 1–2 trusted teammates directly.

Mid‑point self‑check (around day 45–60)

• How comfortable are you with common tasks without step‑by‑step guidance?
• Which assignments went well? Where did you struggle and why?
• Are there any concerns about fit, expectations, or team dynamics that you haven’t voiced yet?
• Do you need scope or expectations to be adjusted?

Third month (days 61–90)

Independence and ownership phase – your weekly focus:

• Own end‑to‑end tasks or a small project and track your commitments carefully.
• Confirm you know escalation rules and when to ask for help.
• Check your understanding of team priorities and quality standards.
• Contribute at least one improvement (documentation, small process tweak, automation idea).
• Observe your own reliability: are you communicating early when something is at risk?

Prep for 90‑day review

• Collect examples of your work (tasks, PRs, incidents, contributions).
• Reflect on your strengths and areas where you still feel insecure.
• Write down what you expect from the next 3–6 months (skills, responsibilities, growth).

90‑day review conversation (if not offered, ask for it):

• Confirm whether you are meeting expectations and in which areas.
• Ask for concrete examples of your strengths and gaps.
• Share honestly whether the role and company match what you understood when you joined.
• Agree on 2–3 development goals and priorities for the next quarter.

Global “am I in the right place?” questions

Use these questions at 30, 60, and 90 days for yourself:

• Do I understand what success looks like in this role in practical, concrete terms?
• Can I perform typical tasks at a level that seems acceptable for this stage?
• Do I feel safe asking questions, raising risks, and disagreeing respectfully?
• Does the team include me naturally in work and informal conversations?
• Do I see steady progress in my knowledge, confidence, and impact?
• If I project myself 12–18 months here, does this environment support the professional I want to become?

If the honest answer to most of these is “no,” and you’ve already tried to address issues with your manager and HR, treat it as valuable information. Your onboarding is not just their process – it is also your early experiment to see whether this is the right place to grow.

Communication

You can make more friends in two months by becoming interested in other people than you can in two years by trying to get other people interested in you.

–Dale Carnegie, American Writer, How to Win Friends & Influence People

The basics of communication

This section is heavily influenced by Dale Carnegie’s classic “How to Win Friends and Influence People.” Carnegie argues that people are driven more by emotion, ego, and the desire to feel important than by pure logic. When you work with that reality instead of fighting it, your relationships and influence at work improve dramatically.

The three ground rules for human communication at work

• Don’t criticize, condemn, or complain: criticism usually makes people defensive and entrenched, not cooperative.
• Give honest, sincere appreciation: people crave recognition; praise must be genuine, specific, and not flattery.
• Arouse an eager want: instead of pushing what you want, frame things in terms of what they want and how your idea serves that.

In practice, these rules mean focusing on people’s strengths, celebrating their wins, and making them feel part of the project. It has to come from a genuine place; if you fake appreciation, people will notice sooner or later, especially in tough moments, and you will lose trust.

A simple example: instead of “I need you to do this report,” shift to “This report will give leadership a clear view of your work on X; if you lead it, I’ll make sure you’re mentioned in the review.”

Habits that make colleagues want to work with you

• Become genuinely interested in other people: ask about their work, hobbies, family, and actually care about the answers.
• Smile: a simple, visible signal that you’re friendly and open.
• Remember and use people’s names: a name is “the sweetest and most important sound” to a person.
• Be a good listener and encourage others to talk about themselves: let them take the stage; don’t interrupt.
• Talk in terms of the other person’s interests: link conversations to what they care about, not your favourite topics.
• Make the other person feel important—and do it sincerely: notice their strengths, contributions, and uniqueness.

All six habits point to one simple truth: people are much more interested in themselves than in you. When you show real interest in them – their work, their goals, their constraints – they open up, trust you more, and collaboration becomes easier. We admire people partly because they represent something we want for ourselves, whether it’s competence, calm under pressure, or influence. If you understand that, you stop trying to impress people and start trying to genuinely support them, which is a much faster way to their heart (and their cooperation). In a professional context, this is the difference between “Let me explain why you’re wrong” and “Can we explore what would happen if we tried it this other way?”

A simple example: instead of telling people how you fixed a problem similar to the one you are facing, ask if they’ve faced something similar and how they handled it. The trap here is turning every conversation into a story about how you did it better. That kills trust quickly.

Onboarding people into your ideas and projects

• The only way to get the best of an argument is to avoid it: arguments create winners and losers; instead, look for common ground.
• Show respect for the other person’s opinions; never say “You’re wrong”: disagree tactfully and with curiosity, not attack.
• If you’re wrong, admit it quickly and emphatically: it builds trust and disarms tension.
• Begin in a friendly way: tone at the start often decides the outcome.
• Get the other person saying “yes, yes” immediately: start with points of agreement to create momentum.
• Let the other person do most of the talking: people support what they help create.
• Let the other person feel that the idea is theirs: guide, but let them “own” the conclusion.
• Try honestly to see things from the other person’s point of view and be sympathetic to their ideas and desires: show empathy explicitly.
• Appeal to the nobler motives: tie your request to values like fairness, pride in work, or responsibility.
• Dramatize your ideas: present ideas vividly, so they’re memorable and engaging.
• Throw down a challenge: people often rise to a friendly challenge or goal.

These points might look like a mentalist trick, but underneath them there’s nothing more exotic than genuine interest and avoiding unnecessary confrontation. It is almost impossible to convince someone they are “fully wrong” in one conversation. I’ve rarely seen anyone truly change their mind just because they heard the right arguments. Instead, your job is to open the door for reflection: question ideas with care, not attacks, and create a small crack where the other person can think, come back with questions, and adjust their position over time.

A simple example: instead of telling people “this is how we make things here”, explain the reasons you keep doing it that way, and what are your concerns about changing the procedure, ask them to think about potential changes now that they have the full picture, and schedule a follow‑up to discuss with the complete context.

Gentle leading: influencing without forcing

• Begin with praise and honest appreciation before pointing out a problem.
• Call attention to people’s mistakes indirectly (for example, asking questions) instead of bluntly.
• Talk about your own mistakes before criticizing the other person: it lowers their defensiveness.
• Ask questions instead of giving direct orders: “How do you think we can handle this?” rather than “Do this.”
• Let the other person save face: avoid public embarrassment or humiliation.
• Praise the slightest improvement and every improvement; be “lavish in your praise”: reinforce progress, not just perfection.
• Give the other person a fine reputation to live up to: describe them as capable and responsible so they act that way.
• Use encouragement and make the fault seem easy to correct: frame problems as solvable and within their ability.
• Make the other person happy about doing what you suggest: show benefits for them, not only for you or the company.

You can summarise these nine points as: be decent, show that you care, involve people so they feel ownership, and encourage them to bring their best. Never try to grab the credit from your team; in leadership, your reputation is built on your people’s success. In the long run, “you are the team and the team is you,” so there is very little room for pure individualism if you want sustainable results.

A simple example:

• You: “Alex, first of all, I really appreciate how quickly you picked up the new billing module. The way you untangled the legacy code and got something working under pressure was impressive.”
  • Begin with praise and honest appreciation.
• You: “I was reviewing the last release, and I noticed a couple of things in the billing feature. I remember when I rushed a similar change last year and shipped with edge‑case bugs because I didn’t have enough tests in place.”
  • Call attention to mistakes indirectly and talk about your own mistakes first.
• You: “Looking at this part, what’s your view on how we can reduce the chance of similar bugs next time? What would you change in your process if you had to do this again?”
  • Ask questions instead of giving direct orders.

Alex suggests adding tests / pairing / smaller PRs, etc.

• You: “Yes, that makes sense. And I completely agree: you’re someone who cares about quality and owns the things you build, I’ve seen that in other features you’ve delivered. This case doesn’t change that; it’s just a chance to tighten the process.”
  • Give the other person a fine reputation to live up to and let them save face.
• You: “So for the next billing change, even adding two or three focused tests around the tricky paths would already be a great step. It’s a small tweak, but it will have a big impact on our confidence in your changes.”
  • Use encouragement and make the fault seem easy to correct.
• You: “And when you did that small refactor in invoicing last sprint, the reliability went up and we had zero incidents after release. I’d love to see the same level of care here, because you clearly can do it.”
  • Praise the slightest improvement and every improvement; reinforce progress.
• You: “If you’re up for it, I’d also like you to share your learnings from this with the team in our next dev sync. It’ll position you as someone who owns the billing area and helps others avoid the same pitfalls.”
  • Make the other person happy about doing what you suggest (benefits for them: ownership, recognition, leadership).

Communicating up (with your manager / leadership)

As you’ve seen so far, communication is more than just transmitting information. It’s about having a clear intent and understanding what the other person needs and expects—and I’ve personally made more mistakes here with my managers than I can count. When you have a clear idea of what you think needs to be done, the natural tendency is to try to convince the decision‑maker that your solution is the solution. That often backfires. You’re not there just to get your thing accepted; you’re there to contribute to a bigger picture, give input, and agree on priorities. As you might guess, this never ends in a good way, you are not there to make your thing, you are there to be part of a bigger picture and advice, and agree on priorities, and that is most of the time what your manager can help you with.

Goals: surface reality, manage expectations, influence decisions

Following the mantra of what your counterpart is interested in, this is the first step you should work on. Ask for time to evaluate the current situation, and be careful with this, we all tend to have a subjective view, and we need to be as objective as possible. Base all your conclusions, report, and presentations in facts, never in perceptions, losing credibility is easy when giving a wrong data that can be fact-checked. Where possible, use simple, verifiable metrics: lead time, incident count, user impact, cost. Facts are your best ally for credibility.

The next step is crucial, we saw in previous sections that having a clear view of the expectations your manager has is the only way to satisfy those expectations. Managing expectations is making clear what can be accomplished, and what cannot be accomplished and why. After clarifying expectations, don’t accept them blindly. Check feasibility, then negotiate scope, timing, and success criteria. This is not being difficult; it’s professional.

Finally, you can see that the word used here for decisions is not to communicate, to impose, or to convince, it is to influence. The decisions that affect you need to be influenced by you as the responsible for those actions. Remember that the best tool you have is information, data, examples, and proposals. Use them to influence those decisions. Think like a product manager of your work: bring options, costs, benefits, and a recommendation, not just a problem.

Skills: framing, brevity, clarity on risks and trade-offs

The most common error on this topic is not being aware that the language your manager speaks might not be the same you are used to. Talking with non-technical people about architectures, clean code, scalability, technical debt, might not be the best idea. You need to translate that to the language spoken in that circle.

Framing

When communicating, in general, but specially with your manager, you come with the whole context and historical information of what you are going to talk about, but probably the rest of the audience does not. To avoid entering an endless list of questions about what, where, how, and why, the best option is to give context on the topic you are going to communicate. The mitigation is easy. Explain the context of the information you are going to provide, and set the boundaries of what you are going to talk about even before starting the exposure of the topic to communicate. This structure makes your manager’s life easier: they quickly know where we are (context), what you’re trying to achieve (intent), and what is and isn’t possible (boundaries).

A simple example:

Hi [Manager],

I want to give you a quick update on the feature and align on expectations.

Context: We’re currently implementing the payment retry logic. The core flow is working, but edge cases (timeouts, duplicate retries) still need validation to avoid production issues.

Intent: My goal is to ship something reliable without creating follow-up incidents or rework next sprint.

Boundaries: If we aim for a release by Friday, I can deliver the happy path only. Covering edge cases properly will take until early next week. Skipping that increases the risk of failures under load.

Brevity

Exposing any situation presumes a previous preparation. When you did not prepare the communication it is very likely that you start rambling and not going to the point. Try to synthesize the information at much as possible and go straight to the point, otherwise the risk of losing your interlocutor attention is high. I’ve seen many situations where, in the middle of the conversation you are asked “but what do you need from me?”, and that is a clear sign that you are not communicating right. You can leave time for specific questions and clarifications at the end of your speech, but that should happen when the intent is clear and the request has been properly transmitted.

A simple pattern that helps is:

“Headline → 1–2 key facts → Ask.” For example: “The payment feature is at risk for Friday. We uncovered two extra integration steps. I recommend we either move the date to Tuesday or cut scope to A and B. Which do you prefer?

Clarity on risks and trade-offs

If experience has taught me anything, it is that every decision has a trade-off, otherwise it is not a decision, it is an action to be done and there is nothing to discuss. So, be clear on what are the risks and trade-offs for each option, so you provide enough information to make a decision with a clear knowledge of what consequences come with each option you present. When you show trade‑offs calmly (“faster, but with higher incident risk” vs “slower, but more stable”), you position yourself as a partner in decision‑making, not a blocker.

Typical formats: 1:1s, status reports, proposals, escalations

Let’s see what are the typical formats for communication with your manager/leader that you should be doing periodically.

1:1s

One to ones are not to discuss the work done, current status, or issues you have, they are the place to talk about you. This is the moment you can expose your personal concerns, your wishes or expectations. It’s where you can talk about better communication, friction with coworkers, proposals for improvement on the working environment, or talk about your career progression. It is the best tool for your manager/leader to take the pulse of the team moral, frustrations, or proposals for improvement in the workplace. Don’t use it as a way to talk about the technical problems, missing assets, or process improvements, there are other forums to do that. Instead, talk about how you feel compared to your expectations, talk about your concerns on your progression, communication problems or ask for advice about how to face a conflict or action you need to take.

As an improvement, it worked for me very well, to do this meetings outside the office, while going for a walk in the park, that provides a more relaxed context and helps on less stressing situations.

Status Reports

This is the formal situation where you will be required to inform about the current situation, possible issues, predictions, and requests. In this meeting, that usually should happen in a separated room in the office, it takes more importance than in any other communication formats to follow the “Skills: framing, brevity, clarity on risks and trade-offs” section that I described previously. There are some topics to consider before even the meeting happens:

• Write a clear agenda with the topics you are going to communicate: This will allow your manager to have a clear idea of what you are going to expose and provides time to collect the information needed to prepare the meeting.
• Share any material you are going to present: Being familiar with the documentation you are going to talk about will help to go to the point during the meeting.
• Write a clear list of outcomes you expect to have once the meeting is done: This should be a common point to all meetings, so all the attendants know what is expected to produce the meeting.

Proposals

This, in general, is not a recurring meeting as you probably don’t have proposals every week. In this case the “context, intent, boundaries” structure makes more sense than ever.

• Context: Expose the frame of the question you want to improve of mitigate.
• Intent: Why you want to mitigate that situation or fix that problem.
• Boundaries: What, when, and how you suggest taking this action.

When framing the meeting this way, there is low probability of not transmitting what is the reason and why it should be approved. Don’t forget to provide a short yet clear exposure of the nature of the proposal in the meeting schedule, so your manager can get the context before starting the meeting.

Summary Table

Communicating down (with your team)

When you communicate with your team, your job is not to impress them with how much you know. Your job is to make their work clear, meaningful, and psychologically safe. Good “communication down” turns vague strategy into concrete next steps, keeps everyone aligned, and reduces anxiety. Always remember two important aspects of communicating down:

• No trust, no communication: If your team does not trust you, the communication you will receive is the one they think you want to hear.
• Challenging is not correcting: You should challenge your team in a constructing way, correcting them is sending a negative message.
• Respect is a result: Don’t think that your position provides automatic respect, it is something you need to win day to day.

Goals: alignment, clarity, psychological safety, context-sharing

Think of communicating down as the opposite of micromanagement: you give people clear direction plus enough context, so they can decide well without you in the room.

• Alignment: Everyone understands the same priorities, why they matter now, and what “good” looks like this week, this month, this quarter.
• Clarity: People know what is expected of them in concrete terms: outcomes, scope, quality level, timing, and how work will be evaluated.
• Psychological safety: Team members feel safe asking “basic” questions, challenging ideas, admitting mistakes, and surfacing bad news early.
• Context-sharing: You don’t just say what to do, you explain why—the business impact, constraints, and trade‑offs behind decisions.

A simple test for yourself as manager: if someone fails to deliver, is it more likely because of lack of skill, or because expectations and context were never truly clear?

A simple example:

instead of “We need to speed up delivery,” say: “For the next two sprints, our top priority is reducing incident volume in checkout by 50%. That means we will pause new features in this area and focus on stability work. ‘Good’ here means fewer incidents, not more tickets closed.”

Again going for SMART.

Skills: turning strategy into concrete expectations, repeating key messages, checking understanding

To communicate effectively downwards, you need a few core skills. None are “natural talents”; they are all trainable habits.

Turning strategy into concrete expectations

Your team does not sit in the same meetings you do. They don’t hear all the reasoning, politics, and constraints. Your job is to digest that noise and translate it into clear, realistic expectations.

• From “theme” to “this week”: Take company or department strategy and break it into 1–3 clear focus areas for the team, then into concrete tasks and behaviours.
• Define done in plain language: For each important initiative, describe what success looks like in observable terms (metrics, behaviours, deliverables).
• Name trade‑offs explicitly: If you’re choosing speed over perfection, or stability over new features, say it out loud so people can align their decisions.

A simple example:

Leadership wants us to ‘improve customer trust’. For us, that means: no Sev‑1 incidents in the next quarter, answering support tickets within 24 hours, and making error messages less cryptic. Your work should support these three outcomes first.

Repeating key messages (without sounding like a robot)

People do not remember everything you say once. They remember what you repeat calmly and consistently across channels.

• Choose your 2–3 core messages: For each quarter, decide the few ideas you want your team to hear again and again (e.g. “stability first”, “fewer projects, more finish”).
• Repeat across rituals: Use the same language in planning, stand‑ups, 1:1s, written updates, and casual conversations.
• Explain the why each time: Don’t just repeat slogans; repeatedly connect them to current context and decisions, so they don’t become empty buzzwords.

If you feel slightly tired of saying something, your team is probably just starting to really internalize it.

A simple example:

You’ll hear me repeat this a lot: for this quarter, finished work beats starting new things. In planning, in stand‑ups, and in 1:1s I’ll keep asking what we can close before we open more.

Checking understanding instead of assuming it

Silence is not alignment. The fact that nobody pushes back does not mean they understood or agree.

• Ask people to reflect back: After explaining something important, ask: “How would you explain this to a new joiner?” or “What’s your understanding of the priority?”
• Listen for inconsistencies: If different people describe priorities differently, that’s a signal to clarify, not to blame.
• Invite disagreement safely: Say explicitly: “If something here sounds unrealistic or confusing, I need to hear it now, not in three weeks when the deadline is gone.”

A simple example:

We’ve talked about focusing on reducing incidents. Before we close, can two of you summarise what you’ll personally focus on next week and how you’ll know if it’s working?

Typical formats: team meetings, written updates, 1:1s, feedback conversations

You communicate down all the time, but these four formats are where you have the most leverage. Use each for its specific purpose instead of trying to do everything everywhere.

Team meetings: alignment and shared context

Team meetings (weekly planning, review, retros, or all‑hands for your team) are the best space to align everyone at once.

Use them to:

• Set and re‑state priorities: Begin with “Here is what matters most for us this week/this sprint and why.”
• Share context openly: Explain relevant decisions from higher up, customer feedback, or cross‑team dependencies in simple terms.
• Invite questions and concerns: Leave space for “What are we missing?” or “What worries you about this plan?” to surface risks early.

Avoid turning every team meeting into a status‑reading session. Status can be written; live time is better used for alignment, decisions, and questions.

A simple example:

Sample agenda:

1. 5 minutes: priorities and why
2. 10 minutes: key updates (incidents, product decisions)
3. 10–15 minutes: risks and blockers from the team
4. 5 minutes: reiterate what we are not doing this week

Written updates: traceability and calm

Written updates (Slack posts, emails, short docs) reduce noise and misinterpretation. They are especially useful for distributed teams and for topics that people need to revisit.

A good written update is:

• Short and structured: Headline, 2–3 bullet points of what changed, clear next steps.
• Explicit about decisions: “We decided X, we considered Y, here is why we chose X and what we’ll revisit later.”
• Accessible asynchronously: Shared in a channel or document where people can find it later and ask follow‑up questions.

A simple example:

Headline: Q3 focus for our team.

1. Primary goal: reduce checkout incidents by 50%,
2. Secondary: improve support response time to <24h
3. We will pause new payment methods until October. Details below, questions welcome in the thread

1:1s: individual clarity and safety

As we described in the “communicating up” section, 1:1s are not just about task status; they are about the person. When communicating downwards, use 1:1s to customize expectations and create psychological safety.

Use 1:1s to:

• Clarify personal expectations: “For you specifically, over the next 60 days, I expect A, B, and C. Here’s how I’ll know we’re on track.”
• Talk about feelings and frictions: Invite them to share where they feel lost, underused, or overwhelmed, and listen without immediately defending yourself or the company.
• Check safety signals: Ask directly: “Do you feel comfortable telling me when something is wrong or when you disagree with a decision?”

A simple example:

As a team, our focus is stability. For you, I want you to own the alerting improvements for service X. That means defining thresholds, cleaning noisy alerts, and documenting runbooks. We’ll review progress every two weeks in this 1:1.

Feedback conversations: growth without fear

Feedback is one of the purest forms of “communication down.” Done badly, it destroys trust. Done well, it accelerates growth and increases safety.

You can reuse the “gentle leading” principles from the earlier section: start with honest appreciation, talk about your own mistakes, ask questions instead of giving orders, and help people save face.

A simple pattern for feedback:

• Start with context and appreciation: “I appreciate how quickly you picked up X; there’s something in how we executed that I’d like us to tune.”
• Describe behaviour and impact, not personality: “In the last release, we merged without enough tests, which led to two incidents and weekend work for support.”
• Ask and co‑create the next step: “How do you see it? What could we change next time? Here are some ideas—what would work best for you?”

A simple example:

Exactly as in the “gentle leading” section, where you praise the person’s ownership of the billing module, share your own past mistake, and then ask them how to reduce the chance of similar bugs next time instead of issuing orders.

Summary Table

Communicating sideways (with other teams)

We covered communication principles and then vertical flows (up/down), but most daily friction in tech teams is lateral: other teams, peers, product, ops, etc. The last piece is “sideways” to close the triangle and feel complete.

Most of your daily work happens sideways: with peers, partner teams, and stakeholders like Product, QA, Security, or Operations. When sideways communication goes wrong, you get friction, handover delays, and “us vs them” dynamics. Good sideways communication is about aligning expectations between equals, negotiating trade‑offs, and keeping collaboration smooth without needing escalation.

Goals: alignment, clarity, psychological safety, context-sharing

Think of sideways communication as joint ownership of a shared problem, not a negotiation to see who “wins.”

• Collaboration: Work with other teams as partners solving a shared problem, not service providers or blockers.
• Clear ownership: Everyone understands who owns what part of the work, and where responsibilities start and end.
• Low‑friction handovers: Tasks moving between teams are ready, documented, and do not generate constant back‑and‑forth.

A simple example:

We own the internals of the payments service; you own the checkout UI. Let’s agree on exactly what we each guarantee at the API boundary and what we log for debugging.

Skills: negotiating scope, clarifying ownership, agreeing on interfaces/SLAs, documenting decisions.

Sideways communication requires a slightly different muscle: you cannot “tell” people what to do; you need to agree.

• Negotiating scope and timelines: When another team asks for something, don’t just say yes/no. Clarify the request, constraints, and propose realistic options.
  • “Given our current load, we can deliver A by end of month, or A+B if we drop C. Which is more valuable for you?”
• Clarifying interfaces and expectations: Make agreements explicit: APIs, SLAs, responsibilities during incidents, expected quality level.
  • Write these down in short interface docs, runbooks, or RACI tables.
• Documenting decisions in simple language: Summarise key cross‑team decisions in writing: what we decided, why, and what happens next.
  • This avoids “I thought you were doing that” three weeks later.

A simple example:

To avoid surprises later, can we write down in two bullets what each of us is committing to for this launch and share it in our teams’ channels?

Typical formats: cross‑team channels, joint refinement, design reviews, incident reviews.

We already have most of the forums; the key is to use them intentionally.

Cross‑team channels (Slack, Teams, email)

Use them for clear, written requests and updates, not vague pings.

Request: We need API X to support field Y by June 15. Current impact: we can’t personalise offers. Options: 1) add Y now with basic validation, 2) delay to Q4 with full redesign. Which is realistic for you?

Joint refinement and planning

Bring the right people to clarify scope before work starts.

• Align on acceptance criteria, dependencies, and who is responsible for each piece.
• Ask explicitly: “What do you need from us so this is easy for your team?”

Design and code reviews across teams

Invite affected teams early when design decisions impact their domain.

• Keep reviews focused: problem, options considered, proposed solution, impact on others.
• Be respectful of their constraints; they also have their own roadmap and pressures.

Incident reviews and post‑mortems

Use incidents to improve sideways communication, not to blame.

• Ask: “Where did our expectations of each other differ?”, “Which signal would have helped us loop you in earlier?”
• Capture one or two concrete changes (runbook updates, extra alert, clearer ownership).

A simple example:

Opener for a sideways 1:1 or sync: “We seem to get stuck at the handover between our teams. I’d like us to map who owns what and agree on a simple checklist, so we don’t need to escalate every time.”

Summary Table

Remote / hybrid communication nuances

Remote and hybrid work turn small communication gaps into big problems faster, because you lose hallway conversations and accidental context. The principles are the same, but you must be more deliberate.

Over‑communicate the boring things

• Make the invisible visible: status, priorities, availability, decisions should live in written channels, not in your head.
• Default to short written summaries after key discussions: “What we decided, why, and next steps.”
• Use clear subjects and headlines so people can quickly scan and know if they need to read.

A simple example:

After a call, post: “Decision: We postpone feature X to next sprint to finish migration. Reason: avoid splitting focus and reduce incident risk. Next steps: A owns migration, B pauses new work on X.”

Be intentional with channels and tone

Choose the right channel: async docs or threads for decisions, chat for quick questions, video for sensitive or ambiguous topics.

• In text, be explicit and kind: avoid sarcasm, add one extra sentence of warmth or clarification you’d naturally give in person.
• When in doubt, jump to a short call instead of escalating a written misunderstanding.

A simple example:

Replace “We need this today” with “We need this today so we can unblock deployment; if this creates a problem for you, let’s jump on a 10‑minute call.”

Design rituals for connection, not just tasks

Keep regular team rituals, but tighten agendas so meetings have a clear purpose and finish with a summary.

• Add small human touches: 2‑minute check‑ins, occasional non‑work topics, explicit appreciation in public channels.
• For 1:1s, treat cameras‑on as the default for sensitive topics, but be flexible when people are tired or have constraints.

A simple example:

Start remote stand‑ups with: “Quick round: 1 win from yesterday, 1 priority for today, 1 risk you see this week.”

Make expectations and availability explicit

Share your working hours, focus times, and response‑time expectations (for yourself and the team).

• As a manager, model healthy behaviour: don’t expect instant replies to late‑night messages; use scheduled send when possible.
• For distributed time zones, agree on overlapping hours and which topics must happen synchronously.

A simple example:

“I’m usually online 9–17h CET; I check Slack deep‑work‑style at 9, 12, and 16h. For urgent production issues, please call.”

Quick checklist for Remote / hybrid communication

• Make the invisible visible: write down priorities, status, and decisions in shared channels (not only in calls or your head).
• Summarise key discussions: after important meetings, post 3 lines: what we decided, why, and next steps.
• Pick channels on purpose: use async docs/threads for decisions, chat for quick questions, video for sensitive or ambiguous topics.
• Be extra clear and kind in text: avoid sarcasm, explain urgency and context (“why today”) instead of just “ASAP”.
• Design rituals, not just meetings: keep regular team rituals with tight agendas, clear outcomes, and a 1–2 minute human check‑in at the start.
• Make availability explicit: share your working hours, typical response times, and what counts as “urgent”.

Key ideas

• Mindset
  • Communication = align intent, expectations, and collaboration, not just transmit info.
  • People run on emotion, ego, and feeling important as much as logic.
  • Aim to move work forward and protect relationships, not “win” arguments.
• Core principles
  • Don’t criticize, condemn, or complain; it creates defensiveness.
  • Give honest, specific appreciation; avoid flattery.
  • Frame ideas in terms of what the other person wants.
  • Avoid arguments and “you’re wrong”; seek common ground.
  • Let others talk more; let them co‑own ideas and save face.
• Everyday habits
  • Be genuinely interested in others and their constraints.
  • Listen more than you speak; don’t hijack conversations.
  • Talk in terms of the other person’s interests and context.
  • Make people feel important in a sincere way.
• Communicating up
  • Goal: surface reality, manage expectations, influence decisions.
  • Use facts and simple metrics, not vague perceptions.
  • Manage expectations: what can/can’t be done and why.
  • Bring options, costs, trade‑offs, and a recommendation.
  • Pattern: context → intent → boundaries; then “Headline → facts → ask”.
• Communicating down
  • Goal: turn strategy into clear expectations and safety.
  • If people are surprised by priorities or deadlines, it’s a comms problem.
  • Repeat key messages across formats; silence ≠ alignment.
  • Actively check understanding; ask people to reflect back.
  • Use: meetings for alignment, docs for decisions, 1:1s for individual clarity, feedback for growth.
• Communicating sideways
  • Goal: joint ownership with peers/other teams, clear ownership, smooth handovers.
  • Treat other teams as partners, not blockers or service desks.
  • Make ownership and interfaces explicit; write down agreements.
  • Negotiate scope/timelines with realistic options.
  • Use refinement, reviews, and incident reviews instead of Slack fights.
• Remote / hybrid
  • Make invisible things visible: priorities, status, decisions, availability in writing.
  • After key talks, post 3 lines: decision, why, next steps.
  • Choose channels on purpose: async for decisions, chat for quick questions, video for sensitive topics.
  • Be extra clear and kind in text; explain urgency and context.
  • Make working hours, response expectations, and escalation paths explicit.