Ahead of Its Time

August 7, 2025

Article, Deming, Doctrine, Familiar, Meaning

Ahead of Its Time

How Familiar Proved Human Flourishing and Business Success Naturally Align

When we started Familiar in 1996, we weren’t building just another software company. Our stated purpose was deceptively simple:

‘To help people—clients, employees, suppliers, everyone—come together to explore what fulfilment meant for each’

This wasn’t corporate mission-speak. It was a genuine proof of concept for creating conditions where human flourishing could emerge through meaningful work.

For years, I’d been immersed in the work of Deming, Goldratt, Ackoff, and other systems thinkers who had fundamentally challenged traditional management orthodoxy. These weren’t reformers trying to make conventional management more humane—they were revolutionaries who understood that command-and-control structures were fundamentally incompatible with human flourishing in collaborative knowledge work environments.

Having worked as a software development consultant from circa 1982-1996, I’d observed the same dysfunctional patterns across dozens of organisations over fourteen years. I already knew by 1996 that we could do so much better. The theoretical insights provided the foundation, but the extensive real-world experience provided the urgency: an organisation where people could genuinely explore what fulfilment meant through meaningful work, free from the industry-wide dysfunction I’d witnessed repeatedly.

Familiar became my proof of concept for whether antimanagement philosophy could create conditions for human flourishing through meaningful work. The name ‘Familiar’ itself carried three layers of meaning:

Something well-known (trustworthy)
Family-related (close relationships)
A witch’s familiar (the magical companion that guides and empowers).

And there was another layer of irony: whilst the name promised something familiar and comforting, the way we actually delivered stuff was profoundly unfamiliar to anyone steeped in conventional management thinking. The antimanagement philosophy, distributed organising intent, fear elimination, and mission command (auftragstaktik) principles would have felt completely alien, even threatening, to traditional managers. They’d encounter something that called itself “Familiar” but operated in ways that challenged everything they thought they knew about running organisations.

We weren’t just delivering software—we were creating a space where people could explore fulfilment through genuine contribution, which required abandoning familiar management assumptions and beliefs to embrace something genuinely transformative.

The Foundation: Systems Thinking

My approach at Familiar was built on three fundamental insights I’d gleaned from the masters:

Deming’s revelation: Most problems in organisations are system problems, not people problems. When people consistently fall short, look at the system they’re operating within, not their individual capabilities.

Goldratt’s insight: Every system has constraints, and optimising anything other than the constraint is just an illusion of improvement. Find the bottleneck, manage the bottleneck, everything else is secondary.

Ackoff’s wisdom: Organisations are systems, and systems are more than the sum of their parts. You can’t understand a system by taking it apart—you have to understand how the parts interact to produce the whole.

These weren’t abstract theories to me—they were practical frameworks for building something better than the command-and-control tech organisations I’d observed.

Deming in Practice: Eliminating Fear

Deming’s fourteenth point was ‘drive out fear’—essential for any organisation trying to help people explore fulfilment. People can’t discover what meaningful work looks like when they’re afraid of making mistakes, taking initiative, or suggesting better approaches.

In most tech organisations I’d observed during fourteen years of consulting work, fear was endemic. Fear of choosing the wrong technical approach. Fear of missing deadlines. Fear of client complaints. Fear of looking incompetent in front of colleagues. Fear re: job security and peremptory job loss. This fear led to exactly the behaviours Deming predicted: people stopped thinking, stopped experimenting, stopped suggesting better ways to do things.

At Familiar, I deliberately applied concepts to eliminate fear:

Technical decisions: Instead of requiring approval for architectural choices, we established technical principles and let people apply them based on their understanding of the organising intent. If someone made a choice that didn’t work out, we treated it as learning, not failure. I can remember our first major client project where we got hung up on a technical decision and set the schedule back by weeks. I have to hold my hand up for that one – and for modelling learning in action.

Client interactions: Instead of requiring all client communication to flow through me, we exposed everyone to the principles of client relationships and let them engage directly based on our shared organising intent. This reduced the fear of ‘saying the wrong thing’ because everyone understood the underlying purpose.

Deadlines: Instead of punitive deadline management, we focused on understanding constraints and bottlenecks. When projects ran into trouble, we asked ‘what’s preventing progress?’ and definitely not ‘who’s responsible?’

The outcome was remarkable. People proposing improvements to client requirements—not because they had to, but because they found fulfilment in attending to folks’ genuine needs. They began experimenting with better technical approaches because the work itself became engaging rather than just completing assigned tasks. They took ownership of problems because they discovered meaning in being truly helpful.

Goldratt’s Constraint Theory: Finding the Real Bottleneck

Goldratt taught us that every system has exactly one constraint at any given time, and that constraint determines the performance of the entire system. Most organisations waste enormous energy optimising non-constraints whilst ignoring the thing that actually limits their throughput.

In software development, I discovered the constraint was almost never coding speed—it was usually something much more subtle:

Needs understanding: Projects stall not because developers are slow, but because they haven’t yet understood what people really need (as opposed to what they think they want).

Context switching: People are inefficient not because they lack skills, but because they are juggling too many deiiverables simultaneously.

Decision delays: Work backs up not because of technical complexity, but because someone waits for approval to proceed.

Knowledge isolation: Problems persisted not because they were difficult, but because the person who understood the solution wasn’t talking to the person who had the problem.

Once I started looking for these systemic constraints instead of individual performance issues, solutions became obvious. We adopted an approach of front-load understanding of genuine needs (“Stakeholders’ Needs” as per Javelin). We limited work-in-progress. We eliminated approval bottlenecks by distributing decision-making authority. We created approaches for knowledge sharing.

The results were dramatic: our throughput improved not because people worked harder, but because we removed the things that were preventing them from working effectively.

Ackoff’s Interactive Design: Purpose-Driven Organisation

Ackoff’s approach to organisational design started with a fundamental question: ‘What is this system trying to accomplish?’ Not what it’s currently doing, but what it should ideally achieve if it were perfectly designed for its purpose.

For Familiar, the ideal wasn’t just ‘deliver software products on time and budget’—that was an operational goal, not a purpose. The real purpose was exactly what we’d stated from the beginning: ‘help people—clients, employees, everyone—come together to explore what fulfilment means for each’.

This distinction changed everything:

Product scope: Instead of building exactly what clients specified, we looked for underlying needs they hadn’t articulated and opportunities to attend to them.

Technical decisions: Instead of choosing technologies based on familiarity, we chose based on long-term client value.

Team organisation: Instead of organising around skills (front-end developers, back-end developers), we organised around client needs and outcomes.

Success metrics: Instead of measuring delivery metrics, we measured client business impact.

This purpose-driven approach created what Ackoff called ‘interactive planning’—where everyone in the organisation could contribute to designing better ways to achieve the overall purpose.

The Synthesis: Mission Command Principles

What we discovered was that Deming, Goldratt, and Ackoff had independently arrived at principles that military strategists call ‘mission command’ (or auftragstaktik)

Shared understanding (Ackoff’s purpose clarity) meant everyone could make decisions aligned with organising intent.

Constraint focus (Goldratt’s bottleneck concept) meant we addressed the things that actually limited our effectiveness.

Fear elimination (Deming’s system thinking) meant people could take initiative without worrying about punishment.

The result was an organisation that could adapt faster than its environment changed because decision-making was distributed to where the information was best, but coordinated through shared principles and clear organising intent.

The Exemplar Results

By 2000, when I left Familiar, we had successfully demonstrated something remarkable: systems thinking and antimanagement principles could create a fundamentally different kind of software organisation where customer success and human fulfilment naturally aligned.

Our projects consistently came in ahead of schedule because we eliminated systemic delays, not because we worked faster or harder. Client satisfaction was exceptional because we attended to their real needs, not just their perceived problems. Our people were genuinely engaged because they understood how their work contributed to larger purposes, not just immediate tasks.

The Broader Implications

The Familiar experience proved that the insights of Deming, Goldratt, and Ackoff weren’t just applicable to manufacturing—they were fundamental principles of effective organisation that worked even better in collaborative knowledge work.

This became the foundation for what would later become Product Aikido: the recognition that organisations, like physical systems, have natural dynamics that you can work with or against. Fighting against these dynamics with command-and-control structures is exhausting and ineffective. Learning to work with them through systems thinking creates seemingly effortless effectiveness (and see also: wu wei 無為).

The control paradox I discovered at Familiar wasn’t really about learning to let go—it was about recognising that auftragstaktik principles, originally developed for military contexts, were perfectly suited to collaborative knowledge work. When you’re solving complex problems with uncertain requirements, the people closest to the technical details always have better insight into possible solutions than those managing from above.

Auftragstaktik Mirrored in Collaborative Knowledge Work

What military strategists call ‘mission command’ becomes even more powerful in collaborative knowledge work environments. Our programmer Sarah’s integration breakthrough happened because she understood both the client’s real needs and the technical possibilities better than I could from an oversight perspective. She had the context, the relationships, and the technical knowledge needed to craft an elegant solution.

This is auftragstaktik in its purest form: clear organising intent, defined boundaries (budget, timeline, integration requirements), and complete authority to determine the approach. The result was innovation that wouldn’t have emerged through traditional command-and-control.

The Product Aikido Framework

What emerged from the Familiar exemplar eventually crystallised into a comprehensive approach to product development that directly challenges everything conventional management teaches. Product Aikido (Marshall, 2013) recognises that every organisation operates within what Clausewitz called friktion—the resistant medium where organising intent meets entropy, where perfect plans encounter messy reality.

The core insight: Traditional command-and-control management doesn’t reduce friktion—it amplifies it.

Mission-Type Tactics (Auftragstaktik) in Collaborative Knowledge Work Instead of detailed instructions, you provide organising intent: what needs to be accomplished and why, along with clear boundaries and constraints. Teams closest to the work figure out how to achieve the intent. This eliminates the friktion of information travelling up hierarchies and decisions travelling back down—all whilst circumstances have changed. In collaborative knowledge work, this becomes even more powerful because the people doing the work always understand the technical possibilities and constraints better than those managing from a distance.

Distributed Decision-Making Authority flows to where the information and capability reside. When Sarah’s database expertise was needed for the integration project, she could act immediately rather than wait for approval. This creates what the military calls ‘surfaces and gaps’—you flow resources through areas of least resistance rather than pushing against obstacles.

Speed and Focus Product Aikido emphasises rapid, concentrated action over slow, distributed effort. You identify your ‘main effort’—the most critical work at any given moment—and converge resources there whilst accepting prudent risk elsewhere. Speed becomes a weapon because it outpaces entropy’s ability to disrupt your plans.

Generalising Specialists Instead of narrow specialists waiting in queues, you develop people with overlapping capabilities who can adapt as situations change. This reduces handoff friktion and keeps work flowing through natural bottlenecks.

Why Command-and-Control Fails

Traditional management approaches fail because they fight against the natural dynamics of complex systems:

Information Degradation: Every layer of hierarchy distorts the signal. By the time strategic organising intent reaches the people doing the work, it’s been filtered, interpreted, and diluted through multiple perspectives and agendas.

Response Lag: Problems that could be solved in minutes take hours or days whilst they travel up approval chains. Meanwhile, opportunities disappear and issues compound.

Initiative Paralysis: When people know that taking action without permission leads to punishment, they stop thinking strategically. They become order-takers rather than problem-solvers.

Bottleneck Multiplication: Every decision-maker becomes a potential chokepoint. The more control you try to exert, the more places where work can get stuck.

Friktion Amplification: Instead of reducing organisational resistance, command-and-control structures create more of it. They turn natural adaptation into bureaucratic procedures, transform quick conversations into formal communications, and replace contextual judgement with rigid processes.

Product Aikido recognises that in complex, uncertain environments, the highest form of control is not needing to exercise it. You apply concepts and evolve approaches that naturally produce desired outcomes rather than trying to control every action within poorly designed systems.

The antimanagement philosophy isn’t about being ‘nice’ to people—though it often brings that about. It’s about recognising that sustainable organisational effectiveness emerges when people find genuine fulfilment through meaningful work. This requires creating conditions where human flourishing and business success become naturally aligned rather than perpetually in tension.

The Learning Journey

Stage 1 – Resistance: People will initially try to control everything, getting frustrated when teams act ‘incorrectly’. The system must be patient here—show them the costs of over-control through experience, not lectures.

Stage 2 – Reluctant Delegation: People start giving mission-type orders out of necessity (too much happening simultaneously). They experience their first ‘pleasant surprises’ when subordinates handle situations well.

Stage 3 – Trust: People begin to see their role in setting doctrine and strategic direction rather than tactical execution. This is the breakthrough moment.

Stage 4 – Mastery: People understand that their job is building effective coordination systems, not controlling individual actions. They become genuine teamies rather than controllers.

The Pleasant Surprises

As I stopped trying to control every decision, something beautiful emerged: people began finding fulfilment through genuine contribution. Tom, our junior developer, figured out a caching approach that cut database load by 60%—not because he was assigned to optimise performance, but because he found meaning in elegant solutions. Lisa discovered a client workflow optimisation that saved the client two hours of daily manual work—because she genuinely cared about making their lives better. Mark built debugging tools that helped us troubleshoot problems in minutes instead of hours—because he found satisfaction in removing friktion for his teammates.

None of these innovations would have happened under command-and-control. I would have specified the solution, they would have implemented it, and we’d have missed opportunities for real fulfilment through creative problem-solving.

But the biggest surprise was how much more effective I became. Instead of reviewing every technical decision, I could focus on client relationships, business development, and strategic challenges that truly needed my attention. Instead of being a bottleneck, I became a force multiplier.

The Trust Dividend

By 1999, something remarkable had happened. Product development ran more smoothly with less oversight. Client satisfaction increased because problems got resolved faster. Our people were more engaged because they owned their solutions instead of just implementing mine.

Most importantly, the organisation became a place where people could flourish even when I wasn’t there. When I travelled to visit potential clients, work continued at full speed because people had found their own sources of meaning and motivation. When I took my first real vacation in three years, I came back to find two projects ahead of schedule and a third that had solved a technical challenge I’d been wrestling with for months—not through heroic effort, but through the kind of creative collaboration that emerges when people feel genuinely fulfilled by their work.

The team had become genuinely self-organising around our shared purpose: helping people find fulfilment through meaningful contribution.

The Ultimate Paradox – And Its Limitation

When I left Familiar in 2000, I discovered something humbling about the systems we’d built. Despite years of implementing antimanagement principles, eliminating fear, and distributing decision-making authority, the organisation I thought had become self-sustaining proved to be more dependent on my personal influence than I’d ever realised.

After 2000, Familiar became a hollow shell and eventually faded into oblivion. It seems the approaches we’d evolved were always dependent on my personal influence. The principles required my presence.

This reveals something profound about the limitations of organisational change, even when built on sound theoretical foundations. The organising intent that had seemed so embedded in our culture, the distributed decision-making that had felt so natural, the fear elimination that had created such innovation—all of it required ongoing cultivation that only I was providing.

The control paradox I’d discovered wasn’t complete. Yes, you can create conditions where people find meaning through meaningful work and where human flourishing aligns with business success. Yes, antimanagement principles can outperform command-and-control structures dramatically. Yes, organising intent and mission command can compensate for organisational friktion.

But creating truly self-sustaining organisations—ones that can maintain these principles without their architect—remains an unsolved challenge.

Looking back, I realise the Familiar proof of concept demonstrated both the power and the limitations of the antimanagement philosophy. The principles worked brilliantly whilst I was there to embody and reinforce them. They created genuine human flourishing and exceptional business results. But they weren’t truly embedded in a way that could survive my departure.

This reflects what I later came to understand as ‘reversion to the mean’ in organisational development. According to the Marshall Model, synergistic organisations—those operating with i.e. distributed decision-making, shared purpose, and intrinsic motivation—naturally tend to revert to the analytic mindset over time, unless actively maintained. Analytic organisations are characterised by command-and-control structures, individual blame rather than collective focus, and extrinsic motivation systems. They represent the dominant paradigm that our broader economic and social systems reinforce.

Without constant cultivation of synergistic principles, organisations drift back toward what feels familiar (sic) and is supported by conventional business thinking, recruitment practices, and societal expectations. The synergistic state requires ongoing energy and attention to maintain—it’s not a stable equilibrium in our current context.

Perhaps this is the deeper lesson: sustainable organisational transformation isn’t just about implementing better systems and principles. It’s about creating cultures that can continuously regenerate those principles without dependence on any individual—even their founder.

The systems thinking masters—Deming, Goldratt, Ackoff—provided the theoretical foundation. Familiar demonstrated their principles could work in practice. But the challenge of creating lasting change that survives leadership transitions remains one of the most gnarly problems in organisational development.

This doesn’t invalidate what we accomplished—it contextualises it. For four years, we created an organisation where people could explore what fulfilment meant through meaningful work, where business success and human flourishing naturally aligned, where the impact of friktion was minimised through distributed organising intent. That’s valuable, even if it wasn’t permanent.

The Continuing Proof of Concept

What started as a proof of concept in applying antimanagement thinking to software development became validation for a different way of organising knowledge work. The principles we validated at Familiar—shared purpose, constraint focus, fear elimination, distributed decision-making, meaning, agency—turned out to be fundamental to effectiveness in collaborative knowledge work environments.

The real insight wasn’t that these approaches were ‘nice’ or ‘people-friendly’—though they were. The insight was that they fundamentally outperformed traditional management approaches at achieving business outcomes. Antimanagement philosophy wasn’t about being softer—it was about being more effective.

Ahead of Its Time: Pioneering What Others Would Later Theorise

Looking back, Familiar pioneered the practical application of concepts that wouldn’t be widely written about until years after its demise. We were implementing these principles in 1996-2000, whilst the theoretical frameworks that would later validate our approach were still to come.

We did discover one contemporary kindred spirit: around 1999, we found Andy Law’s account of St. Luke’s advertising agency in Creative Company (1999), which described another organisation that had chosen a remarkably similar path—eliminating traditional hierarchy, distributing ownership, and organising around purpose rather than profit. It was validating to learn we weren’t entirely alone in our revolutionary approach, though such examples remained extraordinarily rare.

Agile Development: We applied and evolved Agile principles that I had first defined in Europe circa 1994—seven years before the Agile Manifesto was published in 2001. Familiar was implementing iterative development, customer collaboration, and responding to change whilst most of the software industry was still locked into waterfall methodologies or simply code hacking.

Self-Managing Organisations: Familiar operated as what Frederic Laloux would later call a ‘Teal Organisation’ in Reinventing Organizations (2014)—fourteen years after I left the company. We had already proven that distributed decision-making, elimination of traditional hierarchy, and purpose-driven work could create exceptional results.

Intrinsic Motivation: Dan Pink’s Drive (2009) would articulate the importance of autonomy, mastery, and purpose in knowledge work—concepts we had embedded in Familiar’s culture nine years earlier. Our focus on helping people explore what fulfilment meant was intrinsic motivation in practice.

Purpose-Driven Business: The idea that organisations can exist for more than profit maximisation, that they can serve human flourishing, would become mainstream business thinking decades later. Familiar’s stated purpose—helping people explore what fulfilment meant—was radically ahead of its time.

Constraint Theory in Knowledge Work: Applying Goldratt’s Theory of Constraints to software development and identifying systemic bottlenecks rather than individual performance issues wouldn’t become common practice until much later (hat tip to David Anderson). We were finding and managing the real constraints whilst others were, and still are, optimising on individual productivity.

Mission Command in Civilian Organisations: The application of military organising intent and auftragstaktik principles to business contexts was virtually unknown in the 1990s. We were demonstrating these concepts worked in collaborative knowledge work long before they gained wider recognition.

This timeline matters because it demonstrates that Familiar wasn’t following established best practices—we were pioneering approaches that would later be validated by research and adopted by a few progressive organisations worldwide. The proof of concept was genuinely ahead of its time.

The tragedy isn’t that the principles didn’t work—they worked brilliantly. The tragedy is that we hadn’t yet solved the deeper challenge of creating self-sustaining cultures that could maintain these principles without their original architect. That challenge remains largely unsolved today, even with all the theoretical frameworks that have since emerged.

Sometimes the most practical thing you can do is apply good theory.

“In theory, there is no difference between theory and practice. In practice there is.”

~ Yogi Berra

The lessons from Familiar shaped everything I did afterward, not because they taught me better management techniques, but because they revealed what becomes possible when you organise work in service of human fulfilment rather than mere productivity.

FlowChainSensei’s Hitchhiker’s Guide to Tech Startups

June 12, 2025

Action, Actionable Insights, AI, Article, Business, Chatbots, Familiar, Guides, Memeology, Product development, Quintessence, Startups, Working Notes

Leave a comment

FlowChainSensei’s Hitchhiker’s Guide to Tech Startups

DON’T PANIC!

Yes, this post iattempts to be comprehensive in covering a vast array of considerations for launching a tech startup. It may seem daunting at first glance – much like contemplating the infinite complexity of the universe. But remember: there’s no need to tackle everything at once. This guide is designed to be a reference companion throughout the startup journey, not a checklist to complete before breakfast. Take it one section at a time, focus on what’s most relevant to the current stage, and remember that even the most successful founders started with just one small step.

Audience and Scope: This guide is written primarily for founding teams of 1-3 people in early planning stages, scaling from solo founder scenarios to small team situations. Use the sections relevant to your current stage and team size.

Inception vs. Implementation: The framework and briefing establish strategic direction. Detailed implementation planning happens over subsequent weeks through focused work sessions on specific areas.

Part 1: Strategic Foundation Framework

Legal and Regulatory Framework

When to revisit: Immediately (Week 1), then quarterly for compliance updates, and before any major business model changes

Understanding the legal landscape is crucial for any tech startup. The UK regulatory environment provides both opportunities and obligations that founders must navigate carefully.

Business Structure and Formation

Limited company formation remains the preferred structure for most tech startups
- Provides liability protection and credibility with customers and investors; enables equity distribution and investment
Consider partnership structures and shareholding arrangements early
- Early clarity prevents costly restructuring later; proper documentation protects all parties
Understand director responsibilities and company law obligations
- Directors have legal duties that carry personal liability; understanding these prevents inadvertent breaches

Intellectual Property Protection

Register trademarks early to protect brand identity
- UK trademark registration costs £170-200 but protects valuable brand assets; international expansion requires broader protection
Consider patent protection for genuine innovations
- Patents provide 20-year protection but cost £4,000-8,000; only worthwhile for truly novel technical innovations
Implement robust copyright and design right strategies
- Automatic protection exists but registration strengthens enforcement; crucial for content-heavy businesses

Data Protection and Privacy Compliance

UK GDPR compliance is mandatory, not optional
- Non-compliance fines reach 4% of annual turnover; privacy-by-design reduces compliance costs and builds user trust
Implement proper consent mechanisms and data handling procedures
- Clear consent reduces legal risk; transparent data policies increase user confidence and conversion rates
Consider appointing a Data Protection Officer if processing large volumes of personal data
- Legal requirement for high-risk processing; demonstrates compliance commitment to customers and partners

Consumer Rights and Trading Standards

Comply with Consumer Rights Act 2015 requirements
- Legal obligation that affects refund policies, service quality standards, and customer relationship management
Understand distance selling regulations for online services
- 14-day cooling-off periods apply to most online sales; clear terms reduce customer disputes
Implement fair contract terms and transparent pricing
- Unfair terms are unenforceable; transparent pricing increases conversion and reduces support queries

Trust, Safety, and Verification Systems

When to revisit: Immediately for basic framework (Week 2-3), then monthly during first year as user base grows

Building trust in digital platforms requires systematic approaches to safety, verification, and community management.

User Authentication and Verification

Implement robust identity verification systems
- Multi-factor authentication reduces fraud by 60-80%; builds user confidence whilst reducing platform liability
Consider requiring phone number, email, or social media verification
- Reduces bot accounts and spam; phone verification particularly effective for location-based services
Develop user rating and review systems
- Peer ratings build community trust and enable self-policing; clear feedback mechanisms improve service quality
Create processes for handling disputed identities
- Swift dispute resolution maintains user confidence; documented procedures reduce support time

Content Moderation and Community Guidelines

Establish clear community standards and acceptable use policies
- Clear guidelines reduce moderation burden; transparent enforcement builds user trust in platform fairness
Implement automated content filtering for common violations
- Automation scales more effectively than manual moderation; reduces response time for harmful content
Develop escalation procedures for complex cases
- Human oversight ensures context-sensitive decisions; appeals processes maintain user confidence
Create reporting mechanisms for users to flag inappropriate content
- Community-driven moderation leverages user knowledge; empowers users to maintain platform quality

Security and Fraud Prevention

Implement comprehensive security measures including encryption and secure data storage
- Security breaches cost average £3.2 million; proactive security investment prevents larger costs
Develop fraud detection systems and suspicious activity monitoring
- Early fraud detection prevents losses and protects legitimate users; automated systems scale more effectively
Create incident response procedures for security breaches
- Rapid response minimises damage; transparent communication maintains user trust during incidents

Technology Infrastructure and Data Management

When to revisit: Month 1-2 for architecture decisions, then quarterly for scaling and security reviews

Technical decisions made early significantly impact long-term scalability, costs, and capability.

Platform Architecture and Hosting

Choose scalable hosting solutions that can grow with the business
- Cloud platforms like AWS or Google Cloud provide scalability without large upfront costs; enable rapid geographic expansion
Implement proper database design and data architecture
- Good data architecture prevents expensive migrations later; enables advanced analytics and personalisation features
Plan for load balancing and high availability from the start
- Downtime costs revenue and damages reputation; redundancy planning prevents service disruptions

Search Functionality and User Experience When to revisit: Month 2-3 for MVP implementation, then quarterly for optimisation based on user behaviour data

Effective search and discovery capabilities often determine platform success or failure.

Core Search Features

Implement robust search algorithms with relevant ranking
- Poor search functionality drives users to competitors; good search increases engagement and transaction volume
Enable advanced filtering and categorisation options
- Filters help users find relevant content quickly; reduces search friction and improves conversion rates
Consider implementing recommendation systems based on user behaviour
- Personalised recommendations increase engagement by 15-25%; creates additional revenue opportunities

Search Optimisation and Performance

Monitor search performance and user behaviour analytics
- Data-driven optimisation improves user experience; identifies content gaps and user preferences
Implement search result caching for improved performance
- Faster search results improve user satisfaction; reduced server load decreases hosting costs
Plan for search functionality that scales with inventory growth
- Search performance must maintain quality as content volume increases; early architecture decisions affect long-term capability

Payment Processing and Financial Infrastructure

When to revisit: Immediately (Week 1-2), then annually for rate optimisation and when adding new payment methods

Financial infrastructure decisions impact cash flow, user experience, and regulatory compliance.

Payment Gateway Selection and Integration

Research and compare payment processor fees and features
- Payment processing fees directly impact margins; choosing the right processor saves 0.5-1% on transaction costs
Implement multiple payment options to maximise conversion
- Payment method preferences vary by demographic; offering preferred methods increases completion rates by 10-30%
Ensure PCI DSS compliance for payment card processing
- Legal requirement for card processing; non-compliance risks fines and reputational damage

Billing and Revenue Models When to revisit: Month 3-6 for pricing validation, then every 6 months for optimisation based on user behaviour and market conditions

Subscription models in particular require sophisticated billing infrastructure and pricing strategies.

Subscription Management Systems

Implement robust subscription billing with automated renewals
- Automated billing reduces churn from payment failures; improves cash flow predictability
Plan for pricing tier management and promotional pricing
- Flexible pricing enables market testing and promotional campaigns; supports growth and retention strategies
Develop dunning management for failed payments
- Effective dunning management recovers 15-30% of failed payments; reduces involuntary churn

Transaction Billing Systems

Implement robust payment processing with real-time transaction handling
- Real-time processing reduces cart abandonment and improves user experience; immediate confirmation builds customer confidence
Plan for dynamic fee structures and commission management
- Flexible fee models enable competitive positioning and market adaptation; tiered commission structures incentivise higher-value transactions
Develop automated reconciliation and settlement processes
- Automated reconciliation reduces manual errors and processing time; faster settlement improves cash flow and vendor satisfaction
Implement split payment capabilities for multi-party transactions
- Split payments enable marketplace models and partner revenue sharing; automated distribution reduces operational overhead
Create transparent fee calculation and dispute resolution systems
- Clear fee transparency reduces customer complaints; systematic dispute handling maintains trust and reduces support burden
Plan for international payment processing and currency conversion
- Multi-currency support enables global expansion; competitive exchange rates reduce barriers for international customers
Establish fraud detection and risk management for transactions
- Proactive fraud prevention protects revenue and customer data; risk scoring reduces chargebacks and financial losses

Financial Reporting and Analytics

Implement proper revenue recognition and financial tracking
- Accurate financial reporting enables informed decision-making; required for tax compliance and investor relations
Monitor key metrics like Monthly Recurring Revenue (MRR) and customer lifetime value
- Financial metrics guide strategic decisions; essential for fundraising and growth planning
Plan for international expansion with multi-currency support
- Multi-currency capability enables global growth; reduces barriers for international customers

Customer Support and Community Management

When to revisit: Month 2-3 for basic setup, then monthly during growth phases and quarterly for optimisation

Customer support infrastructure must scale with growth whilst maintaining quality standards.

Support Infrastructure and Processes

Implement comprehensive help documentation and FAQ systems
- Self-service options reduce support volume by 30-50%; improves customer satisfaction through immediate answers
Choose scalable customer support platforms
- Integrated support platforms provide better analytics and automation; improve response times and quality
Develop standard operating procedures for common support scenarios
- Consistent support quality builds customer confidence; reduces training time for new team members

Community Building and Engagement

Create channels for user feedback and feature requests
- User input drives product development; engaged communities provide valuable market insight
Develop user onboarding processes and educational content
- Effective onboarding reduces churn by 20-40%; improves user adoption of key features
Plan for community moderation and management
- Active community management prevents toxicity; fosters positive user interactions and platform loyalty

Market Research and Customer Development Strategy

When to revisit: Ongoing during first 6 months, then quarterly for market intelligence and competitive analysis

Understanding markets and customers drives all other strategic decisions.

Market Validation and Sizing

Conduct primary research to validate market demand
- Direct customer feedback prevents building unwanted products; identifies real user needs and pain points
Analyse competitive landscape and positioning opportunities
- Competitive analysis reveals market gaps and positioning strategies; helps avoid saturated market segments
Define target customer segments and personas
- Clear customer definitions guide product development and marketing; improve conversion rates and customer satisfaction

Customer Development Process

Implement systematic customer interview and feedback collection
- Regular customer contact drives product-market fit; identifies opportunities for improvement and expansion
Monitor customer acquisition costs and lifetime value metrics
- Understanding unit economics drives sustainable growth; guides marketing spend and pricing decisions
Develop systems for tracking and analysing customer behaviour
- Behavioural data reveals user preferences and friction points; enables data-driven product optimisation

Future Strategic Options (Horizon 2/3)

When to revisit: After achieving profitability and establishing proven business model (typically 18-24 months post-launch)

Long-term strategic options require early consideration but delayed implementation.

Market Expansion Opportunities

Evaluate potential for geographic expansion
- Geographic expansion multiplies addressable market; requires understanding of local regulations and preferences
Consider adjacent market opportunities and vertical expansion
- Adjacent markets leverage existing capabilities; provide growth without starting from scratch
Assess partnership and licensing opportunities
- Strategic partnerships accelerate market entry; licensing provides recurring revenue with minimal operational overhead

Technology Evolution and Innovation

Plan for emerging technology adoption
- Early adoption of relevant technologies provides competitive advantage; requires ongoing technology monitoring
Consider API development for third-party integration
- APIs create ecosystem opportunities and additional revenue streams; increase platform value and user retention
Evaluate acquisition opportunities and consolidation strategies
- Strategic acquisitions provide capabilities and market access; consolidation can improve market position

Note: Advanced strategic planning begins only after successful market validation and proven unit economics. Focus on core market success before considering expansion models.

Part 2: Partnership Inception Meeting Framework

Note: This meeting establishes strategic direction and framework. Detailed implementation planning happens through focused work sessions over the following 4-6 weeks.

Purpose and Vision Alignment (15 minutes)

Define core mission and long-term vision for the platform
- Essential foundation that guides all strategic decisions; prevents mission drift and ensures consistent brand messaging
Establish shared values and ethical framework
- Creates decision-making filter for difficult choices; attracts like-minded customers, employees, and partners
Discuss personal motivations and what success means to each partner
- Prevents future conflicts by surfacing different definitions of success early; ensures both partners remain motivated
Align on impact goals: environmental, social, and economic outcomes
- Quantifiable impact metrics enable authentic ESG reporting; attracts impact investors and conscious consumers
Clarify the “why” behind the business beyond financial returns
- Strong purpose enables premium pricing through brand loyalty; provides resilience during market downturns

Legal Structure and Compliance Framework [Priority 1] (15 minutes)

Decide on business entity structure (limited company recommended)
Assign responsibility for legal setup and compliance
Review content policies and moderation strategy
Discuss IP protection and trademark registration needs
Plan for GDPR compliance and data protection measures
Establish terms of service and privacy policy development

Business Model Validation and Revenue Strategy [Priority 1] (15 minutes)

Validate subscription tier structure and pricing strategy
Validate transation fee structure and pricing strategy
Define value propositions for free vs. premium tiers
Review market research and competitive analysis findings
Establish target customer segments and personas
Discuss go-to-market strategy and timeline
Set revenue targets and key milestones

Partnership Structure and Equity Discussion (15 minutes)

Define roles and responsibilities for each party
Discuss equity arrangement and percentage allocation
Establish decision-making authority and governance structure
Review time commitment expectations and availability
Agree on vesting schedules and cliff periods

Technical Architecture and MVP Scope [Priority 1] (15 minutes)

Review current MVP progress and technical decisions
Define Phase 1 feature set and launch requirements
Discuss search functionality implementation approach
Plan scalability requirements and technical debt management
Establish development timeline and resource needs
Review security and data protection requirements

Trust, Safety and Search Strategy [Priority 2] (15 minutes)

User verification and authentication approach
Search algorithm strategy and competitive differentiation
Content moderation and community guidelines
Dispute resolution processes and escalation procedures
Platform safety measures and risk mitigation

Operational Planning and Resource Allocation (15 minutes)

Define immediate hiring needs and skill gaps
Plan customer support infrastructure and responsibilities
Discuss payment processing setup and financial management
Establish quality assurance and testing procedures
Review operational costs and budget requirements

Next Steps and Action Items (20 minutes)

Assign immediate action items and ownership
Schedule follow-up meetings and check-in cadence
Establish communication protocols and project management tools
Set deadlines for key deliverables and milestones
Plan for legal documentation and partnership agreements

Priority Parking Lot (Deferred Items)

Marketing and PR Strategy [Priority 3]

Defer to Month 4-6: Focus on product-market fit before marketing investment

Metrics and Analytics Implementation [Priority 3]

Defer to Month 2-3: Implement after basic functionality is operational

Future Strategic Options [Priority 4]

Defer to Horizon 2/3 planning (Month 12+): Focus on core market success first

Part 3: Implementation Roadmap and Planning Tools

Prioritisation Framework

Impact vs. Effort Scoring Matrix Score each item 1-5 (5 = highest impact/lowest effort)

High Impact, Low Effort (Priority 1 – Quick Wins)

Business entity formation (Impact: 5, Effort: 2)
Basic terms of service (Impact: 4, Effort: 2)
Payment processing setup (Impact: 5, Effort: 3)
Basic analytics implementation (Impact: 4, Effort: 2)

High Impact, High Effort (Priority 2 – Strategic Investments)

Core MVP development (Impact: 5, Effort: 5)
Search functionality (Impact: 5, Effort: 4)
User authentication systems (Impact: 4, Effort: 4)
Customer support infrastructure (Impact: 4, Effort: 4)

Implementation Timeline

Pre-Launch Phase (Months 1-3)

Legal and Structural Foundation

Business entity formation: 2-3 weeks, £200-500
Partnership agreement execution: 3-4 weeks, £1,500-3,000
Basic terms of service and privacy policy: 1-2 weeks, £500-2,000
VAT registration (if applicable): 1-2 weeks, Free-£200

Technical Development

Website hosting infrastructure setup: 1-2 weeks, £100-500/month
Core MVP feature completion: 8-12 weeks, £15,000-50,000
Basic search functionality: 3-4 weeks, £3,000-8,000
Payment processing integration: 2-3 weeks, 2.9% + 20p per transaction
User authentication systems: 2-3 weeks, £1,000-3,000

Soft Launch Phase (Months 4-6)

Limited User Testing

Closed beta with 50-100 invited users: 4-6 weeks, £500-2,000
User feedback collection and platform refinement: 3-4 weeks, £300-1,500
Search algorithm optimisation: 2-3 weeks, £2,000-5,000

Operational Validation

Customer support process testing: 2-3 weeks, £500-1,500
Quality control and authentication processes: 3-4 weeks, £1,500-4,000

Public Launch Phase (Months 7-9)

Market Entry

Public platform launch: 2-3 weeks, £3,000-10,000
Marketing campaign execution: 8-12 weeks, £5,000-25,000
Social media presence establishment: 4-6 weeks ongoing, £1,000-4,000/month

Scale Preparation

Customer support team expansion: 3-4 weeks, £25,000-45,000/year per hire
Technical infrastructure scaling: 2-3 weeks, £500-2,000/month additional
Advanced search features: 6-8 weeks, £8,000-20,000

Ready-to-Use Planning Templates

Vendor Evaluation Scorecard Payment Processor Evaluation (Score 1-10)

Processing fees competitive (< 3%)
UK Direct Debit support
Subscription billing features
Transaction billing features
API quality and documentation
Customer support responsiveness
Compliance and security certifications
Integration complexity (lower score = easier)
Failure handling and retry logic

User Research Interview Script Market Validation Interview (30 minutes)

Opening (5 minutes) “Thank you for your time. We’re researching how people currently solve [problem area]. This isn’t a sales call / conversation – we genuinely want to understand your experiences and challenges.”

Current Behaviour (10 minutes)

How do you currently handle [problem area]?
What tools or services do you use?
What’s frustrating about current options?
How often do you encounter this problem?

Problem Validation (10 minutes)

Have you ever wanted a solution that…?
What would make you trust a new service in this area?
What concerns would you have about trying something new?

Solution Testing (5 minutes) “Imagine a service that [brief solution description]…”

What would make this valuable to you?
How much would you pay monthly for this service?
What features would be most important?

Contingency Planning

Plan B Options for Major Decisions

Payment Processing Contingencies

Primary: Stripe + GoCardless
Plan B: PayPal + Worldpay (if primary rejects application)
Plan C: Square + bank transfer (if all major processors reject)
Nuclear Option: Manual invoicing until revenue justifies enterprise processor

Technical Architecture Alternatives

Primary: Custom development
Plan B: White-label solution
Plan C: WordPress + plugins for rapid prototype
Pivot Option: Simple directory without complex features

Revenue Model Pivots (Notional)

Primary: Subscription-based access
Plan B: Transaction fees (2-5% per transaction)
Plan C: Freemium with premium features
Last Resort: Advertising-supported free platform

Stakeholder Communication Framework

Monthly Investor Update Template

Executive Summary (2-3 sentences on key achievements and challenges)
Key Metrics Dashboard
Major Accomplishments (3-4 bullet points)
Key Challenges (2-3 items with action plans)
Financial Summary (revenue, expenses, cash position)
Team Updates (hires, departures, key achievements)
Ask (specific help needed from investors)
Next Month Focus (3-4 key priorities)

Crisis Communication Templates

Service Outage Communication “We’re currently experiencing technical difficulties that may affect platform access. Our team is working to resolve this immediately.

Status: Investigating
Estimated Resolution: [timeframe]
Affected Services: [specific areas]

Updates every 30 minutes at [status page link]. We apologise for the inconvenience.”

Conclusion

Successfully launching a tech startup requires careful orchestration of numerous business elements beyond product development. Using strategic planning frameworks helps balance immediate execution needs with longer-term growth opportunities. Addressing the foundational areas outlined in this guide proactively will significantly improve the likelihood of sustainable growth and long-term success.

Consider prioritising legal compliance, trust and safety measures, and basic operational procedures before launch, whilst developing longer-term strategies for emerging opportunities and transformational growth. Remember: the goal isn’t to complete everything immediately, but to build a sustainable foundation for systematic growth.

Colophon

This comprehensive startup guide was collaboratively developed through an iterative process of strategic planning, business analysis, and practical implementation guidance. The framework presented here draws upon established business methodologies, UK regulatory requirements, and contemporary startup best practices.

Document Creation Process: The strategic analysis and actionable recommendations were developed through extensive dialogue between human expertise in business strategy, technology, and startup operations, enhanced by Claude (Anthropic’s AI assistant) and FlowChainSensei for research synthesis, structural organisation, and comprehensive coverage of technical and regulatory considerations.

Methodology: This post mentions multiple strategic frameworks including the Three Horizons planning model, Impact vs. Effort prioritisation matrices, and risk-weighted analysis to provide both immediate tactical guidance and long-term strategic vision.

Intended Use: This guide serves as a living document designed to evolve with the startup’s growth and changing market conditions. It is intended for use by founding teams, advisors, and stakeholders as both a planning tool and operational reference throughout the business development lifecycle.Pleas take it and evolve it as you need.

Version: 1.0
Date: 12 June 2025
Format: WordPress blog post
License: This work is licensed under a Creative Commons Attribution 4.0 International License. You are free to share and adapt this material for any purpose, even commercially, as long as you provide appropriate attribution to FlowChainSensei.

“In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. Starting a business has similar effects, but with better potential returns.” – With apologies to Douglas Adams

The Art of Being Methodical

May 15, 2025

Actionable Insights, Article, Familiar, Product development, Quintessence

Leave a comment

The Art of Being Methodical

The Missing Link in Modern Work

In a world that often celebrates spontaneity and quick thinking, there’s a profound power in being methodical. This isn’t about rigid methodologies or specific techniques—it’s about embracing a perspective that values deliberate, systematic approaches to life’s challenges and opportunities.

What Does It Mean to Be Methodical?

Being methodical means approaching tasks with a prepared idea of how to proceed from start to finish, with consistency, and with attention to detail. It’s the difference between rushing through an endeavour and thoughtfully executing each step with intention. A methodical person doesn’t just know what to do—they understand why they’re doing it and how each action connects to their larger goals.

The Curious Absence of Methodical Approaches

In collaborative knowledge work, there’s a peculiar paradox: whilst we constantly seek ways to improve our productivity and effectiveness, almost no one has established a concrete routine to achieve these goals. Over decades of professional experience, it’s been remarkably uncommon for me to encounter individuals or teams who have developed, evolved, and maintained a disciplined, methodical approach to their work.

This absence leads to a persistent frustration in collaborative environments: watching colleagues overlook the power of—and need for—methodicality. Teams typically waste inordinate time and effort inventing ways to align their purpose, repeatedly struggling with challenges that a well-established routine could readily address.

Overcoming the “Boring” Perception

Let’s address the elephant in the room: to many in the tech world, the mere mention of routine elicits stifled yawns or outright resistance. There’s a prevailing notion that methodical approaches stifle creativity and innovation—that they’re the antithesis of the dynamic, fast-paced nature of technology work.

This perception, whilst understandable, misses the deeper value of structured approaches. Being methodical isn’t about rigidity—it’s about creating thoughtful frameworks that guide actions whilst remaining adaptable to new information and changing circumstances.

Learning from Existing Frameworks

Several established frameworks have emerged to bring structure to collaborative work. One such approach is Javelin, a deliberate method we developed during my time at Familiar for approaching collaborative endeavours with intention.

At its core, the Javelin approach involves:

Choosing a name for easy reference to “this thing which we have come together to create/build/grow”
Discussing various perspectives regarding common purpose, leading to a Statement of Purpose
Listing key stakeholders and their respective needs (what they say they need, not what we’d like them to need)
Creating shared understanding about how ambiguities will be resolved during development

The approach aims to address inherent risks in collaborative endeavours, including the the enormous and oh-so-common risk of spending precious time and effort building the wrong things. It seeks to establish the minimum amount of structure needed to serve a joint endeavour effectively.

Along with other systems like Scrum and Kanban that have gained prominence in software development, these frameworks share underlying principles of routine, structure, and disciplined approach that can be valuable across all domains. Personal Kanban, for instance, demonstrates how methodical approaches can be adapted for individual use, proving that structured routines aren’t just for large-scale operations.

Note: For those interested in exploring Javelin in greater depth, full details can be found in Appendix A of my book “Quintessence“.

The Core Elements of Methodical Thinking

At its heart, methodical thinking encompasses several key principles:

Intentionality – Making conscious choices rather than acting on impulse
Systematic approach – Breaking complex messes into manageable artefacts
Consistency – Applying the same level of care to each component
Reflection a.k.a. retrospection – Regularly evaluating progress and adjusting as needed

The True Purpose: Enhanced Alignment

What frameworks like Javelin fundamentally offer isn’t a set of repeatable practices—it’s a pathway to deeper group alignment. The primary value of being methodical lies in its ability to get teams genuinely aligned on what they’re trying to achieve together. When a group follows a shared methodical approach, they’re not just going through motions; they’re participating in a common language and framework for understanding their collective purpose.

The Benefits of Embracing Methodical Approaches

1. Cognitive Offloading

When we establish methodical routines, we free our minds from the burden of constant decision-making about the way the work might work. This mental energy can then be redirected towards solving actual problems rather than figuring out how to approach them. a.k.a. “constantly reinventing the wheel”.

2. Consistent Quality

A well-defined methodical approach creates a baseline for quality. When we know exactly how we’re going to tackle each type of task, we’re less likely to miss crucial steps or take shortcuts under pressure.

3. Improved Learning

Methodical approaches provide a framework for continuous learning. When we follow a consistent approach, it becomes easier to identify what works and what doesn’t, allowing for meaningful iterations and refinements.

4. Enhanced Group Understanding

Perhaps most crucially, methodical routines create a shared context within which teams can better understand their collective aims. This alignment leads to more effective collaboration and fewer misunderstandings about goals and priorities.

Implementing Methodical Approaches: A Practical Path

The key to successfully becoming more methodical lies in starting small. Rather than attempting to overhaul entire working practices overnight, begin with a single, well-defined artefact. This might be as simple as establishing a daily list of priorities for joint review, or a structured artefact for product kickoffs.

The Role of Flexibility

Understand that being methodical doesn’t mean rigidity. Effective methodical approaches are living frameworks that evolve based on experience and changing circumstances. The goal is to create a foundation that supports rather than constrains our work.

Moving Forward

The challenge for modern workers and teams is to recognise the value of methodical thinking without falling into the trap of bureaucracy. This requires a delicate balance between structure and flexibility, between established practices and innovation.

As we move forward in an increasingly complex work environment, perhaps it’s time to reconsider our relationship with being methodical. Rather than viewing it as a constraint, might we come to see it as a tool for liberation—freeing our minds to focus on the truly challenging aspects of our work whilst ensuring consistency and quality in our daily tasks? More importantly, it’s a powerful mechanism for achieving what every successful team needs—a clear, shared understanding of what they’re trying to accomplish together.

The next time you face a challenge, consider embracing the methodical path. You might find that taking the time and effort to consider method actually helps you move forward more effectively in the long run.

A Guide to Meaningful Living

December 27, 2024

Actionable Insights, Antimatter principle, Article, Digital evolution, Familiar, Meaning, Motivation, Organisational Therapy, Psychology, Psychotherapy

Leave a comment

A Guide to Meaningful Living

The Man Behind the Method

Viktor Frankl’s journey through the darkest depths of human experience in Nazi concentration camps led to profound insights about life’s meaning. As a psychiatrist and Holocaust survivor, he developed Logotherapy—a therapeutic approach centred on the pursuit of meaning as the primary driver of human behaviour and wellbeing.

The Search for Meaning: Core Principles

Frankl’s approach suggests that life’s meaning isn’t something we create, but rather something we discover. Like a detective following clues, we must remain alert to the possibilities for meaning that exist in every moment, even in suffering.

Three Pathways to Purpose

1. Creative Endeavours

By creating something valuable or performing meaningful work, we contribute to the world. Whether you’re writing poetry, building furniture, or teaching children, the act of creation connects us to something larger than ourselves.

2. Experiential Encounters

We find meaning through experiences and relationships—particularly through love. Frankl believed that by loving another person, we enable them to actualise their potential whilst simultaneously discovering purpose in our own lives.

3. Attitudinal Choices

Perhaps most profoundly, Frankl argued that we can find meaning in how we choose to face unavoidable suffering. When we cannot change our circumstances, we can still choose our attitude towards them.

The Power of Meaning

Rather than asking “What do I want from life?”, Frankl encourages us to consider “What does life want from me?” This subtle shift transforms us from passive consumers of experience into active respondents to life’s challenges.

Practical Applications for Modern Life

Daily Meaning Reflection

Take time each evening to consider three questions:

What did I create today that mattered?
Whom did I connect with meaningfully?
How did I respond to challenges with dignity?

The Meaning Diary

Keep a journal documenting moments of meaning, however small. A child’s smile, a colleague’s gratitude, or the satisfaction of a task well done—these are the building blocks of a purposeful life.

Beyond Happiness

Frankl’s radical proposition is that we might choose to not aim directly for happiness. Instead, we can choose to see happiness as a by-product of living meaningfully. When we commit ourselves to worthy causes and invest in meaningful relationships, contentment tends to follow naturally.

Modern Echoes in Positive Psychology

Frankl’s insights find powerful resonance in contemporary positive psychology, particularly in the work of Martin Seligman. In his seminal book “Flourish”, Seligman expands upon Frankl’s foundation, proposing that true wellbeing encompasses meaning alongside other vital elements like positive emotions, engagement, relationships, and accomplishment (PERMA). This modern framework validates Frankl’s emphasis on meaning whilst placing it within a broader context of human flourishing.

Motivation and Meaning: Pink’s Contribution

Dan Pink’s influential work “Drive” provides a crucial bridge between individual meaning-seeking and organisational effectiveness. Like Frankl, Pink challenges traditional assumptions about human motivation, arguing that once basic needs are met, people are driven not by external rewards but by intrinsic factors that align closely with Frankl’s vision of meaningful living.

Pink’s three elements of true motivation—autonomy, mastery, and purpose—echo and extend Frankl’s insights:

Autonomy and Attitudinal Freedom

Pink’s emphasis on autonomy—the desire to direct our own lives—parallels Frankl’s insistence on our freedom to choose our attitude in any circumstance. In both frameworks, human dignity and meaning emerge from this fundamental freedom of choice.

Mastery and Creative Value

The drive toward mastery that Pink identifies corresponds with Frankl’s pathway of creating value through work. Both thinkers recognise that humans find deep satisfaction in developing skills and contributing meaningfully to the world.

Purpose as the Ultimate Driver

Most significantly, Pink’s emphasis on purpose as the highest form of motivation directly reinforces Frankl’s central thesis about meaning. Both argue that connecting to something larger than ourselves—what Pink calls “purpose” and Frankl calls “meaning”—represents the apex of human motivation and fulfillment.

Logotherapy in Organisational Contexts

The Collective Search for Meaning

Whilst Frankl primarily developed logotherapy for individual therapy, its principles have profound implications for organisational life too. Just as individuals seek meaning, organisations and their members collectively pursue purpose beyond profit—what management consultants now term ‘organisational purpose’.

Meaningful Work Design

Logotherapy’s principles can inform how organisations structure work and roles. When leaders understand that employees seek meaning through their work, they can design positions that:

Connect individual contributions to larger organisational purpose
Create opportunities for creative expression and problem-solving
Enable meaningful relationships and mentorships
Allow for personal growth through challenging situations

Organisational Culture and Values

Logotherapeutic approaches to organisational development emphasise:

Cultivating a shared sense of purpose that transcends individual roles
Creating spaces for collective meaning-making through dialogue and reflection
Developing leadership practices that acknowledge and support meaning-seeking behaviours
Building resilience through shared understanding of challenges as opportunities for growth

Crisis Management and Organisational Change

Frankl’s insights about finding meaning in suffering are particularly relevant to organisational change and crisis management. His principles suggest that organisations can maintain cohesion and motivation during difficult transitions by:

Framing challenges within a larger meaningful context
Encouraging collective ownership of responses to adversity
Recognising and celebrating examples of values-driven behaviour during hardship
Supporting teams in finding meaning through their collective response to challenges

Conclusion: The Ongoing Journey

Finding purpose “the Frankl way” isn’t a destination but a continuous journey of discovery. It requires openness to life’s possibilities and courage to engage with its challenges. As Frankl himself demonstrated, meaning can be found in any circumstance—we need only the wisdom to recognise it and the courage to embrace it.

By adopting Frankl’s approach, we might find that the question isn’t whether life has meaning, but rather how we might better attune ourselves to the meaning that already exists in our daily experiences.

How “Constant State of Ship” Drives Transformative Practices

March 11, 2024

Antimatter principle, Article, Automation, Business, Capability development, Culture change, Engineering, Familiar, Fellowship, Flow, Improvement, Learning, Memeology, Organisational effectiveness, Organisational Therapy, Product development, Quintessence, Self-organisation

Leave a comment

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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

The Catch-22 of Productivity

September 26, 2023

Article, Business, Culture change, Deming, Drucker, Familiar, Giants, Organisational effectiveness, Organisational Therapy, Quintessence

Leave a comment

The Catch-22 of Productivity

What Fuels Top-Performing Software Companies?

The secret sauce of top-performing software companies often lies in their willingness to explore and implement ideas that fall outside the mainstream. Unlike many companies that stick to orthodoxy and status quo practices, these high-performers embrace the works of thinkers like Deming, Ackoff, Buckminster Fuller, Goldratt, Drucker, Seddon, and Trybus. They find value in methods and theories that many businesses either don’t know about or choose to ignore. This approach fosters a culture of continuous improvement and innovative problem-solving, setting them apart from their competitors.

Why Aren’t These Ideas More Widely Adopted?

There’s a paradox here: The ideas from these thought leaders are available, and their effectiveness has been demonstrated, yet few companies make the leap to implement them. This is usually not due to a lack of resources or information but stems from organisational inertia compounded by ignorance. Companies often feel safer sticking to conventional methods, even when evidence suggests that non-mainstream ideas could lead to significant improvements. This risk-averse mentality can create a barrier to adopting transformative approaches.

How Do Beliefs Impact Productivity?

The collective mindset or shared beliefs within an organisation can serve as either a catalyst or an obstacle to productivity. In high-performing software companies, you’ll often find a culture that not only welcomes but also thrives on unconventional wisdom. This creates a fertile ground for out-of-the-box methods to take root and flourish, driving the company forward in ways that more conventional organisations can’t easily replicate. If you’re curious, my recent book “Quintessence” catalogues and maps over seventy of the unorthodox memes of these top-performing companies.

Can We Simply Adopt Another Company’s Methods?

Transplanting methods from one company to another might seem like a straightforward way to boost productivity. However, those methods were developed within a unique ecosystem, shaped by specific challenges, goals, and culture. Attempting to graft them onto an organisation with differing assumptions and beliefs leads to misalignment, cognitive dissonance, resistance from team members, and even failure of the adopted methods to deliver the expected benefits. “Agile” is a classic example in this regard.

Has Benchmarking Any Value Here?

Many companies rely on industry-standard metrics to gauge their performance, but this approach has its limitations, particularly when comparing against top-performers who use unconventional approaches and thus metrics. These high-performers often evaluate success based on measures specifically tailored to their methods and organisational beliefs. This makes traditional benchmarking ineffective and even misleading when trying to measure up to these high-performing companies.

How Do You Close the Productivity Gap?

If you’re looking to close the productivity gap, tweaking existing methods won’t be sufficient. What’s required is a fundamental shift in organisational beliefs and assumptions that pave the way for consideration and implementation of radical, unorthodox ideas. Companies that are willing to examine their own culture critically, and to challenge the industry status quo, stand a much better chance of making significant strides in productivity.

What’s the Cost of Inaction?

Ignoring the widening gap between your company and high-performers comes at a steep price. As these leading companies continue to innovate and improve, companies that stick to conventional methods risk stagnation. In a worst-case scenario, they become increasingly irrelevant in their industry, losing out on both market share and talent to more forward-thinking competitors.

Quickie: More Than Just Technical Practices

April 24, 2022

Alien tech, Culture change, Familiar, Quickies

Leave a comment

Running a high-performance, highly effective software delivery business – or any collaborative knowledge-work business for that matter – is predicated on way more than just its technical practices.

How Do You Set Up A Salary Model That Has Everyone’s Approval?

April 24, 2022

Alien tech, Article, Culture change, Dialogue, Fairness, Familiar, Fellowship, Financial, Psychology, Quintessence, Remuneration

Leave a comment

How Do You Set Up A Salary Model That Has Everyone’s Approval?

Remuneration policy reflects an organisation’s culture. It’s a calling card for your company and a key element of employer branding. Given current recruiting challenges, it also determines who wants to join or stay with your company.

What Is A Salary Model?

A salary model, or remuneration policy, is a system of guidance that an organisation uses to determine each employee’s remuneration (a.k.a. package). A typical salary model takes into account things like merit, length of employment, and pay compared to similar positions.

Everyone’s Approval?

You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.

~ John Lydgate

Salary models are almost always contentious, and the source of frequent fractious arguments and ill-will. Few people favour being treated just like everybody else, seeing themselves as individuals. Yes, fairness has a role to play – humans and capuchins both being acutely attuned to the notion of fairness. But who adjudicates what is fair when it comes to salaries and other remunerations?

At Familiar, and now at TheQuintessentialGroup, we seek to treat people as adults, and encourage adult-to-adult interactions. Accordingly, we believe that only the individual in question is at all placed to decide what is fair, and thus to determine their personal individual salary or other remuneration. Our experiences at Familiar showed this idea as entirely workable, and helped us learn the amazing up-side to such a salary model.

This perspective also aligns with the Antimatter Principle: “Attend to folks’ needs”. Who else but the individual can truly decide what their needs are, salary-wise? Needless to say, the Antimatter Principle stands proud at the heart of TheQuintessentialGroup’s approach to community-building, and to business.

So, for clarity, this salary model states:

Each fellow decides his or her own salary (or other remuneration, depending on engagement model). Each fellow is free to change salary or other remuneration levels as and when – and as often as – they see fit.

Note: This particulalr salary model is the salary model of choice for TheQuintessentialGroup.

Wrinkles

One wrinkle that did emerge at Familiar, given the totally alien nature of this salary model, was the difficulty some folks had in deciding on the specifics of their package. We discovered that support and dialogue amongst fellows (along with full transparency for all) helped greatly with resolving this difficulty.

Another, more general wrinkle is the collective assumptions and beliefs of the decision-makers and those that sign off – or don’t – on the salary model. The headline of this post is about winning everyone’s approval. Managers and executives that have a sublimated Theory-X view of the world probably won’t approve of this salary model. Which I find sad, for the people and for the performance of the workforce (and thus, of the organisation).

– Bob

Afterword

“Has everyone’s approval” seems to me a pretty low bar. I’d prefer to see a salary model that “everyone loves and raves about”. How about you?

What’s An Expert To Do?

April 24, 2022

Article, Business, Experts, Familiar, Quintessence

Leave a comment

What’s An Expert To Do?

If you’re an expert, there’s little satisfaction or joy in trying to change people such that they begin to adopt the things you know they need to do. They won’t understand nor embrace new ways of doing things, nor new ideas. Not because the expert tells them to, anyways.

You may be lucky and stumble across someone or some group that, by happenstance, has become curious about doing things differently. But in most cases, your expertise is for the birds.

So, taking a job or position in organisations as an in-house expert is most often a stupid punt. Almost exclusively, in my experience.

And in the realm of software delivery, there’s pretty much zero likelihood of decision-makers understanding why doing things differently is the only gateway to better performance.

Obduracy

In my post “Obduracy” of several years ago, I wrote:

“The things organisations have to do to make software delivery successful are well known. And equally well known is the fact that organisations will absolutely not do these things.”

And this ain’t gonna change just because an expert or two gets involved.

What To Do Instead

The above was observably true back in 1996, when we decided to apply our expertise for our own benefit, baled from any more consulting, and started Familiar.

And it remains true today, some 26 years later. Which is why we’re embarked on a similar venture, second time around.

Instead of endless frustration in trying to help others move the needle in software delivery, we are, again, picking up the gauntlet and getting jiggy with moving the needle ourselves, through The Quintessential Group.

If you’re an expert in software delivery, I invite you to apply your expertise in starting your own delivery business (we’d be delighted to help). Or, you might like to join us at The Quintessential Group and taste the quintessential experience.

– Bob

Second Time Around

April 22, 2022

Alien tech, Business, Buzz, Familiar, General, History, Memeology, News, Organisational effectiveness, Quintessence, Software development

2 Comments

Second Time Around

Y’all may like to know that Ian Carroll (of Solutioneers fame) and I are launching a new venture named TheQuintessentialGroup, offering a range of services in the software delivery space. First out of the gate will be “Quintessential Teams“. You can find out more at our shiny new website: TheQuintessentialGroup.com.

TQG-Banner2

Note: We’re looking to revolutionise the world of software delivery, along quintessential lines, and we’d love for you to consider joining us.

First Time Around

Back in 1996 we* found ourselves with the opportunity to demonstrate what we had been telling clients for years – that our** approach to software delivery was way more productive than:

a) the industry norm

b) their current approaches

c) what they could ever believe possible

*myself and some colleagues at the Java Centre within Sun Microsystems UK, along with some mutual friends.

**the company we named “Familiar”.

Second Time Around

Now, we*** find ourselves in the same situation once again. Our**** approach to software delivery is again way more productive than:

a) the industry norm

b) our clients’ current approaches

c) what our clients and prospects could ever believe possible

***Ian Carroll and myself

****the company we’re naming TheQuintessentialGroup

Nothing Like Agile

The first time around, commencing circa 1996, our approach could be described as an Agile approach (Scrum-like, albeit risk-based).

The second time around our – distinctly different – approach can be described as the Quintessential approach (nothing like Agile, Scrum, etc. – albeit still very risk-oriented).

Alien Tech For Human Beings

And this second time around, we again lead the industry in breaking the mould and demonstrating the validity and sheer awesome power of the Quintessential approach.

The Quintessential approach is no secret. It’s all laid out, in detail, in my book(s). And yet we defy anyone to replicate this game-changing alien tech. At least, until they have thrown off the shackles of outmoded and crippling beliefs about work and how work should work.

And that ain’t likely to happen any time soon. Although TheQuintessentialGroup.com can help with effecting such changes, too – see my book Memeology, for starters.

If you’re at all interested in the quality, cost, timescales, and predictability of software delivery, you might like to take a look at our newly launched website: TheQuintessentialGroup.com. We have big ambitions and big plans – and we’re hiring too!

Yes there’s more than a little déjà vu here at Sensei Towers at the moment. Familiar was an outstanding success, vindication, trailblazer and golden goose back in the late 90’s. We have every expectation that TheQuintessentialGroup will surpass even that outstanding benchmark.

Putting a dent in the Universe.

– Bob

28 Years Ago

March 3, 2022

Article, Familiar, Organisational effectiveness, Product development, Quintessence, Software development

Leave a comment

28 Years Ago

Twenty eight years ago (i.e. 1994) almost no one was interested in doing software development differently. Waterfall and the V Model ruled the roost. And structured methods (SSADM, Dataflow diagrams, etc.) were de rigeur. I was fortunate in finding the ear of the Finance Director of Barclays Bank, who had two urgent projects he needed to see completed in double-quick time, and with no wiggle room for missing the delivery dates. He felt he could no afford to go down the traditional (slow) route.

Of course, in 1994 the term “agile” had not then been applied to software development (at least, in the way the Snowbird folks appropriated the term circa 2001),

After successfully delivering Barclay’s projects, I moved on to Sun Microsystems’ UK Java Center and brought my “new” approach (then being called “Jerid”) with me.

Having transferred my approach and ideas into several of Sun’s corporate client base (mainly banks and other financial institutions in the City), I moved on to found “Familiar” circa 1996. (Being then the first 100% Agile software house in Europe). Jerid served us well, and continues to do so – now named Javelin – up to the present day.

28 Years On

Twenty eight years on and history repeats itself. Almost no one is interested in doing software development differently. This time around, I find myself the guardian and steward of the Quintessential approach. Another step forward at least as great as Jerid was in 1994.

Sigh. And deja vue.

– Bob

Fun Times at Familiar

November 23, 2021

Article, Community, Culture change, Familiar, Fellowship, Learning, Organisational effectiveness, Product development, Productivity, Quality, Software development, Teambuilding

Leave a comment

Fun Times at Familiar

I’m minded to write something positive for a change (!) so I thought I might share how much fun a quintessential development organisation can be to work with. (I say work with, because we had almost no power structures, no managers, no bosses, and everyone was a colleague, a fellow.)

Familiar was a software house and consultancy, based near Reading UK (some forty miles west of London), which I started and led circa 1996-2000.

The years at Familiar was, for many of us, enormous fun. We were doing great things for our clients, bonding as a group, and learning loads about how to become a Quintessential organisation. The social side was just as much fun as the business side. Indistinguishable, really. We placed a lot of emphasis on the social aspects of the organisation:

Company-funded weekends away in plush country hotels – for the folks in the company along with their significant others.
Regular dIning out as a group, on the company’s expenses.
Collaborative sessions (sprint planning and the like) in each others’ homes.
Other group social events (e.g. exhibitions).
An office configured for socialising – and learning – as much as for work (lounge, sofas, library, books, kitchen, etc.).

This was all made possible by the success we had commercially – a virtuous circle where fun led to great work for clients led to high margins led to funds for more fun…

It was the kind of win-win-win (clients, us, suppliers) that quintessential organisations regard as normal.

If you have any questions, I’d be happy to answer them.

– Bob

ICYMI: The Starting of Familiar

September 28, 2021

Familiar, ICYMI

Leave a comment

Multiple Discovery

August 15, 2021

Agile, Article, Familiar, Organisational effectiveness

1 Comment

Multiple Discovery

It often seems that folks automatically assume that all useful software development innovations come out of the United States. And innovations (and innovators) from places other than the US have little merit. Yet specific innovations have a tendency to pop up, more or less simultaneously, in various places:

“The concept of multiple discovery (also known as simultaneous invention) is the hypothesis that most scientific discoveries and inventions are made independently and more or less simultaneously by multiple scientists and inventors. The concept of multiple discovery opposes a traditional view—the “heroic theory” of invention and discovery.”

~ Wikipedia

I rarely bother to mention Familiar’s independently inventing something very much like Scrum (we called it Jerid, now Javelin) back in the 1994-1996 time frame. Not inspired by Nonaka and Takeuchi’s New New Product Development Game, nevertheless Jerid featured:

Two-week interations
Time-boxing
Sprint planning and sprint retrospectives
Self-organising teams
Focus (through e.g. quantification of objectives)
A risk-based approach
(Later on) Flow

I have no wish to tarnish or undermine Jeff and Ken’s achievements with Scrum. Nor the somewhat later accomplishments of the Snowbird folks. Just putting down a marker for us Brits. And other nations too.

Aside: The Lean manufacturing community has largely forgotten about Frank George Woolard, a Brit whose work preceded and some say inspired the Japanese, notably Eizi Toyoda.

– Bob

The Naming of Familiar

June 23, 2021

Familiar, Innovation

Leave a comment

The Naming of Familiar

Familiar Limited was a Reading-based software house/consultancy that I started with a colleague in early 1997.

One question I regularly get asked is “How did the name ‘Familiar’ come about?”

I had thought I’d already answered this question, but upon looking for that explanation can’t find it. So here it is (for the record):

I’ve long favoured ambiguous or multi-meaning words (homonyms). We chose the name “Familiar” on that basis. Here’s the three meanings we sought to present:

Familiar as in: well-known, easily recognised.

Our approach to software development was way different to what clients had come to expect from software house suppliers. We were decidedly unfamiliar in our approach, but took pains to appear familiar and comforting from the point of view of our clients interacting and doing business with us.

Familiar as in: Of the Family

We used the family as the metaphor for structuring the company. “Family” were close-knit, and each had equity and a say in the running of the company. “Friends” were (only) a little less invested.

Familiar as in: Witch’s Familiar

What we did for our clients was, for them, largely indistinguishable from magic. Or at least, that was our aim. Our “magic”, our technology, was how we did things. In other words, channelling the Arthur C. Clarke quote:

“Any sufficiently advanced technology is indistinguishable from magic.”

~ Arthur C. Clarke

Note also the coquettish reverse “F” in the name, intended to evoke a quizzical, playful spirit (looking a bit like a question mark).

You might like to read my other posts about Familiar too, if this post has piqued your interest.

– Bob

Artefact Driven Delivery

February 24, 2021

Antimatter principle, Engineering, Familiar, Organisational effectiveness, Product development, Software development

3 Comments

Artefact Driven Delivery

My preference when approaching solution delivery (I use that term in preference to software delivery, because #NoSoftware) has for the past 25 years centred on artefacts as opposed to tasks. I’m not going to retread here the arguments in favour of the artefact as the unit of progress. This post covers the use of artefacts in incremental development environments, and lists the core artefacts we use in our approach to solution delivery.

Incremental Delivery

Delaying work on implementing and delivering a solution until we have fully defined the requirements, designs, etc., for that solution magnifies the Cost of Delay, defers feedback significantly, and inflates other risks too. Yet we don’t want to skip having clear requirements and designs, either.

The approach we adopted starting circa 1994 is to establish a set of standard artefacts, at the outset of work on each new solution. From Day One, these artefacts will be empty scaffolds, based on standard templates, each artefact being elaborated just-in-time, immediately in advance of their contents being needed for implementation and delivery purposes.

In this way, we avoid B*UF (e.g. Big Design Up Front, Big Requirements Up Front, etc.) and the delays and risks associated with a Big Bang approach.

Standard Artefacts

The following is a list of all the standard artefacts we create on Day One of the inception of each new solution on which we embark. Note that each artefact is based on a standard template, with, from the outset, little or no solution-specific content (i.e. empty).

Control Document
Articles of Understanding
Glossary of Terms
Statement of Purpose
Case for Action
Vision
Folks That Matter™ and their Needs
Risk Parade
Top Risks
Functional Requirements
Non-functional Requirements aka QQOs
Critical Success Factors
Feature Schedule
Quality Plan
Test Plan
Change Control
Cycle Plans
Cycle Reviews

Artefacts and Deliverables

We share some or all of the above artefacts with our clients (the folks on whose behalf we are developing solutions) continually, and at their request. These artefacts are available for sharing throughout the duration of the development. And serve as a running history of the endeavour, too. The deliverables of any solution (code, data, policies, documentation, configs, databases, etc.) augment these standard, evolving artefacts. Typically, a set of deliverables will fall out of the work according to some cadence or rhythm (for example, weekly or every two weeks).

Javelin

For a fuller (if rather dated) explanation of each particular artefact (some now carry slightly different names), see the Javelin white paper.

In a following post I’ll be showing how you might insinuate the Antimatter Principle into your existing approach to developing solutions, using the Artefact Driven Delivery approach.

– Bob

Some Familiar Experiences

August 24, 2020

Community, Familiar, Organisational effectiveness, Software development

1 Comment

Some Familiar Experiences

[Note: I regard this post as unfinished – I’m publishing it now in the hope that some kind readers will help me in bringing it to something nearer completion. Also, you might like to check in now and again for possible updates.]

A Conversation

Here’s a transcript of a conversation that didn’t take place, but could have, in the vicinity of Reading, England, circa 1999.

Sam: Thanks for allowing me to get some insights into Familiar and what makes it different from other software houses.

Bob: Thanks for showing an interest. We feel the UK software industry would serve society better if more folks had some exposure to what we’re doing here, and maybe take on board some of the principles that have guided us so far.

Sam: I’d like to start with the one thing that intrigues me most. The way you set salaries here. I’ve heard you allow people to set their own salaries? Is that true? Can you explain why you do that?

Bob: Surely. When we set up Familiar, some three years ago now, we all decided we wanted a company that felt more like a family, both for the folks working in the company, and for all the other folks involved – our suppliers and customers, for example. That’s reflected in one aspect of the name “Familiar”, of course (I won’t go into the other aspects of the name, just now). At the time, I was reading the book “Families and How To Survive Them” by John Cleese and Robin Skynner. That book led me to Eric Berne’s work on Transactional Analysis. Berne’s work got me thinking about building a community where Adult-Adult interactions and relationships were the norm.

Sam: So how does having folks set their own salaries play into that idea?

Bob: Well, our approach to salaries – and the same with equipment, working times, locations and the nature of the relationship between the community and the individual – is to have people choose for themselves. If we want folks to behave more often like adults, it makes sense to us to treat them like adults. Folks capable of making their own decisions about the things that matter to them, and to the community as a whole. Moreover, who is at all equipped to decide what salary, etc., suits their needs – other than each individual?

Sam: That sounds really out there. How do people find it?

Bob: It’s true it’s not without its challenges. Firstly, people just starting with us often haven’t thought very much about their commercial value. In other words, at what level they might set their salaries. What might be “fair”. And if someone asks for any given salary, cap-in-hand like, I push back. As far as I’m concerned – and speaking on behalf of the community, too – it’s not a negotiation. Someone announces their intent to bill at a certain rate, or get paid a certain monthly stipend, and that’s what happens. I see it as a positive, all round – for them, others, and the community as a whole – for someone to think about what they charge. You might say “what they’re worth” – but that’s too crass a phrase for me. And then there are other challenges, too.

Sam: Such as?

Bob: Folks billing or getting paid too little. Strange as it seems, our overall staff costs are rather lower than we expected for a software house such as ours. Nobody’s complaining, really. But I’d like to see folks reap greater financial rewards, not just the – less tangible but no less important – rewards of community, fellowship and interesting projects. Americans call wages “compensation” – I guess folks here don’t have to receive as much compensating for the crap as in other companies.

Sam: So you don’t get anyone “trying it on”?

Bob: Not to date. We subscribe to McGregor’s Theory-Y, which invites us to believe that employees are internally – or ‘intrinsically’ – motivated, enjoy their job, and work to better themselves without a direct (financial) reward in return. We’ve found this to be a valid assumption in our case. We strive to make Familiar a place when folks love to get together and do interesting, meaningful things. As our Credo states: “Familiar exists for folks to come together and explore what ‘fulfilment’ means for each one, individually”.

Sam: And as for the other things folks can choose? You mentioned equipment, locations, working times, and the nature of the relationship with the community?

Bob: Again, we want folks to feel like we regard them as adults, with the capacity to choose what’s best and most suitable for them, and thus for the (extended) community too. So everyone gets to choose their development computer(s), monitors, keyboards, etc., and development platform (operating system, tools, languages and such). Some folks have their own kit, and for others Familiar buys some or all of the kit. Some interoperability considerations apply, of course, and the customer often has some requirements relating to the operational/production environment. Project teams organise themselves to factor all this into the mix as part of their development process.

Sam: And locations?

Bob: Everyone works where they feel most comfortable, convenient or productive. Different issues affect different people. And folks are invited to vary their location as they see fit – and as suggested by the nature of the task they’re involved with at a given hour or on a given day. We have our office here, of course, with the public cafeteria, bookable meeting rooms, and our private community office space divided into bullpen, library/lounge with couches, a number of personal offices and the kitchenette. But folks work from home – and each others’ homes – as often as not. We also make a point of getting out as a group, both for meals and drinks in local restaurants and pubs, and for longer weekends away at comfy hotels. One chap who would otherwise have a long commute has a satellite office nearer to his home location. Again, “everybody’s different” – and capable of making their own choices.

Sam: Working times and the relationship with the company/community?

Bob: Folks work the hours that suit them, with the only proviso that the clients’ schedules get consideration. We have some early birds, some late birds, and some bird-of-a-feather (folks who like to regularly pair or work in sub-groups). The latter means they coordinate (self-organise) their schedules and locations, to some extent. As for relationships with the community, I’m talking about what some other companies might describe as the “contractual relationship”. We have some hour- and day-rate “contractors”. Some weekly paid and monthly paid “employees”, and a couple of folks – like myself – whose relationship falls outside those categories. And while we’re talking about pay, I guess I could mention the bonuses. We don’t have any formal bonus scheme as such, but when a particular project goes well, folks get together to consider the costs and revenues and decide if a team bonus is appropriate and what level and split would suit.

Sam: Would you do anything different if you found yourself involved in a different community in the future?

Bob: Nothing significantly different. Excepting that circumstances prevailing when we started Familiar allowed us the opportunity to trial these “wacky” ideas in practice. Such circumstances may not present themselves next time around. Folks have to be open to the ideas of doing things differently, or I suspect a similar scenario might never even get off the ground.

Sam: Do you have any advice for others thinking about building this kind of environment for their businesses?

Bob: I hate giving advice – I find it rarely followed. But one thing I would say – don’t underestimate the time needed for, and the value of, supporting folks who might feel uneasy from time to time about the choices they’re enabled to make. I’ve put in much time supporting people here when the way forward has seems unclear for them personally. But I feel it’s never been enough support, and I always want us to do more. And one word of caution: Time. It’s taken us three years of daily practice to even begin to understand how these ideas all fit together. The benefits are definitely there, we’re demonstrated that, but few companies seem to have a longer-term view. Along the way, we have discovered some useful shortcuts.

Sam: Thanks, Bob, for sharing your experiences with me, and my readers.

Bob: My thanks to you also, Samantha. It’s been fun.

[End]

– Bob

The Evolution Of An Idea

January 19, 2020

Culture change, Familiar, Marshall Model, Organisational effectiveness, Organisational Therapy, Rightshifting

1 Comment

The Evolution Of An Idea

Many people have expressed an interest in learning more about the evolution of Organisational Psychotherapy. This post attempts to go back to the roots of the idea and follow its twists and turns as it evolved to where it is today (January 2020).

Familiar

Around the mid-nineties I had already been occupied for some years with the question of what makes for effective software development. My interest in the question was redoubled as I started my own software house (Familiar Limited) circa 1996. I felt I needed to know how to better serve our clients, and grow a successful business. It seemed like “increasing effectiveness” was the key idea.

This interest grew into the first strand of my work: Rightshifting. I had become increasingly disenchanted with the idea of coercive “process” as THE way forward. I had seen time and again how “process” had made things worse, not better. So I coined the term Rightshifting to describe the goal we had in mind (becoming more effective), rather than obsessing over the means (the word “process”, in my experience, conflating these two ideas).

“Rightshifting” describes movement “to the right” along a horizontal axis of increasing organisational effectiveness (see: chart). Even at this stage, my attention was on the organisation as a whole (and sometimes entire value chains) rather than on some specific element of an organisation, such as a software development team or department.

Circa 2008 I began to work on elaborating the Rightshifting idea, in an attempt to address a common question:

“What do all these organisations (distributed left and right along this horizontal axis) do differently, one from the other?”

Subsequently, the Marshall Model emerged (see: chart). Originally with no names for the four distinct phases, categories or zones of the model, but then over the space of a few months adding names for each zone: “Ad-hoc”, “Analytic” (as per Ackoff); “Synergistic” (as per Buckminster Fuller); and “Chaordic” (as per Dee Hock).

These names enabled me to see these zones for what they were: collective mindsets. And also to answer the above question:

Organisations are (more or less) effective because of the specific beliefs and assumptions they hold in common.

I began calling these common assumptions and beliefs a “collective mindset”, or memeplex. This led to the somewhat obvious second key question:

“If the collective mindset dictates the organisation’s effectiveness – not just in software development but in all its endeavours, across the board – how would an organisation that was seeking to become more effective go about changing its current collective mindset for something else? For something more effective?”

Organisation-wide Change

Organisation-wide change programmes and business transformations of all kinds – including so-called Digital Transformations – are renowned for their difficulty and high risk of failure. It seemed to me then (circa 2014), and still seems to me now, that “classical” approaches to change and transformation are not the way to proceed.

Hence we arrive at a different kind of approach, one borrowing from traditions and bodies of knowledge well outside conventional management and IT. I have come to call this approach “Organisational Psychotherapy” – named for its similarities with individual (and family) therapy. I often refer to this as

“Inviting the whole organisation onto the therapist’s couch“.

I invite and welcome your curiosity and questions about this brief history of the evolution of the idea of Organisational Psychotherapy.

– Bob

Inventing Agile

September 18, 2018

Agile, Familiar, Scrum

3 Comments

Inventing Agile

[Tl;Dr: I invented Agile in UK / Europe, independent of the USA / Snowbird folks, circa 1994].

I was running a project in Europe (Brussels, Belgium) when I first woke up to the value of “process” in delivering working software. It wasn’t the first project I’d been managing, but it was the first time in a corporate environment, with many stakeholders, and with developers and methods not of my own choosing. I have to say that the project was not an unalloyed success.

Upon completing my assignment and returning to England, spurred by my dissatisfaction, I explored the existing literature for ideas about how to do things better. And in my next few assignments I experimented with some of these ideas and began to evolve a coherent approach to software development.

Motivation

I had already long been motivated by a need to see folks able to realise their innate potential. I had often been appalled by the waste of human potential I had seen time and again in places I had worked. I was convinced there must be a better way, and set about finding it.

Influences

Key influences during this time included:

RAD (Rapid Application Development – James Martin, etc.)
JAD (Joint Application Development)
Evolutionary Development (Gilb)
Rapid Iterative Development
Risk Management (Capers Jones, etc.)
TQM (Crosby, Juran, Shingo et al)
NextSTEP
Modula-2 (Wirth)
Eiffel (Meyer)
Objective-C (Cox)

The Roots of European Agile

By the time I came to work with the CFO of Barclays, running some internal projects at Barclays head office, I had the kernel of an approach that today we’d label “Agile”. This was 1994.

As you may see from the influences listed above, I was already leaving the waterfall / V-model camp and beginning to favour iterative and incremental approaches.

Even in these early days, the results were outstanding.

Continuing to apply and evolve the ways of working I discovered at Barclays, I then did a tour of some of the major merchant banks in the City, where proven ideas for improving their software development results found some favour.

A couple of years later found me at Sun Microsystems’ UK Java Center, bringing these development approaches to Sun’s major corporate clients looking to transition their development teams into the Java ecosystem.

At this time I began referring to my now well-formed approach as “Jerid”.

Note on the Name

Jerid grew out of two complementary initiatives I had been running for some years named “SPEAR” and “BEAR” – Software Process Engineering And Reengineering, and Business process Engineering And Reengineering. SPEAR consisted of many of the techniques I had found useful through years of experimentation and application, packaged into a coherent whole. But SPEAR was more an umbrella concept, with different flavours of specific development approaches underneath – most notably Jerid.

In case you’re wondering, “Jerid” is a kind of javelin (throwing spear) used in games played on horseback in certain Muslim countries in the Middle East. It was also a somewhat convoluted acronym for “Java Enterprise Rapid Iterative Development”. Jerid later evolved into “Javelin”.

The Heart of Jerid

Jerid was founded primarily on ideas from risk management and rapid and evolutionary iterative development. By 1997 it had evolved to a point where, with hindsight, it looked circa 80% like Scrum was to look some years later. Two-week iterations (time boxed), sprints, sprint goals, sprint planning, retrospectives, etc.. I had independently invented “Agile” software development in Europe some years before the name itself was chosen at Snowbird, USA in 2001.

The core difference between Jerid and e.g. USA Agile/Scrum was Jerid’s emphasis on risk management. Jerid projects ensured that the major risks were identified and controlled. For me, this is the essence of any Agile approach – managing and controlling the major risks – both those common to all software development projects and those specific to each individual project.

We continued to apply and evolve Jerid during the late ’90s, at Familiar and its clients, until my departure from Familiar circa 2000.

Since then I have worked with a large number of different companies, large and small, helping them discover the fundamental principles underpinning iterative and agile approaches, and evolving practices and ways of working from those principles.

Acknowledgements

I’m very pleased to be able to acknowledge the contributions made to SPEAR and Jerid by many folks along the way. Although none of this would have happened without my input, their help and support was invaluable to me in evolving my understanding of software development, and later, the intersection of software development and general business.

Disclaimer

I’m pretty sure other folks also invented their own takes on the Agile theme before it became known by that name. Maybe even before I did. I’d be delighted to hear from anyone who believes they fall into that category.

Also please note that many of the strands of the thing that has become known as “Agile” existed long before I even got started in the field of software development methods. We all owe a debt to those many pioneers who were pushing the envelope and challenging accepted wisdom back as far as the 1960s and 1970s, if not before.

– Bob

Why Familiar Was Europe’s First 100% Agile Software House

January 9, 2015

Agile, Antimatter principle, Familiar, Organisational effectiveness

7 Comments

Why Familiar Was Europe’s First 100% Agile Software House

Familiar was a software house based near Reading UK (some forty miles west of London), which I started and led, along with several ex-Sun Microsystems colleagues, circa 1996-2000.

This post is about why we decided on “Agile” as our general approach to getting things done. It’s not so much about why we were the first.

One Hundred Percent Agile

This refers to the fact that all our work – both client-facing and internal – was conducted in an “agile” manner. Which is to say, the way we worked back then looked something like Scrum does nowadays, e.g. with two week iterations, emergent “requirements” and regular delivery of working things into production.

Of course, this was some five year years before the label “Agile” was to be coined by the Snowbird folks and therefore some years before this way of working began to be applied more widely, by others, in the software house kind of context.

You could also say we were 100% Agile because (what came to be identified as) Agile principles informed our approach to working across the whole organisation – both our own organisation and that of clients – and not just in the software development work we did.

Why

We didn’t call what we did “Agile” or “agile”. We weren’t trying to replicate someone else’s approach or ways of working. We weren’t trying to be agile, we were intent on being great! And for us, great meant “highly efffective”.

We adopted our own approach to work – primarily but not exclusively software and product development work for various clients – because we wanted to better meet the needs of our customers, of ourselves and of our company. And incidentally, the needs of our suppliers, our loved-ones, our shareholders – mostly the folks working for the company – and our channel partners, too. We continuously evolved our approach – which we then called Jerid, now Javelin – both to adapt to changing contexts, and to more effectively meet folks’ needs, as we learned more about what those need were and how to go about better meeting them.

Let me say that again, we chose to work the way we did because we wanted to better meet folks’ needs. I wouldn’t have uses this form of words back then, but with the benefit of hindsight this is what we were intent on doing.

We had all seen enough of the IT/software industry to know that the industry norm was far from meeting anyone’s needs effectively. We knew we could do much better. And we knew the basics of how. We were determined to continue to advance our knowledge in that regard.

Success

We succeeded, I believe, because the whole organisation was geared to the Jerid approach, and there were no discontinuities, such as we see in many organisations trying to “go agile” today. By which I mean, for example, the discontinuities between the “agile” software teams and the rest of the containing organisation, with its raft of decidedly non-agile – even anti-agile – beliefs, principles, processes, policies, procedures and organisational structures.

Put another way, our way of working met folks’ needs, not because of any specific characteristics – NOT because it was, or we were “agile” – but because we wanted to be great at what we did, and took time and effort to understand how we could achieve at least some of that aspiration.

We were building an environment in which folks could come together, work well together, find and grown intrinsic motivation, build positive interpersonal relationships both internally and externally, and excel.

– Bob

Ahead of Its Time

How Familiar Proved Human Flourishing and Business Success Naturally Align

The Foundation: Systems Thinking

Deming in Practice: Eliminating Fear

Goldratt’s Constraint Theory: Finding the Real Bottleneck

Ackoff’s Interactive Design: Purpose-Driven Organisation

The Synthesis: Mission Command Principles

The Exemplar Results

The Broader Implications

Auftragstaktik Mirrored in Collaborative Knowledge Work

The Product Aikido Framework

Why Command-and-Control Fails

The Learning Journey

The Pleasant Surprises

The Trust Dividend

The Ultimate Paradox – And Its Limitation

The Continuing Proof of Concept

Ahead of Its Time: Pioneering What Others Would Later Theorise

Further Reading

Share the joy :)

FlowChainSensei’s Hitchhiker’s Guide to Tech Startups

DON’T PANIC!

Part 1: Strategic Foundation Framework

Legal and Regulatory Framework

Trust, Safety, and Verification Systems

Technology Infrastructure and Data Management

Payment Processing and Financial Infrastructure

Customer Support and Community Management

Market Research and Customer Development Strategy

Future Strategic Options (Horizon 2/3)

Part 2: Partnership Inception Meeting Framework

Purpose and Vision Alignment (15 minutes)

Legal Structure and Compliance Framework [Priority 1] (15 minutes)

Business Model Validation and Revenue Strategy [Priority 1] (15 minutes)

Partnership Structure and Equity Discussion (15 minutes)

Technical Architecture and MVP Scope [Priority 1] (15 minutes)

Trust, Safety and Search Strategy [Priority 2] (15 minutes)

Operational Planning and Resource Allocation (15 minutes)

Next Steps and Action Items (20 minutes)

Priority Parking Lot (Deferred Items)

Part 3: Implementation Roadmap and Planning Tools

Prioritisation Framework

Implementation Timeline

Ready-to-Use Planning Templates

Contingency Planning

Stakeholder Communication Framework

Conclusion

Colophon

Further Reading and References

Business Strategy and Planning

Subscription and Platform Business Models

UK Legal and Regulatory Framework

Partnership Formation and Governance

Trust, Safety, and Content Moderation

Payment Processing and Financial Technology

Customer Experience and Community Building

Risk Management and Crisis Planning

Startup Operations and Scaling

Government and Industry Resources

Share the joy :)

The Art of Being Methodical

The Missing Link in Modern Work

What Does It Mean to Be Methodical?

The Curious Absence of Methodical Approaches

Overcoming the “Boring” Perception

Learning from Existing Frameworks

The Core Elements of Methodical Thinking

The True Purpose: Enhanced Alignment

The Benefits of Embracing Methodical Approaches

1. Cognitive Offloading

2. Consistent Quality

3. Improved Learning

4. Enhanced Group Understanding

Implementing Methodical Approaches: A Practical Path

The Role of Flexibility

Moving Forward

Share the joy :)

A Guide to Meaningful Living

The Man Behind the Method

The Search for Meaning: Core Principles