• Let’s start this post by a great generalization of the difference between a manager and a leader that was voiced out by Brent Jensen and Alan Page in their A/B Testing podcast Episode 211: Leadership Stuff:

    How I know if someone’s a leader? They have followers.

    The hard thing is - what is the follower?

    What is the difference between a direct report and a follower?

    A follower follows you because they want to.

    OK, why?

    Because they want to, because they believe in what you’re doing for the organization. They believe that you can achieve results with them.

    Or whether they believe that your path is beneficial, right?

    Followers choose their leaders based on their own understanding of what is beneficial for them. And it is easy to spot that being promoted to a manager does not make you a leader.

    Further in the podcast, Alan mentioned John Maxwell’s “5 Levels of Leadership” where Position and Permission explain the difference in more detail.

    Finally, in most cases one does not need a Position to get Permission - I saw many examples of how leaders stand out from the crowd naturally when there was an issue or a demand that they can address. One does not need to have a title to provide some benefit to the “followers”.

  • Recently I had a chance to explore in more detail how platform engineering teams work and reconsidered the topic of being a manager vs being an individual contributor (IC). BTW, there is an amazing A/B Testing podcast episode on that topic as well.

    It took me some time to understand that to influence the end result (i.e. Product), platform engineering teams focus on improving the engineering experience first (as engineers are the customers of platform engineering teams) by providing tools, training, resources, etc. And who may have thought - you should think not only about the quality of your product/materials, but also about “go-to-market strategy” - how to make your product adopted by engineering teams or single ICs?

    The more I thought, the more I started seeing my current role as a single platform engineer role building (and “selling”) testing tools for others to use. In a way, the more modern the testers are, the more I see them as platform engineers - building for others, coaching, enabling, empowering…

    However, I struggle with the “selling” part. I struggle with how others adopt whatever there is to adopt. I struggle to communicate the benefits. But it was not always like that…

  • Reflecting on a lot of successful (a.k.a. well-adopted) events we made (academies, hackathons, meetups, a conference, etc.) I noticed that the road to success was based on balancing the quality of the content with the focus on the user experience.

    “You’ve got to start with the customer experience and work back toward the technology — not the other way around.”

    - Steve Jobs

    I remember how at some point after one hackathon we were planning the next one and we needed to re-design the concept from scratch just because of the user experience alone - it was unacceptable to make participants wait for 3 or more hours at the end of the event while the jury is checking their code. As a result, the solution checking process was adjusted to eliminate that waiting at the end completely resulting in a way better UX during the next event.

  • Reflecting on my success (and failures) as a leader in the field of testing/QA/quality, I have to say it is a mixed feeling. Trying to evaluate that from the perspective of my “followers” and what kind of benefit they saw in me - my initial answer is “technical” (programming-related). Test automation advice, performance testing solutions, coding patterns, debugging, and similar things. Such things result in rapid feedback typically (fixed error, working solution, passing test, etc.), while analytical advice, critical thinking tools (models, heuristics), and any other tooling for thinking - the benefit of the latter is not that obvious to the follower. Or maybe the idea that one’s own thinking is flawed is not that easy to admit?

    Also, it is very possible that this evaluation is skewed for the same reason - availability bias due to the different nature (and speed) of feedback.

    But my general observation is that ideas with slower feedback (or slower return) is harder to sell. The benefit of such an idea is not always here and now. So, how do you sell then? Same strategies that worked for a tech lead will not work here (for a thought lead).

  • Finally, something to try out - WorkLife with Adam Grant podcast. After an open discussion (related to similar things - team’s engagement, how they adopt things, etc.) I received a recommendation to listen to some particular episode, and I got hooked up. Following the theme of this post, I can recommend The Three Big Myths of Mentoring, but as I (did some heavy driving recently and) listened 15-20 of them already, I can say it is well worth exploring more topics as well.