A day in the life of a Tech Lead is packed with the good stuff. Empowering a team to get results you will be proud of, seeing your colleagues growing in their careers and with a feeling of contributing to something big, helping your clients find that smart solution that will make their ecosystem sound like an oiled engine. These sensations are all priceless and the cherry on the cake of every leader that is inspired by the mindset “empower people to achieve top-notch results”.
After working for more than 18 years in the software industry, and having played several roles amongst software developer and product owner, also leading technical teams for almost 10 years, I’ve failed and learned enough to have the confidence to say that there is nothing better than hearing from your team members that they feel the proud owners of what they built.
But don’t think this all comes together so easily. There are heaps of techniques, tools and tactics that Tech Leads can leverage and incorporate into their work towards empowering their teams and nail it on the delivery of complex solutions.
1. Raise appreciation over the Big Picture
As the Tech lead in a project, you need to work with the owners of the functional aspects, the business analysts, key users and engagement managers to come up with a collective understanding of what needs to be built. Which will become your Solution Design.
It’s Tech Lead’s mission to create awareness within the team around the overall design of the solution they are about to build as a team. Finding the right granularity of the bolts and nuts in the design you want to disclose to your team is key though. Focus is key and you don’t want your team distracted with details only relevant 3 sprints from now.
Highlighting the easy stories but also pointing to where the challenges are, enforcing reusability, identifying opportunities for proofs of concept (PoCs) of known-unknowns, encouraging the team to ask questions and own the solution with you, are some of the tactics I normally use to build awareness with my teams around the solution we will deliver together.
As a collateral effect, your team will help you understand what is missing. Remember, the more experienced you are the more susceptible to miss silly pitfalls that can turn into real problems. So always have your team watching your back and helping you get to a robust solution design.
“Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results.” — Andrew Carnegie
2. Seek for confidence around the complex requirements early
It’s hard to be 100% confident about the results of the delivery in the early stages of any project. But reducing that level of uncertainty is what ultimately enables you to manage risks and increase the chances of success.
Identify complex requirements and tackle them in the very beginning of your project. If you get the chance to have developers involved in the initiation / inception of your project, put a concise plan together and define clear results to get the best out of your PoCs. At least, make sure your team is protecting time for this while sprinting.
This is something I learned in the school of hard knocks when once, long time ago, my team worked hard in a project for a big insurance company to cope with the expectations for quick and early delivery. We took the obvious route and prioritised the quick wins. After the team iterated for a few sprints we finally had some energy to get our heads around the complex requirements. It was too late and the necessary refactorings significantly impacted the health of the project.
Be ahead of the current sprint. Remove the blockers before bringing them to the attention of the team. This definitely increases predictability, as it helps the team come up with better estimation while avoiding the spillover effect.
3. Give your team space to fail and learn
Although as a Tech Lead you need to step up and represent your team, you need to be careful with how much you are preventing them from learning with real experience. Nothing teaches more than facing real challenges. And giving them that opportunity is fundamental. I have experienced several occasions where I was lucky (and happy) enough to combine my teammates’ innate abilities with their desire to step up and learn.
6 years ago I worked with a guy who had engaged as a junior developer in my team. After struggling a bit in one of his first projects he performed way above expected. He decided to take ownership over the stories he implemented and worked closely with testers and key-users. That helped him understand how to improve the quality of his unit tests and he learned a lot with it.
After 6 months working together I was defending his promotion myself to his bosses. Now, I can’t feel prouder seeing that he’s become a great tech lead himself, grown on top of the same principles and values we carved together when working as a team.
“The mind that opens to a new idea never returns to its original size.” — Albert Einstein
4. Chunk up every now and then
A.K.A. manage your project’s technical debt. But, please, do it with the team. ‘Chunking up’ means you are leaving the world of small ideas behind for a moment to have a look at something bigger, larger pieces of information. It’s similar to thinking outside of the box. It’s about giving yourself and your team the opportunity to see things from a different perspective and reassess architectural recommended practices.
The way we do it at Phoenix is by having 2 recurrent technical sessions on every project. One of them is the Architecture Review, when we have an experienced Architect reviewing the overall solution with the project’s Tech Lead. In this session we are typically asking questions like “What assumptions have changed since the original design?”, “Any new component added to the solution that moves away from the scoped architecture?”, “How is this new application integrating into the current landscape?”. The Architects also have the chance to approach with their experience from other projects, and offer an outside eye view, which is normally hard when you’re heads down in your day-to-day activities, in delivery mode.
Another important event we encourage our Tech Leads to do is a Technical Review. It normally happens fortnightly, in the context of the project, but not only focused on the current sprint. This is the opportunity for the Tech Lead to promote the use of best practices and to find opportunities to tackle technical debt. Depending on the findings, new stories can be planned for the next sprints in order for the team to protect time (or points) and to avoid building up too much technical debt to be tackled at the end of the project.
Outsystems has powerful tools that help on these recurrent reviews, such as Discovery, which helps you be on top of your ecosystem’s architecture highlighting issues like cyclic references. Architecture Dashboard was launched recently and is meant to help the team manage technical debt. It will introspect the applications and warn when an anti-pattern is found on the code, like Client and server side Entities and logic aren’t isolated, or Monolithic mobile UI module, etc.
Finding out how far the implementation has gone from the initial solution design is key to avoid project cost overruns. Use these events as a learning experience for your team, so you see the same mistakes being committed less and less.
5. Delegate based on expertise + willing + opportunity to learn
I have recently worked on a project where I could happily delegate some of the tech lead’s activities to someone who was eager to step up and take ownership. It doesn’t happen every project. But when it happens, take it! He was not yet ready to just take on the lead, but everyone needs a chance to learn, right? His openness to learn, candor with the delivery of the project, and background knowledge on the previous sprints made him an excellent reference developer. He is now the go-to person for technical questions and has been providing clear guidance to the team around priorities.
As a Tech Lead you are a mentor of your team, and there is no point in leading a team that doesn’t have space to commit to the next level of their activities. You are not leading, you are holding your team back.
Finding a fine balance amongst current knowledge (expertise), the keen desire to step up (willing), and space to learn without compromising results (opportunity), is the right formula to create an atmosphere of empowerment and thrive.
“The capacity to learn is a gift; The ability to learn is a skill; The willingness to learn is a choice.” — Brian Herbert
6. Use the peer review as a learning opportunity
Tech Lead is not a Goal-Keeper. So it shouldn’t be Tech Lead’s only the responsibility for peer / code reviews. Tech Leads that don’t allow their teammates to own certain activities are acting as blockers and holding the whole team down, not only for a sprint release, but for their teammates’ careers. The peer review is an excellent opportunity for any developer to look at someone else’s code and learn from it.
You probably have more experience to find that redundant logic in 2 different modules that will become a bug soon. But instead of you, why don’t enable your team to do it themselves? If your answer to this question is related to “”they’re not ready”, it’s probably because they’ve never done it. So again, everyone needs a chance to learn, right?
Be part of the first code review sessions. Perhaps protect more time for the first ones as, besides reviewing code, you are guiding someone to take their own steps later on. Then start progressively rolling the responsibility off your plate and towards your team. Take part in the sessions when there is a tricky story to be reviewed and refresh your guidelines every other sprint.
7. Manage external dependencies
In 2015 I worked with a big latin-american bank that, as expected, had some tricky security requirements in the project we were to deliver, and some of them depended on another project being conducted by their internal R&D department. That deliverable had no clear ETA yet at the moment we were doing inception. The perfect combination of variables that put any project in jeopardy.
We then decided to bring to the top of the backlog a proof of concept (PoC) to be conducted together with the R&D team. The results of this PoC allowed us to get to a clear definition of risks and an assertive estimation. Everyone was happy for having done that before it was too late.
So, act proactively to map the biggest uncertainties and build an action plan to turn them into well defined requirements. Sometimes it just means you didn’t have clarity around that particular scenario at that moment in time. But you will never know until you thoroughly assess it.
“To win big, you sometimes have to take big risks.” ― Bill Gates
At the end of the day, it’s how you anticipate risks and prepare for them that will help you thrive. Creating an atmosphere where your teammates feel at the same time challenged and empowered to contribute and speak up can really make the difference between success and failure.
Joao Melo
Technical Lead
Connect with Joao on LinkedIn
