10 Learnings From My Developer to Technical Lead Transition at a Start-up
In the Fall of 2017, my good friend and the former Technical Lead of our product team at SuperAwesome decided to bite the bullet and join a well know fin-tech company. After countless, exhaustive handover sessions, he was still taking a chunk of expertise with him — leaving behind big shoes to fill!
At that point, my tenure in the team has been the longest and I knew all the nooks and crannies of this fairly unique product space — a zero-data ad tech product used by hundreds of children’s content media and product companies, the likes of Nickelodeon, to serve millions of ad impressions in a legislated, privacy-regulated space.
I was kindly offered and agreed to officially step in his shoes.
Here are the top 10 learnings, I hope you enjoy and find the read insightful!
Adjusting your mindset
Congratulations — if you accepted a new job as a Technical Lead or are considering moving to this role within your organisation, you are in for an enlightening experience. It is not just a promotion, a glorified Software Developer. You are no longer a sole contributor, you are now additionally going to be supporting the success of your team. Transitioning from being an individual contributor to taking on these new support responsibilities requires a certain shift in your mindset.
Different responsibilities, not more or less
In most product start-ups or scale-ups that I know of, the role of a technical lead is fully hands-on and this means that you will be mastering the complex time management and a balancing act between your responsibilities as a Developer (pairing, code reviews, whiteboarding, all the usual agile rituals) and your newly acquired responsibilities as a Technical Lead.
What worked for me was a time split in the region of 70–30 — I would allow for a day and a half out of the 5 days in my calendar for ad-hoc meetings with various stakeholders, system design interviews, product planning and OKR catch ups with the Product Manager, and everything in between.
Focus on the outcome and not output
Your team spending the bi-weeklies doing over-time shipping a new feature that nobody cares about, using tools and processes that makes everyone on your team miserable — is hard, but not smart.
The thing is, as a product team, we are measured on the outcome and not output. So it’s important to nourish a culture of measurement and focus on the right things. Together with the product manager, you are in a great position to ensure this is the case.
Measure
Make sure that every new feature is shipped with an ability to produce metrics. These metrics should ideally feed into some system to help track and surface those Key Performance Indicators (KPIs). These should feed into and be aligned with your team’s Objective-Key-Results (OKRs). If you can prompt and capture the requirement of metrics as early as in your user stories Acceptance Criteria, your product manager will be grateful.
Additionally, you might find needing to measure defect rates, Commit-To-Deploy, branch lifetime, and other team performance metrics indicating the health of your development team. If not done already, make sure to take notes and action points in your team-retrospectives. Defect rate metrics and cyclomatic complexity of source can provide ammunition for a constructive discussion when liaising with the Product Manager to make sure important tech debt work is done.
Calendar, my dearest friend
Your calendar, aside from your experience, is the most powerful weapon in your arsenal. Use it to book time with your colleagues to perform dedicated focus time tasks, such as pair-programming, so product stakeholders can’t pull you out of the zone in the middle of a pairing session.
Book your lunch-time, gym time, your one-to-one’s, or even ‘stop working’. You can’t be a good Tech Lead if you are a meanie due to not being able to find enough time for yourself.
Imposter syndrome gets stronger
Our industry is crippled by the imposter syndrome. Every engineer knows more, works on more exciting technology, “magically” finds time to sneak in pull requests eliminating the smelliest tech debt. How do they find all this time?! Now, you are telling me I still have to code, but with 30% less time?!
If you are suffering from imposter syndrome (don’t we all?), truth is, this transition will make it even harder.
So, unless you stop evaluating your performance through the lens of output and instead focus on enjoying the process, you will not be having a good time.
A successful product manager I used to work with at SuperAwesome, used to say ‘Have a good time, all the time!’.
Product Manager’s best friend
OKRs, product planning, estimation sessions, ad-hoc catch-ups. Truth is, you will be spending about the same amount of time with the Product Manager as you do with the rest of the engineering team. Sure, your team’s product manager might not know what a monad is or how to implement map-reduce from scratch, bah, they might not even know SQL! But, it’s them who are ultimately accountable for the successes or failures of your product team.
That is not a light burden, so be nice to each other, bring each other an unprompted coffee once in a while — be the one to initiate it!
Processes
Through your hard work as an engineer and close relations with the product team, you unintentionally gained the trust and a position of authority where you can influence your processes and shape them such that they are enjoyable and don’t slow your team down.
Your process is slowing you down or making you miserable? Change it! It still doesn’t work? Change it again. Agile is not just following a ‘Scrum and Kanban for Dummies’, it’s being agile!
Architecture
Chances are, as a result of constantly being questioned about it, you will be one of the few people on the team who can recite the complex map of your micro-services when woken up by Pager Duty in the middle of the night during an outage.
This is invaluable when pro-actively thinking about the system-as-a-whole architecture and conveying the importance of some land re-shaping work to your team and the Product Manager. So, initiate and facilitate discovery and whiteboarding sessions for your team. Organise architecture walkthrough sessions for new joiners. Challenge the status quo.
The force multiplier
You are now part of a pulley system meant for multiplying the force of your team. Tempting as it is, the outcome of your work as a Technical Lead is not solely the outcome of you as an individual contributor.
What is more important is the positive impact on the outcomes of your team or what is know as the force-multiplier.
Can you, through your actions, make each of the team members 10% more productive? Now, multiply this 10% by each member of a team of 8. That is huge!
Fear not, through careful time management and maintaining a time split, you can still practice your programming craft — being a successful individual contributor (ideally pair programming) 70% of the time.
Conclusion
This article was a summary of my learnings in my transition from a Developer to a Technical Lead in a product team of a start-up company called SuperAwesome.
It is an interpretation of what I consider the unique challenges of a Technical Lead. Every organization is different and you might be required to put on different hats as your team takes on different shapes and directions.
All views expressed are mine and not of my current or former employer.
I no longer work at SuperAwesome, but I heard they are hiring for similar roles! After 4 years, I decided to see what the hype of fin-tech is all about by joining another fantastic team, this time at Kroo — a new social digital bank.
