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

Concern

  • 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.

Inputs

  • 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
          • ...

You'll only receive email when they publish something new.

More from andy stone
All posts