Leading cross-functional teams and the product manager

Transcript

1. 1.

   Leading Cross-Functional Teams Ken Norton VP, Products JotSpot, Inc.

2. 2.

   What am I going to talk about • A disjointed

   set of learnings • What I wish I’d known before • (There will only be two formulas)
3. 3.

   Here’s the good news.

4. 4.

   You have the resources.

5. 5.

   You are completely accountable.

6. 6.

   You are ready to go.

7. 7.

   But…

8. 8.

   You have no authority.

9. 9.

   And everyone is skeptical.

10. 10.

    Why?

11. 11.

    Without sales, nobody would sell. Without engineering, nobody would build.

    Without support, customers would riot.
12. 12.

    Without product managers?

13. 13.

    Life would be just fine.

14. 14.

    (For a while.)

15. 15.

    Organizational structure: What you are working with

16. 16.

    What you’ve probably learned:

17. 17.

    Functional organization. PM

18. 18.

    Weak matrix. PM

19. 19.

    Strong matrix. PM

20. 20.

    What you actually find.

21. 21.

    The real world. PM

22. 22.

    The reality. • You will not be closely supervised. •

    Little to no authority will be handed to you. • You will not have direct managerial oversight for the people who work on your stuff. • You will be highly accountable for success (or lack thereof).
23. 23.

    The team: Who you are working with

24. 24.

    7 ± 2 Ideal team size.

25. 25.

    7 ± 2 (That’s the first formula).

26. 26.

    Always trust your instincts.

27. 27.

    If you don’t have the right team, get it.

28. 28.

    There is nothing more important to invest “political capital” on.

29. 29.

    Communicating: How you are working with who you are working

    with
30. 30.

    There are only three things you need to remember.

31. 31.

    1. “Never tell people how to do things. Tell them

    what to do and they will surprise you with their ingenuity.” (General George Patton)
32. 32.

    2. Communicate to different people in their own language.

33. 33.

    3. Represent the points of view of the people not

    in the room.
34. 34.

    How to get respect from engineers.

35. 35.

    Clear obstacles. Always take the blame. Ask smart questions. Explain

    the “why.” Empathize. Bring the donuts.
36. 36.

    How to get respect from sales.

37. 37.

    Know their number. Get on the phone with customers. Make

    promises so they don’t have to. Help them be creative. Bring the donuts.
38. 38.

    How to get respect from executives.

39. 39.

    Have a vision. Be patient. Know your competition. Make your

    commitments. Bring the donuts.
40. 40.

    How to get respect from customers.

41. 41.

    Understand what they want. Call them out of the blue.

    Keep your promises. Take the blame. Bring the donuts.
42. 42.

    A. B. S.

43. 43.

    Always Be Shipping.

44. 44.

    Nothing helps a team become efficient more than a steady

    release tempo.
45. 45.

    Agile development.

46. 46.

    Can be extremely effective.

47. 47.

    But requires hard work and experience.

48. 48.

    If you do nothing else…

49. 49.

    Have a fifteen minute daily meeting.

50. 50.

    Ask your team three questions: • What have you completed

    since our last meeting? • What will you have done by tomorrow’s meeting? • What’s standing in your way and how can I help?
51. 51.

    Estimating work.

52. 52.

    Product Manager: “When can you get this done? Today?”

53. 53.

    Engineer: “Well, I think it needs more time.”

54. 54.

    Product Manager: “We need it ASAP. What about tomorrow by

    end of day?”
55. 55.

    Engineer: “Uh, OK.”

56. 56.

    The right question: “What needs to happen for you to

    finish, and what can I do to help?”
57. 57.

    Rule of thumb for estimates.

58. 58.

    Likely estimate (L): “How long do you think it will

    take?”
59. 59.

    Pessimistic estimate (P): “OK, but what’s the longest it could

    take, accounting for unforeseen roadblocks?”
60. 60.

    Optimistic estimate (O): “What’s the least amount of time required

    if everything goes well?”
61. 61.

    O + (L x 4) + P 6 What you

    plan.
62. 62.

    Another rule of thumb for estimates.

63. 63.

    Never assume more than 5 hours of progress per developer

    per day.