README: [email protected]
This doc is a “manager README”: a guide to set expectations for new team members. The aim is to share mindset, style, preferences, and quirks. I’m still new to Microsoft and building a small team in “remote” Madison, WI. Foremost I’ll aim for transparency within the team and reflecting outward (to the community) and inward (to Microsoft).
I’m focused at the intersection of healthcare and technology – spurred by my own experience (and frustration) working in hospitals and clinics, and motivated by the belief that technology will change the way we maintain wellness and manage disease. Over the course of my career I’ve dug farther and farther “down the stack” to lay infrastructure that supports a better healthcare developer experience, with a focus on open protocols and standards for data, communication, and the integration of apps/tools/advice into clinical workflow. I tend to value designs that are 1) as simple as possible, 2) clever, and 3) build on real-world, working systems.
First, welcome! I’m so excited you’re on board – and we’ve got our work cut out for us :-)
Your job is to help us build better standards, explain how they work, and test them in the real world. You should expect a mix of engineering, product design, “customer” engagement across the health standards community (with a variety of stakeholders, who may or may not be Microsoft customers in a conventional sense).
We're growing out a new group from scratch. It’s a tremendous privilege, and a challenge. I'm exhilarated about the opportunity and will be asking for your help in recruiting and evaluating candidates (as part of a shared process with the broader team in Redmond). Over time we’ll explore differentiated roles and responsibilities; but as we get started, my bias is to share knowledge and responsibilities across the team rather than expecting individuals to sub-specialize in a single area. It really helps if anyone can pitch in or cover when someone else is unavailable.
Outward focus; working with “the community”. We’ll be an unusual team at Microsoft because we’re focused on the health interoperability community. We’re building specs, tools, and libraries for broad adoption by large companies, academic health centers, startups, and even government agencies. As we engage with diverse stakeholders, I want to help you form direct connections so you can work directly and effectively with this community, rather than via me. Early on, this will be a bit of a balancing act. A few principles for our choice of tools and tech stack. We should...
-
not assume our target audience is “on the Microsoft stack” in any way
-
build tools that can run smoothly in any cloud (or on a developer’s laptop)
-
plan, develop, and document our work in the open (i.e., publicly visible and comment-able)
Transparency and discoverability. We'll work out the details as we go, but some of my personal, pragmatic preferences are to...
-
manage code and issues in GitHub
-
manage project plans with something visual like GitHub or Trello
-
build prototypes that interact with standards-based servers by wrapping/proxying, rather than modifying code from underlying systems (where possible)
-
“containerize all the things” so developers can deploy wherever Docker runs
Planning. We'll plan together, and I expect our planning process will evolve. We'll start with“OKRs”, defining team-level Objectives and Key Results. Let me know if you prefer paper or an e-reader platform so I can buy you a copy of John Doerr's book, Measure What Matters. (As John will tell you, OKRs aren’t a silver bullet – but having a framework and planning transparently can be hugely effective.)
Protoypes > Production. As a small team working in a big, challenging space, our goal is not to develop production-level software. It’s to drive interoperability forward by experimenting, exploring, documenting, and iterating together with the community. We should have a low threshold for sharing and soliciting feedback. Within and outside of our regular planning and design cycles, I hope you’ll feel empowered to explore new tech, try out some wacky ideas, and share what you learn.
Microsoft runs on trust. The tag line can seem trite to outsiders, but this is an incredibly important part of the way we engage. Working with the healthcare community, we must be collaborative, transparent, direct, reliable, and trustworthy.
“The Cloud – not just Microsoft’s cloud.” My remit from Peter Lee is broader than just Microsoft: to make healthcare interoperability work in the cloud, no matter whose. I’m strongly focused on the development and adoption of open protocols for health interop – regardless of where they run. This means I try to stay vendor-agnostic in nearly all my interactions (unless I’m specifically pulled into a customer meeting or pitch).
Open door. Please ask me questions and share feedback-- especially the hard questions about context, history, why we're adopting an approach, and whether we’re overlooking something important. Realistically my most frequent answers will be "it depends" and "because it's something we can get consensus on.” But part of your job is to push back and challenge assumptions. Especially if you can do it with data, demos, or both.
Connections within Microsoft. Since I’m new to Microsoft and work 2000 miles from Redmond, my personal network within the company is relatively weak. I don’t expect this to be a huge handicap, since 1) we’re largely an outward-facing team, focused on the healthcare interoperability community, and 2) we have tremendous support from within the Microsoft Healthcare org. But still, I want to help connect you internally at MS, because it’s an important part of your career development and support network. Sometimes this will mean that I "hand off" your questions by connecting you to folks in Redmond, rather than guiding you through a process that I don't fully understand myself. When this happens, we should aim to close the loop, reviewing what we've learned about process/policy/how get stuff done at Microsoft. This way we can learn together.
Travel and availability. I travel extensively for work, including routine week-long meetings (e.g., HL7 Working Group Meetings) where my availability can be quite low. During these times, asynchronous communication will be key. In any case, the goal is to ensure you have ownership over team objectives and can work and make decisions autonomously. For code and design reviews, we’ll evolve practices as the teams grows. I want to give feedback because this kind of iteration improves designs; but I never want to be a blocker.
Mobile communication. It’s helpful to know that my mobile phone is split across two profiles (personal + Microsoft). I don’t see Teams or MS e-mail messages on mobile unless I explicitly check -- so if you want to get in touch in real-time, and I’m not sitting down in front of a computer, I'm more responsive on https://chat.fhir.org . (And you should always feel free to text me at 617-500-FAKE.) It's fine to contact me any time of day; I silence my phone anytime I don't want to be disturbed.
What did I miss? Create an issue or a PR here :)