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.

Following By Example: The Role of Effective Leadership

There are any number of things that can work against a TTL‘s ability to perform his or her job effectively. These might relate to infrastructural limitations (i.e. availability or connectivity constraints), restrictive policies (e.g. information restriction, defensive internet / website policing), environmental inhibitors (e.g. fragmentation of time, noisy or interruptive work area, physical separation) or inter-personal difficulties (e.g. siloed specialist teams, dependence on (groups of) individuals with other priorities or skill sets, availability of key personnel).

As the TTL, it is typically your role to ensure that team members are shielded as much as possible from counter-productive working conditions; minimising their effects where possible and trying to effect some change where practicable. However trying to achieve this on your own can be taxing at best and near-impossible usually. This is where your own line manager comes in. Just as it is your job to work on clearing the path for your team to work at their best capacity, so it is your manager’s responsibility to enable the same for you. Having an effective and actively engaged manager is a – regrettably – often rare privilege.

Engage with the team and understand their project

Having an active interest in the project helps ensure the development team feel recognised, appreciated and valued.  This doesn’t mean taking an active hand in the running of the team, micro-management or making decisions on the team’s behalf, but just having a physical presence adds a great deal from a psychological point of view.  The TTL will generally feel that their work has visibility and adds value, the fact that management aren’t interfering but still taking an interest sends the message that they are on the right path and the TTL will feel that issues or problems will be taken seriously and can be addressed easily because the manager is readily available for those types of discussions.

Support your Team Lead and back their decisions up

Typically the TTL role has only implied authority but no formalised line management, financial responsibility or personnel (hiring) authority.  Therefore, when the TTL makes a strategic decision or delivers a communication around a particular issue, it is reasonable to expect that such an act is well-informed and well-intentioned.  In these cases, the TTL needs to know that their line manager has faith in their ability and will support their decisions.  If  the manager just sits on the fence or tries too hard to please everyone, then the risk arises of an implicit message, “You have no autonomy or authority and I will undermine your decisions if they don’t fit my personal style”.

This form of Defensive Management is destructive and shows that the manager doesn’t trust his / her own people.  People who feel untrusted have little inclination to feel engaged in their company or to bond together as a team.

The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded.

Respond to TTL communications and proposals in a timely fashion

It’s to be expected and quite understandable that managers are typically busy people and are often away from their desk. The usual approach to this is for the TTL to send an email asking for a response or an approval for a particular action. Not responding (or – at a minimum – agreeing to respond by a certain date) sends a dual message of “Not only am I not physically present when you need my input, but I don’t view your communications as being important”.

This point relates to the previous in that a development team, and the TTL in particular, rely on the reassurance that the team is headed in the right direction.  Think of it as the “I told her I loved her when I married her” style of management.  If management aren’t treating issues, communications and requests for action with an audible degree of urgency (even if the response is, “let me think about it and get back to you by…”), then the team members are left to fill in the blanks to their own detriment: “my manager doesn’t respect this team”, “this company doesn’t care whether this team performs or not”, “I only hear back from my manager when something goes wrong”.

An effective leader is one who doesn’t need to interfere, audit or control the operations of a development team, but is available for discussion, makes a physical effort to show their presence on a regular basis and acts quickly on communications sent by the TTL or team members.  He or she will give the TTL freedom to act in the best interests of the team they are leading and the freedom to be wrong in the manager’s eyes.  In short, they act in a way that sends the implicit message that the team’s efforts are valued, respected and visible to those outside of the immediate project.

Recognising a team’s work and their efforts regularly demonstrates tacit approval, encouragement and respect.

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.