Milestone map
Milestone map
6 milestones
3 Builders working through this Challenge
Hold a real 1:1 with each report
2 weeks (30–60 min per direct report)
In your first two weeks, hold a 1:1 with every direct report. Make it about them, not status. Ask about their career goals and what they want to learn. Ask what frustrates them and how you can help. Take notes during or right after each one.
Proof required
Submit notes for each direct report, names removed. Each must include one thing they want to learn and one frustration. Each must include one specific commitment you made to them. Add a 150-word reflection on what surprised you most.
What gets checked
- Notes exist for every report, not just the ones you know well.
- Each commitment is a defined action with a timeline, not 'I'll think about it'.
- The reflection names a real surprise. 'They want to grow' means you didn't listen closely.
Common mistakes
- The 1:1 becomes a status update. If status takes over 20% of the time, redirect.
- You talk more than you listen. Aim to speak 30% and listen 70%.
- No notes, or late notes. Memory fades within a day, and notes are your proof.
Powstik Guide
Notes from a real 1:1 with each report.
Steps
- Book a 1:1 with every direct report.
- Ask what they want to learn.
- Ask what frustrates them.
- Remove names from your notes.
Template
| Report (code) | Wants to learn | Frustration | My follow-up | |---------------|----------------|-------------|--------------|
What gets sent back
- Reports missing.
- Names included.
- No follow-up.
Resources
Foundationstart here
What a verifier looks for
- Ask what they committed to for their most junior report. If they can't recall, it was a status meeting.
- Look for curiosity: open questions and specific details about the person.
- Confirm notes exist for every report, including ones they already knew.
You'll sign in first, then come straight back here.
Run your first team retrospective
1–4 weeks from joining the team (schedule within the first month)
Facilitate a retrospective on the last sprint, project or month. You facilitate; you don't take part. Draw out the team's views, not yours. It must end with action items, each with a named owner and a deadline.
Proof required
Submit the retro output: what worked, what didn't, what to try, and the action items. Each action needs one named owner and a specific deadline. Add a 100-word reflection on one thing you'd do differently as facilitator.
What gets checked
- Every action has one named owner. 'The team will do X' doesn't count.
- At least one action is due within the next sprint or week.
- The reflection names the hardest moment to facilitate, not 'it went well'.
Common mistakes
- It becomes a complaint session with no actions.
- You dominate and quiet people never speak. Then you took part; you didn't facilitate.
- Actions are accepted without owners. They won't happen, so push until each has a name.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Read the actions. 'Improve communication' fails; 'Sara sends a Monday update by 10am' passes.
- Ask which action was actually completed. None completed means no accountability.
- The reflection must name a specific moment in the session.
You'll sign in first, then come straight back here.
Give your first difficult feedback
Whenever the situation arises — do not wait; most new managers delay by months and the situation always gets worse
Pick a real performance or behaviour issue with one of your reports. Raise it directly in a 1:1. Don't hint, and don't change a process to avoid the talk. Say what you saw, its impact, and what needs to change. Be specific and kind.
Proof required
Write 200 words on the conversation. Give what you said, word for word if you can. Say how they responded. Say what next step you agreed. Don't name the person. Add 100 words on what made it hard and one thing you'd change.
What gets checked
- The feedback is about behaviour, not character. 'You missed three deadlines', not 'you're disorganised'.
- A specific next step was agreed. The person said yes to something concrete.
- The reflection is honest. 'It was fine' means it wasn't really difficult feedback.
Common mistakes
- Giving it over Slack or email to avoid discomfort. Do it in person or on video.
- Softening it until the point is lost. If you're unsure they heard it, they didn't.
- No agreed next step. Then you got clarity, but they have no accountability.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask whether the person understood what had to change. If unsure, it wasn't specific enough.
- Check it's about behaviour and impact, not character or attitude.
- A verifier with management experience is best placed to judge this milestone.
You'll sign in first, then come straight back here.
Write a team charter together
4–8 weeks from joining the team (run the session async or sync across 1–2 meetings)
Write a team charter with four parts. How the team makes decisions. Working hours and communication norms. What 'done' means. How you handle disagreements. Every team member makes at least one edit. Publish it where the whole team can find it.
Proof required
Share the charter as a link or document. Show every member contributed, through comments, edit history or sign-offs. Add 100 words on which section caused the most discussion and why.
What gets checked
- All four parts are covered, not just one or two.
- Every member's contribution is visible. One author with signatures isn't a team charter.
- The hardest section is named, showing it surfaced a real gap.
Common mistakes
- You write it alone and ask for sign-off. The value is in the disagreements.
- It's so generic it fits any team. Then it doesn't describe yours.
- It's published and never used again.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask which part the team has used since publishing. None means it's just a document.
- Check edit history or named comments. 'Everyone contributed' on its own isn't evidence.
- The discussion section should name a real disagreement the team worked through.
You'll sign in first, then come straight back here.
Resolve your first real team conflict
Whenever a real conflict arises — if no conflict has arisen, the more likely explanation is that people do not feel safe disagreeing
Two people on your team disagree, and it's affecting their work or the team's output. Don't pick a side. Talk to each person alone to understand their view. Then run a conversation with both of them. Write down what was agreed.
Proof required
Write 300 words, names removed. Cover what the conflict was about and how you spoke to each person alone. Cover how you ran the joint conversation and what was agreed. Add 100 words on what you learned about how you handle conflict.
What gets checked
- The conflict affected work, not just feelings. Slowed delivery counts; mutual dislike doesn't.
- You spoke to each person alone before bringing them together.
- A resolution is written down. Partial counts; 'we talked' doesn't.
Common mistakes
- Waiting until it becomes a resignation or a performance issue.
- Taking a side before hearing both. Any hint of bias reaches the team within a day.
- Calling it resolved when one person just won. If someone feels unheard, it's suppressed.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask whether the two now work well together. If not, it was managed, not resolved.
- The account should give each person's view before the joint talk.
- A verifier who has led a team is strongly preferred here.
You'll sign in first, then come straight back here.
Deliver a real project through the team
8–16 weeks depending on project scope — this is the capstone; it takes as long as a real project
Take a meaningful project from requirements to shipped, without writing the code yourself. Your job is to clarify requirements, remove blockers, run the process and update stakeholders. It must ship to production or reach a real user.
Proof required
Write a 400-word case study. Cover the project and your contribution as manager, not engineer. Cover the blockers you removed and how you updated stakeholders. Add one thing you'd change. A team member on the project must verify this proof on Powstik first.
What gets checked
- Your contribution is managerial. If it's about your code or design choices, start over.
- A team member verifies it before you submit. Self-reporting isn't enough here.
- The 'do differently' point is specific, like a kickoff to agree what done means.
Common mistakes
- Slipping back into coding because it's easier. It slows your team's growth and yours.
- Claiming the team's technical decisions. The verifier will see it.
- Submitting without a team member's verification. It is required at this milestone.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- The team member's verification is required. Ask them what this manager did that helped.
- The answer should be unblocking, clarity, process or stakeholders. If it's technical, flag it.
- Confirm the project actually shipped before you approve.
You'll sign in first, then come straight back here.
Part of