**Period**: Feb 2026 – Jun 2026 (4 months)
**Review cadence**: Every 4 weeks (self-review); adjust if priorities shift
**Context**: Transitioning from Senior Engineer toward a role that blends technical leadership with people development
**Hub**: [skepp.md](skepp.md)
---
**Why**: The engineering landscape is shifting fast. Staying current is not about knowing every tool — it is about developing judgment and fluency that makes you useful to the team and credible as a technical leader.
| # | Key Result | Target | Status |
| --- | ---------------------------------------------------------------------------------------------------------------------------- | -------------- | ------ |
| 1.1 | Ship one self-directed AI-integrated project end-to-end (ideation engine counts) | By May 2026 | |
| 1.2 | Identify and close one meaningful technical gap (e.g. architecture patterns, AI integration, infra) through deliberate study | One gap closed | |
| 1.3 | Share at least 2 “AI in engineering” practices or learnings with the team — in a retro, doc, or conversation | 2 shares | 1/2 — Mar 2026: applied MLP concept to a ticket, commented specific suggestions, shared with Sway (credited his post as source) |
• Continue building ideation engine as a living experiment
• Use learning budget for one focused course or resource
• Write short internal notes after learning something worth sharing
---
**Why**: As the role evolves toward people leadership, the aim is to lead cycles through others — planning, unblocking, reviewing — rather than through personal output. This requires intentionally pulling back while keeping quality high.
| # | Key Result | Target | Status |
|---|-----------|--------|--------|
| 2.1 | Lead at least 2 full development cycles (planning → delivery → retro) with reduced personal coding contribution | 2 cycles | 2/2 in progress — Cycle 1 complete (Feb 2026); Cycle 2 kicked off Mar 3, 2026 with Sway actively involved, prototypes submitted Day 1 |
| 2.2 | Run at least one planning session per cycle where the team generates the approach, not you | Per cycle | |
| 2.3 | Track your own leading-to-coding ratio across the 4 months; aim for a visible shift toward more leading by June | Directional trend | |
• At the start of each cycle, ask: "What can I delegate completely?"
• Actively hold planning and retro conversations rather than just participating
• Note where you default to coding when you should be unblocking
---
**Why**: People leadership is happening organically. The goal now is to become more intentional about it — to invest in people well, grow in coaching skill, and build a track record of real impact in the people you are walking with.
| # | Key Result | Target | Status |
|---|-----------|--------|--------|
| 3.1 | Hold regular growth conversations with each person you are walking with (intermediates + juniors) — at least once every 3–4 weeks | 5+ conversations per person | Jian-Wei: first individual 1:1 Mar 4, 2026 (discovery session) |
| 3.2 | See at least 2 visible growth outcomes in the engineers you are mentoring — captured and named | 2 outcomes | Early signal (not yet counted): Jian-Wei instinctively applied a “lovable” approach to his Cycle 2 prototype — named and affirmed in feedback (Mar 2026) |
| 3.3 | Invest in one people leadership resource (book, course, or structured reflection) and apply at least one thing learned | 1 resource applied | |
| 3.4 | Deliver at least 2 pieces of direct, kind, timely feedback to someone you are walking with | 2 feedback moments | 1/2 — Mar 2026: affirming feedback to Jian-Wei on his prototype, connecting his instinct to the MLP concept |
| 3.5 | In at least 3 coaching conversations, stay in ask-mode for the majority of the session — self-assessed after each | 3 sessions | 1/3 — Mar 4, 2026: first 1:1 with Jian-Wei ran predominantly in ask-mode (self-assessed) |
| 3.6 | Follow up individually with the junior engineer who left the Feb session without clear direction — close the loop with a concrete next step agreed | Done by Mar 2026 | Done — Mar 4, 2026: individual 1:1 held, concrete next steps agreed (AWS cert + Cursor skill/workflow as 3-month focus) |
• Schedule lightweight recurring slots for conversations (even 20 mins counts)
• Keep a short log per person: what is growing, what is stuck, what to address next
• Use learning budget for a coaching or people leadership resource
• Read the conversation guide *before* each session, not during — familiarity is what keeps you on it under pressure
• After each significant conversation, do a 5-minute debrief: what did I tell vs ask, what was missed, what needs following up
• Default to 1-on-1 format; only use combined sessions when the topic is genuinely shared and the individuals are at the same place
• When you feel jitters: slow down, ask one question, and wait — do not fill the silence with an explanation
---
**Why**: NextSteps is going to maintenance after 3.5. The engineers currently on legacy will lose their primary work context. The Lovable/AI discussion is reshaping how product thinks about engineering. Without deliberate action, engineers who don't adapt will become redundant — not because they lack skill, but because no one built a path for them. This objective is about building those paths: the structures, platforms, and culture that keep engineers central in an AI-era org.
| # | Key Result | Target | Status |
|---|-----------|--------|--------|
| 4.1 | Present the strategic proposal (Scoria + knowledge sharing + budget accountability) to Tatai. Receive feedback and confirm direction. | Done by end of Mar 2026 | |
| 4.2 | Launch the budget accountability system — all engineers informed, first monthly declarations completed, first share-back session held. | First session by mid-Apr 2026 | |
| 4.3 | Run at least 1 cross-team knowledge-sharing session (greenfield ↔ legacy) on architecture or AI-native development patterns. | By end of Apr 2026 | |
| 4.4 | Produce a concrete Scoria concept document — scope, architecture direction, integration points, first useful slice — that Tatai and Charles could evaluate. | By end of May 2026 | |
| 4.5 | Run one engineer-driven initiative cycle end-to-end (identify → frame → propose → build → measure → share) — either personally or by supporting an engineer through it. Demonstrable outcome with before/after measurement. | By end of May 2026 | |
• Book time with Tatai — lead with the strategic question (NextSteps to maintenance), not the proposal
• Tell all engineers about the $200/month — confirm it's real, share the acceptable uses, give them the monthly template
• Identify which greenfield engineer (Siyang is most likely) would run the first knowledge-sharing session and what topic they'd cover
• After the Tatai conversation: write up any changes to the proposal and share with Charles
• Keep a record of what each engineer does with the budget — this becomes the evidence base for continuing (and expanding) the program
• Pick one AI ops or legacy stewardship problem and run the first initiative cycle personally — use it as a demonstration to teach the process to others
• Identify which engineer (Siyang is the best candidate) to pilot the initiative lifecycle with first
---
> Am I growing into the kind of leader others will look back on as a meaningful influence — or am I just being busy in the right direction?
---
_(Add notes after each monthly review)_
**Early observation (Feb 2026)**: First combined junior session (2-on-1) revealed a real gap in coaching under pressure — defaulted to telling over asking. One engineer left more confident; one still unclear on direction. Skill matrix and individual OKRs still to be completed for juniors. Key personal observation: jitters in that format are real; preparation and familiarity with the guide before the session would help. Good instincts on content, weaker on facilitation discipline.
**Feb 25, 2026 — Media Files Cycle 1 Retro**: Led full cycle (planning → delivery → retro). Team gave unprompted positive feedback on leadership, planning quality, clear tickets, and communication — "really well planned and executed from an engineering standpoint." Retro started without preparation — had to wing format, logistics, and structure until Charles joined midway. Key leadership difficulty surfaced: product/UX/engineering disconnect is structural and can't be solved from within engineering alone — Charles communicates to Sway/Aaron but the loop isn't closing — retro actions haven't produced change. Team morale affected by feeling that retro actions don't produce change. Action identified for next cycle: prototype-first approach, single feature branch, merge behind flag by Wednesday of week 3, then iterate on feedback and touchups.
**Late Feb 2026 — Process reform week (retro + GM 1:1 + junior session)**:
Three back-to-back sessions on the same structural problem from three different angles.
• *Retro (Cycle 2 lead)*: Advocated for team health. Raised the absence of real Product contact with the team — “Product” arrives as vague pressure (e.g. “Product feels we are going too slow”) through Charles, never from an actual product person. UX removed from the process. Whether Product even knows the cycle shortened to 3 weeks is genuinely unclear — that ambiguity was named directly. Raised the pattern of cycles ending with incomplete or feedback-rejected work. Proposed prototype-first approach: prototype early with minimal design, demo to Product/UX via stage, then production-ready in phases. Team receptive; Charles leaned on prior corporate experience for ideas.
• *1:1 with GM (Charles)*: Aligned on the prototype-first experiment — rapid prototype from low-fidelity design or basic user story only, followed by a stage demo for Product/UX feedback, then production readiness. This is now the agreed approach to pilot. Key clarity from this session: “Product” has never been a real person in direct contact with the team — feedback like “Product feels we are going too slow” arrives as vague pressure through Charles, with no named person or direct conversation. Whether Product was even aware of the 3-week cycle change is genuinely unknown — that ambiguity was raised directly. Concrete outcome: Charles secured department lead agreement to free up product manager Sway to join cycle stand-ups going forward. First real Product contact in the process if it holds.
• *Planning discussion with junior*: Detailed the 3-week cycle structure — Week 1: functional prototype + must-fix/non-negotiable feedback; Week 2: production readiness based on must-fix; Week 3: polish, QA, deploy. Also discussed branching strategy, tech debt streams (maintenance mode), and deferring UI styling work. Notes in `work/Planning Discussion.md`.
• *OKR links*: 2.1 progressing (next cycle will test the new approach); 2.2 relevant (team is being brought into the approach rather than just handed tickets). The prototype-first design also comes from Obj 2 intent — lead cycles through structure, not personal output.
• *Ongoing context*: Still head above water across three active areas — cycle planning and execution, technical assessments preparation, and people development. The influence is reaching further than the immediate team, which is both an opportunity and a weight.
**March 2026 — Cycle 2 Kickoff (Mar 3)**:
First real kickoff with Sway (product manager) present — the first time Product has been in a direct team meeting. Presented the 3-week cycle structure and 3 parallel workstreams (one per engineer). Sway was engaged and enthusiastic about joining ongoing team meetings. The rest of the team (2 engineers + QA) were quiet — they already knew Sway and had nothing to add. Presentation felt unrehearsed and talk-heavy; hard to benchmark without a peer reference for this team context.
All 3 engineers submitted first prototypes on Day 1 and began requesting feedback from Sway — noticeably faster cadence. Set a format for feedback requests by leading with the first concrete example. A question surfaced about whether Sway/Charles could generate PRs directly from codebase ideas — explained Linear/Cursor integrations and the backend incompatibility challenge, and proposed a dedicated product experimentation environment as a scoped experiment.
MLP (Minimum Lovable Product) concept picked up from Sway's post in the org's AI Slack channel — applied it to a ticket immediately, commented specific suggestions, and credited the source back to Sway. First concrete instance of translating external AI/product thinking into team-level application (KR 1.3: 1/2).
*OKR links*: 2.1 — Cycle 2 now in motion (2/2 in progress); 2.2 — format for feedback requests and kickoff structure shaped by engineer input; 1.3 — first share completed (MLP on ticket).
**March 4, 2026 — First individual 1:1 with Jian-Wei (discovery)**:
Ran the session using the [jian-wei-1-1-cheatsheet](people/jian-wei-1-1-cheatsheet.md). Goal was discovery: who he is, what he wants. Stayed predominantly in ask-mode; closed with “what was most useful,” “one thing to think about,” and stated takeaway. Jian-Wei left with concrete 90-day focus: finish AWS Cloud Practitioner cert (already ~20% through), and use “writing my own Cursor skill or workflow” as a measurable milestone for AI proficiency. He engaged openly — rabbit holes (AI planning/clarifying questions, writing/communication), satisfaction from both clean code and visual output, MLP instinct confirmed as deliberate. You named the team vision/mission gap (stories from the field) as a coaching moment and reflected back that he could have impact there without a formal role.
*OKR links*: 3.6 — done (loop closed); 3.5 — 1/3 (ask-mode held); 3.1 — Jian-Wei first individual conversation logged; 3.2 — early signal (MLP affirmation) not yet counted as full outcome.
**April 2026**:
**May 2026**:
**June 2026 (close-out)**: