Monday, September 5, 2022

SoCraTes 2022 - A Welcoming Community of People Learning Together

Over years, various people recommended me to join a SoCraTes conference, especially the main German edition. They said it would be right up my alley and I'd love it there. I indeed loved the idea of software crafting and testing coming together. Still, I hesitated. This conference is designed as an open space, an unconference. The agenda and anything that happens or doesn't happen is decided by the participants. They build the conference. Don't get me wrong, I really enjoy this format, it's amazing to see its magic happening. My hesitation came from a different place: I am fortunate to be able to visit several conferences a year, thanks to me speaking at them and hence making use of the deal I have with my company. If there's no speaking engagement, though, I would need to take vacation, money, energy etc. on my own budget.

This year, my hesitation was resolved and I made it to my first on-site SoCraTes in Soltau. The SoCraTes people ran an experiment to bring experienced people and new joiners together and cover re-occurring topics in a "Foundations Day" before the open space starts. I was one of the lucky trainers to be invited to give a session on this day, which then also allowed me to experience the rest of the conference. Problem solved, here I come!

There's another reason why I was fortunate this way. For SoCraTes, you don't just go buy a ticket - instead you apply for one. The lottery will decide whether you get the chance or not. Why that? To intentionally build a diverse space where not only the same people return every year and no one else has a chance to break in. It allows for a good mix of people to meet. As a trainer for Foundations Day, I had my place already safe and didn't have to worry about my lottery luck.

Therefore: special thanks to Tobias GΓΆschel and Thierry de Pauw for inviting me! And overall huge thank you to all the organizers - this conference is community-driven, all of them are volunteers, and they did an outstanding job.


The Day of Arrival

The train ride to Soltau gave me time to prepare. I brainstormed topics I'd like to propose at the open space, or sessions I'd like to join or pull. I already had my list of personal goals ready that I wanted to aim for during this conference.

  • Connecting with the crafter community: building further bridges with regards to testing and quality, especially beyond people already in my network
  • Practice coding: I really strive for more practice and felt it would be an awesome place to hone my skills further
  • Discover something new: this is always something I'm looking for, and it never left me disappointed

In the evening, I arrived just in time for dinner with the community. Meeting some of the people in real life for the first time was amazing, as always! Especially Thierry de Pauw whom I've spoken so much with over the last years.

Over dinner, I realized I was not the only one joining this conference for the first time. Later on, we realized lots of people were new joiners indeed, based on recommendations they chose to give this conference a try. Was really great to see.

In the beginning, things were still a bit new, strange and even stiff; as it often is for me these days when suddenly seeing lots of people in real life. Within a short period of time I could loosen up, though. The more people I got to know, the more I relaxed and felt at ease.


Foundations Day & World CafΓ©

The Foundations Day format was an experiment by the organizers, the first of its kind. I can already share I loved it. Not only from a speaker's point of view, but also from a new joiner's point of view. It was a day with less people and hence a smaller crowd to get used to. A day covered with fundamental topics without them being too basic, so I learned a lot even with topics I knew about. A day where we had a schedule set in advance, which took away the uncertainty of what would happen. A day to get to know people a bit already.

One word ahead: This conference is all about inclusion and crafting a welcoming space where people feel safe, that they belong and can be themselves. This included not only free rapid Covid tests each day for everyone, yet also wearing masks indoors - led by example through the organizers, and implemented by nearly everyone of the participants as well. Kudos to all of you!

Back to the Foundations Day. Here are the sessions I've joined.

  • "TDD Foundations" by Emily Bache. Test Driven Development is one of those fundamental "classics" on conferences that I've rarely seen even mentioned in every day work. Yet when I practice it hands-on myself, I really enjoy the thinking and working in many small steps, aiming for just enough, having the final design emerge and maybe surprise us. It really fits well to me and my personal endeavor to reduce cognitive load whenever I can. Some great insights from this session: "Learning TDD is a way to reduce your delivery cadence. If you're aiming for short delivery cycles you need these short development cycles, too." Or Emily's emphasis on using tooling, like refactoring support our IDEs offer. Or that for existing tests she would never reverse test assertions to see if tests can fail, only deliberately write wrong code to make them fail - Romeu Moura, another trainer, instead would. Also, I just love Emily's teaching style. I've not only learned more about TDD as such, yet also on a meta level gained ideas and inspiration on how to facilitate sessions. How she used her Miro board when presenting, how she used a video recording of her doing a kata and added her narration, how she used the "yes and" principle with critiquing feedback from the audience and in general navigated this in a very constructive way.
  • "Legacy code: Add a reliable test harness (quickly) and refactor!" by Michelle Avomo. Given legacy code without tests, Michelle demonstrated how we can make use of golden master tests to gain understanding. She warned though that this approach is only a tool, these snapshot tests are often not reliable and fragile as any new change will break your test, even if not relevant. Once you understand what you want to do, you can move to other types of tests. Michelle also emphasized: "The tests are our first clients" and "Do not modify any production code that is not covered by tests". Wise words!
  • "Refactoring for Deeper Understanding" by Nicole Rauch. When we encounter existing code, it might be hard to comprehend. Refactoring to the rescue! Nicole presented an implementation of a simple method. She asked people what problems they see and how we can improve things (for example, by introducing types). She had great list of questions that the method left open to answer. These unclarities would make any code change difficult and even dangerous. After refactoring, she checked it against her initial questions to see if this version is indeed better - a validating feedback loop. Like Emily, Nicole also demonstrated how to use the refactoring options our IDEs offer us to make changes faster and safer. Also, she emphasized that refactoring does not mean big changes at once. We can just complete this one small step, commit and push. A huge refactoring can be done in very small steps - it does not mean detaching yourself from the main branch! So let's break it down to tiny steps, as tiny as possible.
  • "Different ways of using Property Based testing in your code next Monday" by Romeu Moura & Dorra Bartaguiz. I've been in a few sessions about property-based testing before, yet only now I've finally got a grasp on the concept! Really loved the demonstration in steps and the explanations added by Romeu and Dorra. We have a hypothesis about our implementation and place a bet that our implementation, i.e. our understanding of the business rules, is correct. In our test we only define this rule, not any input. The property-based testing framework now tries to find a suitable input value to prove us wrong, a counterexample! Input is generated randomly based on given criteria, and hundred tests are run against the hypothesis with different input values. It might all be good for a few runs, until the framework detects the case that is not supported by our implementation. In this scenario, a green test run means "I have not proved you wrong yet", a red one instead "gotcha". And in both cases we're happy as we learned! Very interesting to note as well: these test runs are extremely fast and cheap. Romeu and Dorra encouraged us to take it and try it ourselves with one test on a legacy code base - it's quick and we can discover interesting things.
  • "Ensemble Exploratory Testing" by me. A session that I've given many times for many different audiences - seems it's quite a timeless one where there's a lot of demand for. I've been asked to re-do it during the open space as well, so I did. Overall, it was once again fascinating to see how much people can learn in short time when they bring their knowledge and skills together, even if the single parts (like ensembling, exploratory testing, API testing, a legacy system, unknown people, etc.) are completely new to them.

In the evening, we enjoyed a lovely dinner with great conversations. Yet that was not the end of the day's program. More people had already arrived for the main part of the conference. To set the scene, a World CafΓ© was hosted by the wonderful Juke, getting all of us connected to SoCraTes and each other. How it worked? We had three rounds, a new question each round. For each group, one stays at the same place while all others look for a new group to join. The one who stays welcomes the new people and shares what the previous group had talked about. Usually this is supported by taking notes and drawing on flip charts or similar means. As I had my session at the end of Foundations Day, I got a bit late to dinner and hence also to the World CafΓ©. Didn't matter, I could simply join in towards the end of the first round. I picked a table, and was positively surprised - Kris Corbus was there! Just loved seeing Kris again after many years, I didn't expect this happy encounter at this conference. Overall, the World CafΓ© was great to get to know more people, realizing how many are indeed new joiners, and having a few familiar faces more for the next days.


Open Space - Day 1

The main part of the conference started! Juke once again was an amazing moderator, introducing us to the conference space as an intentionally welcoming and including safe space, as well as getting everyone familiar with the concept of an open space unconference. In short: we build the agenda we want to see! And that's what happened. It's fascinating how you can really trust in the system. The queues to briefly present the proposed topics were really long, and the emerging schedule looked amazing. So many awesome topics representing a great mixture ranging from hexagonal architecture to philosophy, from hiring to graphical visualization, from nail polishing to spikeball over lunch, from asking for support to debug a problem to example mapping - the list continues. And lots of people were contributing.

Here is how I designed my day.

  • "The Practices that Make Continuous Integration" by Thierry de Pauw. Thierry is currently crafting a new talk and wanted to do a very first raw dry run. I knew about the talk as I've also reviewed his abstract proposal to submit it to conferences, and was keen on hearing the first version. As this was a dry run I won't spoil its content here, yet I can say I really enjoyed it! And the practices mentioned give lots of food for thought on how we can achieve an always working state providing fast feedback. Also, it was super cool to see Thierry run this experimental raw version of his talk, even without access to his first notes. Super courageous, I loved this demonstration of how "good enough" can generate value and early feedback. Can't wait for the final conference talk.
  • During the second slot of the day, I took it slowly. I was late from the first one anyway, and as I've been asked to re-do my ensemble exploratory testing session it was a good moment to prepare for it. So, I sat down in the kitchen area, prepared, and as things usually go at conferences and especially open spaces, people came by, joined me for great conversations, and we went for lunch together.
  • "Dedicated Tester - Never worked with one? How could this be effective? Ask me Anything" by me. Having talked with a few people at the conference, I realized I didn't encounter too many people identifying themselves with the testing and quality space. Also, one of my personal goals was to foster bridges and communication. And on top I wanted to get myself out of my comfort zone and try new things - like giving a session I could not prepare for. Long story short, I proposed this "ask me anything" session and was fascinated by how many people joined me and how many questions they asked. Among them also Eric Proegler who could provide yet another viewpoint to the conversation. We talked about testing as an activity, what we're aiming for, how this can look like every day, pairing and ensembling, power dynamics, and more. It also ended up with continued conversations over dinner, or later on people approaching me with "oh are you the tester?" Guess there weren't many others after all (yet!).
  • "Improve Learning Culture" by Stefan Boos. This was an interesting session and exchange on how to foster a learning culture. It's a recurring challenge at many companies indeed. We brainstormed how to increase the number of peers taking time to learn together and how to respond to critics who question the benefit for the business or don't want to discuss at all but tell their opinion. Lots of great people to exchange thoughts with, quite a few things to take back and try out at work. For example, we talked about internal communities, explicit policies, sharing stories and celebrate learning, ensembling, framing as experiments, how we can measure success, that it's in the end about money and what drives people.
  • "Blind ensemble" by Romeu Moura. What a great way to deliberately practice effective communication and collaboration! I've always been inspired by the many ways Romeu uses constraints to practice pairing and ensembling. This time I could experience one of them: only the person at the keyboard saw the code (in this case, Romeu himself). Everyone else had to communicate by voice. In the middle of the exercise, he also took away visual cues by not having the rest of the ensemble see the person at the keyboard. It was fascinating to observe the dynamics. It was communication on a higher level, the details of the programming language used did not really matter (wasn't even shared or asked for) as the driver at the keyboard transcribed it. Also, the driver did not have any means to "write their influence", aka trying to write something ahead of the conversation and wait for people to complain. We usually rely a lot on tools to enhance cognition, yet in this exercise we don't have that, also personal notes are invisible. Getting lost is expensive in general and gets way more expensive in this constrained setting. It forced people to break down problems to smaller parts. Also, the exercise showcased that people worked on many assumptions and didn't make things explicit (as an observer, I was wondering for quite some time if Romeu actually wrote code or just pretended to do so).

Right after the open space day sessions were finished, we had another queue for evening sessions as well! Lots of great activities being proposed by everyone, from purely social fun to more tech topics, the whole range was present. I offered the redo of my ensemble exploratory testing session. Over dinner more people got interested - and indeed, we found a great group to work with and had some fun testing together in the evening.

This evening ended up in the bar, having further great conversations following my Ask me Anything session. I met Markus GΓ€rtner for the first time in person, cool to get in touch finally as well. Lastly, more tech fun, this time in the form of a coding kata. Romeu had asked a few times if I'd like to join him on a kata, and I never really took the courage. Yet when he came over to the bar table and kindly asked again, it was just the moment. So kata it was! The evening got late and it was time to get some rest before the next one. But not before agreeing with Romeu that we will propose a paired session the next day - whatever it might be.


Open Space - Day 2

The second day started and once again many people offered many great sessions.

  • "Talking about Security" by Claudius Link. A great open conversation on all things security. Lots of interested people joined, asking questions and sharing stories. We talked about how risk to a company is also risk to you as well as your family and friends. Think of the network! It's usually an industry working against us; a lot of attacks are automated, yet there are also a few targeted ones. Claudius is especially intrigued by the human element in all this, so we also talked about the seven principles of social engineering. How to counteract? What you can reduce most easily is the time pressure. Also: make people talk with someone.
  • "Pipeline Game - DevOps CI/CD Pipeline" by Emily Bache. I've heard of the pipeline game and related card deck a few times, now was my chance to join a session and give it a try myself. We could not do the full rounds yet enough to get a gist on it. I loved the conversations that emerged that also showed up our own biases! Based on a chosen scenario, our group designed our ideal pipeline with all the steps we felt necessary, always checking how fast our feedback would be. What stuck with me was Emily sharing that pipeline design is also a business decision - it's too important! Another curious insight for me was that most people talked about manual work as something done by others: by testers, or UX, or someone outside the team - yet not as everyone on the team and hence we would have additional waiting time.
  • "Reading Code under the Influence of Our Emotions" by Romeu Moura and me. This ended up as the paired session we agreed on doing. Reading code was the overlapping theme in our topics, and hence we went with it. We both had a vague idea and aligned for probably 30 seconds shortly before the session. This was a nice challenge in improvisation for me, and Romeu was the perfect one to do it with - huge kudos to Romeu for rolling with me on the fly, I loved it! And it seems we've hit a nerve with this improvised session. Lots of people joining and contributing. The main idea? We're spending most of our time reading code, often written by other people, yet also by ourselves. We all are human and have emotions when reading code. How can we get better at both reading code for comprehension as well as coping with our emotions while doing so? We had our own thoughts on what practices and techniques would help, yet mainly gathered input from participants and had conversations together that generated even more ideas. Lots of food for thought. I think we need more sessions on these topics.
  • Yet another slot I skipped due to conversations following the code reading and my ensemble sessions. It's an open space, some things emerge without being planned and on the schedule, and it's good this way!
  • "Security Fun - Let's Tackle OWASP Juice Shop" by me. This session was inspired by a conversation during the last days where someone mentioned Juice Shop and I felt more people might want to know about it. Hence, I seized the opportunity. I introduced people to this intentionally vulnerable application, set the scene for the first challenge and supported the groups as they went on their discovery journey. It seems people enjoyed it and had fun - and they also all managed to solve the initial challenge, or even quite a lot of them!

The official open space closed with a retrospective. We gathered in groups and collected our feedback for organizers, facilitator, session hosts and participants, writing it all down on flip charts. Loved seeing all the thought that went into it!

While the official part was done, we still had evening sessions scheduled. As we had talked about card decks today, I brought my TestSphere and Would Heu-Risk It? card decks and offered a session based on these - story telling or other activities depending on the people joining. People came indeed and were mostly intrigued by trying RiskStorming. I invented a scenario and product to brainstorm on. We had lots of fun discovering what matters to us, what risks there are and what we could do to mitigate them.

This evening was still by far not over. A few of us engaged in deep conversations filling hours, and I just loved it.


Workshop Day

The day after the open space is traditionally meant for workshops only, also ones spanning more time. I heard that traditionally also a Code Retreat would take place. I've had a few opportunities in the past where I could have joined one, and I always wanted to - yet again and again got scared and shied away from it. This time, seeing the community being so welcoming, open and focused on learning with each other, I felt this might just be the moment for me. I have to admit, I still nearly didn't go. Yet I took up my courage and sneaked into the room while introductions began. Stefan Scheidt originally wanted to join a code retreat himself, ended up facilitating it - and I'm ever so grateful for this kind and safe experience that made it easy for me to get out of my comfort zone once again. Especially as he was the first one to team up with me!

Now, what is a code retreat in a nutshell? It's a structure for deliberate practice of coding. You usually go with the same coding kata, like the classic Conway's Game of Life the whole day. You try to solve the kata in each round with a new pair using TDD. At the end of the round, you delete the code, and reflect on what you learned in the whole group. Each round you might have different constraints; you might work in a new programming language, or choose design constraints, or specific ways of collaboration (like ping-pong pairing), and more. Despite tackling the same challenge, it can be solved in a lot of different ways - each round will be different and you will learn new things! In the five rounds we did, I had four different pairing partners. The last round we did as an ensemble. I worked in four different programming languages: Java, Kotlin, Python and Haskell. We had different pairing agreements: when to switch, how to collaborate, who decides the next step, who talks etc. We started outside-in and inside-out. We used different IDEs. We used different code design constraints inspired by Janina Nemec's upcoming Code Retreat Kata Card Game - and more.

As I said, I was scared before. I'm not scared anymore! It was such a great experience and really makes me want to do more. I also realized that my previous pairing and ensembling practice really helped me in this situation (once again), just like everything I picked up on the way and that I worked across many systems, IDEs, languages and pairing styles already. It's making us really flexible in the end and doesn't get in the way of the solution. I realized once again that I know more and can learn more than I thought. I also feared that my very tired brain after all these conference days without much sleep would be overloaded quickly, that my cognitive load would be too much. Yet thanks to TDD and the engaging pairing sessions it worked really well despite being so tired, it was rather energizing. And the safety aspect allowed me to really use my energy for learning, not worrying.

The evening came, more conversations, more great people to get to know better and hang out with. Loved that I finally had a chance to catch up with Seb Rose this way! Also, I've found a partner in crime and real challenge when it comes to the game of Set - some of you might have seen it as a common guest at testing conferences. It was amazing to see Janina Nemec (whom I've met in the Juice Shop session and paired with in the code retreat) rock this game - loved playing with her, was super fun!


Returning Home

The day of saying final last goodbyes arrived. We could postpone them a bit further, though. A whole bunch of us took the same regional train to the next bigger city together. Yet another hour of sharing and enjoying that community feeling! Wonderful.

My whole experience was awesome. Organizers had put in lots of effort and intention to make this a great experience for as many people as possible and were eager to learn at every step how they can do even better. Participants were open, welcoming, curious and lovely to talk with. Personally, I felt very welcome. I left with a lot more people in my network, lots of deep and long-lasting conversations, lots of ideas and inspiration. Also, I was returning home with my personal goals achieved. I created bridges and fostered our common space. I practiced coding. I discovered something new. I also dared quite a few things, the conference inspired me to go out of my comfort zone again and grow.

That being said, there's also a word of caution: this conference can trigger lots of fear of missing out (FOMO) and I have to admit I did not sleep much. Next time I'll definitely need to include more self-care and also take a vacation day right afterwards.

One of my personal favorite aspects of this conference that surprised me in a way I didn't expect were hand-written kudos cards. Such an awesome feeling to suddenly have another person hand one to you! This time, I only managed to get my own kudos verbally across, yet next time it'll definitely be on my list to make time to write these cards. I'm ever grateful for those people who did take that time for me.

In any case, I can only whole-heartedly recommend this conference. It might be rather developer- and architect-centric as of now, yet people are really caring about their craft from a holistic point of view. So, here's a warm welcome and encouragement to have more of every skill we need added to it. Be it testing, quality, agile, operations, product, UX focused folks - in the end, we're all taking about very similar things from different perspectives, and should be working together anyway. Let's learn together.

Wednesday, July 27, 2022

A Time of Transition - Eight Months on a New Team

It's been eight months now that I'm at my new company, on my new team. Beginning of the year, I've shared my observations on the first months and my onboarding experience. Now that I've been here for over half a year, it's time to look back and reflect on what happened so far. Brace yourself, there's a lot to share.

In the following I'll be reflecting on my own team's context and transition. My team is usually my home base to operate from across teams. It's also where I deliberately put my focus on for the first part of my journey at this new company. We've already been through many challenges together, we've grown a lot, there's more change ahead, and I'm still having good reasons to stay at the company and move in better directions together.

Now, besides my team, there's a lot more to say about my first impressions and experiences at the company. On the one hand, there's the quality engineering guild with so many knowledgeable people I'm still honored to be colleagues with. We had great interactions so far, though not as many as I'd love to have yet. I mean, imagine the possibilities! On the other hand, there's the rest of the company with lots of more amazing experts of all areas. Like our infrastructure people, our medical doctors, our security experts, and many more. It's been a pleasure having our paths overlap already - again, not enough for my taste yet. And still, the focus on my own team was an intentional choice and I still feel it's where my attention is needed most. Which brings us to this post about the transition we went through together in the team: looking back to where we started, what happened, where we are right now, what helped on our way, and what the future might hold.


Where did we start?

It's always good to look back and see where we started out together. Without intentional sugarcoating, just as I've experienced it. In hindsight, some of my initial observations became stronger with additional evidence, other realizations only came over time. Please note that it's about people here. People who wanted to do a good job given the circumstances, people who have my respect. We'll see later how things changed and what impact this had, yet let me first paint the situation as I've observed it.

  • Solo working as default. I've experienced this as quite a contrast to my previous team. When joining this one, people could not really relate to me speaking about "pairing" or "ensembling". I realized they just never experienced effective synchronous collaboration. Everybody just did their thing, then considered it done and handed it over to someone else. I joined a team by name, yet did not encounter a team by spirit.
  • Limited communication within the team. I've seen people share a few sentences once per day during our daily. I saw only very few messages sent in the team channel or directly to me. I did see a few pull request comments from half the team. Whenever there were team calls, many people were completely quiet. That most people had their video turned off all the time did not make it easier. Yes, there are valid reasons why people don't turn on their camera, and I don't want to force anyone - yet it does make communication and building relationships harder for me.
  • Knowledge silos, gatekeeping, non-transparency. Oh my, this was a tough landing. I've seen people not share information with each other that definitely could and should be shared. I've seen the same with knowledge or any kind of learning. I've seen it with permission and access, be it for tooling or invites to meetings or channels or anything. At times, people were not only not involved, yet being actively kept out of conversations. Usually, there was only the one person who you depended on to get anywhere - yet you first had to find that person. You can imagine that people did not know the whole system they were working on. You can imagine the knowledge loss when people left the team. You can also imagine there was lots of misunderstanding and unrealistic expectations towards each other, as there was no shared understanding on a team level. You can also imagine that people did not like sharing their own work in progress before they considered it "done".
  • Expert role thinking. I've seen people treating each other very differently based on the role they identified with. I've seen them retreat to their own box, and shift tasks or responsibilities towards others once they did not fit perfectly in that box. I've seen "that's not my job" attitudes and other defensive patterns. This group felt at times like a conglomerate of sub-groups of individuals based on expertise or identities, like the "backend people" and the "frontend team".
  • Inaction, not daring to make decisions. I've encountered this over and over. I was coming from great environments where I learned that most of the time it is okay to go ahead without formal permission and rather ask forgiveness afterwards (while always considering impact upfront). Here, I encountered people who turned in circles over and over before daring to take action - if they took action at all. Let's rather have someone else make the decision or give us permission. Let's wait for someone else to make the first move. For everything, even very little things within the pure scope of the team. You can imagine that there was no experimentation going on or any tangible improvements to be seen.
  • Being pulled in various directions. There was no clear vision for the team or their product, at least none I learned about. Instead, I've seen the team being torn in various directions by various stakeholders who lacked understanding of the complexities of product development. Expectations were left unmanaged and I did not see any clear communication in place. Frustrations built up as people outside saw the team did not deliver things to the end, while the team was frustrated that before they could finish something they got pulled on to the next big thing.
  • Boundaries being crossed. Some people were super mindful with boundaries, and I celebrate them! Yet truth be told, I've seen the very opposite behavior with other people and this takes a toll. I've seen the team being asked on a late Friday evening to get results for early Monday morning. I've been myself in calls the whole day and being asked in each call to do something right away - yet when? Of course, the super urgent "whatever it was" was not being needed at all, or not being followed up. Expectations were unrealistic and definitely not healthy or sustainable. We lacked breathing space. I definitely did. I felt the need to push back heavily and make my boundaries overly explicit with some people, while trying not to fall back into my own personal pattern of being a people pleaser.
  • Blame shifting. This was maybe the most unfortunate, yet it explained lots of the defensive behaviors I've seen. Anyone made a mistake, any failure - and the blame game started. Be it across roles in the same team, or across teams - it's always the other one. No wonder why people came up with coping mechanisms, retreated to their own little safe places and did not dare do anything they might get blamed for.
  • Bad team reputation in the company. Another very sad thing I've heard from different people, even before I joined in. Their history (or rather their historical outside perception) wasn't shining a bright light on the team. It seems lots of communication issues across teams occurred. People expressed frustrations with the team introducing changes that broke things for other teams. People complained about all the perceived issues with the product. When joining the team, I did not find too much evidence to support this, yet once a team has a certain reputation it's going to take effort to switch this around.
Suffice it to say, I've encountered a group of individuals who tried their best working in this situation. They tried to help and support each other according to their knowledge and experience, given these conditions. Suffice it to say, I thought they deserve better - me included. So, let's shift this narrative and craft our own. But before that, let's add more details to the picture and also have a look at how testing and quality was considered in the team.
  • Throwing it over the wall. Automated tests were in the realm of the developers, yet anything else was "moved over the wall" to the dedicated quality engineer on the team. It was even considered a phase in the workflow. At this point changes were merged into mainline already, developers moved on to their next topics and feedback loops took really long. Little to no collaboration across roles could be observed. Later on, I found out lots of reasons, from not understanding what testing is about to developers not daring to test themselves, fearing they might miss important things.
  • Skipping backend testing. Changes on backend side often slipped through the cracks and were just moved to "Done". Well, you can imagine people were surprise about changed behavior. You can also imagine that avoidable bugs escaped to production.
  • Lack of foundational knowledge. Due to the knowledge silos and lack of sharing, people were not aware of things that I previously would have considered essential to the very task. They simply never had or took the opportunity to find out, and there was no incentive in it for them to do so either. I'm talking of knowing how to run your services locally, or calling the API of a deployed service. And these are good people - they just weren't aware of their options or sought to find out what's possible. Many even had been told it's not possible and it stopped there.
  • Testing only integrated states. As testing was coming in late, people only ever tested the integrated system. Sometimes this meant lots of changes combined already which in my experience makes it hard to detect problems, pin them down and relate them to their root causes. It's way easier to go in small steps and first see how the small change in a single piece behaves in isolation, before you put the pieces together and look how they behave together. 
  • Poor testability. Wherever I looked, things were hard. Harder than they needed to be. Time to find out how to make it easier, so it's also getting easier to spread the knowledge. Yet at the beginning, no one looked into making testing easier, they either thought it's not possible, or not worth it, or did not have capacity or the needed reward to invest in it (yes, similar to above). Instead, let's go the way of least resistance for now and either not test at all besides automation, or test the integrated state. Yet even there, we had poor visibility into what's actually going on.
  • Starting over finishing. As people were focused on their own piece of the work, and once it was done for them, they considered it done overall. Guess what? People continued starting new topics. All the time. Didn't hurt them, right? Yet when starting a trillion things and not following through to the end, you will end up with a huge queue and block yourself. Developers might have three topics to juggle with themselves in development, and maybe one or two to review - which is already a lot yet might still be okay for one person. From a dedicated tester's perspective though, this is a nightmare. Five developers each having their three topics going on means fifteen topics to switch context between for you. And lots of ping pong. Forget about throughput and flow, let alone fast feedback.
  • Poor observability and monitoring. Knowing or rather not knowing production was one of the first things I realized. If issues occurred, they were not easily and quickly spotted. Investigating issues was not straightforward yet complex. Responsibilities were unclear as well; who even responds to the people raising our awareness to problem reports?

I guess there's always more to share, yet this should give you the context where we started from to understand the transition the team made.


What happened?

So many things took place in the last eight months. Here are a few highlights of our journey together.

  • Team changes. First of all, the team I started in is not the same anymore as the team I'm on now. Five former people left, two contractors joined and left within this period, four new permanent people joined. It's been an overly huge team when I started out, now at ten people it's still at the very maximum when it comes to team size from my perspective. Communication pathways are already very complex.
  • Finding a dearly missed product manager. The team had multiple, frequently changing product people before and suffered from it. Now we got really lucky and found a wonderful product manager who is all up for transparency and knowledge sharing and always involves the team. Someone who sets clear priorities and gives the team focus. Someone who sets clear expectations with stakeholders and also shields the team from unhelpful organizational issues. Someone who makes quick informed decisions, instantly takes action and leads by that. I cannot overstate enough what difference this makes!
  • Rediscovering how to release. Knowledge got lost, and even such crucial knowledge as how to even release. Yes, that hurts. Given we have to consider compliance for very good reasons for our product, this was no little effort to figure out what's needed to get a new product version to the market. As the rediscovery phase took long and lots of changes queued up, it was a huge release. We all wanted to practice this more often and have smaller releases with less risk. With each following one we learned more about how we can make it easier, and we're still learning. Yet now we have transparency, the whole team is involved and enabled to do releases.
  • Team canvas session. This was initiated by our new product manager and was what the team needed at that time. A place to share what's important to us, where we want to grow into, what opportunities we see for our product, our personal values, and more. A foundation for the team to build on. As an outcome we now also have made our team values explicit. This way, we have a great reference for us to live by and also for people outside the team or joining the team to start with.
  • Huge epic. Beginning of the year, the team was made aware of an upcoming topic. When I heard of it, I instantly knew this will mean a gigantic effort, while observing lots of expectation mismatches (even down to "we'll do this in 2-3 weeks" - no way). In the end, it was a gigantic effort indeed! We're in the finishing touches now, yet this was huge. It was so huge, we had to literally drop everything else in order to make this happen. Kudos also here again to our product manager setting expectations very explicitly.
  • Extinguishing lots of fires. The time from March to June was a bit extreme. Lots of super urgent topics that all had to happen at the same time created lots of pressure. All while we also already worked on that huge epic. I think we only got through thanks to trying to tackle one thing at a time and our new product manager really stepping up. Can't emphasize this enough - she's seen the worst in her first month and is still with us! So, to see the positive here: this was the opportunity to set clear constraints and manage expectations, share the situation with other teams, get their understanding and support. I really felt this was a moment which could either break or make the team - and we ended up on the good side, the team really grew closer together.
  • My first time away from the team. I deliberately declined conferences and other endeavors within my first months, yet at some point they were coming. I knew up to this point, I needed to have the team enabled to take over testing themselves. They have the full context, anyone external would end up in the situation I was finding myself in when I started, it's not worth it for a temporary period - and also it would have reverted lots of the culture change we've been working on.

At the same time, we had lots of other constructions sites and room for improvement in the team. After the first month of observing, building relationships and growing my knowledge, here are the initiatives I ran within the team.

  • Onboarding and offboarding guidelines. Already in my first month it became clear that the team lacked shared knowledge, it was a rough start. As I had to gather the information bits and pieces anyway, I revised the existing onboarding page to a guide to help the next ones joining. Documentation itself was only half of the story, the other half was the mindset how to meet a new teammate, how to make them feel welcome and taken care of. Just last week a new person started in our team. Based on their feedback, it seems we're doing things a lot better already! Now, as much as there will always be new people coming, there will also be people leaving. That required a guideline as well to make sure we not only have a good last time together, yet also to handle permissions and set up the new team for their own future.
  • Making knowledge common. This ranged from sharing knowledge while collaborating, to sharing what I learned in the team channels, to writing "how to" documents. I quickly realized people really appreciated knowledge sharing! They also wanted to have fun together. Hence, we introduced a bi-weekly "knowledge & games" session where we took the first half to share whatever we learned, as informal as it could be to lower the barrier. The second half was reserved for games, whatever we were up for on that day. Already in the first sessions, I observed lots of aha-moments! During the high phase of the epic, we observed less knowledge sharing and more games, yet it was one the few things we did not stop. Now, we also see the sharing part being revived again, which makes me happy.
  • Issue handling policy and issue investigator of the week. One part of knowing production was to know how to deal with reported issues in production. The company had a guideline overall, yet it was not actionable enough for the team's context. I made good experiences in the past with having an explicit policy in place, so that's what I tried here as well. I made a proposal, I requested comments, we walked through everything together in a call, we all agreed to it. And we live it. Part of the policy is that we make quick decisions and not allow issues to hang around in our backlog, rotting away and just representing waste. Another part was quick response time to issues that we either identify ourselves or that are brought to our attention. Now we have a rotation in place, every teammate taking a weekly turn as "first responder" (or "issue investigator" as we call it) to evaluate any issues and then handle them according to our policy. At first, the team was not really comfortable with making calls like "we won't fix this, it's not providing enough value" and reflecting this decision in the ticket status by closing it. If it's not worth working on right away, however, then let's rather face the truth we won't tackle it at all unless our knowledge about the situation changes. If things are more important than initially thought, they will surface again. Ever since beginning of the year, you can see not only a clean issue backlog (some old issues had gathered dust there for three years), yet also quick decisions, important issues actually being fixed, quick responses to new incoming ones, and a lot less weight on the shoulders of the team. There's a lot more clarity now.
  • More cleanups, more transparency. As the issue backlog cleanup was so successful, we decided not to stop there. We also cleaned up the rest of our backlog, closing old epics that hang around, outdated tickets and more. Absolutely freeing and also providing more clarity. Great timing as well, just before our new product manager joined. We also cleaned up our wiki space - so many outdated documents! Also here, nothing got deleted, yet pages got moved in an "Archive" section and hence the rest of the wiki is now lean, up to date, accessible and manageable again.
  • Shaping the system to include everyone. For us it was crucial not only to pull single people into conversations actively, yet to have things accessible and visible from the start so people can make their own choices. For example, having all team related calls on the team calendar. Little thing to do, massive improvement in team culture! Or having one call link always available where everyone can join in and work together or alongside each other like in a physical team room. This way, I also overheard lots of conversations I wouldn't have access to myself otherwise. Or dissolving other systemic silos, like granting permissions to all needed tooling to all team members alike, independent from their role. Fostering a culture where people outside the team reach us through a common team channel so that we all see it and all can respond, instead of having individuals as single contact points and hence bottlenecks. Makes a huge difference in sharing load and increasing resilience, as well as in shared ownership and a feeling of team responsibility.
  • (Re)Discovering ways to collaborate for flow and fast feedback. When I started out, I realized the people on the team did not have any connection or understanding what I refer to when I speak about "pairing" or "ensembling". I understood they were working very asynchronously as well. Therefore, I tried to meet them where they are and at first collaborate very closely in an asynchronous manner. Working the board from "right to left", providing feedback on the items farthest in the process first and then working my way closer to what my developer teammates worked on right now. I added my findings as comments to the ticket as they couldn't oversee them this way. I used Slack heavily to ask questions or share insights. I tried to be fast and basically overtake them so we could work "side by side", being quick in any asynchronous manner. This worked nicely and people started to see what I meant with fast feedback as they experienced it! I also stopped talking about "pairing" and instead started to catch people in our daily calls, asking them "can you stay on for a moment? I'd like to show you something". Sharing screen, demonstrating where I had questions on or what I found, and then continue interacting with the system during the call. Demonstrating the benefit of looking at things together, making it easier to understand what's going on. At some point, an early adopter turned this around. He asked me instead if I could stay on the call. This developer wanted to share the current state with me and actively pulled my feedback on an early iteration. He had realized this shortens the feedback loop and he can move faster! He continued asking me for pairing sessions from then on. He even said maybe he should wait with merging. Maybe we won't need the "testing" column anymore in the future. Big win! Especially as he lived this in front of the others. I had my early ally already advocating for new ways. This grew to me pairing with each and everyone. Having them pair with each other as well. Having small groups work together as ensemble. People pulling in more people on demand. Sometimes just working side by side, yet more and more often together on the same thing.
  • Living continuous holistic testing. Not only speeding up feedback throughout delivery, yet also testing all kinds of pieces, from ideas to logic units, from mockups to automated tests, from documentation to architecture. Testing earlier and earlier, smaller and smaller. With trying to overtake people to meet them where they are or even before they picked up a new task, I naturally started testing smaller iterations and smaller pieces. I was used to that from my past teams, yet no one on the team experienced this yet. Some people on the team felt it's a waste of time or not the correct approach in their minds. I decided to just do it (as so many times) and let them experience the benefits. And they did! Nowadays, I finally can even join them when implementing a change or any other activity. In the first months, though, I was already content with joining efforts on testing only. I also made a point to brainstorm test ideas before people picked up new work planned for the sprint. Again, meeting them where they were by simply leaving comments in tickets and making people aware, asking for their thoughts, using them as conversation starters, and moving on from there.
  • Solving testability problems. By testing earlier, I came across lots of things that made it hard to test. Discovering solutions that were good enough, then building on them helped massively. For example, understanding how to run things locally as this right now provided most visibility under the hood. Or improving readme files and creating Postman collections for an easier starting point. Or using Wiremock to stub out external dependencies and explore more of our service's behavior. Or using other tools to gain more insights while testing. Also creating "how to" guides to document this for others as references. Yes, all that at the same time was a massive endeavor, and I really drew a lot from my past experience. Honestly, starting at a new company validated the experience I gained over the past six years heavily. Nowadays, I feel a lot less like an impostor. There's still a lot more we can do to increase testability, and I have lots of ideas - yet capacity is limited and I have to choose carefully what would have the most impact and not run too fast for the team to follow up with change.
  • Stop starting, start finishing. Luckily, I was not the only one repeating this mantra. Product and engineering managers joined me in this constant preaching. Preaching alone does not help, though! You have to lead by example, taking actions, making clear calls. Setting up the system to reward "finishing" behavior. Only when people experienced the pain themselves it got easier and they started to think first where they can help each other before they started something new. Well, some weeks were better than others, yet we're all human. Especially when pressure is on and we feel stressed, it's so easy to fall back to old habits. I see that with myself over and over again. Nowadays, the flow is a lot smoother and on most days we have a lot higher throughput than before. What helped here as well was that we had clear focus on our huge epic, clear priorities, and this approach was very clearly supported by our product manager. Focus really helped to get everyone not pressing ahead on their own yet to collaborate closely.
  • Enabling the team to test. Having each teammate now experience pairing sessions with me and practicing testing together with me (including documentation), they learned more and more about the whole system, what to look for, how to do it. Also here, I tried something that had helped me with past teams: I created a generic testing guideline. It always helped me personally not to forget about specific things that are important in the context, and I learned it helps others as well, especially if they are less practiced in testing. We don't have to re-invent the wheel! Also here, it proved to be a nice reference for people to think of when I would not be available. As it happened, I was off the time for increasing periods of time. At first, I was away only for two days. A few weeks later, for a whole week. Shortly after, for over two weeks. People really knew what's coming up and realized they have to step up, they can't just let things slide if they don't want to fall back massively. What happened? The first two days, the early adopter developer made a heroic effort of covering testing all by himself. He mimicked a lot of what he's observed with me, it was amazing to see! Yet it was a lot and all on him. The second time around, the team struggled and rather favored working on new changes over testing others. Tickets piled up waiting for feedback, and they experienced the pain and friction themselves. When I returned, it also took me the next two weeks to get back to a clean state together with them. Well, it was expected that people struggle, they've never done this before. And finally, my longest off time came - and they managed super well! I came back to an up-to-date state, could calmy start without pressure, things were taken care of by three of my developer teammates this time. Absolutely amazing outcome! I've seen teams successfully taking over before, yet never so fast so well. Super proud of them.
  • Doing releases as a team. When rediscovering how releases were done, I documented the single steps in a "how to" guideline. Then we started sharing this knowledge across the team. For our previous release it was the first time all teammates available on that day joined in with release testing together - massive improvement! As all of them now are also experiencing the friction in our current release process, they got inspired to find better ways, make it less tedious. Our current release has now been done without me being in a leading position, I'm just being consulted when needed and obviously I'm still there to support. This is a huge step again for the team!
  • Fostering cross-team collaboration. For the huge epic we're working on, it requires lots of teams. A great opportunity to establish and learn how to work well together across teams, including testing together! Absolutely nice to gain empathy, learn about the system as a whole, get to know the domain better, and especially also create relationships. Another topic: we showed up as a team during incidents that also required collaboration across teams. People suddenly saw our team in a different light, they saw us collaborating closely and constructively in a stressful situation. I bet it gained us reputation points or at least made people reconsider their viewpoint. We also had lot closer communication and collaboration with people from other specialties, like infrastructure services, customer experience, medical knowledge. Creating bridges and bonds here, always trying to be as transparent, constructive and helpful as possible. Learning which dependencies we have, who needs to be informed about what and be proactive about it. We've now also seen people actively reach out to us asking for how we work and pulling knowledge.
  • Knowing production. This is still a huge topic for us. It was one of my first ones to start with, and also one of the first to sadly be interrupted during the hot phase of our huge epic (I know, what a contradiction - just when we needed it most). I invested in learning more about our current infrastructure setup, our tooling to see what's going on, started to clean up and filter out noise to see the important parts we needed to act on. Before trying to create good practices in the whole team, I implemented a daily habit for myself to see what's actually going on on the only system that counts in the end - production. I discovered issues this way that we fixed which was a promising start. Then it came to a halt, just keeping the status quo without improving further. Only now we all can pick it up again.


Where are we now?

We made huge strides on our journey. Remember where we started out? Compare it to what we see now.
  • All kinds of collaboration modes. Synchronous pairing and ensembling, working side by side in the same virtual space, as well as asynchronous solo work. Wherever people are right now, whatever they deem best right now. And still evolving.
  • Heavily increased communication and making things explicit. This occurred thanks to synchronous work in general, yet can also be observed in team channels and in calls. Also across teams!
  • Inclusion and access by default. A topic we will continue learning about for a long time, yet we can already see how people changed their behavior, thinking of the team - which they also benefit from themselves. This was a huge game changer for us.
  • Higher confidence in our product, less observed issues. Fast and early feedback paid off! As did increased testability and enabling everyone to do foundational testing. Sharing knowledge across roles. Including diverse perspectives. All of that and more.
  • Increased systems thinking, higher focus on getting things done. People started to realize which impact actions can have on a system overall. Starting to see flows and queues, throughput and waiting times, and more. How we can help each other across roles and main areas of expertise, how we can share the load. At times feedback is again slow, yet our flow improved massively compared to when starting out.
  • Trying things out becomes safer and more normal. We're not having an experiment-driven culture yet, yet just feeling the freedom that we can make our own decisions and give something a try was liberating for the people on the team. We saw a lot more initiatives already and kept the good.
  • Becoming a team. We all grew a lot closer - I can now really say we are a team indeed! It's heavily more pleasant to work in this team, experience the spirit, to co-create something great. And this is by far not the end of it, it's an ongoing journey.
  • Being seen as a different team. Our reputation and outside perception already changed to the positive. We are continuously working on improving this, intentionally.
We're also coming into calmer waters now, finally. We all acknowledged that for the time being we needed to make tough calls in favor of achieving the challenges we faced - like this gigantic epic to tackle. Yes, there had been a few hiccups, yet overall, I'm super glad things went very smoothly! Many thanks and kudos also to our neighbor team here including the very amazing Patrick Prill. I loved the close and super supportive collaboration. They had a big part in this success and also a very positive impact on the team's journey.

I also want to acknowledge that I'm now working on the most diverse team I've ever been on in my whole career. Ten people from nine countries of origin, people of four races, with three women, and also other aspects I'm aware of like educational background, parenting, and others. Yes, I'm sure we're missing out on certain perspectives. At the same time, we have as many as I never had combined in one team so far. Invaluable, I'm learning so much.
All this has not been an easy ride, it's been a real challenge. It will stay a challenge, I'm sure of that. Yet now we're truly in this together and can all make our way to better directions. We're growing and changing; the future awaits us.

What helped make this transition?

People within and outside the company asked me how I contributed to the team's transition. Yes, I had my part in it with initiatives as described above, yet there's been a lot of people working together to achieve this. Thinking about what helped me on this journey, I realized I'll need to think about this further. I am considering making this the subject of my next talk proposal, as I feel there might be inspiration in there to try out and build on. I'm sure there are many ways how things could work. Whenever we don't see any way right now, sharing experiences like these could trigger a new spark, something different we could try. For now, let me share a few more things that helped me in the last months.

Remember my post "Dear Future Me: I Am Not Alone"? At peak times, I really had to remind myself about this. I did not intend to get into a similar situation again, yet here I was. My own advice from last year still proved valuable for me this year again.

What else helped? Patience, patience, patience. And lots of optimism and hope. Adopting new mindsets, changing behaviors and shaping systems take a long time. We're working with humans after all, and are human ourselves. We won't always have our best days, either. I'm in for the long game! So, whenever I see anything praiseworthy, I'll celebrate. Really, celebrate each step on the journey, every little thing. It's where I gain lots of energy from to go through the less successful periods. You might see me do this publicly a lot. You might think from the outside it's all nice and shiny. I can tell you it isn't. It requires the same effort. It requires the same patience. I do celebrate every win, and we fail a lot more than that and that's okay. There's no shortcut I know of. There's still so much more to do and we have it in our own hands to do it.

I drew a lot from what I've made good experiences with in the past. Like: approaching any situation with curiosity, showing you want to learn. Appreciating what's working, seeking the positive and turning up the good. Showing gratitude for help and explaining why it's impactful for me. Knowing people usually have good reasons why they behave in certain ways. Many people just never made good experiences or had opportunities or permission to try things out. So, let's give them just that, let them make their own experiences. Changing my own behavior - I cannot change them. Observing, gain ing transparency, creating awareness, luring people to experiment. Lots of "we" thinking, messages and also action. Leading by example. Being authentic and vulnerable, sharing as you go with all successes and failures. Not bothering with theory, yet getting down to tangible action. If it's not feasible, no one will pick it up anyway. Acting in ways to support people's work, not obstruct it or gatekeep. Using lots of pragmatism as well and not holding too closely to high ideals when we're trying to get foundations in place. Living very close to people and their needs. Speaking their language. Starting where we are and incrementally improving from there. Striving for better than we left it, yet never jumping to perfect - better is good enough for now. Explaining your reasoning behind actions or decisions, the why.

Not everyone is the same and that's great. I have early adopters as well as late adopters in the team - sometimes one person is both on different topics. Both types made huge transitions relatively to their own previous position. Someone who held back would now instantly go on calls with me. Someone who never did work together at the same time would now ask for people joining them to have more eyes on the same critical action. This might not be my own ideal for our future (which constantly changes anyway), and at the same time it is a huge step for them that I personally judge very positively. In short: don't expect to make everyone make the same jump at the same time. People need to go at their own pace and different things are differently challenging for them.

Work where work is visible for the people you'd like to lure into change (like ticket comments). Try not to convince them that certain things are valuable to do (test in isolation first, test the API only, read the code, test the tests, etc.). Instead, just do it and let the results and outcome convince them. Don't take it personally when it does not work out right away - remember, this takes a lot of time. Confidence helps - yet most often, we have to build our own confidence while we already need to take the team along, which is a challenge. Try to be clear about it yet not be put off. Yes, I also still need courage.

Just last week, I finally finished the amazing book "More Fearless Change" by Mary Lynn Manns and Linda Rising - and realized I'm using a lot of the various patterns to help change mentioned in the book. It resonated so much with me, it's incredible. Really recommended read if you are up for change.

What else? Let's get to know each other and build relationships, we're in this together. Let's create a safe space for us. Then we can focus on learning, try things out and see what happens so we all improve and can do a bit better each day. So yes, first and foremost, dare to try something. Inaction does not help. Someone else will not fix it, or not in a way you'd like to have it. Take action yourself. It doesn't have to be perfect, just a bit better than yesterday. It doesn't have to be huge, just a tiny step. You don't have to be in a formal leadership position, you have power to change things from your very career start. Observe, try something, reflect on what happened. Based on this learning, try something else. Continue.


What's next?

A lot happened in the last eight months. The team is not comparable anymore to the group of people I encountered when starting last December. We really started to craft our own narrative, and it's by far not the end. I'm looking forward to what the future holds for us and what we can do to help shape it to our team's as well as the organization's needs.

As we're now going back to a more sustainable pace, picking up things we had to drop in the last months, and also growing further as a team, a new exciting time is starting. There's a lot of topics to dive in to and further initiatives to drive from a team perspective. More problems to solve and friction to reduce. Lots of knowledge, skills and tools to learn to help us build a more valuable product. We can work on technical foundations now, grow into experimentation as a lived team culture, and make further connections with other teams. So much more to do. Lots of opportunity ahead, it's not getting boring any time soon!

In addition, there's a few organizational topics I'd like to dive into. Now that we are returning to a usual work pace, I'll have more time to reflect, to really stop and think about my next endeavors and experiments. I'm thinking of more knowledge sharing across teams in various setups. I'm thinking of more hands-on collaboration across teams, especially more pairing and ensemble sessions. I'm also thinking of acting on organizational observations I've made over time to achieve change on a bigger scale. I'll have to see what to try first to learn fast, where I'll have the most impact, and what also adds to my own growth. I cannot tell what's next besides it's going to be in the same organizational context. I'm curious myself for the future.

Thinking of my team again, change really does take time for humans. We've come a long way in quite a short time and I'm grateful.


Bonus: Collaboration Celebrations

You can see our team's transition reflected in my tweets over time. Some of them I already embedded above in context. Yet there's more, especially on increasing collaboration and growing closer as a team. Here's a tweet compilation to showcase the collaboration highlights of the last months. Remember, I celebrate every little thing and there's lots of white space in between. And still, there's so much worth in celebrating the good and the awesome people I have the honor to work with.