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.

Leading and Motivating Engineers - what product managers need to know - product camp '17

1,464 views

Published on

Effective, experienced technical product management is crucial to make software development hum: Engineering and Product Management are symbiotic. Product managers lead and motivate by first establishing credibility with engineers, and by bringing vision, data, collaboration, prioritization, and protection. Ron Lichty has repeatedly been brought in to transform chaos to clarity in software development. Here’s what product managers can apply to lead and motivate engineers and make software development hum.


BIo:
Ron Lichty has, for 30-plus years, championed delighting customers. He believes that strong product/engineering collaboration is essential to achieving that goal. Ron co-authored the Addison-Wesley book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net) and annually coauthors the Study of Product Team Performance (http://www.ronlichty.com/study.html).

Ron spent seven years as a programmer, two years as a product manager, and 25 years managing product and development organizations at all levels - to VP of engineering, VP of product and CTO - at companies ranging in size from tiny startups to Charles Schwab,Stanford, and Apple.

He now consults across that realm, taking on fractional interim VP Engineering and acting CTO roles, training teams in agile, training managers in managing software people and teams, and coaching development teams and executives in making software development hum. (http://www.ronlichty.com)

Ron has long been a popular speaker at product, development and agile meetups and conferences. Ron@RonLichty.com

Published in: Software
  • Be the first to comment

Leading and Motivating Engineers - what product managers need to know - product camp '17

  1. 1. Leading And Motivating Engineers: What Product Managers Need To Know Ron Lichty, principal, Ron Lichty Consulting author, Managing the Unmanageable www.RonLichty.com www.ManagingTheUnmanageable.net
  2. 2. Ron Lichty, Managing Development & Product Teams SOFTWEST 2
  3. 3. Annual Study of Product Team Performance http://www.ronlichty.com/study.html© Ron Lichty 3
  4. 4. * Addison Wesley * © Ron Lichty 4
  5. 5. Training Teams: Agile 1-4 weeks © Ron Lichty 5
  6. 6. Debugging Software Teams © Ron Lichty 6
  7. 7. Debugging Software Teams © Ron Lichty 7
  8. 8. Debugging Software Teams © Ron Lichty 8
  9. 9. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential © Ron Lichty 9
  10. 10. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential – Technical – Effective – Experienced © Ron Lichty 10
  11. 11. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential – Technical – Effective – Experienced • Product Managers have to lead – Vision – Data – Collaboration – Prioritization © Ron Lichty 11
  12. 12. Vision pixabay.com © Ron Lichty 12
  13. 13. Scattershot, Hit-or-Miss Development pixabay.com © Ron Lichty 13
  14. 14. Scattershot, Hit-or-Miss Development • It’s PdM that supplies consistent direction – vision – roadmap – prioritized backlogs of stories © Ron Lichty 14
  15. 15. It Starts with Vision pixabay.com © Ron Lichty 15
  16. 16. … Based on Data © Ron Lichty 16 pixabay.com
  17. 17. Your Opportunity: Engage Developers with Real Users pixabay.com © Ron Lichty 17
  18. 18. Engage Users • Open a connection to users for developers • Remember: It’s about delighting users! 18
  19. 19. Project Workflow Vision
  20. 20. Project Workflow Roadmap Vision
  21. 21. Project Workflow Vision -> Roadmap -> Project
  22. 22. Project Workflow Epics & Stories Listing Project
  23. 23. Cost of Adding Features Spikes pixabay.com © Ron Lichty 23
  24. 24. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Listing Project
  25. 25. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Listing Sizing Project
  26. 26. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Ordering Listing Sizing Project
  27. 27. Order the Backlog by Value © Ron Lichty 27 pixabay.com
  28. 28. Ordering: Value / Size: ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROIOrdering Listing Sizing Project
  29. 29. Ordering: Not Just ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROI/Dependencies/RiskOrdering Listing Sizing Project
  30. 30. Groom the Backlog in Collaboration with your Tech Lead! • PdMs are responsible for the backlog • Critical technical Product Backlog Items: – just-enough architecture – resolving technical risk – automating building and testing – fixing critical bugs • Either – collaboratively interweave technical PBIs – assign nn% every sprint to tech team stories © Ron Lichty 30
  31. 31. Ordering Is More than ROI • Good user-story ordering is a collaboration with Eng – take dependencies into account – support risk-first development – reduce uncertainty – enable design to emerge – test architecture – listen for opportunities
  32. 32. Ordering: Not Just ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROI/Dependencies/RiskOrdering Listing Sizing Project
  33. 33. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Urgency / RiskROI/Dependencies/RiskOrdering Listing Sizing Project
  34. 34. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Urgency / RiskROI/Dependencies/RiskOrdering Listing Product Backlog Integrating Sizing with ~ 2 ½ sprints detailed Project
  35. 35. Provide Clarity: Scope or Deadline??? © Ron Lichty 35
  36. 36. Project Workflow Project Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Two-Pass Sizing Urgency / RiskROI/Dependencies/RiskOrdering Listing Product Backlog Sprint Backlog Integrating Sizing Planning with ~ 2 ½ sprints detailed
  37. 37. Sprints Are a Mishmash of Stuff pixabay.com © Ron Lichty 37
  38. 38. Scattershot, Hit-or-Miss Development • It’s PdM that supplies consistent direction – vision – roadmap – prioritized backlogs of stories – theming sprints © Ron Lichty 38
  39. 39. Theme Your Sprints © Ron Lichty 39 pixabay.com
  40. 40. pixabay.com © Ron Lichty 40
  41. 41. Manage Stakeholders / Protect Developers pixabay.com © Ron Lichty 41
  42. 42. Be an umbrella to the noise --John Evans photo © Ron Lichty 42
  43. 43. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development © Ron Lichty 43
  44. 44. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development • Courage: “Great idea! I’ll put that in the backlog” © Ron Lichty 44
  45. 45. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development • Courage: “Great idea! I’ll put that in the backlog” • Prioritize: Developers want to do what customers value © Ron Lichty 45
  46. 46. Let developers focus © Ron Lichty 46 pixabay.com
  47. 47. Don’t Be a Source of Interruptions © Ron Lichty 47 pixabay.com
  48. 48. Source: Mike Cohn, citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993 Don’t Be a Source of Multitasking © Ron Lichty 48
  49. 49. taking communications overload into account Source: Rob Maher, “Increasing Team Productivity: A project focus creates waste and leaves value on the table”, Scrum.org Whitepapers Rob Maher, surmising that email, texts, IRC, chat, smartphones together represent a second “task” Source: Mike Cohn, citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993 Don’t Be a Source of Multitasking © Ron Lichty 49
  50. 50. --Larry Maccherone, The Impact of Agile Quantified, Rally, 2013 Don’t Be a Source of Multitasking © Ron Lichty 50
  51. 51. Enliven Your Developers! pixabay.com © Ron Lichty 51
  52. 52. Connect the vision with the team’s work http://www.ManagingTheUnmanageable.net © Ron Lichty
  53. 53. Prioritize • Developers want to know they’re working on the stuff customers will value most! • There is no such thing as “2 top priorities”! • Get good at the mantra, “I’ll put it in the backlog” 53
  54. 54. Prioritize • Developers want to know they’re working on the stuff customers will value most! • There is no such thing as “2 top priorities”! • Get good at the mantra, “I’ll put it in the backlog” • “If everything is a priority, nothing is a priority.” — Sheila Brady, Apple project management guru 54
  55. 55. Personify Agile Culture © Ron Lichty 55
  56. 56. Personify Agile Culture © Ron Lichty 56 • Focus on fomenting amazing teamwork – on supporting the team becoming high performance
  57. 57. Deliver Clarity © Ron Lichty 57
  58. 58. Deliver Clarity / Be Present • Clear requirements • Always based on the customer • An answer to every ambiguity • The “what”; for context the “who” & the “why” • Never the demotivating “how” • How we’ll know we’ve achieved success: UATs • 3rd ‘C’ in Planning Meeting 3 C’s: Confirmation © Ron Lichty 58
  59. 59. Share the “What” not the “How” • It’s subtle 59
  60. 60. Be Available • Be there with clarity – with the priorities / with the backlog – with the stories – with the acceptance tests – with the detail – with the clarity / the disambiguation 60
  61. 61. Listen to Developers pixabay.com © Ron Lichty 61
  62. 62. Listen to Developers • Support a culture of communication – at every level – with everyone • up, down, within and across • “We have two ears and one mouth. Use them in this ratio.” — Kimberly Wiefling 62
  63. 63. Listen to Developers “If you’re just using your engineers to code, you’re losing half their value.” “The single biggest innovator in many companies is the tech lead.” --Marty Cagan © Ron Lichty 63
  64. 64. Listen, Ask pixabay.com • Developers want to delight customers, too • They see opportunities in the code • Give them context / expect rich options © Ron Lichty 64
  65. 65. Projects Not Suitable for Agile? 65
  66. 66. Projects Not Suitable for Agile? • Micromanagement 66
  67. 67. Projects Not Suitable for Agile? • Micromanagement disrupts Agile • Micromanagement prevents Best Teams • Micromanagement prevents Learning • Micromanaged teams become order-takers 67
  68. 68. Projects Not Suitable for Agile? • Micromanagement disrupts Agile • Micromanagement prevents Best Teams • Micromanagement prevents Learning • Micromanaged teams become order-takers • Agile calls for everyone on the team to step up • Micromanagement causes everyone to step back 68
  69. 69. Partner 69 Photo by Esti Alvarez, Some rights reserved, http://www.Flickr.com/photos/esti/4638056301/
  70. 70. Debugging Software Teams Transforming Chaos to Clarity Product Management is essential © Ron Lichty 70
  71. 71. Debugging Software Teams Transforming Chaos to Clarity Product Management leadership and motivation are essential © Ron Lichty 71
  72. 72. Rules of Thumb / Nuggets of Wisdom* * 300 in the book / more at http://managingtheunmanageable.net/morerulesofthumb.html © Ron Lichty 72
  73. 73. Ron Lichty Consulting • Interim & acting CTO/VP Eng roles / making development hum – http://ronlichty.com, Ron@RonLichty.com • The book and the video training: Managing the Unmanageable: Rules, Tools & Insights for Managing Software People & Teams – http://ManagingTheUnmanageable.net • The study: The Study of Product Team Performance – http://www.ronlichty.com/study.html • Training: Zero to Agile in Three Days The Agile Manager Managing Software People and Teams© Ron Lichty 73

×