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.

1. Managing
projects &
teams
Ashutosh Agarwal

2. Team Structure Effective Process Product Lifecycle

3. Structure of teams

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

6. Two types of
Teams

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”

42. Effective Process

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

48. From
Mission Statement
to
Production Software

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