Skip to main content

Transparency is the andon of knowledge work

6 min read

Summary: In Toyota’s production system, anyone can stop the line when they spot a problem. Transparent collaboration brings that same principle to knowledge work, so problems get caught before they compound.

Table of contents

The shift from waterfall to agile was predicated on the belief that what worked for the factory floor during the Industrial Revolution would not work for knowledge work in the Information Age, but assembly lines and modern software development have more in common than you might think:

Agile development can trace its roots back to the production floor of Toyota as far back as the 40s and 50s. At the core of the Toyota Production System (what eventually inspired the lean manufacturing movement) was the concept of an andon, and software teams still use the idea today.

Anyone can stop the line for any reason

In short, an andon is a system of lights and signals that allows workers to alert managers and colleagues to any problems or defects in the production process. With the pull of a cord or the press of a button at each station by any worker, the entire production system grinds to an instant halt.

The andon gives every worker the authority to stop the line and fix the root cause instead of hoping someone else fixes it later. It’s as much a culture of continuous improvement as a quality control tool: everyone is encouraged to speak up, share feedback, and work on the fix together.

Transparency is software development’s andon

Transparent collaboration in software development and other knowledge work is like the andon in a production system. Anyone can spot and call out problems early, before they get worse, and engage in constructive dialogue and problem-solving with their peers and stakeholders. Some of the benefits of transparent collaboration are:

  • Faster and better feedback loops. When the work is visible and accessible to everyone, users, customers, and colleagues can weigh in sooner and more often. This feedback can help validate assumptions, identify gaps, and improve the quality and usability of the product or service. It can also head off misunderstandings, conflicts, and rework.
  • Higher engagement and motivation. When everyone has a voice and a stake in the work, engagement and motivation go up. People can raise their ideas and concerns, and help make decisions and solve problems. They also get to see the value and impact of their work, and to receive recognition and appreciation from their peers and managers.
  • Greater trust and alignment. A shared understanding and a common goal build trust between workers and managers. Transparent collaboration lowers the barriers and silos that can hinder communication, collaboration, and coordination. It also promotes a culture of honesty, openness, and accountability, where everyone is responsible for the quality and outcome of the work, and where everyone can learn from mistakes and successes.
  • Higher quality and customer satisfaction. Catch problems early, and you prevent defects and rework before they ship. Seek and give feedback throughout the process, and your software is more likely to meet your users’ needs.
  • Faster and more efficient delivery. Visible work cuts the waste of information silos, duplicated effort, and handoffs. Stopping the line and escalating when needed avoids delays, disruptions, and dependencies, and speeds up delivery.

Transparent collaboration has real trade-offs. It requires a shift in mindset, behavior, and culture, as well as a set of tools, processes, and norms that support and enable it. It also requires a balance between openness and privacy, between collaboration and autonomy, and between feedback and focus.

Applying the andon principle to software development

The benefits of transparent collaboration outweigh the costs, especially when the work is complex and uncertain. Here are some ways you can apply the andon principle to your software development team:

  • Make your work visible and accessible. Lean into transparency. Don’t view openness and early, broad engagement as a potential liability or risk that someone might “shoot down” your idea, but as an opportunity to get feedback and improve your work. Use tools and processes that allow you to share your work with your team and your stakeholders, and to solicit and incorporate their feedback.
  • Stop the line and escalate issues when necessary. Don’t ignore or hide problems, or hope that someone else will fix them. Be proactive and responsible for the quality and outcome of your work. If you encounter a critical issue, such as a bug, a security issue, a performance degradation, or a user complaint, stop what you’re doing and alert your team and your stakeholders. Don’t resume your work until the issue is fixed, or a mitigation plan is in place. Learn from the issue, and implement preventive or corrective actions to avoid or reduce its recurrence.
  • Seek and provide feedback early and often. Don’t wait until the end of the project or the release cycle to get feedback from your users, customers, and colleagues. Solicit and incorporate feedback throughout the software development process, from ideation to deployment. Use techniques such as user research, prototyping, testing, and experimentation to validate your assumptions, identify gaps, and improve your software. Be open and receptive to feedback, and use it to learn and improve, not to blame or defend. Give constructive and timely feedback to others, and appreciate and acknowledge their contributions.
  • Collaborate and problem-solve with your team and your stakeholders. Don’t work in isolation, or assume that you have all the answers. Draw on the experience of your team and your stakeholders. Involve them in the decision-making and problem-solving processes, and respect their perspectives and inputs. Use methods such as brainstorming, design thinking, and retrospectives to generate and evaluate ideas, and to identify and address root causes. Communicate clearly, and align on the goals, expectations, and roles. Celebrate and share your successes, and learn from your failures.
  • Create a culture of continuous improvement. Don’t settle for the status quo, or assume that there’s nothing you can do to improve. Continuously reflect on your work, and look for ways to make it better. Use tools and processes such as retrospectives, postmortems, and root cause analysis to identify and address issues, and to implement preventive or corrective actions. Encourage and reward experimentation, learning, and innovation. Be open to change, and embrace new ideas and approaches. Don’t be afraid to fail, and learn from your mistakes. Share what you learned with others, and help them improve.

Pull the cord

Software development is not the same as manufacturing, but it shares some similarities. Both are complex, iterative, and collaborative processes that involve creating and delivering value to customers. Both also face challenges such as quality, efficiency, and innovation. And both can benefit from the andon principle.

The andon principle won’t fix everything, but it’s a powerful tool for catching problems early and building a culture of collaboration on your team. Next time you spot a problem, pull the cord.

Keep reading

  • AI-first program management

    AI-augmented program management grows out of async-first, engineering-inspired workflows. It amplifies human judgment instead of replacing it.

  • Manage like an engineer

    If issues, pull requests, and project boards are the best way to develop software, should they not also be the best way to manage software development?

  • Why open source: 26 reasons to embrace it

    Open source isn't a fad. Here are twenty-six economic, moral, and personal reasons your organization should embrace it.

Ben Balter

I'm Ben Balter, and I write here about developer platforms, product and engineering leadership, open source, and showing your work. I spent over a decade building developer platforms at GitHub. For five years I was a product manager for trust and safety, shipping 500+ features and the API endpoints behind them to 50M+ developers. I also led a bottom-up rewrite of GitHub Pages and wrote the open source library behind GitHub's license detection, and my open source projects have hundreds of millions of downloads. I wrote Open and Async, the playbook for remote and distributed teams, and shipped a Model Context Protocol (MCP) server alongside it so agents can query it directly. More about the author

Follow along: Bluesky LinkedIn

Originally published August 30, 2023 View revision history

This page is open source Help improve this article on GitHub

Keyboard shortcuts

Search

  • / or ⌘ K Open search
  • ↓ or j ↑ or k Move through results
  • Enter Open the selected result
  • Esc Close search

Go to

  • g then h Home
  • g then p All posts

This page

  • y Copy link to this page
  • ? Show this list