Making sure that engineers are heard at the management level is a constant struggle at companies large and small. One of Commit’s team members hosted a conversation between Commit Engineers and Khang Tran, SVP of Engineering at Goodwater Capital, to talk about how to approach the rest of the organization as an engineer, managing career progress and growth, and using engineering culture to overcome big challenges. Read the second post here.
On how to approach the rest of the organization as an engineer
Question: Most of the businesses that you’ve joined are in low-tech industries and themselves probably started out relatively low-tech. As you’ve worked at these companies, how have you approached the challenge of encouraging more adoption of software?
Khang Tran: I’m an engineer and software is where my heart is. You definitely have to strike a balance and there’s always space for the manual, offline, brute force, ‘throw bodies at problems’ approach. But once you figure out something is working and you have to scale it, that’s where software comes in.
For engineers, it’s very natural to think that if you need to repeat a task 1,000 times across 100 humans, of course you throw software at it. But you also have to meet people where they are.
If you go to an ops team or a specific person who has a job—which is to do things manually—you really have to step outside of yourself and exhibit empathy. You have to tell them that software is going to help scale and help them understand its value while also acknowledging that they might be worried about their job or even that software is going to make their job irrelevant.
There’s always this need to learn who your customer is, to let them know the advantages of software, and also to specifically reassure them that software is taking the most boring parts of their job off of their plate.
Many of the ops folks at Uber are ex-business school consultants or investment bankers who took a steep paycut to work at a technology company, so I found that connecting and getting buy-in from those people can make your job a lot easier. Having that dialogue really helps.
Question: It’s so important to think about a person’s incentives going into a conversation. What’s the reason that they get up every day and do their job, what’s the thing that they’re rewarded for? It’s a good life lesson in general, but it’s also a useful strategy when you’re an engineer talking to somebody who isn’t one.
Khang: If you’re an engineer going to a non-engineer and advocating for software, my advice is to avoid coming into that conversation feeling like it’s something obvious that needs to be done. Instead of assuming that software is always the solution, remember that it’s only part of the solution.
Question: You’ve spoken pretty candidly about how companies like Uber have this culture of scaling as quickly as possible and that there’s a trade-off to those decisions, which is that you sometimes end up starving longer-term tech investments. I’m curious how that discussion plays out at the leadership level. How do you make the case for longer term-tech investments, recognising that it will probably slow the organisation down in the short-term?
Khang: This is a really tricky one. Every single company or startup I’ve ever been at, no matter how engineering-oriented, has always had tech debt. The challenge is balancing paying down tech debt versus investing in things that might push the business forward. There’s no silver bullet.
What doesn’t work well are brute force solutions that make investments mandatory, because while you might accomplish the specific thing you set out to do, you might also erode trust with your stakeholders because you’re effectively saying ‘this is just how things go, this is happening now, because I say so.’
What works better is to empower and inspire people and to speak up and advocate for investment. Invest in engineers and make them part of the conversation when it comes to planning and setting goals. Instead of just saying that I’m going to hold a hard line at 20% allocation on x, I’d rather empower someone to have a seat at the table and drive the direction of what we’re going to do.
It’s hard, because if you look at founders, what percentage of them have a technical background? When a founder has that in their DNA it tends to permeate the rest of the organization, but it’s common to have non-technical founders and that puts engineering in the backseat. It’s really upon engineering leaders and engineers to speak up. Empowerment over brute force, that’s my approach.
Question: We had the VP of engineering of another company speak to us a few weeks ago about how important it is to understand your stakeholders and make the argument to them in such a way that it connects to the things that they ultimately care about. Always try to tie the technical change that you’re pushing for to the business change.
Khang: If you come in saying ‘we have to do this, we have to go to Microservices or we have to do X,’ you don’t leave room for conversation. It’s less productive than to say ‘here’s something I think is important and here’s why.’
Do you want to stay up-to-date with Commit news? Subscribe to our newsletters!