In the last year, John has met with and coached hundreds of cross-functional product development teams. One pattern stands out. Engineering leadership is passionate about embracing “product thinking” and the shift from projects to products, but they are hitting common roadblocks repeatedly. They stumble into well-worn intuition traps. They struggle with unwinding their own defense mechanisms and rebuilding mutual trust. And they have trouble speaking the language of product...especially as it relates to the bets they are advocating for. In this talk, we’ll explore how engineering leadership can more effectively collaborate with their product management and design counterparts. What does cross-functional product DOING look like, and how can we work together to make that possible? How can you make an apples-to-apples case for working down technical debt, and investing in more resilient tooling and infra? How can you unwind the perverse incentives that keep engineers busy at the expense of outcomes and sanity? Finally, we will explore what happens when the functional boundaries fade, revealing more capable (and happy) product teams.

1. @johncutlefish
cutle.fish

3. Learning more about you…

4. "professional culture clash"
Amy Edmondson | How to turn a group of strangers into a team
“different values, different time frames, different language”

5. M V P

6. F M L
M V P

7. Learning more about you…

8. “product thinking”

9. The Team

11. “I have to figure out how to product
manage the product managers and
product leaders. Something feels off.
We’re getting beaten up over here.”
CTO

12. A. Build exactly this [to a predetermined specification]
B. Build something that does [specific behavior, input-output,
interaction]
C. Build something that lets a segment of customers complete [some
task, activity, goal]
D. Solve this [more open-ended customer problem]
E. Explore the challenges of, and improve the experience for,
[segment of users/customers]
F. Increase/decrease [metric] known to influence a specific business
outcome
G. Explore various potential leverage points and run experiments to
influence [specific business outcome]
H. Directly generate [short-term business outcome]
I. Generate [long-term business outcome]

13. A. Build exactly this [to a predetermined specification]
B. Build something that does [specific behavior, input-output,
interaction]
C. Build something that lets a segment of customers complete [some
task, activity, goal]
D. Solve this [more open-ended customer problem]
E. Explore the challenges of, and improve the experience for,
[segment of users/customers]
F. Increase/decrease [metric] known to influence a specific business
outcome
G. Explore various potential leverage points and run experiments to
influence [specific business outcome]
H. Directly generate [short-term business outcome]
I. Generate [long-term business outcome]

15. A B C D E F G H I
Dev
UX
PM
A. Build exactly this [to a predetermined
specification]
B. Build something that does [specific
behavior, input-output, interaction]
C. Build something that lets a segment of
customers complete [some task,
activity, goal]
D. Solve this [more open-ended customer
problem]
E. Explore the challenges of, and improve
the experience for, [segment of users/
customers]
F. Increase/decrease [metric] known to
influence a specific business outcome
G. Explore various potential leverage
points and run experiments to influence
[specific business outcome]
H. Directly generate [short-term business
outcome]
I. Generate [long-term business outcome]

16. A
B
C
D
E
F
G
H
I
Team
PM
GM
Team
PM
VPoP
GM
Org 1 Org 2

17. Trap 1:
Contributing to high…
Work In Progress
Promises In Progress
Change In Progress
Elephants In Progress
(with best intentions)
(even though you know it is bad)
(because THEY made you do it)
(because Scrum or SAFe made you do it)
Elephants In Progress (EIP)

19. 40 Hour Week
A
A
A A
B
B
Lunch
Diagnosing production issues
Status checks and ETA
updates for future work
Estimating future work
Meetings about future work
Waiting for CI, tooling issues
Delayed by technical debt
(not working through it)
Hiring new people
(response to “going slow”)
A Value add project A
B Value add project B
Context switching, “resetting”
Getting started, focusing

20. 40 Hour Week
A Value add project A
B Value add project B
Context switching, “resetting”
Getting started, focusing
PRODUCTIVITY

21. Tech Debt Month
REDUCE DRAG MONTH
Personal Pizza Sized Teams
Lunch

22. 40 Hour Week
Lunch
Diagnosing production issues
Status checks and ETA
updates for future work
Estimating future work
Meetings about future work
Waiting for CI, tooling issues
Delayed by technical debt
(not working through it)
Hiring new people
(response to “going slow”)
A Value add project A
B Value add project B
Context switching, “resetting”
Getting started, focusing
A B

23. (Credibility + Reliability + Empathy)
Apparent Self-Interest
Trust =
https://www.devsecopsdays.com/articles/trust-algorithm-applied-to-devsecops

24. Start together
Work together
“Finish” together
https://www.devsecopsdays.com/articles/trust-algorithm-applied-to-devsecops

27. Trust can be built (or rebuilt) more
effectively through small promises regularly
kept… in person, not through proxies
Lower WIP. Higher Trust.
Start Together. Work Together. Finish Together
https://www.devsecopsdays.com/articles/trust-algorithm-applied-to-devsecops

28. Trap 2:
Velocity > Cadence
“Moving Around” > “True Work”

29. Opportunity…
AKA
“The Safe Humble-Pie”

30. Learn faster than you ship
Ship faster than you learn

31. “We know when something is working
…when we spend longer on it”

32. Respond
Sense
Respond
Sense

33. Rapid feedback loops. More repeatable wins (and bigger wins). More with less complexity.
5 4 2 6 7 3
3 2 1
3 6 7 8 2 6 10 9
6
27
49
Well oiled feature factory. Reasonably usable features. Reasonably happy customers. Occasional wins.
Difficult to get anything “out the door”. Extremely long feedback loops.
Impact
Total
Time

35. Can’t identify single customer facing outcome
Massive 5y lake/warehouse/BI effort
3-5 weeks for “report”
Losing passionate problem solvers
$###k is “too much”
100+ person team
10 new recs ($3m - $5m/y)

36. One day out of the office? Are you kidding?
That would screw up our sprint. And metrics.

38. Trap 3:
“Technical Backlogs”

43. We don’t want to show too much. Otherwise
we’ll be micromanaged. They will not
understand anyway…

44. Turns into … you will be micromanaged.

45. (Credibility + Reliability + Empathy)
Apparent Self-Interest
Trust =
https://www.devsecopsdays.com/articles/trust-algorithm-applied-to-devsecops

46. Opportunity vs. Intervention
The simplest prioritization:
Huge Opportunity / Experimentation Friendly
Big Opportunity / Guaranteed very small

47. Review:
Opportunity 1: Really lower WIP/CIP/PIP/EIP
Opportunity 2: Balance between ship/learn
Opportunity 3: Apples to Apples Prioritization