Leading project as code

Project success is owned by team, the failure by project lead.

Start with your own motivation

---

Focus on value adding results(impact maybe) by solving harder challenges to grow faster with pleasure as a team. Basically, boils down to 3 things: impact, domain knowledge and collaboration. Less toil work is preference.

Project success matters, but as the Project lead added values are:

• Lowering risks

• Tactics: improve speed, quality, communication effectiveness, approach to challenges, surprises, team morale

• Communication methods: early and often: simple, clear and concise.

• Team Morale: less stress, toil and distractions

• Delegatable and replayable faster execution

• Any situational patterns, challenges generalizable requires team, organization level attention?

• Being last in line and picking stuff may left behind and/or unblock if can

Get some external inspirations

---

There are many books, but below ones are good enough to get started.

Inspiration 1: Book “Extreme Ownership” is written by Jocko Willink and Leif Babin.

Here are some of my takeaways, hope you will find it useful:

1. Take total responsibility, own failures, pass the wins to team.

2. Enforce high standards as a lead, it is not what you preach, it is what you tolerate.

3. Leader must be a true believer in the mission for others to follow. Ask questions until you understand why, so can believe and pass down the chain with confidence.

4. Most difficult ego to deal, is our own ego. It drives us to win and be best. But, it may also harm our judgement and be disruptive.

5. "Us versus them" mentality. 1 team 1 mission. Work together to win.

6. It is critical to keep plan and communication simple, clear and concise.

7. Problems can compound in a snowball, each demanding attention. As a lead, stay calm to prioritize and execute best to your knowledge.

8. Trust is built over time, not blindly given. Empower others to make decisions and take initiatives. 4-6 is ideal team size to lead.

9. Checklist for planning:

- Analyze the mission
- Identify personnel, assets, resources and time.
- Distribute and delegate the plan
- Focus efforts on best simplest course of action
- Have a contingency plan to mitigate risks
- Continually check and question plan
- Brief the plan to team
- Conduct debrief after execution

10. Leadership not just flow down the chain of command, up as well.

11. Act on logic, not emotion. Waiting 100% right and certain solution leads to delay, indecision and inability to execute.

12. Leader must lead, but also ready to follow. Discipline and freedom are opposing forces that must be balanced.

Inspiration 2: Book “The Phoenix Project” is written by Gene Kim, Kevin Behr, and George Spafford.

1. Align Engineering goals with Business goals

2. Create a collaborative culture of continuous experimentation and learning using tree structure knowledge base.

3. Use actionable metrics to measure and improve Engineering productivity, quality of process and product

4. Create feedback loop to keep iterating and improving

5. Manage the vendor, product and any other dependencies to ensure reliability and stability

Conclusion

No book can tell a leader exactly how to lead in every situation. Leadership is simple, but not easy. It is both art and science.

PST Playbook

---

Process

• How to enable less shy, more Question/Help asking as habit resulting in more clarity, and improving our problem solving skills? Asking ourselves, chatgpt, google, team cross team, vendor, even community?

• What is a best way to communicate urgency without creating sense of pressure or micromanagement?

• How we can do upfront escalation and reach outs?

• What is a best way to create guardrails in project to timebox efforts?

• How to be a good role model for a team?

• How we can enable admitting early accidental or assumptional mistakes?

• How we can calibrate our mistakes and learnings to feedback into project to be better of us?

• Any loops? Asking team to guide us to guide them?

• How to improve communication to be: simple, clear and concise?

• How we can develop approach to faster response and not react to challenges?

• How we can gain more control in project and make it more predictable?

• How we can be more accountable? Quantify the progress made, if the result still is not achieved? By writing more and sharing with team?

• If we stuck, how enable to start with #whatweknow and keep iterating till building confidence, merging our partial brain dumps to be in same page?

Scope

Manager → Project Lead

• Why are we doing it?

• Why it matters?

• Why it is even priority now? Next Q?

• What if we don’t do it now?

• What are the risks if we fail doing it or pass deadline?

• What needs to be done, by when and team assigned?

Project Lead → Tech Lead / Project Team

• What team is expecting from project leading style? Is it clearly communicated?

• What is team spirit level? Do we have on call engineer in project and/or any other commitments for team outside scope of project?

• What are the checkpoints(milestones, phases) in a project?

• What are the key project artifacts or deliverables, timeline and quality and is team aware of them?

• List risks and mitigation strategies if any: dependencies, surprises, challenges, uncertainty or ambiguity?

• Are the standups good enough for a project or better set 11s to make team more productive?

• Buffer time added to the scope?

Atomic tasks

💡 Each block is a piece of art and can be internally, publicly shared.

Can the project broken down to atomic single owner blocks and what are the concurrency and sequential executions? Any constraints?

• Owner: X

• Target Date: Y

• Output type: Spike, Design, Code, Playbook etc.

• Dependency/blockers/risks: approval, team, crossteam review meeting, vendor, release, other block.

  • L0 - No dependency

  • L1 - 1 dependency

  • Ln - Nested dependency level

• #DONE success criterias - Final Quality check

  • List success metrics

  • List deliverables

• Updates

  • Tickets/stories/tasks status

  • (Optional) Inform project team if needed to unblock.

• Activity(Optional): Training, Room for experiments, learnings, not contributing to the result.

• Mentor/Peer review(Optional): Name Z

• Selfcheck (Optional, but key for fastrack growth):

  • Do I know how to do it?

  • How can I do it fast and qualitative?

  • Replayable for later me?

  • Delegatable for somebody else?

  • How we can not do it?

  • Anything I learned that can be used in other projects, even shared publicly?

Team

Map of organization, teams, individual levels:

• Distritube atomic nodes more effective and efficient way with ideal quality and acceptable risks.

Organization level:

• Meet any business or other teams OKRs.

Team level:

• Effectiveness (meet scope by deadline)

• Efficiency (adjustable velocity, team size, scope change )

• Quality (playbook, code standards, best practices, naming conventions, observability, production readiness checklists)

  • acceptable

  • ideal

  • amazing

• Risk level

  • acceptable

  • blocker

  • depends

Individual Contributor level:

• Not commit - Revisit project scope with Tech leads and managers.

• Commit, not deliver - Check if any other priorities, blockers or personal reasons, clarity in task, ask team for help.

• Commit, deliver, lack of quality - Help with Mentor / Pair for guidance.

• Commit and deliver with stress - Check for cause, ask for feedback to do better.

• Commit and deliver without stress - Good job!

Code - Fun part

---

Have you heard about that amazing project called Mermaid? If not, you should and we are going to use for codifying our project and start again enjoying our individual contributor role helping to team where we can.

Mermaid is a JavaScript-based diagramming and charting tool that uses Markdown-inspired text definitions and a renderer to create and modify complex diagrams. The main purpose of Mermaid is to help documentation catch up with development.

flowchart LR
classDef y fill:#f0d800,stroke:#000,color:#000
classDef g fill:#6ad98b,stroke:#000,color:#000
classDef r fill:#b30000,stroke:#000,color:#000

%% Project level %%

Project1(Automate project leadership) --> Deadline
%% Project1--> Quality-->Acceptable
Project1--> Team
Project1--> Risks
Project1--> Scope

%% Timeline %%

Deadline --> 02/28/2023
Deadline --> P1 --> 02/01/2023
Deadline --> P2 --> 02/14/2023
Deadline --> P3 --> 02/21/2023
Deadline --> P4 --> 02/28/2023

%% Team %%

Team --> P(Peter)
Team --> S(Sako)
Team --> T(Tom)


%% Risks  %%

Risks --> R1(Fail to be effective)


%% Scope %%

%% Phase 1 %%
%% T - Tasks, D - Delivery success criteria, O - Output type, U - Updates

Scope --> P1(Phase 1)

P1-->P-->T1-->CreatePoster(Poster: Using Mermaid create poster for blog):::g
P1-->S-->T2-->PostInSocials(PostIn: Linkedin):::g
P1-->T-->T3-->PostInSocials(PostIn: Twitter):::g


T1-->O1(Code)
T1-->D1(Build, test and merge PR):::g

T2-->Out2(Poster)
T2-->Done2(High Q post):::r

T3-->Out3(Blog)
T3-->Done3(Publish in Substack):::g
T3-->U31(Blocked on Poster)-->U32(Still waiting)-->U33(Done)

%% Scope changes in Phase 1 %%

%% Phase 1 Summary %%
P1-->S1(Completed Phase 1 ontime, poster quality was low, so we will try in upcoming phase focus more on quality.)

And you get below nice generated tree structure diagram. It makes easier to plan for concurrent atomicity, unblock any dependencies and identify potential risk in project including the delays not obvious.

Contribute to the project in Github.

Play with it Online.