Opening New Doors

At the end of this month I’ll be leaving my current job to start at a new company in a new town.  I’ll be taking up a position of Technical Lead for a finance company in Dunedin, New Zealand and will also be tasked with providing strategic technical input to the company’s service offerings.

This is the first time I’ve actually had the word “Lead” written into the role, which to many people might be quite alarming.  Why hasn’t this job function been formally recognised before?  The answer is that in all my previous roles, I have built a new team from scratch as a senior developer and the job description has never really adapted to reflect the broadened job functions.  This time I’m going into an established team and therefore a pre-defined recognised position.

Given that my job function will now require me to actively manage my team of developers (as opposed to the implicit “develop first, workload management second” expectation of my previous role), I feel I have finally reached a point where I need to place considerably more focus on my management skills.  This will be a challenge because, like many technical team leaders, I’ve had very limited chances to observe really good management in action.  Much of my line manager’s day-to-day activity has happened “behind closed doors”; precluding me from learning the tasks and challenges I need to understand.  To quote Esther Derby and Johanna Rothman, “poor managers create the illusion of productivity through busyness”.  Fairly or unfairly, my line managers’ productivity has often seemed illusory because it was actively hidden through unshared calendars, high levels of unavailability through absence and a lack of communication.  I should point out here that I am not suggesting my managers have always been unproductive.  Merely that I have not been given an opportunity to understand how they structure their workload to create an effective management style.

So I have elected to seek out an alternative source of management training in an excellent book called “Behind Closed Doors” by Esther Derby and Johanna Rothman.  As I progress through my new role, I will be writing here about my experiences in learning about the people and the work, building the team and its capabilities and identifying areas where my team can add real value to the business overall.  I’ll look at how the development team’s commitments and capacity are placed and how I can strengthen the team’s processes and throughput.

My next post (due at the end of June) will look at my first week on the job and the challenges I face in learning a new company’s products and services, my team’s role in facilitating those and how I ease myself and my team through the processes of Forming, Storming, Norming and Performing.

My hope is that these regular posts provide some valuable insight for others in similar situations.  I would be very surprised if I was the only one who found himself faced with these new challenges and hopefully I can pass on some experience and useful ideas to you along the way.

On becoming a Team Lead

Team leadership

I’m a bit stuck.  After having held the position of Technical Team Lead in my last three jobs, I’ve lately come to a point where I’ve started to do some reflection on my qualifications and experience and question what exactly it is that the role of Team Lead means.

The thing is I’ve only been in this development game for about six years. I finished college in 2002 where I’d majored in programming (VB6 was standard at the time) and project management and took up a job in the capital as a security administrator for just under a year before landing a job in a software shop as a helpdesk operator. 18 months after bagging and tagging calls, I finally managed to negotiate (or at times, even force) my way into a role supporting the company’s smaller ASP applications.

Not having ever worked on websites before, this was a considerable amount of learning for me. I then moved on to ASP.Net and started teaching myself C#. Over the following two or three years I built up a team of (typically) graduate developers to help me as the workload grew. Being the incumbent, I was informally given the title of Team Lead.

Now having moved on to a new job at a financial institution, I find myself again with this informal title of Technical Team Lead. I believe that – again – it’s not because I’m the most proficient, knowledgeable or even necessarily competent person on the team; simply that I’m the guy who said “yes” when the manager asked if I’d like to head up its formation.

So here I am after two years in the role and finding that in reality, I’m not actually that well-versed in the basics. I’m having to remind myself what the point of interfaces are and how abstract classes work at a fairly rudimentary level. I don’t really know how to apply design patterns to my code or even what many design patterns are, for that matter. I blurted out to one of my team that I didn’t know what Domain-Driven Design was today. I now feel I must learn and understand it.

The problem – for lack of a better term – is that I’ve risen to the position of Team Lead quite quickly. I haven’t built up my core knowledge and experience as thoroughly as my peers because I’ve often been concentrating on a broader range of responsibilities. In my roles I’ve been responsible for reporting, invoicing, timesheet approval, documentation, design, architecture, customer meetings, requirements gathering… all manner of things that aren’t related at all to actually writing code.

So does this mean I am right to be concerned about my qualifications to lead a team? Well, yes and no.

The first point to note is that, at least in my experience, the role of Team Lead is one in name only and is rarely recognised formally by the organisation. All the company wants is a senior developer (typically with 5 or more years experience) who is prepared to sacrifice some of his involvement in the core development process for the administrative and project coordination tasks that are effectively outside a “regular” manager’s field of expertise. The Team Lead will be able to see the tradeoffs between the various technical aspects of a project while being able to clearly communicate relevant information to the business or client in non-geekspeak. In other words, leading a team is not entirely about having the highest level of technical skill out of all the other members; it requires equal measures of people, communication, writing, and time management skills as part of the day-to-day routine.

The second point is that I’ve risen from a support desk analyst to senior developer in a fairly short space of time – about 6½ years – which (I like to think) is some reflection on my abilities. However I do recognise that this has come at the cost of not having obtained some of the core experience that might otherwise be expected of someone at this level. Still – a key part of solving a problem is recognising that the problem exists in the first place and being willing to act on it. That is where I find myself today: identifying gaps in my knowledge and creating a set of personal plans and goals to correct those gaps.

So over the course of this blog, I am going to chart my thoughts, challenges and personal lessons in my capacity of Technical Team Lead / Self-Doubting Developer. I’ll look at how I started in the team lead capacity by growing my own job function, growing a team around me and what sorts of events and capacities I’ve worked through since.