I recently completed the GitLab TeamOps training and certification. My notes are below, but the general gist is that TeamOps is the application of DevOps and product management principles to team and organizational dynamics.

TeamOps notes

core philosophy is everyone can contribute

empowers decentrailized decision making at centralized (organizational) level

principles

  1. shared reality - opimized for info retrieval; handbook-first mindset
  2. everyone contributes - create system for everyone to be able to contribute
  3. decision velocity - bias for action; success correlated with quantity of decisions made in given time; concensus is not the goal
  4. measurement clarity - measurement is critical to achievement

prerequisites

  1. communication guidelines
  2. shared set of values - core values documented, actionable, and reinforced in everything
  3. team trust -
  4. focus on results - measuring output; clear, transparent goals
  5. culture of belonging - inclusive environment, psychological safety

Shared Reality

low context communication - assume the person you’re communicating with has no background on the topic, provide all links and background needed to make an informed response.

low context communication should be

  • explicit
  • direct
  • simple
  • comprehensive

if decisions in a group appear ill-informed, audit the context expectations first

teamops requires transaparency about change and communication about both what is changing and why it is changing; this both supports the change and provides a knowledge base for future decision makers to understand why a change was made

situational leadership strategy - adapting leadership and communication style to match the individual situation and scenario

  • https://about.gitlab.com/blog/2021/11/19/situational-leadership-strategy/

bias for asynchronous communication supports inclusion and diversity

Everyone contributes

orgs must create systems to allow everyone to consume and contribute information

everyone can but everyone is not required to contribute; goal is not full agreement with decisions

using merge-requests as starting point for change allows asynch communication and reduced meetings

DRI - Directly Reponsible Individual; each project or decision assigned a single individual who is the ultimate decision maker

Key Review Meetings and Group Conversations

  • Key Review allow a functional group to provide read out of OKRs, KPI, achievements, etc to execs
  • Group Conversations are much the same but the audience is the company as a whole
  • https://about.gitlab.com/handbook/group-conversations/
  • https://about.gitlab.com/handbook/key-review/
  • for both meetings, no presentations are allowed; input is shared ahead of time and questions supplied back

decisions should be seen as two-way doors, easy to undo; reverting back is a positive step

disagree, commit, disagree - supported by two-way door thinking; removes time-limited aspect of other orgs’ “disagree and commit” policy

informal communication to build trust

  • provide asynch methods to get to know each other; like README’s

Decision velocity

success is correlated with decision velocity, evidenced by length of collaboration processes and accuracy of decisions resulting

collaboration codification - formalizaing the practices, standards, and expectations of how the organization collaborates; ties to prerequisite for communicaiton guidelines

push decisions to lowest possible level

  • decisions should be made by the person doing the work (the DRI)
  • supports agency and increases efficiency
  • aligns with fail-fast concept of agile

boring solutions

  • prefer the known and consistent over the new and innovative
  • Occam’s Razor
  • Minimum Viable Change

stable counterparts

cross-functional team members consistently work with the same person in the partner team

  • speeds decision making
  • establishes trust
  • supports stronger communication
  • e.g., a single HR person is assigned to cover a department
  • enchance cross-functional execution without downsides of matrix organization

collaboration not consensus

  • feedback should be documented transparently but DRI not required to accept, or even respond to, all feedback

only healthy constraints

- managers need to restrain the urge to be involved in every decision

- avoid putting in constraints, processes and approvals which aren't strictly necessary
- Gitlab's tactics to avoid unhealty constraints: https://about.gitlab.com/handbook/only-healthy-constraints/#resisting-unhealthy-constraints
    - "We put expiration dates on processes or decisions that are introduced in response to immediate needs or short-term issues."

Measurement clarity

  • measure productivity, value, and results without depending on physical supervision
  • objective measurement decreases bias and increases accountability

measurement transparency

  • KPIs and OKRs should have a symbiotic relationship; KPIs are smaller increments releated ot OKRs but not dependent upon them

  • KPIs for each function should be transparently shared across the organization

measure results not hours

  • don’t conflate efficiency and speed
  • success is based on outputs rather than inputs
  • results should include deliverables and non-deliverables like helping a teammate, revising documentation… anything that adds value to the “shared reality”

prioritize due dates over scope

  • due dates are required to force execution on decisions and accountability

  • if necessary, cut scope rather than moving the due date

iteration

  • do the smallest viable and valuable thing
  • applies to every process and decision
  • inculcate “low level of shame” to support making minimum viable changes (MVC) without fear of censure for something which is not perfect and refined
  • consider Iteration Office Hours, discussions of how to iterate in a given situation; see https://www.youtube.com/watch?v=2eA7-E950ps