Archive

Self-organisation

How “Constant State of Ship” Drives Transformative Practices

Introduction

In the relentless pursuit of delivering value to customers, with unparalleled speed and reliability, the software development world has yet to widely embrace a revolutionary principle – the “Constant State of Ship”. This state, where software artefacts and products are perpetually poised for release into production environments within just 15 minutes’ notice, has emerged as a driving force behind best practices that enable true continuous deployment. Remarkably, this groundbreaking concept formed the foundation of the pioneering “Javelin” software development approach, a visionary approach conceived by FlowChainSensei (Bob Marshall) at Familiar circa 1996 and onwards, foreshadowing the industry’s even-now-yet-to-be-realised embrace of these practices.

The Power of “Constant State of Ship”

The “Constant State of Ship” serves us as an unyielding forcing function, inviting teams to adopt and adhere to a comprehensive set of best practices that catalyse the seamless flow of software into production. Let us explore how this principle reinforces each of thirteen fundamentals of Continuous Delivery (hat tip to Dave Farley):

The 13 Fundamentals Enabled

  1. A Repeatable, Reliable ProcessWith the ever-present possibility of an imminent release, teams may choose to establish a well-defined, automated pipeline for building, testing, and deploying their software. This process needs to be repeatable and reliable, minimising the risk of human error and ensuring consistency across releases.

    The “Constant State of Ship” mindset suggests that teams have a streamlined, automated release pipeline that can be triggered at any moment. Manual steps and ad-hoc and emergency exception procedures become liabilities, as they introduce variability and increase the chances of mistakes during deployment.

    To achieve this repeatability and reliability, teams are supported to invest in build automation tools, automated testing frameworks, and deployment automation pipelines. Every step of the release pipeline can be codified, documented, and thoroughly tested to ensure predictable outcomes each time.

    Moreover, the “Constant State of Ship” principle fosters an environment of continuous learning and improvement. Any failures or issues encountered during a release are promptly analysed, and the release process is refined to prevent future occurrences. This cycle of continuous feedback and optimisation ensures that the release pipeline remains reliable and efficient, even as the codebase and systems evolve over time.

    By operating in a “Constant State of Ship” mode, teams are invited to treat the release pipeline as a critical component of their software development lifecycle, investing the necessary resources and effort to make it repeatable, reliable, and capable of delivering changes to production environments at a moment’s notice.

  2. Automate All the ThingsIn a “Constant State of Ship” paradigm, manual interventions become significant bottlenecks and risks, hindering the required velocity and reliability. Automation becomes imperative, spanning every aspect of the delivery pipeline, from code compilation to infrastructure provisioning. The threat of an imminent release leaves no room for error-prone manual processes that could delay or derail a deployment. Teams must automate build processes, test execution, environment provisioning, deployment steps, and release orchestration to ensure consistency and minimise the risk of human error.
  3. Maintain a Releasable StateThe core tenet of “Constant State of Ship” requires that the codebase and associated artifacts remain in a perpetually releasable state. This principle invites teams to address issues promptly, maintain a high level of code quality, and vigilantly consider the accumulation of technical debt. Any defects, bugs, or instabilities in the codebase could potentially disrupt an imminent release, leading to costly delays or failures. Teams must adopt practices like continuous integration, automated testing, and ensemble programming to ensure that the codebase remains in a stable, deployable state at all times.
  4. Focus on Robust (Real) Quality Assurance

    In the “Constant State of Ship” paradigm, where the possibility of demand for an immediate release is ever-present, quality assurance cannot be treated as an afterthought. “Constant State of Ship” invites the integration of quality practices throughout the entire development lifecycle, ensuring that quality is baked into the software from inception to deployment.

    While testing plays a role, it is merely one facet of a comprehensive quality assurance strategy. Teams may choose to adopt a holistic approach that emphasises quality as a continuous, pervasive practice woven into every aspect of the development approach.

    This begins with cultivating a culture of quality-driven development, where every team member participates in collective ownership and responsibility for the quality of their work. Practices such as clarity of (quantified a la Gilb) requirements, ensemble programming, peer code reviews, adherence to coding standards, and continuous static code analysis can help identify and mitigate potential issues early in the development cycle.

    Furthermore, “Constant State of Ship” invites teams to embrace principles of iterative and incremental development. By breaking down complex features into smaller, manageable, well-bounded increments, teams can more effectively manage quality risks and ensure that each increment and subsystem meets the required quality criteria before progressing to the next.

    Continuous integration and deployment pipelines play a pivotal role in this quality assurance strategy, enabling teams to continuously validate and verify the software’s functionality, performance, and stability with each incremental change. These pipelines automate the execution of various quality checks, including unit tests, integration tests, and performance tests, providing real-time feedback and enabling teams to address issues promptly.

    However, quality assurance extends beyond mere testing alone. Teams have the opportunity to adopt a holistic approach that encompasses design practices, architectural decisions, and operational readiness. By considering quality implications at every stage of the software development lifecycle, teams can proactively identify and mitigate potential risks, ensuring that the software remains in a releasable state at all times.

    “Constant State of Ship” elevates quality assurance to a core discipline that permeates every aspect of the software development effort. By fostering a culture of quality-driven development and adopting continuous quality practices, teams can attend to the needs of all the Folks That Matter™, with confidence, knowing that their software meets the highest standards of reliability, stability, and performance.

  5. Implement Robust Deployment PipelinesAchieving a “Constant State of Ship” necessitates the implementation of robust deployment pipelines. These pipelines automate the entire process of building, testing, and deploying software changes, ensuring consistency and minimizing the risk of errors. With the ever-present possibility of an imminent release, teams cannot afford manual, error-prone deployment processes. Automated deployment pipelines provide a standardised, repeatable path to production, reducing the likelihood of failed or inconsistent deployments.
  6. Monitor the PipelineRegular smoke testing of the deployment pipeline is crucial in a “Constant State of Ship” mode. This practice helps catch issues early, before they can impact production environments, ensuring the pipeline’s reliability and preventing costly downtime. The possibility of an imminent release amplifies the importance of having a thoroughly validated deployment pipeline. Smoke tests act as a safety net, verifying the integrity of the pipeline and identifying any potential issues that could disrupt a deployment.
  7. Integrate ConstantlyThe “Constant State of Ship” mindset encourages teams to integrate their changes frequently, often multiple times per day. This practice surfaces issues early, reduces merge conflicts, and ensures that the codebase remains in a releasable state, ready for deployment at any given moment. Infrequent integration can lead to divergent codebases, making it harder to identify and resolve conflicts, which could potentially disrupt an imminent release. By integrating frequently, teams can maintain a stable, unified codebase that is always primed for deployment.
  8. Evolve the ArchitectureMaintaining a “Constant State of Ship” over time invites the continuous evolution of the system’s architecture (see also: Reverse Conway). Are teams prepared to refactor and adapt their architectures to accommodate new requirements, technologies, and scaling needs, without compromising the ability to release rapidly and reliably? As products grow and evolve, architectural decisions made early on may become hindrances to continuous deployment. The “Constant State of Ship” principle invites teams to proactively evaluate and evolve their architectures, ensuring that they remain flexible, scalable, and conducive to rapid releases.
  9. Leverage Data EnvironmentsWith the constant possibility of an imminent release, the ability to provision and manage data environments becomes critical. Teams may choose to adopt practices like database versioning, data seeding, and data masking to ensure consistent and reliable testing and deployment across environments, minimising the risk of data-related issues in production. The “Constant State of Ship” mindset invites a robust data management strategy that enables seamless and repeatable deployments, regardless of the data complexities involved.
  10. Mirror Production EnvironmentsTo minimise the risk of issues arising from environmental differences, teams operating in a “Constant State of Ship” mode may choose to ensure that their development, testing, and staging environments closely mirror production environments in terms of configuration, data, and infrastructure. This practice helps identify and address potential issues before they impact the live production system. The possibility of an imminent release heightens the importance of having production-like environments, as any discrepancies could lead to unexpected behavior or failures during deployment.
  11. Codify InfrastructureManually provisioning and configuring infrastructure for each release becomes a significant bottleneck when operating in a “Constant State of Ship” mode. Adopting Infrastructure as Code (IaC) practices, where infrastructure is defined and managed through code, enables teams to provision and tear down environments rapidly and consistently, minimising delays and reducing the risk of configuration drift. The “Constant State of Ship” principle invites a high degree of automation and repeatability in infrastructure management, making IaC a beneficial practice for ensuring rapid, reliable deployments.
  12. Foster Collaborative OwnershipAchieving a “Constant State of Ship” invites a high degree of collaboration and shared ownership among team members. Siloed responsibilities and knowledge become obstacles to rapid delivery. Teams may choose to adopt practices that promote collective code ownership, cross-functional collaboration, and shared understanding of the codebase and delivery processes. The “Constant State of Ship” mindset invites a culture of collective responsibility, where all team members are empowered to contribute to and understand the entire delivery process, enabling seamless and efficient releases.
  13. Continuous ImprovementOperating in a “Constant State of Ship” mode exposes inefficiencies and bottlenecks in the delivery pipeline and processes with uncompromising clarity. Teams may choose to embrace a culture of continuous improvement, regularly reviewing their practices, identifying areas for optimisation, and implementing changes to enhance their ability to deliver value rapidly and reliably. The constant presence of imminent releases acts as a driving force for continuous improvement, encouraging teams to continuously refine their processes, tools, and practices to achieve higher levels of velocity and quality. FlowChain was designed to systematise this very purpose.

The Visionary “Javelin” Approach

The “Javelin” approach (initally named “Jerid”) pioneered by me and my teams at Familiar from 1996 onward, was truly ahead of its time, recognising the transformative power of the “Constant State of Ship” mindset. By enshrining this principle as a cornerstone from its inception, “Javelin” has paved the way for the modern continuous deployment practices that have since become poised to gain industry standard status. This pioneering approach, along with FlowChain and e.g. Prod•gnosis, Flow•gnosis, Product Aikido, etc. exemplifies the spirit of continuous improvement intrinsic to the “Constant State of Ship” principle, ensuring its enduring relevance and impact.

Deep Cultural Implications

Reshaping the Culture and Mindset

Adopting the “Constant State of Ship” principle suggests a profound transformation that extends way beyond technical practices and processes – it hints at a seismic shift in the culture and mindset of software development teams and their parent organisations. This metamorphosis permeates every aspect of the organisation, reshaping shared assumptions, beliefs, and ways of working. However, navigating such a profound cultural shift can be a daunting challenge, often met with resistance and inertia.

This is where the discipline of organisational psychotherapy plays a pivotal role. By applying principles from psychotherapy, sociology, and group dynamics, organisational psychotherapy facilitates teams’ cultural and mindset shifts required to embrace the “Constant State of Ship” paradigm smoothly and effectively.

A Culture of Ownership and Accountability through Empowerment

The “Constant State of Ship” mindset fosters a culture of collective ownership and accountability. Organisational psychotherapy techniques, such as participative decision-making and fellowship, empower team members to take responsibility for the quality, stability, and deployability of the codebase and overall product. This sense of empowerment cultivates a culture of shared ownership, where individuals proactively address issues, collaborate across boundaries, and collectively strive for continuous improvement.

Embracing Transparency and Trust

Maintaining a “Constant State of Ship” requires a high degree of transparency and trust among team members. Organisational psychotherapy practices, such as surfacing shared assumptions and beliefs, encourage open communication and facilitate the identification of problems and risks early. By fostering an atmosphere where team members feel comfortable expressing concerns, sharing mistakes, and seeking help, a culture of transparency and trust emerges, enabling teams to collectively address challenges and ensure the software remains in a releasable state.

Prioritising Continuous Learning

The “Constant State of Ship” principle instills a mindset of continuous learning and improvement. With each release, teams gain valuable insights into their processes, tools, and practices. Embracing new shared assumptions becomes essential, as teams must continuously refine and adapt their approaches based on feedback and lessons learned. This culture of continuous learning fosters an environment of experimentation, where failures are embraced as opportunities for growth, and success is measured by the ability to deliver value rapidly and reliably.

Aligning Towards a Common Goal

Ultimately, the “Constant State of Ship” principle unifies teams around a common goal: meeting the needs of all the Folks That Matter™ with unparalleled speed and reliability. This shared mission transcends individual roles, responsibilities, and technical disciplines. It creates a sense of collective purpose, where every team member’s contribution, regardless of their specific function, is valued and recognised as essential to achieving this overarching objective.

By leveraging organisational psychotherapy techniques, organisations can accelerate and streamline the cultural and mindset shifts required to embrace the “Constant State of Ship” paradigm. This discipline not only makes the transition quicker and easier but also more cost-effective, as it addresses the root causes of resistance and inertia, facilitating a smoother and more sustainable transformation.

By reshaping the culture and mindset of software development teams, the “Constant State of Ship” principle cultivates an environment conducive to continuous deployment success. It fosters a sense of collective ownership, transparency, continuous learning, and shared purpose – traits that are indispensable in today’s rapidly evolving software landscape.

Embracing the Future

When the ability to swiftly adapt and innovate is paramount, the “Constant State of Ship” principle emerges as a beacon, guiding software development teams towards a future of quiet competence and competitiveness. By embracing this mindset, as exemplified by the visionary “Javelin” approach, teams can unlock the power to attend to folks’ needs with unprecedented speed, reliability, and quality – solidifying their organisation’s position as industry leaders in the software development arena.

What is Rigour?

Rigour refers to the strict precision and accuracy with which work is executed in fields like software engineering and collaborative knowledge work (CKW). It entails adherence to standards and best practices for needed outcomes.

The Importance of Getting it Right

Attentive rigour matters because carelessness breeds mistakes. Flaws in logic or bugs in code stem from a lack of rigour. This introduces unwanted surprises, and failures down the line. Rigour is an attitude of mind that zeroes in on getting things right the first time Cf. Crosby, ZeeDee.

The Perils of Getting it Wrong

However, the quest for rigour can go awry when imposed hastily or mindlessly. Establishing rigorous frameworks like requirements analysis, peer review etc. does carry overhead. Teams can get so bogged down chasing perfection that creativity, productivity and morale suffer. Or so much time is spent eliminating small defects that bigger picture progress slows. Like most things, balance is warranted.

The Laissez-Faire Extreme

At the other end of the spectrum from rigour lies the laissez-faire attitude. This French phrase meaning “let it be” encapsulates a laid-back approach where participants have broad freedom to work in whatever manner they choose.

In software and knowledge work contexts, laissez-faire environments feature very few enforced policies, protocols, or mechanisms for ensuring quality. Creativity and unhindered workflow takes priority over rigour. Peer reviews, quality assurance, and documentation are optional. Teams self-organise organically without work standards.

This spontaneity can spark innovation but has pitfalls. Lack of rigour tacitly permits cut corners, gaps in logic, unfinished ideas and sloppy execution. With an easy-going approach, easily preventable flaws accumulate and undermine end results.

In applied contexts like commercial software development, laissez-faire practices practically guarantee shoddy work products riddled with defects. User needs demand rigour not as an obstacle, but as an enabler of excellence. Finding the right balance is key.

The absence of rigour embodied in laissez-faire philosophies may promote freedom. But the ensuing chaos leaves the fruits of hard work easily compromised. Some structure and rigour ultimately serves applied collaborative knowledge work better in the long run.

While cutting corners is not an option, forced rigour without context can mean marginal gains at disproportionate cost. Rigour must enable, not encumber, the pursuit of excellence. Teams that foster a culture where rigour flows from all participants, intrinsically and voluntarily, tend to find the sweet spot. Getting there requires clarity of purpose, patience, and care. Do that and rigour lifts the quality of collaborative knowledge work substantially over time.

What does rigour mean to you and your team?

The Social Side of Improvement

While organisational purpose, leadership directives, customer feedback and development processes model guide improvement efforts in business and technology, the truth is that willingness to improve is driven primarily by social and behavioral factors within teams. Even the most meticulous goals, inspired leadership, and incentive structures fall flat without the initiative of people who develop, design and maintain systems. Understanding social dynamics is key.

Cultivating Constructive Exchanges

Improvement starts with recognition of social blockers* and unhelpful or deleterious assumptions – things which teams and individuals may find uncomfortable to confront. Where people feel uncertain about transparency, or fear judgment, they tend to hide issues instead of raising them. Leaders may choose to actively cultivate environments geared towards constructive exchanges, allowing for open dialogue around issues. This helps normalise the process of identification and resolution of deficiencies.

Intrinsic vs Extrinsic Motivation

While extrinsic rewards like bonuses or promotions may temporarily boost improvement efforts, intrinsic joy and satisfaction derived from enhancing systems sustains team momentum better long-term. By tapping into natural human needs for growth, learning and overcoming challenges, organisations can activate self-perpetuating cycles of improvement. Especially in CKW (Collaborative Knowledge Work) this intrinsic drive always outweighs extrinsic rewards.

Team Cohesion and Alignment

Teams that agree on why improvements matter and how to make them happen can work together better to upgrade the way the work works. When a team shares beliefs about the value of making progress, they can encourage each other to take helpful steps through dialogue, teamwork, and motivation. Without this same vision and coordination as a team, people can lose steam and direction, which slows progress.

No policies handed down by an organisation can force improvement to happen without support within the team itself – people’s drive to learn and tackle problems as a group keeps development going over time. Smart teams focus first on creating a common purpose and satisfaction from incremental gains among the team members. This activates social forces within the team that enable ongoing improvements to happen more easily.

In essence, having people work positively together as a team, united by common goals and motivations, is what sustains long-term progress above all. Savvy teams build pride in small wins, and in camaraderie focused on solving challenges that come up. This gives the team itself an inner drive to keep improving.

The Role of Nonviolence

Teams working together day after day to refine and upgrade systems will inevitably encounter disagreements, debates over technical design tradeoffs and even interpersonal conflicts. Without mindful effort, discussions around imperfections can turn counterproductive if they degrade into blame games, aggressive posturing or dismissiveness. Leaders therefore need to proactively encourage nonviolent communication norms.

Attending to Folks’ Needs

For nonviolence to truly take root, teams may choose to move beyond civil language, to proactively attending to the psychological, emotional and practical needs of team members. This involves empathy, active listening, validating concerns without judgment, and extending support to help resolve issues causing distress. By being attentive caregivers, teams allow themselves to feel safer, exposing vulnerabilities including skill limitations and interpersonal issues that may be blocking progress.

Empathetic Language

By teaching team members to frame problems objectively, avoid finger-pointing around issues and discuss potential improvements with empathy, compassion and non-judgment, conversations become solution-focused. This prevents people from becoming defensive when their work is critiqued and keeps debate civil, allowing cooperative analysis of flaws.

Mediation Over Escalation

When conflicts around system deficiencies do emerge within teams, leaders should mediate issues through open dialogue between parties rather than let tensions escalate. Allowing people to air their perspectives fully and feel heard diffuses situations where egos can clash during ongoing refinement efforts. If deficiencies are structural, collective responsibility should be emphasized over singling out individuals to avoid disincentivizing transparency around limitations.

Nonviolence In Action

Ultimately, by normalizing nonviolent communication, dialogue and conflict mediation practices within teams, leaders can ensure that the necessary discussions around flaws and areas of improvement do not themselves disturb the social fabric underlying cooperative work. This sustains healthy relationships between members which are foundational for iterative development.

*Social Blockers

“Social blockers” refer to interpersonal or group dynamics that inhibit progress, innovation, and improvement in teams and organisations. Some examples of social blockers include:

  1. Groupthink – Where there is pressure on members to conform to a dominant narrative and not challenge assumptions. This smothers dissenting perspectives that may reveal flaws or areas to improve.
  2. Blame Culture – When failure or deficiencies consistently get attributed to individuals’ mistakes rather than addressing systematic gaps. This makes people defensive about problems rather than openly discussing solutions.
  3. Office Politics – Power struggles, protection of turf, and ego issues can distract focus away from constructive progress. Backbiting, sabotage, nepotism etc. form rifts that block alignment.
  4. Poor Leadership – Leaders who don’t welcome critical feedback or consumer insights, provide inadequate resources/training, resist change, or don’t mediate conflicts actively perpetuate barriers to improving the social dynamic.
  5. Complacency & Myopia – Organisations can get habituated to certain ways of operating, becoming complacent. Lack of outside perspective also breeds collective myopia to needs for positive change.
  6. Toxic Communicational Norms – Uncivil dialogue, aggressive confrontation styles, disrespect, and microaggressions during discussions on progress inhibits constructive exchanges in teams – somthing vital for improvement.
  7. Violence & Intimidation – In toxic organisational cultures, literal or symbolic threats of violence, intimidation, and aggression are sadly used to suppress dissent and critical feedback that reveals improvement areas. By creating an atmosphere of fear, obligation, guilt and shame,, such coercive tactics block openness.

Essentially any interpersonal and group dynamic that suppresses objective problem-solving, transparency around limitations, innovation through fresh perspectives, and constructive dialogue hampers the will and ability to improve – be it products, services or workflows. Managing these “social blockers” is key.

Further Reading

Rosenberg, M. B. (2015). Nonviolent communication: A language of life (3rd ed.). PuddleDancer Press.

The Far-Reaching Impacts of the Law of Unintended Consequences

The law of unintended consequences states that actions will have unanticipated effects, often counterproductive ones. This concept profoundly applies to software development, and collaborative knowledge work more generally. In these domains involving interdependent human and technical factors, even well-intentioned plans often go awry.

This post explores key unintended consequences that manifest in software develeopment and collaborative knowledge work (CKW):

Technical Debt

Technical debt refers to the deliberate choice to take shortcuts in order to expedite software delivery. Like financial debt, it can be beneficial if consciously taken on and repaid through refactoring. However, scheduled repayments often get deferred as teams race to meet deadlines. The “interest” accrues as ongoing maintenance costs.

Feature Creep

The lean startup mentality of minimum viable products and iterative development has advantages. However, an unintended consequence is feature creep – products become bloated as developers continuously add but rarely subtract capabilities. And as management finds more and more pointless or decreasing value work to keep their standing teams busy. The result is complex products growing like topsy.

Information Overload

Modern collaboration tools enable unprecedented information sharing. But an unintended consequence is information overload, which hampers productivity and decision-making. Each piece of information seems useful, yet the cumulative result is a distracted, overburdened workforce.

Tunnel Vision

In software development, teams focus on completing narrowly defined tasks. This tunnel vision means losing sight of the big picture. Pressure to deliver assigned work leads to task-oriented rather than solution-oriented thinking. This tendency is exacerbated by the widespread case of work assignments coming from management rather than self-organising teams. The unintended consequence is misalignment, reduced value, and lack of integration.

Morale Issues

Open information flow and accountability bring major benefits. However, the unintended consequence can be decreased risk-taking, and morale problems. With every action visible and judged, workers avoid mistakes that could impact performance reviews. Innovation suffers when people focus on safe, incremental tasks and protecting thir own arses (cf. CYA).

Busywork

When work is misaligned with overall goals and strategies, inevitable busywork is the result. People spin their wheels on tasks that provide no real value to customers or the organisation and its customers. Energy is frittered away on going through the motions versus really attending to folks’ needs.

Perverse Incentives and Focus on Productivity

Reward systems, especially those aimed at boosting individuals’ productivity, undermine quality and teamwork. For example, compensating developers based on lines of code incentivises quantity over quality. Emphasising individual contributors over collaboration is another common unintended consequence.

Loss of Tacit Knowledge

Capturing processes, best practices, and “how-to” knowledge in wikis and databases can provide some benefts. However, over-reliance on documentation loses tacit knowledge that comes from experience and learned skills. Key contextual information gets lost when veterans leave without transfering hard-to-document knowledge.

Technical Monocultures

Standardisation has advantages in terms of compatibility and skill transferability. But an unintended consequence is the risk of monoculture technology stacks vulnerable to single points of failure. If a widely used framework has a major bug, many downstream systems are suddenly impacted.

Integration Headaches

Connecting modern microservices architectures can provide agility. However, an unintended consequence is integration headaches when stitching together disparate systems and data sources. Overally product reliability can also suffer. Development timelines often underestimate the complexity of integrating components.

Zombie Projects

Organisations generally find it difficult or impossible to kill failing initiatives. There is a tendency for questionable projects to lurch forward as “zombies” that nobody wants to end due to e.g. sunk cost fallacy. The unintended consequence is opportunity costs – as zombies consume budgets, workers and that rarest of all resources – management attention.

Mitigation Strategies

With sufficient foresight and systems thinking, organisations can choose to institute mitigating actions:

  • A systemic focus on the Antimatter Principle (have all efforts directed at attending to the needs of all the Folks That Matter™ Cf. The Needsscape).
  • Institute product management disciplines to curtail feature creep (Cf. Product Aikido).
  • Promote diversity and constructive dissent to counter groupthink.
  • Prioritise attending to folks’ needs, including capturing (e.g. documenting) knowledge that serves folks needs for reference information .
  • Stay vigilant w.r.t. unintended consequences (often only obvious through hindsight).
  • Engage with Organisational Psychotherapy so issues can be surfaced, and reflected upon, early.

By understanding where the Law of Unintended Consequences applies, teams can take proactive steps to minimise disruptive friction and dysfunction. The result is better alignment, usable products, and organisations where the whole exceeds the sum of misguided parts.

The Two Questions Guiding Self-Organising Teams

Time to update this classic post!

[Tl;Dr: Navigating the complexities of self-organising teams isn’t a walk in the park, but these questions can serve as your compass.]

Start with these crucial questions

  1. “What is the purpose of this team from the peerspective of all the Folks That Matter™?”
  2. “What measures will the team* use to understand and improve its work?”

*For avaidance of ambiguity, it’s down to the team to choose and track their measures (not managers, not customers, etc.).

Misconceptions: Self-Organising Isn’t So Clear-Cut

Ever been embedded in a self-organising unit? It’s anything but straightforward. In theory, it’s about people coming together to figure things out. But the lived experience is something else entirely, full of nuanced emotions and dynamics you’ve got to experience to fully grasp.

The Learning Curve

Need to understand self-organising teams? If you’re new to it, learning on the job is okay, especially with a seasoned coach guiding the way. If you’re joining an already self-organising team, they’ll help you fit in without breaking stride.

But if you’re in a leadership role, misunderstanding the concept can lead you to unintentionally sabotage the very benefits you’re trying to foster. Benefits which include:

  • Elevated engagement
  • Focused commitment
  • Alignment with organisational purpose
  • Improved morale
  • Meticulous attention to detail
  • Productivity
  • Increased speed  of delivery

The Oblique Approach

Chasing these benefits head-on can make them elusive. Instead, approaches like Fellowship, Servant Leadership or Host Leadership can create a more fertile ground. The key is not pushing for self-organisation but enabling a space for purposeful dialogue.

Paradox of Attention

Oddly enough, the more you make self-organising your goal, the more you push it away:

  • Emphasise self-organising, and it weakens.
  • Focus on the team’s purpose, and it strengthens.

Further Reading

Stack, J. (1992). The Great Game of Business. Doubleday.
Greenleaf, R. K. (1998). The Power of Servant Leadership. Berrett-Koehler Publishers.
McKergow, M. (2014). Host Leadership. Solutions Books.
Kay, J. (2010). Obliquity: Why our goals are best achieved indirectly. Profile Books.
Whitmore, J. (2002). Coaching for Performance. Nicholas Brealey Publishing.
Seddon, J. (2003). Freedom From Command & Control. Vanguard Press.
Derby, E. (2018). Misconceptions About Self-Organising Teams. [Blog Post]. Retrieved from [insert website].

Applying Auftragstaktik in Software Development: Fostering Fellowship Over Hierarchy

Auftragstaktik, an organisational philosophy originating from the Prussian military in the 19th century, and more recently the USMC, has found resonance in various spheres, from combat planning to corporate management. At its core, Auftragstaktik focuses on the principle of needs-oriented leadership. It’s the idea that leaders should define goals – the “commander’s intent – and provide the necessary resources, but leave the “how” to subordinates, thus enabling those subordinates’ creativity, flexibility, and autonomy.

However, an emerging question is how to apply Auftragstaktik in environments that seek to de-emphasise hierarchical management structures and instead foster a sense of fellowship. Specifically, in the world of software development, the traditional reliance on junior officer analogues such as team leaders, Scrum Masters, senior developers, or middle managers is evolving. There is an increasing push to build a more egalitarian and collaborative culture, which can sometimes appear at odds with the military hierarchy from which Auftragstaktik emerged.

Here’s how we can reconcile these two approaches and effectively apply Auftragstaktik in software development environments that prioritise fellowship over hierarchical roles:

Foster a Culture of Ownership

The beauty of Auftragstaktik is that it promotes a sense of ownership among team members by providing them the freedom to approach work in ways they find most effective. In a fellowship-oriented culture, this sense of ownership becomes even more profound. Fellowship empowers teams to not only implement solutions, but also identify problems, propose assignments, and provide feedback to others. This fosters a sense of mutual respect, collaboration, and shared responsibility that is central to a high-productivity culture.

Value Collective Intelligence

A fellowship-oriented culture values collective intelligence above individual contribution. Similarly, Auftragstaktik can be implemented in a way that emphasises the strength of the collective team. By articulating clear needs to be attended to (cf. the Needsscape) and allowing the team to collaborate on the means to meet these needs, you draw on the diverse skills, experiences, and perspectives within the team. This maximises innovation and problem-solving capabilities.

Encourage Continuous Learning

For Auftragstaktik to work effectively within a fellowship model, an organisation might choose to promote and value continuous learning. Teams may choose to cultivate their ability to assess their strategies, learn from their mistakes, and continuously adapt. This invites the organisation to provide space for reflection, constructive feedback, and iteration.

Promote Transparency and Trust

Trust is the bedrock of Auftragstaktik and a fellowship-oriented culture. The organisation might choose to trust their teams to devise the best strategies, while team members need to trust each other to carry out their respective parts. This trust is cultivated through transparency in communication, objectives, expectations, and feedback.

Equip Your Team

Finally, for teams to take responsibility for the “how,” they need to be adequately equipped with the necessary tools and resources. This includes not only tangible assets, such as software tools, but also intangible ones such as information, knowledge, skills, budgets, and support.

Summary

In conclusion, applying Auftragstaktik in a fellowship-oriented environment requires a slight shift in focus from the traditional approach. Instead of concentrating on hierarchy and rigid roles, the emphasis should be on mutual trust, transparency, and the empowerment of the team. Such an approach would not only harness the power of Auftragstaktik but also foster a culture of camaraderie, collaboration, and collective ownership, which are at the heart of the fellowship model.

Further Reading

For a complete book detailing the convergence of Auftragstaktik and Fellowship (and Aikido, too), look no futher than my awesome book, “Product Aikido“:

Marshall, R. W. (2013). Product Aikido. Retrieved from /wp-content/uploads/2013/04/productaikido041016.pdf

The Human Element

Why VP Engineering Roles Revolve Around People and Culture, Not Just Tech

The title ‘VP Engineering’ may conjure images of a senior executive hunched over keyboards, fervently writing software code, and designing complex architecture. However, the truth is that this role has almost nothing to do with engineering in the technical sense and almost everything to do with people and culture. Although it might seem counterintuitive, let’s explore why this notion holds considerable validity.

The Veil of Technicality

By training and by function, VPs of Engineering often come from a software or engineering background. They’ve likely spent many years at the coalface of technology, wrestling with complex systems and writing code. However, as they rise in the ranks and assume this pivotal position, their role transforms.

Being a VP Engineering isn’t about being the best coder or systems architect. Instead, it becomes about fellowship, strategy, and building a team-friendly culture that empowers all employees to work at their best. It’s about orchestrating talent, aligning them with company goals, and facilitating the right environment for innovation to flourish.

The Fellowship Imperative

While technical prowess is undeniably important in any technology-driven company, the most successful VPs of Engineering understand that their leadership capabilities have a more significant influence on the success of their teams and their company.

In their hands lies the responsibility of hiring, inspiring, and retaining the best engineers in the market. They ensure that their teams have the necessary tools, resources, support, and training to perform at their optimal best. Moreover, they create an environment where creativity is encouraged, failure is seen as an opportunity for learning, and success is collectively celebrated.

The Crucial Role of Culture

Company culture is a critical factor in any organisation’s success. For technology firms, this rings even truer. Culture defines how the organisation operates, how teams and departments collaborate, and how individuals contribute to the collective success.

The VP Engineering plays a vital role in shaping this culture. By embodying and promoting values such as innovation, collaboration, continuous learning, and respect, they can foster a culture that supports both fellowship and team cohesion.

Moreover, a well-cultivated culture is a competitive advantage, attracting top talent and driving employee retention. When engineers feel that they are part of something greater, are valued, and have room for professional development, they’re more likely to stay and thrive.

Nurturing People

In essence, a VP Engineering’s job is about nurturing people and optimising culture, rather than crafting code. Their role demands soft skills much more than hard skills. These include communication, problem-solving, conflict resolution, and change management skills.

They support their teams through constant change and innovation, mitigate risks, and resolve conflicts. They are adept at communicating complex issues in ways that stakeholders can understand. They also have to be approachable and empathetic, facilitating open dialogue and trust.

Summary

In conclusion, the VP Engineering’s role, much like the title suggests, involves engineering – not of software, but of highly effective, motivated teams and a culture that empowers them. They’re not just executives in a tech company; they’re linchpins in a people-centric profession. Their role transcends code, components, and systems, shaping the very heart of the organisation: its people and its culture.

From Leadership to Fellowship: Expanding Fiedler’s Contingency Theory

In the wide realm of organisational psychology, one theory stands out for its distinctive approach to understanding leadership: Fred Fiedler’s contingency theory. This innovative model, proposed by the Austrian-born American psychologist Fred Fiedler, reshaped how we perceive leadership effectiveness and its dependence on both the leader’s style and the situation at hand.

Fiedler’s Contingency Theory: An Overview

Fiedler’s groundbreaking work focused on two primary factors: leadership style and situational favorableness. He developed the ‘Least Preferred Co-worker’ (LPC) scale to quantify an individual’s leadership style as either task-oriented or relationship-oriented. Those who score low on the LPC scale tend to prioritise tasks, while high scorers place emphasis on relationships.

Situational favourableness, the second part of the equation, refers to how much a situation allows a leader to control and influence their followers. It considers aspects such as leader-member relations, task structure, and the leader’s positional power.

According to Fiedler, task-oriented leaders excel in situations that are either highly favourable or highly unfavourable, while relationship-oriented leaders do well in moderately favourable situations. This paradigm suggests that there’s no one-size-fits-all leadership style. Instead, it highlights the importance of aligning leadership styles with situational demands to achieve effectiveness.

Generalising and Extending Fiedler’s Theory to Fellowship Models

Fiedler’s model has been instrumental in understanding leadership dynamics within an organisation. But what if we extended this theory beyond the confines of leadership, into other models, such as fellowship? Fellowship refers to the participation and engagement of individuals in a group who may not be in a leadership role but significantly influence the group dynamics. (For example, Tolkien’s Fellowship of the Nine in his book The Lord of the Rings).

Just as leadership style impacts the effectiveness of a leader, we can hypothesise that a fellowship’s approach – let’s term it as ‘fellowship style’ – could have a similar effect. A fellowship could be task-focused, aiming at the objective completion of the group’s tasks, or relationship-focused, prioritising social harmony and interpersonal connections within the group.

Furthermore, the same principles of situational favourableness could be applied. The group’s cohesiveness, the clarity of tasks, and the influence fellows have within the group could dictate the effectiveness of their contributions. A task-focused fellowship might thrive as a highly cohesive group with well-defined tasks, whereas a relationship-focused fellowship might excel in situations where tasks are ambiguous and the group needs to foster better communication and teamwork.

Connecting Leadership and Fellowship: A New Horizon in Organisational Psychology

Fiedler’s contingency theory underscores the reality that effective leadership hinges on the compatibility of a leader’s style with their situation. By applying this to the concept of fellowship, we open new avenues for exploring group dynamics and organisational behavior.

The extension of Fiedler’s theory to encompass fellowship aligns with the evolution of modern workplaces that emphasise collaboration and shared responsibilities over hierarchical leadership. It promotes the idea that everyone, regardless of their position in the organisation, can contribute effectively if they align their approach to the group’s needs.

From this perspective, leadership wanes and fellowship waxes, the latter ever more critical to the success of the organisation. As we continue to explore these dynamics, Fiedler’s contingency theory serves as a solid foundation, reminding us of the significance of situational factors and the need for flexibility in our approach to both leadership and fellowship. The future of organisational success relies not so much on great leaders, but rather on great fellows.

You Don’t Get It

Listen up, folks! There’s a whole lot of you out there in the business world who just don’t get it. You’re missing the point, and it’s costing you. Big time.

Unheard truths echo,
In business, losses follow,
Insight, hard to swallow.

Culture Rocks

First up, let’s talk about culture. Not the kind you find in a yogurt, but the kind that permeates every corner of your organization. Culture isn’t just about casual Fridays or the company picnic. It’s about shared values, beliefs, and attitudes. It’s the glue that holds your team together and drives them towards a common goal. Ignore it at your peril.

Culture’s silent pulse,
Invisible yet potent,
Shapes the firm’s heartbeat.

It’s the System, Stupid

Next, you need to understand how the work works. It’s not enough to just do your job. You need to understand the processes, the systems, the mechanics of how things get done. That’s how you find efficiencies, eliminate waste, and improve productivity.

Work’s rhythm, unseen,
In its flow, wisdom gleaned,
In details, truth’s gleaned.

Auftragstaktik

Ever heard of Auftragstaktik? It’s a German military term that means “mission command.” In business, it’s about moving decision-making real close to the front line. It’s about empowering your people to make decisions and take action. It’s about trust and accountability. It’s about getting out of the way and letting your people do what they do best. Some call this self-organising teams, but it’s more, much more, than that.

Auftragstaktik reigns,
Decisions like scattered grains,
Empowerment gains.

Find the Demand

Next: product-market fit. It’s not just a buzzword. It’s about finding the sweet spot where your product meets a market need. If you’re not there, you’re just throwing your time and money into the wind.

Product-market fit,
In the sweet spot, we commit,
Success, bit by bit.

Radical Pivots

And then there’s the pivot. Not the kind you do in basketball, but the kind that can save your business. Markets change. Customers change. If you’re not willing to change with them and go where the demand is, you’re going to rapidly become irrelevant. And out of business.

Pivot, change your stance,
In market’s fickle dance,
Adaptance is chance.

Wake Up!

So wake up, folks! Pay attention to these things. They’re not just buzzwords. They’re the keys to success in business. And if you don’t get that, well, you’re just not getting it.

Awake, heed these words,
Not mere buzz, but success’ birds,
Ignorance affords.

Further Reading

Gerber, M. E. (1995). The E-Myth revisited: Why most small businesses don’t work and what to do about it. HarperBusiness.
Winget, L. (2008). People are idiots and I can prove it!: The 10 ways you are sabotaging yourself and how you can overcome them. Gotham Books.
Winget, L. (2007). It’s called work for a reason!: Your success is your own damn fault. Gotham Books.
Bungay, S. (2011). The Art of Action: How Leaders Close the Gaps Between Plans, Actions and Results. Nicholas Brealey Publishing.

Team Fruit Bowl Quiz

Take the quiz to find out what’s important to your teamies.

This quiz is based on my new book “The Team Fruit Bowl”, now available on LeanPub .

Quiz version v1.0.
Based on: The Team Fruit Bowl book, version v1.2

Which Fruit Best Characterises Your Team?

Learn a little more about your team and how it sees itself. Try this quiz yourself, and then compare your answers with your teamies, or tackle the quiz together, as a teambuilding exercise.

The Benefits

Understanding the characteristics of your team offers numerous benefits, not only for the team as a whole but also for each individual teamie. Here are just some of the key benefits:

  1. Effective Communication: By understanding your team’s characteristics, you can identify the best methods for communication. Some people may prefer direct, straightforward information, while others might need more context or prefer a softer approach. Understanding these preferences can improve the clarity and effectiveness of team communication.
  2. Enhanced Collaboration: Different teamies will have different strengths, weaknesses, and working styles. By understanding these, you can better collaborate, as tasks can be allocated in a way that plays to each person’s strengths and compensates for their weaknesses.
  3. Conflict Resolution: Knowing your teamies’ characteristics can help anticipate potential conflicts and handle them more effectively when they do arise. Understanding different personality types can provide insights into how individuals might react in a conflict situation and what resolution strategies might be most effective.
  4. Motivation: Different people are motivated in different ways. Some teamies may be more driven by their need for recognition, while others might value autonomy or the opportunity for professional growth. By knowing the needs of your teamies, you can help create an environment that maximises motivation and productivity.
  5. Building Trust: Understanding and acknowledging the individual characteristics of teamies can help build trust within the team. When teamies feel understood and valued for their unique contributions, they are likely to trust their colleagues and peers more.
  6. Professional Development: With an understanding of your team’s characteristics, you can provide more personalised feedback and professional development opportunities. This can help each teamie grow and improve in a way that aligns with their skills, needs, and career goals.
  7. Increased Effectiveness: Understanding the dynamics and characteristics of your team allows for the development of effective workflows and processes. You can design these to take advantage of the unique skills and talents in your team, leading to increased efficiency and productivity.

Rationale

Knowing a team’s characteristics contributes to effective team management and can lead to improved performance, better relationships, and a more positive work environment. The use of fruit as a metaphor adds some fun and can reduce the discomfort that some teamies may feel whilst discussing these things.

Instructions

For each question, select the answer that best describes your team. At the end, tally up the number of times you selected each fruit. The fruit with the most selections represents your team.

The Quiz

  1. When your team faces a challenge, you…
  • (Banana) Stick together and learn from the experience.
  • (Pomegranate) Leverage the diversity and unique skills of each team member.
  • (Kumquat) Show resilience and bounce back stronger.
  • (Pineapple) Use your tough exterior to protect the team while maintaining a rewarding essence.
  1. Your team’s growth is best described as…
  • (Banana) Synchronous, with each individual ripening at their own pace.
  • (Mango) Slow and steady, with patience and meticulous care.
  • (Watermelon) Fast and exciting, with a juicy interior.
  • (Blueberry) Incremental, with many small contributions adding up.
  1. Your team’s approach to diversity is…
  • (Pomegranate) Embracing unity within diversity.
  • (Apple) Appreciating and leveraging the unique qualities of each team member.
  • (Grape) Forming a close-knit cluster where everyone contributes.
  • (Pineapple) Balancing a tough, protective exterior with a sweet, rewarding interior.
  1. Your team’s approach to balance and harmony is…
  • (Pear) Focusing on shape and ripening, understanding that everyone grows at their own pace.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster, with everyone working closely together.
  • (Peach) Balancing the soft and hard aspects of teamwork.
  1. Your team’s approach to innovation is…
  • (Apple) Nurturing core assumptions and beliefs while embracing the power of diversity.
  • (Lemon) Making lemonade out of lemons, seeing challenges as opportunities to innovate.
  • (Raspberry) Embracing delicacy and fellowship, understanding that great ideas can come from anywhere.
  • (Blueberry) Believing that many small contributions can add up to big innovations.
  1. Your team’s approach to team dynamics is…
  • (Banana) Understanding that growth might come with some bruises, but seeing them as opportunities for learning.
  • (Pomegranate) Emphasizing the integral role each team member plays in the team.
  • (Kumquat) Showing resilience in the face of challenges.
  • (Pineapple) Balancing a tough, protective exterior with a sweet, rewarding interior.
  1. Your team’s approach to team identity and culture is…
  • (Pomegranate) Emphasizing the integral role each team member plays in the team.
  • (Apple) Nurturing core assumptions and beliefs, providing unity and direction.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster where everyone contributes.
  1. Your team’s approach to team development is…
  • (Banana) Understanding that growth might come with some bruises, but seeing them as opportunities for learning.
  • (Mango) Believing in patience and meticulous care.
  • (Watermelon) Growing fast and seizing opportunities.
  • (Blueberry) Believing that many small contributions can add up to big results.
  1. Your team’s approach to team unity is…
  • (Pomegranate) Emphasizing the integral role each team member plays in the team.
  • (Apple) Nurturing core assumptions and beliefs, providing unity and direction.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster where everyone contributes.
  1. Your team’s approach to team resilience is…
  • (Banana) Understanding that growth might come with some bruises, but seeing them as opportunities for learning.
  • (Kumquat) Showing resilience in the face of challenges.
  • (Pineapple) Balancing a tough, protective exterior with a sweet, rewarding interior.
  • (Lemon) Making lemonade out of lemons, seeing challenges as opportunities to innovate.
  1. Your team’s approach to team growth is…
  • (Banana) Understanding that growth might come with some bruises, but seeing them as opportunities for learning.
  • (Mango) Believing in patience and meticulous care.
  • (Watermelon) Growing fast and seizing opportunities.
  • (Blueberry) Believing that many small contributions can add up to big results.
  1. Your team’s approach to team diversity is…
  • (Pomegranate) Emphasizing the integral role each team member plays in the team.
  • (Apple) Appreciating and leveraging the unique qualities of each team member.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster where everyone contributes.
  1. Your team’s approach to team balance is…
  • (Pear) Focusing on shape and ripening, understanding that everyone grows at their own pace.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster, with everyone working closely together.
  • (Peach) Balancing the soft and hard aspects of teamwork.
  1. Your team’s approach to team harmony is…
  • (Pear) Focusing on shape and ripening, understanding that everyone grows at their own pace.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster, with everyone working closely together.
  • (Peach) Balancing the soft and hard aspects of teamwork.
  1. Your team’s approach to team innovation is…
  • (Apple) Nurturing core assumptions and beliefs while embracing the power of diversity.
  • (Lemon) Making lemonade out of lemons, seeing challenges as opportunities to innovate.
  • (Raspberry) Embracing delicacy and fellowship, understanding that great ideas can come from anywhere.
  • (Blueberry) Believing that many small contributions can add up to big innovations.
  1. Your team’s approach to team dynamics is…
  • (Banana) Understanding that growth might come with some bruises, but seeing them as opportunities for learning.
  • (Pomegranate) Emphasizing the integral role each team member plays in the team.
  • (Kumquat) Showing resilience in the face of challenges.
  • (Pineapple) Balancing a tough, protective exterior with a sweet, rewarding interior.
  1. Your team’s approach to team identity and culture is…
  • (Pomegranate) Emphasizing the integral role each team member plays in the team.
  • (Apple) Nurturing core assumptions and beliefs, providing unity and direction.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster where everyone contributes.
  1. Your team’s approach to team development is…
  • (Banana) Understanding that growth might come with some bruises, but seeing them as opportunities for learning.
  • (Mango) Believing in patience and meticulous care.
  • (Watermelon) Growing fast and seizing opportunities.
  • (Blueberry) Believing that many small contributions can add up to big results.
  1. Your team’s approach to team unity is…
  • (Pomegranate) Emphasizing the integral role each team member plays in the team.
  • (Apple) Nurturing core assumptions and beliefs, providing unity and direction.
  • (Orange) Forming layers and connected segments, with everyone playing their part.
  • (Grape) Forming a close-knit cluster where everyone contributes.
  1. Your team’s approach to team resilience is…
  • (Banana) Understanding that growth might come with some bruises, but seeing them as opportunities for learning.
  • (Kumquat) Showing resilience in the face of challenges.
  • (Pineapple) Balancing a tough, protective exterior with a sweet, rewarding interior.
  • (Lemon) Making lemonade out of lemons, seeing challenges as opportunities to innovate.

After participants answer these questions, you can tally the results to determine which fruit most closely represents your team. The fruit with the most selections represents your team.

Just in case you were wondering: Some questions appear more than once. This is intentional.

How To Support Teams’ Learning And Development Needs

Organisations can fundamentally support their teams’ learning and development needs by cultivating an environment that fosters intrinsic motivation. But how to achieve that?

One approach is the adoption of the Toyota Kata model. The term ‘Kata’, borrowed from martial arts, refers to a structured routine practiced so it becomes second nature. Toyota applies this concept in the realm of continuous improvement and coaching.

To put it simply, Toyota Kata isn’t about providing answers, but about establishing an organisational culture that motivates individuals to discover solutions themselves. This inherently appeals to intrinsic motivation, as employees are driven by the satisfaction of mastering challenges, the thrill of problem-solving, and the joy of personal development. They’re not learning and developing because they’re told to, they’re doing it because they want to.

Organisations utilising the Toyota Kata model promote a learning mindset where curiosity, creativity and resilience are valued. They foster an environment where it’s okay to make mistakes, as they’re considered part of the learning process. This can reduce or eliminate the fear of failure, which significantly hinders innovation and risk-taking.

Further, the Kata routines can ensure teams have a clear focus and direction. Through the Improvement Kata, employees are guided to understand the direction, grasp the current condition, establish the next target condition, and experiment towards that target. When people know where they’re headed and why, it encourages them to take ownership of their roles and fosters intrinsic motivation.

Moreover, the Coaching Kata supports managers in developing their subordinates by not simply providing solutions, but by asking insightful questions that encourage critical thinking. This way, managers become facilitators for growth rather than just taskmasters. This coaching approach can instill a sense of competence and autonomy, which are key components of intrinsic motivation.

Toyota Kata isn’t about achieving perfection, but about continuous learning and improvement. By acknowledging this journey and celebrating the learning process, organisations can make their teams feel valued and motivated to continue their development.

So, an organisation’s support for its teams’ learning and development needs goes way beyond merely offering training programmes or growth opportunities. It’s about creating a culture of continuous improvement and learning, fostering intrinsic motivation, and supporting this with models like Toyota Kata. When organisations achieve this, they’ll likely see not only improvements in their team’s skills and capabilities, but also enhanced engagement, productivity, and innovation.

Mastering the Art of Self-Organisation with a Modicum of Expert Support

💡 Imagine a world where your team conquers every challenge, seamlessly navigating the ever-changing landscape of business and software development. It’s possible, you know – but only if we strike the perfect balance between self-organisation and expert support. Let’s dive into how you can help your team unlock its full potential while overcoming the inherent limitations of self-organisation.

➡ Self-organisation – it’s a buzzword we’ve all heard thrown around in the world of business and software development teams. While it’s a fantastic concept, it’s important to recognise that it does have its limits. Let’s have a little chat about what those limitations might be, shall we?

Now, don’t get me wrong – self-organisation can sometimes work wonders. It can boost team morale, encourage innovation, and even improve productivity. But let’s face it, most teams aren’t full of experts in every single area. That’s just not realistic. No matter how talented and skilled team members are, they simply can’t be expected to be proficient in everything.

So, what happens when your team hits a roadblock or encounters a complex issue they’ve never dealt with before? Well, that’s where the limitations of self-organisation come into play. Without the proper knowledge or expertise, the team might struggle to make acceptable decisions, especially for longer-term scenarios.

That’s why it’s crucial to have some support in place to mitigate these limitations. By providing on-call experts from whom the team can “pull” knowledge and expertise as they see fit, they can bridge their knowledge gaps and effectively tackle even the most challenging problems. With the right support, self-organisation doesn’t have to be an all-or-nothing approach – it can be a flexible process that adapts to the team’s needs and capabilities. Assuming the fundamental reflex – knowing WHEN to pull – is in place.

In conclusion, self-organisation has its merits, but it’s important to remember that it’s not a one-size-fits-all solution, and on-call expert support can make all the difference.

Self-Organisation: Liberating, Not Frustrating, the Key to Relaxed Teamwork and Productivity

Self-organisation is a powerful tool that allows teams to work together more effectively. It is an approach to getting things done that focuses on empowered team members taking ownership of their roles and responsibilities, and working together to achieve common goals. This approach can be particularly beneficial for “code-toad” developers, who often want to focus on writing code all day, every day.

One of the key benefits of self-organisation is that it allows developers to focus on what they do best – writing code. By removing the distractions of administrative tasks and meetings, developers can spend more time working on the code itself, which can lead to better quality code and faster development times. Additionally, self-organisation can help to foster a more collaborative and productive working environment, as team members are able to share ideas and work together more effectively.

Another key benefit of self-organisation is that it allows teams to assign different roles and responsibilities to different team members. For example, some team members may be more energised by interacting with users and customers, while others may be more focused on administration matters. By allowing team members to take on roles that suit their strengths and interests, teams can work more effectively and find more joy.

In some cases, teams may also consider enrolling ex-managers looking to reinvent themselves to help with management tasks from inside the team. These individuals can bring valuable experience and skills to the team, and can help to ensure that the team is on top of things. Additionally, such an individual can advise on bridge any gaps between the team and the rest of the organisation, which can be particularly important when working with stakeholders.

Overall, self-organisation is a powerful tool that can help teams to work more effectively and joyfully. By sharing out different roles and responsibilities across the team, teams can work more effectively.

Revolutionise Your Software Development: Ditch the Foxes and Embrace a Collaborative Approach

The issue of putting managers in charge of software development is a thorny one that has long been agonised over in the tech industry. The metaphor of “foxes in charge of the henhouse” is often used to describe this situation, as it implies that managers, who may not have the same level of technical expertise as developers, may not be able to fully understand or appreciate the needs and challenges of the development team. And indeed may “eat” the chickens. This can lead to a number of problems, including poor communication, lack of trust, fear, productivity-lowering stress, and ultimately, a lack of success in development efforts.

It can also cause frustration and resentment among developers, who may feel that their managers do not value or even understand their expertise and contributions.

The solution to this issue is to adopt a more collaborative approach, where managers and developers work together as a team to achieve common goals. This approach can help to build trust and understanding between managers and developers, and can lead to more effective working.

Another alternative is a servant leadership style, with developers leading the development efforts, and managers providing support and guidance as needed. This can help to ensure that the development process is driven by the needs and expertise of the developers, rather than by managers who may not fully understand the technical and interpersonal challenges.

A third alternative, and the preferred one, is to eschew managers entirely, in favour of developers and etc. self-organising and self-managing themselves.

In summary, putting managers in charge of software development can lead to a number of problems, including poor communication, lack of trust, distress, and ultimately, a lack of success in the development process. Alternatives such as a more collaborative approach, where managers and developers work together as a team, or having developers in charge of the development work themselves, can help to mitigate these problems and lead to more effective development efforts. It all boils down to: what development culture can you accept? And how important is it to the organisation to have the development efforts firing on all cylinders?