About a year ago, I moved into the role of a tech lead on my team. For some background, I work on an embedded software team within a larger Energy Efficiency Consultancy organization. Embedded Teams function very differently than teams in larger software organizations. You will be required to wear multiple hats, process will have to be built from ground up, you'll have to be very mission oriented, and you'll have to learn the business. I learnt a lot along the way, and I am grateful to my team for giving me space to grow and learn.
1. Context is everything
People like being part of a greater mission. One of the ways to reiterate your company's mission is by providing context for everything your team will build. Over-communicate your roadmap, bring up your quarterly painted picture regularly. Connect stories back to the bigger picture. Connect stories to problems it could solve in your business domain.
2. Manage up
As a Tech Lead, you have the opportunity of expanding yourself beyond the stories that your team works on. You have a chance to anticipate business needs or see places that need process improvement. Freely share your learning to your peers.
3. Document your decisions
Decision making is tedious, and you may encounter decision fatigue. Document these decisions and make it freely available to your team.
4. Be selective of your advisors
A lot of the advice for software development and management process is from a perspective of a company providing solutions purely through software. Be aware that sometimes it is harder to scale down advice than scale up. Read all the blogs/books you can, but do reflect on what works best for your team.
5. Be your team's biggest advocate
Get to know your team in a professional setting, through regular 1:1s. Get to know their interests and how you can help them grow their career. Be a coach and a mentor. Recognize the value that each member brings to the team and give positive feedback generously.
6. Provide direction but let your team be autonomous
Don't feel like you have to control every part of the software development lifecycle. Provide a framework where decisions can be made without fear of failure. Things can go wrong, but that's OK. We'll move on and learn from it.
7. Read code and participate in code reviews
You may not be able to contribute to sprint cycles regularly anymore. Keep in the know by reading code that is being written and merged to production every sprint.
8. Do some spikes
You do have the opportunity as a team lead to look at the bigger picture. Go ahead and do some spikes. Try various architectures, so you can help make informed decisions.
9. Engage in customer support
Delight the customer. Put yourself in regular customer service rotations to gain customer perspective and understand their pain points.
10. Broaden your skill set
Now is the time to go broader on your T-shaped skill sets, rather than go deeper. Read generously about developments in the industry across your full stack.
11. Learn about your business
Become a business domain "expert". This will come in handy when you have to provide context to your team.
12. Talk less, listen more
Folks who speak the most benefit the least. Foster innovation on your team through a culture of knowledge sharing and brainstorming.
13. Don't be afraid to fail
Go forth and fail, rise up, and learn. Be a kind, empathetic human being.
Top comments (6)
I became a team lead myself at the start of the year, and this was an awesome read for me. Thanks for writing it!
I would be really interested in hearing about your learnings and findings!
I think I'd have a lot of trouble fighting perfectionism to the point that I'd give up halfway through 😅
I only got a chance to be a team lead for six weeks earlier this year...the environment was so hostile and toxic I was randomly missing work to try and make them fire me...but that's a story for another day.
With #5, I think I would sum it up as know what motivates each member of your team and what work can help them follow that path.
With #13, I like the mantra move fast and break things with stable infrastructure.
Embedded software is hard, hats off to you for growing to meet all of the challenges! My first job was working with transportation-industry devices which would these days be considered IoT. I loved having a bunch of gadgets wired up across my desk and being able to solder well and the satisfaction of wiring up a digital sign and making it display your message for the first time. I never finished my degree, and I have found that a big barrier to getting into the embedded sector again. It's still a hobby now, and maybe it's better that way because I only take on projects I enjoy!
Thanks for the feedback! The context of failure here is in terms of process and decision iteration. If we only realize we are failing at the end of a feature or product, then maybe we should get better at interpreting the signs that could have led us there. I should have made that clear..
Good article!
One thing:
You may want to emphasise what you mean by spike, given the flexible nature of agile your interpretation may be different to others.