Note: Scroll down if you’re short on time, and want to get straight to the list of goodness.

Software product development is an optimization problem. Adding objectives, constraints, and uncertainty to an optimization problem adds complexity. If you’ve done this for a while, you know the constant push-pull between short term gains and long term results.

The present bias refers to the tendency of people to give stronger weight to payoffs that are closer to the present time when considering trade-offs between two future moments (O’Donoghue, &, Rabin, 1999).Put simply, people tend to want to get the reward today, but push the pain of loss far into the future. (source)

A great example is building a feature to close a new customer. The money is right in your face. You can feel it. If you build X, you will make $Y. It’s easy to lose sight of the actual costs (including the opportunity cost).What if you focused on something riskier, but more valuable? We tend to lose sight of that option, which makes sense because thinking too far (or deeply)

into the future can have a paralyzing effect. The lion will eat you if it takes that long.

Other examples relate to organizational resiliency. It can be tempting to shoot for short-term gains (adding headcount quickly, adding layers of hierarchy, siloing specializations for efficiency), without considering the long term effects. In short…we add constraints and new objectives. Which makes navigating the problem space more difficult. And entropy ensues.

I often run into orgs that are trying so damn hard (as hard as they can, actually)

, but they can’t seem to generate any forward momentum. They’re layering more and more process on the situation without any impact. They’re chasing down a new symptom every quarter. But when you actually interview the various actors, you learn how insanely constrained their world is. We’re not talking about an inability to find a globally optimal solution. That would be too ambitious. Rather, even mediocre ways forward are impossible, or require mind-numbing 3 dimensional chess.

“Installing” Agile without removing constraints will fail.

Which brings me to a conversation I had with Josh Seiden (Sense & Respond, LeanUX) the other day. Josh correctly pointed out that my post 42 Things Non-Front-Liners Misunderstand was basically preaching to the converted, and that Non-Front-Liners just wouldn’t get it. If a Dev or UX sent this to an executive, they’d get an “um”. His challenge — which will take me a while to execute on — was to figure out how to elicit a “hmmm, I think I see what you mean, I get it now, we should act on this!”

But how?

When you boil down many of the points in the 42 Things post, you end up at the tension between short(er) and long(er) term thinking, and individual and group intrinsic/extrinsic reward systems. Front-Liners, for example:

• DO touch the product, the code, and the design
• DON’T touch the sales quotas, revenue projections, and meetings with investors, lawyers, and analysts
• DO bang their heads against tech-debt ridden code, feel the hit of multi-tasking, and cringe at “just shipping” crappy features
• DON’T spend 60hrs per week in meetings where people are primarily 1) complaining and/or 2) pitching their pet projects
• DO have to sit in close quarters with a small development team, and — according to the data — have to solve a cost/benefit design decision every 15 minutes with very intense cognitively challenging work
• DON’T have the fate and livelihood of many hundred (or thousand) people in their hands. And have to be “good at PowerPoint” AND strategy
• … and tend not to have to answer 30 support calls a day, send a hundred outbound sales emails, butt heads with vendors, and field calls from angry first-tier customers

So there are different versions of “good job” happening, and different mental models, cause/effect, and cost/reward. We respond to the present bias in different ways because of how we think, and what we know.

How do you build shared understanding?

If you’re lucky, the CTO or CPO are able to explain and describe the calculus to other senior leaders. If you’re even luckier, they are able to stand head to head with the CRO, CFO, and CEO, and translate the calculus into an actionable risk-management and continuous improvement framework. They’ll explain why chasing efficiency begets rigidness, and that you need to care about resiliency. They’ll explain why a lack of focus begets an exponential increase in the number of constraints. Finally, they’ll explain why having a tall org might not benefit the product. But that’s if you (and they) are lucky.

Consider, then, that senior leaders often don’t understand how certain decisions will impact the future. They’re already too far away from the action and no one has explained the calculus. People are running around talking about UX, Agile, DevOps, leaving slack in the day, lowering utilization, and Outcomes over Output…and someone without experience in the trenches (or experience a long time ago) will not know WTF is going on.

We put humans on the moon. And will send them to Mars. And you can’t fucking ship a mobile app, and migrate to the new ERP system? That makes no sense! Is anyone giving a damn here?The constraints you are experiencing today are a culmination of many, many decisions. At one point, you probably had a choice. And that is the central challenge. We need to explain why these choices matter for the long term success of your product development org. But don’t make them so sacred that you never make any decisions — or respond to any changes.

That is OUR responsibility.

What if you could say? Why can’t you say?

In the spirit of making my Medium posts way too long, below I have listed 60 examples of things YOU COULD DO AND SAY if you play your cards right. But, given that I’m known to point out problems… I want you to ask yourself about what is stopping you from saying these things. What is the “yeah but”. Or if you can say them, what decision made that possible? And then reflect on how you can remove that constraint.

1. “Maybe we can borrow a developer from another team? It would be helpful to get a fresh pair of eyes on the problem.”
2. “Very reassuring to be able to test this in a production-like environment. But without the risk of harming customers if something goes wrong.”
3. “Let’s colocate the teams during the kickoff.”
4. “We may need to block out some of Team B’s time. But we’re not sure. It could go either way. Glad we have the flexibility of short notice scheduling.”
5. “We’ll benefit by having rapid access to customers. We have a list of customers that we’d like to contact in the next week.”
6. “Yes. We can hit that date within +/- 10d.”
7. “If the early data is encouraging, the team would like to continue iterating before jumping to another effort.”
8. “At the moment, our scaling predictions are very rough. Luckily we can add computing/network resources if required.”
9. “The team can talk this out together. I know the topic is a bit sensitive, but there’s an upside.”
10. “I consider myself lucky to work with people who aren’t all the same. The diversity of viewpoints and work styles is energizing.”
11. “The problem was quickly isolated to a tiny set of customers.”
12. “We’re not sure when we’ll need to talk to the UX Designer. But we will eventually. He’s available on short notice, right?”
13. “Since this will impact marketing, it would be great if at least a couple folks from that team could attend standup. Who is coming?”
14. “This is a great candidate for an A/B experiment. Let’s get it going.”
15. “Doug has many strengths as a new team member, but he will really benefit from closely pairing with that senior dev Maria for the first month or so. Maria has available cycles, right?”
16. “Anyone can take that front end story.”
17. “Ideally for this project we’ll be able to deploy on our own schedule, and without bugging Ops. Cool?”
18. “We have decided to pull this feature. It is rarely used, and it adds a lot of complexity to this area of the code.”
19. “We can hand over the reigns of the service to another team if you’d like. It’ll take a week or so of onboarding, but not much more.”
20. “I spoke up about that issue at the company meeting. I know it was hard to hear, but I’m positive we can learn from that failure.”
21. “We have some slack. We’d be happy to knock that high priority item out for you.”
22. “What a great opportunity! That area of the codebase is decently re-factored. This is something we should act on. It’ll be high value for the company.”
23. “I’ll just pop in to her office. It’s great when the CEO has open office hours.”
24. “Ah. Peace and quite. I really need to limit some distractions to get this done.”
25. “The meeting room is always available. It’s our team room! That means we can keep our stuff up on the wall.”
26. “You don’t need to pick a track here. If you’d like to try management, and then go back to being an IC, there is no stigma.”
27. “I was able to lay out the initiative in broad strokes and get going. There was a ton up in the air, so we needed to start digging in.”
28. “Jira didn’t work for us. This was more of a Trello quarter. So we fired up Trello.”
29. “Even if they are a great performer from a financial perspective, it is never OK to keep a toxic person here at the company. We took action and fired them.”
30. “Operations wasn’t his strong suit. So he willingly shifted roles. And now things are working so much more smoothly.”
31. “We’re going to be using more Go and Scala moving forward. Luckily, our teams are fast studies. The transition shouldn’t be tough, and we’re ok with making that investment.”
32. “Customer Success has such good insights on our customers. I’m happy to be able to draw on that knowledge when considering new features.”
33. “Multiple teams can work on that product and deploy on their own schedules.”
34. “It’s reassuring to do larger scale retrospectives, and to have the larger global blockers removed.”
35. “There’s enough time in the week to do some unstructured innovation work. It doesn’t need to be company oriented, either.”
36. “It’s nice not to have to put up your guard when C-level people come by.”
37. “Our compliance environment is tough, but we have taken a “compliance as code” approach. I’m so much more confident this way. And the teams don’t get bogged down as much. We automate as much as possible.”
38. “It was hard to kill the project that late in the game, we all agreed it it was in the best interest of our customers and internal teams.”
39. “Luckily there is great test coverage in that area of the codebase. It shouldn’t be hard to do an incremental refactor. I was worried for a second that we’d need to do a parallel rewrite.”
40. “Please. Enjoy your paternity leave. Don’t worry about us. We’ll be OK for the next eight weeks.”
41. “Localization shouldn’t be a big lift. We’ll get on it in a couple weeks.”
42. “Thanks for asking! Let’s take a look at the card wall, and I’ll talk you through the work.”
43. “It’s safe for us to augment this project with contractors. They can be effective AND not screw anything up.”
44. “It’s a relief to be able to make a data-informed decision on this.”
45. “The interns have arrived! One of my favorite times of the year is working with interns on their intern projects. Sure, we hire some. But it also help the senior folks hone their teaching and mentoring skills.”
46. “I used the company card to order lunch. Our expense reports run automatically.”
47. “We spent the day visiting customers with the whole team. It was awesome to see everyone connect with our users.”
48. “Adding measurement to that area of the product was super simple. Even for a non-technical person. Good thing we didn’t need to bug our developers.”
49. “You’re free to shift around between teams, which is nice when you are looking for a new challenge. There’s nothing worse than feeling stale.”
50. “Shit happens. But when a production issue comes up we have enough slack to actually get to the bottom of it. Putting out fires is OK. Solving the problem (so it never comes back) is satisfying.”
51. “Potential new hires can join us for two weeks to do real work. It is good for us and them.”
52. “The CEO “ask me anything” was refreshing.”
53. “The team (developers and UX) can pretty much handle the effort on their own. With the help of their part-time agile coach, they’ve shifted off Scrum, don’t need a manager, and leave the PM to focus on bringing in outside context.”
54. “Sometimes you just need an individual challenge. Once you’ve been here for a year or two, we allow developers to work on an individual project to really push their limits. And then they return refreshed to a team.”
55. “We caught the threat very early. What a relief. We all got to bed at a reasonable time that night.”
56. “The pattern library has made it super easy to build quick prototypes. We don’t need to reinvent the wheel. Instead of using Slack or InVision, our UXDs can just assemble working interfaces.”
57. “We can take a new grad and get them up to speed quickly. They stay, too! It is rewarding to help someone get situated in their career.”
58. “Having time set aside to attend conferences as a team has really helped us hone our chops.”
59. “We always had a hunch this might work. To get a working prototype out there in front of customers so quickly — warts and all — was such an asset. Otherwise we would have had to make a big project out of it.”
60. “The best part is knowing if the work we’re doing is actually have an impact. It is great for retention.”