đŸȘŽ Quartz 4.0

Invitation to Engineering Organization Theory

Sep 16, 20185 min read

image

  • Invitation to engineering [organization theory

    • Refactoring thinking and organization to face uncertainty
    • Technical Debt

  • Amazon

  • The title sounded interesting, so I made a note of it anyway (6/12).

  • I had heard rumors that it was a good book, but I hadn’t had much interest in reading it, probably because I had little interest in “organizational theory. I became interested in the book when I heard that there was something in the opening chapter that was useful for mentoring. - mentor I guess business is also organizational theory.

    • An organization connected by a relationship that is not a boss-subordinate relationship

  • 1-1 All Bugs Are in the Thinking

  • 1-2 Uncertainty and Engineering

    • Engineering Meaning
    • Consider the beginning and the end
    • Uncertainty cone in the project
    • Organizational Structure and Uncertainty Flow
    • Uncertainty and Information
    • Sources of Uncertainty
    • Generating information

  • 1-3 Concept of generating information

    • Three differences between work and academic tests
    • Converting work problems into academic test questions
    • 3 thoughts and software development

  • 1-4 Blind Spot in Logical Thinking

    • Logical thinking and two assumptions
    • For humans to think correctly and logically
    • Not thinking illogically = thinking logically
    • People cannot correctly perceive facts.
    • Four of Bacon’s idol (esp. in philosophy).
    • cognitive distortion
    • Control the amygdala.
    • Know the scope of your identity.
    • Convey “anger” as “sadness.”
    • Problem recognition is more difficult than problem solving.

  • 1-5 empiricism and hypothetical thinking

    • The only way to know what you don’t know is to find out.
    • Uncertainty and Summer Homework
    • Professional Work
    • What you can control/what you cannot control
    • What can be observed/what cannot be observed
    • What you can do
    • Think boldly with little information .
    • Misconceptions of data-driven decision making
    • Clarifying problems is more difficult than solving them.

  • 1-6 Holistic and systems thinking

    • A system is about capturing the relationship of the whole.
    • Conflict arises when you only see parts of the picture.
    • Cognitive Range and Systems Thinking
    • Finding problems is more difficult than solving them.

  • 1-7 Accept human imperfection

    • Communication Uncertainty
    • Fable of Curry Making
    • Reducing Uncertainty and Creating Order
    • Chapter 2 mentoring techniques

  • 2-1 Refactoring the other party’s thoughts with [mentoring

    • History of Mentoring
    • Mentoring and Engineering Relationships
    • Techniques for “creating human resources who think for themselves
    • Effective mentor/mentee relationship
    • From “persuasion by others” to “self-persuasion”
    • Difference between “worrying” and “thinking

  • 2-2 listening closely ・ visualization (data, results, etc.) ・ reframing

    • Converting unsolvable puzzles
    • Only an empty glass can hold water.
    • Difference between “listening” and “just listening
      • empathy to get a “signal” to listen to what they have to say.
    • Visualization” and “clarification” of the problem

  • 2-3 How to make [psychological safety

  • 2-4 Focus on actions, not inner thoughts

    • We cannot see their innermost thoughts, but we can see their actions.
    • SMART behaviorSMART_criteria
    • Do you understand?” is a meaningless word.
    • Ability is the integral of habit; habit is the integral of action
    • Why can’t we take action?
    • Ride the Time Machine to the Finish Line
    • Chapter 3 Principles of Agile Teams

  • 3-1 agile is a technology for mentoring teams

    • Agile Development Penetration Rates in Japan and Worldwide
    • The number of agile practitioners is far fewer in Japan
    • Two reasons why agile development was needed
    • Agile development is 3 times more successful, 1/3 the failure rate
    • Project and Product Management
    • Don’t Be Agile, Be Agile
    • Waterfall or Agile?

  • 3-2 History of Agile

    • Agile Development is a Management Science
    • From Production System to Knowledge Management
    • Development of life sciences and their influx into social sciences
    • Hacker Culture and Admiration for Eastern Thought
    • lightweight software development process
    • Agile Software Development Declaration
    • Three key points in the history of Agile

  • 3-3 Misconceptions about Agile

    • 5 Misconceptions about Agile
    • Why Agile is misunderstood

  • 3-4　 Agile Ratings

    • Agile” is the ideal state.
    • Agile Methodology
    • Agile development is “[deconstruction (as in the term coined by Jacques Derrida)

  • Chapter 4 Learning Teams and Uncertainty Management

  • 4-1 How to manage uncertainty

    • Uncertainty Management

  • 4-2 Schedule Forecasting and Uncertainty

    • Basics of Schedule Management
    • Pessimistic and Optimistic Estimates
    • Visualization” of schedule anxiety
    • Forecast from actuals, not plans
    • Requirement Granularity and Uncertainty
    • Schedule anxiety can be controlled.

  • 4-3 How to make demands and market instability - schedule conflict and symmetry of market instability

    • When can market instability be reduced?

  • 4-4 Reflection on facing scrum and anxiety

    • Scrum as a Framework for Facing Anxiety
    • Where to go and how to look back
    • Knowing Insecurity and Gaining Team Mastery

  • Chapter 5: Technical Organization Dynamics and Architecture

  • 5-1 What Reduces “Productivity” in Technical Organizations?

    • Difficulty with the term “productivity
    • Ability of the organization to process information
    • Relationship between the organization and the system
    • How can we improve the information processing capacity of engineering organizations?

  • 5-2 empowerment and accountability

    • Organization and Authority
    • Authority and Uncertainty
    • Levels of delegation of authority and delegation poker.
    • Conflict of Authority
    • Authority and organizational design

  • 5-3 Identity of [technical debt

    • The Debate over Technical Debt
    • Classification for Communication
    • The Myth of the Quick and Dirty
    • Technical liabilities “cannot be seen.”
    • Expression by difference from additional man-hours in ideal system
    • Not a “technical debt” if you can see it.
    • Shedding Light on Technical Liabilities

  • 5-4 Transaction costs and technical organization

    • Transaction Cost Theory
    • hold-up problem
    • Architecture and Outsourcing Management
    • In-house transaction costs
    • Importance of cross-functional teams

  • 5-5 Goal Management and Transparency

    • Misunderstood Goal Management
    • Self-control that has slipped away
    • Transparency of goals through [OKR
    • Transparency and Disclosure

  • 5-6 Organizational Design and Architecture

    • Transaction Costs and Architecture
    • Operation Inverse Conway (nuclear reactor)
    • microservices architecture
    • Difficulty in timing of microservices conversion
    • Engineering Company

This page is auto-translated from /nishio/スンゾニケăƒȘăƒłă‚°ç”„çč”è«–ăžăźæ‹›ćŸ… using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. I’m very happy to spread my thought to non-Japanese readers.

Graph View

Backlinks

  • No backlinks found