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 Questions for a Frantic Family by Patrick Lencioni (2008)

Our family is no longer frantic; this book would have been fantastic during the decades our family was frantic. Interestingly, the business concepts behind their application to families shines through, making the book worthwhile, so I am glad I did (eventually) read it.  I still have a bunch more Lencioni books to read. 4/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.

Tips for business writing

A wise friend of mine recently posted these simple tips for business writing.  I personally violate all of these rules frequently and needed Marc's reminder.

minimize dependences

One of the rare objective principles we try to apply to reorgs and org design is to minimize the required communication and lock-step dependencies each execution team requires to deliver value to end-users.  This empowerment is sometimes called the "independent executor model" within the rubric of coordination models.  Recently my wise friend Michael posted his own take on how to apply this model to existing product teams.  The key, as Michael points out is that teams should be self-reliant:

They ask, but never expect other teams to do work for them.

Vanity and other Metrics that measure the wrong thing

John Cutter has a new piece out about vanity metrics that's worth skimming.  It's a reminder that our cognitive biases and need to boast, brag, and make ourselves look great to "management" can be destructive to our mission and purpose as an enterprise.  I have encountered more subtle cognitive biases where our metrics and goals in a business-to-business setting are focused on the use of our free software service instead of the purpose for which our free service is intended.  Folks are using our software, yes.  But are they getting our joint mission and purpose done better and more efficiently?  Software is our means to an end.  Customer success is literally our success.  Therefore, even if our customers love our software and love using it, if alternatives to our software are better or more efficient, both our customers and we have failed.  Focus on what matters.

InfoSec map is not the Info-Threat territory

We have many recent reminders of the growing, irrational gap between real information security threats and the solutions, regulations, practices, mitigations, and technologies we can and should bring to bear to mitigate these threats.  The recent successes and growth of ransomware is one indicator that malware threat mitigation is obviously failing.  Personally, I would like to enlist everyone to protect themselves and "crowdsource" aspects of the problem.

Within the Information Security attack / defend landscape, attackers have all possible advantages, including "asymmetric warfare," where a single attacker can easily harm billions of people. Attackers have enormous wealth and resources to create attacks as they are funded and resourced by nation states, wealthy organized criminals, and professionals.  For decades, governing entities, regulators, & consortia have written standards, regulations and policies that chase after emerging "cyber" threats, and the trillion-dollar tech giants have tried to protect their own customers by developing anti-malware prevention, defenses, as well as mitigation hardware and software.

 

 # 

A wise mentor once told me "Policy is hard.  Technology is easy."  This wisdom is broadly applicable in many areas of software development and IT: Naming Policy, Data Governance Policies, Algorithm Selection, Object Factoring, and even Design Policy.  

One recurring problem I have encountered is the ubiquitous confusion in Information Technology of an abstract requirement, problem, threat, or need versus one or more technological solutions (software products) that try to meet the requirement or solve the problem.  IT professionals get caught up in the solution and see their own problems through the lens of some product or product family.  It is nearly impossible for me to convince them to separate clearly the probability of a successful attack, the true severity of such an attack, and the resultant risk for our organization. Instead they see our problem through the lens of some specific IT technology that is designed for some other customer in some other situation to mitigate that other organization's risk.  This issue is much worse in an organization where estimates of probability multiplied by the severity (risk) varies enormously among the organization's stakeholders and decision makers.  After my repeated attempts to help InfoSec folks write artifacts that separate threats from technologies, they always inject some product and some mitigation to risks we do not have and I never prevent it.

So, I plan to "democratize" and crowd source threat mitigation wherever I can.

I shall enlist and empower everyone to help mitigate cyber threats.  One method is illustrated by the entire lifecycle of the Russian military's attack on Space-X Starlink consumer internet service in Ukraine. The approach Space-X's took to reacting to the problem is instructional and generalizable. They created, and shipped a mitigation very quickly. But most-importantly the shift in attitude from the USA's department of defense on the attack / defend methods will eventually broaden how nation states and large companies help defend us. When Starlink was jammed in Ukraine, Space-X reacted by calling the issue a "free QA department" that found a bug for Starlink to fix.  All of us can take this idea to heart.  We should all consider email spam, phishing, ransomware, click bait, and cyber attacks we encounter as training to make us "antifragile" and resistant to more-dangerous and better attacks we shall encounter in the future.  The US DoD said that our current checklist-driven approaches are flawed and we must be much more proactive in formulating defense.  Education, training, and constant vigilance among everyone is a step in that direction.

The 5 Dysfunctions of an engineering team

Management concepts like this one deserve frequent reminders. Thank you, Michael, for blogging the link and sharing your own thoughts.  Organizations in which I have been a member fall into these patterns of failure from time to time, so recording a reminder here will be useful. The original book when it came out was great and the sequel, "overcoming the 5 dysfunctions of a team" was a great refresher.

 # 

On a somewhat related note, another set of authors and books worthy of frequent reminders are the Crucial Conversations team who also wrote Influencer. Don't fall into the "serenity trap."

reminders about importance, urgency, mindful focus

Michael reminds us that those simple "ringing telephone" urgent-not-important examples from pithy self-help sources are not nearly as useful as thoughtful considerations of "flow," unplanned interruptions, shifting priorities, unknown unknowns, and false precision.  The source to which he links covers aspects of urgency we don't normally consider and is also worth reading.

Should you brand your workplace a "Family?"

Here are two articles worth skimming: the first is an interesting Harvard Business Review (HBR) study about the deleterious effects of branding and considering work colleagues a "family," and the second is a CEO letter about the separation of work from private individualism, specifically explaining that "work" is not a family.

(I stuffed both articles into a doc for you because they are behind paywalls.)

Fake it til you almost make it or really going fast

Shipping pressure and throw-away "proof of concept" demonstrations very frequently lead to spectacular failures. My buddy recently re-posted an analysis and link to John Cutler's insightful twitter content associated with "feeling like we are going fast" versus really increasing true value delivery velocity.  It's worth a quick 2-min read.  

 # # #

Note: I think Michael's comment about the origin of the expression "jedem Anfang wohnt ein Zauber inne" (there's magic in every beginning) that he credits to Hermann Hesse should be attributed to a mistranslation into English of an 1808 edition of  "Faust: eine Tragödie"  by Johann Wolfgang von Goethe:

Was heute nicht geschieht, ist morgen nicht getan,
Und keinen Tag soll man verpassen,
Das Mögliche soll der Entschluß
Beherzt sogleich beim Schopfe fassen,
Er will es dann nicht fahren lassen,
Und wirket weiter, weil er muß.

The texture, meter, and rhyme are fun, right?  Goethe can be soothing to read.

The common (terrible mistranslation into an) English version is:

What you can do, or dream you can, begin it,
Boldness has genius, power, and magic in it.
Only engage, and then the mind grows heated, —
Begin it, and the work will be completed!

It is a common inspirational quote I see floating around the interwebs from time to time.

Better Outline of New Hire Documentation for Developers

Wow!  This "Reverse Onboarding" (as my buddy called it) list of 20 questions a developer should ask when she joins a new team is a fantastic outline for new-hire onboarding and a great, prioritized checklist for getting settled into a new team.