Data Team in Clinical Org

01/27/2022 Compiled by Valmeek Kudesia; accumulated from experience

Culture

Team is 1st High Expectation Customer

• Acknowledge current state of healthcare system ➡ complex and unable to fully describe it's own complexity, therefore

  • Accept that extracted/derived user stories, requirements will always be incomplete

  • Team must have hybrid clinical + tech expertise ➡ have intrinsic sense of the system "how ought to be" or *could be*

  • How well our team understands holistic end-state, communicates, builds ➡ the simplifying power of our work vs "tech-enable" the broken

    • The nature of our team ➡ the nature of our work provided for clinicians

    • Virtuous cycle (easy, simplifies, perceptive) in team ➡ virtuous cycle for clinicians

• Our Team is a “learning place” ➡ learn, make mistakes, ask for help

• “Stand for each other” ➡ psychological safety ➡ high-performing-team

• Value freedom and responsibility over rigidity

High Value for Green Work

• Green Work" - want/ought to do

  • [[make-the-problem-obsolete]] ➡ reshape tomorrow

  • Help/teach teammate

  • Understand own work, team's work, big picture, how future could/ought to be

  • Simplify the work of our team

  • Maintain state of "low confusion" and "easy to know" for team

• Minimize yellow (must do, for now)

• Eliminate/automate red (ought NOT do)

Change Simplifies

• Change will always happen

• Use each change to find what can stay the same in solution

• Solve for change in way that optimizes what can stay the same for the next change thereby [[maximize-the-work-not-done]]

• Welcome system-wide design via insight through making that prompt redesign for simplification

Culture in Action

Own Our Time

• "Meetings" ≠ right work; sometimes right work needs "meetings"

• Evaluate new work as a team

  • Priority, green-ness, impact on teammates

  • Use new work ➡ move towards *how things ought to be*

  • Dedicate time for ([[learning-requires-metacognition]])

    • Thinking, working, learning, designing

    • Capture, describe work and actions

    • Communicate, plan, share knowledge

Employ the [[power-of-stop]]

• If confusion, collision, duplication, or opportunity (e.g. growth, simplification) ➡ stop to understand

• Stop to understand ➡ call on team ➡ define way forward (including stop doing something)

• Stop to traverse [[levels-of-perspective-and-action-modes]]

• Stop to understand (green work) ➡ shape facts of tomorrow (green work) ➡ lead change (green work)

Make Knowing Easy

• Heavily inspired by Gitlab Handbook

• Resist fragmentation: [[frenetic-pace-of-business-false-justification]]

• Optimize for easy self-service and easy self-learning; faster we know, the faster we choose wisely

  • Make easy to know who is doing what, why, waiting on whom

  • Capture and maintenance of knowledge is "always-on" requirement of every role

  • Strongly favor work-focused discussions, tasks, knowledge collection performed in view of whole team so that all can learn vs small group

    • If have question ➡ 1st check documentation; if answer not found or not available ➡ ask in public ➡ document answers or connect to existing answers to pay it forward

    • If answering question ➡ answer with a link to documentation; pays it forward

    • Say thanks in public

  • Team experience and product ➡ is more inclusive; significantly fewer interruptions ➡ more "flow", better designs ➡ more good work

How We Build and Create

• Be Transformative

  • Align actions and solution with how “things ought to be” vs “things are right now”

  • Lower the threshold for inclusion; within and external to the team

• Incrementalism Over Ad-Hoc

  • Learn everything about our stakeholders’ problems and what is useful

  • Incrementally meet needs on an-ongoing basis instead of ad-hoc

  • Make reversible decisions

  • Iterate deliberately

• Minimum Viable Change/Product/Growth Over POC

• Focus on what we can control; start with *something*

  • Start sooner, simpler with less ➡ learn sooner ➡ do better sooner

  • Strongly favor tangible, smaller solution focused on problem kernel that "aims" toward how "things ought to be" instead of more complete but theoretical elegant solution

  • See work/product in action, reflection to [[insight-through-making]]

  • Design for change, failure

  • First optimize for speed and results, then scale

• High Performance Small Team

  • No costly infrastructure/tooling; heavily favor open source

  • Operate with the minimum amount of resources; [[maximize-the-work-not-done]]