"Why is this system so complex?"

The most common answer to this is pretty simple. Building systems as a series of loosely-connected steps creates complexity. The often well-thought-out step implementations failed to consider their place in the overall system design. More times than not, this is a direct result of aggressive deadlines.

When working in these systems, it's essential to recognize the external influences that could have forced a shortcut delivery. Try to separate the implementation details and the intended outcome. Poor execution makes it easy to get distracted, but this only slows down the improvement work. Besides, complaining doesn't help anything.

For even more fun, take multiple complex systems and get them to work together; a common scenario in mergers and acquisitions. This environment typically fosters conflict between teams and an increase in siloed behavior.

It's best to remember that the makers didn't set out to deliver complexity; complexity is a side-effect of other factors. Focus on the intention.

Strongly consider refactoring or creating system bridges before diving into a rewrite. The odds that you'll end up reintroducing bugs are pretty high.

being present

How often are you in a meeting and hear someone say, "Can you repeat that?"

Well, if they were present, no repetition would be necessary. Multitasking in a meeting is not respecting everyone else's time. The team will get more out of the time if people are focused. The email or chat can wait.

If only a few people consistently act this way, don't blame the schedule. The issue most likely lies in their discipline. However, if you see multiple people not paying attention, a review of the meetings and their purpose is probably due. They most likely feel it's the only way to get everything done.

go workspaces

With the release of Go 1.18, Workspaces allows you to reference local copies of project imports.

Workspaces are convenient when your projects share common dependencies.

Instead of pushing up code to get a new commit hash reference for your import, you can now reference your local copy.

This new ability has simplified development a lot for this scenario.

Thank you to the Go team for delivering such a helpful development capability.

example file:

go 1.18

use .

replace v1.0.1 => ../mylib

team i/o

Team I/O is a way to organize teams by the information consumed and produced. 

For as long as this post is, it's still only a brain dump that needs refinement.

Proceed with caution.

Roles and responsibilities are common ways to document but fall short in context. Roles are generally generic titles found on job posting sites, and like roles, identical responsibilities are present in multiple teams. 

The thought behind Team I/O is to give context on how people fit into the business process and how they contribute. 

Maybe "information" isn't the right word for "information consumed and produced," but we are running with that term for now.

To give more context, below are examples of information. 

  • Meetings
  • Calls 
  • Docs 
  • Diagrams 
  • Designs
  • Images
  • Code
  • Email
  • Issues

With the Team I/O concept, each team has defined input and output information. If we use cards to organize, it might look something like:‍

  • Team name
    •  Red Widget backend development
  •  Concern
    •  Rsponsible for the services powering the Red Widget UI
  •  Inputs
    •  Backlog grooming
    •  Sprint planning
    •  User Stories (Acceptance Criteria)
    •  User Story Comments
    •  Primary Slack channels
      •  #red-widget-support
      •  #red-widget-dev
      •  #red-widget-*
    •   Email
  •   Outputs
    •   Red Widget services software
    •   Automated tests
    •   User Story: create/edit/update
    •   User Story Comments
    •   Support via Slack primary channels
    •   Email for general company needs

Of course, most people aren't lucky enough to only have three Slack channels to follow.

This list should cover the channels people should expect a response in a reasonable timeframe.

When there are email groups that the team monitors, list them out; this way, people use the desired communication channels.

Now let's break down this card in a bit more detail.

Team Names

  • The name should convey the high-level responsibility of the team
    • [Product(s)] [function] team
      • Red Widget backend development
      • Yellow Widget marketing
      • Blue Widget product management
    • [company|division] [function]
      • Digital Widgets HR (company-wide)
      • European HR (a division)
      • Happy People Finance (company-wide)
  • Teams collaborating on the same goals have the same descriptors
    • Red Widget product management
    • Red Widget UX
    • Red Widget development
    • Red Widget marketing
  • If a team is responsible for multiple products, the company should have a name that describes the association
    • External product design
    • Internal product design
    • Payments development
    • External reports design
    • Reports design


  • The concern should detail this team's responsibility in the company. 
    • The external product design team is responsible for designing all customer-facing products.
    • Payments development provides payment functionality for all company applications.
    • The Red Widget product team is responsible for our Red Widget product's market research and strategy.


  • A bullet list of information sources for the team
    • External product design
      • product owner requirements
      • project management direction
      • user feedback
      • docs covering available functionality
      • ...
    • Payments development 
      • products owners requirements
      • project management direction
      • downstream systems owners
      • information security team guidelines
      • infrastructure team guidelines
      • ...
    • Outputs
      • A bullet list of information output of the team
        • Red widget backend development
          • code providing Red widget application functionality
          • Red widget application technical support
          • Red widget technical documentation
          • ...

meeting times

I like the concept of 25-minute and 50-minute meeting times; it gives people time between meetings to reset and take care of personal business. These times are great when the attendees know the subject matter well and can produce clear outcomes at the end.

However, when the meeting topic is exploratory, like planning, proposals, troubleshooting, or anything that benefits from focused thought beforehand, a 45-minute meeting is ideal.

The 45-minute meeting runs differently. The collective chat doesn't start until the 16th minute. The first 15-minutes is dedicated time for the individuals to prepare for the meeting.

With this meeting style, the invitation must have a well-defined subject and clear goals. I think this should be in all meeting invitations but is a prerequisite for the 15-minute focus time.‍

guiding principles

Brad Mohs and I worked on these principles for several weeks attempting to strike the right balance of terms and coverage of concerns.I’m quite happy where we landed on this, but I do expect this to evolve over time.

technology guiding principles

  • scalable: design and implement to be dynamically scaled
  • learnable: short time to meaningful contribution for new team members including: documentation needed for self motivated engagement
  • reliable: system continues to operate properly in the event of one or more component failures
  • recordable: data recorded to provide meaningful business metrics and playback
  • supportable: simple and quick to get from issue notification to identification to resolution
  • automated: Humans only do what computers can’t
  • testable: design for unit, functional, security and load testing
  • consumable: interfaces into our systems will be simple and intuitive

business guiding principles

  • secure: pci compliance and pii best practices
  • fast: systems. time to market. updates. bug fixes
  • serviceable: built to be used
  • evolvable: adapt, grow and create products/services as the business needs
  • malleable: products/services/outputs fit the varied needs of our customers/clients
  • observable: the business must know how our systems are performing: accurate sales reporting, insightful system monitoring and meaningful notification system
  • reviewable: ability to visually confirm before promoting to production. multi-tenant: single instance serves multiple tenants‍