Can you destroy your product AND not get fired?

The reality is that you WILL NOT get fired or risk career advancement if you:

• Are “responsive” to the business

• Ship something quickly (provided things don’t blow up)

• Work around constraint and bottlenecks (instead of attacking them)

• Work within your scope of control and influence

• Represent the interests of your functional silo

• Raise the profile of your functional silo, increase reliance on your functional silo

• Deliver on a consensus driven initiative. Deliver on the HiPPOs silver bullet

• Hit a widely socialized goal or target. Or better yet beat the goal

• Add debt that is not immediately quantifiable

• Optimize for your individual performance plan

• Highlight the positives

• Demonstrate you are fulfilling your “side of the bargain” You can be awesome at the above AND do harm to the global whole. Taking care of the global whole is a thorny business. The reality is that you risk getting fired (and risking your career advancement) if you:

• Tell the business “no”

• Delay shipping something due to quality or value concerns

• Take time to address the root cause of a constraint, or swarm the bottleneck

• Ruffle feathers outside of your immediate scope of influence

• Point out that the interests of your functional silo do not align with business goals

• Decrease reliance on your functional silo

• Challenge consensus driven decisions. Ignore the HiPPO’s silver bullet

• Ignore a goal that ceases to be helpful

• Challenge adding complexity to the product unless it adds a value multiple. Challenge the necessity for a project

• Highlight the negatives For an example, consider this quote from a Director of Engineering:

All we hear about is how engineering is slow, and how we need to be more predictable. At the end of the day I need to be responsive. That’s how I’m measured, even if we deliver a ton of crap. Of course I’m interested in business results, but I can always blame product for poor product decisions if we do our part.Note how doing “our part” comes before business goals. Can you blame them? Ask “what’s wrong” to a cross-section of employees at a company, and you’ll hear things like:

• Engineering is too slow
• Ops didn’t plan correctly
• Product is running a feature factory
• Sales is selling the roadmap It’s easy to isolate blame to a particular group, but in my experience the efforts of other groups to circumvent the constraints/bottleneck create problems that are equally as damaging. The “problem” is more one of how to approach global continuous improvement, and not the problem of an individual subsystem.

How can you make it safe for your team to optimize for global health and outcomes over individual or group interests?