Technical Leadership – The First Transition
Posted by Sri Subramanian (@whosissri) on July 2, 2011
In Technical Leadership – An Introduction, I claim that real growth involves changing what we do. This post is about the first change.
We join the workforce as interns or college recruits with limited work experience. We are eager to learn, and to work hard, but need to be told exactly what to do, and, at some level, how to do it. Oh, we are expected to have some basic skills, and even some self learning skills. However, we do need a lot of guidance. We need training programs, pointers to documents and books, and someone overseeing the results of our work.
The most common error as we make this transition is not knowing when to ask for help, and when not to. We know that in order to make this transition, we must first show that we can address the current well defined problems with little outside help. In an effort to show this, we end up not asking for help at all. The result is that we sometimes take inordinately long time to do what could have been done very simply. When this happens growth opportunities come slower.
On the other hand, asking for help for everything, can leave our colleagues frustrated, and become career limiting.
So, what is one to do?
A good approach is to take every opportunity to succinctly talk about what we are doing – at the manager staff meeting, at the water cooler, at lunch with friends and colleagues. By sharing what we are trying to figure out, and how we are approaching the problem, we give our colleagues the opportunity to give us those pointers – to docs, training, and other resources – that can help us achieve our goals faster, and demonstrate growth potential.
Often, developers associate this transition with going from bug fixing to writing features. It is not. A simple, well defined problem may be a bug, but it is a certain type of bug. [A hello world (or such) program is also a well defined, simple problem - though of little use to a typical workplace.] Working on a race condition bug, on the other hand, is a loosely defined, complex problem that is worthy of a senior developer who has successfully made this transition. In fact, the most complex issues are often issues with code already written and in use by customers. The live customers add some very interesting complexity to any problem
In order to make the next transformation, one needs to work on different types of loosely defined and complex problems – difficult bugs, customer escalations, feature development, tool development, etc. – but that is a topic for the next post
The full series of blogs on Technical Leadership: