Diary of a technical lead newbie at Sage AI

A self-reflection after the first six months of taking up a technical lead role, capturing my thoughts on the experience and things that helped me on the job. Food for thought for those considering the next steps in their career

A new opportunity? Why not?

Sage AI was created with the mission to transform Sage into an AI-enabled technology business. I started at Sage AI as a machine learning engineer, working mainly on an accounts payable automation project together with a handful of peer developers. With the rapid development of our product, we very quickly expanded our team (and we are still growing!).

As a result, our original project grew to a size where it was sensible to split it into several smaller projects to make it easier to manage. I was asked if I wanted to be the technical lead for one of these projects, to take ownership and keep driving the project forward.

Of course, this post would not exist had I said no! But let me clarify: I was not forced into this role. What I like about Sage AI is that the organisation cares about each member’s career growth and development according to their personal goals. I was enjoying my developer role at the time and could have said no to the opportunity. However, I’ve always enjoyed trying and learning new things, and knowing that there was a need for someone to step in, it looked like a very good win-win situation. So I said, “Why not?”

Technical lead at Sage AI

The technical lead role can be vague, and varies between companies. So I will attempt to define what this means at Sage AI. Generally, this covers work such as:

• Defining the technical roadmap for the project
• Managing priorities and timelines with stakeholders
• Planning with the technical team (e.g. software, data, Machine Learning (ML) engineers, and data scientists) to deliver realistic project needs (and being part of the technical team as well)
• Being the point of contact for other teams we collaborate with
• Keeping the production services healthy and functional

Six months later…

Time flies but it felt like time passed by even quicker as a technical lead! I’ve been meaning to write this post as part of a formal self-reflection after 3 months of being in the role. But in the blink of an eye, 6 months have gone by at the time of writing!

What have I been doing?

From the day I dived into the role, I cannot recall a single day where I did the exact same thing. Every day there were new issues to resolve, and new things to design. This would always fill up a day’s work and more. Such tasks included:

• Meeting business teams to confirm features for the next release
• Defining the strategy to incorporate new functionality and evolve the programme architecture
• Assigning the tasks for my technical team to execute the strategy
• Deploying an urgent bug fix in production
• Pair programming with a data scientist, and training and deploying a machine learning model
• Software engineer work on maintaining common libraries and functions for the team to reuse with ease

At the peak of busyness, I was squeezing a handful of tasks into a day. It was rather overwhelming at first. However, as I got settled into the role, I picked up a few new ways of working that helped make the job a lot more manageable and productive.

Ways of working that helped:

Drawing and keeping the big picture in mind

I started drawing diagrams of the architecture and workflow. I even went to the extent of combining these drawings into one overarching diagram consisting of several layers (using a free tool on diagrams.net).

Figure 1: Sample expandable draw.io diagram views (blurred out)

This allowed me to navigate different parts of the diagram, giving me the big picture overview, as well as allowing me to zoom in and expand on focused details when needed.

I originally thought it was a waste of time to draw diagrams just for my own benefit. But while it was a continuously growing “blueprint” for me to plan and further the technical roadmap, the rest of the team found it very useful as well, as the expandability of the diagram meant the view could be adjusted depending on the level of audience. The diagram was used by product managers when discussing high-level workflows with business units, and saved a lot of time in reducing confusion when discussing any part of the project with the technical team.

Delegating and trusting the team

I had a tendency of trying to get involved in everything. But as I took responsibility for the project, I was stretched too thin, and was less able to spend as much effort attending to all the issues we had. It was only natural that I started delegating more tasks to the team.

For each member, I would discuss and plan their tasks with them, ensuring they understood what they needed to work on. Then I would let them get on with the task independently, but also be there to provide minimal guidance if necessary. I believe this was how we built up trust and confidence amongst the team as I got to know everyone’s strengths. Over time it made it a lot easier to estimate the effort and time required for new development work to be carried out.

…but saving some time for yourself to handle groundwork!

While I got used to delegating tasks to my team, I had some regular days carved out of my schedule so I was able to handle some of the technical tasks on my own.

I like to think that a “smooth sea never made a skilled captain”, and as a captain leading the technical project, being active in handling tasks is a way to ensure I don’t lose touch with the technical side of things. Being responsible for the whole project, I believe that it is absolutely crucial that I am able to jump in and out of different components of the project, get my hands dirty in order to assist my team when needed. This will always be a work in progress and will never be easy, especially when we need to fix critical matters while keeping the forward momentum of the project.

Saying NO

When you take into account the various business needs, all the requirements imposed by stakeholders or other collaborating teams can easily drown the team. Everyone wants everything, so we have to be strategic and selective in order to make the best use of the team’s effort in a given timeframe. As technical lead and the one with the deepest understanding of the team’s capability, I realised that I had both the power and the responsibility to step up and decline requirements that did not align with the team’s priorities. By saying no, we can control and reduce the chances of:

• Biting off more than what we can chew (i.e. overpromising and later under-delivering)
• Rushed and hacked code that is more prone to bugs

Although the first point is immediately observable, the second point is actually more dangerous. This is because it can easily build up technical debt, which can spiral out of control if not carefully managed in the long term. Occasionally there might be simple hacks and shortcuts, but a team needs to have the breathing space and time to replace those hacks with more permanent solutions, and definitely avoid putting a hack on top of a hack!

Outlook: what did I get out of it?

At first, I wasn’t sure what I would really get out of the role apart from extra bragging rights on my CV. However, looking back at the past 6 months of being a technical lead, it was very rewarding. There’s no doubt that mistakes were made during the journey, but learning from these experiences was what allowed me to build more resilience and confidence in leading the team. On the plus side, I really enjoyed:

• Planning at a much larger scale, beyond what just one developer could do alone
• Orchestrating the team and seeing all the gears working in action, according to the technical roadmap
• Building trust and working as a team, and being able to rely on one another to deliver target goals
• Patting ourselves on the back to celebrate wins, whether it is reaching milestones or receiving good customer feedback on a working product

Final thoughts

These new ways of working have certainly helped me, especially for the last 6 months. I am keen and excited to continue my journey as a technical lead. I aim to revisit this “diary” to self-reflect and reassess whether such ways of working will stand the test of time, and perhaps add another entry in 6 months.

I hope that whomever is reading this might find my thoughts and experience useful. If you are considering the next steps in your career, whether it is a technical lead role or not, my advice would be: “Why not?” You should have enough data at hand, either through reading about other people’s experience or trying it first hand, before you decide whether you hate something or not. Ideally, you would want to be in an organization like Sage AI that supports your career growth, whichever direction you choose!