Surviving (and thriving) Through Peak Season 2016 on the Digital Observability Team

A Scrum Master's Perspective

It is 7:30 AM on a Monday morning in late October. I am waiting in line at Cafe Donuts to bring my team breakfast for our mandated ‘no work for one hour’.

We just wrapped up a strenuous week of implementing a major upgrade to our Elastic logging cluster. Many digital teams are relying on this upgrade to position themselves to confidently monitor their application health during the most important day in retail - Black Friday. It was a successful, much anticipated upgrade that resulted in many hours of overtime, late night calls, and cross-team performance tests. Morale is high, but it hasn’t always been.

It has been over three months since the team disassembled to work on new initiatives. I have since had a chance to reflect on the qualities of the team that made it so unique. I can’t speak for my colleagues, but the accomplishments we made over six months are my proudest achievements in my five year tenure at Target.

Leadership support

Our leaders truly supported and enabled our work to be successful. They gave us the resources and confidence to confront organizational blockers and competing priorities. They helped us celebrate wins by providing recognition through updates to high level executives and advertising our achievements in forums. They took risks for us, trusted us to make decisions, and went to bat for us even when there was doubt that we could deliver on our promises.


This quality is near and dear to my heart. I never witnessed competition, resentment, distrust, or judgement among the team. Everyone truly respected one another and their unique perspectives. We were all aligned, working towards the same goals, and were in it together. Lead engineers partnered with junior engineers to ensure they understood the entire tech stack and could independently support our customers. I personally felt like my opinions and ideas mattered. On call schedules were set, but we supported one another through escalations and incidents. As a primary on call member, you knew you were never alone. There were countless occurrences where engineers picked up shifts when they knew someone had to focus on life events or just needed a break. It was obvious that team members were proud of one another. I found myself bragging constantly in leadership updates and even to my family and friends about the uniqueness of our team.


Four different product owners rotated in and out of the team in a nine month span. At times, it felt like a constant, disruptive setback. But in hindsight, it enabled each team member to feel more connected to our priorities and customers. We were forced to share responsibility of visits and check ins with application teams. It is much easier to motivate a team when they can deeply empathize with their customer. The entire team built and prioritized our backlog instead of a Product Owner writing and maintaining tasks to hand off to the team. When our final Product Owner joined the team, he humbly respected the team dynamics and wholeheartedly advocated for our work.

People over process

My favorite agile ‘principle’. Our team quickly iterated through several methodologies, tools, and agile techniques. We kept the pieces that worked for us and ditched the ones that hindered our ability to move fast. We never considered processes or ceremonies sacred, but instead used them as tools to improve our productivity. We learned our colleagues’ working styles and how to best communicate with one another. We typically picked up 1-2 ‘features’ at a time and swarmed until they were finished. Engineers partnered on tasks that interested them, but also the non-sexy ones that they knew just had to get done. We met daily (most often in person) to share updates, blockers, and learnings. We talked often about frequent support incidents and aligned our priorities to fix them. We also talked about other things - Matt’s cat, Lydell’s band, Shawn’s daughter, Aaron’s hockey games, Jonathon’s inability to wink, Mickie’s hair color of the week, or the number of CD-ROM discs that we could fill with an audio version of someone reading all of the application logs our platform could ingest on a daily basis. The mutual respect and trust allowed us to connect on a personal level. This is an aspect of a successful team that I believe to be vitally important. Fostering the human side of software development - or any job that requires teamwork - is vital in maintaining healthy, productive, and happy teams.

Be your authentic self

This one speaks mostly to my role as a Scrum Master. I consider myself somewhat of a perfectionist in my professional career. I strive to meet the expectations of my role in the organization; attempting to exceed the job description. I find the Scrum Master role to be very tough to measure. What do my day to day tasks look like? How can I measure my success? Over the past couple years, I have learned that it isn’t possible to concretely answer these questions. There aren’t a list of steps in a Project Plan to follow to produce the #dreamteam. You also cannot fulfill the role by simply setting up and facilitating meetings. Instead, it requires working through a vast amount of interactions every day to enable a team to perform at its full potential; consistently delivering quality software. It is about each member feeling proud of what they achieved and ensuring that the team continues to improve its way of working. I realize that I feel most successful when I remove my expectation of trying to mirror a perfect ‘mold’ of the role. Instead, I try to be myself, leveraging my experiences and strengths to make the best possible decisions to benefit my team. Fortunately, I naturally yearn to help people and make them happy so the role fits my personality quite well.

Passion for technology

I am very fortunate to work among patient, caring, and inclusive individuals. As a naturally curious person, I strive to understand as much as I can about the technologies that my teams use and build. Without hesitation, everyone was extremely supportive in my desire to learn and contribute to our product. As we worked through technical design and strategic decisions, they explained in detail; encouraging me to ask questions and share my thoughts. Eddie Roger, one of our Principal Engineers and a personal mentor, was instrumental in establishing my confidence to develop a true passion for technology and even roll up my sleeves to build and deploy changes to our platform. Armed with this support and experience, I have been able to expand my role as a Scrum Master; recognizing the team’s pain points, posing insightful questions, and effectively communicating with our stakeholders and partners. My colleagues’ gracious willingness to teach me has allowed me to feel truly connected to the vision and future of our products.