Section 1.1: The Importance of Honest Disagreement

Recently, I listened to an insightful podcast that emphasized the role of disagreement in fostering high performance within teams. It highlights concepts that align with what I’m about to discuss here.

Disagreement is often uncomfortable for many; we naturally tend to seek “social cohesion” by steering clear of conflict. However, evading conflict—more accurately termed debate—hinders the vigorous exchange of ideas that can lead to superior decisions compared to what one person could devise alone. The term "honest disagreement" is intentional; it signifies that productive debate isn't about "winning" or proving oneself right, but rather about striving to arrive at the best possible conclusion.

Honest disagreement entails that every participant thoughtfully considers others' viewpoints to synthesize ideas effectively. When executed properly, this principle fosters a lively exchange where each individual articulates the merits of their suggestions while actively listening to others.

Over time, I’ve developed some guidelines to facilitate constructive and honest disagreement within the technology team. First, senior leaders should share their opinions last to prevent influencing junior members. Typically, I encourage those closest to the decision to voice their thoughts first before seeking input from others.

Second, it’s crucial that discussions remain respectful; this includes avoiding personal attacks and focusing on the ideas rather than their originators. In any group, some individuals are more vocal than others, so I recommend periodically inviting quieter members to contribute their perspectives to ensure diverse input.

It's important to note that this principle has two components: honest disagreement and commitment to decisions. The latter is vital for success. Once a constructive debate reaches a conclusion—regardless of whether consensus was achieved—participants must commit to moving forward with the decision. Many organizations falter because they keep revisiting past decisions or because some members feel compelled to rehash debates until they achieve “victory.” This tendency indicates a misunderstanding of honest disagreement and a need for quick intervention and training.

Additionally, it’s essential to differentiate between two-way and one-way decisions. A two-way decision allows for easy re-evaluation, while a one-way decision is more permanent. Most choices are two-way, yet people often treat them as one-way, leading to unnecessary deliberation. Understanding this distinction from the outset can streamline decision-making processes and enhance organizational agility.

The first video titled "Tools & Technology: Seven Tenets of Process Management" offers insights into the foundational principles that can help streamline processes within technology organizations. It aligns well with the importance of fostering a culture of constructive debate.

Section 1.2: Appointing Single Threaded Leaders

The effectiveness of crucial products or projects correlates directly with the time and focus dedicated to them. Part-time involvement typically leads to partial results. A Single Threaded Leader (STL) is an individual focused solely on a specific product or project, often a Product Manager (PM) whose entire attention is devoted to that initiative. They are not distracted by the management of team members, allowing them to align resources effectively to ensure product success.

An STL should possess excellent interpersonal skills and resilience to motivate cross-functional teams toward a common goal. In technology, STLs are often Technical Product Managers (TPMs) who collaborate across functional areas.

The distinction between an STL and a functional leader, like the Director of Data Engineering, is straightforward. Functional leaders manage multiple projects and focus on the performance of their teams, while STLs concentrate entirely on the product's success. They are the critical champions of the product, and their performance should be primarily assessed based on the successful delivery of their initiatives.

Do all products require an STL? I contend that strategically significant products always need one, while less critical ones may not. Hence, every technology product needs a TPM, but not every TPM needs to function as an STL. For smaller organizations, it’s essential to reserve STL roles for strategically crucial products to avoid excessive costs.

The second video, "5 Organizational Principles That Drive Success," explores foundational principles that can significantly impact organizational effectiveness, complementing our discussion on the role of STLs in tech organizations.

Section 1.3: The Necessity of Documentation

It might seem unusual to highlight documentation as a principle of technology, yet many organizations struggle to prioritize it unless under pressure. Factors contributing to this include the urgency to code and release projects, the unappealing nature of writing documentation, and a general short-sightedness regarding the long-term consequences of inadequate documentation.

My early career taught me the value of thorough documentation when I faced challenges updating my code just six months later due to a lack of notes. Since then, I’ve made it a priority to document everything.

With experience, I’ve recognized that comprehensive documentation aids in several ways: 1) onboarding new team members who can independently familiarize themselves with processes; 2) retaining knowledge within the team during transitions; 3) enabling asynchronous work, allowing team members to consult documentation instead of relying on direct communication; and 4) reducing maintenance costs through clear records of how systems operate.

As a result, one of the first tenets I establish with any technology team I lead is a requirement for thorough documentation. No project can move to production without adequate documentation, which is integral to the project plan. I regularly review documentation to ensure it meets standards, using random checks to enforce compliance.

I advocate for utilizing wiki software like Confluence for maintaining comprehensive documentation, as it scales effectively and remains accessible across the organization. Relying on traditional document formats can complicate management and accessibility. Therefore, I recommend approaching documentation from two angles: user documentation for end users and technical documentation for team members.

If you’re interested in exploring more about building high-performing technology organizations, please follow me on Medium. Your interest encourages me to continue writing on this important topic.