Employers need to adopt fluid structures for people to find balance in their role, technical and managerial paths should lie side by side, you can’t have genuine effective growth without psychological safety, and a good mentor with whom to talk about problems and scenarios is invaluable; these are some of the reflections on technical leading brought up by Julia Hayward, technical lead at Redgate Software.
Julia Hayward shared her reflections on a year of technical leading at Agile in the City Bristol 2018. InfoQ is covering this conference with Q&As and summaries.
Becoming a tech lead shouldn’t involve career risk, argued Hayward. It should be possible to change your role back to technical work without having to answer why.
Hayward stated that "As a tech leader you need to measure your impact: what has the team produced vs what would they have produced without you."
If you don’t trust your team, that’s your problem as a leader, not your team’s problem. She suggested getting coaching to find solutions for dealing with that.
InfoQ spoke with Hayward after her talk.
InfoQ: You mentioned some of the anti-patterns that can create a chasm between developers and managers. What are they?
Julia Hayward: The most significant chasm comes in companies which see management and development as distinct skillsets, and have a two-track organisation - that is, actively locking their talented developers into purely technical roles while others are brought in to manage them. This happened to me early in my career, where I was refused a promotion on the basis that I was "too valuable as a coder", and a junior salesman was promoted over my head.
Certainly some developers do wish to stay purely technical, and I wouldn’t want anyone to be pushed into more managerial roles against their will. But this two-track scenario leads to a culture of "us and them", where decision making often happens without enough technical context, where developers can’t broaden their view and skill up to take on wider responsibility, and the inevitable communication failures breed suspicion and cynicism.
A second scenario is where there are opportunities for technical people to take on managerial responsibility, but it’s a one-way process - the managerial side of the role dominates to the exclusion of the technical side. It’s also very often coupled with status and pay - so that if the newly fledged manager finds the role doesn’t agree with them, it’s very difficult to return to a more technical role. If technical people perceive taking steps into management as a fundamentally risky career step, many will shy away from taking them even when that would be a positive move.
InfoQ: What are the cures to these anti-patterns?
Hayward: Employers need to adopt more fluid structures so that people can find balance in their role. Technical people should be encouraged to broaden their skillsets and take on some degree of management responsibility, but in a safe environment. Managerial roles should be there to serve and support the developers creating value. And technical and managerial paths should lie side by side, allowing people to pivot in either direction as they grow.
InfoQ: How does the tech lead role look at Redgate?
Hayward: After a major reorganisation in 2016, Redgate completely overhauled their technical structure and could devise a new tech lead role more or less from scratch. As a tech lead, I spend about half my time hands-on with my team - coding, reviewing code, and investigating support cases. The other half is a mixture of line management, liaising with other parts of the company, advocating for the team, and assisting in their personal development.
I work very closely with my own development lead, who is a great mentor when I’m developing my managerial skills, and who trusts heavily in my technical expertise. It’s a very interesting role and gives me a lot of scope to shape my career around what I know I enjoy doing, as well as progressively taking steps into the unknown. For example, I’d never seen myself as a potential conference speaker until Redgate gave me an opportunity - and a gentle push - to try it at our first internal conference early this year.
InfoQ: What lessons did you learn as a tech leader?
Hayward: In moving from an exclusively technical role, I basically fell into three major traps. Firstly, as a new manager my life became a lot less predictable and linear, and the range of tasks that could come across my radar broadened rapidly. Delegation was hard at first because I wasn’t sure what I could safely pass to the team, and how much scope I had to push back on intrusions into my schedule. Prioritisation was an order of magnitude harder while I was developing my understanding of the relative importance of tasks - often I felt I was trying to compare apples and pears. It’s an ongoing lesson for me to discern the value in everything and proactively defend my time.
The second trap was still wanting to be the skilled developer taking on the most challenging code. "It’ll be quicker if I do it" is such a temptation! It was hard to let go of measuring myself by how fast and reliably I could turn around features, and instead measure my less tangible contributions to the team’s output. I’ve learnt that the team as a whole functions at its best when I clear more peripheral and smaller technical issues out of their way into my broken-up schedule, creating an environment where they can be in full flow on very difficult problems. And it’s a great feeling watching them grow into domain experts that I trust absolutely.
Finally, when I accepted the role, I had a vision of myself as a magnanimous manager defending the team from all the jobs they considered unpleasant. It took time to understand that I was denying them good opportunities to develop their own skills and that delegating judiciously was an important part of preparing those who were considering tech leadership in the future. I also needed to make sure I was still enjoying my role, making sure my technical skills weren’t going rusty, and spending time on my own personal development.
InfoQ: What makes it so important to create psychological safety for teams?
Hayward: You can’t have genuine, effective growth without psychological safety. Growth requires regularly stepping outside of your comfort zone and putting yourself in emotionally vulnerable situations. I ran an experiment on my team, colour-coding post-its on our team board by age, trying to understand what tasks they procrastinated on and why. One of the factors making the team reluctant to pick up particular items was the perceived consequences of failure - for example, no-one wanted to be the one to pick a bug only to find it intractable and have to say so at standup.
Building the team’s confidence that they are in a completely safe environment has enabled them to experiment with new skills such as presenting talks, take on technical challenges where the outcome is far from assured, and be much more open with each other. Our retrospectives have become more candid and honest, and we’ve attempted ambitious projects that we would probably have shied away from a couple of years ago.
InfoQ: If a person with a technical background and experience would like to become a technical leader, what advice would you give?
Hayward: Take every opportunity you can to broaden your skill set, and remember that interpersonal skills are hard! Having a good mentor to talk problems and scenarios through with will be invaluable. Much of what you already know from being a great development team member will carry across into being a great technical leader; understand the environments that you are able to flourish in now, because your job as a leader will be to recreate those environments so that your whole team can flourish. Practice being an enabler as much as an individual contributor, and learn to celebrate everyone’s success. It’s a fantastic feeling when your team achieves something big together, even if you can’t always put your finger precisely on the part you played in it!
