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.
Ron Lichty,
Managing Development & Product Teams
SOFTWEST
2

3.
Annual Study
of Product Team Performance
http://www.ronlichty.com/study.html© Ron Lichty 3

4.
* Addison Wesley
*
© Ron Lichty 4

5.
Training Teams: Agile
1-4 weeks
© Ron Lichty 5

6.
Debugging Software Teams
© Ron Lichty 6

7.
Debugging Software Teams
© Ron Lichty 7

8.
Debugging Software Teams
© Ron Lichty 8

9.
Debugging Software Teams
Transforming Chaos to Clarity
• Product Management is essential
© Ron Lichty 9

10.
Debugging Software Teams
Transforming Chaos to Clarity
• Product Management is essential
– Technical
– Effective
– Experienced
© Ron Lichty 10

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.
Vision
pixabay.com
© Ron Lichty 12

13.
Scattershot, Hit-or-Miss Development
pixabay.com
© Ron Lichty 13

14.
Scattershot, Hit-or-Miss Development
• It’s PdM that supplies consistent direction
– vision
– roadmap
– prioritized backlogs of stories
© Ron Lichty 14

15.
It Starts with Vision
pixabay.com
© Ron Lichty 15

16.
… Based on Data
© Ron Lichty 16
pixabay.com

17.
Your Opportunity:
Engage Developers with Real Users
pixabay.com
© Ron Lichty 17

18.
Engage Users
• Open a connection to users for developers
• Remember: It’s about delighting users!
18

19.
Project Workflow
Vision

20.
Project Workflow
Roadmap
Vision

21.
Project Workflow
Vision -> Roadmap -> Project

22.
Project Workflow
Epics & Stories
Listing
Project

23.
Cost of Adding Features Spikes
pixabay.com
© Ron Lichty 23

24.
Project Workflow
Technical PBIs*
Epics & Stories
*
PBI: Product Backlog Items; list provided by technical leadership
Listing
Project

25.
Project Workflow
Technical PBIs*
Epics & Stories
*
PBI: Product Backlog Items; list provided by technical leadership
Sizing
Listing
Sizing
Project

26.
Project Workflow
Technical PBIs*
Epics & Stories
*
PBI: Product Backlog Items; list provided by technical leadership
Sizing
Ordering
Listing
Sizing
Project

27.
Order the Backlog by Value
© Ron Lichty 27
pixabay.com

28.
Ordering: Value / Size: ROI
Technical PBIs*
Epics & Stories
*
PBI: Product Backlog Items; list provided by technical leadership
Sizing
ROIOrdering
Listing
Sizing
Project

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.
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.
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.
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.
Project Workflow
Technical PBIs*
Epics & Stories
*
PBI: Product Backlog Items; list provided by technical leadership
Sizing
Urgency / RiskROI/Dependencies/RiskOrdering
Listing
Sizing
Project

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.
Provide Clarity: Scope or Deadline???
© Ron Lichty 35

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.
Sprints Are a Mishmash of Stuff
pixabay.com
© Ron Lichty 37

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.
Theme Your Sprints
© Ron Lichty 39
pixabay.com

40.
pixabay.com
© Ron Lichty 40

41.
Manage Stakeholders / Protect Developers
pixabay.com
© Ron Lichty 41

42.
Be an umbrella to the noise
--John Evans photo
© Ron Lichty 42

43.
Be an umbrella to the noise
--John Evans photo
• Speed of Ideation exceeds the Speed of Development
© Ron Lichty 43

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.
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.
Let developers focus
© Ron Lichty 46
pixabay.com

47.
Don’t Be a Source of Interruptions
© Ron Lichty 47
pixabay.com

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.
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.
--Larry Maccherone, The Impact of Agile Quantified, Rally, 2013
Don’t Be a Source of Multitasking
© Ron Lichty 50

51.
Enliven Your Developers!
pixabay.com
© Ron Lichty 51

52.
Connect the vision with the team’s work
http://www.ManagingTheUnmanageable.net
© Ron Lichty

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.
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.
Personify Agile Culture
© Ron Lichty 55

56.
Personify Agile Culture
© Ron Lichty 56
• Focus on fomenting amazing teamwork
– on supporting the team becoming high performance

57.
Deliver Clarity
© Ron Lichty 57

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.
Share the “What” not the “How”
• It’s subtle
59

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.
Listen to Developers
pixabay.com
© Ron Lichty 61

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.
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.
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.
Projects Not Suitable for Agile?
65

66.
Projects Not Suitable for Agile?
• Micromanagement
66

67.
Projects Not Suitable for Agile?
• Micromanagement disrupts Agile
• Micromanagement prevents Best Teams
• Micromanagement prevents Learning
• Micromanaged teams become order-takers
67

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.
Partner
69
Photo by Esti Alvarez, Some rights reserved, http://www.Flickr.com/photos/esti/4638056301/

70.
Debugging Software Teams
Transforming Chaos to Clarity
Product Management is essential
© Ron Lichty 70

71.
Debugging Software Teams
Transforming Chaos to Clarity
Product Management
leadership and motivation
are essential
© Ron Lichty 71

72.
Rules of Thumb / Nuggets of Wisdom*
* 300 in the book / more at http://managingtheunmanageable.net/morerulesofthumb.html
© Ron Lichty 72

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