The whole point of conducting a series of interviews is to be surprised by what your conversation partner has to say. Should you find yourself unsurprised, it’s sort of hard to argue that anyone learned anything new — a content cardinal sin, to be sure. More plainly, the resulting piece is bound to bore.
The LogRocket content team has wanted to launch an interview series for some time now (you may have noticed we’ve had our hands full with tutorials over the last few years). While people seem to enjoy the tutorials we publish, we couldn’t shake that gnawing feeling that we were neglecting the engineering manager. Maybe they don’t write as much code as they used to, but they’re every bit as important as the individual contributor.
We settled on “operational efficiency” as our first topic well before Covid-19 amplified its importance. So, when we set out to interview a group of engineering leaders about it, we didn’t expect an exposition on management would be the result.
We figured we’d hear a lot of technical discussion around processes and tooling, and the time (read: cost) savings they enjoyed as a result thereof. And, certainly, we did get some of that. But at the end of those conversations, what stood out most were the human benefits behind the processes.
The conversations were more about people than numbers — not just the teams these leaders managed, but their peers across the organization. The processes are the beginning, but they really exist to aid in the management of people and expectations. Operational efficiency is the result of all these pieces. How the pieces fit together is what follows.
Jordan Smith, software engineering manager, formerly at PillPack. PillPack is a full-service online pharmacy that was acquired by Amazon in 2018, and Jordan’s perspective is colored in large part by his time there throughout its early growth stages. Jordan now works for a large e-commerce company.
Sanjeev Banerji, VP of engineering at Ellevation Education, an edtech company that serves solutions for school administrators and educators working with English-language learners. Sanjeev, too, has a background in startups, having previously worked at Delphix and BitSight.
Amos Benninga, VP of engineering at LightForce Orthodontics, a medical device company that produces individually customized 3D-printed braces (and the software that makes it possible). Amos has a range of engineering experience, having formerly held leadership positions at GrabCAD and, later, Stratasys, after the latter acquired the former.
You want to build great software that people enjoy using — that’s a given. User feedback is invaluable here. But the exercise of balancing that user input with business priority, and the many voices that determine it, is hard.
“Like most of the things you do in management, you’re really trying to look for a Goldilocks, overlapping, Venn-diagram approach,” says Jordan Smith, a former software engineering manager at PillPack who recently joined a large e-commerce company.
Once you hit that sweet spot and decide what to work on, how do you make sure you don’t over-engineer the need? Building out too much of a feature no one uses isn’t just a waste of time, it’s bad for morale.
Your team won’t feel good about spending a month adding bells and whistles to a feature no one ends up using, to say nothing of how company leadership will respond. This is a major part of the MVP’s raison d’être — to validate a need.
“Something I’m drawn to is this notion of having a hypothesis,” says Sanjeev Banerji, VP of engineering at edtech company Ellevation Education.
“The MVP is about a hypothesis. It’s actually not ‘minimum time to value.’ It’s more, what’s the thing we can ship rapidly to answer questions?”
“And answering questions doesn’t mean releasing garbage,” he clarifies. “It means having something out to answer questions as rapidly as possible. And then once that MVP is out, we make an intentional decision as to whether we continue investing in it and at what rate.”
Amos Benninga, VP of engineering at LightForce Orthodontics, agrees. “We’re really looking around, what’s the MVP for anything we do?” he says. “We try to always do the minimum we can because the faster we can get it out to the market, the faster we can get feedback on that.”
“Instead of trying to spend too much time arguing about the specific feature set or something else,” Amos continues, “a big part of what we do is really around understanding the use case. What’s the minimum that we can do to get it out at not just the minimum quality, of course, but also the minimum functionality? And then once you get that, if you work enough with [your users], you start to get feedback, and that’s all the incremental development.”
“I think the balance [your team] needs,” he concludes, “is how much to get out and be willing to refactor afterwards, versus how much is too much to invest, building too much of a product before anyone even needs it.”
In short: build something that meets a need. Test it. Does it solve the problem? Does it provide value? Good. Keep building. Incremental development is for the add-ons, the nice-to-haves, the fine-tuning — the icing, if you will. Doing that work up front is a waste of time, and when time is your scarcest resource, that’s a cardinal sin.
Let’s double-down on how to avoid wasting time. Before you start building, leadership will likely want some estimate of how long a given project will take. The reasons are obvious. They want to understand how much time (i.e., money) they’re investing in a project before they move forward with it; the cost of building shouldn’t exceed its return.
In the agile methodology, this exercise of measuring time to delivery is often called t-shirt sizing or pointing. Without getting too in the weeds, it’s simply an estimate of how much effort it will take your team to deliver a user story, the end goal expressed from the user’s perspective.
Jordan, formerly of PillPack, questions not just the accuracy, but the usefulness of this exercise. “I don’t believe in really, really detailed engineering estimates,” he says. “And one of the reasons why is that I think they’re almost always wrong.”
“Everyone wants the same thing: they want to use the company’s engineering resources efficiently,” he explains. “But really what they’re saying is, we want you to put a lot of effort into planning to avoid the risk that we make the wrong decision. And I think that’s a naive approach, and it’s very expensive.”
It comes down to managing expectations — and remembering that you’re talking about an estimate, not a compact. That means maintaining open lines of communication not just with your immediate team, but with leadership and with stakeholders in other business units.
“We know that risk is constant and a certainty,” Jordan says. “How can we structure the project so that we front-load a lot of the risks? How can we have our team in such frequent contact with our business stakeholders that when we encounter a large risk, those stakeholders know what they’re opting into and are forgiving because they know what we’re dealing with?”
“I’m a big proponent of relationships and communication over formal contracts,” he concludes. “I think managing risk and uncertainty — and accommodating risk and uncertainty — is a better approach than trying to paper over it.”
What we’re really talking about is the skill of managing up, down, and across. It’s not easy, but it’s necessary, and you and your team will be better off for it. It ensures you and your team make the most of your time, and it also builds trust and strengthens your relationships across the company.
That trust will come in handy when you start advocating for unsexy projects like refactoring your architecture. The benefits are obvious to engineers, but it’s not likely your architecture will be a keystone of your marketing messaging anytime soon; it isn’t exactly a “key differentiator” to anyone but you and your team.
So you have to flip the script and sell the value to the rest of the company. That’s a lot easier when you have good relationships with the people you’re selling to.
“A motto I like to use comes from motorcycle racing: it’s ‘go slow to go fast,’ ” says Amos, the VP of engineering at LightForce. “If you build [the architecture] right, then you start to get more features more quickly without trying as hard. But if you try to deliver quickly, you end up taking a lot of shortcuts, which then, over time, accumulate.”
If you’ve been good to your word, compromised here and there on new feature sets, kept your lines of communication open, and in general been effective at managing up and across, you’ve likely got the caché to successfully advocate for substantive work on core systems. That’s the point Amos makes next. “A lot of the time, that depends on management.”
For Sanjeev at Ellevation, that’s something he’s tried to communicate to his junior team members. “I want them to think about it,” he says of explaining to non-engineers why it’s important to work on architecture. “If you can work faster, if you’re a little less annoyed, and that makes you more efficient, there’s business value.”
If you can communicate and, ultimately, objectively demonstrate the value of maintaining and improving your architecture, it’ll be easier to get others to buy in down the road.
It’s an approach that’s worked for Amos at LightForce. “I’m very happy where I am today because I think the CEO understands that when we build the right infrastructure, you start to get a lot of things more quickly.”
And your team will be happier and more productive for it. Amos puts it simply: “I think that engineers want to build great code,” and that starts with your architecture.
The reality, though, is that you need to pick your spots. You can’t refactor everything at every turn. And, going back to our discussion about the MVP earlier, you simply don’t have the time to work details to death. “There’s a constant tension,” Jordan says. “How do you balance the need to deliver business value with your long-term approach towards tech debt?”
Tech debt is the result of working quickly, and it’s a pejorative in the eyes of many. But it’s also a tool to be leveraged. You can use it when you need it to quickly test a hypothesis or get feedback, for example. “I’m pretty cavalier about tech debt,” Jordan says, especially in his time at PillPack. “I think that’s because it’s just the mentality you have to have at a startup.”
But to take an ambitious approach, you need to be ready to address issues that might arise as a result. Overusing tech debt can impact the relationships you’ve worked hard to build.
For Jordan, when internal users repeatedly experienced UI rendering bugs, they began to lose trust in other areas of the software — and, ultimately, in his team. “Even though the rendering bugs themselves weren’t very expensive [to fix], having a strong relationship with our stakeholders was.”
Amos, too, touches on the fact that your approach to tech debt has broader repercussions within your company. “A big part of technical debt is that you often get fights between sales teams and engineering teams around how much time to invest in new features.”
He continues, “When you fix technical debt, no one really knows what you’re doing because you go into a box for a month and come back, and [the sales team] says, ‘Well, what did we get? It’s the same product. I want you to spend time on new features.’ And so these kinds of discussions are a symptom, I think, of relationships and culture in a company.”
So on the one hand, you risk moving so quickly that you overdraft your tech debt and disappoint your users — and upset your team by forcing them to work with crappy code. On the other, you don’t adequately demonstrate the value of paying down your tech debt, frustrating your peers and leadership.
Again, it comes back to managing expectations and building a culture based on trust and communication. Your team needs to recognize the short-term benefits of cutting a few corners to move more quickly. Sales needs to understand how much more efficient your team can be when you pay down tech debt in calculated chunks. And efficiency makes everyone happy.
Indeed, whether your team is happy is the most consequential piece of all. A happy team is more inspired to deliver, and delivers more efficiently. The tools and processes you put in place, the relationships you build across the organization, these really only exist to benefit your team. Together with the right people, these factors lay the groundwork of your team culture.
It may sound obvious, but it begins with hiring. “I think the number one thing starts from hiring people that enjoy doing work,” LightForce VP Amos explains. “I think most developers, above all, enjoy building stuff for people. And if you have the right people, that’s what you get.”
Bringing in the right people only gets you so far. Figuring out what they need to feel valued and fulfilled on an individual basis is the necessary next step. “Essentially, it’s management 101,” Sanjeev, of Ellevation, says. “What motivates somebody? What motivates the individual?”
He’s quick to point out that for leaders with large teams, this isn’t sustainable. “It is very hard to replicate that on a person-by-person basis. So where are our leverage points? If I can help really empower one person, if I can put wind in their sail, they’re going to put wind in someone else’s sail. That’s what it is. What motivates people on a one-on-one basis, and then also, where are places where someone can get someone else really excited?”
Amos shares a similar sentiment about existential motivation. “You want to be important. You don’t want to be a small cog in a big machine. And that has to do with not just the size of the company, but the responsibilities. Am I allowed to override a test that’s failing? Am I allowed to force-merge? In the right culture, we expect people to be responsible.”
For Sanjeev, code reviews are another factor in creating a culture of accountability and empowerment. “We didn’t have a culture of code reviews when I joined [Ellevation]. One must have that — that’s a table stake. But it’s hard to institute that on the fly when you’ve got a successful company shipping product. We can’t pause, and we don’t want to pause.”
In his case, part of the issue was that his team’s efficiency was impacted by the legacy tooling they’d been using for code reviews. “So we finally brought in GitHub, moved all our repos over, and now we’ve got rules in place for code reviews, and that does increase efficiency,” Sanjeev explains. “Because you’re doing the right things as you get the code out. And we’ve seen bug counts go down non-trivially across the board.”
Shipping better code more efficiently and more often is a motivating factor in itself, according to Amos. “I really find that for developers, the more you release, the more you enjoy it,” he says. The cycle of writing, releasing, collecting feedback, and then iterating is enriching, and with the right processes in place, it’s seamless.
To paraphrase one of Jordan’s quotes above, all of your company’s leaders want to use your engineering resources efficiently. It’s fairly obvious why they do, and it becomes even more so when you start measuring the dollar value of your team’s time, the deals won based on new features, and so on.
But I was surprised that these conversations, which I expected would focus so intensely on the objective, quantifiable areas of operational efficiency, turned into more qualitative discussions around management.
It’s not that the tooling and processes you choose are inherently more efficient, that they save more time and money by virtue of design, it’s the fact that they contribute to a culture and an environment in which teams are simply happier, more motivated, and better informed. And that goes beyond your immediate team — it permeates throughout the company.
You could put a reasonably accurate dollar value on the cost of onboarding a new engineer and how much you stand to lose or gain against that investment based on their tenure at the company. But it’s harder, if not impossible, to put a price on the fulfillment they get from working on a great product with an efficient development process.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to implement one-way and two-way data binding in Vue.js, using v-model and advanced techniques like defineModel for better apps.
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
