Stephen Covey explained that: Trust is a function of two things: competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive, and your intent with people. Both are vital.
Empowerment of an engineer means that you provide the engineers with the problem to solve and the strategic context, and they are able to leverage technology to figure out the best solution to the problem. An easy way to tell whether or not you have empowered engineers is if the first time your engineers see a product idea is at sprint planning, you are clearly a feature team and your engineers are not empowered in any meaningful sense. If you're just using your engineers to code, you're only getting about half their value.
There is actually a third type of technology team, which is referred to as a delivery team (or “Scrum team” or “dev team”). A delivery team doesn't even pretend to be a true product team. They are not cross‐functional, and they are not empowered. There is a product owner (responsible for administering the product backlog) and some number of engineers. They are purely about output (code and ship). If you're running a process like SAFe, then this is unfortunately you, and truthfully, I have no idea why you would want to read this book, since what I describe here is the polar opposite both philosophically and practically.
Feature teams look superficially like a product team. They are cross‐functional, with a product manager, a product designer, and some number of engineers. The difference is that they are all about implementing features and projects (output), and as such are not empowered or held accountable to results. The feature teams get to work first designing the features on the roadmap, maybe doing a little usability testing, and then proceeding to building, QA testing, and deploying the features (known as delivery).
In the empowered product team model, the product manager has a clear responsibility, which is to ensure that the solutions are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business). Together with a product designer who is responsible for ensuring the solution is usable, and a tech lead who is responsible for ensuring the solution is feasible, the team is able to collaborate to address this full range of risks (value, viability, usability, and feasibility). Together, they own the problem and are responsible and accountable for the results.
to summarize feature teams vs. empowered product teams: Feature teams are cross‐functional (a product manager doing mainly project management, a product designer, plus some engineers), and assigned features and projects to build rather than problems to solve, and as such they are all about output and not business results. Empowered product teams are also cross‐functional (a product manager, a product designer, and engineers), but in contrast to feature teams, they are assigned problems to solve, and are then empowered to come up with solutions that work—measured by outcome—and held accountable to results.
In contrast, in strong product companies, teams are instead given problems to solve, rather than features to build, and most important, they are empowered to solve those problems in the best way they see fit. And they are then held accountable to the results.
Your products are the lifeblood of your company, and these skills must be core competencies. Your customers depend on these products and services. Outsourcing these things will almost certainly kill any chance you have of teams of missionaries. Just the opposite, you literally have created teams of mercenaries.
If you want to pick a role model for designing a group’s practical rules of engagement, you can’t do better than Merton. To start, he coined the phrase “role model,” along with “self-fulfilling prophecy,” “reference group,” “unintended consequences,” and “focus group.” He founded the science of sociology and was the first sociologist awarded the National Medal of Science.
Pete Carroll was a victim of our tendency to equate the quality of a decision with the quality of its outcome. Poker players have a word for this: “resulting.” When I started playing poker, more experienced players warned me about the dangers of resulting, cautioning me to resist the temptation to change my strategy just because a few hands didn’t turn out well in the short run.
In most of our decisions, we are not betting against another person. Rather, we are betting against all the future versions of ourselves that we are not choosing.
Chess, for all its strategic complexity, isn’t a great model for decision-making in life, where most of our decisions involve hidden information and a much greater influence of luck. This creates a challenge that doesn’t exist in chess: identifying the relative contributions of the decisions we make versus luck in how things turn out.
