Skip to main content

Posts

Showing posts from 2021

The thing I wish I knew before being a team lead

On the heartbeat podcast, host Claire Lew has a question that she uses to ask to each guest: what is one thing or several things that you wish you would’ve learned earlier as a leader? While listening to the podcast I've often wondered how I would answer that question, and I've had a few back and forth , until I settled on the classic the higher you rise the less power you have. You have more influence, but less power . This seems intuitively true to to me, and it does reflect in the experiences I've made in my personal journey, from individual contributor, to team lead, to lead of leads. However, I always had this sense of guilt about it, because it states a true condition but not how to operate within this condition. Sure, one way to address it is to write,write, write or repeat the messages, but those seem means, rather than an end. Instead I was looking for an end, to justify those means and to use them coherently. The answer came to me, rather unexpected, as these thin

Show me

Fewer things have affected my leadership style in a direct, practical, quick-turnaround way than the Toyota Kata "show me". The picture below (link from O'Reilly Toyota Kata excerpt, found via Google) summarizes it, albeit in a short, easy to overlook form: From: https://www.oreilly.com/library/view/toyota-kata-managing/9780071639859/xhtml/spart4.html. For those with the physical book it's at page 225.   "Show me" is the mantra-ish question I ask whenever someone comes up with a proposal to do something, without clearly stating, or being able to explain, what is the root cause of the problem they are trying to solve. I am sure we all have experienced this, for example: a user asks that we add a feature so that they can edit a certain record, which is intentionally not editable. They might ask this because they often make a mistake in another part of the app, i.e. because of bad UI/UX. In this case we want (and have!) to fix UI/UX rather than adding another

Everything is a negotiation

I find that most people employed in ICT know what a negotiation is, yet they inevitably fail to see one, even when it's placed right in front of them. I don't know the reasons (maybe our compulsively rational, binary mindset?) and I don't plan to study them. I will however claim,  rather ambitiously, that if we realize that everything is a negotiation, and deal with it accordingly, we can greatly improve the way we work together, and also be more effective. Some examples: a colleague reaches out to me and suggests we buy support for the Open Source monitoring product we use, because it's critical to our infrastructure. I say no, briefly arguing my reasons. We reach out to another team and suggest a change, they decline it. Are these negotiations? yes! and no! Yes, well of course they are: as the title says everything is a negotiation. At the same time, the conversation stops short of  the discussion with the intent to find a compromise , so it's only just a potenti

Reflections on imposter syndrome

Each week, in our weekly team meeting, we set out to explore complex/interesting topics. Recently we touched on learning to learn, and imposter syndrome came up, while discussing what can and what can't enable a "being good at learning" disposition. I'll admit that so far my reflections on imposter syndrome stopped at the personal belief that, if one can harness it, it can be turned into a positive force, a force that will encourage us to double-check our work, reduce bias, foster capacity to incorporate feedback, and thus lead to better, more sound results overall. In the weekly meeting multiple, different point of views were offered, and while considering this diversity it dawned to me how much of my own point of view is born out of my generally positive experience of working in ICT. I started out in 1996 when, at university, I was first exposed to computers, Linux, and the internet. I was lucky because the internet was just starting out, and so was I. Things were n

Team mgmt patterns in Moneyball (movie)

Recently, I watched Moneyball  ( IMDB ,  Rotten Tomatoes ) again. Moneyball tells the story of Billy Bean (Brad Pitt), a baseball team general manager who has to put together a team with a tight budget. After unsuccessfully asking for more money, Billy and his assistant Peter Brand (Jonah Hill) pursue a very atypical management choice for baseball. What convinced me to write this post is that in the movie I saw some team patterns that I apply, and encourage others to apply as well. This post is about these patterns. Spoiler alert: if you haven’t seen the movie, consider stopping here. If you have, or don’t care, carry on.