Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing software projects & teams effectively

Managing a team and project are quite synonymous. Especially, teams require effective distribution of responsibility / roles. Once that is setup, a proper process guides people to make progress. All this fits into a product lifecycle, which is essential to develop the right product, in the right way, and deliver it at the right time.

Related Books

Free with a 30 day trial from Scribd

See all
  • Login to see the comments

Managing software projects & teams effectively

  1. 1. Managing projects & teams Ashutosh Agarwal
  2. 2. Team Structure Effective Process Product Lifecycle
  3. 3. Structure of teams
  4. 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. 5. Company Product A Product B Frontend BHorizontal FunctionsFrontend A Backend A Backend B ● Functional vs Horizontal Teams ● Structure of a team
  6. 6. Two types of Teams
  7. 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. 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. 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.
  10. 10. Structure of a (Productive) Team
  11. 11. 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
  12. 12. The Why Effective flat hierarchy operation ● Different functions ○ Product vision ○ Technical complexity ○ Process leadership ○ Maintaining stability ● Different individual skillset ● Different teams different priorities.
  13. 13. 4 key players ● Product manager ● Technical Lead (TL) ● Program Manager ● SRE The What
  14. 14. 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”
  15. 15. Strategy is the key role, but PMs are the necessary glue for everything else.
  16. 16. Product Manager != People Manager Influence without authority
  17. 17. 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
  18. 18. Contribution styles Technical complexity (my code, my algos) Leadership (my team x 10) Impact (my company) From Junior SWE to TL
  19. 19. 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
  20. 20. 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.
  21. 21. SREs optimize for uptime, not for egos of individual teams / people
  22. 22. Product Manager Product Sense Technical Lead Technical complexity SRE Maintaining stability Program Manager Process Leadership
  23. 23. 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
  24. 24. Life of a Product
  25. 25. 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”.
  26. 26. It’s worthwhile thinking about each part Propose Plan Execute Maintain. Refactor. Deprecate
  27. 27. Double Diamond: Strategy + Execution of the right solutioin
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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.
  35. 35. The Chromium projects (Design Docs) http://dev.chromium.org/developers/design-documents http://aosabook.org/en/posa/high-performance-networking-in-chrome.html
  36. 36. 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”
  37. 37. Effective Process
  38. 38. Everything is process ... Whether you’re compiling code, hiring staff, or making breakfast. - Andy Grove, High Output Management
  39. 39. 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.
  40. 40. Role of a process, is to improve effective productivity of the overall team towards the goal.
  41. 41. 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
  42. 42. Process in various stages of product
  43. 43. From Mission Statement to Production Software
  44. 44. 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.
  45. 45. OKRs Objectives & Key Results
  46. 46. 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.
  47. 47. (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.
  48. 48. 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.
  49. 49. Minimize Waste Obviate unnecessary artifacts ● Pretty docs ● Over documentation ● Status meetings ● Lengthy launch approvals
  50. 50. 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

×