Voltron Studio logo black rectangle

Article

Does your tech lead know the importance of tech buy-in? Here’s how to achieve it

David Vuong

·8 mins read

A balanced and strong tech lead is critical to the success of your engineering team and product being delivered.

A balanced and strong tech lead is critical to the success of your engineering team and product being delivered.

Having worked in the industry for years, ranging from startups to agencies to enterprises, I’ve seen the importance of a strong tech lead first hand. A poor tech lead can create an unproductive team that lacks accountability, is unsupportive, and delivers a product riddled with broken windows. Worse, a poor tech lead can take a highly productive team and drag it down to the ground.

I’ve learnt my fair share over the years having been mentored by industry leaders. I’ve taken these lessons and learnt to successfully lead my own teams. It’s an incredible feeling when the team is aligned, motivated, meet tight deadlines, and each member holds each other accountable. This all starts from the top.

In this post, I’ll talk about why as a tech lead, it’s essential for your team to buy into your ideas, what happens when the team doesn’t agree and a data driven approach to winning team members onto your side.

Overcoming roadblocks

Strong leaders with a deep sense of passion for what they do usually lead to them holding strong opinions. It’s natural to have others disagree or feel reluctant to take on your ideas.

  • The freshie - Inexperienced, loud, strong opinions, naive, and thinks they know it all
  • The 9 to 5 - Unmotivated, only works with what they know, doesn’t want to rock the boat, and does the bare minimum
  • The big head - Ego driven, also loud, even stronger opinions, and defensive
  • Team 1999 - 20 years behind technology, still following outdated paradigms, no understanding of modern software. Always complains about new technologies

Why are these types of engineers problematic? They create friction.

  • Communication - Meetings and workshops become longer. Every conversation is a bit more painful, everybody feels more defensive about their choices
  • Stifling of ideas and creativity - Less encouraged to present their ideas, “it’s not worth it” mindset
  • Motivation - Loss of enjoyment, risking talented engineers leaving your team, or worse, the company
  • Quality of work - Trickled down from the lack of motivation and stifling of ideas. Unmotivated teams give subpar results. It creates an attitude of “just get it done” rather than “what is the best solution and how can I strive for it?”.

Every card and off the cuff idea you bring up will be fought on. You’ll compromise on areas you shouldn’t have to, the team will be in constant disarray and you’ll lose passion for the work.

Reduce friction. Sway the team to arrive at the same conclusion about an idea as you did on their own. From my experience, the best way to do that is to present the idea as data rather than an opinion. Demonstrate the value of the tech can provide and take the politics and ego out of it.

What is the best way to demonstrate value? Showcase it. Engineers want to see it working and solving their problems. You can create slides, hold meetings, listen to talks, ask them to read articles and that’s all great but the best way to achieve team buy-in is to actually produce something tangible and then demo it.

Solve real problems, don’t manufacture problems

Any idea or tech you want to introduce has to solve an existing or foreseeable problem. At Voltron, we take on a supportive lead role and we try to look for issues teams are currently having. Those are the problems we feel that provide the most value when solved. We see it as a multiplier effect. Solving a team productivity problem boosts the entire team, not just one person.

Let’s use a common issue within engineering teams: a slow, flaky and unreliable CI/CD pipeline.

  • Was the CI/CD pipeline a tacked on process from the beginning?
  • Was it introduced without buy-in when it was first implemented?
  • Original choice of tech dated and there wasn’t a consensus on what to use?

What ramifications are you seeing in the team?

  • Infrequent builds or disabled builds
  • PR passing criteria sometimes omits a passing build
  • Automated tests are not so automated anymore
  • You see a sea of red rather than green when you look at your CI/CD dashboard

You’ve identified an issue, have an understanding of why it may have occurred, and aware of the negative ramifications. The next stage is to spike out a prototype. This is the data building stage. Again, present the idea with data, not opinions. So what’s involved?

Research. Find articles from other leaders encountering the same problem. Dig deep into the depths of GitHub issues, reach out to colleagues, attend meetups, compare alternative solutions, and gauge your own team’s thoughts

Implementation. Back up your findings with something real. Build an MVP that solves that teething issue everyone is having right now

Proposal. Bring it all together with how this can solve all of your team’s problems and more. Provide a direction and transition path. Highlight milestones, and provide as much value along the way. Sell it.

Influence your team throughout the process

Data is one component of buy-in. The other is entirely emotional and equally as vital. During the research and implementation stages, it’s important to expose the work that’s happening and float ideas between team members.

Stand-ups are opportunities to do mini pitches, lunch sessions are great to dive deep into the technicals, and after work drinks are opportunities to gauge their true feelings on the problem. If you can get buy-in before a proposal is presented from a few key players, they’ll start becoming champions for the tech and it makes the process even smoother.

Final thoughts

Almost everything we do here at Voltron follows a data driven approach and it works. The technique is used by tech leads, CTOs, and solution architects across multiple industries and multiple teams. Having a demonstrable prototype, influencing others, and winning team members is critical.

If what you’re proposing is reasonable and proven to work, regardless of the team structure, company, or the people, the process stays the same. It may be drawn out a little more and you may need to spend more time finding backers but the core holds true. Identify the issues with the existing approach, build data by spiking out a MVP, address each issue, sell the idea throughout the process then proposal and demo.

Building software and solving problems isn’t just a technical challenge, it’s also a political one. Technology buy-in and winning over your team is just another song and dance we all have to play.

Thanks for reading, now it’s time to take action.

Related tags
Engineering
Written by

David Vuong

Co-Founder & Director at Voltron Studio

Sign up for our newsletter.

Be notified when we share new ideas and updates. Stay up-to-date on news and tips in web technologies, healthcare software, and radiology!

We care about the protection of your data. Read our privacy policy.

Voltron Studio logo white text and square

© 2021 Voltron Studio Pty Ltd, ABN 72 645 265 103