I read 読書メモ『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』広木大地（著） (An Invitation to Engineering Organization Theory ~Thinking and Organizational Refactoring to Face Uncertainty by Hiroki Daichi), so I’ll share the insights I gained from the book.

Background: Recommended Reading for Managers

I had finished reading this about 4 years ago, but since it became a recommended book for managers within our company, I’ve decided to publish these reading notes now, albeit belatedly.

Impression: Essential Reading for All Business Professionals

Although the title “Engineering Organization Theory” might seem like a book for engineers, I think it’s essential reading for managers at companies with engineers. Ideally, I’d want all business professionals who have engineers as colleagues to read it.

Keywords

Here are search keywords for my reference:

• Misunderstanding of data-driven decision making
• Cone of uncertainty
• Curry making parable
• Agile
• Project management vs Product management
• Technical debt
• Conway's Law / Inverse Conway's Law
• Microservices

Below are quotes and notes from sections that left an impression on me.

Chapter 1: Refactoring Thinking

1-5. Empiricism and Hypothesis Thinking

■ Rationalism and Empiricism

Empiricism seeks the source of knowledge in “experience.” It caused a strong paradigm shift that knowledge can only be gained through conducting experiments or taking actions.

(omitted)

It’s hasty to interpret from past stories that “people in the past were foolish, but we aren’t now.” Even in modern times, and in the engineering world, “rationalistic” attitudes were considered common sense until just a few years ago. Processes that stood on the premise that software could be built systematically through reason without being based on actual experience were “design-oriented processes” like waterfall. In contrast, software development methodologies like Scrum, which are becoming mainstream in recent years, are called “empirical processes.” The Scrum Guide mentions empiricism as follows:

? Waterfall = Design-oriented process Scrum = Empirical process

Misunderstanding Data-Driven Decision Making

Sadly, there seems to be much misunderstanding about “data-driven decision making.” The misconception is that if you have large amounts of data, you can understand the correct action to take next. In reality, data is always incomplete, and decisions cannot be derived from it.

“Data-driven decision making” is effective in: • Visualizing available data to infer “hypotheses” • Statistically validating whether “hypotheses” were correct

It’s not about being able to derive answers deterministically through deductive or inductive reasoning from data. Therefore, what’s important is to boldly infer customer insights and hypotheses from limited data and take actions to verify the uncertainty of whether they’re correct.

1-7. Accepting Human Imperfection

■ Information Asymmetry

Information asymmetry is a state where one person in a group with the same purpose knows some information while another doesn’t. For example, a boss knows information that subordinates don’t, or conversely, the field knows information that management doesn’t.

Also, since people cannot accurately convey what they’re thinking to others, information asymmetry emerges even when they think they’re transmitting information. While information asymmetry is natural, people often mistakenly act based on assumptions that others should know their situation, or based on the wish that they should know. There’s a saying called “Hanlon’s Razor”:

Never attribute to malice that which is adequately explained by incompetence (Robert J. Hanlon)

As this adage shows, even when problems are caused by imperfect information transmission between people, humans tend to find malice or ill intent in it.

Chapter 3: Principles of Agile Teams

3-1. Agile as Team Mentoring Technology

Two Reasons Why Agile Development Was Needed There are two reasons why "agile development" was needed in software development: "software became large-scale and complex" and the necessity to "respond to market uncertainty" emerged.

Project Management vs Product Management

■ The Meaning of ○○ Management (omitted) Projects have “beginning” and “end,” and their purpose is to “finish” effectively. In contrast, products are “goods/services,” so the purpose is for the product to continuously generate revenue, exceed the break-even point and develop, meaning “not to end.”

3-3. Misunderstandings About Agile

Five Misunderstandings About Agile

■ Misunderstanding 1: Agile development is a fixed process ■ Misunderstanding 2: Agile development doesn't do design ■ Misunderstanding 3: Agile development requires excellent members ■ Misunderstanding 4: Agile development has no medium to long-term planning ■ Misunderstanding 5: Agile development is a method where developers have decision-making authority

3-4. Agile Maxims

"Agile" is an Ideal State The word agile refers to "a certain ideal state." That ideal state is "a state where the team adapts to the environment and most efficiently reduces uncertainty." This is also called self-organization. Since this state is ideal, it points to a high goal that can never be reached. To move toward this state, a certain "question" is posed to the team: "How can we reduce more uncertainty?"

Chapter 4: Learning Teams and Uncertainty Management

4-2. Schedule Prediction and Uncertainty

Pessimistic and Optimistic Estimates

■ Estimates and Agency Slack Estimates are predictions. However, when this prediction is treated as a “quota,” there’s a possibility it becomes a capability or evaluation issue when it can’t be achieved. Originally, if predictions don’t hit, there should be a problem with prediction accuracy, not with inability to complete work. The moment predictions become “quotas,” overloaded work is created to achieve them, and quality drops. Or schedule prediction accuracy keeps declining. To avoid this, engineers try to make defensive, pessimistic estimates next time.

4-3. How to Create Requirements and Market Anxiety

Symmetry of Schedule Anxiety and Market Anxiety

In time-bounded projects, project buffers are prepared before deadlines to prepare for time uncertainty. In contrast, feature-bounded projects prepare the difference between originally planned features and MVP to prepare for uncertainty. This is scope buffer. In realistic projects, buffers are prepared for both boundaries (time and features), and projects aim to land within the overlapping area. Time and features have a certain symmetry in this way.

Chapter 5: Dynamics and Architecture of Technical Organizations

5-1. What Reduces Technical Organization "Productivity"?

Once Visible, It's Not "Technical Debt" (omitted) Tasks comprising technical debt whose true nature has been revealed are generally called non-functional requirements. These are requirements arising from demands regarding performance, scalability, operability, etc., that don't affect surface functionality. In other words, technical debt is called technical debt precisely because it's "invisible." Once each piece becomes visible, it becomes manageable as a list of unfulfilled "non-functional requirements."

Shedding Light on Technical Debt Technical debt becomes problematic because it’s invisible. If you make it visible to management, it becomes manageable.

That’s all from the Gemba, where I want to practice engineering organization theory.