1:1s that people want to keep

A 1:1 is the one meeting in the week that is about the person, not the project. Andy Grove, in High Output Management (1983), argued that the 1:1 is the report's meeting: they set the agenda, and how often you meet should depend on how experienced they are in their current work. Treat it that way and people bring you problems while they are still small.

Cadence. In this course you hold weekly 1:1s of about 45 minutes with your two tech leads, Sam and Dara, because they carry the most decisions and you are coaching them in a new role. Everyone else gets 30 minutes every two weeks. For 11 people that is about three and three quarter hours a week, the best-spent time in your calendar. Someone new, struggling or going through a hard time can move to weekly for a while.

A shared doc per person. Keep one running document for each person, newest meeting at the top. Both of you add items during the week, so nothing waits for memory. Each entry has three parts in this order: their topics, your topics, and actions with an owner and a date. The next 1:1 starts by checking last time's actions. The doc stays between the two of you, and it becomes the record you both look back on months later, for example in a review (Performance and growth).

No status updates. If a 1:1 turns into "here is what I did this week", it has been taken over by work that has a better home: the stand-up, the sprint board, a written update. Read the board before the 1:1, so you never need to ask for status there.

Never cancel; move or shorten. Cancelling a 1:1 for something "more important" tells the person exactly where they rank. If a week is on fire, move it a day, or keep 15 minutes. If someone says "I have nothing to discuss", keep a short one anyway and ask one good question.

Questions that get past "all fine". Open questions about specific things work better than "How is everything?" Some that work well:

• "What's taking more energy than it should right now?"
• "What should I know about that I probably don't?"
• "If you ran the team for a week, what would you change first?"
• "What's one thing I could do that would make your work easier?"
• Once a month, a longer one: "Where do you want to be in a year, and what is in the way?"

In the very first 1:1 with each person (The manager's job), also ask how they like to get feedback, how you will know when they are stressed, and what the best manager they ever had did for them. Write the answers in the doc. You will use them for years.

Feedback that lands

Feedback changes behaviour only when the person can see exactly what to repeat or what to change. Most feedback fails because it is vague ("be more proactive"), late (saved for the review) or a judgement of character ("you're careless") that the person can only argue with.

The Situation-Behaviour-Impact (SBI) model from the Center for Creative Leadership gives you a structure:

1. Situation: when and where. "In Thursday's demo to partner sales..."
2. Behaviour: what the person did, in words a video camera could have recorded. "...when they asked for partial payments, you said it would be easy and we'd add it..."
3. Impact: what happened as a result, for users, the team or the person. "...the team spent two days re-planning, and partial payments is now on the sales slide for 1 December."

Then stop talking and ask. Lara Hogan's version of the same idea, her "feedback equation", ends with a question or a request: "What was going on for you in that moment?" or "Next time, can you say you'll check with the team and come back by the next day?" The question matters because you only saw the behaviour. They may have a reason you don't know, and the conversation should end with a next step you both agreed.

The camera test. Before you speak, check every word of the behaviour part. "You were rude" fails: a camera cannot record rudeness. "You interrupted Tara twice while she was explaining the test plan" passes. Labels make people defend their character; behaviour gives them something to change.

Timing and place. Give feedback within a day or two, while both of you remember the details. Give corrective feedback in private. Never correct a tech lead in front of their own team, because it takes away the authority they need to lead it. A good rule: nothing in a performance review should be news, so everything in it was said in a 1:1 first.

Praise is feedback too. "Great job" feels nice and teaches nothing. Specific praise uses the same structure and tells the person what to do again: "In the sync bug last week, you wrote down the steps to reproduce it before you touched the code. Hugo fixed it in an hour because of that." Some people love praise in front of the team and some hate it; you asked in the first 1:1, so use their answer.

Care and challenge together. Kim Scott's Radical Candor (2017) puts feedback on two axes: how much you care personally, and how much you challenge directly. Both high is radical candor. Care without challenge is ruinous empathy: you stay quiet to be kind, and the person keeps making a mistake everyone else can see. Challenge without care is obnoxious aggression, and neither is manipulative insincerity. Managers who used to be peers of their team often slide into ruinous empathy. The kind move is to say the small thing early, when it is easy to fix, and to show the care in how you listen and help afterwards.

Keep feedback small and frequent: one point per conversation. Three criticisms in a row turn into a verdict, and the person hears none of them.

Receiving feedback, and skip-levels

The more power you hold, the less feedback people give you. Engineers rarely tell a new manager that their planning meetings run long or that their messages at 10 pm cause stress. You have to make it cheap and safe to tell you.

Ask small and specific. "Any feedback for me?" gets "No, all good." Ask about one thing: "What's one thing I could do differently in sprint planning?" Then wait through the silence; people often need ten seconds to decide whether you really mean it. Rotate the topic each month so it never feels like a ritual.

Know your triggers. Douglas Stone and Sheila Heen, in Thanks for the Feedback (2014), describe three triggers that make us reject feedback. A truth trigger: the feedback seems wrong. A relationship trigger: who it comes from gets in the way ("what does he know about managing?"). An identity trigger: it shakes how you see yourself ("I'm a good listener"). They also point out that people ask for one kind of feedback and receive another: appreciation (you are valued), coaching (here is how to get better) or evaluation (here is where you stand). Naming which trigger fired, even silently, helps you hear the useful part.

Respond in four moves. Thank them. Ask for an example ("Can you tell me about a time it happened?"). Don't defend in the moment, even if part of it is wrong; you can sort out the facts later. Then close the loop: a few weeks on, say what you changed and ask whether it made a difference. Closing the loop is what teaches a team that telling you things is worth it.

Skip-levels. In a skip-level conversation, Ken, your manager, meets the people who report to you, alone or in small groups, perhaps once a quarter. He learns how the organisation feels from the inside, and your engineers get a channel to raise something they would not raise with you. Support it openly. Tell your teams it is a good thing, and when Ken passes on what he heard, ask for themes and examples. Never ask who said it, and never try to work it out. The day one person feels exposed, the channel goes quiet for everyone, including about the problems you most need to hear.

You can use the same idea yourself. Sam and Dara lead their teams day to day, so once a quarter ask each team as a group, without the tech lead present, what is working and what isn't, and share the themes with the tech lead afterwards.

Coaching with questions

Coaching means helping someone find their own answer. Telling is faster today; coaching is faster over a year, because the person builds the judgement to solve the next ten problems without you. That matters even more with two teams: if every decision waits for you, you become the bottleneck for 11 people.

Ask first, and offer a choice. When someone brings a problem, try: "Do you want my ideas, or do you want to think it through together?" If they want to think it through, the GROW model from Growing as a PM gives the conversation a shape: their goal, the current reality, the options they see, and their will (what they will do, by when). You don't need the letters in your head. A few questions from Michael Bungay Stanier's The Coaching Habit (2016) do most of the work:

• "What's on your mind?"
• "And what else?" (asked two or three times; the first answer is rarely the real one)
• "What's the real challenge here for you?"
• "What do you want?"
• "How can I help?"

Keep the problem with its owner. A new tech lead will often hand you problems they should own. William Oncken Jr. and Donald Wass described this in the Harvard Business Review in 1974 as a monkey jumping from one back to another: the person leaves your office lighter and you leave heavier. A coaching question puts the monkey back gently: "What would you do if I were away this week?" End with their next step and a date, written in the shared doc.

Know when to tell. Coaching is the wrong tool in three cases. When it is urgent, such as a payment failure during the festival rush. When the risk is high and hard to undo, such as a data-protection question or a change that could stop scanners in 320 stores. And when the person simply lacks the knowledge; then you teach or point them to someone who can, as in Delegation and mentoring. Say so openly: "This one I'm going to decide, and here's why." People accept telling when it is rare and explained.