Showing posts with label culture. Show all posts
Showing posts with label culture. Show all posts

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.
Posted by at No comments:
Labels: , , , , , , ,

Tuesday, November 9, 2021

Six Years of Learning and Contributing

Today was my last day at the company that I've spent half of my career on. Time to reminisce and reflect! As I won't be able to put down everything that happened in the last six years, I'll focus on the kind of impact this time and place had on me. Well, or at least take note of the things that were prominent in my mind these days.


Where It Started

In my last job before joining Flix, I've learned a bunch of things, yet had less and less opportunities to test and grow my career. As a previous colleague reached out to me about this new opening, I was uncertain if they were really looking for someone like me, but eager to listen. The more I heard about it, the more I wanted to join. So I applied and got in, thanks to my colleague's referral. That was six years ago and in hindsight it was one of the best decisions I've made so far.

I entered the company as the second tester overall. Most people had never worked with a tester or other quality professional before. Thanks to the sponsorship of my previous colleague, my new team was ready to give it a try and figure out what that means on the way.


What I Have Achieved

After having practiced seeing my achievements for what they are over many years, there's probably a lot of things I could acknowledge as achievements, small and big. The following things, however, do stick out in my point of view.

Living a whole team approach to testing and quality. Let's start with my team. I've stayed on the same product team for six years. It never got boring and I really enjoy evolving a product also on longer term. In addition, there was lots of opportunity to grow in the team as well as on organizational level. My product team was my home base to operate from. The team constellation changed a lot over the six years and we continuously evolved our testing and quality culture. It might have taken me six years and a lot of experiments, yet this year I've finally seen the team actually living the whole team approach to testing and quality. They understand the value, they are enabled, they really feel responsible. I thought I've achieved this a few times before (especially with the team where we ensembled a lot), yet only now I realize the difference. Also, it is surely not the end and I really hope they continue this way on their further journey. (Have I mentioned I was fortunate to work with amazing humans here? Not my achievement, yet still a fact; and definitely helping me achieve this.)

Creating and running a testing community of interest. Now let's look beyond team boundaries. I was hired not only to test hands-on in the product team but also to evolve the company's quality culture. Me and the only other tester started a monthly sync, brainstorming what we can do, like educating people and hiring more testers. The other one soon left the company, yet over time, we created a testing community as an internal expert network, fostering knowledge exchange, inspiration, and collaboration across teams. I'm very curious what will become of it now that I made space for people and for new things to happen.

Bringing the first company tech conference to live. This was the company-wide initiative that was instrumental for my promotion to principal: I've made the first company tech conference happen, from concept to post-production, to nurture knowledge sharing across teams and companies. Unfortunately, it stayed with one FlixTechSummit only so far. I had to move on to my next initiative and handed things over, yet the next installment did not take place anymore as planned.

Enabling teams to experiment to grow a quality culture. I've designed and ran a series of experiments with multiple teams that improved their continuous learning, testing, and quality practices. This was a huge endeavor that also resulted in a whole conference talk on growing an experiment-driven quality culture. Our initiative group had a lot of impact with this experiment, and yet there was also impact we hoped for but didn't have. What we learned went into further experimentation.

Building the foundation for quality through leadership workshops. I've co-created and co-facilitated a series of six leadership workshops together with our amazing coach Shiva Krishnan. Shiva had initiated the series before, I've been on the previous cohort myself which had a huge impact on me, and I'm ever grateful he agreed to pair with me on the next one. We both learned so much from this experience! As part of leadership, our workshops raised people's awareness on identity and impact, and contributed to growing the company culture. The next cohort is currently running. Sadly without me this time, yet Shiva found another wonderful co-conspirator for the season afterwards.

Receiving feedback close to my values. Finally, a personal achievement I need to remind my future self about when I'm reading this again. In my last weeks, I've asked my current team for personal feedback, especially regarding the impact I had on them and what I could do differently next time. Admittedly, I really had a wonderful team with awesome humans for the last ten months. The feedback they shared with me (which I'm absolutely grateful for) validated what I've worked on a lot over the last years. I've always wanted to be considerate of other people and include them from the start, value their perspectives; and still my actions and the actual perception told a different story. It seems indeed that I managed to turn the points I've received as pointers to change over the years into appreciations now. And they are really aligned with my personal values. My heart was so full when receiving such feedback! I can only hope to continue living up to it and learn some more.


What I Would Do Differently

I've achieved a lot, and at the same time I also see things that I've done and that I would do differently nowadays. Or at least try to.

Focus on enabling. In most of the six years I've focused on doing things myself. Yes, I wanted to focus on sharing knowledge and enabling everyone, yet to be honest with myself, I still fell back into the habit of taking over, volunteering, driving things, advocating, catching balls, and preventing fires again and again. Only this year, I've indeed spent the majority of my time - okay, not the majority either - yet way more of my time on actually enabling others. I definitely want to do this more. I learned it still doesn't stop me from contributing hands-on myself in various ways. This applies to my work in the team just as much as to my work in the community or on other initiatives. The goal should be that they run just as well without me. This applies to specific activities related to core expertise just as much as to glue work. Everyone should be enabled to see, appreciate, and take over glue work as it needs. With my last team I've seen proof that this is indeed feasible.

Give feedback as soon as you have it and address conflicts as they arise. I am so much a people pleaser that I'm often seeking harmony over addressing a conflict. I'd rather avoid conflict if I could. In the last years I had a challenging team situation that originated (and got worse) from not putting things on the table early on, not speaking up and not raising concerns. It came from trying to be gentle and it ended up in avoiding difficult conversations. I did learn that being nice is not helping at all, and the kind thing to do would be to speak up instead. This is again something I think I've done a lot better this year. Giving constructive feedback as soon as I have it, no matter how difficult it might be, and managing a conflict instead of avoiding it. Interestingly, this also led me to give way more positive feedback as soon as I had it - and people appreciated this a lot. This is a huge topic where Shiva and our leadership workshops series had a lot of impact on me personally.

Be clear and transparent on what you work on and why. As I've not only been working embedded in a product team yet also had to split my capacity and energy with organizational topics, and I was also speaking at conferences hence spent time away from the team, it was always a challenge what of my work to share with the team and what not to. Sometimes people struggled with the level of detail I shared, sometimes with me not sharing enough, and mostly I realized they needed to be able to understand why I set my priorities as I do. I often felt the need to justify myself and apologize - even though this was actually part of my job. People came to me suggesting I drop this or focus on that, yet they contradicted each other and also what I wanted to work and have impact on. Now I learned it's all about me having a strategy plus being clear and transparent on the why and what people can expect so we can find a solution that works for everyone.

Make initiatives and communities visible and well known. I've started the testing community and ran a lot of different cross-team initiatives, and yet most of them were not seen in the tech department. When people wanted to know or learn something, they still asked their network instead of our experts or making use of our offers. I thought I've been very vocal on these things, yet now I've learned I wasn't enough and the word did not spread. Next time I need to come up with a better strategy, probably more advertisement, and having people experience the benefits so much they talk themselves about it.

Sponsor more people. I've received a lot of sponsorship myself which really helped me succeed; see also the next section on what I'm grateful for. Only the last years, I've started to sponsor other people myself more intentionally, making them visible, granting access to knowledge, referring them for opportunities, and so on. This is definitely something I want to do more from the start.

Take better care of myself. I nearly missed this one, and only now added this looking at my recent feedback and my previous blog post. I've been doing a lot better over the years when it comes to listening to my needs and communicating them, managing expectations and setting boundaries, saying "no" more often and also giving myself more time. That's still something to continue doing better. If I can take better care of myself, then I can also take better care of others. Only if.


What I Am Grateful For

Not everything was shiny over the last six years and some challenges could not be overcome. There are, however, so many things I'm grateful for. Like the following on the top of my mind.

The people and long lasting relationships we've built. I'm extremely grateful for all the wonderful people I've worked with. That was one of the biggest reasons to stay for six years - the amazing people. People who helped each other grow, people who got inspired and inspired others, people who paved the way, people who really cared for what we did and how we did it together.

My managers having my back, always. I am super fortunate to have had the two best managers I've ever had - and I did have great ones before. Both these two were exactly the right ones for me and for where I was on my journey. The first one, John Webber, confirmed my belonging within the first two weeks on the job and gave me the safety to fly. He actively supported my journey giving back to the outside community by blogging and speaking at conferences. He even helped me improve my posts and also sat front row in one of my first conference talks, holding up his mobile phone the whole time so he could get a recording for me. I've met him a few days ago and thanked him again for letting me fly. The second manager, Chris Vestrini, took over from John and instantly cheered me on on my speaking journey as well. How many times we've laughed when I asked yet again if I could take up yet another speaking opportunity I've received! Chris was always having a kind and open ear, nudged me with his questions in tricky situations and provided gentle advice. I'm ever so grateful for these two having my back inside and outside the company that allowed me to grow so much over the years.

Sponsorship gave me the chance to fly. Now I've said before, I've received lots of sponsorship in this company. I wouldn't even be there if not my previous colleague had vouched for me. I received two promotions, one to senior right after starting out, and one to principal three years later - despite other people trying to actively hinder it. I very well know I've only received this opportunity to prove myself because of these two amazing managers and them actively and loudly advocating for me. This is how I ended up as the only principal who differed heavily from everyone else, despite all my privilege: the only woman, the only tester, the only one not having a STEM background. I know we have lots of other great people who are not yet made seen and supported as much as I was, and I can only hope for more people in powerful positions sponsoring them. Thanks to me being made visible from the start, I've also received lots of other opportunities. Just some examples: I was referred to a talent program I've joined and could build a network from. I was asked to be a mentor. I received personal coaching that really helped me further. I could continue, yet I guess you get the point.

Being safe to dare and taking courage. When I recently thanked John for the safety and sponsorship he provided, he shared with me that he was impressed with me daring, having the courage to take responsibility and follow through. For example, my pact with Toyer Mamoojee to take up conference speaking really impressed him. The last six years, I've indeed used a lot of courage to move things within the company and also outside in our global community. That reminded me of the agile testing principles I've learned through Lisa Crispin and Janet Gregory already a decade ago, that explicitly include courage and influenced me from the start. I'm very grateful to have learned that courage can be worth it, that at times it's about rather asking forgiveness than permission. And it also reminded me of the "dare to lead" approach of Brené Brown (I just love the related podcast series) as well as of my own privilege that added to the safety I've received. What made me fly was safety plus privilege plus sponsorship plus courage. Then I could put in the effort, and it paid off. And I'm grateful for it.


What I Have Learned As a Tester

Phew, so many things. My mindset and approach continuously changed and evolved over the years. Also here, a few things stand out for me.

It's all about the people, interactions and systems. In the end, it's boiling down to foundations like communication and collaboration. That's usually where quality can emerge or is hindered by. A lot of my work was focused on finding better ways working together. Another major aspect is the system we're operating in - actively shaping it can make a huge difference. For example, think about which behavior gets rewarded in which ways?

Enabling others for resilience and the freedom to grow your expertise. I've already mentioned above, this time I've managed to have the whole team feel both enabled and also responsible for testing and quality. When I'm off, the whole team knows what to do and how to learn themselves. When I'm there, we can learn together and also I have more capacity and energy to bring in new topics and expertise, hence growing the whole team again. I really had to learn how to step back and let others do the job, though.

Experimenting for the win! It's all about the context and we have to figure out what practice works and what not. Again and again, it became clear that the contexts of our manifold product teams clearly differ. Not only slightly, yet heavily. In a larger sense some good practices might work well in a lot of them, like unit testing or pairing, yet there was also a lot of different settings and needs. Having the teams experiment for their specific context is key. This environment provided me and the teams the freedom to experiment with a lot of different approaches and we learned so much from it.

Testing and quality are holistic in nature. Personally, I identify as a specialized generalist. Over the years, I've realized just how much I thrive on learning more about all kinds of aspects of software development and how all these bits and pieces help me do a better job with testing and quality. This also means I can free up others from time to time, jumping in on tasks that are not my core expertise - and also add to the team's resilience this way.

Growing competencies through first time experiences. There were so many of them in the last six years! There was the first time I finally tested continuously, from idea to production. My first time testing all kinds of things, like ideas, mockups, requirements, infrastructure, data, and more. The first time I was set up and enabled to run the application locally myself, seeing the code changes, joining reviews, writing automated tests, and more. My first time giving talks and workshops internally. My first time trying out ensemble programming and moving to pairing heavily as ways to reduce feedback loops, waiting time, cycle time and increase the quality of the outcome. My first time exploring APIs without a frontend. My first time fixing issues myself and contributing to our infrastructure. My first time trying out different ways of reporting my findings. My first time testing for quality aspects like security and accessibility - and also advocating for building them in. My first time joining architecture discussions and doing domain modeling. My first time being active part of refactoring conversations. Already a long list and I could go on.

The more tools in my toolbox, the more options at hand. I've got in touch with so many technologies that I haven't had the opportunity to work with before. Just to name a few: Groovy, Typescript, Angular, Stencil, Jest, Serenity BDD, Cypress, REST APIs, Websockets, GraphQL, Kafka, MongoDB, Docker, Kubernetes, Bamboo, Jenkins, Gitlab. So many more tools and tips and tricks allowing me to do my work smarter and more effective, and also share that knowledge with other people.


Where Things Are Now

I am ever so happy that my mentee joined my last team as a dedicated tester who can drive things further and bring in the quality expertise. At the same time the people are fully enabled to own testing and quality as part of product development. I know they got this, and this is a great feeling. It's both sad to leave now and exactly the best moment to leave. Things are in good hands.

People shared with me that I've changed their way of thinking about testing and testers, which makes me really happy. More teams got inspired to improve their practices and make their first steps in integrating new approaches and figuring out what works for them, even if they don't have dedicated testers in their team. More teams understood how holistic testing and quality are in nature and that it's  encompassing way more than automation. More teams even decided to hire experts for their teams to learn from. I'm curious to see where their future leads them.


What I'm Looking Forward To

Very soon I'm visiting Agile Testing Days again. This event is meaningful to me, as exactly six years ago, just before starting at Flix, this was my first conference ever. From this community I've received a lot of sponsorship and support - hence I'm doing what I can to give back and pay forward.

Soon afterwards, my next opportunity at Ada Health is waiting for me. It's a chance to start fresh, continue building on the impact I've achieved, and do some things differently that I wished I would have done earlier. I'm very much looking forward to first observing, focusing on understanding the new context, making things transparent - and then experimenting to see what works in this context.

Most of all, I'm looking forward to getting to know great new people and to work together with them on a very purposeful product. Over and over, I've seen that I can learn so much from each and every one. I'm eager to see what I can learn from all these new people, and what I can contribute for them so we all help each other forward.

To the past six years, to now, and to the future!
Posted by at 4 comments:
Labels: , , , ,

Tuesday, December 8, 2020

My Personal Vision and Mission

This year, I set out to craft a personal vision and mission for myself. I'm sharing it now for multiple reasons. On the one hand, for my own learning and growth, as writing about it forces me to summarize my thoughts and preserve my reasoning for my future self as a reference. On the other hand, for your inspiration, in case you want to create a personal vision yourself to see if it helps tackling your challenges, or in case the content of my vision speaks to you in some way.

Balancing Opportunities and Impact

Since last year I became very deliberate with what I spend my time and energy on at work. Where can I provide the most value? Where do I want to have impact? How? Given the privilege and freedom I have at work, there are many opportunities at hand. The last years, especially coming with my promotion to principal level, I took the bait of saying yes to way too many topics. All the things sounded great and worthy after all! However, it's a trap. Juggling with contributing to too many initiatives at the same time can hurt a lot. It hurt the quality of the outcome achieved as I was spreading myself too thin to have as deep an impact as I wanted to have. It hurt due to opportunity cost, as quickly agreeing to all opportunities that came my way didn't leave the option to contribute to others that might have been more valuable to pursue. It hurt me personally as my stress levels increased with each topic exponentially, especially when tasks and deadlines collided. And it also hurt the interactions I had with other people as I was constantly in a rush, causing me to miss a lot of nuances in collaboration, often not having energy left to show my best behavior. I had to learn that the hard way last year.

Reflecting on this, I tried to increase focus for my commitments and see where I could provide most value every day, every week. Using a simple notebook page per work week (yes, an analog one), I started planning ahead for the upcoming week. I jotted down the most important points to work on, on which day, so I could provide the most value overall for all of us. Making things visual and having them lying next to me at any time indeed helped me focus. I could tick items off as I went, highlight them if I didn't come to them, or strike them out in case they didn't apply anymore. I also tracked my mood at the end of the work day to indicate whether the day worked out well or not so I could adapt what I had in my hands. While this was (and still is) helping already, I still was spread across too many things. I felt I needed even more focus and not fill my time up fully to keep a certain amount of flexibility. Yet what to focus on? Where to best spend my capacity?

Beginning of this year, I started reflecting on who I wanted to be and how I wanted to lead by example. I came up with five characteristics I'd like to see for myself, calling it my vision for my future self. That helped with grounding myself a lot. Also, I thought about the productive and generative work I wanted to do, both short term and long term - kudos to Maaret Pyhäjärvi for the approach and inspiration! This helped me come up with concrete strategies and balanced focus.

I viewed things from a "range of impact" perspective. If I do this, who would be impacted? Me, my product team, our cross-team testing community, the tech department, the whole company? I started limiting my initiatives to one per category, which already helped. Work in progress limits for the win. Over time, I condensed these even further to three groups only. Only three topics in progress at the same time, next to my everyday hands-on work in my product team. That worked well for quite some time.

This year, however, with limited energy at hand, I made the choice to reduce my topic limit yet again. Now I'm counting the every day hands-on work as one of three buckets I can fill. I could still approach this in new ways of course, yet now I'm explicit about combining these initiatives. Why? Last year I had created an explicit agreement with my team that on average I will work for two thirds on team topics and one third on topics beyond the team, impacting maybe another product team, or our domain, or any kind of grouping with people from various teams. So now I'm thinking of this roughly as follows: one third of my time for hands-on everyday topics with my product team (e.g. pair testing with my teammates), one third to drive initiatives within my team (e.g. increasing testability for our interfaces with services from other teams), and one third for topics beyond the team (e.g. supporting our domain technical offer experimenting to evolve a quality culture in the domain). So now I had roughly three buckets overall, so I'd rather only have only one focus topic for each of them.

All this worked quite well for the time being, and throughout this year I got better and better in not taking on new commitments. I even found an accountability partner when it came to saying no, my dear colleague Paulo Azevedo. I rather streamlined the attention and energy I had, driving less things at the same time - and I was feeling better.

With 2020 being a special year in itself, having a toll on everybody, I felt not guilty about not taking on formal cross-team topics and initiatives and instead chose to experiment more informally on my own. There was a lot of value in having this free time and new flexibility to involve myself and drive small things forward. Still, now that I went through the first waves and turbulences after my promotion and managed to calm down and regain energy, now that I'm in a good position where I can really trigger change, it was time to take up something bigger again. Take the next step in my personal growth as well. So once again, during the last months I've thought a lot about what I wanted to achieve, which impact to have.

Around the same time, I've completed a series of leadership workshops given by my amazing colleague Shiva Krishnan that provided a wealth of food for thought. It allowed me to understand myself as well as past interactions a lot better, and inspired me heavily to try out lots of different things. Along with the workshops, Shiva offered personal coaching sessions. I was eager to take him up on his offer as I had already learned how valuable personal coaching can be. In our first session I told Shiva I wanted to define my next step on my journey. So I shared the vision I had for my future self at that point in time - and his questions made me realize that my points rather described the how, not the what. What was it that really inspired me, that I wanted to achieve, my dream vision? I didn't have an answer. I could tell who inspired me; I tried to follow their lead by example. Yet what is it that inspired me personally, what did I want to reach or work towards as an individual? Thinking freely without barriers, leaving out all the things I might think I "ought to do"? What makes me happy, what do I enjoy, what do I want to continue? Shiva said to me that I don't always need to know everything, only where I want to go. So my actual next step became clear to me. I wanted to create a personal vision for myself to serve as guiding light when it comes to deciding which impact I want to have, where and how to provide most value, and which opportunities to decline, accept, or even create myself.

My Personal Vision and Mission

So far I had helped creating a vision and mission for groups and initiatives, yet never one for myself. I searched the internet for tips. I brainstormed and reflected on the past and present. Lots and lots of questions asked. What would I observe when the dream became reality? How to notice that what I did got us closer to my vision? How to know the vision is good enough at all for my purpose? Well, for the latter I found my answer. Given a vision, I wanted to be able to ask myself for any kind of opportunity: Does it support my vision? If yes, go for it. If not, it's either not the right thing to do or not for me to do it.

A vision is the dream goal, the ideal state. A mission leads to a vision, it's how to reach the higher goal. A vision and mission is never carved in stone, they evolve over time or might even change completely. Given all this, I created a first draft of my vision and continued iterating on it. Shiva was instrumental here in guiding my thinking with invaluable questions which triggered lots of thoughts, helping me uncover and shape what I see as mine. In the end, I had crafted my personal vision and mission as of now.

Vision: Systemic inclusion and growth for a better world 

Mission: By fostering a culture of DICE
                    Diversity, equity & inclusion 
                    Inspiration 
                    Collaboration 
                    Experimentation
=> Simple words: Foster a culture where everyone is sharing and learning with each other 
=> Shortest version: Everyone learning together 

My vision, the ideal world I'd like to live in, is to have systemic inclusion and growth for a better world. Because I strongly believe if we really include all perspectives and all the people with different lived experiences and we all get better together and grow and learn more, it will automatically result in a better world in the sense of better policies for our planet,  for our other fellow humans, for everything. Better products, more innovation, better ideas, better solutions. That's the base that I would love to have, the ideal, the dream.

It's about having a system where this is just natural, where people just do this naturally, where this is the easiest way to go. It's just the way it is, not something out of the norm, it's the default. There's no effort for people they have to put in as it's the usual way to go, you don't have to be a super human to do that. All good will come out of it, we can move forward together from a safe space. This vision needs me to think of systems more. How to set up policies, how to create the space, shape the environment - so that good things happen. That's my dream for the world overall, but also in a smaller part for tech which is my bubble. It's the higher thing that I'd like to contribute to and work on. I strongly believe if we have that we have a better world.

My mission to reach this vision is to foster a culture of "DICE". I use this as an acronym to make it more snappy and memorable. The D stands for diversity, equity and inclusion which is often abbreviated as DEI. The I is for inspiration, C for collaboration, and E for experimentation. I felt if I put this mission in very simple words, it would be to foster a culture where everyone is sharing with each other and learning with each other. So everyone learning together would be the shortest version, sort of the elevator pitch. I still kept the more verbose original one as default because I felt it's more explicit and expressive for me, but if I would need to explain it for someone else, probably the simple words and short version will help.

I am aware that some people might wonder where the testing and quality part is in here. I did not want to bind my vision to a specific aspect, activity or role. That does not stop me, however, from being able to see this vision and mission from different perspectives and takes. I can focus on testing and quality but don't have to. I wanted to have it explicitly overarching and including not only all those things that I do, not even only all those things we do in product development, yet be applicable to a lot of contexts. Shiva asked me whether I feel bad that quality is not explicitly mentioned in there. The answer is no. Based on my own experience, I believe that quality will emerge out of such a system, be the natural outcome so I don't need to focus on it.

I am also aware that my personal vision and mission can be perceived as quite open, high level and generic; so how could it be useful for decision making? Well, I see this as a benefit. I can do a lot of different activities to get closer to this, to help this vision. So many experiments I can think of that can contribute! Also, I wanted a vision I could live every day. Keep in mind that this is not tied to work only. I wanted to have a real personal vision and mission that's guiding me in life, which means in work life plus my personal development and private life as well. I hoped it would be a tool, a guiding light for prioritization and decision making, using which I could always ask myself: does this pay into what I actually want to achieve, the higher goal?

In the end, my vision and mission really feels good to me. I can remember it even when not reading it every day, can just tell anyone that's what I want to work towards. Also, it inspires me. On the one hand I'm already working on some of these things. I'm working on the growth part for several years now with all my personal challenges, learning together in groups, help others grow, sharing what I learned. I invested there a lot already. The inclusion part I always wanted to work on yet haven't done much yet, there's a lot of potential in this part and I'm just at the beginning. I could also say that this will lead to personal growth again; I feel I first need to learn what I can do to create such systems where others can do it, too. The key change in thinking now is the systemic part. I always thought of cultures yet never made it that explicit, never really considered deliberately shaping the space during my experiments to drive change. People have reasons for when they do something or not do something; I need to take care of the environment to be able to trigger change.

A Guiding Light

Having my vision and mission at hand and always visible, I wanted to give it a try to see if it really helps my decision making. New options and opportunities showing up? Now I could bounce them off my vision and mission, see if they pay into them or not. Also, I wanted to come up with my next big initiative. During our personal coaching sessions, Shiva mentioned the VMOSA framework that can help break things down further to actionable steps we can take towards our vision. VMOSA stands for:

  • Vision: the dream
  • Mission: what you will actually do to make your vision a reality
  • Objectives: what you're hoping to achieve in a given time frame
  • Strategies: the how
  • Action plans: detailed plan of who, what, by when, to make what change happen

I felt this VMOSA framework might be too blown up for my usual case, yet I wanted to try it out as a thinking tool and see if it would allow me to derive with concrete guidance for the next year 2021. I already had the vision, and the mission. The objectives? Phew, that one felt tough. However, thinking about strategies, Shiva had already made me realize that my original wishes for my future myself had represented strategies rather than a real vision. So I skipped the objectives for now and instead took the strategies I already had, extended them where needed, and mapped them to the points in my mission. Which strategies could I apply to get closer to which parts in my mission?

  • Leading by example 
    • The kind includer: creating space for people and helping them grow by providing crucial feedback, prioritizing the most vulnerable (D, I)
    • The inspirer: sharing my stories and lessons learned for others to discover and explore (I) 
    • The doing leader: demonstrating the whole team approach by getting my hands on wherever I can provide value (I, C) 
    • The collaborator by example: going the way together by pairing and ensembling (C) 
    • The learning advocate: becoming better every day by running small frugal experiments (I, E) 
  • Creating spaces with policies that have consequences 
    • Make inclusion and growth the default (D, I, C, E) 

The concrete action plans were also not hard to come up with. I felt that my actions would be represented by my experiments. Experiments applying strategies to achieve objectives paying into the mission to get closer to the vision and hence having real impact. Well, I have long lists full of ideas for my next experiments. Mapping these ideas to parts of my mission made also visual where they would pay into. Some experiments would pay into several, others only into one of them.

So far so good, yet I had skipped the objectives step. So now I thought about concrete, measurable objectives for 2021. It took me some time until I could formulate my first objectives, and all of a sudden I had nine of them. All quite big. Definitely very ambitious, most probably too many to reach in 2021. Am I spreading myself too thin again? Especially as I wanted more focus and balance? I wonder, what if I would see those rather as objectives and key results (OKRs), where it's recommended to define them in a way that you probably reach 60% of them? I definitely was up for a challenge again. In the end it's about outcome over output. I also mostly chose high numbers for my measures so I have to make it systemic to achieve them. Well, the objectives I have now might not be perfect, yet they are a starting point. And they did what I wanted from them initially, to provide guidance and help me choose my next initiatives to involve myself in. Which experiments to run now, which ones not to run, or not yet.

As a final step in this thinking process, I checked if my vision and mission is in line with our company vision, goals and values as well; especially considering my work objectives for next year. I was happy to see they actually do pay into it as well (or did I just see what I wanted to see?). Well, all that was an exercise to help me think. I cannot tell yet whether the objectives chosen will actually help me decide which experiments to try or not. Maybe they will indeed, yet they definitely won't be the only aspect. Whatever I will learn on my way will inform my next experiments in any case.

For now, I only decided on my very next experiment. This one is a real big one that is scary as well. It will definitely need me to be out of my comfort zone, stretching myself into the learning zone. It's as safe as it can be at the same time, as I'm going to pair with Shiva on this one. We agreed to do the next round of the leadership workshops for my location together. We're going to build upon each other's ideas and make this a new workshop series, an evolved one, our own one. These are going to be the first workshops where I not only talk about learning, collaboration, experimentation - but also about diversity, equity, inclusion, systems of oppression like racism, privilege, cognitive biases, psychological safety, and more. So much looking forward to what we will all learn together.

Building Future Systems

For the time being, I know my dream vision and my mission how I think we can get there. I do not know every exact step on the way there, though. Yet now I can work on this a lot more deliberately, experiment by experiment. I'm curious where it leads me and which ways I find to create systems, shape systems, and help them evolve - and us with it.

Posted by at 4 comments:
Labels: , , , , , , , , , ,
Subscribe to: Posts (Atom)