Jean-Denis Grèze’s engineering management philosophy can be summed up in just one word: pragmatism.
“When I was younger, I really liked the idea of building a perfect system and engineering something really perfectly. And that’s nice in the world of computer science and engineering and in the abstract, but pragmatically, you’re at a company with a budget,” says Grèze, Head of Engineering at fintech startup Plaid. “You have a timeline by which you need to deliver something, or your competitors will deliver something faster. You have a lot of constraints. And in that world, great engineering is about solving business problems faster and better than your competitors can — and that just boils down to pragmatism.”
Before joining Plaid, he served as Director of Engineering at Dropbox. But he’s got a theory that his pragmatism goes back even further than that. After studying computer science back in undergrad and even starting his PhD, Grèze took a sharp left turn and enrolled in law school. And while he calls his journey to becoming a lawyer a “four-year detour he probably didn’t need,” he picked up a few powerful lessons.
“What I learned from that experience is that I love building things with computers, and the worst day I have as an engineer is better than the best day I had as a lawyer,” says Grèze. “The second thing I learned in law is that I’m not that smart. Before going to law school, when I was an engineer, I was an obnoxious know-it-all, who thought he had the right answer to everything.”
That window into the legal world began to crystallize this pragmatism versus perfection ethos. “Engineering and math can make you feel like there’s one right answer to everything. But the reality is in real-world engineering, there’s no right answer. There’s always a range of answers and they have tradeoffs. What’s really important is convincing other people to align behind one answer. That’s what I learned in law school,” he says.
It’s not a world of black and white — being a manager is about getting groups of people to align on a path through the gray area.
In this exclusive interview, Grèze unpacks his advice for the five biggest challenges engineering leaders face — from crafting an ownership-driven engineering culture and aligning on a single galvanizing KPI, to honing his hiring ethos. He also gets incredibly tactical on how he approaches team motivation, navigating the seismic shift to becoming a manager-of-managers, and why he prefers folks on his teams don’t have titles. Grèze pulls on threads from across his career to weave together a modern playbook for engineering leadership — and the hard-won lessons from Plaid and Dropbox that stick with him.
ENG LEADERSHIP CHALLENGE #1: HOW TO CRAFT A BOTTOMS-UP CULTURE OF OWNERSHIP FROM THE TOP.
When Grèze reflects on the commonalities across great engineering managers at both Plaid and Dropbox, one “It” factor jumps out. “Both companies shared a value of ownership. The best leaders act like no problem is outside of their purview. It doesn’t matter if it’s a business problem, a design problem, an engineering problem, or a legal problem. They push through and find a way to get groups of people to solve the thing,” he says.
And while ICs may not have that amount of cross-functional influence, Grèze is adamant that this same ownership mentality can and should be applied to their own spheres of influence. “On the IC side, I see ownership a bit differently. I think of it as a little more constrained to your immediate project — making sure everything gets done on the things that you can control,” says Grèze.
But like any cultural ethos, this doesn’t happen by accident. “It might be surprising that my most common answer to a lot of organizational issues that come up is to just say, ‘Hey, that’s great, why didn’t you tell [insert the name of the right peer] about it? You need to solve it with that person.’ I want the leaf nodes across various functions to figure out 90% of the more difficult things on their own,” he says.
It’s a team-wide habit he’s constantly reinforcing.
I write multiple emails a day that basically say, "Thanks for telling me, I appreciate this as an FYI, but I don’t understand why you and this other person can’t solve this on your own.
Cut through complexity from the bottom-up.
Grèze peels back the layers to why he believes so strongly in this approach for the API company. “Plaid is interesting because we have three very strong stakeholders for almost everything that we do. On one end, we have financial institutions. On the other end, we have developers. And on the third end, we have consumers. That complexity can be very costly because you generally don’t want three stakeholders for all decisions that you make. The incentives are not the same for each of those groups,” he says.
There’s one thing I believe in really strongly for Plaid right now, which is that we will succeed if we’re really bottom-up in our approach to problems.
“At the unit level, if every time someone runs into a problem it goes up to me, the cost for me to understand the specific problems with those three stakeholders, as it applies to whatever the product is, it’s ginormous. It’s just way too complicated. But for that team on the ground, they actually have all the knowledge that they need. When they push it up to me, I don’t have any additional insights. The world is just too complicated for me to chime in,” says Grèze.
He’s got a clear directive for the problems to up-level. “The only questions I want to go up to me, frankly, are questions where allocations of budget or people is a hard trade-off. If we don’t have enough people to both make customer set A and B happy, that’s my job. Let me work with our CEO and figure it out. But otherwise, I want the units as low to the ground as possible to learn how to deal with that complexity on their own, because that’s how we’ll move fast,” he says.
Scaling bottoms-up and embracing cross-functional arguments.
Grèze flags a couple potholes where he’s also seen things go sideways. “As Plaid grew, the number of things that weren’t solving themselves bottom-up kept increasing. It took us a bit of time to recognize that this stuff used to solve itself, why is it not happening now?” he says. “EDP worked really well together, but the membranes between EDP and go-to-market weren’t very fluid. People would share information, but the decisions weren’t being made,” says Grèze.
The diagnosis may surprise you. “The interesting root cause behind that actually comes from a lot of trust and respect for other functions. You kind of assume that the other side is doing the right thing and you trust them. But that means you haven’t built a muscle for arguing with them,” says Grèze.
He sketches out an example. “We have a really strong legal team, and every time legal has done anything, the quality of that work has been A+. But that also means no one’s used to asking legal if there’s a different way to approach and solve a problem,” says Grèze.
“It comes from a good place. Who doesn’t want to have strong functional identities and a lot of respect for your coworkers? These are all positive qualities, but you’ve got to see them to their logical conclusion. As you grow, you always have these kinds of scale problems where things that are good at one stage don’t end up being good at the next one,” he says.
That’s the fun part of management. You identify the problem, you talk to peers, you make a mistake, eventually you solve it, you move on — and something else becomes not as good as it should be. You keep moving forward.
ENG LEADERSHIP CHALLENGE #2: HOW TO MOTIVATE FOR TACKLING BIG PROBLEMS AT SCALE.
Grèze points to two key areas where he thinks very strategically about motivation: metrics and values. This yin-and-yang balances the quantitative needs of the business with the qualitative, less-tangible aspects of human nature.
Align on impact with the right metric.
“The easiest way to get clarity on impact is to have a KPI where it’s easy for people to understand how their work lines up to the KPI,” he says.
Grèze outlines an example from Plaid from the earliest days when he joined the company. “Every engineering meeting, every all hands, we talked about the percentage of users on Link,” says Grèze. “Link is part of our SDK that’s embedded in the apps, web and mobile that developers use for building on Plaid. Before, you either built your own UI or you used Link, but we realized it was better for end consumers and for developers longterm for everyone to be on Link.
Here’s why it worked: “It was really clear — now it’s a rallying cry. Every single team could look at that KPI and say, ‘Is the work I’m doing going to drive this metric? Is it going to make it easier for developers to adopt Link? If so, is it the highest ROI thing that I can do?’” he says. “Just the fact that we had that metric made it a lot easier for people to align their work. I’m not saying bad ideas weren’t generated along the way, but they could be considered. And if they weren’t the best way to do it, you had a language to talk about it: Amount of time on engineering spent to get what lift of end-users using Link.”
Create tokens that align with your values.
On the qualitative front, Grèze has seen time and time again that small gestures can have an outsized impact. “I’m a big believer in incentives that align with the culture and values. A funny one that people don’t realize can be super helpful is creating tokens — objects that you reward for a specific behavior," he says. “You can create a subculture around a new value. Humans — we love an object, we love a token.”
He pulls an example from a past team. “We had a model of the rocket ship from the Tintin cartoon. It’s this cool 1920’s or 30’s vision of a future spaceship, with a red-and-white checkered pattern. Every two weeks in our managers meeting, we’d share two highlights and two lowlights. Then we’d all vote and give that spaceship to the team that had the most impact,” he says. “There was a ton of pride in being awarded that spaceship as a team, and oddly enough, the spaceship took on a life of its own as a token. When a team was going to launch a new feature, they’d try to make a splash and drive impact so they could receive the spaceship,” says Grèze.
ENG LEADERSHIP CHALLENGE #3: HOW TO BALANCE COMPANY GOALS AND EMPLOYEE GOALS.
“I came into management a little bit later into my career, and the hardest part of management is to manage the times when the expectations and hopes of individuals don’t match the expectations and hopes of the company. That’s when management gets really, really difficult,” says Grèze. Think when a report comes to you with a passion for growing their skills in a particular area — without a clear direction for how that piece fits into the larger team puzzle.
“My solution to that has always been to be very direct with people who report to me. I’m like, ‘Hey listen, Alice or Bob, this project is really important for the business. I know it’s not quite aligned with how you want to go in the next six months, but it’s the most important thing for the business, and let me show you why.’ That’s so much more trust-inducing, reasonable and clear,” he says. “If I ask you to take one for the team now, next time I’m giving you what you want. I always put the business first in the short-term and the employee first in the long-term.”
I have a speech that I give, which is: "In the moment, I will ask you to do what’s right for the business. But over time, I’ll do what’s right for you." Meaning, when there’s that misalignment, I’m not going to let that misalignment last too long.
But what if you don’t see a direct line to the employee’s career goals? “That’s a tough conversation, isn’t it? If you want to be a manager and you haven’t shown the skills, I need to lay that out: ‘I know you want to be a manager, but if you’re a manager you need to work with different personalities, or you need to deal with ambiguity and I’ve got concrete examples here where you weren’t able to do that in the last six months. I’ll meet you halfway, which could be pairing you with someone who’s good at it, and you get to learn and you get to show me that you can do it,’” he says.
One of his favorite examples is when the needs of the business and the needs of the employee finally coalesced — but it took some patience on both ends. “There was an engineer who wanted to become an ML engineer, but had no experience at all in that space. And I said, ‘Okay, you can take half a day every two weeks just to do ML on your own time, but I’ll ask you to do it at the office and keep me apprised of it.’ And after that, there was a project on the ML team that required someone really junior. It took a year and a half, but eventually they were on that team, doing ML full-time,” he says.
ENG LEADERSHIP CHALLENGE #4: HOW TO BUILD TEAMS WITH HIGH HUMILITY AND LOW EGOS.
When it comes to hiring engineering managers at Plaid, for Grèze it all goes back to the culture of ownership.
A quote from a good friend of mine says, “Great managers have an overdeveloped sense of responsibility.”
“I love that word overdeveloped, because it’s a big burden on your life to worry about a lot of things. But you don’t just stop at the boundaries of your team, you stop at the boundaries of the problem that needs to be solved for the business,” he says.
This is why in the interview process he pushes hard for candidates to give plenty of examples of when they’ve swam outside their designated lanes. Grèze’s got one other go-to interview question that he always leans on. “I ask them to tell me about a time that they failed. I provide more context behind the question so they can be honest with me and tell me about a true failure,” he says. “50% of people either give you a fake failure that actually makes them look good. And the other mistake I see is they point out a failure, and they clearly haven’t thought about how they would have behaved differently if they had a time machine and could go back in time. Basically half the people fail that question and don’t move forward in the process,” says Grèze.
The hidden traps of titles.
“Most places I’ve worked, I have preferred not having titles,” says Grèze. His reasoning may sound familiar: “The point of a title structure is that people will use the titles internally. They’ll say, ‘Oh, so-and-so is a staff engineer, I think you need to get a principal engineer to review that.’ Or ‘Seems like you need a senior architect for a project of this size.’ Those are the behaviors that I want to stop,” he says.
The danger of titles is that the best idea doesn’t win, and it creates an internal hierarchy as to whose ideas have more merit than not.
Instead, the company assigns tech leads for specific projects. “I like it much better when the process is, ‘Hey, Alice or Bob is the expert in the system. They’re really the person who should be the primary reviewer for your tech spec, because they know a lot about this.’ It doesn’t matter what Alice or Bob’s level or title is — they’re the right person because they know the most and are going to be most helpful for that problem,” he says.
But career levels are deeply embedded in our experiences in the workplace — particularly when it comes to tracking our progress and growth. To strike the right balance, Grèze’s implemented personal, internal levels at Plaid — such as E2, E3, E4, etc. “We have levels, but they’re private to yourself. You know what you are, you can feel the accomplishment for yourself, but because other people don’t know what it is, they don’t look at you differently because of your level,” he says.
But Grèze will admit there are drawbacks. “Recruiting people who love titles becomes more difficult,” he says. And as the company grows, you’re not able to look to titles to navigate increasingly-complex orgs. “Another benefit of titles is that you know who to speak to on another team when you’re looking for somebody who’s an authority. If you have a 2,000-person engineering org, isn’t it nice to know immediately who’s the person on that team that I should speak to who’s an expert?”
But Grèze goes back to that pragmatic streak — and accepts that all decisions have tradeoffs. “I think with things in place like tech leads, we can have a really good high-humility, low-ego culture.”
ENG LEADERSHIP CHALLENGE #5: HOW TO TRANSITION TO BECOMING A MANAGER-OF-MANAGERS.
Grèze’s most recent stint as an IC was over seven years ago, before taking on leadership roles at Dropbox and Plaid. “It’s not just the role of management. It’s managing a bucket of teams or managing a function where you might as well be an alien to the average person on your team,” he says.
Now, the tasks that used to come as second nature don’t quite fit within his day-to-day. “It requires very different skill sets and approaches. Right now, if I go and read a technical spec and write comments in it — that’s a disaster waiting to happen. Because whatever I write, only a handful of people on the team will feel comfortable telling me that I’m an idiot, just because I’m ‘the big boss,'” says Grèze.
Over time, he’s needed to adapt his approach, including flexing his empathy muscles. “Most of the things that managers complain about their lead-of-leads or VPs not doing well, actually are things that their lead-of-leads and VPs aren’t doing well,” he says. “All the examples that I can think of are: ‘You didn’t communicate to me early enough about this organizational decision or change you wanted to make.’ Or ‘You didn’t provide clarity on the strategy or what I should by optimizing for, and then you’ve decided to kill the team because it’s no longer right for the business, and I feel like it came out of left field.’”
It’s really hard and it takes a huge amount of time to communicate with all your managers about everything. There’s so much context sharing. Every time I get in a situation where someone’s unhappy, I realize I could have just communicated about this more and earlier.
Stop us if his example sounds familiar: “You send an email to six people, and then you realize you forgot somebody. Now you know that if you forward the email to them or add them afterwards, you’re like, ‘Ugh it’s going to hurt their feelings or their ego because they should have been on the email initially,'” he says. “You kind of wish everybody understood the big picture, because you’re trying to do right by the big picture. So whenever you miss the communication and someone gets offended you’re like, ‘Okay, I forgot to include you, but you should understand that I’ve got 250 people to keep track of.’”
Over time, that knee-jerk defensive instinct began to fade. “You think about it for a few seconds and you realize, ‘Oh my God, no — my one and only job is to globally set everyone’s expectations correctly and to communicate to them.’ Just the fact that they’re offended reflects that, in general, you’re not doing a good job of keeping them informed such that you even had to draft the email in the first place. Or in the past you’ve made them feel not included in the conversation,” says Grèze.
Spot the right signals, and ignore the wrong ones.
Just as Grèze doesn’t call for his reports to understand all the challenges from his perch, he doesn’t expect to grasp what’s entangling those a few layers down. “It’s been a long time since I was an IC. I don’t recall that much about what was difficult or easy at that scale anymore. There are times when things don’t happen and I don’t understand why they’re not happening. But that’s because I don’t remember what it’s like to be in those positions and how difficult it is to deal with certain classes of problems. I’ve forgotten the problems as much as the solutions,” he says.
Instead, from his rung on the ladder, Grèze keeps an eye on annual goals, churn, hiring rate, pulse surveys and how the teams are trending towards KPIs. One thing he refuses to check in on? Hours spent in the office. “Is the business hitting its goals? Is it okay with how much money is being spent on engineering? And if the answer to both of those is yes, do you care how many hours people are working? I don’t care how many hours people are in the office. I don’t use GitPrime to measure productivity,” he says.
“What I look at is the percentage of our OKRs that are green, and I use a very simple feedback cycle. If you’re green on 90-95% of your OKRs, I would like for you to be more ambitious next time. And if you’re green on 50% of your OKRs, I would like for you to be better at estimating and more realistic about what you can do the next time around,” says Grèze.
To fill in the gaps between what the KPIs can’t tell you, Grèze leans on his management squad. “There’s a dozen metrics that I look at, but for each of my managers it better be art and not science. They need to understand the morale of their team, not just from their pulse scores, but from the 1:1s they’re having,” he says.
WRAPPING UP: WHAT’S NEXT ON THE HORIZON?
“There’s a lot of ways to create a culture in a company. My observation on Silicon Valley is that we’re all operating at a local maximum of what great engineering could be,” says Grèze.
“When you think about it, we’re all learning from Google, right? There’s Google managers, and then they go to Dropbox, and then the people who learn from them go somewhere else. Then you have managers from Facebook — same thing. And then you have the Amazon tree, the Microsoft tree, the Netflix tree — all these trees,” he says. “There’s these templates about how you build companies and how you build engineering teams that are passed down. But if you look at the origin of the templates, it’s just a few companies.”
Overall we’re at the infancy of how you build great software. Yeah it’s been 60, 70 years. But compared to building bridges, we’re still at the infancy of this world.
“I think it’s exciting. We’re still learning and playing with things and seeing what really works. There’s a lot of variety of things that need to be tried,” he says.
Grèze points to an example most are plenty familiar with after the past year. “The distributed teams that are happening right now, it’s forcing people to consider different ways to make decisions that would never have happened otherwise. It’s forcing us out of our existing set of practices, and it might be for the better. You might come back to in-person and have learned a bunch of things from remote work. There’s a big market for being slightly more efficient at building a company,” he says.
This article is a lightly-edited summary of Jean-Denis Grèze's appearance on our new podcast, "In Depth." If you haven't listened to our show yet, be sure to check it out here.
Cover image by Getty Images / Felix Cesare.