Silos, Politics, & Turf Wars by Patrick Lencioni (2006)

It's another interesting story; however the "model" (prescriptive methods of overcoming the problems), is not (at all) appropriate to my own situation; so I was disappointed. 3/5 Stars.

The Six types of Working Genius by Patrick Lencioni (2022)

I am still catching up on all the Lencioni books.  This one popped up in my queue.  I did not like it as much as most of his books.  He is over-selling this idea and the book reads like an over-hyped sales pitch.  It is obvious to most of us that we should do what we love, especially within our chosen profession.  It is somewhat less obvious, but easily understood that we should seek out others who are talented, passionate, and competent at areas our "day job" work requires so that the team we form is optimized for performing the entire mission and attaining the outcomes required.  And there is likely some strong academic literature that verifies this common sense.  But Lencioni's claims and hyperbole detract from his ideas. This is a good, short story / idea but among the worst I have read by Lencioni. 3/5 Stars.

Three Signs of a Miserable Job by Patrick Lencioni (2007)

Another great book by Patrick Lencioni!  Short, direct, clear, and actionable.  I have added all three simple methods to my daily work:  Recognition for everyone; constant updates of our team's impact and the relevance of our work for the company, customers, and making the world a better place.  And, perhaps the hardest in a big tech company, is asking everyone to help define their own, individual daily, on-going success measures.  Fantastic. 5/5 Stars.

Getting Naked by Patrick Lencioni (2010)

In many high-pressure work situations it is very hard to keep centered, thoughtful, and "mindful." We can all use the ideas and checklist from this story about consulting companies.  The key theme of vulnerability generalizes to being genuine in high pressure business settings. Clients and customers appreciate partners who are genuinely interested in customer success. 4/5 Stars.

The Motive by Patrick Lencioni (2020)

Short, sharp, insightful, valuable.  I am catching up on the Lencioni books I should have read a while ago. 5/5 Stars.

When to create a better fire extinguisher

In a work meeting today someone explained an aphorism of the three times to build a better fire extinguisher:

1. Before a fire so you are prepared,
2. After a fire so you are better prepared for the next fire
3. During a fire, which is a terrible idea.

As software developers, we frequently look at all problems and projects as new code (or a cool script) to be written, optimistically predicting we can develop, test, and run the new code and meet the deadline. It's frequently better to use an existing system or process to meet a tight, important deadline than to bet your reputation that your new code will work perfectly the first time.

Drop the Pink Elephant by Bill McFarlan (2004)

My buddy in Berlin posted a selection of "hidden gems" book recommendations. I read this one in one sitting and also recommend it. It is a "self-help" book about communication with simple, effective methods we can all apply. 4/5 Stars.

Communication and Decisions (2 of 2)

Many of us prefer frank, open, direct transparency; we are attracted to the concept of keeping a decision log into which major decisions are entered before they are made and then recorded along with alternatives, context, desired result, vision, etc. At first blush such a decision log seems like a great idea. One can go back to these logs to see what the decision makers were thinking and how they arrived at their decision. Even better is that folks who want to become involved in decisions by advocating for one alternative or another can subscribe to changes in the log document (e.g. using watch in Atlassian or notifications in Google sheets). These interested stakeholders can contact the decision owner and other stakeholders to advocate for their preferred option. My personal experiences implementing such a system have been extremely disappointing.  Many decisions, such as who gets promoted (and more importantly who does not) are very sensitive. Other decisions, such as organization changes, additions or reductions in staff, and other personnel decisions are confidential. "Build versus Buy" business decisions for upgrading an in-house system are always controversial.

Many people prefer to complain after the fact instead of communicating their point of view before the decision is made (Failure is an orphan).  Sometimes there are stakeholders who have valuable input for a decision but are too shy or too busy to make their ideas known; decision owners should proactively solicit points of view either 1:1 or in a meeting if such an effort is worth the time and if the decision will have a big impact.

Starting with the questions from this book (not a good book) I have created the following checklist of questions a person or small team might want to  consider when they are discussing and solving problems or discussing alternatives (e.g. a design review) for a decision and some action they will take.     Note there should always be a  "so that" clause in the answer to describe the result and success vision as shown in these examples.

 

 

Question	Example
What are we trying to accomplish? What is the desired result or outcome and why is it good?	We are trying to prevent the customer from falling into this confused error state in our app. We want the customer to understand and select the appropriate option so that she can complete the larger task in her workflow for her business purpose.
What are expectations for next steps?	We shall create, ship, and run A/B tests of alternative wording in the app on a stratified sample of customers to measure if we can reduce customer confusion and errors in the app so that we can gain confidence in shipping our fix.
What should we not do?	We do not want to shift right to customer service or app training because we want our app to be intuitive in first use for absolute beginners.
What could go wrong? If something goes wrong, what should we do?	Our online A/B testing may measure only this point in time or season and fail for future customers. Our new experience may cause more confusion and have the opposite effect as the result desired. We may be spending time on the wrong problem (priorities) and fail to deliver more important bug fixes or revenue. If there is testing bandwidth, we should re-test each quarter so that we verify the fix continues working. We should verify priorities with business owners so that we maximize value delivery to customers.
What is the status update frequency? What stakeholder feedback is expected by when? How & when are surprises communicated to stakeholders? If you were in one of the roles receiving this information rather than delivering it, what else would you want to know?	Trello cards updated daily with re-estimates of time to milestone; weekly status reports with JIRA links to stakeholders; we have no separate update email to stakeholders so that we concentrate on work and automate the communication. As a stakeholder receiving confusing updates in the trello cards that are tracking progress on this decision I know I should add a comment asking for clarity on confusing information so that I can stay informed and aligned. Surprises are sent via SMS and live meetings.

Obviously, many of these factors are not applicable or not important to some decisions.  However, prompting yourself to consider these criteria can be helpful, even with smaller decisions.

When an employee engagement survey or executive talks about "decision making process" remember it is a secret code word for "communication" and remind everyone to stay alert and remind themselves when they are taking some action that will affect others.  If people are not responding "no" to the question in meetings, "Are we making a decision?" at least once during a meeting, you are not surfacing that question frequently enough.  It is also important to be very proactive in communication about decisions. Do not expect anyone (ever) to search for information about your decisions.  Add them to the notifications or "watchers" lists yourself. 

Communication & Decisions (1 of 2)

TL; DR (too long; didn't read)

Your issue is communications, not "the decision making process."

Decisions and Decision Making receive an enormous amount of attention among managers in the global 5,000 largest companies. Many processes, paradigms, job aids, tools, articles, case studies, patterns, & practices are researched, taught, applied, and evolved to overcome "problems in the decision making process" at organizations. From responsibility assignment matrices to the neuroscience of decision making, studies and analysis of decision making produces petabytes of wisdom and thousands of column inches of Harvard Business Review (HBR) studies. Old "models" that are new again continually fail to solve underlying issues and group dynamics of the people and teams affected by, or involved in business decisions. There is even a society of decision professionals whose careers revolve around helping others make decisions and that try to "repair" others' decision making processes. The large majority of  issues perceived as caused by "the decision making process" are not associated with decisions or the process.

Solving any problem normally involves a decision about what changes will be made as part of the solution.  Frequently, many others will be affected by such changes. When a decision is identified, a number of others affected by the outcome are unaware the decision owner will or has already made a decision.      Those affected are  blindsided by the changes and confused how and why the changes were made. Issues in "decision making" start with discovering that       someone or a team is or will soon be making a decision that materially affects others.  Once the decision owner or participants  realize(s) there is a      decision that affects others she can go about identifying who all will be affected, as well as what all communication is needed.  But there remain problems of effectively communicating with everyone impacted.

Thrashing (wasted work)

As the Poppendiecks explained when they invented Lean Software Development, the worst impediment to rapid, high value delivery in software development is   waste. And the largest source of waste is partially done work. Poor communications about decisions contributes enormously to unplanned changes, which, in   turn, results in partially done work (thrashing).

Instead of concentrating on decision quality or decision process, we should frame issues and solutions as communication. This focus will lead to less       friction, better behaviors, and better outcomes.  Managing behaviors and process changes is always painful and difficult in organizations. Concentrating on changes associated exclusively with communication will go a longer way in solving problems in "the decision making process" that are in reality issues in   communication surrounding decisions.

The first person with whom the decision owner must communicate is herself.  She must first surface the fact to herself that she is making a decision that   will affect others and consider if and how to communicate this discovery to each person affected. Then she can execute whichever "decision making process"  her organization prescribes that is appropriate to the impact of her decision and type of decision. She could, for example, start with identifying          audiences and members of a responsibility assignment matrix associated with the decision she discovered she is making.

In some situations, decisions are pushed down to the person and team with the most context; leaders are content to be "informed" of how their teams have    chosen to accomplish a result instead of pulling decision ownership up to HIPPOs (higher paid people in the org).  In these cases, clear accountability for the success of a decision should also be delegated. (Success has many parents but Failure is an orphan). It is imperative that a decision owner understands who all her decision will affect and the consequences; such an understanding is difficult in large organizations; therefore stakeholders must be very
proactive in communicating this context.

In other situations there is a top-down hierarchical command and control culture, where most decisions float up to HIPPOs, decision criteria are often less-technical and more business-oriented. In such circumstances, technical folks are tasked to communicate the context, desired outcomes and acceptable tradeoffs (collateral damage) of a decision to leaders using concerns and language the HIPPO understands.  The vision for how a decision will lead to the desired result, as well as a clear measurement for success must be part of the decision's communication.

In the second half of this blog post we shall cover a checklist to consider associated with your decision as well as how to craft communication persuasively to your audiences.

The Advantage by Patrick Lencioni

Fantastic book. Prescriptive and useful. Highly recommended for senior leaders in any organization. 4/5 Stars.

Zero to One by Peter Thiel

Fantastic book.  I wish I had access to this information when I had my own startup. There are brilliant insights into the obvious phenomenon of power law dominance in many areas to which business leaders and finance professionals are blind.There are many dense pearls of wisdom. 5/5 Stars.

Should we meet?

I saw this 20-second decision making tool (and flowchart) on my friend's blog and had to share.  Do we need a meeting?

10 Principles for Growth as an Engineer

Today at work, someone pointed me at Dan Heller's blog post from a few years ago about how to be successful as an engineer.  They are:

1. Reason about business value
2. Unblock yourself
3. Take initiative
4. Improve your writing
5. Own your own project management
6. Own your education
7. Master your tools
8. Communicate proactively
9. Seek and exploit opportunities to collaborate
10. Be professional and reliable.

It's worth spending 3 minutes to read the whole article.

And the concepts are reminiscent of Elon's 5 Rules for Engineering.

Green Swans by John Elkington

I don't know how this book appeared in my stack but I am severely disappointed. At most 20% of the material makes any sense and there are so many ridiculous, random ideas, I was frequently tempted to put the book down and stop reading. 1/5 Stars.

Mature vs Immature Developers

As a manager, I frequently consider impact, results, peer feedback, artifacts, and other direct, objective information about developers when analyzing their performance.  There is a dimension of seniority that is not easily summarized by these objective measures -- maturity.  I usually summarize observable, behavioral differences by saying things like "the senior developer comes into code you wrote, cleans it up, adds documentation, and fixes your bugs for you; the junior developer files bugs without reading your code and asks you to add capabilities or features that violate the purpose of your design."  But what are the abstract elements and signs of maturity?

My friend recently blogged about an article he came across and generalized that non-developers also display these abstract signs of maturity or immaturity.  I could not agree more.

Go, Venti!

Congratulations to Venti for rounding out their C-suite dream team.

Most tech folks dislike tickets and everyone hates JIRA

Arnaud Porterie wrote about the "ticketing system" problems most global-5000 tech organizations have. His company "Echos" is trying to help solve some of these problems.  Arnaud gives some very-compelling arguments about why ticketing systems are abused for multiple purposes.  Ticketing system overuse (especially JIRA) disempowers the product or development teams forced to comply with tops-down disempowerment.  I have personally watched this phenomenon taken to an extreme recently.

I agree with the elegance of linking to task tracking using github labels instead of tickets or extra github issues.  I am curious if developers and product teams actually enter data for all the purposes he describes in his company's product.  I suspect many teams are just not good at communicating in general.  I have seen a lot of content-free or incomprehensible updates in whichever system(s) the team is using, even when the team embraces their role of being ticket monkeys.

However, if the leadership of an enterprise is enlightened and wants to empower their teams, the Echos product looks pretty good.

customer delight level objectives (DLO's)

Most technology organizations have embraced the shift away from 20th century service level agreements (SLAs) and 19th century availability measures of "mean time between failures" (MTBF)  mean time to repair (MTTR).  Everyone is looking at service level objectives (SLO's) which are customer-perspective measures of your service, outage budgets, and service level indicators (SLI's).  SLI's are numerical observations and, one hopes near-isomorphic mappings to SLOs.

I perceive that direct customer feedback, engagement, & emotion are missing from our measurements.  When we formulate our objectives, measurements, and actions, we make terrible assumptions about what our customers want, how they feel, and if they like what we have delivered.

I am therefore proposing that instead of Service Level Objectives and outage budgets we should start with Customer Delight Objectives (DLOs).  Delighting customers is all that matters.  We ignore direct customer feedback, customer sentiment, and customer promotion of our service at our peril.

Openness and Employee Engagement

Limeade has published a study that aligns to my introspective value of openness and transparency.  It's always a great feeling to find data that agrees with your opinions.  Of course it is much better to seek out and find data that can help changes your opinions. . .

Best Practices Cult

(Cargo Cult practice)

Michael Haupt has pointed us at a great blog post about how software development organizations frequently slip into behaviors driven by the logical fallacy post hoc ergo propter hoc (that follows this, therefore this causes that), or more colloquially "cargo cult" practices. DomK goes into detail about how many organizations blindly follow "Best Practices," without ever questioning if there could be better approaches that are much better or evolving these practices over time.  And Michael links to an example.

 I posted about this antipattern with respect to agile practices in 2014. Michael's summary and advice are actually better and more general.  Focus on the success measures of the mission and be prepared to change your practices when they are no longer optimal.  "The nines don't matter if your customers are unhappy."  Keep looking for how to get better at accomplishing your mission and don't assume "best practices" are "best" for your team.  Improve, continuously.