Being a Tech Lead in an Empowered Product Team

Being a tech lead in an empowered product team is not a purely technical role. In addition to your typical engineering duties, you are a part of the product manager/tech lead/product designer trifecta and you collaborate on product decisions.¹

In this post, I want to talk about how the tech lead role is different and what I consider essential to being successful in it. I’m drawing on my own experience of being a tech lead as well as the experiences of my product manager friends who helped me see it from the other side.

Collaborating on product as a tech lead means you need to work together with your product manager and designer to discover and solve problems for your customers.²

You ensure, as partners, that the features you build are valuable (your customers will find them useful), feasible (you can build them), usable (your customers can use them) and viable (they work for your business). To do this successfully, you have to combine your unique expertise and collaborate closely in an environment of trust.³

As a tech lead, your area of expertise is feasibility. You know what is possible and how difficult it will be to build, and your team will defer to you for feasibility questions. Similarly, the product manager is the expert on value and viability and the designer the expert on usability.

Rather than being a purely technical senior role (unlike e.g. an architect who owns big technical decisions but isn’t involved in product), you are acting as the bridge between the product and the implementation.

This means you need to work in two directions. Outwards, from the technology to the product, by knowing what the technology you have makes possible. And inwards, from the product to the technology, by building software to meet your product goals.

Beyond just knowing what is possible, you should use your technical leadership to create possibilities for your team. Having more than one path forward means a higher chance of success. You need to think broadly about possible solutions, work creatively around constraints and avoid tunnel vision.

In addition to being an excellent engineer, I consider these six traits essential for succeeding as a tech lead:

1. Being an excellent collaborator.
2. Building a trusted relationship with your team.
3. Having a strong product mindset.
4. Being able to quickly assess feasibility.
5. Always working to open up possibilities.
6. Being an enabler of ideas.

Collaboration

You need to work closely with your product manager and designer to successfully solve hard problems. There isn’t a single good way to collaborate, but there are some anti-patterns common when engineers, product managers and designers work together:

Treating it as a negotiation. If you see this as a give and take relationship, you are likely missing basic trust and it won’t work. Likewise if you are putting your own or your department’s needs above the team’s.

For example, if you feel like you need to protect the engineers on your team from unrealistic deadlines imposed by the product manager, you are not trusting each other with basic things like giving realistic estimates, respecting them and delivering on them. You need to fix that first.

Pleasing everyone. If you settle disagreements by splitting the difference, you are moving forward in a way that’s not a win for anyone. Collaboration isn’t a negotiation and it’s not about making everyone happy.

If you are competent and trust each other enough, you should reach an agreement on most things. If you can’t agree, it’s best to run a test to find out or disagree and commit. As a tech lead, keep in mind that the product manager is ultimately accountable for the success of the product and therefore has the last call on product decisions.

Working in isolation. If everyone “does their bit” in isolation in order to combine them at the end, it isn’t true collaboration. True collaboration requires a high bandwidth conversation where you can bounce ideas off of each other and work in small increments.

Working in isolation can be a symptom of not trusting each other to provide constructive feedback. You should absolutely be comfortable with giving and receiving feedback on each other’s work.

Not collaborating in real time. Because this collaboration needs to be a conversation, it should be in person or at least over video. Chat is too low bandwidth and documents are the wrong tool completely.

Producing artefacts for each other. If you find yourself producing a lot of artefacts or documents for each other (like product briefs, wireframes or implementation plans), you aren’t truly working together.

Reliance on artefacts is a sign of siloed departments and waterfall processes. If you have the product manager writing a brief so that the designer can make some wireframes for the engineers to start estimating a project, all collaboration is dead.

Trying to do everything yourself. Sometimes when there’s a lack of collaboration, engineers have a tendency to try to do everything themselves. They are the ones shipping the code after all.

But you need your product manager’s and designer’s expertise to assess the value, usability and viability of your features. While you might be able to do some of that yourself, this usually means you don’t trust them or their skills enough, and you need to fix that.

Just doing what you’re told. The opposite of doing everything yourself is being passive and just building what you’re told.

Like your colleagues, you have a unique perspective. If you don’t use your perspective to bring some good ideas and insights to the table, you are not giving your team your full value.

Trust

Close collaboration requires a high degree of trust.

You need to trust your product manager’s and designer’s skills and intentions. If you don’t, you won’t be able to work with them closely enough to succeed. Equally, your product manager and designer need to trust you — your skills and your intentions.

There are many aspects to building trust, but there are a few especially relevant ones for a tech lead:

Have a track record of delivering on your commitments. Make high integrity commitments and deliver on them. Do that consistently over time to build trust.

Own your mistakes. Nothing makes you untrustworthy like not owning your mistakes. Made a wrong technical call? Missed a deadline? Misestimated something? You need to proactively acknowledge it, fix it, and make sure it doesn’t happen again.

Have a positive mindset and be an enabler. This one is not as obvious, but many engineers fall into that trap. If other people feel like you’re negative and they always have to fight against your pushbacks, they won’t like working with you and they won’t trust you.

Product Mindset

Being a tech lead on an empowered product team requires you to have a product mindset. For some engineers this comes naturally because they’ve always been interested in the product side of things. For some it takes a lot of getting used to after spending most of their careers in a different mindset.

Product mindset means you always think from the perspective of your customers and what they would find valuable. In other words, you start with the product, not the implementation.

Not starting with the implementation can be counter-intuitive. As engineers we are used to focusing on the implementation — that that’s the part we are responsible for, and we enjoy solving problems.

Your focus as a tech lead needs to on making sure you only build what is valuable for your customers. Finding out what is valuable is primarily your product manager’s role, but you should be able to do it too. Talk to your customers, run a test, but never build only based on assumptions.

Focusing on what is valuable to your customers also means you solve the problems they have now, not the ones you think they might have in the future. Anticipating problems and thinking through possible future requirements can be useful from a code architecture perspective, but it can lead to over-engineering and needless complexity. Strive to build the smallest, simplest thing that will meet your customers’ needs.

Choosing simple solutions means you can’t do cool tech for cool tech’s sake. It can be tempting to show off your chops as a tech lead on a difficult problem like scalability. You may even be incentivised to do that — many engineering orgs (consciously or not) end up rewarding people who lead complex implementations without checking that the complexity was justified. But you should use your judgement to keep yourself and your team away from that.

Assessing Feasibility

Assessing feasibility is the main expertise you bring to the product team leadership trifecta. You are in a unique position to know what is and isn’t possible with the technology you have or can have. This means the role has two sides.

One side of the role is to assess the feasibility of something when asked. Is it possible to build something? Will it be easy or hard? Roughly how long would it take?

Being good at quick order of magnitude work estimates is a key skill for a tech lead. You should be able to take a feature and get an idea of how complex it would be given your team and tech on the spot. Accuracy isn’t the aim at this stage and proper scoping can take place later. Sometimes you will miss some complexity and that is ok.

You should try to be realistic but positive when doing this. A common engineering mistake is being defensive and defaulting to worst case estimates. You should trust your product manager enough to give them a quick estimate without worrying someone will hold this against you. If you can’t, you need to create a more trusted environment first.

The other side of the role is to tell people about things that are possible they might not even know about. Sometimes, your counterparts might assume something is impossible when in fact it’s possible (or even easy), and you need to tell them.

That is how true innovation happens — as a team, you combine a deep understanding of your customers with the knowledge of what is possible. What does (new) technology enable that most people wouldn’t even think is possible? That is how successful products are made.

Opening Up Possibilities

One of the best ways to communicate what’s possible is by always offering a range of solutions to a problem and opening up different ways for your team to meet customer needs.

This can be counter-intuitive. After all you are the expert who should decide on the best solution, so why offer multiple? In less collaborative environments, that might even be frowned upon.

But most problems have a spectrum of possible solutions that come with different tradeoffs. Taking your team through the solutions and their tradeoffs lets you make a more informed decision and take the product and design considerations fully into account.

Showing more than one possible path forward should be done proactively. Others might not even know the right questions to ask to begin uncovering them, so it is on you to offer them.

Another way to open up possibilities is to keep your technology as flexible as possible — although flexibility shouldn’t come at the cost of increased complexity or over-engineering.

A good rule of thumb is that things that are the most likely to change should be the easiest to change. The least certain features of a product will experience the most churn, and you should structure the software to anticipate that.

On the other hand, limiting possibilities is often result of one of those three mistakes engineers tend to make:

Deciding on a solution too early. It can be tempting to take a problem and start finding the optimal solution straight away. However, deciding on a technical approach before taking product and design into consideration can create the impression that that is the only possible solution and severely limit your team.

Letting technical constraints dictate your product approach. This one is more nuanced because sometimes technical constraints truly exist. However, engineers often over-focus on constraints and correctness in a way that limits the end product and isn’t always truly necessary.⁴ Being pragmatic and maximising the value for your customers is key.

Of course, that is not to say that you should compromise software quality for the sake of features. A useful feature that is insecure or unreliable will fail sooner or later. But it is your job as a tech lead to explore different options, work around constraints and open up possibilities for your team instead of limiting them.

Painting yourself into a technological corner. Sometimes, well intentioned past decisions or even mistakes mean your technology can’t support your current product needs. If a piece of software can’t support important product needs, it isn’t fit for purpose anymore, and it shouldn’t be used as a reason to limit the product. Instead, you should use your engineering and leadership skills to get your team out of the corner as quickly as possible.

Being an Enabler

Beyond finding technical solutions to specific problems, you should be an enabler of ideas in general.

Your team will only be as successful as the number of ideas and experiments it tries. You need to have a positive attitude towards other people’s ideas and work hard to enable them.

Many engineers are guilty of the opposite. When presented with an idea, their instinct is to start poking holes in it and finding reasons why it won’t work. This is a useful skill when stress-testing technical designs, but it’s not a helpful attitude when assessing product ideas.

When presented with an idea, you need to think of ways to make it easy to try. How could you prototype it? Test it? Run an experiment?

This might require significantly reducing the scope. That is where your knowledge of the implementation comes in. A full idea may be prohibitively complex to implement but a subset of it surprisingly easy.

Perfectionism isn’t helpful when prototyping and testing. Covering all edge cases and shipping high quality software is what you should aim for with finished features. However, when testing, you should bias towards testing ideas quickly and taking risks.

It can be helpful to think in terms of tradeoffs. What tradeoffs would you have to make to make an idea easy to test? Bring that information to your team and you can make a decision. A quick prototype might be too simple to provide useful results when tested. The risk of a user hitting an edge case might too high. But maybe a smoke and mirrors prototype would allow you to test the value of an idea with your customers and move forward quickly.

A Different Kind of Role

These six traits are by no means an exhaustive list. There are many other important aspects — leadership, communication, and stakeholder management to name a few.

I hope this post made it clear that being a good product team tech lead isn’t just about being a good engineer, and that the role is different both from purely technical senior IC roles and from engineering management roles. While all of the above traits can be learned, not every senior IC or manager is a good fit for a tech lead.

It is also worth mentioning that a tech lead isn’t always a dedicated job title. It is a role people with different job titles can fulfil. Commonly this is a senior IC on the team but it can also be the engineering manager.

The important part is that the product manager does have an engineer to partner with and collaborate on product decisions in the way described here.