Making sure that engineers are heard at the management level is a constant struggle at companies large and small. 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 first post here and the second post here.
On leveraging engineering culture to overcome obstacles
Alex: I have a question about culture. As leaders, I think it’s our job to create and develop the company culture. How do you make sure that it happens correctly and that people are happy to just be there and to do their job and be with the other employees?
Khang: Excellent question, and I think there’s no easy answer. It comes down to knowing what you want and taking a step at defining what that looks like. It could be similar to Amazon where you have customer obsession. The first step is to define the culture and also to realize that it is not set in stone and that it’s going to evolve over time. You should have a core foundation of what that culture looks like, 80% of which will stick around for a while.
From there, the way you hire has to incorporate that idea. The last thing you want to do is hire somebody promising them this culture when actually it’s something else. Your hiring needs to be very transparent and you need to let prospective hires know that if they’re not excited about it, they shouldn’t join. You should hire people who align or could be culture adds.
On the flipside, as a leader part of your job is to manage people who don’t fit. I’ve had to do that quite a few times, let go of many smart people, and it’s usually a culture thing where they’re just not excited about the way you do things.
Culture is so important to scale a company, it’s just really about whether you know what it is and whether you’re able to articulate it. Even if you don’t know how to do that up front, you can do that after the fact with the team you have as an exercise and get their inputs.
At Hipcamp we had this one behaviour we really liked to reward called ‘leave code better,’ which was great. If you’re still forming your culture, get your team together and figure out what should be rewarded and reinforced.
Jihod: What kind of problems have you seen before with companies that grow really fast or hire really fast, and how do you deal with those problems?
Khang: There are so many problems when you grow fast. One: you lose knowledge. If you’re doubling every year, that means half the team is new, and only some set of people have all this knowledge. If they don’t document it or onboard well, the new people don’t learn it. So knowledge is lost or at least siloed and culture tends to dilute unless you proactively try to find a way to reinforce culture.
Another common thing I have seen is that the founding engineers and other employees feel a sense of loss or they feel disconnected, because there’s a company growing around them. They might feel like they’re not scaling with the company and people are being hired over them. You start having people feeling alienated.
There’s no easy solution to that, but what scales well is investing in a strong onboarding program so when new people join, you foster their path from zero to being a good representative of the culture in the company. If that experience can help imbue new people with the culture and best practices, that will keep paying back into the team.
At the same time, the culture has to be reinforced. Culture is better at scaling because the ideas behind culture are a lot simpler than if you had a ton of processes and rules and policies.
The last thing that I would invest heavily in is leadership. A common thing that happens is as you grow, you need managers. The instinct is always to turn an engineer into a manager, and there are a lot of pros to that. But there are cons too because now that engineer is no longer doing the thing they’re really good at, which is engineering.
At the same time, the last thing you want is your entire leadership team to be inexperienced leaders. You need to find a balance as you create your management layers. Maybe for every two managers that are new converts, there’s one experienced one that we hire from the outside so you have a mixture of people who understand the team with folks bringing in a fresh perspective.
Uber made a big mistake where 90% of the leadership was all internal converts who had no idea what they were doing, and obviously, a lot of bad things happened after that. So you want to avoid that.
Andrew: When you present a seemingly insurmountable task like trusting technology to invest billions of dollars, how do you keep yourself and your team motivated to take on this task and just keep pressing forward for it?
Khang: When you say insurmountable, you mean it’s a big challenge or is it something that people dread?
Andrew: It’s a big challenge because it’s a lot of start-ups too. They want to take on this task and they want to scale really quickly with such a small team and it wants to be big. They want to make a big wave and oftentimes when you present that to a team of engineers, the first thing on their mind is: this is a big task for a very small team.
Khang: I’ll start with a curveball answer: this is where a culture is important. What if part of your culture is being excited about big scary problems? Because your culture is all about being excited about that, you would inherently hire people who just were excited about that, and so that problem goes away. So make that part of your hiring, hire people who want to do big crazy things. Which is of course easier said than done.
I also think this is where leadership comes into play. It could be a literal leader or leadership, the quality within people. I think a really good mark of leadership is having composure. A good leader looks at a problem and says, OK let’s talk about this, let’s break it down, let’s see what the pieces are, decompose it.
You want to coach your team so that they can digest big problems. When a challenge or obstacle is big, they can calm down and consider, what is the ask? What are we building? What does Ken mean by we want to invest in 10,000 companies?
Play through it and slow it down, because another common mistake people have that I see a lot is that anything that’s asked they assume it has to happen right away. You want to get people to a place where they can calmly absorb an idea and create space for working through it.
Kingsley: My question is about technical debt. You talked about how most organisations have some form of technical debt and you talk about how there are different ways to go about it and you talk about ways not to go about it, i.e. having hardline approaches. What are the ways to actually go about it and from an individual point of view, what do you expect from engineers and making decisions and keeping the technical debt to a minimum?
Khang: To get tactical, a few things I’ve seen that worked reasonably well is to make some of this a part of your engineering culture. It could be that part of your engineering principles addresses things like refactoring or testing or quality to some degree. So in broad strokes, maybe your engineering principles give people permission to do things like leave the code better or encourage things like monitoring.
That’s a big one, finding a way to make that part of your engineering culture specifically so that people just have that as a muscle, an instinct, and that they have permission to do it mentally. That could have a very interesting effect, because when you’re doing your sprints and writing your code, there’s a small part of you in the back of your head that says, ‘oh I should leave it better.’ It takes an extra 30 seconds to change the order of functions or fix some spaces or add some curly or lint or something, so having a strong engineering culture that infuses quality and stewardship of code could actually take care of a lot there.
On-call rotations tend to be a good space to create a buffer, if your system’s relatively reliable your on-call should be pretty quiet. During the on-call, if you’re an on-call engineer part of what you should do is look at opportunities to improve code, refactoring, testing or whatever. That’s all about creating a safe space where you have the free reign to just work on specific things around tech debt.
Bugathons have also been popular in past teams that I had, where over time inevitably there will be some accrual of bug reports. In a way a bugathon is kind of like a hackathon, where you know that there are some things that you’ve always wanted to get to but couldn’t.
A ‘bug bash’ or hackathon-type event where the purpose is to make your customers happy, fix those bugs and put those tiny little features that we’ve always wanted in, that’s another way you can create space for engineers who want to do the right thing for the firm. If you just create that space and give them high-level guidance, they’ll end up doing that.
Alex: How can you promote an environment where innovation is welcomed and where new ideas coming from engineering can actually land on the roadmap?
Khang: In my experience, product managers tend to have louder voices, and sometimes engineers aren’t as vocal or maybe they’re more timid.
Part of it is about creating the medium for them to speak up. There are ways to do this by creating a space like a hackathon, or it could be a dedicated time where you can do anything. If your goal is to get these ideas into production and to be on the same level as an idea from a product manager, try to get a format that allows people to capture an impactful idea, receive feedback on it and get it tested.
I think as an engineering leader you want to make sure that the planning process is inclusive so that you avoid a common dynamic with planning, which is that it feels very top-down. An ideal planning process is both bottom-up and top-down.
It could be as simple as hosting a brainstorm session where people put ideas on a post-it note, where the format allows people to freely speak up. You want to make it so that it’s a safe space and there’s no rejection or criticising of ideas. As an engineering leader you want to make sure that you create that space for engineers so they can be brought along for the journey and have a voice.