Lead an Engineering Team for the First Time

Proof required

Submit your 1:1 notes for each direct report with names redacted. Notes must include: one thing each person wants to learn, one thing that frustrates them, and one specific commitment you made to them. Add a 150-word reflection on what surprised you most about these conversations.

What gets checked

• Notes exist for every direct report — not just the ones you were already close to; every person gets the same quality of conversation
• Each note has a specific commitment from you, not 'I'll think about it' — a commitment is a defined action with an implied timeline
• The surprise reflection identifies something that actually surprised you — generic 'they want to grow' reflections indicate you did not listen deeply enough

Common mistakes

• Turning 1:1s into status updates — if you spend more than 20% of the time on project status, redirect; this time belongs to the person, not their tasks
• Talking more than listening — target a 30/70 ratio where you speak 30% and listen 70%; most new managers invert this instinctively
• Not taking notes during or immediately after — memory fades within 24 hours; your notes are both proof and the foundation for future 1:1s

Resources

Arena

What a verifier looks for

• Ask the submitter: 'What did you commit to for your most junior direct report?' — if they cannot recall, the 1:1s were status updates, not real conversations
• The notes should show curiosity, not agenda — look for open-ended questions and specific details about the person, not project status
• Verify notes exist for every report — a new manager who skips 1:1s with reports they already know has not completed this milestone

You'll sign in first, then come straight back here.

Proof required

Submit the retro output document: what worked, what didn't, what to try, and the action items with single named owners and specific deadlines. Add a 100-word reflection on one thing you did as facilitator that you would do differently next time.

What gets checked

• Every action item has a single named owner — 'the team will do X' does not count; ownership must be individual
• At least one action item has a deadline within the next sprint or week — demonstrating the retro produces near-term accountability, not distant intentions
• The facilitator reflection identifies something specific you would change — 'it went well' is not a reflection; name the moment that was hardest to facilitate

Common mistakes

• Letting the retro become a complaint session with no action output — the output is not 'we discussed issues'; it is a list of named actions with deadlines
• Dominating the discussion instead of drawing out quieter team members — if only the loudest people spoke, you participated, not facilitated
• Accepting action items without owners — they will not happen; push back in the session until every action has a name attached

Resources

What a verifier looks for

• Read the action items — are they specific and owned? 'Improve communication' is not an action item; 'Sara sends a Monday async update by 10am' is
• Ask the submitter which action item from this retro was actually completed — if none were completed, the retro did not produce accountability
• The facilitator reflection must name a specific moment in the session, not a general observation about retrospectives

You'll sign in first, then come straight back here.

Proof required

Write a 200-word account of the feedback conversation: what you said (verbatim if you can recall), how the person responded, and what you agreed as the next step. Do not name the person. Add a 100-word reflection on what made the conversation hard and one thing you would do differently.

What gets checked

• The feedback described was specific and about behaviour, not character — 'you missed three deadlines this sprint' not 'you are disorganised'
• A specific next step was agreed between you and the person — not implied or assumed; agreed means the person said yes to something concrete
• The 'what made it hard' reflection is honest — if you write 'it was fine actually', either the feedback was not difficult or you are not reflecting

Common mistakes

• Giving feedback via Slack or email to avoid the discomfort of a live conversation — difficult feedback must be delivered in person or on video; anything else is cowardly and ineffective
• Softening the feedback so much the person does not understand what needs to change — if you are not sure they heard the message, they probably didn't
• Not agreeing a specific next step — without one, the conversation produced clarity for you but not accountability for them

Resources

What a verifier looks for

• Ask the submitter: 'Did the person understand what needed to change?' — if they are not sure, the feedback was not specific enough
• The feedback described should be about behaviour and its impact, not character or attitude — character feedback causes defensiveness; behaviour feedback produces change
• A verifier with direct management experience is ideal for this milestone — assessing whether feedback was real and effective requires lived experience of delivering it

You'll sign in first, then come straight back here.

Proof required

Share the team charter as a live link or document. It must show evidence that all team members contributed (comments, edit history, or explicit acknowledgments). Add a 100-word account of which section generated the most discussion and why it was hard to agree on.

What gets checked

• Charter covers all four sections: decision-making, communication norms, definition of done, and disagreement handling — not just one or two
• Evidence of every team member's contribution is visible — edit history, named comments, or a sign-off list; a charter one person wrote and others signed is not a team charter
• The section that generated discussion is named specifically — this shows the charter surfaced a real gap in how the team works, not just documented what everyone already agreed on

Common mistakes

• Writing the charter alone and asking people to sign off — this produces your charter, not a team charter; the value is in the disagreements surfaced during the process
• Charter so generic it could apply to any team anywhere — if you could copy-paste it unchanged into a different team, it has not captured how your team actually works
• Publishing the charter and never referencing it again — a charter only has value if you use it to make decisions or resolve disagreements

Resources

What a verifier looks for

• Ask the submitter: 'Which part of the charter has your team actually referenced since publishing it?' — if the answer is none, it is documentation, not a working agreement
• Verify evidence of team contribution in the document — an edit history or named comments list is sufficient; self-reported 'everyone contributed' is not
• The discussion section should name a specific disagreement the team worked through — 'everyone agreed on everything' means the charter was too vague or the conversation was not real

You'll sign in first, then come straight back here.

Proof required

Write a 300-word account (all names redacted): what the conflict was about, how you approached each person separately, how you facilitated the resolution conversation, and what was agreed. Add a 100-word reflection on what you learned about your own conflict-resolution style.

What gets checked

• The conflict was real and affected work output, not just interpersonal tension — 'two people dislike each other' is tension; 'their disagreement is slowing delivery' is a work-affecting conflict
• You spoke to both people separately before bringing them together — one-sided information leads to one-sided resolution; separate conversations first is non-negotiable
• A resolution was reached and is documented — even a partial resolution counts; 'we talked' without an agreed outcome is not resolution

Common mistakes

• Avoiding the conflict until it becomes a resignation or a performance issue — conflict avoided is conflict compounded; the longer you wait, the worse the options
• Taking sides publicly before hearing both perspectives — even one private comment showing bias will be known by the whole team within 24 hours
• Confusing resolution with one person winning — if one person feels unheard after the resolution conversation, the conflict has been suppressed, not resolved

Resources

What a verifier looks for

• Ask the submitter: 'Are the two people still working effectively together?' — if not, the conflict was managed, not resolved; managing and resolving are not the same thing
• The account should describe what each person's perspective was before the joint conversation — single-perspective accounts mean the submitter only heard one side
• A verifier with team leadership experience is strongly preferred — assessing whether a conflict was resolved well requires experience with what failure looks like

You'll sign in first, then come straight back here.

Proof required

Write a 400-word case study: what the project was, what your specific contributions were as manager (not engineer), what blockers you removed, how you communicated to stakeholders, and one thing you would do differently. Get one team member who worked on the project to endorse this proof on Powstik before you submit.

What gets checked

• Your contributions are managerial, not technical — if the case study focuses on code you wrote or architecture decisions you made personally, start over; that is IC work
• A team member endorsement is required before submission — self-reporting the final milestone is not sufficient; endorsement is what separates claimed leadership from demonstrated leadership
• The 'what I would do differently' is specific — 'I would have communicated more' is not specific; 'I would have run a kickoff to align on definition of done before sprint 1' is

Common mistakes

• Slipping back into coding because it is faster and more comfortable than managing — every time you write code the team should have written, you delay their growth and undermine your own transition
• Taking credit in the case study for technical decisions that were the team's — this will be visible to the verifier; the case study should celebrate the team's output
• Submitting without a team member endorsement — the endorsement is not optional at M6; the entire point is that someone else confirms your managerial contribution

Resources

What a verifier looks for

• The endorsing team member is mandatory — do not approve M6 without it; if possible, ask the endorser directly: 'What did this manager do that made the project go better?'
• The answer to that question should be about unblocking, clarity, process, and stakeholder management — if the endorser names technical contributions, flag this to the submitter
• The case study must describe a real shipped project, not a work-in-progress — confirm the project status at time of review before approving

You'll sign in first, then come straight back here.