Does Your Job Really Matter?

The Fundamentals of Choice

In business and innovation, the freedom to choose how to respond to requests plays a pivotal role. Choice energises individuals and teams, sparking creativity and fostering environments ripe for innovation. It’s not just about what’s being offered or requested; it’s about how the offer or request is framed.

Step 4 in Nonviolent Communication

Marshall Rosenberg, known for his work on Nonviolent Communication, sheds light on this concept with Step 4 of NVC: Making a Request. In this step, the focus is on asking for what we want in a manner that respects the other’s ability to decline. By making a refusable request, the psychological impact on the recipient is less about feeling coerced and more about seeing an opportunity for collaboration and mutually making life more wonderful.

The Psychology of Invitation vs. Direction

Traditional management styles often involve direction or obligation, wherein people are told what to do, with nary an option to decline. An alternative approach rests on the psychology of invitation. Inviting someone to partake in a action subtly confirms their autonomy, making them more likely to engage meaningfully, when they choose to do so. Compared to direction or obligation, which might result in grudging compliance but not enthusiasm, invitations cultivate genuine interest and involvement.

Delving Deeper into Refusable Requests

Understanding the psychology behind refusable requests can shed light on why this approach is so powerful in collaborative settings, particularly in business and innovation.

Respecting Autonomy

Human beings are wired to seek autonomy, the ability to govern ourselves and make our choices. When a request is framed in a way that it can be refused without negative consequences, it implicitly acknowledges the person’s autonomy. This respect often leads to higher levels of trust and openness between parties, vital elements in any business relationship.

Encouraging Psychological Safety

The possibility of refusal without repercussions creates a sense of psychological safety. In such a safe space, individuals are more likely to express their ideas, concerns, or hesitations, leading to more robust decision-making processes.

Enhanced Intrinsic Motivation

When people are allowed to choose their path freely, they are more likely to be motivated by internal factors like interest, joy, or the sense of accomplishment that the task provides. Intrinsic motivation is a strong predictor of high-quality work and innovation.

Reduced Resistance

Imposed tasks or directions can often meet with subtle forms of resistance, even if overtly accepted. Refusable requests minimise such resistance because they transform the nature of the task from an imposition to an option. When people perceive they have options, resistance lowers, and the likelihood of wholehearted engagement rises.

The Catalyst in Innovation

In the sphere of innovation, choice is the bedrock. The act of inviting colleagues to contribute or refusing a request without backlash supports a risk-taking culture. When people aren’t afraid to say no, the yeses are more potent. This framework not only invites diverse perspectives but also fosters a sense of ownership among participants.

Making Life Mutually More Wonderful

Incorporating refusable requests into business practices doesn’t just improve collaboration; it enriches the overall experience of working together in a manner that benefits everyone involved. Such an approach signals mutual respect, fosters empowered decision-making, and minimises stress, thereby enhancing well-being. The ripple effect of these individual benefits culminates in a culture that’s ripe for innovation and creativity. In essence, the practice of framing requests as refusable not only elevates the quality of decisions but also fosters a work environment that makes life mutually wonderful for all participants. Semper mirabilis!

Future Considerations

If we view business and innovation as intricate social systems, the way we communicate can significantly affect behaviours, and thus productivity. Through the art of crafting refusable requests and understanding the psychology behind them, we can evolve beyond traditional practices. This isn’t just about being polite; it’s about leveraging human psychology to catalyse groundbreaking improvements and innovations.

The Mirage of Measuring Productivity

Most organisations regard metrics as the Holy Grail of productivity. But what if we’re wasting our time, trapped in a Sisyphean cycle of measuring, adapting, and then measuring again, without achieving improvement? Metrics often mislead us. The more relevant question is: How do we truly make a difference?

The Complexity of Social Systems in Software Development

To get to the heart of the issue, we have to confront the chaos that comes with human beings working together. People aren’t variables in an equation; they’re living, breathing agents of unpredictability. In such an environment, even if we find a metric that looks promising, the inherent complexity could render it meaningless.

Deming’s Caveat: “The Most Important Figures are Unknown or Unknowable”

Before we take another step down the rabbit hole of productivity metrics, let’s pause to reflect on a pertinent insight from W. Edwards Deming, the father of modern quality management. He stated,

The most important figures that one needs for management are unknown or unknowable.

If one of the most influential minds in quality management and productivity warns us against an over-reliance on metrics, it’s worth taking note.

Why Metrics Often Fail in Social Systems

Metrics tend to misfire when applied to the inherently chaotic world of human interaction. It’s not a mechanical system with predictable outcomes; it’s more of an organic entity with complex, non-linear interactions. So, when metrics disappoint, it’s not the numbers that are at fault but our misplaced expectations of their ability to capture reality.

Turning to Systemic Improvements: The Untold Chapter

If we heed Deming’s advice, our focus shifts from trying to measure the immeasurable to creating conditions for productivity to flourish. When we step back from the Sisyphean task of trying to pin down productivity with metrics, as per Deming’s counsel, we make room for a paradigm shift.

Instead of fixating on measured outcomes, the focus turns towards the fertile ground from which these outcomes naturally emerge. Here’s how this shift fundamentally changes our approach to productivity. (Cf. Quintessence).

Systems Thinking: The Big Picture

Deming was a strong advocate for systems thinking. This perspective urges us to see the workplace not as a collection of isolated variables but as a holistic system. Individual performances are interrelated, affected by the entire system, including leadership styles, workplace culture, communication pathways and a host of other memes. By optimising the system as a whole, we inherently create conditions for better productivity.

Quality of Interactions Over Quantity of Output

If we’re not bogged down by the numbers, we can invest time and energy into what really matters, such as the quality of interactions among team members. High-quality interactions naturally lead to high-quality output. Team members who communicate clearly, collaborate effectively, and feel psychologically safe are more likely to be productive.

By heeding Deming’s advice, we engage in a more holistic, humane, and, ironically, effective approach to boosting productivity. We may not have a neat vanity metric to showcase in the next board meeting, but the signs will be everywhere—in the engagement of the team, the quality of the work, and the satisfaction of your clients.

Improving Without Measuring: Sounds Like Heresy, Doesn’t It?

Here’s the part where some people might think we’re heading into taboo territory. How do we know we’re making progress if we’re not measuring it? The key is to focus on systemic improvements that are intuitively beneficial, such as:

• Surfacing and reflecting on collective assumptions and beliefs
• Attending to folks’ needs
• Enhancing communication channels
• Making things visible
• Reducing work-in-progress
• Emphasising learning and personal development
• Promoting psychological safety

By attending to these areas, we’re likely moving in the right direction, even if we can’t quantify it.

Feedback Loops: Your New Best Friend

Feedback loops provide insights without the narrow focus of traditional metrics. They allow teams to observe patterns, adapt, and continuously learn. These can range from daily stand-ups to sprint reviews, to customer feedback sessions. The idea is to keep the feedback continuous and actionable.

Holistic Approaches: Taking a Cue from Organisational Psychotherapy

Improving productivity in complex systems requires less of a mechanical approach and more of a therapeutic one. Techniques like organisational psychotherapy aim to uncover underlying issues at the collective subconscious level. By addressing these foundational aspects, we’re more likely to see a genuine shift in productivity.

So, Are We Moving the Needle?

The perennial question still stands: How do we know we’re improving? But maybe we’ve been asking the wrong question. The more relevant question is: Are we creating an environment where improvement is not just possible but inevitable? And what does that environment look like?

So, let’s leave behind the vanity of metrics and embrace the nuanced, often messy journey of actual improvement. The numbers may not make it to a glitzy PowerPoint presentation, but the positive change will be palpable. And isn’t that what really matters?

1. Don’t.
2. More nuanced: Articulate your needs (for e.g. information) and invite the developers (teams) to attend to your needs.
3. There is no 3.

At least the execrable, and totally misinformed, recent McKinsey article “Yes, you can measure software developer productivity” has us all talking about “developer productivity”. Not that that’s a useful topic for discussion, btw – see “The Systemic Nature of Productivity”, below. Even talking about “development productivity” i.e., of the whole development department would have systems thinkers like Goldratt spinning in his grave.

The Systemic Nature of Productivity

Productivity doesn’t exist in a vacuum; it’s a manifestation of the system in which work occurs. This perspective aligns with W. Edwards Deming’s principle that 95% of the performance of an organisation is attributable to the system, and only 5% to the individual. McKinsey’s article, advocating for specific metrics to measure software developer productivity, overlooks this critical context, invalidating its recommendations from the outset.

Why McKinsey’s Metrics Miss the Mark

Quantitative Tunnel Vision

McKinsey’s emphasis on metrics ignores the complex web of factors that actually contribute to productivity. This narrow focus can lead to counterproductive behaviours.

The Dangers of Misalignment

Metrics should align with what truly matters in software development. By prioritising the wrong metrics, McKinsey’s approach risks incentivising behaviours that don’t necessarily add value to the project or align with organisational goals.

Predicated on Fallacies

McKinsey’s suggestions are riddled with fallacious assumptions, including:

• Benchmarking – long discredited.
• Contribution Analysis – focused on individuals. Music to the ears of traditional management but oh so wrong-headed.
• Talent – See, for example,  Demings 95/5 for the whole fallacious belief in “talent” as a concept.
• Measuring productivity (measure it, and productivity will go down).

The Real Measure: Needs Attended To and Needs Met

The Essence of Software Development

The core purpose of business – and thus of software development – is to meet stakeholders’ needs. Therefore, have the most relevant metrics centre on these factors: How many stakeholders’ needs have been identified? How many have been and are being attended-to? How many have been successfully met? These metrics encapsulate the real value generated by a development team – as an integrated part of the business as a whole. (See also: The Needsscape).

Beyond the Code

Evaluating how well needs are attended to and met requires a focused approach. It includes understanding stakeholders’ requirements, effective collaboration within and across teams and departments, and the delivery of functional, useful solutions. (Maybe not even software – see: #NoSoftware).

Deming’s 95/5 Principle: The Elephant in the Room

The System Sets the Stage

Ignoring the role of the system in productivity is like discussing climate change without mentioning the Sun. Deming’s 95/5 principle suggests that if you want to change productivity, you need to focus on improving the system, not measuring individuals, or even teams, within it.

The Limitations of Non-Systemic Metrics

Individual metrics are the 5% of the iceberg above the water; the system—the culture, processes, and tools that comprise the working environment—is the 95% below. To truly understand productivity, we need metrics that evaluate the system as a whole, not just the tip of the iceberg. And the impact of the work (needs met), not the inputs, outputs or even outcomes.

The Overlooked Contrast: Collaborative Knowledge Work vs Traditional Work

McKinsey’s article advocates for yet more Management Monstrosities, where the category error of seeing CKW – collaborative knowledge work – as indistinct from traditional models of work, persists.

The Nature of the Work

Traditional work often involves repetitive, clearly defined tasks that lend themselves to straightforward metrics and assessments. Think of manufacturing jobs, where the number of units produced per time period or per resources committed can be a direct measure of productivity. Collaborative knowledge work, prevalent in fields like software development, is fundamentally different. It involves complex problem-solving, creativity, and the generation of new ideas, often requiring deep collaboration among team members.

Metrics Fall Short

The metrics that work well for traditional jobs are ill-suited for collaborative knowledge work. In software development, such metrics can be misleading. The real value lies in innovation, problem-solving, and above all meeting stakeholders’ needs.

The Role of Team Dynamics

In traditional work settings, an individual often has a clear, isolated set of responsibilities. In contrast, collaborative knowledge work is highly interdependent. This complexity makes individual performance metrics not just inadequate but potentially damaging, as they can undermine the collaborative ethos needed for the team to succeed.

The Importance of Systemic Factors

The system in which work takes place plays a more significant role in collaborative knowledge work than in traditional roles. Factors like communication channels, decision-making processes, and company culture (shared assumptions and beliefs) can profoundly impact productivity. This aligns with Deming’s 95/5 principle, reinforcing the need for a systemic view of productivity.

Beyond Output: The Value of Intellectual Contributions

Collaborative knowledge work often results in intangible assets like intellectual property, improved ways of working, or enhanced team capabilities. These don’t lend themselves to simple metrics like ‘units produced’ but are critical for long-term success. Ignoring these factors, as traditional productivity metrics tend to do, gives an incomplete and potentially misleading picture of productivity.

A Paradigm Shift is Needed

The nature of collaborative knowledge work demands a different lens through which to evaluate productivity. A shift away from traditional metrics towards more needs-based measures is necessary to accurately capture productivity in modern work environments.

Quality and Productivity: Two Sides of the Same Coin

The Inextricable Link

Discussing productivity in isolation misses a crucial aspect of software development: quality. Quality doesn’t just co-exist with productivity; it fundamentally informs it. High-quality work means less rework, fewer bugs, and, ultimately, a quicker and more effective delivery-to-market approach.

Misguided Metrics Undermine Quality

When metrics focus solely on outputs they can inadvertently undermine quality. For example, rushing to complete tasks can lead to poor design choices, technical debt, and an increase in bugs, which will require more time to fix later on. This creates a false sense of productivity while compromising quality.

Quality as a Measure of User Needs Met

If we accept that the ultimate metric for productivity is “needs met,” then quality becomes a key component of that equation. Meeting a user’s needs doesn’t just mean delivering a feature quickly; it means delivering a feature that works reliably, is easy to use, and solves the user’s problem effectively. In other words, quality is a precondition for truly meeting needs.

A Systemic Approach to Quality and Productivity

Returning to Deming’s 95/5 principle, both quality and productivity are largely influenced by the system in which developers work. A system that prioritises quality will naturally lead to higher productivity, as fewer resources are wasted on fixing errors or making revisions. By the same token, systemic issues that hinder quality will have a deleterious effect on productivity.

Summary: A Call for Better Metrics

Metrics aren’t the problem; it’s the choice of metrics that McKinsey advocates that demands reconsideration. By focusing on “needs attended to” and “needs met,” and by acknowledging the vital role of the system, organisations can develop a more accurate, meaningful understanding of holistic productivity, and the role of software development therein.Let’s avoid the honey trap of measuring what’s easy to measure, rather than what matters.

Afterword

As with so much of McKinsey’s tripe, the headline contains a grain of truth – “Yes, you can measure software developer productivity”. But the nitty-gritty of the article is just so much toxic misinformation. Many managers will seize on it anyway. Caveat emptor!

Many software folks pay lip service to Bill Deming and his work. Few if any pay any attention to the implications. Let’s break the mould and dive into how the great man himself might look at software developer productivity (a subset of collaborative knowledge worker productivity more generally).

This isn’t just a thought experiment; it’s an invitation to rethink our existing assumptions and beliefs about productivity.

Why Traditional Metrics Don’t Cut It

If Deming could peer over our shoulders, he’d likely be aghast at our fascination with shallow metrics. Lines of code? Bugs fixed? DORA? SPACE? These are mere surface ripples that fail to delve into the depths of what truly constitutes productivity. Deming was a systems thinker, and he’d want us to look at productivity as an outcome of a complex system. It’s influenced by everything from the quality of management practices to the clarity of project goals, and yes, even the standard of the coffee in the break room.

Aside 1

Let’s not get too hung up on staff productivity and the measurement thereof.

Deming’s First Theorem states that:

“Nobody gives a hoot about profits.”

A corollary might be:

“Nobody gives a hoot about software developer productivity.”

Which, drawing on my 50+ years experience in the software business, rings exceedingly true. Despite all the regular hoo-hah about productivity. Cf. Argyris and espoused theory vs theory in action.

Aside 2

While we’ve on the subject of measurment, let’s recognise that measuments will only be valid and useful when specified by and collected by the folks doing the work. I’ve written about this before, for example in my 2012 post “Just Two Questions“.

Aside 3

Let’s remember that the system (the way the work works) accounts for some 95% of an individual’s productivity. Leaving just 5% that’s a consequence of an individual’s talents and efforts. This makes it clear that attempting to measure individual productivity, or even team productivity, is a fool’s errand of the first order.

Here’s the Deming Approach

So, how would the statistician go about this? Hold on to your hats, because we’re diving into an eight-step process that marries statistical rigour with psychology and humanistic care.

1. Understand the System

First things first, get to grips with the holistic view. Understand how a line of code travels from a developer’s brain to the customer. This involves understanding the various elements in the software development lifecycle and how they interact.

2. Define Objectives

Random metrics serve no one. Deming would urge us to link productivity measurements to broader business objectives. What’s the end game? Is it faster delivery, better quality, or increased customer satisfaction?

3. Involve the Team

The people on the ‘shop floor’ have valuable insights. Deming would never neglect the developer’s perspective on productivity. Involving them in defining productivity criteria ensures buy-in and better data accuracy.

4. Data Collection

We’ve got our objectives and our team’s perspective. Now it’s time to roll up our sleeves and get to work on data collection. But this is Deming we’re talking about, so not just any data will do. The focus will be on meaningful metrics that align with the objectives we’ve set.

5. PDSA Cycle

Implementing the Plan-Do-Study-Act (PDSA) cycle, any changes aimed at boosting productivity would be introduced in small, incremental phases. These phases would be assessed for their effectiveness before either full implementation or going back to the drawing board.

6. Feedback Loops

You’ve made changes; now listen. Feedback from developers, who can offer a real-time response to whether the changes are working, is invaluable.

7. Regular Reviews

Productivity isn’t a static entity. It’s a dynamic component of a system that’s always in flux. Regular reviews help recalibrate the process and ensure it aligns with the ever-changing landscape.

8. Leadership Commitment

Finally, if you think increasing productivity is solely a developer’s job, think again. The leadership team must be as committed to this journey as the developers themselves. It’s a collective journey toward a common goal.

The Long Game

Deming never promised a quick fix. His was a long-term commitment to systemic improvement. But the fruits of such a commitment aren’t just increased productivity. You’re looking at more value for your business and greater satisfaction for both your developers and customers. So, let’s stop paying lip service to Deming and start actually embracing his philosophy. After all, a system is only as good as the assumptions and beliefs that shape it.

Introduction

In the world of product development, hiring for the right skills is paramount. Yet, hiring managers and HR people often fail to appreciate the necessary core skills, and thus certain crucial skills often go unsought, overshadowed by more flashy competencies or specific technical abilities. While technical expertise is a nice to have, ignoring these unappreciated skills can lead to teams and departments that lack cohesion, struggle with efficiency, and miss out on a broader understanding of the development landscape.

Top Ten Overlooked Skills and Their Consequences

Conclusion

To create a well-rounded and effective software development team, hiring managers migh choose to look beyond just technical proficiencies. By recognising and valuing these often-unappreciated skills, companies can increase the likelihood of building and maintaining cohesive, efficient, and innovative teams equipped to tackle the multi-faceted challenges of modern product development.

As the product development landscape continues to evolve, sadly, appreciation of the essential skills required to navigate it does not. Is it yet time to give these unappreciated competencies the recognition they deserve in the hiring process and beyond?

Offer

If your organisation suffers from any of the maladies listed under “consequences” in the table above, get in touch today for clear, independent advice on steps you can take to tackle the skills shortfall: bob.marshall@fallingblossoms.com

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

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

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

Foster a Culture of Ownership

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

Value Collective Intelligence

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

Encourage Continuous Learning

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

Promote Transparency and Trust

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

Equip Your Team

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

Summary

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

Further Reading

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

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

In the fast-paced world of product development, time is often considered the most valuable asset. The need to bring products to market faster has given rise to a growing emphasis on development velocity. Companies are investing in tools, methods, and practices to make their development cycles shorter. But is engineering velocity – speed in a given direction – really the panacea it’s often made out to be? Is it even a valid metric? Let’s take a closer look.

What is Engineering Velocity?

Engineering velocity refers to the speed at which a product team completes work items, such as features, bug fixes, or other deliverables. It’s often measured in terms of story points, completed deliverables, or other similar units within a given time frame.

The intention behind tracking this metric is clear: it’s a way to quantify progress and, ostensibly, efficiency. However, the pursuit of velocity for its own sake can lead to some serious pitfalls.

The Fallacy of Velocity as a Metric

Velocity as a metric has many shortcomings that make it not only pointless but sometimes even detrimental when it comes to product development.

1. Quality vs. Quantity: By focusing solely on the speed of development, there’s a real danger that quality can suffer. Cutting corners to increase velocity may lead to more bugs, technical debt, and products that don’t meet the needs of the Folks That Matter.
2. Misleading Measurement: Velocity is often tracked using arbitrary units, like story points, which can vary greatly between teams and even within a single team over time. This lack of standardisation makes velocity an unreliable metric for comparison or prediction.
3. False Sense of Progress: High velocity may give a sense of progress, but it doesn’t necessarily mean that the right things are being built. Teams may rush to complete tasks that don’t align with strategic goals or the needs of the Folks That Matter, leading to wasted effort and resources.
4. Impact on Team Morale: Emphasising velocity may lead to unnecessary pressure and stress within product teams, affecting collaboration and creativity. This can result in burnout and ultimately slow down the delivery process.

An Alternative Approach: Needs over Velocity

The key to successful product development isn’t necessarily moving faster; it’s moving smarter. Here’s what organisations might choose to do instead:

• Focus on the Needs of the Folks That Matter: Prioritise features and deliverables that best attend to the needs of the Folks That Matter. Regularly gather feedback from these consitituencies to ensure that development efforts are aligned with folks’ real-world needs.
• Emphasise Quality: Building quality products will lead to satisfaction and loyalty. Invest in e.g. ZeeDee and continuous improvement to ensure that quality is never sacrificed for speed. (Interestlingly, it’s a little appreciated fact that speed increases in proportion to improvements in quality).
• Leverage Self-organisation: Implementing Auftragstaktik-derived practices can help teams adapt quickly to changing requirements and focus on delivering value incrementally. Emphasising collaboration, adaptability, trust, and continuous improvement can lead to accelerated product development and delivery.
• Encourage a Healthy Culture: Foster an environment where team members feel supported and empowered. Recognise that creativity and innovation often take time and wilt under an overbearing stress on speed.

Conclusion

Engineering velocity might seem like a logical solution for bringing products to market faster, but it’s not a one-size-fits-all metric. In many cases, it’s misleading, counterproductive, and even harmful. Instead, companies might choose the smarter path:focusing on attending t folks’ needs, delivering value, ensuring quality, embracing adaptability, and building a positive team culture. By adopting these principles, organisations can develop products that not only reach the market more quickly but also resonate with the Folks That Matter, stand the test of time, and ultimately contribute to long-term success.

The business world is captivated by talent – an intoxicating attribute that often eclipses other factors. Many leaders believe that by hiring the most talented individuals, they will invariably achieve superior results. This notion, however, can be more delusional than it appears, particularly when viewed through the lens of W. Edwards Deming’s principles and systems thinking.

Deming, a renowned statistician, professor, author, and consultant, is best known for his groundbreaking work in improving production in Japan after World War II. His philosophy champions a systems perspective, emphasising processes, statistical variability, and the importance of culture in an organisation’s performance.

Talent – A Double-Edged Sword

As Deming and systems thinkers would argue, the excessive focus on talent can be misleading, obscuring the importance of organisational systems and culture.

There is a propensity in business to attribute success or failure solely to individual effort and capability, neglecting the critical role of the system within which these individuals operate. When an employee underperforms, it is easy to lay the blame on their lack of talent, rather than investigate systemic issues that may have caused the underperformance. Conversely, when an individual excels, it is tempting to credit their talent alone, ignoring how the system may have enabled their success.

This overemphasis on talent perpetuates what Deming dubbed the “prevailing style of management,” which involves managing by results or objectives, rather than focusing on improving the system. Such an approach can lead to short-term gains but overlooks long-term stability and sustainable growth.

The Power of Systems Thinking

Deming’s philosophy and systems thinking suggest a more holistic approach to understanding performance within organisations. It shifts the focus from individuals (and their talent) to the interconnectedness of components within an organisation, and to the power of interpersonal relationships.

Under this perspective, businesses are viewed as systems composed of interconnected processes. Here, a team’s performance isn’t merely the sum of individual talents; instead, it’s the result of interactions among team members, internal procedures, management practices, and the overall corporate culture.

A systems thinking approach emphasises that most problems and most possibilities for improvement lie in the system, not the individual parts (or talent). It’s estimated that about 94% of performance results from the system, leaving only about 6% attributable to individuals. This insight is a paradigm shift away from our intuitive, but delusional, individual-focused view of performance.

Building Better Business Systems

Recognising the power of systems over individual talent, how should businesses adapt?

Firstly, it’s critical to identify, understand, and improve the systems within which employees work. Rather than overemphasising talent recruitment, focus on the environment that enables or hinders their success.

Secondly, invest in training and development. In Deming’s view, education and continual training are critical to building better systems. Encourage an organisational culture where employees understand and appreciate the systems within which they operate.

Lastly, maintain a focus on continual improvement. Remember that most of the room for improvement lies within the system itself. Foster an environment that encourages questioning, rethinking, and overhauling systems as needed.

Conclusion

Obsession with talent should not distract businesses from the fundamental truth that systems and processes are the primary drivers of performance. Embracing Deming’s philosophy and systems thinking offers a more comprehensive, accurate, and ultimately effective path to long-term business success. Remember, a superstar employee might bring temporary success, but a superb system will bring sustainable growth.

In the demanding sphere of business organisations, a challenging dichotomy frequently arises between tackling the daily workload and engaging in dialogues about making the work work better. Both aspects are equally crucial for an organisation’s growth and development, but striking the right balance often presents a conundrum.

Daily tasks and responsibilities are the lifeblood of any business. They drive the operational efficiency and directly impact the bottom line. However, being caught in the ceaseless whirlwind of daily tasks can easily create tunnel vision, where the broader perspective of considering the way the work works for increased effectiveness gets lost.

On the other hand, conversations about improving the “way the work works” are essential for progress. These dialogues include brainstorming sessions, team meetings, offsites, and discussions around process improvement, optimisation, and innovation. They provide an opportunity for identifying bottlenecks, tackling problems, and integrating more effective strategies. But if these dialogues dominate the schedule, the urgency of daily tasks can get sidelined, affecting the immediate productivity.

The key to balancing this conundrum lies in – paradoxically – regular dialogues about where the balance presently lies, and where it would best lie. Folks can choose to make time for such discussions on balance without hampering the daily workflow. This can involve setting aside dedicated times for such conversations, or integrating feedback and improvement processes within the daily work routines.

Organisations that manage to master this delicate equilibrium not only stay on top of their day-to-day operations but also continually enhance the way their work works, leading to a long-term, sustainable success.

Has the thought ever crossed your mind that you could be wrong, just plain wrong, about the whole Agile thing?

Ever found yourself musing on a quiet afternoon, over a comforting cuppa, if there’s a smidgeon of possibility you could be mistaken about Agile? That perhaps, despite all the hubbub, Agile wasn’t as marvellous an idea as you’ve pegged it to be?

As an observer now on the outside of your community, I can’t help but wonder at the sheer dedication with which you all have embraced Agile. However, every coin has two sides, and it’s not in anyone’s interest to overlook the flip side, is it?

There’s no shame in contemplating that members of the Agile community might’ve got it all arse about face. After all, progress lies not in being unerringly correct, but in learning from our miscalculations and adapting accordingly?

Feel free to comment your thoughts below or reach out privately if this little question has ever tickled your curiosity.

Here’s to open dialogue and continued learning!

Lewin’s Equation

Lewin’s equation,

B=f(P,E)

suggests that behaviour (B) is a function (f) of the person (P) in their environment (E). This equation represents a pioneering leap in psychology, introducing a framework that doesn’t solely focus on either the individual or the environment, but instead recognises the interaction between the two.

Systems Thinking

Systems thinking, on the other hand, is a holistic approach to analysis, emphasising how a system’s constituent parts interrelate and how systems work over time within the context of larger systems. It’s about understanding a system by examining the linkages and interactions between the components that comprise the entirety of the system.

Intertwined

Let’s consider how Lewin’s equation and systems thinking might intertwine. Lewin’s equation encapsulates the essence of a systems perspective. It embraces the interaction of personal and environmental factors, acknowledging that behaviour isn’t static, but rather dynamic and context-dependent. In other words, it reflects the key principle of systems thinking: the whole is more than the sum of its parts.

Lewin’s equation can be seen as a precursor to systems thinking in behavioural sciences, as it articulates a similar concept—that individual elements in a system can’t be evaluated in isolation. Just as in systems thinking, where system behaviour can’t be understood by analysing individual components alone, in Lewin’s equation, behaviour can’t be fully understood without considering both the person and their environment.

Moreover, the systems thinking approach expands on Lewin’s equation by emphasising the importance of understanding feedback loops and the time dimension, which Lewin’s model doesn’t explicitly incorporate. Systems thinking suggests that feedback within the system (which could be a person’s environment in Lewin’s equation) can alter the person and thus their behaviour over time.

Overall, combining Lewin’s equation with systems thinking provides a more holistic, dynamic and interrelated view of human behaviour. This combination encourages the consideration of multiple factors and their interactions, enhancing our understanding of how behaviour emerges from the complex interplay of a person and their environment.

The New Lewin Equation

So, systems thinkers, and Deming, Scholtes fans, might choose to rewrite Lewin’s equation as

p=f(5P,95S):

individual performance (p) is a function of 5% the abilities of the individual person (P) and 95% the nature of the system (S) – the way the work works – within which the person must perform.

Everyone in the software industry (managers excepted) knows the following is true, yet nobody wants to talk about it:

Effective software development is entirely incompatible with typical (hierarchical, command-and-control) management.

After 50 years in the industry, I’d go so far as to say:

Effective software development is entirely incompatible with ANY known form of management.

Corollary

Place managers in charge of software development and it can NEVER be ANYTHING but ineffective (high costs, low quality, poor due date performance, lack of innovation, etc.).

NB Applies more broadly, beyond the domain of software development, too.

Reasons

The reasons for this incompatibility can be explained as follows:

1. Creativity and innovation: Software development is a highly creative and innovative process that often requires developers to think out of the box, experiment, and come up with novel solutions. A hierarchical management structure stifles creativity and inhibits the free flow of ideas, emphasising, as it does, strict adherence to rules and policies.

2. Responsiveness and flexibility: In the rapidly changing world of technology, software development teams need to be responsive and adaptable in order to respond quickly to changes in requirements, market conditions, approaches, and user feedback. A command-and-control management style, which relies on rigid plans and mandated approaches, tools, makes it difficult to impossible for teams to pivot and adapt as needed.

3. Collaboration and communication: Effective software development relies on close collaboration and communication among team members with diverse skills and expertise. Hierarchical management structures create barriers to communication, with information flowing primarily up and down the chain of command, rather than freely among team members.

4. Autonomy and motivation: Software developers tend to be highly skilled, motivated individuals who thrive on autonomy and the ability to make decisions about their work. Command-and-control management undermines their motivation by imposing external control and limiting their decision-making authority.

The broader point being made in the corollary statement is that traditional hierarchical management is never the best fit for software development, and that organisations might choose to consider alternative organisational styles and structures that are more conducive to the unique demands of software development.

This idea can indeed apply beyond the domain of software development, as many industries are increasingly recognising the need for more responsive, collaborative, and flexible management approaches to drive innovation and adapt to rapidly changing environments.

Are you tired of relying on the idea of “management” as the default solution to organisational problems?

The strong inclination towards management as a solution for organisational problems can be influenced by bias in a variety of ways. These include:

• Cultural bias: Western cultures tend to place a high value on individual achievement and personal success, which can lead to a focus on hierarchical management structures as a means of exerting control and achieving results.
• Confirmation bias: Organisations and individuals may be predisposed to seeing management as the solution to problems, leading them to selectively seek out and interpret information that supports this view.
• Limited perspectives: Management can be seen as the default solution for organisational problems due to a lack of consideration or awareness of alternative approaches or perspectives.
• Financial incentives: Financial incentives can create a bias towards management as a solution, particularly among those who stand to benefit financially from its implementation.
• Management industry: The management industry has a vested interest in promoting management as the solution to organisational problems, which can create a bias towards this approach.

Upton Sinclair’s dictum,

“It is difficult to get a man to understand something, when his salary depends on his not understanding it,”

is particularly relevant in this context. Financial incentives and the influence of the management industry can create a powerful bias towards management as a solution for organisational problems, particularly when individuals stand to benefit financially from its implementation.

To address bias towards management as a solution, it is important to maintain an open mind, seek out diverse perspectives, and evaluate potential solutions based on their effectiveness rather than defaulting to a particular approach. This may involve exploring alternative management styles, such as servant leadership, or considering other approaches to addressing organisational challenges, such as self-organising teams, #Fellowship, and #NoManagement.

By remaining open to new ideas and approaches, organisations can avoid the limitations imposed by bias and better address their challenges and opportunities.

Need to unlock your team’s full potential and supercharge your software development process? Uncover the game-changing strategy behind embracing “Not Everybody Matters”, and learn how mastering the Needsscape and understanding the Cost of Focus can catapult your project to success!

In the world of software, service and product development, catering to every stakeholder’s needs can be both challenging and resource-intensive.

Embracing the idea that “Not Everybody Matters” can lead to more effective development processes by prioritising the most critical needs and stakeholders. By focusing on the essential elements of a project, teams can allocate resources more effectively and reduce development time.

The Needsscape
The Needsscape is a concept that helps identify and dynamically prioritise the needs of various stakeholders. By carefully tracking the Needsscape, development teams can determine which needs have the most significant impact at any given moment, and align their efforts accordingly. This approach acknowledges that not all needs are equally important, and allocating resources to meet every need regardless of relative impact leads to increased costs and inefficiencies.

The Cost of Focus
The Cost of Focus is the trade-off that occurs when concentrating on one are over another. By acknowledging that “Not Everybody Matters,” development teams can make informed decisions about where to invest their time, effort, and resources. This approach might involve prioritising features that have the highest value for the majority of users or focusing on the needs of specific subsets of the audience.

The concept of “Not Everybody Matters” in software development is a bold approach that encourages teams to prioritise the most critical needs and stakeholders by leveraging the Needsscape and understanding the Cost of Focus. By doing so, they can streamline the development process, maximise the value delivered, and ultimately create more successful software products.