Syntax Highlighting

Tuesday 14 July 2015

Talking with tech leads: James Gaisford

At the end of last year I was offered the role of Head of development at my company. Having been a reluctant senior developer, I was a little reluctant to take the role, but after some careful consideration I accepted the offer. As with previous career challenges, I sought advice and guidance from the internet. But the best steer came from an unlikely source - a tweet from Martin Fowler

The book referred to in the tweet is called "Talking with tech leads" and it is a must read for all developers thrust into the strange and unfamiliar world of leading a technical team. The book takes the form of interviews with a number of tech leads, asking a core set of questions particularly around significant challenges faced and how they balance the technical and non-technical worlds.

So, after my first six months as a tech lead, I present my answers to those same core questions asked in the book.


What should a Tech Lead focus on and why?

Solving problems without coding. As a developer your core skill is to be able to solve problems by coding. This is a skill that has been honed over many years. It is very tempting as a developer, new to the tech lead role, to offer only code based solutions to customer problems, but stop. and think if there could be a non-code based solution to the problem presented. Pushing back on client requirements? Negotiating with project managers to get additional resource? Scrutinizing client requirement documents? Writing tight functional specifications. All of these and other non-code based solutions can come to your rescue. Expand you toolbox. 


What has been your biggest challenge as a Tech Lead?

Don't over-commit.... and delegate. With a new role comes a lot of new responsibility. This means a lot more work. Depending on the set up in your company, there may be an expectation that you still perform some or all of your previous role's responsibilities as well. You will be asked to do a lot, but don't be afraid to push back, to say no. You may have a team to whom you can delegate some of your work to. Don't be afraid to use them. No one will think you are incapable, slacking off, or being lazy. In fact, if the team is good, they will relish the challenge.... just don't over do it.


Any time-management tips?

Get in early. Process emails. Work out a plan of attack for the day. Create a simple list using a pen and paper - I know, it's pretty revolutionary - in priority order to work through. Close the inbox. Cross through items on your list. Its amazing how that simple process can help feel like you are "winning" t the day. Decline any meetings invites that aren't relevant. And for those meetings you have to go to, make sure there is an agenda with a clear purpose, and any actions noted.


How do you strike the right balance between writing code and dealing with other issues?

This is really tough. The thing that makes this easier, is knowing you have a team of people who are as good, if not better, than you at coding. So, there is no need to worry that the code will get written. Of course you should always try and devote at least some time in your week to writing code, but nothing that will take longer than a day and nothing that would jeopardise the project if you had to drop it.... which you most likely will.

1 comment:

Unknown said...

As someone who moved from dev to a 'Director' role, I can say this is good advice!