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.