“Loop engineering” brings a shift beyond prompting agents one turn at a time, but behind the new term, there seem to be simple and familiar process automation principles at play. I think of “loop engineering” simply as process automation with agents. A loop is just a scheduled task trigger, and a skill is just reusable instructions to perform a task.

Making sense of “loop engineering”

The rapidly evolving ideas and terminology around “loop engineering” can be tricky to follow.

“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops,” says Boris Cherny, the creator of Claude Code (which has a /loop scheduling feature). Boris describes a real shift beyond manual prompting: systems can now discover work, invoke agents, check outcomes, and continue directing the work without someone initiating every turn.

Addy Osmani describes the practice of what Boris calls “writing loops” as “loop engineering”. Addy breaks that system into automations, worktrees, skills, plugins and connectors, sub-agents, and memory.

A process automation lens

All of this can seem new and confusing at first. The exciting part is that we can cut through that by viewing these new capabilities through familiar ideas from process and workflow automation in organisations:

• Which process tasks do we want to automate?
• What should trigger each process task?

From that perspective:

• A “loop” is a scheduled trigger for a task in a process.
• A “skill” contains reusable task instructions.
• “Loop engineering” is simply process automation.

The ideas behind process automation are not new. What is new is the way it is implemented: using agent development harnesses such as Claude Code, Codex, Cursor, and OpenCode, together with a variety of new practices.

Examples

Scheduled automation

A scheduled trigger is the most straightforward example. A schedule might trigger a security scan every morning. The skill tells the agent which scanners to run, how to assess the findings, and where to report any problems.

Creating our automation can be very easy:

• The skill describes how to do the task: Defining one can be as easy as writing a few lines of instructions and saving them in a SKILL.md file.
• The trigger starts it: Creating one can also be as easy as typing /loop in your chat and saying what should run and when.

Event-based automation

Task triggering does not have to be schedule-based; it can also respond to an event. Consider a simple software development lifecycle:

Requirements → Specification → Planning → Development → Testing → Review → Deployment

This is the process. Each stage contains tasks that might be completed by people, agents, or both.

For example, a ticket moving from planning to development is an event or change-of-state trigger that can start the development task. The skill is the reusable prompt that tells the agent how to complete that task. It might include understanding the specification, making the change, running the tests, and preparing the work for review.

In both cases, a trigger starts a defined process task.

Conclusion

The tools are new, and the possibilities are exciting, but process thinking isn’t. By unpacking the processes in our organisations, we can find opportunities to improve or automate them and use “loop engineering” and skills to put those changes into practice with agents.

Agentic software is changing how we build.

As agentic coding becomes more common, how good your prompts specify the behaviour you want is a key to good agent dev outcomes. The goal is longer autonomous execution loops: give an agent intent, let it plan, let it build, let it run checks, and keep going.

The workflow many of us are moving toward is:

Prompt with a Spec → Agent Plans → Agent Builds → Agent Runs Tests

Weak specs lead to unreliable autonomy. Strong, executable specs make autonomy safer.

1. Agentic software is changing how we build

Agentic coding is increasingly common. Tools like Claude Code, OpenCode, Codex, Cursor, and Goose point at the same direction: longer loops where the system can take intent and move from analysis into implementation.

But the key constraint remains intent.

The emerging workflow is simple:

1. Prompt with a Spec
2. Agent Plans
3. Agent Builds
4. Agent Runs Tests

Weak specs still produce weak outcomes. LLMs do not remove ambiguity. They often scale it.

2. The industry is experimenting with spec tools

A good example is GitHub’s Spec Kit: an open-source toolkit for spec-driven development. It installs a specify CLI, sets up agent workflows, and gives agents structured commands like /speckit.specify, /speckit.plan, /speckit.tasks, and /speckit.implement.

That is useful. It makes the path from product scenario → spec → plan → tasks → implementation more explicit.

But it still points at the same hard problem: generating a plan from a spec is useful; keeping the spec correct as the system changes is the long-term problem.

3. Specification by example already exists

The main idea in the Specification by Example book is simple: instead of writing traditional requirement documents like “the system should calculate discounts correctly”, teams define concrete examples:

“When a customer buys 3 items, they get 10% off”

“When they buy 10 items, they get 20% off”

These examples become the basis for:

• requirements
• automated acceptance tests
• development guidance
• documentation

This approach is what the book calls Specification by Example (SBE). It is the same family of practice behind BDD, Cucumber, and Gauge: make behaviour concrete enough that humans, agents, and CI can all work from the same examples.

That directly solves a problem agentic development exposes:

• Ambiguity – examples make intent concrete.
• Misalignment – humans and agents can work from the same behaviour contract.
• Spec drift – the build fails when behaviour no longer matches the spec.

The important part is that it isn’t just a static document, it is the feedback loop. If the spec is continuously validated by the build, it does not silently rot.

4. BDD + AI = spec-driven development loop

Put together, the practical workflow becomes:

1. Prompt with a Spec
2. Agent Plans
3. Agent Builds
4. Agent Runs Tests

This is where BDD and AI fit together naturally: BDD plays at both ends of the flow. At step 1, it gives the agent concrete examples up front. At step 4, executable tests keep the loop honest after the build.

With AI, this matters more because LLMs amplify spec quality. Strong specs make autonomous execution more reliable. Weak specs create scalable incorrect behaviour.

Gauge test framework fits this BDD model well because Markdown specs are readable by humans, easy for LLMs to consume, reviewable in pull requests, tied to executable code, and close enough to the repo and CI to become part of the engineering system.

The final point:

BDD helps solve the specification drift problem by turning examples into executable tests: the same specs guide the build and keep checking the behaviour over time.

Thought experiment: a ~20 person team structure (aka Peloton)—about 7 2-person-crews, ~5 supporting specialists, and a product manager—might ease new bottlenecks from LLM efficiency.

LLMs have significantly expanded what individual software product developers can achieve.

How does this massive change affect software product org structures? This seems to be an open, jarring question.

Below is my stab at a reference structure to answer this—but only as a thought experiment for larger software product orgs, not as something you should “roll out” from a blog post.

The shape below is stitched together from first principles and from what I have seen coaching and advising over the years. It is not a case study of one “proven” model. Treat it as a sketch to argue with: stress-test the ideas, steal a piece, or discard the lot.

I mean this as an open discussion: the field is moving quickly, and I am super keen to learn more from others’ thoughts and experiences.

So here it is: instead of only the Spotify-style squad—the usual canonical 5–7 person cross-functional team—consider a Peloton-shaped unit.

Treat this as an idea, not a rigid org chart. The part worth considering is the pattern: pair-sized ownership, pull specialists when you need depth, a shared harness, and guardrails—more than any exact headcount. The numbers below (±20 people, ~7 crews, ~5 specialists) are illustrative: one plausible balance of coverage and flow. You might run smaller, combine roles, or split a Peloton across product lines without “breaking” the model—as long as you do not reintroduce the old bottlenecks by accident.

Guiding structure & roles:

• Peloton is a +-20 person end-to-end product development team (large!) composed of 5-7 2-person-crews and 5-7 specialists.
• Crews: Each crew is an autonomous product development pair: typically a senior generalist and a junior developer, who together own the full process from idea to delivery. Alternatively any pair that covers all the generalist skills necessary to develop a feature: product, domain, UX, code, engineering, QA, infrastructure. In some cases a crew of 3 could work.
• Support: specialists: Supported by 5-7 shared specialists. Product, domain, UX/UI, guardrail+QA engineering, software, harness engineering.
• Support: product manager: oversees overall priorities and cohesiveness of product components and backlogs. Not involved in every detail.

Process:

• The Crew owns delivery from idea into users’ hands (in production). We understand that this requires harness maturity, so practically staging with external checks could be implemented as a crutch, but not the end goal.
• The Crew pulls in specialist help as needed: e.g. when making a small change, maybe run a proposed implementation past the UX expert. Maybe a software/harness expert to improve flow. Maybe guardrail+QA engineer to workshop guardrails for the new work.
• Each Crew has its own prioritised backlog of work which it works from daily, and its own standups. No shared daily standup with other crews.
• The Crew pulls work from the product manager’s overall roadmap into its backlog when it plans. With bigger, non-obvious changes crew workshops solutions with the product manager, UX to come up with overall design.
• The Peloton can get together to align on product, share learnings, retrospect, maybe once a month.

In bigger orgs:

• Specialist “Chapters” that operate across Pelotons, to help crews and specialists in a specific specialty and defining cross-Peloton learning and governance is valuable as ever.
• Product Managers can report into a central structure to prioritise business goals.

In this thought experiment, the structure attempts to combine what worked before with first principles: a team shape that optimises flow of value given that a single person can do lots more, while handovers, consensus, and gates that depend on other people still act as bottlenecks. Also, one person can’t be the perfect generalist, and needs help. Organisations (and society) also need to think about continuity, knowledge sharing and mentoring the next gen (hence the junior).

One downside of the above model is the vast amount of skills a generalist Crew member is required to have - but I’m wondering: isn’t this the reality of the skills growth challenge we are faced with in order to get the full flow benefits of LLMs?

Context

In the Agile world, the well established idea of cross-functional software product teams became the canonical structure to optimise product development value, eloquently described in Hendrik Kniberg’s Spotify Engineering Culture videos. In coaching work I have helped organisations move toward that kind of model; the Peloton sketch earlier in this post is a separate, speculative step for the LLM era—not a claim that I run it end-to-end in my own small team.

However, in the era of LLM-assisted development, that canonical squad model is being challenged. Everyone recognises the need to get very skilled at working with LLMs and learn how to get the benefits. Also, everyone seems to have experiences of 1 person team / “lone wolf” being extremely productive, there is consensus on this. But structuring your company as 1000, 1 person teams would surely be chaotic? Imo you need effective team/communication structures in a larger org, in the LLM era, just as much as the Roman army did 2k years ago.

Historically, similar transitions have followed a consistent trajectory: Extreme Programming introduced pairing and tight feedback loops, and CI/CD gradually became an industry standard. The direction has been consistent: faster feedback loops, reduced handoffs, increased ownership, and stronger engineering discipline. LLMs represent the next step change: capable developers can now operate across implementation, design exploration, testing, documentation, analysis, and refactoring. This does not remove the need for teams or software engineering practices but changes the shape of the smallest effective delivery unit. Traditional cross-functional teams aimed to reduce dependencies between specialised roles, but when individuals can operate broadly across the stack, those structures may become unnecessarily constraining. At scale, the question is what shape preserves flow while enabling scale, quality, and learning—this article offers one possible answer, not the answer.

The Core Unit: Product Development Pair

The fundamental new delivery unit is the Crew: A Product Development Pair, typically a senior generalist and a junior developer.

It doesn’t have to be senior/junior, any pair that covers all the generalist skills necessary to develop a feature: product, domain, UX, code, engineering, QA, infrastructure would work. The reason I’m pushing the junior here as a kind of apprentice, to solve the continuity for the company and large skills requirements to be effective - and grow the next generation of builders. Think of a blacksmith with an apprentice. It’s more for the long term benefits.

The pair owns delivery end-to-end, collaborates closely, and uses AI tools to expand capability.

While a pair can operate as a single individual, pairing provides several lasting organisational and personal benefits. A crew of 3 could also work in some cases. Knowledge sharing prevents silos and single points of failure. Not growing the next generation would be a mistake - and becoming a good generalist is especially daunting. Pairing supports the development of future generalists, creating a continuous learning environment embedded directly in delivery work. LLMs expand individual capability, but collaboration remains essential for quality, human growth and long term continuity.

Each pair maintains an independent backlog and aims to deliver with minimal blocking dependencies, ideally to production. Independent backlogs clarify ownership, increase delivery speed, and improve the flow of value.

Pairs have authority to decide when specialist input is required. Lightweight prompts can support decision-making, such as: “Does this change introduce architectural complexity?” or “Are there reliability concerns?” Temporary checkpoints can scaffold teams still building capability, similar to early CI/CD adoption, ensuring high flow and quality without rigid gates.

Pairs pull in specialists only when beneficial. For example, a UX specialist may contribute to complex interaction design or review flows, while a product/domain specialist may shape problem definition or validate direction. The harness engineer provides architectural guidance and shared technical patterns. QA specialists focus on exploratory testing, edge cases, and system reliability. Specialists act as force multipliers rather than sequential phase owners. Most teams I dealt with struggled to reach fully pull-based delivery before—but I don’t think that will be optional if we want the speed and quality now available.

The Harness Engineer

A key new specialist support role is the harness engineer, who maintains the shared technical environment across the unit. Think of this as the devops engineer for the LLM enabled world. This role builds systems and pipelines, guardrails, manages development environments and reusable engineering patterns, develops approaches for LLM usage, and optimises system-level performance. The harness ensures pairs can operate effectively without managing infrastructure complexity themselves.

The QA and Guardrail Engineer

QA remains critical, providing exploratory testing, scenario evaluation, and confidence in releases. Guardrails supplement QA by proactively enforcing automated validation patterns, reliability practices, observability standards, and system-level safeguards. Together, QA and guardrails allow pairs to move quickly while maintaining product quality.

I think the traditional QA roles now need to also start thinking in terms of guardrails and test automation. Test automation is not new by any means, but in my experience where the previous best practices faltered for most teams is in test automation—I suspect it will be an even bigger problem, so the shift is from “maybe we’ll get it right one day” to “necessary from day one.”

Avoiding speculation & anthropomorphism

In this article I avoid several common views (which I don’t share):

• Job loss predictions: To me, the impact of capability expansion on employment is unclear; historically, infrastructure improvements increased demand rather than simply reducing labour - but who knows this time? Rather not speculate! But there seems to be a consensus: doing good product development now requires a broad skill set, and I worry about junior product engineers being left behind unless we deliberately make room for them in how we organise (hence the junior in each crew). “Skill up and you’ll be fine” seems to be the best advice atm.
• Teams of agents: I believe LLMs are best treated as engineering components, context, structured prompts, and guardrails, LLM in a loop with tools, rather than anthropomorphised actors. We are the engineers that have to utilise these amazing new processors.
• Removal of software engineering discipline: can a slop monolith give the best UX and also speed going forward? In my experience, no: working with LLMs increases the importance of understanding software engineering principles and practices - we need those things more than ever. E.g. XP practices like TDD and CI that allow us to work in small, safe steps, to gain speed and quality.

I am still learning on this topic; if you are running experiments with team shape in the LLM era—at a larger scale, or a deliberately different one—I would genuinely like to hear about it.

I believe the web works best when it is open and people control it. Businesses can prosper without trapping people in one ecosystem. Open protocols and portability can let services and AI providers compete while people keep their privacy, safety, and choice.

Photo: Matthew Osborn on Unsplash.

Why this matters now

The web has delivered enormous social benefits, but much of online life now runs through closed platforms. These platforms can amplify manipulation, addictive behaviour, misinformation, harassment, isolation, and polarised public debate.

Over the last ~20 years, closed platforms and their incentives have gradually shifted control over identity, relationships, information, and discovery away from people and the open web.

AI is becoming another important way people encounter the Internet’s knowledge and ideas. Its shape is not yet settled, but companies are already racing to build their own ecosystems around it. We still have a chance to do this differently.

A web that serves society

The W3C’s ethical web principles provide a useful starting point:

• An equitable, informed, and interconnected society. The web should be secure, respect privacy, support healthy communities and debate, help people verify information, and give individuals more control.
• Human agency and dignity. The web should empower people rather than manipulate, isolate, or addict them.
• Healthy community and public knowledge. The web should support constructive debate, freedom of expression, trustworthy sources, and the ability to verify information.
• Openness in service of society. Universality and non-centralisation matter because they prevent any one platform or authority from controlling how people participate, connect, and share knowledge.

What I want from the web

For me, making this vision real requires:

• People in control: identity, relationships, content, and communications should be portable rather than trapped in one ecosystem. People should control their data, time, attention, sources of trust, and the algorithms that shape what they see.
• Trust over engagement: people should choose the voices and sources that shape their social world, including who they trust to help judge information. Ranking can be useful when people can understand, choose, and change it; maximising attention should not be the organising principle.
• Healthy incentives: businesses should be able to prosper without closing the web, preventing people from leaving, or consuming ever more of their attention. Journalists should be rewarded for trustworthy, evidence-based work, not for feeding outrage and echo chambers.
• Open in practice: protocols, data formats, and the interfaces needed for interoperability should be open even when services and software are not. Openness matters only if ordinary people can switch services without losing their social lives.
• Safe for children: as a parent, I think the web should make it easier for guardians and communities to create safe, age-appropriate spaces for children. This deserves particular emphasis.
• AI is part of the Internet: AI gives us a new way to access the knowledge, culture, and collective contributions people have shared online. It should not become another proprietary layer that captures this shared foundation and controls access to it. People should be able to choose providers, carry their personal context, understand the sources behind important claims, and retain control of their data.

To me, success means being able to connect with people, find information, or use AI while remaining in control, without being addicted by design or dependent on one company’s decisions.

What could this look like?

People could carry their identity, profile, relationships, and content between compatible services. They could communicate privately across provider boundaries, choose the systems that rank information, and inspect the sources behind important claims.

The same could apply to AI. People could change services without losing their personal context or connection to the underlying web.

Providers could still compete by offering different products, communities, moderation, AI models, and business models on this shared foundation. Portability can still protect other people’s privacy, security, and consent.

What we can learn from today’s platforms

Today’s platforms already show us both what works and where control gets stuck:

• Facebook and social feeds. Early Facebook centred on updates from chosen friends and family. Over time, algorithmic recommendations and advertising optimised for attention took more of the feed. The open web should restore the emphasis on chosen relationships and personal control.
• Google and web search. Early Google put simple web results first, with advertising kept distinct. Over time, ads, promoted material, and Google’s own content became more prominent. A search business should prosper by helping people reach the web, not by gradually displacing it.
• WhatsApp and private messaging. WhatsApp gets important things right: simple communication, end-to-end encryption, and no attention-driven public feed. But identity, groups, and history remain tied to one provider. People should be able to move between compatible services, subject to everyone’s privacy and consent.
• Twitter (now X), public conversation, and journalism. Twitter showed the value of short public posts, chosen voices, and discovering events as they unfold. But identity, reach, ranking, and trust signals remain under one company’s control. Public conversation should not depend on one platform, and journalism needs healthier ways to earn trust and make a living.

AI can be part of the open Internet

Generative AI, particularly large language models (LLMs), provides another test of these principles. Without the Internet and the vast body of language, ideas, and experience people have shared through it, these models could not do what they do today.

I think of chatting to an LLM as engaging with voices and ideas from across the Internet: an extraordinary but imperfect form of the wisdom of crowds, rather than an alien intelligence. To me, that is a hopeful reflection of the value people have collectively created online.

As companies race to build ecosystems around these models, familiar questions return. Who controls people’s prompts, conversations, and personal context? Can that information move between providers? Can we trust and verify the sources?

We risk repeating the pattern of closed platforms, but it is not inevitable. I am optimistic that competition and commoditisation will limit the lasting advantage of any one company. We can build AI that remains open enough for people to retain control and real choice.

Conclusion

An open web, useful AI, and successful businesses can coexist. So why not?

Why not reclaim social life on the open web through private and group messaging, public posts, identity, profiles, and feeds shaped by trust, and use AI built on the Internet’s knowledge without once again losing control of our personal data?

Businesses can thrive on this foundation without any one platform controlling how society connects, learns, and shares information.

It began with a brief overview of the LLM breakthrough, highlighting the transformer architecture and scaling laws.

The session then offered software engineers a practical mental model: thinking of LLMs as a new type of processor, analogous in some ways to a CPU.

Although this might seem like common sense, most debates about software practices are still based on the assumption that there is one best practice for all contexts. It took us few failed software product start-ups and unstable mature products to learn this, and how to adjust our way of work, depending on the business context.

This idea has recently been expressed in various guises by a few prominent thinkers, like:

• Simon Wardley’s Value Chain Mapping
• Kent Beck’s 3X - Explore, Expand, Extract
• Jeff Patton’s Dual Track Development - Discover -> Develop

In this talk I will take you through new ideas on the topic and important differences in the 2 contexts, share stories of our own failures and successes, and give you some practical advice on adjusting your approach for the context.

This talk is for any software professional who cares about business value.

In this talk I explore a few equations that describe dynamics in software engineering, which can help us see the forest from the trees. I also cover some modern practices - and show how software engineers can get back control of their delivery.

The problems addressed include:

• Deadlocked by Dependencies: Inability to deliver due to waiting on something
• Code-Degeneration: Code changes become more difficult over time
• Congestion: Slow, unpredictable delivery even though we are very busy
• Firefighting: We know what we should do, but we don’t have time to improve

One of the most harmful misconceptions is that programming and testing are similar activities to construction in mature engineering disciplines, performed after the design has been completed.

In this talk I will give the audience a fresh look at software engineering, inspired by a 1992 article by Jack W. Reeves: “What is design?” I will show how software product development is a creative, collaborative process involving the create creative energy of all the role players in a team (including UX, BA, Dev, Test, Ops).

Finally I will revisit ideas from XP (Extreme Programming) and just show how cool this software design can be when we do it together as a team.

As an iOS developer I am convinced that a carefully designed native app provides the best user experience. So why would we choose Ionic2/Angular2 on Cordova (a bleeding edge Hybrid JavaScript framework) for our latest mobile app? In this short talk I will share our thinking and experiences on the current landscape of mobile stack options.

I will introduce the contenders: Native (iOS and Android) vs Semi-Native (Xamarin and React Native) vs Hybrid (Ionic2/Angular2 on Cordova) vs Web. We will then go through some of the prominent tradeoffs between the different options: cost, reuse, single language, speed and user experience, device support, learning curve.

This should give you some (opinionated) guidelines to choosing the right mobile stack for your particular app.

This session we will equip attendees with techniques and lessons to help them refactor more effectively. We will share our experience gained while working with various software teams, from startups to mid-sized organisations, that attempted to rescue their legacy from impending doom.

You will learn how to justify the investment in refactoring legacy code to product owners; when and how to apply different refactoring workflows on legacy code; and practical tips to avoid common pitfalls when refactoring code.

This list does not include my list of (great) programming, philosophy or management books, but speaks more to understanding and managing software development on a higher level - as I believe most software endeavors succeed/fail before a line of code was written.

A note on learning:

Almost all I know and believe about software comes from experiences and observations in delivering software, but that does not discount the value in these tomes. I typically learn a fundamental principle by first observing a phenomenon in various environments, and then, when I come across a great study or article which clearly expresses and justifies the principle I get that “AHA!” moment where deep understanding is formed. E.g. seeing estimation inaccuracy occur 100s of times, and then reading Don Reinertsen’s description of variability in product developments gave me a big “AHA!”.

Too be honest, so much in software engineering isn’t obvious or intuitive and I initially miss the messages in books that were not pre-empted by my experiences (XP being a prime example).

Here goes:

Approach and principles:

• Managing the Development of Large Software Systems, Royce (1970) The paper that introduced waterfall gave a clear warning about its risk and showed (rudimentary) ways to introduce feedback
• The Mythical Man Month, Brooks (1975) *
• No Silver Bullet, Brooks (1986)
• The New New Product Development Game, Takeuchi&Nonaka (1986)
• Extreme Programming Explained: Embrace Change, Kent Beck (1999) *
• The Agile Manifesto (2001)
• Agile Software Development with Scrum, Schwaber&Beedle (2002) *
• Lean Software Development: An Agile Toolkit, Poppendiecks (2003)
• The Principles of Product Development Flow, Reinertsen (2009)

Building the right thing

• User Story Mapping, Patton (2014)
• The Lean Startup, Ries (2011) - to find out if we are building the right things often needs more than just detailed analysis, we need to experiment, but do it fast so that we don’t run out of time/money.
• Specification by Example, Adzic (2011)
• I need more on Interaction and User Experience design! **

Building the thing right

• Decomposing Systems into Modules, D.L. Parnas (1972)
• What is Software Design?, Reeves (1992)
• Refactoring, Fowler&Beck&Brant&Opdyke&Roberts (1999) - Code is design and design should be evolve
• Test Driven Development: By Example, Beck (2002) *
• Domain-Driven Design, Evans (2003) **
• Continous Integration, Fowler (2006)
• Clean Code, Martin (2008)
• Continuous Delivery, Humble (2010)

Being a professional developer

• Code Complete, McConnell (1993)
• The Pragmatic Programmer, Hunt&Thomas (1999)
• The Art of Unix Programming, Raymond (2003)
• The Software Craftsman, Mancuso (2014) **

People, teams, systems and environment (still have a lot of reading to do here!)

• Drive: The Surprising Truth About What Motivates Us, Pink (2011)
• The Five Dysfunctions of a Team: A Leadership Fable, Lencioni (2002)
• Peopleware, DeMarco&Lister (1987) **
• Leading Self-Directed Work Teams, Fisher (1993)
• Out of the Crisis, Deming (1982) **
• An Introduction to General Systems Thinking, Weinberg (1975) **
• Biomatrix: A Systems Approach to Organisational and Societal Change, Dostal (2005)

*Books I have to read again, because I didn’t realise their significance when I read it, and therefore didn’t absorb the content.

**Books I have only skimmed that are still on my must-read.

“Nothing is more powerful than an idea whose time has come.” — Victor Hugo

“Am I going to be bored or enlightened?” was the question I asked before attending Agile 2015, my first international software development conference as a speaker.

I was enlightened. Almost overwhelmed. This is why.

I started conversing with people at the Agile Coach Camp open spaces: agile coaches, industry celebrities, hardcore programmers, change management consultants, authors, community builders, philosophers, eccentrics. A diverse bunch, but all open to debate, share, learn and apply. I’ve never experienced anything like it.

For a full week it did not stop. Topics ranged from 21st century democratic organisations to games to error handling code. The scheduled talks were good, but the informal conversations and debate were much better.

That’s great. What did I take out of all this?

How ideas in our industry work

One thing is a sense of how ideas in our software industry works, how they emerge, spread and get accepted. For example, how did DevOps get widely accepted and become de-facto?

I drew the following conclusions:

1. Ideas get born, live and grow in a professional community
This became apparent to me after speaking to a few of authors and comparing how I experienced the book versus the conversation. An idea printed in a book creates the illusion of immortality of the ideas in it. But ideas are living things in a sense: if the community rejects/forgets it, it is dead in a way (seen as false or invalid). Ideas are mortal and grow by virally replicating through professional networks.

2. Ideas are born from other ideas
The illusion of “the lone genius that figured it out, out of thin air” is often misplaced. Ideas are mostly built from other ideas, maybe a novel combination or reconfiguration.

3. Ideas often have champions
Just because an idea is not completely novel does not mean an idea does not have a champion. There is more than often an thought leader that promotes and nurtures an idea, even gives it a name. Sometimes even takes credit for it all. I call this persona the thought leader.

Do these 3 points apply to industries outside software? I think so, but the community nature of ideas seems more pronounced in software, since software practices are still changing rapidly (less stable than say, accounting), and we have no central “authority” (there is no “Ivy League Old Boys Club” or organisation that controls which ideas get accepted).

How to become an industry thought leader

The above made me think more about what makes an industry thought leader.

We had the privilege of having conversations with (in no particular order) Jeff Patton, Michael Feathers, Diana Larson, Ron Jeffreys, Dave Hussman, Chet Hendrickson and other well known coaches and authors – people I see as thought leaders in our industry (thanks Declan Whelan for making a few great conversations happen).

These discussions made me realise that I had some misconceptions. I learnt that a good thought leader often has the following traits:

1. A thought leader is a community leader
Giving credit is like spreading seeds for an idea. All of the above people were the most generous in sharing, giving credit, giving back to both people wanting to learn and people wanting to contribute new ideas. They almost always gave credit wherever they could, and promoted other people and their ideas where they could. The persona of a generous, loved community leader emerged across the board. This surprised me. I now think that this is necessary for ideas to flourish, especially for their own ideas which they are promoting.

2. Practice, practice, practice what you preach. Then show results
Practicing your ideas, and having great case studies on how you applied your thinking to various situations is crucial to getting credibility and buy in from the professional community. You obviously have to show that it works, and understand the limitations when facing better than anyone. If you have this, your idea can quickly get traction.

Charisma can get attention, but you need to show results to be widely respected – I am surprised how many speakers miss this part.

There are ways to do this without being everywhere at once. For example, Martin Fowler seems to tap into the experiences of many teams in his organisation.

3. Know how to receive critique and disagree respectfully
Critique is necessary to heathy ideas. Thought leaders know how to receive, absorb and respond to critique, without getting defensive. Critique is the hammer and anvil that hardens and moulds your ideas (or breaks ones that should not be). Your arguments will grow stronger and stronger if you consider critique carefully.

That said, it is often necessary to disagree with other ideas to draw distinctions and clarify your ideas. Thought leaders know how to do this well: know the pros and cons of the idea you are criticizing before jumping to conclusions. Rather defer judgement or even ignore arguments of other ideas you do not understand. Resist the temptation to be a “hater” in your critique, don’t use straw men or appeal to authority. “Hater” behaviour might get a bit of attention, but you ultimately loose respect and get alienated. Alienation means starvation of your ideas.

4. Bring experience from other fields
This point is about where good ideas come from. A lot (but not all) of the fresh, novel approaches come from applying ideas from other industries. Examples are plentiful, but most notably Lean Manufacturing, Life Coaching, Biology, Other Engineering Disciplines, Philosophy, Improvisation Acting, Industrial Design, Mathematics, Art and Music, Sci-Fi and a bunch more.

Having varied experience and a balanced life with varied interests, puts you in a better position to stumble across the next big thing.

5. Focus on one or two ideas at a time
Even though a thought leader might have many interests and ideas, to be a thought leader you have to be a centre of discussion on a contemporary theme, and thus have to focus on that area, at least your public interactions. You have to write and speak about it.

Conclusion

I don’t think we all have to strive to be celebrity authors, but realising that ideas live in a community, and becoming an active idea participant, a good citizen, in this community, makes you a thought leader and makes our industry better.

Or you can just build stuff.

Thanks to Martin Cronje (a few of the ideas in this post was his), and Declan Whelan (who made sure good conversations happened and ideas spread)

The Blinkist app really helped me with this dilemma last week; I managed to cover the key insights of 40+ books in just a few days. Good job Blinkist.

During this self-help binge, I noticed a few ideas being repeated in a wide variety of books, especially the more core principles.

Here are a few insights that struck me as reoccurring, as well as the books they came from:

On being effective:

• The best way to be more effective is to focus only on highest impact things next. The 7 Habits of Highly Effective People (First things first), The 80/20 Principle, The 4-Hour Workweek and others.
• Be more productive by doing only one thing at a time. The Pomodoro Technique, Getting Things Done, The Principles of Product Development Flow and others.
• Define a simple system of prioritised queues with small work items to visualise and manage work. Getting things Done, The Principles of Product Development Flow, The Pomodoro technique.
• Have goals: define explicit goals and values and measure your progress against them. Most of the productivity books I read have this idea in some form; I liked what Challenging Coaching said on it.

On becoming a better thinker / communicator:

• People inherently don’t make rational decisions/predictions – be aware of your innate cognitive flaws. E.g. we are intuitively bad at stats. Thinking, Fast and Slow, The Black Swan, Predictably Irrational.
• Practice can make hard things automatic and frees your mind up to innovate. Thinking, Fast and Slow, Outliers, Mastery.
• A story with a protagonist and an antagonist is the best format for conveying information in presentations, specifications, etc. The Presentation Secrets of Steve Jobs, User Story Mapping.
• Surround yourself with people you can learn from. Mastery and many others.

On adapting and learning:

• Managing well entails putting frequent, lightweight, honest feedback mechanisms in place at various levels. The One Minute Manager, The Lean Startup, The Principles of Product Development Flow, Challenging Coaching and others.
• Build small versions of your product first and get feedback from early niche, adopters. The Lean Startup, Crossing the Chasm
• Become good at adapting to change quickly, or die. The Innovator’s Dilemma, Who Moved My Cheese

On finding opportunities

• Build and contribute to your professional network; it’s a more secure structure than a company. The Tipping Point, Coffee, Lunch, Coffee, Never eat alone
• The Internet and social media have opened up marketing for a bigger variety of products. The Long Tail, Purple Cow

There is a sentiment that developers have to type really fast because we “type code for a living”.

I’ve long rejected that idea, and not just because lines of code is the worst possible metric for productivity. My main reason was that a good dev workflow normally entails much, much more reading than writing. Also, communication skills, design skills, etc. seem more important to me. I thought fast typing was merely a nice to have, and I never really invested time into improving mine.

But reading the great book “Thinking, Fast and Slow” by Daniel Kahneman showed me a flaw in my view (there’s so much substance in that book, I’m sure I’ll get many more insights from it).

The insight is this:

• Explicit, conscious thinking (which I believe paramount to development) takes a lot of mental energy.
• Like physical stamina, we literally have a limited pool of mental energy. Any task that needs our conscious attention depletes our mental stamina, leaving us with less good thinking.
• Unconscious, automatic processing takes less of a strain (like strolling or breathing).
• Therefore, in order to do more good thinking (as is required in solving programming problems), we need to minimise non-automatic activities.

From this we can see that an activity like correcting a typing mistake will tap our “thinking stamina”, but when typing becomes fully unconscious/automatic it will free up some space for productive problem solving. Hence, it’s important that we learn to type automatically (fast is just a nice side effect of automatic).

This line of thinking can be taken much further than just typing. Anything in our dev environment that is explicit and not automatic, like looking for a menu with some function, or doing an explicit compile, will waste our mental stamina. It is therefore really important to:

1. Know your dev tools, including common shortcuts and navigation tools. Keeping it simple is a easy way to achieve this. This has a similar benefit to automatic typing.
2. Cut out explicit tasks. First thing that comes to mind is compiling. The Ruby and other dynamic lang peeps have been doing this for years, continuously running tests in the background that shows you the impact of changes, instead of a compile, run action. Some great tools in static world, like Resharper and NCrunch helps here. Another is deploying - the whole continuous delivery movement applies here. Tools like JRebel in Java world can also help.

In summary: as a developer, always find ways to reduce explicit, non-automatic tasks that draw your attention. I, for one, will take my environment and skills like typing more seriously now.

The Harvard Mark I aka the IBM Automatic Sequence Controlled Calculator!

This amazing machine was one of the first programmable computers. I’ll tell you more about this monolith at the end of the post.

“Loop”

The original (mechanical) loop. The program is a long paper tape with holes punched in and runs in this loop. Conditional branching is not supported (no gotos, jumps); you just have one long while (true).

“Patch”

See the actual patch. A correction is made by literally patching a piece of the tape and punching new holes in. Fix your code with duct tape!

“Bug”

The classic! This “bug” was found on a Mark II mechanical component, so not really a program error. It must have been working on my machine.

More..

Tidbits I found interesting:

• It started computing 70 years ago!
• It was Steampunk! Ok, I mean it was electro-mechanical. The inventor Howard Aiken basically built a Babbage engine on steroids.
• John Von Neumann used it to help design the atomic bomb. Seems most of our high-tech was born in that war.
• The number system was decimal, not binary. So you could use all your fingers to count.
• It ran solidly for 15 years. Seems Moore’s Law does’nt apply to mechanical computers.
• The inventor did not give attribution IBM, who funded and built large parts of it. I guess after this IT companies started employing lots of lawyers.

The machine is on display at the Harvard University Science Center (where I took these photos). Hope you enjoyed this as much as I did.