Managing software projects & teams effectively
2 likes906 views
The document discusses effective project and team management strategies, highlighting the importance of team structure, roles (such as product managers and technical leads), and processes in achieving product success. It emphasizes the need for clear communication and collaboration among different teams while detailing the product lifecycle from ideation to launch and maintenance. Additionally, it underscores the significance of performance metrics and iterative processes in improving productivity and minimizing waste.
Managing software projects & teams effectively
- 2. Team Structure Effective Process Product Lifecycle
- 4. Services aka Teams Conway’s Law: “Organizations which design systems … are constrained to produce designs which are copies of the communications structure of these organizations”
- 5. Company Product A Product B Frontend BHorizontal FunctionsFrontend A Backend A Backend B ● Functional vs Horizontal Teams ● Structure of a team
- 7. Functional teams ● Goal: agility. ● Services are product specific ● Responsible for both frontend & backend services. ● Connect with backend infrastructure services to do heavy lifting.
- 8. Infrastructure Teams ● Goal: stability. ● Functional -> Product Infrastructure -> Core infrastructure ● Each service is used by variety of clients. ● Pre-contracted SLA contract: QPS, performance ● Company-wide / Product-wide impact.
- 9. Infrastructure teams: examples ● Common layer for container deployment & orchestration ● Microservices framework. ● Common monitoring framework. ● Common alerting framework. ● Common storage offerings with inbuilt usage monitoring.
- 12. Structure of a (Productive) Team
- 13. Bottom-up (mostly) ● People come up with ideas ● Pitch ideas / prototype ○ To fellow engineers, managers ○ To leadership, customers ● Gain momentum. Move fast. Move faster. ● It’s like running a startup The Why
- 14. The Why Effective flat hierarchy operation ● Different functions ○ Product vision ○ Technical complexity ○ Process leadership ○ Maintaining stability ● Different individual skillset ● Different teams different priorities.
- 15. 4 key players ● Product manager ● Technical Lead (TL) ● Program Manager ● SRE The What
- 16. Product Manager ● Provides direction & vision for the product ● mini-CEO for the product ● Works with TLs/UX to define detail specifics ● Works with Sales, Marketing for go-to-market strategy “It is like being the Conductor of an orchestra”
- 18. Strategy is the key role, but PMs are the necessary glue for everything else.
- 19. Product Manager != People Manager Influence without authority
- 21. Technical Lead a.k.a TL ● Provides technical direction ○ Getting the technical architecture right ○ Negotiating product specs with PMs ● Responsible for keeping eng-team productive ○ Coordinates sub-tasks within team ● Main point-of-contact with external teams ● Not a manager, and has no reports usually
- 23. Contribution styles Technical complexity (my code, my algos) Leadership (my team x 10) Impact (my company) From Junior SWE to TL
- 24. Program Manager ● Provides structure to big projects ● Influence spans multiple teams ● Manage plans, schedules and drive deployment of projects ● Proficient in technical details and organizational skills ● Influence authority through processes and structure
- 25. Site-Reliability-Engineer (SRE) ● Responsible for keeping downtimes low (add another 9) ● Responsible for building and maintaining large scale production services ● Responsible for capacity planning ● Not all teams have SREs - they have to earn the traffic to have one.
- 26. SREs optimize for uptime, not for egos of individual teams / people
- 27. Product Manager Product Sense Technical Lead Technical complexity SRE Maintaining stability Program Manager Process Leadership
- 28. People Managers What do they do ? ● Coach. Help people achieve their individual goals ● Well-being & employee success. Finding the right team-fit. ● Collate feedback from a person’s peers. ● Resolve interpersonal issues. Who are they ? ● Sometimes TLs are TLM (TL + Manager) ● Part of a larger team, but not responsible for product decisions
- 29. Life of a Product
- 30. One good product, and many many bad products “ … no good product-market fit” “ … there were too many things changing. In the end, the backend architecture was a mess:. “ … it was too bloated. Maintenance hazard” “ … too much coordination was required across different teams”.
- 31. It’s worthwhile thinking about each part Propose Plan Execute Maintain. Refactor. Deprecate
- 32. Double Diamond: Strategy + Execution of the right solutioin
- 33. Propose. Propose Plan Execute Maintain. Refactor. Deprecate Step 1: PM / TL have an idea Step 2: Create a short Product-requirement document (few paragraphs) and circulate it quickly among team(s). Step 3: Discuss & iterate. Output - Vision Document - Product Requirements Document
- 34. Plan. Propose Plan Execute Maintain. Refactor. Deprecate Step 4: Technical design / architecture proposal Step 5: Circulate it among your own team first. Step 6: Resolve feedback, rinse repeat. Step 7: Circulate the design doc with other impacted teams Step 8: Define milestones and respective scopes, Two special milestones - “dogfood” and “launch” Output - Technical design doc with full detail - Milestones & Dependency plan
- 35. Execute. Propose Plan Execute Maintain. Refactor. Deprecate Step 9: Code, Code, Code. Daily / Bi-weekly standups until milestones. Step 10: Dark Launch (feature / product only enabled for the team) Step 11: Company dogfood launch Step 12: Public Launch Output - Product - Emergency playbook
- 36. Maintain. Refactor. Step 13: Discover bugs. Fix bugs. Push regularly. Step 14: More teams want to launch similar stuff. They want to reuse some components. Refactoring galore ! Fun fact: Google code changes about 50% in a year. Output - Stable Product - Reusable infrastructure
- 37. Deprecate. Propose Plan Execute Maintain. Refactor. Deprecate Step 15: Some more generic infrastructure components are identified and new backend created. Step 16: Slice of traffic is sent to new backend to try it out. Step 17: New backend is stable. Traffic to old backend is turned off. Step 18: Old backend is turned off and deleted if no one is using it. Output - Stronger, Faster, Higher
- 38. Product Requirements Doc (PRD) Defines the “What”, “Why” and for “Whom”. “If PRD is done well, still might not be a successful product, but it is certain that if the PRD is not done well, it is nearly impossible to build a good product. “ - Silicon Valley Product Group
- 39. Technical Design Doc (by Malte Ubl, Tech Lead Google AMP Project) Goals ● Document the software design. ● Clarify the problem being solved. ● Act as discussion platform to further refine the design. ● Explain the reasoning behind those decisions and tradeoffs made. ● List alternative designs and why they were not chosen. ● Support future maintainers and other interested parties to understand the original design. Non-goals ● Establish non-technical requirements of the software. ● Be independently understandable by a person with no background in software stack. ● Act as user documentation for product or system.
- 40. The Chromium projects (Design Docs) http://dev.chromium.org/developers/design-documents http://aosabook.org/en/posa/high-performance-networking-in-chrome.html
- 41. Oncall Playbooks “Hope is not a strategy.” ● Note down past failures, ○ What went wrong ○ What was the immediate fix ○ What is the long term fix ○ How to prevent it in future. ● Avoiding culture of “heros”
- 43. Everything is process ... Whether you’re compiling code, hiring staff, or making breakfast. - Andy Grove, High Output Management
- 44. Software Development is often chaotic ● Changing Product Requirements ● Changing feature priorities ● Tendency to over-engineer ● We don’t know whether this new feature will work or not.
- 45. Role of a process, is to improve effective productivity of the overall team towards the goal.
- 46. Examples Requirements gathering, build better products Planning & estimation, unwrangle dependencies Agile development, reduce engineering waste Triage, reduce backlog Launch checklist, follow best-practices Infrastructure Integration Process, communicate requirements
- 47. Process in various stages of product
- 49. Ruthlessly measure progress ● Define milestones ○ Date - Monthly / quaterly ○ Features / items in scope ● Define progress ○ What metrics ○ Define levels of achievement ■ Red = Below Expectations ■ Yellow = Meets expectations ■ Green = Stretch Goal ● Product launch is just one of the milestones Old adage - what you can measure, is what you can improve.
- 50. OKRs Objectives & Key Results
- 51. Iterations ● Unit of time for progress check ● 2 week to 1 month long ● Priorities should remain constant within a sprint ● Execution style: agile vs waterfall From one sprint to next, specs might change, priorities might change. Minimize throw away work. Software time estimation is hard. Iterations help manage estimation risk.
- 52. (Over) Communicate ● Not just about informing stakeholders ● What is working, what is not. ● What is pending, what is not. ● What is working amazing, what needs more work. Most engineers, what to work independently, and later emerge with their masterpiece. In practice, results in wasted efforts, and missing corner cases.
- 53. Retrospective “I think, we should cancel that weekly sync, there is no use for it”. “We should write a script for that. We get too many bugs doing that manually”. “If we launch this hack, it would help us launch and iterate.” Remember - Goal of a process is to add efficiency for the overall team towards the goal.
- 54. Minimize Waste Obviate unnecessary artifacts ● Pretty docs ● Over documentation ● Status meetings ● Lengthy launch approvals
- 55. Prioritized backlog ● Milestone planning leads to backlog ● Features / Bugs that were P0 before, may be P2 in later milestones. ● Careful management of backlog helps manage technical debt Dashboards ● Openness is the key ○ Bugs burn rates ○ Who’s working on what