Becoming a tech lead

In this post I aim to give a high level overview of things I have found useful balancing work and life while working as a lead software developer, which is no easy task!

A new side, becoming a tech lead

It seems the more senior developers like me get, the more we can be pushed into 'manager' roles. I've been told I'd make a good manager, however I want to remain 'hands on' and focus on where I can add the most value - architecting technical systems working alongside the team leading the direction rather than above them.

I have worked to develop new skills in leadership, working alongside a team of computer scientists. Part of being a tech lead means delegating interesting challenges to the right members in the team and helping them to break down the challenge into achievable tasks - we each 'own' our own projects and estimations. I lead the team to achieve a larger common goal together, rather than working alone. The overall aim is to remove all knowledge silos so we can scale and grow together as a team using the latest tools and techniques.

Roadmaps

An important part of leading the tech strategy is having a vision to come up with a roadmap which breaks down my overall vision into very achievable parts. I prefer to break this down into quarters (Q1, Q2, Q3, Q4) made up of high level epics. Later on the epics are broken down into stories by each developer which are then estimated and assigned to sprints.

Alignment - I align the technical roadmap with the needs of the business with product developers, to make sure we deliver the right things in a way that is understood by the non-techical side of the business.

Vision - I see the big picture and create achievable roadmaps to transform legacy systems incrementally to use the latest in microservices architecture and identity access management. Ensuring we use the latest standards and security practices is of highest priority.

Incremental - The key here avoiding over complicated 'dream' big bang type approaches which are unachievable and focus on what can be done one step by step with small incremental improvements.

Visualise - I also visualise the architecture and how all the systems communicate which is key to get everyone to see things the same way. OmniGraffle is pretty handy for this with high level diagrams of systems and the relationships between them.

The Human side

Acting as a Mentor - I have mentored new developers completing computer science degrees, as well as senior developers, by sharing knowledge and allowing them to avoid common mistakes, bugs and issues. This also includes warning about burnout and preventing others from taking on too much in a sprint, personally I am against others doing any kind of overtime and overpromising - personalTime != companyTime.

Catchups - I run weekly 30 minute one on one catchups, it is always surprising what comes up and what I can help with personally or resolve blockers in communication to the rest of the company.

Code reviews - I prefer to do them from git diffs, spot mistakes, common problems and bugs, helps the team as a whole improve knowledge and learn from mistakes - I recommend reading How to Do Code Reviews Like a Human.

Presenting Ideas and Achievements

I have presented complex technical roadmaps and achievements to over 50 partners and stakeholders in a way understandable to all. Public speaking is naturally a big fear of mine like many others with nerves and anxiety, but, I am now able to control this fear and deliver clearly. I am always surprised to hear from the audience how well it went, and it is a great way to bring everyone on board with my vision.

Finding time to code

I work on a makers schedule, I try to spend as much time as possible in the code base in addition to leading the team. I do this by blocking out entire mornings or afternoons in my calendar with 'Developer Make Time', and try to force meetings to occur outside of these times. It can be hard to get the rest of the company to respect the make time blocks in the calendar but it is important to protect productive time. Be firm (but friendly) about your unavailability.

I work part remote. Office time for me is where I take part in meetings, freeing up my remote time to spend on coding. Some weeks this unfortunately does not go to plan, but it's a good balance to aim for the best of both. 21 Tried-and-True Tips For Remote Working.

With non-technical companies it's important everyone respects that developers need to focus, open offices usually mean headphones are usually on to avoid distractions and unnecessary context switching.

Focus on what is most important

I enjoy taking on ambitious creative challenges. I am driven to achieve them and am optimistic. With the fast paced world we live in there are endless incoming opportunities, it is impossible to accept all of them, and impossible to keep everyone happy. Ways I can keep focused on what I know is most important:

• Maintain boundaries by rejecting the things that don't match with my vision
• I stay focussed on the most important 20% in order to deliver the minimum viable of new ideas first before doing the 'nice to haves' - Product strategy means saying no
• Knowing what is in my control vs not in my control, and only caring about what I can control.

Leading myself and being emotionally intelligent

Part of leading is being able to lead myself too! I have learnt it is important to be self-aware. The aim is to make controlled decisions and communicate clearly. After doing a Lumina Emotion course, I found I was:

• Optimistic - I am positive with an upbeat and enthusiastic attitude and believe I can achieve my vision. I am aware to be cautious and to learn from tried and tested techniques, I always think through all the potential problems to avoid being over-optimistic.
• Impassioned - I have strong feelings for what I do, which makes me passionate and animated. I am aware to avoid getting irritated when provoked by others with different agendas.
• Responsive - I keep calm and am resilient and composed under pressure. I act with urgency under pressure which helps me deliver what I set out to do. I am aware to avoid being frustrated by disruptions and setbacks.

It's about using my emotions as a positive driver to get stuff done, and conversely being aware to avoid stress and frustration when things don't go to plan - it's about the perception of being in control and dealing with the situation.

I hope you find these tips useful. It would be great to hear any additional ones you have, connect with me on LinkedIn.