It is unfair to expect people who haven’t worked on the front lines in software development to just get it. Just as, I’m guessing, it is hard for developers and UXers to grok sales and marketing, being a CEO, and working in HR. Assuming malice is a big mistake. We all want great outcomes for our respective businesses, but have a hard time bridging the divide.

I’ve offered up 40 or so based on my conversations with developers, designers, UXers, data scientists, customer support, and product managers. Of course … “it depends”, and none of these apply everywhere.

Please add more!

Non-Front-Liners routinely …

1. Underestimate the cost of multitasking and context switching
2. Underestimate the cost of increasing complexity (adding use-cases, capabilities, etc.)
3. Underestimate the benefits of regular refactoring, investing in tooling, and allocating time for unstructured research/experimentation
4. Underestimate the investment required to build (and maintain) a meaningful level of shared understanding
5. Underestimate the value of iterating immediately (not months later) based on actual customer usage and feedback
6. Overestimate the value of “divide and conquer” models whereby individual teams have limited contact with other teams that are contributing to the same initiative
7. Overestimate the value of having managers/proxies communicate between teams (vs. having the teams communicate directly)
8. Overestimate the value of centralizing/sharing certain functions (e.g. QA, DevOps, UX)
9. Underestimate the value of committing later to work (e.g. acting on new information, not pre-committing resources)
10. Underestimate the value of more unstructured hacking/spiking to fully grasp the magnitude of a new challenge
11. Underestimate the cost of isolating individual team members on distinct “projects” to boost utilization rates (vs. having more slack time, and focusing on fewer initiatives)
12. Underestimate the cost of having single architects who “decide everything” in isolation, thereby removing front-liners from the decision making process
13. Overestimate the value of segregating front end and back end developers
14. Overestimate the value of using artificial deadlines to motivate employees
15. Underestimate the cost of leaving known bugs/defects active in product
16. Overestimate the value of extensive pre-planning without individual contributors (the people who will do the work) present
17. Underestimate the value of spending time “away from keyboards” (e.g. visiting customers, team white-boarding, etc.)
18. Underestimate the cost of preventing developers from using their tools of choice. The flip-side might be overestimating the value of consistency in tool selection.
19. Overestimate the ability for customers to describe what they need, and what they might find valuable
20. Underestimate the value of connecting new developer hires with the broader business context (e.g. invite them to sales calls, the customer support queue, etc.)
21. Underestimate the cost of becoming emotionally attached to high-fidelity mock-ups
22. Underestimate the value of unbiased coaching and facilitation
23. Underestimate the value of co-location and underestimating the cost of mixed-location (having some people co-located, but others remote)
24. Overestimate the value of adding process when an environment features low trust/low safety
25. Overestimate the value of having experience in a specific language/domain (of course, sometimes this is very valid)
26. Underestimate the value of working horizontally across a problem space (vs. going deep component by component)
27. Underestimate the value of live pattern libraries
28. Underestimate the cost of celebrating silver bullets when the work required corner cutting and is obviously “for show”. Overestimate the value of success theater
29. Underestimate the value of giving a team autonomy over its work environment and providing dedicated spaces to meet/work
30. Underestimate the cost of having a system that is too complicated for any one person to understand/explain
31. Overestimate the value of measuring a team solely based on story point velocity
32. Underestimate the interest developers have in understanding the business/customer problem (and the value that might afford to the company)
33. Overestimate the value of addressing team conflict via 1:1s (vs. coaching the team to resolve its issues publicly)
34. Overestimate the ability for a single product manager to correctly predict the future
35. Underestimate the value of connecting work to high-level business outcomes
36. Underestimate the cost of having inconsistent environments for QA, Staging, etc.
37. Underestimate the cumulative drag created by a “brilliant” executive who exhibits toxic behavior. Underestimate the costs required to insulate that behavior from the rest of the organization (and the efficacy of those efforts)
38. Underestimate the degree to which certain incentive structures can create conflict between team members
39. Underestimate the cost of coherence issues (e.g. actions running counter to stated company culture or goals)
40. Underestimate the value of divergence early in an initiative. Our tendency is to prematurely converge and “get moving”
41. Underestimate the cost of making individual promises to customers around compliance and security (vs. global policies)
42. Overestimate the degree to which developer “touch time” impacts the total lead time for initiatives (a value of 40% is good, 10–15% typical) Here’s what would be awesome… if together we could amass a compendium of “things Non-Front-Liners routinely underestimate and overestimate when thinking about software product development”. I think this format works, and would help us stay consistent:

• Underestimate the cost of ____________________
• Overestimate the value of __________________ My goal here isn’t to rant, but rather to build bridges and shared understanding. Let’s keep comments short and concise, with a focus on benefits to the business.