menu

[Episode 1] A Day in the Life of a ThoughtWorks' Tech Lead: Robin Doherty

Meet Robin

Robin Doherty

Robin lives and works at the smallest TW “office" in Australia, in Charters Towers, North Queensland.

He enjoys cooking up a feast for his friends and family (often on the BBQ) and frequents the local festivals (think burnouts, dirt, and bad country music) and pubs. Robin has a passion for technology and cats. He will one day design a robot that converts cat behaviour into spoken demands. Then his pet cat Duncan will truly rule the world.

Robin serves ThoughtWorks Australia as Regional Security Champion / Lead Security Architect / Tech Lead / Developer. He provides information security assurance and assistance with secure software delivery practices to all of our software delivery teams and acts as an internal consulting service on security matters to ThoughtWorks consultants. He also takes responsibility for security capability development within ThoughtWorks Australia.

Robin is also a software developer in the ThoughtWorks’ Identity team, a globally distributed team that is responsible for ThoughtWorks’ identity service.

What does a Tech Lead actually do?

Taking an active role in producing the software with fingers on the keyboard is essential, and a tech lead’s job is not to 'do the hard stuff.' You don’t want a one person silo of technical knowledge in your team – this gives you a bus factor of 1, which is bad. So the tech lead’s role includes programming, like any other developer in the team.

They also play a role in leading the technical team, which is far harder to define. It includes taking some responsibility for the professional development of the other members of the team, and taking accountability for the strength of the solution, both in terms of its appropriateness for the problem being solved and its technical strength. This means that the tech lead's role involves a lot of communication (and hopefully influence), both within the team and beyond, with stakeholders, other technical teams and other parts of the organisation.
 

Team at workWhat does your typical day look like? 

My days are rarely ‘typical’ at all, because my current role is quite unusual. In fact, I have two roles, and both require collaboration with team members in far-flung time zones, so my work day is very different from most ThoughtWorkers’.

What’s the most challenging part of your job?

The most challenging part of any job in the software industry is a cliche – it’s people. This is particularly true for the job of a Tech Lead. Most times when I'm working on a client project, my job is about interacting with other people. I very rarely spend time alone writing code on a keyboard. As I said before, I always program with a pair, so even then, communication is just as important as technical expertise. I am always communicating with other members of my team, and with people outside the team. Even the code I write is communication – the most important thing about the code is for it to be understandable and easy for other people to read. Sometimes it’s technical communication, and sometimes it’s not. Being a good communicator (which includes being a good listener) at all times is challenging, and there’s always room for improvement.

What are you measured on?

I am measured by the client on the success of the project. That usually means delivering a robust solution and solving the right problems. Teams achieve that when their culture and ways of working are effective. Unfortunately, to an outsider, that effectiveness is hard to observe, and it's much easier to influence negatively than positively. The benefit of delivering software (business value) incrementally is that the “success” (or lack thereof) is visible to stakeholders, which facilitates better decision making.

I focus on building and maintaining a good team culture, and fostering the right skills in the team, and when I am able to do that well, it leads to success in all useful measures.

What makes a good Tech Lead? 

Consciously develop and exercise your skills of communication and influence. They’re required for most of your job.

Build a broad and deep understanding of the project and the software. It’s a myth that you must be either a “big picture” person or a “detail” person. A tech lead needs to be both.

Understand the people on your team, let them use their skills effectively, and foster their professional development. Direct the right kind of work to the right people (it makes them happy, and that makes your team successful).

Build a strong team culture. Easier said than done. A part of this is setting the example of how you want team members to communicate with each other. I think a strong feedback culture is important for teams to grow together, and so that is something I explicitly say, and try to model myself.

How do you balance coding/non-coding responsibilities?

The challenge is often in ensuring that I have enough time set aside to keep my thinking grounded in the code. The extent to which this is necessary, and the methods for doing it, vary necessarily from project to project and team to team. Depending on the client, project, and team, I try to set aside a portion of my time (30%-60%) for this purpose.

I've found "core pairing hours" a useful way to achieve this, and sometimes it's best to block certain hours of the day out of my calendar for that purpose. I always pair. It's important for me to hear others' perspectives and be part of the knowledge sharing within the team – making any one person a single point of failure for any part of the code is a recipe for disaster, especially when that person has a role that requires a flexible schedule.

It's important to remember that being a tech lead doesn't mean being the most knowledgeable or most proficient coder. If you are forced to take that role, my advice is to immediately begin work on your transition plan – figure out a way to enable the team members around you to take on more responsibility – lest you become indispensable (which is stressful and unproductive).

On your current project, what technology has you most excited?

I enjoy working with any technology that helps me or my team deliver better software, faster.  I am a big fan of Clojure for that reason, and currently, Serverless (the paradigm and the framework) is saving me a ton of time and effort.

More than any one technology, I am excited by solving problems that are interesting to me. Right now, I’m working on device management for ThoughtWorks. I’m enjoying the challenge of doing that in a privacy-respecting, transparent way. The code will be open source, at least internally, and we’ll have a way to allow TWers to see the limited set of data collected about their laptop.

My role is split 50% in Identity and 50% in InfoSec and in this project, I’m developing a thing for Identity that’s really useful for InfoSec – I’m my own happy customer. As a ThoughtWorker, I’m happy to be able to trust that my privacy is not invaded, and from an infosec perspective, it’s important to be able to tell our clients with certainty that yes we enforce security for our laptops – encrypted, with strong passwords, antivirus and firewall.

How do you balance your role as a consultant, with the role of tech lead?

The best tech leads are excellent consultants. Being a tech lead demands excellence in communication and influence, as does consulting. I see this as one role, not two.

I love being a consultant because… 

I enjoy variety, learning new things (quickly), and working in teams. Working with different clients in different industries on different kinds of projects with different technologies and people means there’s rarely a day that’s just like the last.