I had the luck to be selected on an expense-paid trip to observe a team of neural surgeons and nurses work for a week in their ward settings. There are some similarities to how we work in an agile software development team. I want to share these observations and my personal remarks with you to generate some thoughts and discussions.

The shift roster of nurses is like a Bach canon. A nurse’s start time changes from late evening to early morning to mid-afternoon and back to late evening again over a period. Other nurses follow the same cycle some days behind. This arrangement allows a nurse to work with every other nurse, similar to pair rotation. Only we software geeks luck out from the graveyard shift. The important point I’m trying to make is pair rotation matters as it allows us to learn from different people. Their personal style, their approach to problems, and even the darker side of their personality as they teach us how to deal with conflicts, which becomes an increasingly important skill to have as we navigate large teams in client organisations.

Before nurses start their actual shift work they come in early for a huddle. Chitchat, tea and biscuits. Because work is done by people, it’s important to have a strong team culture. Then, the stand-up meeting starts between the starting and the finishing teams to discuss each patient. Conditions, pain level, medicines given and other contextual information is shared. The finishing team shadows for a while before going off.

The nurses mostly pull tasks at fixed times based on patient nursing needs (medication, pulse and temperature checks, phlegm excavation 🤢). Unfortunately, there’re lots of push demands as well (bodily functions, mostly). The nurse I talked to said juggling tasks is one of the most important skills to develop and also one major source of mistakes. How do you focus? I shut down all notifications, including email and instant messaging. Block a reasonable chunk of time to concentrate. Break up a story into many small commits you can make in 15-20 minutes. Keep pushing your code to CI without breaking the build. Learn feature-toggling. Along the way, you’ll develop a laser focus on the essence of stories and how to deprioritise the noise. YAGNI. These are crucial (and very dev-centric) tricks. How do people in non-dev roles cope? Any great tip to share?

Many of the nurses have practicum students shadowing them. Students help out with basic tasks such as pulse and temp checks, drawing blood and basic cleaning. At the end of the shift there’s a huddle to discuss what the students learnt and for the senior nurse to give feedback. I encourage you to discuss the code you’re writing during pairing. Talk about the general principle or pattern being used, and how the principle is being reified in your code. Discuss what-ifs and it-depends. How would your design cope if the external environment or user demands changed? Note down new or related concepts for further reading.

Doctors shadow too. Trainee doctors, working at their laptop perched on standing desks, move around the floor like post-human cyborgs, following resident doctors and consultants who visit a couple of times daily. A consultant, i.e., the real doctor, is like a software architect, focusing on the big picture and relationships between systems, and communicating the overall treatment plan of a patient. It’s the resident doctors and the nursing team who do all the actual treatment and nursing. The consultant doctor tracks progress using patient outcome as feedback. A danger here is becoming post-technical, a danger that is all too real for some of us. As many of you progress in your journey in a software delivery team, you need to find your own path and passion. That delicate balance between writing code as quickly as you can and teaching a team to write the code. Between learning your fifth logging library and learning a game-changing foundational technology. Between leading a team and impacting a community. Progress is not linear. It’s perfectly fine to write code when you are 40. On the other hand, being senior is not about hogging the most complicated bits of the system.

The medical profession is strictly hierarchical. Junior doctors and nurses do not get to make too many decisions. While I want people on my team to experiment and learn, I don’t want people to make unilateral decisions they’re not qualified to. So what qualifies someone to make decisions? I put it down to education, experience and context, the last being the most important in my book. It’s incumbent on tech leads to share context, to communicate the desired outcome, and to let people closest to the code to make technical decisions. Project kick-off, story kick-off, and desk-checks are some tricks in the tech lead toolkit. I shall have more to say about fitness functions when I write a summary of Neal’s, Pat’s and Rebecca’s Evolutionary Architecture.