Technical Leadership – The Leadership Transition
Posted by Sri Subramanian (@whosissri) on July 7, 2011
In Technical Leadership – An Introduction, I talk about how growth is associated with doing different things, and not necessarily doing more. The first change is the transformation into an independent problem solver. The next transition, I call the leadership transition
As we negotiate this next transition, we often get vague advice, such as “be a leader”, or “work smarter, not harder” that leave us intimidated, rather than inspired. In plain words, this next transition is from solving problems to improving how we solve problems. It involves discovering, prioritizing, and mitigating pain points – specifically those encountered by us and our peers. This is when we don’t just do work, but focus on how it is done, and then go on to make it better.
A few of us make this transition just by chance. A few us find good role models and mentors who lead us through this change. Unfortunately, many of us are not so lucky. We either don’t know how to create the opportunity to work at this level, and end up blaming circumstances and lack of opportunity, or worse, we mess it up by trying to do something too big too soon. When we do the latter, we trip over, and get a reputation among peers of talking without knowing. It very much harms our chances of making the transition later on.
So, what is one to do?
A good approach is to start working on small improvements that we know we would want to use ourselves, and do it in stolen time (time spent over weekends, or time gained otherwise). We provide our work to others, but do not require or expect others to uptake. As we observe what resonates well with others, we become aware of pain points that we as a team feel vs. those that we as individuals feel. We then are able to get management buy-in for real time (our own, and sometimes in form of help from others) that can be spent on these activities.
It is also important to continue to work on different types of problems. The pain points can differ depending on the nature of work, and having that 360° view helps us prioritize what we can work on to have the most impact. Should we, as a team, focus first on more modular code, on that merge tool that will do automatic bug updates, or on that diagnostic tool that will help us get all the information for a customer case in one shot?
As we address their pain points, we gain the respect and trust of our peers. We establish ourselves as leaders. It is very important to measure our success at this stage by the impact we make on our peers (including those in other functional teams like QA and support) – and by that alone. The real consumers for our work are our peers, and if we do not make a difference that can be felt by them, we are not adding real value. Moreover, their trust and support is key to the next transitions. Stay tuned for more on that.
The full series of blogs on Technical Leadership: