Introduction

Welcome to the world of mentorship, a place where we share knowledge, nurture growth, and build connections. Our journey starts with a simple letter that unexpectedly set me on this path, eventually leading me to become a mentor myself.

In this article, we’ll explore the profound impact of mentorship. We’ll dive into my personal experiences and uncover the valuable lessons and motivations that make mentorship so remarkable.

Mentorship isn’t just about passing on wisdom. It’s a partnership where people of different ages come together to learn, grow, and shape their futures. It’s an exciting adventure filled with inspiring stories, moments of empathy, and the sheer joy of watching others thrive.

So, get ready for this adventure. Together, we’ll navigate the joys, challenges, and motivations that make mentorship a powerful force for positive change. Strap in, and let’s explore the magic of mentorship, where we can nurture growth and create brighter futures.

The Power of Being Mentored

• Where it all began

Let’s rewind to where my mentorship journey started, back when I was the one looking for guidance. But don’t worry, I’ll keep this part simple and engaging.

After high school, I received a letter that changed everything. No, it wasn’t an acceptance letter to a magical school like Hogwarts, but it was intriguing. The letter came from an organization that noticed I graduated with honors. Their mission? To help students from less privileged backgrounds who were doing well in school. They offered to connect me with a mentor who could guide me through higher education and the professional world.

At first, I couldn’t help but wonder, “Am I really underprivileged?”. I then realized that I was the first in my family to graduate from high school. Studies show that children from working class families are less likely to pursue (let alone graduate from) higher studies, compared to kids from privileged backgrounds¹. I soon realized that I was entering uncharted territory, and a little help might go a long way.

• Into the world of preparatory classes

Skipping ahead, instead of going to a regular university, I plunged into preparatory classes. These classes aren’t your typical ones; they’re two intense years preparing for entrance exams to engineering schools. Think of it as a world where your exam rankings determine your future, and you’re surrounded by brilliant minds. This is probably a good time to mention I’m from France, hence the slightly different flavoring of higher studies.

Preparatory classes are known for being demanding, often labeled as “elitist” because many students come from privileged backgrounds and prestigious high schools. Meanwhile, my high school focused more on getting students to graduate than preparing us for this challenging journey. I felt like I was playing catch-up, trying to keep pace with students who seemed like seasoned pros.

• Enter Jean, my mentor

About two months into this whirlwind, I met Jean, my mentor. He was no stranger to preparatory classes, aced them, and made his way to one of France’s top engineering schools. He also had a successful career and had recently become a father.

Our mentorship was meant to last throughout my studies, but at the beginning, I wasn’t sure what to expect. I approached it with an open mind, not fully grasping how important mentorship could be.

• The uphill battle

Now, picture the early days of preparatory class: Stress levels soaring, confidence plummeting. In high school, I was a top student, but here I found myself in the middle of the pack (yes, they ranked us on top of grading). My daily two-hour commute didn’t help, and exhaustion became my daily bread (because I’m French, get it? 🥖). It was a frustrating cycle; despite my dedication, I couldn’t see the progress I longed for. At one point, I even considered giving it all up, dreaming of a dual degree in math and Italian, with fantasies of teaching math in the scenic Italian countryside (a true story).

• The turning point

That’s when Jean, my mentor, stepped in. He shared his own struggles during preparatory classes and the coping strategies he had developed to handle the stress. It was like having a wise guide show me the way through this challenging terrain. Thanks to his guidance, I finally found an approach that worked for me, and I could see light at the end of the tunnel. Long story short, I managed to succeed in the exams and secure a spot in a school that perfectly aligned with my aspirations (with some assistance from Jean in ranking my choices).

In this whirlwind of mentorship, I experienced firsthand its transformative power. Having a mentor wasn’t just about surviving; it was about thriving, discovering untapped potential, and having someone believe in me when I needed it most. My journey from being mentored to becoming a mentor is a testament to mentorship’s enduring impact and its ability to shape lives.

Now, as we continue through this article, I invite you to explore the layers of mentorship — the motivations, experiences, and lessons that have shaped my mentorship story. Together, let’s uncover the richness of mentorship’s impact and its incredible potential for each of us.

[1] Study on higher education in France depending on family background: https://www.inegalites.fr/L-enseignement-superieur-se-democratise-t-il
Similar study in the UK: https://commonslibrary.parliament.uk/research-briefings/cbp-9195
“Pupils eligible for free school meals are much less likely than other pupils to go into higher education, particularly to more prestigious universities. They are also almost twice as likely to drop out before the start of their second year in higher education.”

The Motivation to Give Back

When I was in engineering school and things were more quiet, I took the time to reflect on that experience. I realized a few things, which ended up making me want to mentor when the time came.

• Luck and gratitude

The first thing I realised was that without this person in my life at that time, I would probably have dropped out and definitely not be where I was then. To me, it felt like I had been incredibly lucky to have had that person placed on my way when I needed them. But then, reflecting even more, luck was only a part of that. The major part was that somebody had been willing to give their time to help someone that they did not know. I was grateful for that, and soon realized that I was able to create that kind of “luck” for someone else as well.

• Imposter syndrome

The second thing I realized was that it did not necessarily take specific skills to mentor someone. Sometimes all you need to provide is a listening ear, and you’re already helping a lot. Sure, my mentor knew a lot about a lot of things, had a few degrees, a solid job, etc. But the main thing he helped me with was motivation, listening to me, sharing his personal story, and giving me some advice based on what he had seen in the professional world.

Also, do you remember the person you were when you were fresh out of high school? I’m pretty sure that no matter what your life looks like right now, there are many lessons you have learned since then. All these lessons and the life experiences that you have gathered, they make you more than able to be useful to somebody who has so many things to figure out.

• Ripple effect

Mentorship has this incredible superpower — it’s like throwing a pebble into a calm pond, and suddenly, ripples spread far and wide. Remember how my mentor changed my life? Well, they didn’t just change mine; they changed the lives of everyone I’ve mentored, and hopefully, the lives of those they’ll mentor in the future. It’s like a chain reaction of positive change, and I want to keep that chain unbroken. Seeing the influence of my guidance extend to others is what keeps me excited about being a mentor.

• Pride and joy

Another exciting aspect of mentoring is that you get to see people grow. Watching someone you’re mentoring go from “I’m not sure if I can do this” to “I’ve got this!” is an amazing feeling. Helping a mentee tackle challenges, learn new stuff, and grow in confidence is like watching your favorite team score a game-winning goal. That sense of pride and joy in their progress is what makes mentoring such a heartwarming experience.

• Representation

One last thing I considered as a motivation to get into mentoring, was to provide more representation. Being a woman in the tech world, I’ve noticed that it can sometimes feel like we’re the unicorns in a forest of horses². That scarcity of women in tech has given me a big push to be a mentor. I want to show young women that tech isn’t just a boys’ club — it’s a place where we can thrive too. When girls see someone like them making it in tech, it’s like a green light saying, “You can do this too!”. And when I get assigned young men as mentees, I like to think that I am normalizing for them to see women in these positions. So representation is a big deal to me, and I think that I am making my small part of this big piece of work with my mentoring.

In conclusion, my motivation to give back as a mentor boils down to a few simple yet powerful things: gratitude for the mentors who lit up my path, a belief in the ripple effect of mentorship, the thrill of watching others grow, and a desire to be a beacon of representation, especially for women in tech. These motivations guide me through the exciting world of mentorship, reminding me daily why I’m passionate about this journey and why I’m committed to making a positive impact in the lives of those I mentor.

[2] From https://www.womentech.net/women-technology-statistics (2023):
“Women hold 28% of all jobs in computer and mathematical occupations, and 15.9% of jobs in engineering and architecture occupations.
In the European Union, women make up only 19.1% of the ICT (information and communication technology) sector.”

The Art of Mentoring

Welcome to the heart of mentorship, where we dig deep into the different sides of this mentoring gig. Mentoring isn’t just about giving advice; it’s an art, and sometimes, it can feel a bit like an adventure. So, let’s dive into the world of mentoring and see what makes it tick.

• One-on-one or group mentoring

Mentoring doesn’t come in a one-size-fits-all package. Some mentors like the one-on-one approach, where you focus on a single mentee. That’s what I do because it worked well for me as a mentee, so I figured it’d be my thing as a mentor too. Some other mentors prefer mentoring a group. That brings more points of view to the discussion, and you can also see more people being impacted by your actions. It’s like choosing between solo karaoke in the shower or a group sing-along — both are fun, but it depends on your style!

• Set expectations

Here’s a vital tip: lay down clear expectations from the get-go. It’s like drawing a map for your mentoring journey. Talk about your goals, boundaries, and how you’ll measure success. Even when the goal seems crystal clear, like helping someone find an internship, how you’ll actually provide that help varies for different mentees. Having this chat from the start ensures everyone’s on the same page and sets the stage for a smooth ride.

• The Power of Listening

Mentoring isn’t just about talking; it’s about being a good listener. Sometimes, the best thing you can do is lend an ear. Let your mentees spill the beans about their thoughts, hurdles, and dreams. It’s a bit like being a detective, uncovering the hidden gems of their potential. Ask open-ended questions, encourage reflection, and be that sounding board they need. You’ll be surprised by the insights they’ll find on their own.

• Guidance, Not Control

Being a mentor isn’t about being a know-it-all who calls all the shots. It’s more like being a helpful navigator on a road trip. You’re there to provide support and guidance, not to take the wheel. While you can offer advice and share your experiences, it’s essential to empower your mentees to make their own decisions and learn from their choices. It’s like being a co-pilot, offering directions while letting them take the lead in their journey.

• The Patience Game

Mentoring can sometimes feel like watching a pot of water boil. It takes time. Be patient, and remember that growth isn’t always linear. Celebrate small wins, and don’t be discouraged by setbacks. It’s like tending to a garden; with care and patience, you’ll see those mentees bloom.

• Empathy

Empathy is a superpower in mentoring. It means putting yourself in your mentee’s shoes, understanding where they’re coming from, and offering support without judgment. It’s a bit like being a great friend who truly listens and cares about what’s happening in their life. Empathy allows you to connect on a deeper level and offer the kind of support that makes a real difference in their journey.

So, there you have it. In the mentoring world, it’s not about strict rules or climbing metaphorical mountains; it’s about finding your groove with your mentee. Remember, effective mentoring is a mix of sharing your know-how while empowering your mentees to chart their own path. It’s about patience, listening, and personal growth.

What I Gain as a Mentor

Let’s get real about something — being a mentor isn’t just about giving; it’s also about receiving in the most unexpected ways. So, what’s in it for me? Here are a few examples on how this is an all-round positive experience.

• A Fresh Perspective

Here’s a fun aspect of mentoring: it keeps me on my toes. Every time I mentor someone, I’m not just sharing what I know; I’m also learning from them. Their fresh ideas, unique experiences, and questions often challenge my own thinking and push me to see things from new angles.

• Rediscovering the Basics

Have you ever tried explaining something you’re good at to someone who’s just starting? It’s a wild ride! It forces me to break down complex concepts into bite-sized, understandable chunks. This process of simplification makes me revisit the basics of what I do, and in doing so, I often discover nuances and insights I had long forgotten.

• Personal Growth

Being a mentor is like a personal development bootcamp. It hones my communication, patience, and leadership skills like nothing else. It forces me to be empathetic, a better listener, and a more effective communicator. I’ve seen my own growth mirrored in the growth of those I mentor, and it’s an exhilarating ride of self-improvement.

• The Feel-Good Vibes

Last but not least, the feel-good vibes I get from mentoring are off the charts. Watching a mentee overcome challenges, achieve their goals, or simply grow in confidence is a high like no other. It’s like a power-up for my soul, and it keeps me coming back for more.

So, you see, being a mentor isn’t just about altruism; it’s a two-way street of learning, personal growth, and those unbeatable feel-good vibes. It’s a win-win, and I wouldn’t trade it for anything else in the world.

Conclusion

In the world of mentorship, I’ve gone from being the one seeking help to being the one offering a helping hand. It’s a change that’s not only shaped my life but also the lives of those I’ve had the honor to mentor. When I look at mentorship, I’m reminded of its incredible impact, its power to lift, empower, and inspire.

From the days when I received that letter from an association to surviving the challenges of preparatory classes, mentorship was like my guiding star. My mentor, Jean, came into my life at a critical moment, offering not just advice but also unwavering support and understanding. Together, we faced the difficulties, and I emerged from it all even stronger.

Now, as a mentor myself, I’ve had the privilege of passing on the guidance and inspiration I received. Every interaction, every mentee, is a chance to make a positive difference, to be that encouraging force that propels someone toward their dreams.

Mentorship is a fantastic journey, like a dance of learning, growth, and shared experiences. It’s about helping each other, lending a hand when things get tough, and celebrating every victory, no matter how small. It’s about shaping the future, one mentoring relationship at a time.

So, whether you’re thinking about being mentored or becoming a mentor, remember that mentorship is a powerful way to bring about change. It’s about creating a ripple effect of knowledge, support, and empowerment that goes far beyond our individual paths.

As I wrap up this exploration of mentorship, I invite you to take a step forward, to embrace the transformation that mentoring can bring to your life. It’s a journey filled with gratitude, growth, and a chance to make a real impact.

Resources for Aspiring Mentors

Mentoring is a rewarding journey, and if you’re inspired to become a mentor, there are plenty of resources available to help you get started on this meaningful path. I should say that I am working with none of these so far, I’m mentoring through the association that mentored me back in the day (Dema1n), and as it is French-speaking, I’m assuming it’s not the most relevant here. Here are some valuable resources and other organizations to explore:

• MENTOR: MENTOR is a global advocate for youth mentoring. They offer resources, training, and support for mentoring programs worldwide.
• Mentorship Programs at Local Universities: Many universities in Sweden have mentoring programs for students. If you’re an alum or have expertise in a particular field, consider reaching out to universities to explore mentoring opportunities. For example, see the KTH mentoring program here.
• LinkedIn and Meetup: These platforms often have mentoring groups and communities where you can connect with potential mentees or mentors who share your interests and goals.
• Mentor.se: Mentor Sverige is a Swedish organization dedicated to promoting mentoring in various fields, including education and career development. They offer mentoring programs and resources for both mentors and mentees.
• My Dream Now: A nonprofit organization that aims to inspire and support young people in Sweden, particularly those from disadvantaged backgrounds, in pursuing their dreams and career goals. They offer mentorship programs and workshops.

Remember, the most effective mentoring relationships often come from a genuine desire to share knowledge and support others in their growth. Whether you choose a formal mentoring program or informally mentor someone in your network, your guidance can make a significant impact on someone’s life.

Mentoring Matters: Navigating Life’s Challenges Together was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

But first some background

We were coming out of a phase of organic growth and our processes weren’t as polished as they could and should have been.

Over the years we accumulated a range of different tools and had a very manual and somewhat tedious process for how code got into production. Without going into too much detail, we can just say that the journey to production consisted of around 10-ish manual steps.

To tackle this debt, we decided to consolidate all our delivery-related tools into a fully automated, streamlined, and opinionated delivery pipeline, with next-level developer experience built in from the get-go.

We didn’t only want to optimize for the usual suspects, the short feedback loops, and the small but frequent production deploys, we also wanted to make the whole thing “fun” to work with.

Guiding principles

We started off by gathering our team of platform engineers and fleshed out some guiding principles for how we envisioned our opinionated delivery pipeline to work and behave.

🤖 As little human involvement as possible

We wanted the path to production to be as frictionless as absolutely possible, i.e. eliminate all unnecessary chores and automate everything that can be automated.

The core of this was to trigger the delivery pipeline on every commit to the main branch, and for the delivery pipeline to take code changes all the way to production, every time.

This would then ensure that:

• The main branch is at any given time reflecting what’s running in production.
• All changes, small or big, go out in production minutes after they have been merged.
• The feedback loop from code merge to production is as short as possible.

🚧 Build once and run everywhere

We have several environments (production, development, local) and it’s generally considered good practice to have as much parity as possible.

In this case, this meant that the same container image should be used in all environments, i.e., build it once in the pipeline and run the same image in production as in all pre-production environments.

🔎 Pipeline visibility

Visibility and insight are crucial and we wanted our engineers (and others) to have full visibility into how their code is progressing through the delivery pipeline. At the same time, we didn’t want people to jump between many different tools to gather that insight.

What we really wanted was for all relevant events from all the different parts of the pipeline to be consolidated in a single “view”, where the relevant information is beautifully presented, approachable, and without adding any unnecessary noise.

🔒 Secure by default

It wouldn’t make a whole lot of sense for us to give away the keys to our castle to a third party, especially considering all the leaks that have been going on over the last couple of years.

You generally don’t want anyone but yourselves to have access to our production environment, meaning that whatever is integrated with our environments should be owned and managed by ourselves.

Execution

With our guiding principles in place, we went on to sketch out a solution.

We knew we wanted to build upon and leverage the tooling we already had, only introduce new technologies if absolutely necessary, and package everything as a streamlined pipeline instead of as individual tools.

To tie everything together into a cohesive experience, we decided to emit events from all relevant parts of the pipeline and implement an event aggregating service responsible for piping and presenting the progress of a pipeline run in Slack, in a beautiful way.

The following image shows how we envisioned this to work:

Continuous Delivery vs. Continuous Deployment

CD is one of the more confusing acronyms because it can mean both continuous delivery and continuous deployment. The difference between the two is that continuous deployment takes a code change all the way to production with no human intervention whatsoever, while with continuous delivery the very last step, the production deploy, is manually triggered. It’s still a fully automated process, it’s just that the trigger is manual.

We’ll revisit this and go full continuous deployment at a later stage but for us, it made the most sense to start with continuous delivery for the time being.

Anyhow, that’s why there’s a box in the drawing above saying Approve production deploy, it’s a button in Slack, the manual trigger.

🤹 Implementation

The pipeline starts with a GitHub Actions workflow going off on each and every commit to the main branch.

This can be seen as the continuous integration phase of the pipeline.

In this phase, we’re kicking off tests, compiling the code, running security scanning and we’re putting together a Docker image. All of these tasks fire off their own events, such as Tests started when the tests start running and Tests finished when they finish successfully.

As mentioned earlier, all these events are piped to and rendered in Slack through our event aggregation service.

We’re using ArgoCD for GitOps and we’re keeping all our Kubernetes manifests for all workloads in a centralized repo. The last part of the GitHub Actions workflow is to push a commit to this repo saying that there’s a new image version available for the workload we’re currently building.

We’re now entering the continuous delivery phase.

At this point we only want the change to go out in our development environment so those are the only manifests we’re touching. This commit will also fire off an event Rollout started.

Shortly after, ArgoCD will pick up the updated manifests and apply the changes according, effectively rolling out our newly built images in our development environment and sending out a Rollout finished event.

With the code change out in the development environment we can move on to the last phase of the pipeline, the production deploy. The one step of the process that has a manual element.

We’re showing a button in our Slack bot with the text Promote to production. When a user clicks this button (as they should) we’re kicking off another GitHub Actions workflow that is updating the production version of the Kubernetes manifests. This is firing a new Rollout started event, but this time for production.

Again, ArgoCD will shortly pick up the updated manifests, apply the changes to the production environments, and emit the corresponding Rollout finishedevent.

That’s it. Our code change is now running in production and the journey to get there was both smooth, secure, and fun. Mission accomplished! 💪

That’s the full delivery pipeline implemented with GitHub Actions, ArgoCD, Slack, and some clever glue code.

What’s explained above is obviously the happy path but as we all know things can and will go wrong, so there are also corresponding X failed events that are picked up and acted on accordingly by the event aggregation service, basically notifying the user that something broke and needs to be looked into.

Wrap-up

We went into this with the ambition to massively reduce the amount of manual toil and improve our developer experience, and we can safely say that we managed to achieve that. The number of steps required to ship something to production was reduced from 10-ish to just 2.

Great success! 🎉

In addition, we kept the complexity to a minimum by re-using what we already had, with the true key being that all relevant tooling was extended to emit events.

All in all, this gave us a full-fledged and streamlined continuous delivery pipeline that is not only optimized for short feedback loops but is also fun to work with and beautiful to look at.

In a future episode, we’ll dive deeper into the learnings and the impact all of this had on our engineering teams, so stay tuned!

Cheers and thanks for reading! 🍻

All kudos go to the great platform engineering team at Storytel who did all the hard work. 🌟

Credits: Pixelspeechbubble.com and Avatarsinpixels.com

Continuous delivery and DevEx was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Storytel made a big leap forward with the mobile apps’ DORA metrics in 2021Q1. We have transformed our internal processes and found an innovative way to reduce the app release cycle from three weeks to a single week without driving our engineers mad. Below I want to share some of our learnings — and yes, some burns — along the way. And of course, we are not done, the last section will share some ideas and idealistic plans of where Storytel is going next.

Once upon a time, in Storytel’s early days, its mobile app releases were on a “spontaneous” release cadence. As most startups do early on, the team simply released whenever it felt it had something important to bring to the users, whether it was a new feature or an important bug fix. This could happen frequently or rarely but whenever it did it was accompanied by a flutter of activity: testing, fixing, stress, panic. It was towards the end of 2018 when we made the leap to the “trains” approach, having a release every 3 weeks whether we needed it or not. This added a lot of needed structure and predictability and was generally regarded as a very positive change.

And then… mostly nothing happened. For a long while. Despite knowing that it is not a terribly good cadence we fell deep into the “good enough” trap. It wasn’t awful, and it mostly worked for us. And despite expressing ambitions to improve on this already in 2019, we never done much about it nor made any concrete commitments to future investments. During all this time our processes (both those inside and outside the Tech department) synced their dance with the “Storytel Beat” dictated by the mobile app releases, making it an axiom. It felt that with every passing quarter it would be harder to change it.

Computer Scientists have been using this hack since at least 1985 to solve problems just out of their reach

This is the part where I tell you that vacations and disconnecting are truly important. It’s cliché but it’s true. Let me paint you a picture: It’s November 2021, I’m enjoying an extended weekend in a spa. I am wearing a goofy kimono, attending one of those group relaxation sessions, and yet work challenges are on my mind. And while I was drifting in and out, somehow my mind landed on that hack Computer Scientists have been using since at least 1985 to solve problems just out of their reach: Pipelines!

And suddenly, lying there in a dippy kimono, I knew: Instead of fighting uphill to shorten our many release-related processes, adding time pressure and making everyone stressed, I simply needed us to have more ongoing release processes at the same time. This way we can create, effectively, weekly releases without our processes having to change much at all. Of course, hopefully the processes would get lighter, more effective, more streamlined and all in all better eventually anyway, but the key insight was that all this doesn’t need to happen first. We do not have to wait.

The release processes at the time took 3 weeks and had roughly 3 stages so it was easy to draft into a 3-stage pipeline.

• Stage 1: “Freeze”: We branch off from the development branch, creating a new Release Candidate (RC) and starting a QA process on it. The code enters “code freeze” where only approved quality-related changes are accepted. This takes about a week.
• Stage 2: “Beta”: The RC is considered mostly stable now and it enters a “Beta” period. This involves exposing it to a wide audience including external Beta users. The main focus of this stage is monitoring. If some truly critical problems are detected code changes can still be made, but the aim is to avoid any further changes. During this stage we formally send the RC for the final review by Apple/Google stores.
• Stage 3: “Rollout”: We use a gradual rollout and have our finger on the Abort button in case of severe bad news coming from Crashlytics or Customer Support. This stage is not laborious, but it can be very impactful, potentially saving a lot of pain for a lot of users and Customer Support. Normally this takes most of the work week, with the rollout completing at 100% at the latest on a Friday.

All “Project Turbocharge” was set to achieve was allow doing these processes in parallel instead of in sequence, and not aim to change or improve any of the stages. By the time project would complete we would have one release candidate in every phase each week, for a total of 3 parallel release candidates.

To make it happen I did a fair bit of selling and there my most important finding was that analogies are key. Even for very technical employees it was hard to make the pipelines mindset “click”. I threaded carefully to be respectful at all times and found that the established “9 couples can’t make a baby in 1 month, but they can make 9 babies in 9 months” analogy was helpful to many, even if it can be uncomfortable to mention in a work setting.

I took out one of my favorite tools: I wrote an RFC for our whole Tech community. I shared a document that clearly stated how I wanted our release process to look and what the benefits and drawbacks were. I allowed quite a long time to collect feedback on it, allowing everyone to gather their thoughts and provide suggestions. In the end most of the feedback I received was positive and most of the rest could be earmarked as “it sounds like more work for me”. The rest I were able to address, so altogether after this stage I was quite confident there weren’t any real, big, hard technical issues that would prevent us from going through with the plan.

At this point in the story the winter-break hits, so I gave one last encouragement to think about it over the holidays. As soon as we were back in January, I pulled the trigger: We are going to do this, and we are going to do it by the end of Q1.

Perhaps this seems drastic, but I am a big believer in Parkinson’s Law: Work expands to fill the available time. Therefore, when putting this plan into motion I put one of my favorite quotes to good use:

I admit I wasn’t truly confident that such a big change to our ways of working could really be achieved within a single quarter. But I was sure that it wouldn’t happen unless I was bold and set the expectations very high.

There is only one way to start up a pipeline: you insert the first item, and then insert the next item into phase 1 after the exact time that matches throughput you expect to see at the other end.

Even as the dev teams did a lot of work to make this happen, mostly within the scope of Automation efforts and scripting on our CI/CD, I did a lot of thinking about how we might actually make this happen when the time is right. When the insight finally came, it was as simple as one might hope: It is a pipeline, and there is only one way to start one of those up: you insert the first item, and then insert the next item into phase 1 after the exact time that matches throughput you expect to see at the other end (in our case, 1 week).

Suddenly the 7 weeks we had allowed for preparation were up, and it was time to start filling the pipeline. As you might expect, despite my best efforts to make this clear and communicate the plan well in advance, when we actually got started, plenty of people were surprised. I’ve heard plenty of “Oh is that this week?”, “oh, I’ve misunderstood that” and my favorite “oh I was reading the schedule backwards”. There are definitely a lot of learnings when it comes to communication, but…:

In the end it worked! March 21 and March 28 were our first “turbocharge releases” with only one week in between them. We have been working on that same cadence ever since, freezing on each Friday, and starting the release rollout every Monday. 31 releases at the time of this writing and counting!

It is important to remember that introducing change to any established process is going to also bring some short-term negative consequences.

The story doesn’t quite end there though. I think it is important to remember that introducing change to any established process is going to also bring some short-term negative consequences: there will be confusion, mistakes, and many lessons will be learned the hard way. All of this is necessary before the gains of the new process can be felt by the organization. As luck would have it, it was during this time I’ve learned that there is a term for this: “The J Curve”

One of the core principles of our new delivery strategy was that when we have a problem, we no longer focus on fixing the problem in the current version and deploying it (aka no “hotfixing”). Instead, the process it to abort the current rollout and make sure we fix it in the version that is up next. This is very important, as it breaks the negative feedback cycle we often previously experienced when the developers and testers needed to focus on the current problematic release, not spending their time on the next release, making it even more likely that the next release will also be problematic in some way or another.

It didn’t take that long until we had to test if the new principle was only good on paper, or did it also work in practice? Our 6th “turbocharge release” we got a non-trivial crash in our iOS signup flow, and it was not something we could fix by adjusting a feature flag. We kept a cool head and followed the plan: We halted the current rollout and fixed the issue in the release for next week. Guess what? This worked! The following release was a success and we succeeded in explaining the lack of hotfix to internal stakeholders, even as it meant that some users had to wait longer or business plans had to change.

To sum it up, here is a short list of benefits we see with pipelines now after we’ve been living the dream for a full half-year:

• More frequent updates to the user
• Less risk associated with deploying mobile app code to production
• No hotfixes, leading to much less “ad hoc” work, making work more predictable and stable for everyone working with mobile apps in some capacity.
• More flexibility when it comes to planning, validating and experimentation for PMs and the product teams

Of course, we do not consider the journey to be done. That is the pinnacle of continuous improvement, we do not want to settle. We do not want to find ourselves back in the good enough trap. Now after running with this system for 6+ months, we find ourselves on the “right side of the J-Curve”. We are hoping future improvements will come in two main areas:

• Get even more value from our dogfooding program by distribute daily builds from the develop branch to a wide internal audience. We seek to further increase the value we get from this by being even better and faster at triaging the feedback that comes in.
• Shortening the stabilization period: Having less release candidates in the oven at the same time, therefore simplifying, and further improving time to market.

Stay Tuned!

Does any of the above sound interesting to you? We’re hiring!
Check out all the interesting opportunities at jobs.storytel.com, including within the iOS and Android Platform Teams that played a big part in making all of the above happen.

Turbocharge: Storytel’s Story of weekly mobile app releases was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

This has allowed our designers to create UI with the same set of colors they normally use (Surface, Primary, Secondary, etc), knowing that if we apply an Image-Based theme to that piece of UI, those generated colors will work well with each other. Our developers then can implement that UI in a theme-agnostic way, by using Theme.colors.Primary, Theme.colors.Surface and so on, which helps produce clean and maintainable UI code.

A note to the reader: this article turned out to be quite long. It’s split into 2 parts. The first one goes through our approach on achieving a theme along with some color theory. The second part uses Jetpack compose to implement that theory.

The theory

Let’s start by analysing a piece of UI from the app. Here we have one of the blocks we show in our main page. It consist of an image, a card, some text, and a rating star. The card uses our Surface02 color, texts use Neutral03 and the rating star uses Primary01. These colors work well with each other but are not related to the image, which is what we want to change.

Our previous approach to achieve image theming was through Google’s Palette library. This library extracts a series of colors, each of one them including a suitable text color. This works fairly well on simple UI blocks, but it has a few drawbacks. The main one is that designers don’t know what to expect. Colors might be very vibrant in some images and dull on others. It works very well in a piece of UI that uses a single extracted color, but not so well when combining several. Our Primary colors are designed to have enough contrast and be used on top of all Surface colors, but the extracted ones won’t work well in most cases on top of each other. Let’s see how this same block would look using colors straight out from the Palette library.

Using these directly is a bit of a lottery. If you compare the new colors with our main theme, you can see how text have much less contrast towards surfaces, and the color of the rating star is much less saturated. Muted and Vibrant colors don’t necessarily work well together either, as you can see again in the rating star. The main problem with this approach is that the Palette library does not guarantee that you’ll always get all possible swatches, it only guarantees to provide the Dominant color of the image. This required us to add a bunch of logic in order to know what to pick depending on theme, and fallbacks if those colors were not available. This in turn made our code harder to read, error prone and less maintainable.

Before we start creating the theme, let’s talk about HSL. Just as RGB, HSL is a way of representing colors, but instead of describing them in terms of Red, Green and Blue, it does so in terms of Hue, Saturation and Lightness. We will use this because our approach to create a theme will be to tint the existing ones with extracted colors. This tinting is achieved by replacing the Hue of a color, while maintaining its Saturation and Lightness values intact. Let’s see an example of how this works for our Surface and Neutral colors:

As you can see, by replacing just the H, we get a new color with the same properties. Surface02 is still pretty light and unsaturated and Neutral03 remains nearly black (look closely, it’s not pure black). This would be really hard to do in RGB, while in HSL is a simple value substitution. The result is that any of the tinted versions of Neutral03 would have a good contrast on top of any of the tinted Surface02, just like in our base themes.

Now that we know how tinting works, we need to decide towards which hues we want to tint to. We will choose hues out of colors extracted from an image. In our app we pick 3 different hues to do this, but in order to keep this article shorter, we will only choose 2 here, but he principle is the same. In our app themes, Surface and Primary colors have very similar hues, so we will tint those using the same Hue target, and use a second Hue for tinting the Neutral colors. Let’s go back to the Palette library and see what we get from it:

Notice how for each color we have an optional name, provided by the library, its representation in HSL and RGB. We will now put them all in a color wheel, based on their Hue values, which are always a number between 0 and 360:

We will pick the Dominant color as our first Hue. This is because, as its name suggests, it’s the color with most presence in the image, and it’s the only color that the Palette library guarantees to provide. As second Hue, we will look for the one that has the maximum angular distance to the Dominant’s color Hue. This is so we get a good Hue spread in the generated theme. The formula for calculating angular distance, in Kotlin, is:

fun Float.angularDistanceTo(beta: Float): Float {
    val phi = (abs(beta - this) % 360).toInt()
    val distance = if (phi > 180) 360 - phi else phi
    return distance.toFloat()
}

This is easily translatable to any other programming language. For more info, check the wikipedia page. We will run this formula from the Dominant’s Hue towards all others, and pick the one that gives us the longest distance. Here is the result:

Great. Now that we finally have our 2 target Hues, it’s just a matter of replacing the H in our theme colors with those values:

What’s so powerful about this approach is that since you are tinting an existing theme, you will get one with the same Lightness and Saturation. You’ll get dark and light themes with the exact same calculations. In fact, in our app, we have 6 themes that are used in different situations (main, kids and monochromatic, all with their light and dark versions). This method works just as well with any of them. Imagine the amount of code needed for picking colors manually for each one.

The result is much more pleasing to the user’s eye and predictable for designers. Let’s compare the original block with the tinted version we generated:

And this is it for the theory. This, as you can imagine is not perfect. Contrast ratios are not maintained 100% since some hues have less intrinsic contrast than others with certain colors, with the most problematic being yellow. But with a bit more logic these problems can easily be resolved.

Needless to say, all this theory is applicable to any platform.

The code

If you’ve made it here, good job, I know all this is a bit heavy. But theory is important before we can start coding. Now let’s do some Compose and see how we can get this to work. Consider a basic theme setup that provides a color theme:

fun YourTheme (
    content: @Composable () -> Unit
){
    val colors = remember {
        getThemePalette(
            isDarkModeOn = isDark,
            isKidsModeOn = isKids, 
            otherParams...
        ) 
    }

    CompositionLocalProvider (
        LocalColors provide colors
    ){
        content()
    }

} 

Here we have a function getThemePalette that provides a ThemePalette object. This object contains different color values depending on whether we are in dark mode, kids mode or a combination of other factors. We want to replace that setup with one that accepts an optional url (new code in bold):

fun YourTheme (
    url: String?,
    content: @Composable () -> Unit
){
    val colors = remember {
        getThemePalette(
            isDarkModeOn = isDark,
            isKidsModeOn = isKids, 
            otherParams...
        ) 
    }

    if (url.isNotNullOrBlank()){
        GenerateImageBasedPalette(
            basePalette = colors,
            url = url,
            onGenerated = { generatedColors ->
                colors.update(newTheme = generatedColors)
            }            
        )
    }

CompositionLocalProvider (
        LocalColors provide colors
    ){
        content()
    }

}

Our theme accepts now an optional url, which will trigget a call to GenerateImageBasedPalette if provided. Since this requires image loading, we will run that function in a background thread and post the result in a callback (onGenerated). Once that’s done, we’ll update the values of the colors in our ThemePalette object.

While all this is happening, colors are being provided through the CompositionLocalProvider. The UI will be displayed with whatever base theme you have, and the colors will update once we receive the generated one. Another advantage of this approach is that if for some reason we can’t load or generate the theme, we can rely on our base theme. Let’s look at the code that generates the colors:

@Composable
fun GenerateImageBasedPalette(
    fallbackPalette: ThemePalette,
    imageUrl: String,
    onGenerated: (ThemePalette) -> Unit
) {
    val hash = imagePaletteGenerationHash(
        fallbackPalette = fallbackPalette,
        imageUrl = imageUrl
    )
    ExtractImageColors(
        imageUrl = Uri.parse(imageUrl),
        sideEffectKey = hash
    ) { extractedColors ->
        extractedColors?.let {
            val imageBasePalette = imageBasedColors(
                fallbackPalette = fallbackPalette,
                imagePalette = extractedColors
            )
            onGenerated.invoke(imageBasePalette)
        }
    }
}

@Composable
private fun ExtractImageColors(
    imageUrl: Uri,
    sideEffectKey: String = imageUrl.toString(),
    onExtracted: (Palette?) -> Unit
) {
    val imageLoader = LocalContext.current.imageLoader
    val request = ImageRequest.Builder(LocalContext.current)
        .data(imageUrl)
        .allowHardware(false)
        .build()

    LaunchedEffect(key1 = sideEffectKey) {
        launch {
            val palette = imageLoader.execute(request).drawable?.let {
                Palette.from(it.toBitmap()).generate()
            }
            onExtracted.invoke(palette)
        }
    }
}

In these two functions we load the image and use Google’s Palette library to get the first color selection. Notice that we are creating a hash that is unique for the combination of current theme+url, and we use this as key in our LaunchedEffect. This is to prevent us doing this once per recomposition.

fun Palette.themeSwatchSelection(): List<Palette.Swatch>? {
    val primary = dominantSwatch ?: return null

    var secondaryAngularDistance = 0f
    var secondary = primary

    swatches.forEach { secondaryCandidate ->
        if (primary.hsl.hue() != secondaryCandidate.hsl.hue()) {
            val primaryHue = primary.hsl.hue() ?: 0f
            val angularDistance = primaryHue.angularDistanceTo(
                beta = secondaryCandidate.hsl.hue() ?: 0f
            )

            if (angularDistance > secondaryAngularDistance) {
                secondaryAngularDistance = angularDistance
                secondary = secondaryCandidate
            }
        }
    }

    return listOf(primary, secondary)
}

This code gives us the 2 swatches needed to start the tinting. After all this is done, we do the Hue switching, like we did in the theory.

private fun imageBasedColors(
    fallbackPalette: ThemePalette,
    imagePalette: Palette
): ThemePalette {

    val selection = imagePalette.themeSwatchSelection() ?: return fallbackPalette

    val primarySwatch = selection[0]
    val primarySwatchHue = primarySwatch.hsl.hue()
    val surfaceHue = primarySwatch.hsl.hue()

    val secondarySwatch = selection[1]
    val neutralHue = secondarySwatch.hsl.hue()

    return fallbackPalette.copy(
        bgTheme = fallbackPalette.bgTheme.hsl().withValues(hue = surfaceHue).toColor(),
        surface01 = fallbackPalette.surface01.hsl().withValues(hue = surfaceHue).toColor(),
        surface02 = fallbackPalette.surface02.hsl().withValues(hue = surfaceHue).toColor(),
        primary01 = fallbackPalette.primary01.hsl().withValues(hue = primarySwatchHue).toColor(),
        primary02 = fallbackPalette.primary02.hsl().withValues(hue = primarySwatchHue).toColor(),
        primary03 = fallbackPalette.primary03.hsl().withValues(hue = primarySwatchHue).toColor(),
        neutral01 = fallbackPalette.neutral01.hsl().withValues(hue = neutralHue).toColor(),
        neutral02 = fallbackPalette.neutral02.hsl().withValues(hue = neutralHue).toColor(),
        neutral03 = fallbackPalette.neutral03.hsl().withValues(hue = neutralHue).toColor(),
    )
}

For completion, these are the functions that are used to work with HSL colors:

fun FloatArray.hue() = getOrNull(0)
fun FloatArray.saturation() = getOrNull(1)
fun FloatArray.lightness() = getOrNull(2)

fun FloatArray.withValues(
    hue: Float? = null,
    saturation: Float? = null,
    lightness: Float? = null
) = floatArrayOf(
    hue ?: get(0),
    saturation ?: get(1),
    lightness ?: get(2)
)

fun FloatArray.toColor() = Color(ColorUtils.HSLToColor(this))

fun Color.hsl(): FloatArray {
    val result = floatArrayOf(0f, 0f, 0f)
    ColorUtils.colorToHSL(
        toArgb(),
        result
    ).also {
        return result
    }
}

HSL is nothing more that a floatArray of three values, which we can replace as we please.

Finally, in order to apply this to a screen or UI block, all you need to do is to wrap it inside a new theme where you provide the url of the image, as simple as this:

YourTheme(
    imageUrl = imageUrl
) {
    YourUIBlock()
}

And you are done! You can apply this at any level you want. It can be applied to a block within a screen or to the full app. I’ll leave a small video of how we use this in our player too. Before we call it a day, just mention that in order to keep this article relatively short, I’ve omited several colors from our theme generation, like Secondary, Accent, onPrimary and onSecondary, but the process is the same and you can easily extrapolate it. Finally, I’d like to mention that at the time of writing we are looking for passionate android developers at Storytel. Check our open positions.

Image-based themes with Jetpack Compose was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

We did this using Terraform to set up PagerDuty. Teams, Services and Event Rules used to integrate with GCP and Stackdriver is constantly synced between Storytel and PagerDuty via Terraform. Big thanks to account managers and support people at both PagerDuty and GCP to help us iron out the details!

(If you are just interested in how we connected GCP/Stackdriver to PagerDuty Event rules, you can jump directly to the section “Integrating with GCP Stackdriver” below.)

Edit: This is now available also as a talk.

Starting Point

Storytel had a single global on-call team with two services (and two escalation policies) in PagerDuty, “The High Urgency Service” and “The Low urgency Service”. The High Urgency Service wakes people up at night, The Low Urgency Service does not.

Goal

Storytel has not just two, but 100+ services in PagerDuty, each corresponding to a System at Storytel. A System is a key component and examples are book-search, consumption-tracking and content-contract, and these Systems may span over both backend and frontend components. All ~10 teams at Storytel are represented in PagerDuty, and each team monitor their own components 24/7 according to Full-Service Ownership. Once Systems are added, deprecated or changes team, PagerDuty is automatically updated.

Prerequisite

At hand, we have management’s commitment and an API where we could get a list of all our Systems and the team owning each one of them. The System API is backed up by a database where we store all our assets from e.g. GCP and Github and map them to a System. Each System is in its turn connected to an Owner. Something like Asset -> System -> Owning Team.

Shortcomings

I decided to not include Escalation Policies and Schedules in Terraform, but to keep managing them from the PagerDuty webpage. The GUI at PagerDuty for managing (especially) schedules is so much easier to use compared to terraform text files, that it was considered to outweigh the pros of auditing that you can get from Terraform files in combination with some version control.

Secondly, we decided not to put slack integrations in Terraform at this stage, but it may come later. The reasons are that firstly, you cannot provide slack channel names, but you need the channel ID which makes it less intuitive. Secondly, you cannot operate the PagerDuty API (and thereby Terraform) for slack integrations with the account-level access token, but you need a user level token. This would require us to create a separate account just for this integration.

The Terraform setup

The following PagerDuty resources should be synced from our Systems API. (More about that later.)

• Teams
• Services
• Ruleset Rules

The following resources will be managed by manually editing terraform files:

• Rulesets
• Users
• Team membership (The connection between users and teams)

To make user and team membership easier to handle, I created a module for that. It allowed us to specify users and team membership using a syntax like:

Gotcha: This provided a way to inline team membership, but it also introduced a dependency that Terraform did not sort out. Teams must be added before putting users in the added team, it cannot be done in the same “apply”. For us, this was however no problem since we add teams by syncing with our Systems API, and we add users on demand via manual Pull Requests to our terraform repository.

I also created the root main.tf file, and files for the different resource types. I’ll show a representation of my file system here, linking the files to Github Gists as I create them during the course of this article:

| — main.tf
| — modules
|. . .+ — users
|. . . . . . | — main.tf
| . . . . . + — variables.tf
+ — users.tf

Exporting the current setup from PagerDuty to Terraform

The next step was to export our current setup to terraform. I wrote a script that took data from the Pagerduty API and generated both Terraform resource definitions (.tf files) and import commands to get the current setup into the Terraform state.

Note that this was the first time I ever worked with Terraform, so my approach was very exploratory. And when I got it to work, I did not care to refine the design considering this was a one time task. So I simply went to the PagerDuty API Explorer page, and got a list of all our teams and all our users.

I put them in two js files. Then I did a small nodejs script that gave me what I needed (but nevertheless is a bit embarrassing to show). It did the job, but not very gracefully. :-)

With this I populated the files users.tf and teams-legacy.tf

| — main.tf
| — modules
|. . .+ — users
|. . . . . . | — main.tf
| . . . . . + — variables.tf
| — teams-legacy.tf
+ — users.tf

At this state, if running “terraform plan”, I can see that terraform wants to add all those teams and users. This is because terraform state is empty and does not know that these resources are already there. To remedy that, I executed all the import statements generated by the same script above. (I did a similar thing for services, but that script I lost. By now, you’ve got the idea anyway. :-) )

Introducing the new Services and Teams

Finally, I wanted to grab the information from our Systems API and put that into PagerDuty too. Our key components at Storytel are the Systems, so each Storytel System will map to a PagerDuty Service. You will see the term “system” in the API response body below. (We rarely track individual micro-services, our systems are the entities where we need to put incidents. For that reason, we chose this mapping. We have so far not made use of PagerDuty Business Services or Service Dependencies used by the Service Graph, but we hope to extend with that in the future.)

Our System API response body contains these fields:

I use the system label, name, description and escalation policy ID to create my terraform records for PagerDuty Services. I use distinct team names to create my terraform records for PagerDuty Teams, and I use the system label to create Ruleset Rules for the Event Rules. This is done in this very straightforward JavaScript named generate_pagerduty_terraform.js described in the section “The script and its runtime” below.

After running that we end up with a file system that looks like this. (The file ruleset-rules-AUTO-GENERATED-DO-NOT-EDIT.tf will be discussed a bit later.)

| — main.tf
| — modules
|. . .+ — users
|. . . . . . | — main.tf
| . . . . . + — variables.tf
| — ruleset-rules-AUTO-GENERATED-DO-NOT-EDIT.tf
| — services-AUTO-GENERATED-DO-NOT-EDIT.tf
| — teams-AUTO-GENERATED-DO-NOT-EDIT.tf
| — teams-legacy.tf
+ — users.tf

The Escalation Policy Id

You may notice that our API response contains an Escalation Policy ID, that looks a bit out of context. Since we decided not to include Escalation Policies (and Schedules) in Terraform, but to keep managing them from the PagerDuty webpage, Terraform has no record of those and cannot map any resource id to PagerDuty ID. Instead, for each team at Storytel, I had to fill in the Escalation Policy ID by hand in our database. We have only around 10 teams, so it’s not a big deal.

While a fully terraformed setup of Escalation Policies would look something like this:

We just skipped the escalation policy part ad did this:

The script and its runtime

Finally, I wrapped that script in a small shell script that will:

1. clone our repo with current terraform files
2. run the JavaScript mentioned above to generate new files
3. use git to see if anything was changed
4. If there were changes, make a Pull Request with the updates

The shell script is packed in Docker and runs as a Cronjob on GKE a couple of times per day. If a Pull Request is opened on Github, my team will get a notice, and if approved, our Atlantis plugin will apply the updates on PagerDuty.

You can see our app here:

| — app.sh
| — Dockerfile
| — generate_pagerduty_terraform.js
| — json_encoder.sh (For GCP structured logging)
| — package.json
+ — cronjob.yaml

Integrating with GCP Stackdriver

With over 100 PagerDury Services, it becomes tedious to set up Stackdriver Integrations for each one of them. This calls for work on both PagerDuty and GCP. Instead, the PagerDuty Event Rules Automation was used. I would best describe this (from Storytel point of view) as an “Incident Router”, where incidents from a single integration can be both routed and prioritized based on incident metadata.

The most challenging part here is the “incident metadata” needed for the routing. Different integrations (external alerting tools) send this metadata in different ways. For that reason, we decided to set up one Global Event Ruleset for each integration. This will focus on the GCP/Stackdriver integration. I created the file rulesets.tf by hand, and it describes our GCP/Stackdriver integration. We chose to have one Global Event Ruleset per integration rather than one per team. This is because they are all managed by terraform anyway and we control access rights via terraform instead. The Ruleset Rules are generated by the script described above. The file system now looks like this:

| — main.tf
| — modules
|. . .+ — users
|. . . . . . | — main.tf
| . . . . . + — variables.tf
| — ruleset-rules-AUTO-GENERATED-DO-NOT-EDIT.tf
| — rulesets.tf
| — services-AUTO-GENERATED-DO-NOT-EDIT.tf
| — teams-AUTO-GENERATED-DO-NOT-EDIT.tf
| — teams-legacy.tf
+ — users.tf

Stackdriver metadata

Finally, on 29/3 2022, just when this article was about to be published, Google did a major update in the Stackdriver integration with PagerDuty, and a lot more information is now available. Prior to this, the only metadata that could be controlled by the user available in the alert was the Alert Policy name, and it came in a generic description field mixed in with other data points such as a description of what went wrong etc, all in one big mess. The scripts included in this article still describe a best-effort parsing of that old message type. It still works, but we are now of course looking into more robust ways of parsing what service is affected and with what priority using the new data fields in the updated Stackdriver message.

Here is an example of a GCP/Stackdriver alert message prior to the update:

What we figured out so far is that:

• The JSON message received from Stackdriver integration is not always valid JSON. Some data fields contain unescaped quotation marks and if the metadata contains labels, it has one or two extra closing (right hand) curly brackets for that JSON object, making the full JSON struct unparsable. A ticket has been created.
• When filtering on labels in your alert policy, the labels become a part of the metadata in the alert message to PagerDuty. For example adding “filter (metadata.user_labels.system == ‘consumption-tracking’)” will add a JSON field at “details”.”incident”.”metadata”.”user_labels”.”system”: “consumption-tracking”. We have so far only seen this by trying it out, and not had it verified by any documentation.
• Severity can only be added when describing your Alert Policy via MQL. This makes it possible to do dynamin Severity based on for example how close you are to a certain threshold. It would however have been nice if custom static labels were supported too, for example, to explicitly set our system label or to be able to set a static Severity for example on uptime checks etc.

Here is an example of a GCP/Stackdriver alert message after to the update 2022–03–13:

GCP integration with PagerDuty using Terraform was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Accessibility guidelines will legally require compliance in the EU by 2025. Read that sentence one more time. How does that information make you feel? Confident? Worried? Overwhelmed?

Storytel is one of the biggest audiobook companies in the Nordics. When we started discussing accessibility among our design colleagues, it became clear that accessibility is important in design and to test with users. In the end, our main goal as designers is to make products and services accessible and inclusive as well as create awesome user experiences.

At Storytel, we believe that stories should be shared and enjoyed anytime, anywhere by anyone. That sentiment should be reflected in our app and website design. However, making sure that our product is 100% accessible with the current guidelines is a huge project and honestly, we felt a bit anxious about it.

Where do we start? Who should be involved in the process? Who should take responsibility and ownership?

Starting out, we were afraid that we would have to be experts on all accessibility rules and guidelines from the start. We thought that the effort we would have to put into learning would block our progress and innovation. The teams already had full roadmaps, how could we add accessibility on top of everything else?

We had a lot of questions, but we also had a great desire to learn and a willingness to get started as soon as possible.

WCAG 2.1

Let’s zoom out a bit. Why has accessibility become such a buzzword today?

Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make web content accessible for everyone. Websites, apps and other digital products should follow WCAG 2.1 guidelines for both the private and public sector. For the private sector, it will be a legal obligation to follow WCAG 2.1 by no later than September 2025. This means that there is not so much time left, especially if you haven’t started the accessibility work for your product yet.

Let’s look at the problem from a different angle: Is it really the legal obligation and possible financial punishment that should drive this change and make companies work towards more accessible products? User accessibility is a matter of decency, not just a legal obligation. We do what we do because of our users. We should make sure that everyone can use our products and services because we all have unique needs.

Types of disabilities

There are different types of physical and mental variations and not all of them are plainly visible. Around 20% of all people worldwide have some kind of disability:

• Visual impairments
• Cognitive variations
• Hearing impairments
• Motor disabilities
• Speech disabilities

There are also temporary disabilities. For example, a person with a broken arm may temporarily have the same difficulties as a person who is born with only one hand. A bartender may have the same difficulties as a person with hearing impairments due to the high volume of music in the nightclub.

In other words, all people in the world could benefit from accessible products.

Storytel is used by more than 2 million users around the world in over 25 different countries. Statistically speaking, around 400 000 (20%) of our users may have some kind of disability. It’s not ethical to exclude anyone. So how did we start improving accessibility in the Storytel app?

Our first step: Talking to the users

We started with the most important and valuable asset we have — our users. We set up an online meeting with a user with visual impairment to understand their usage and interaction with the Storytel app. We asked them to open the app and what we saw surprised us. The app version they used was ancient. The answer to why they have not updated it made us even more curious.

“I know the navigation and functionality by heart, I use the app every day, it’s in my muscle memory. I don’t want to risk that due to visual design changes and updates.”

This shed light on the problem and sparked an eagerness to pull our sleeves up, put our hair in a messy bun and start working to improve the user experience. We needed to switch mindsets and prioritize functionality over visual design.

Our learnings:

1. Don’t wait with the usability tests until you have a perfect user panel with different disabilities and variations. Just get started.
2. Think of UX as muscle memory. Consistent navigation is super important for users. Make sure you notify them when you implement big design changes.
3. Include accessibility in the “definition of done”. We need to have accessibility as a part of the process and design documentation so that developers can build and test the implementation accordingly. For example, making sure that all design elements have the correct labels and text for screen readers.

Further evaluation of the app with the users

Playback speed

One of the examples that we would like to share is how we worked with playback speed. It’s a feature in the player that allows users to choose how fast or slow the narrator reads the book.

While working with playback speed in our app, we had an interview with a blind person. We sat next to her and observed how she was using her phone. But we couldn’t understand a word that her screen reader was saying because she used it at a very high speed, which we weren’t used to. Many people with visual impairments use their screen readers at very high speeds as a way to quickly scan a text.

The highest audiobook playback speed that we provided in our old design was 2 times the normal speed, which is already fast and is standard in the industry. But, after our interview, we decided to go even higher — up to 5 times the normal speed to make sure that we cover everyone’s needs.

Surprisingly it didn’t make much of a difference. Even though our intentions were good, our data analysis showed that no one needed these high speeds. Visually impaired users are used to them when using screen readers, but when people listen to content like books or podcasts they usually listen at normal speeds. So we put a lot of effort into something that wasn’t needed by our users.

Our focus was on general behavior (i.e. how people were using their phones and apps). We placed too little focus on how our users were using our products. This has a special meaning for accessibility work because not taking care of and properly understanding users’ behavior can lead to exclusion.

Our learnings:

1. Don’t go with the general approach and assumptions for accessibility. Make sure to test the solution in your users context.
2. Dig deeper. Make sure you really understand how your users behave and how they interact with your product.

Sleep timer

The sleep timer is one of the most used and thus one of the most crucial functions in the player. As a part of the player design work, we also wanted to redesign the sleep timer. The design process was followed diligently and was tested numerous times with various users. Edge cases were taken care of, it was iterated on many times and when we were happy with the result, it was implemented.

Here you can see two designs, the old one (left) and the new one (right).

From a design perspective, it may seem like the new version is much better, however, when it comes to accessibility it’s not that simple.

After the release, we started to get a lot of feedback from our users. Many were really frustrated that they couldn’t use the sleep timer anymore. As you can see in the image below, people got confused with the many dots and all of the abbreviations.

As you may have guessed already, the problem lies in the enlarging text font size. This is usually done in the phone settings, and not in the app settings.

Around 20–30% of people worldwide use this setting to ease reading. Once people turn this feature on, they tend not to think about it again. In other words, it becomes a standard, a person’s “default” setting.

In our case, the sleep timer function became unusable for those users who had enlarged the font size on their phones. Numbers and text were automatically replaced with dots and letters which made no sense.

Our learnings:

1. Not everything can be tested on a prototype. A lot of accessibility functions, including dynamic text type features, should be tested just after the implementation, and if possible before the release.
2. This situation raised a very important discussion in our company — there was no clear process about when this should be done and who should own this responsibility. How should designers, developers, testers and other roles share the responsibility? We recommend starting this discussion as soon as possible because all of us need to take ownership and do our part.

Usability testing with screen reader users

Recently, we have tested our app remotely with users that use screen readers to navigate. Usability testing is by far the best way to naturally learn about how your users interact with the app and see and hear what works and what doesn’t work. The users shared their screens with us and we asked them to explore the app by giving them several tasks. We kept close attention to the VoiceOver feedback for the different parts of the app and let the users lead the session by pinpointing the issues they faced. And the result? We learned a LOT!

Our learnings:

1. Button labels. Go through all the clickable elements in the app and listen to the screen reader. Make sure to put correct labels on buttons so that users can understand what they can click and interact with them.
2. Button’s additional states. Make sure to put correct labels on buttons so that users understand their different states. In our case, users didn’t get feedback if some buttons were selected or unselected.
3. Feedback. Make sure the screen reader provides users with feedback when they change something in the app. For example, we found out that our users didn’t get any information from their screen readers when they rated a book or set up a sleep timer in the player.
4. Progress bar sliders. These are really tricky elements for screen readers. Make sure they are easy to use, that they give the right feedback and that it’s easy to revert the changes if needed. For example, we discovered that the progress bar slider in the book player jumped by percentage for screen reader users, which could be confusing. It’s much more user-friendly to read the interval by time out loud instead.
5. Information order. Make sure that the information in the layout is grouped and follows a natural information hierarchy order for screen readers. In our case, we found that our book reviews cards (placed in a horizontal scroll with a name, star rating, and review) were read as “Jonas”, “Sofia”, “Amanda” followed by users’ star ratings and reviews. A more natural order would be the name of the reviewer, their star rating, and the comment before the screen reader continues to the next review.
6. Navigation. Make sure that the scroll position on the previous page is saved for screen reader users as well. We have saved scroll position for users not using any accessibility tools and we should have the same behavior for screen reader users.

A new accessible Design System

Last year we switched our design tools, moving away from Sketch to our new tool Figma. Right now we are in the middle of setting up our new Design System for Storytel. We decided to take this opportunity, both designers and developers, to build accessibility into the components from the start. By doing this we make sure that the components we use in the app follow WCAG 2.1 standards.

These are the things we improved connected to accessibility

(that you can steal with pride and get started with right away)

1. Components check. We went through all the clickable elements and buttons in the app to make sure the touch areas are big enough.
2. Color contrast check. We did an inventory of all our colors in the components to make sure they have good enough color contrast.
3. Label check for screen readers. We specified how our components should sound when users use VoiceOver or Talkback in their apps.
4. Dynamic text adaptive components. If users have enlarged text size in their phone settings we make sure that our design and text can adapt accordingly.
5. Use of native components. Apple and Google offer native components which already have built-in accessibility. For example, the wheel where you can scroll to select a time or date. We try to use them as much as possible, for example in the sleep timer the native component works much better with screen readers than if we would have used a custom component.

Summary

These are the key takeaways:

1. Start with at least one usability test. Find one user and just test your product. You will be amazed by how many insights you can get from one single user with a disability.
2. Many accessibility features cannot be tested on a design prototype — like screen readers, dynamic text, etc. But they should still be tested somewhere in the process. For example, after the implementation and before it’s released to the public. Make sure you include this in your Definition of Done, so you don’t forget about it.
3. Start small — you don’t have to be an expert. Even small changes are big wins for many users. Just a quick color contrast check or the implementation of native components instead of custom ones is already a win.

Good luck on your accessibility journey! 🚀
Maybe you have already started? What have you learned so far? We are curious to hear your story in the comments!

This article was written by Linnea Berggren and Maria Pustynnik. To our dear colleagues and friends who reviewed the article, thank you very much.

Accessible app design: how to get started was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

We keep hearing stories about superhero developers, teams of rockstars, and dramatic problems that were solved last minute. These stories are fascinating and inspiring, but you don’t want to rely on this way of working.

Inspired by John Cutler’s post I wanted to write about boring teams. Or as Cutler calls them: boringly effective. In the same spirit, I recall a quote from a Swedish soldier deployed to Afghanistan a few years ago, when describing their mission, and the risks of it:

A boring day is a good day

Imagine a boring team. A team where things just work. A team that knows where they are going, knows how to break work down, plan it, build it and ship it. A team that is strong on software craftsmanship, delivers code with high quality that is easy to understand and extend. They write plenty of tests and automate away mundane tasks. If problems are discovered they get nipped in the bud. The team is boring from a no-drama perspective, but they are stable and constantly deliver value to customers. This doesn’t mean it is boring to work in a team like this, rather, it is safe. There can be plenty of big challenges and hard problems to solve. This team will fail plenty, but most failures are small and safe. Failures lead to reflection, learning, and eventually improvements.

This is the team you want, and the environment your organization should strive for creating.

When I hear about an organization that celebrates hero behavior, rewards teams for pulling all-nighters, and constantly enter crunch mode to save a project last minute, I know something is wrong. This kind of drama is a sign things are not working well.

Heroes

When an organization relies heavily on heroes to come and save the day, it is a symptom of several problems. I have observed people hoard information, system access, and knowledge, to constantly be needed. This is mostly a system problem. There is a lack of knowledge sharing, lack of investments in removing technical debt that only the heroes know how to deal with. There is a lack of coaching to help people become unstuck from the hero role, and a lack of investment from the organization to get out of the situation. This can be due to a lack of enough senior engineers in the organization, which in turn often is a symptom of a specific hiring strategy.

Always busy

I have observed both teams, and individuals being measured by how busy they are. We are taught concepts like “important managers have many meetings” and “teams need a full backlog of tasks to work on”. There is a notion that we should always say we are too busy, don’t have time right now, and are working on something more important. Those familiar with lean management and the theory of constraints, know that sweating the assets creates a large work in progress (WIP) and long cycle times (the time it takes from starting work to finishing it). The team will not be able to pick up the most important work when needed. Nobody will be able to work on improvements and polishing, because we are always running for the next project. A system needs slack to be healthy and responsive, and so do individuals. The slack needs to be planned and protected. Priorities need to be clear and constantly updated. Roadmaps need to be regularly revisited and treated as bets or best guesses, rather than prophecies of the future.

Crunching

Recurringly forcing a team into crunching mode is said to be a symptom of poor planning. My observation is that it is rather how the organization and team deal with the plan, and deviations from it, that creates weekends and long evenings of work. If a team is forced to stick with a plan because of an arbitrary deadline, it is the drama all over again. Admittedly, some teams deal with real deadlines (as opposed to sadlines, as stated by Liz Keogh) that have to be met. Unexpected events might occur and have to be mitigated, but these should be seldom and exceptions. Teams that constantly work in this mode will not be sustainable, and neither will their work. You want to make sure the team can keep a sustainable pace, and be boringly effective. Identify which dates must be met (because otherwise people, or the company, might die) and which delays are acceptable and mostly will upset someone.

Taskforces

Another common drama is the creation of task forces. This is a symptom of the organization not being able to carry out the most prioritized work in their current structure. Instead, people need to be handpicked for the job, a tiger team created and the organization yet again relies on heroes (or rather the fantastic four) coming to save the day. Once the problem has been solved, the business opportunity met or the feature built people go back to their original place in the organization, often leaving the ownership of what was just created floating around. The disruption of taskforces can be avoided by adapting the organization to the flow of work. Perhaps team structures need to change more often and reteam.

How to be boringly effective

All of the above are symptoms of problems in an organization. The remedies can vary (it depends) and it is all tightly connected to the context you are in. But the general rule of trying to achieve a calm, sustainable pace and boringly effective team is a good goal to strive for. If there is drama, find ways to reduce it. As a system thinker, I strongly believe that the solution lies in the system surrounding the team, and rarely in the team itself, the manager, or the individuals in the team. Instead, focus on adapting things like architecture, organizational design, transparency of work, priorities, work in progress limits, and knowledge sharing. Focus on improving the flow of work. Don’t reward the drama (the heroes, the crunching, the taskforces). Teach teams to put out small fires early, rather than celebrating huge firefighting efforts. Give your organization the goal of becoming boringly effective.

Applicable everywhere?

During an early review of this text, I got the question whether boring teams really are applicable everywhere. Some companies, like startups, are built around the drama. They don’t have enough resources to have the luxury of being boring. They have real deadlines because missed opportunities might make them irrelevant, or block another round of funding, bringing the whole company down. I agree that there are situations where drama is needed. Where there is enough urgency to get all hands on deck and stop everything else. But the key is to avoid these situations, and this goes for small companies dependent on funding too. We have to build sustainable businesses without constantly relying on drama, heroes, and crunching to meet business goals. My ideas in this area are well reflected in DHH and Jason Fried's books It Doesn’t Have To Be Crazy At Work and the now more than a decade-old Rework. For further reading (or rather listening) I’d also recommend Eliahu Goldratt's classic The Goal and the brilliant book The Phoenix Project.

I’m curious about your observations of boringly effective teams, and where drama has damaged companies. But I’m also curious about situations you might have observed where the drama lead to something good, and sustainable. Please share in comments below.

Boring organizations are the best was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a software engineer at Storytel, I often get to interview candidates for our developer positions at the technical interview stage. I have had so many interesting interactions with our candidates, both good and bad, and over time, gathered some thoughts on what I would have liked to tell them ahead of time, to help bring out the best of them and make the interview a success.

With this in mind, I sat down with a couple of fellow engineers here at the company to write up our most important tips for a technical interview based on our experience.

Here’s what we wish we could have told our candidates ahead of time:

Brush Up the Relevant Skills

We cannot stress this one enough! As a candidate you often know which areas the interview is going to be focused on. If it involves APIs, brush up on the API best practices, response codes etc, security and authentication, or if it’s iOS be prepared to discuss Cocoa design patterns, and data structures and their efficiency are always important for backend positions.

This is actually one of the most important tips that we can give you, as while you might be familiar with these topics, demonstrating your skills in a tech interview is a whole different thing. You might get nervous, not have enough time, be overwhelmed by another question and most likely will not be able to look something up online to refresh your memory — so do it beforehand. Use this time, of the tech interview, to show the depth and breadth of your knowledge, and make sure you use this time to shine!

Communicate Your Thought Process and Tradeoffs

One of the most important things that we try to learn about the candidate during the interview is how they think and solve problems. If you remain silent most of the time, providing only your final conclusion as the answer to questions or when explaining something, it is very difficult for us to understand the tradeoffs and your thought process.

Understanding your thought process can often also be helpful when you don’t have the right answer, we all make mistakes. But if it’s clear to us how you approach a problem then this shines more light on your abilities.

Same goes for home coding exercises. Invest time in explaining why you made important decisions about your project. For instance: what would be different for a real-world application, what was not implemented due to lack of time or resources, and if you choose a programming language that is not your biggest strength, explain why.

Ask for Clarifications

Asking the interviewer questions that help you clarify a topic is crucial in more than one way.

First, it can obviously save you from making mistakes simply because of a misunderstanding or a wrong assumption.

Second, we like seeing that you approach problems with attention, work carefully and don’t jump into the implementation stage before fully understanding what’s at hand. What’s more, this lets us learn more about how you think and break down a problem. So in general, don’t be afraid to ask questions!

By the way, this also goes for the end of the interview. Whenever possible, prepare some questions in advance, as this can be another way to show what you’re interested in and show off what you know just before the interview comes to a close.

Here’s what one of the developers on my team had to say during our discussion:

“It’s always good to ask the interviewer if the solution should be close to a real-world application, or if it’s mostly meant to demonstrate some basic knowledge. It’s one thing to implement a working solution, but for production applications, one should also consider performance, scalability and maintainability.”

Don’t Forget Testing

Testing is a topic that is almost always discussed in interviews. We may want to know, how would you test your code, and whether you considered different corner and edge cases. We want to see that you gave this a thought, have testing experience, know about unit tests versus integration tests and have the right approach to it. Be prepared to discuss this in the code interview and always address it in your home coding exercise.

Here’s an input from one of our iOS developers on the topic:

“I’d say, write tests, even if you weren’t asked to. This helps to verify that what you submit is working, plus it shows you can do that.”

Object-Oriented Programming

Demonstrating a good understanding of Object-Oriented Programming is important to us, as these are the languages we mostly use. When creating your implementation, make sure not to mix OOP with Functional programming design, for example, and show strong knowledge of implementing classes, fields, immutability etc.

Being Nervous Can Be a Good Thing

Very often we notice that the candidates seem nervous, though for us, this isn’t usually a problem — nerves can indicate that the interview matters and that the position is important to the candidate. Besides, we were all on the other side of the interview ourselves at one point or another. If you are feeling nervous during the interview, keep in mind that some interviewers see this as a positive and do not get nervous about being nervous!

Carry on — we are all human, and try to shift your focus on the topic we are talking about, rather than how you are feeling.

So don’t let your nerves ruin it for you, and just focus on the topics we discuss.

On the same topic, next up on our blog is a post on Tips for a Coding Home Project, coming up soon…

Tips for a Tech Interview from Storytel Engineers was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my early days as an agile coach I worked for a company that was thriving in a really complex and volatile business and we also had really happy employees.

You know all those things that the agile community says you will get if you do agile. It was just that, we had not implemented agile or even talked about it… So why did we thrive? It became clear to me that what we had was something way more powerful than the agile tools and frameworks, we were living by the agile values. And as you know culture (your values) eats strategy (implementing a framework) for breakfast. In this blogpost I will share my thoughts around values and agile software development.

The manifesto for agile software development has been around for 20 years! Yes that’s right, the birth of it happened at Snowbird Resort Utah in feb 2001. Isn’t it odd that after all these years the internet is flooded with articles like “How to make the stand up not suck” or “Help my PO is killing team spirit” or anything else centered around that agile is broken and can be fixed.

Most people think agile software development is something that you do, that it is a process and has tools. You just have to learn it and then you are fine, like going from having all your source code on a network drive to implementing a source control system and applying a PR process. But as you might have guessed I think that is wrong.

You can’t do agile you have to be agile

As I said I don’t believe that you can do agile, you have to be agile. Being agile means that you know why you are doing the things you are doing and also that you believe in that why, i.e. the daily scrum is not just something you have to do, rather you truly believe that it is the best way to start the day together with your team. Or delivering a feature before it is gold- or even silver plated is nothing you do because the agile manifesto says we should do early and continuous delivery, you do it because you really want to include your stakeholders on the journey and really value the feedback .

If you embrace that you have to be agile it becomes very clear that it is about values and principles and not about framework and tools. By the way, these values are not the ones that are typically known as the four agile values, these are basic human values.

In far too many organisations (mostly outside software development organisations these days, since agile frameworks are more or less standard here) it goes something like this.

• Hey I’ve read this book about agile, it says you will get double the value in half the time. We need to do agile.
• OK, I hear you but we have tried so many things so this time we need to do it by the book so we make sure we do it right.
• OK, the book says we should have cross functional teams, have short sprints, do daily meetings and retrospectives.
• And so on…

Before you know it you have a full blown organisation by the agile book but you are not getting the results you wished for, instead you get the quotes from the ingress. The reason is that you started at the wrong end. You started by implementing the framework and tools and forgot about making sure that your organisation fosters the values needed to be agile. You are trying to push a square peg through a round hole.

Instead of the daily stand up creating inclusion and engagement people think it wastes their time because they have to listen to things that will not affect them.

Instead of creating teams that take ownership of and deliver value you get teams saying that they constantly are stuck waiting on others they are dependent on. And so on.

So how can you tell if you are on the “wrong” side? Here are a few hints.

• Postponing demos because it is not done. This might seem very obvious since it is part of the 12 agile principles but I have seen it so many times. This goes both ways, developers not wanting to show until it is shiny but also stakeholders not wanting to see until everything is done.
• Opting for output rather than outcome. If you are postponing, or simply not have, demos with stakeholders you will probably sooner or later fall into the trap of wanting to do as many things as possible instead of making sure to make things that create value. That is natural because without a dialogue about what creates value for your stakeholders you will need to define your purpose in other ways and that will be the number of things you deliver.
• People dependent backlog. If you are assigning people to the issues already when they are in the backlog you are a slippery slope that will lead to people availability dictating the prioritisation instead of value. When that happens people focus on delivering their task and not delivering value and if you are focusing on your tasks of-course it feels like a waste of time listening to all others tasks. As soon as you are starting to opt for output rather than outcome you risk ending up here because it is probably a smart thing to only do things that fit you perfectly if you want to do as many things as possible.

An agile organisation is like a pyramid where the values create the foundation, the framework is the top and in between there are principles and methods. If you want to have an organisation that succeeds with the chosen framework, if you choose to have one, you must first have a solid foundation.

So what are the values I’m talking about?

First of all there are some common interpersonal values, trust, respect, honesty, and loyalty, that in my opinion need to be there regardless to have a healthy organisation. In this context though you can’t live by the agile principles without them. I.e you can’t live by the agile principle of self organising teams without them, you can’t live by the agile principle of focusing on value without trust and honesty and so on.

Then there are a few really essential, let’s say more agile specific, values that you must believe in and live by in order to be able to be agile.

Transparency, courage and innovation are all three really key, without them you will not be able to be agile all the way. Let’s take a look at what I mean and put it in the context of some of the well known agile principles, these are the 12 agile principles behind the agile manifesto.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.

Many organisations focus only on the bold text and forget what’s really key to being agile, namely early and continuous delivery. I don’t think they intend to do that, only that doing early and continuous deliveries takes courage, loads of it to be fully transparent and share your day to day progress and setbacks with your customers. Let’s face it, it’s super scary to actually deliver something that you don’t think is done because you might get feedback that suggest that you should shift direction.

Simplicity — the art of maximising the work not done — is essential.

Making something truly simple, both processes and products, without diminishing the value of it, takes a lot of innovation. You also have to have the courage to do something disruptive.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

This is probably one of the most essential agile principles and also the one where it is the most common case of following the framework but not truly living the values. Often when reflecting teams tend to come up with either low hanging fruits like “we take on too much in each sprint” or things that are outside the team like “management constantly changes strategy”. These things are very safe to talk about but it is also not the things that have the most effect on effectiveness. Talking about the things that have real impact on the effectiveness of the team requires a lot of transparency and courage. For instance if you think you are missing the best solution because your teammate constantly is killing the discussions you need to tell that in the retro, that will have far bigger impact than discussion the correct phrasing of a user story.

To reap the full benefits of agile you need to be agile not do agile and to be agile start living by the values and work your way up the pyramid. The first thing we need to do is take the values; trust, honesty, loyalty, transparency, courage and innovation and turn them into verbs because it is so much more powerful to ask “Have you invited and shared your insights with people around you today?” then it is to ask “Have you been transparent today?” or “Today I’m gonna look at the problem from a different angle?” compared to “Today I’m gonna be innovative”

This will also give the added benefit that they will be more tailored for you and your organisation.

So here is my challenge for you. Take the agile values; trust, honesty, loyalty, transparency, courage and innovation. Sit down and define what they mean for you, i.e what does transparency mean, which also includes defining what it is not, in your organisation. Is it sharing customer insights with the team or maybe it is letting people around you know what’s going on in your personal life. Then turn those things into verbs, i.e share your insights with your team or tell your team if something is bothering you in your personal life. That way you can easily talk about them and use them as questions in your team sessions.

The value of values was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Transitioning from maker to multiplier is hard, especially if you are also taking on management responsibilities. About a year and a half ago I transitioned from agile coach to my first management position. My motivation at the time was to become a better coach by understanding the challenges of management. I wanted to learn new skills, and have an opportunity to lead, not just coach, a team. As I am now taking on the mentorship of a new manager, I am reflecting on some of the learnings I’ve had and how my work has changed.

My experience of and long-standing interest in leadership has prepared me well for a role as a manager. Far from all leaders are managers, and far from all managers are leaders. The intersection is powerful, but not enough to be a good manager, and I was new to many responsibilities of a manager.

Changes in expectations

The biggest change in my transition to management has been the expectations of me and the work I do. As an agile coach you are seldom responsible, or accountable for the team’s results. Being a coach is ungrateful, because success is always the team's success, and you get blamed for the failures. But you are not really accountable. As a manager you are. You can be tasked with reaching certain results, fulfilling goals, and meeting deadlines. With that also comes being part of the team’s success. When the team fails, you are not only blamed but also expected to remedy to make sure the failure is not repeated.

The expectation from the team is also very different. People expect you to act on problems and get them solved. They look to you for decisions, and in some cases for a detailed description of what to work on. As a coach, you can stand comfortably on the sidelines and answer most questions with “it depends”.

Dynamics change

With the change in expectations, the dynamics and your relationship with the team also change.

A coach can be the team's best friend. Their focus is to improve the team and the environment. Every failure is an opportunity for learning. It is easy to fall into the trap of blaming managers that are part of the system around the team as obstacles. Team members and other managers can easily trust you because you are not a threat.

Stepping into management these dynamics changes. You now have the power to make decisions that will affect people’s lives. You decide who to hire into the team, and in some cases who should leave the team. You set the salary affecting people’s financials. You also have the powers to tell people what to do, when, where, and how to work (but you’d be damned if you use these powers). People become more careful around you, especially team members. After all, you are their manager and we have been taught from early childhood to be careful around the boss (I’ve started cringing at the stereotype boss described in children’s books and films). Depending on the culture of your organization your peers might now treat you as a competitor for resources, power, fame, and glory. Luckily, at Storytel, we support each other to build the best product for our customers, rather than optimizing for our own territory.

Being a manager you should be more careful about your own behavior. Even though every leader models behavior, people are especially affected by their manager. If you set rules you’d better be the one following them thoroughly. You have to think about how your communication can be interpreted. Suggestions can be interpreted as orders, challenges as deadlines, and disagreements as a risk of being fired.

As a manager, you are now part of the system. You might have to defend decisions you disagree with, without blaming anyone else. Likewise, you will have to defend your team, even if you are frustrated with the situation.

Building trust

For both managers and coaches, vulnerability trust is the primary tool. You have to build trust between yourself and the team members to work effectively. Besides focusing on your own relationships you also have to create an environment where team members can trust each other. I have found that it takes more effort, and is much harder to build trust as a manager. Your team members know you hold extra power and there are more situations where you cannot share information openly.

I view trust as a currency. Once you have collected enough, you can invest some in a hard feedback session or a challenge. As a manager, you will find yourself in situations where you have to deliver hard feedback without having had a chance to build up enough trust currency to do it well. You will find yourself in tricky situations that handled well will build trust with the whole team, and handled badly will decrease the overall trust. Letting a team member go is a prime example of such a situation. Showing empathy for the team and quickly solving a painful situation will build trust, but letting someone go in a bad way will scare people and decrease trust.

A seat at the table

As a coach, it is easy to get frustrated about changes happening to you and your team. You often find yourself on the sidelines when important decisions are made that affect the whole system you are trying to improve. As a manager, you get a seat at the table. Admittedly you are not part of every big decision made in the organization, but you are always involved if the decision directly affects your team. Your opinion matters.

When I worked as a coach I often found myself in situations where I knew how to solve a problem, but simply did not have the decision power to make the change happen. Instead, I had to work through others. As a manager, I do have this power but have to use it carefully. This allowed me to implement a system of reteaming and make other systematic decisions I was comfortable with. With power comes responsibility. A good manager has to work even harder to understand how and why people disagree and be very open about a decision being wrong.

The same dynamics described above apply to the larger organization you are a part of. As a coach, I have been part of several big change initiatives, but I was always dependent on someone else making the decision to implement the change. As a manager, I can either work with other managers to make the change happen or start by doing things differently and then inspire others to follow suit.

Strategy vs tactics

When working as a coach I often found time to think strategically. I could zoom out to see the bigger picture and apply systems thinking to my approach. It was easy for me to be an observer to a lot of the tactical decisions and actions going on in the team. As a manager, my calendar magically filled up with meetings. This is natural, as meetings are the arena where most management work happens. There are just so many of them. I also become involved in an endless flurry of tactical decisions and questions (Slack promotes this bad behavior). I have to fight much harder as a manager to make sure I have time to think strategically. I have also discovered that a lot of managers never do this, they are in constant firefighting mode. Even if it is easy to get caught up I have reserved time for strategic thinking, reflections, explorations, and learning. I constantly have to protect that time from being eaten up by tactical issues that need to be dealt with.

Let it go

In the words of a famous Disney princess — you have to let things go. As a coach, I used to step back to allow the team to fill the void, grow and learn. This was expected of me, as the coach is always temporary and should help the team improve. I am applying the same principles as a manager, but it is much more challenging. Mostly because the expectations of the outside world, and the team, are very different. The process of stepping back is slower, and the team is slower to fill the void. As the team grows I have found the act of letting go is essential to survive as a manager. It is simply impossible to be involved in all the details.

Tips from the mentor

As I step into the role of mentoring a new leader I want to distill my learnings into more concrete tips and guides to make the beginning of the journey easier. I still have a lot to learn, but so far I have found the following to be useful to me:

• Lead the space, not the particles. Or in Drucker’s words “Manage the system, not the people and not the work”. Make decisions and set direction on a systematic level, and not in the details.
• Build your support system. As a new manager, it is invaluable to have a support system around you. Be it a mentor, a group of peers, a coach, or someone else that you can share your pains with, discuss challenges with and look for guidance from.
• Find your partners. Find who in your team, and around your team are your partners in making decisions and implementing them. People that are willing to challenge you, but also ready to disagree and align making things happen.
• Experiment and learn. Don’t be afraid to try things out, but make sure there is a feedback loop. Run the experiment for a while, see if it works and keep adapting.
• Use data. Have a data-driven approach to your leadership, and use the data that is already available to you. Check what effects your decisions and experiments have on the data. Use both available outcome data (looking at customer behavior) but also on output data (lead time of bugs, WIP, and more).
• Coaching is a powerful tool. Use it wisely. I am applying coaching in all my 1:1 conversations, and use it for formal coaching sessions. I have also applied it in more informal settings with peers.
• Remember rule number 6. That means don’t take yourself so seriously. This is one of my most valuable lessons from The art of possibility. You are not more important than anyone else. Your job is just a bit different.

Finally

I am truly enjoying my transition into management, and I am proud of what I have achieved so far. I am constantly learning new things, and I still have a long way to go on this journey. The biggest reward is seeing team members grow, and the team reaching new heights. It’s addictive! At the same time, it is a very challenging journey, and I’ve found myself in deep waters on multiple occasions. It is not for everyone, but if you are curious about management and leadership I encourage you to find a role that allows you to safely try your wings.

Further reading

There are tons of leadership and management books, blogs, and podcasts. As a new manager, I’d recommend reading and listening to a lot, and then picking the raisins out of the cake. There is no single truth and no silver bullets. Learning broadly, experimenting, and learning as you go has been my approach. To me personally, these books have been valuable:

• The Art Of Possibility by Ben and Rosamund Zander. Best book on self-leadership. You have to be able to lead yourself before you can lead others.
• The Making Of A Manager by Julie Zhuo. A great introduction when you are starting your management journey.
• Drive — The Surprising Truth About What Motivates Us by Dan Pink. A must-read to understand what motivates people that do creative work, and why there is a gap between what science knows and what business does.
• Turn The Ship Around by David Marquet is a great example of how to step back from decision making and make space for the team to fill
• The Five Dysfunctions Of A Team by Patrick Lencioni. This leadership fable and model is great for understanding team dynamics, and understanding how to improve your team.
• It Doesn’t Have To Be Crazy At Work by Jason Fried and DHH is a fresh take on the corporate world and how to work sustainably.
• Nine Lies About Work where Marcus Buckingham and Ashley Goodall debunk myths about work using survey data. To me, it was especially eye-opening that people care more about the team they work in and how they manager act than the organization they work for.

Becoming a manager was originally published in Storytel Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.