SPEAKER

Jan Chong - VP of Engineering @ Tally

Jan Chong is Vice President of Engineering at Tally, a financial automation company helping people navigate the complex world of consumer finance to save money, pay down their debt and reach their goals sooner. She leads and oversees the company’s client engineering, infrastructure security and technical operations teams.

"Organizations are made up of humans that are making decisions based on the data they have. If you don't think about how that data is being seen and understood, then you're going to have a really hard time getting the outcomes or driving the goals that you want to achieve..."

<cite>- Jan Chong</cite>

Before joining Tally, Jan was a long-time executive at Twitter where she played a critical role in launching and scaling its core mobile and web products, overseeing a team of more than 300 people in Twitter’s consumer engineering organization. Prior to that, Jan ran client and server development at OnLive, a cloud gaming platform. She received multiple degrees from Stanford University, including her Ph.D in management science and engineering, and M.S. and B.S in computer science.

Special thanks to our exclusive accessibility partner Mesmer!

Mesmer's AI-bots automate mobile app accessibility testing to ensure your app is always accessible to everybody.

To jump start your accessibility and inclusion initiative, visit mesmerhq.com/ELC

Show Notes

• What is Managing Up (3:52)
• What to do when your manager has different expectations and perception of your performance (6:19)
• The fundamentals of managing up (8:42)
• Making the world of management visible (10:39)
• The three categories of “managing up” and why you should align with your peers first (15:07)
• Who you need to “mind-meld” with & how to replicate it remotely (22:29)
• How to align & “mind-meld” with your peer leaders (27:22)
• Managing up at different levels of seniority (33:28)
• What you need to do to “manage up” effectively (39:30)
• Unexpected differences of working with non-technical colleagues & Jan’s metaphors to explain engineering (43:23)
• Takeaways (51:05)

Transcript

Patrick Gallagher: We're here to talk about managing up, what it means, how to be effective at it and explore the different scenarios that engineering leaders can expect to encounter throughout their career.

Because oftentimes at work, we're all pretty much accountable to someone. And if that person's a great manager, awesome! Our life is easier as a high performer, but given a lot of the stats around work today, especially around happiness and the oft-cited quote "that people don't leave companies, they leave bad managers."

Odds are, most of us don't really have a good manager...

Jan Chong: I would like to push back on that though...

I want to say I hear that quote all the time and I have personally left excellent managers. So I think people overweight that. But I do, I agree that the larger trends

Patrick Gallagher: I think my attempt was to highlight the stakes that regardless of whether or not you have a good or a bad manager or who you're accountable to, it's essential to be able to manage up because your ability to navigate interact with those people is essential.

But Jan your experience is unique in that you've navigated the challenges of managing up across almost every permutation of seniority level, company size, and across almost all different types of functions. So we're really excited to dive in to all of those experiences today with you.

We want to start off with a high level and then maybe dive into some of the specific scenarios. So I think to get everybody on the same page... what is "managing up?" And is there a specific time or scenario where you experienced the pain and challenges of managing up that stands out to you?

What is managing up?

Jan Chong: Yeah. So I think of managing up as actively thinking about your work and your performance through the lens of someone else's eyes, usually your boss... and adjusting how you do your work and how you represent that work in order to fit to that.

So in some ways I think of it as meeting your manager halfway, and as your manager becomes more important in the company or higher up in role, often that halfway goes much more, or you might have to beat them like 90% of the way in order to kind of get there.

And I think almost the theme for everything we were talking about today is a little bit like "it's not about you..." and how to kind of break outside your personal perspective.

An early on lesson that I got and kind of thinking about how to do this is one of my first jobs at OnLive, which is a cloud gaming company. I had to do a lot of work on video performance. But we kept getting complaints from our exec, actually our vice president of engineering... about the system being slower. Even though we'd been kind of for weeks and weeks, making a really steady stream of improvements.

So I found this really frustrating cause you do all this work and then on Monday he'd be like, "No build's still slow. It's not working."

It's like "What the...?"

And the light bulb moment was really sitting down with him, at the end, I was like, "What are you seeing that I'm not seeing?"

And realizing that the way he was evaluating our build was that every Monday morning we'd publish the new build, and he would install it on his machine. And then he would do a run through of his favorite driving game. Which is Need For Speed.

And so he would just play a round of Need For Speed. And then based on his course time, that was how he was judging whether or not our build was faster or slower. And that made us realize, "Okay... well, we need to give him a better way to think about performance time."

Because certainly his lap time is good, but not probably, not entirely correlated with video build performance.

Patrick Gallagher: Or consistent, because I feel like unless you're, unless you're a machine, you can't have a consistent time.

Jan Chong: Yeah. So we ended up building a "per stat" overlay that he could turn on and see live as he was playing what the actual system was reporting as his performance stats. And that was kind of a way for us to align how he was measuring performance with how we were measuring performance.

And sure enough, after that, you know, the complaints kind of went away. Or it would be a little more scientific about what aspects were broken.

So that was a really abrupt lesson.

Patrick Gallagher: So specific to that moment I'm really curious, you know, how did you first identify the difference between how he was measuring performance and how you all were setting up the test structures for how you all were measuring performance. When did you first notice that?

What to do when your manager has different expectations and perception of your performance

Jan Chong: Well we had internal stats that we were looking at, but they were very informal. They were a little casual, you know, it's a startup company we weren't public or the product hadn't been released to users. we would do it. We would run a couple scenarios and we had some reporting, And so we were looking at those numbers and feeling really good.

We were saying, Oh, we would think about what new optimization we should make. And we would steadily see impact. And so we have this really strong narrative internally to the team of "we are killing this project."

And so it was weird to every Monday, get that JIRA ticket. That was just like, "Nope! like still not good. It still needs to be better."

And in a service like that, there's actually many breakdown points, right? It could be, the wifi. Could be whichever, you know, network congestion could be the game itself is introducing actual latency in the system.

So we started asking for more and more details " Hey, tell us, what are you actually doing?" And we'd replicate it and still not have the same issue. So it was literally "I'm just going to sit beside you. Can you just show me what are you really doing? And how we are so off? why do you just keep telling me this is bad when I feel like we've put in so much work to make it good."

So it was really that core discrepancy.

Patrick Gallagher: I think just to point out the aha moment in the lightning moment of, of almost stopping everything we need to halt the presses. Just tell me what's going on. Let me follow you.

I think that really strong moment of calling to action of like, we need to figure this out, sometimes you just need to really call extreme attention to something, to move forward.

Jan Chong: I mean, and as an engineer, it was very frustrating because this is not making the system better. This is by definition cycles I am not spending on optimizing system. This is cycles I am spending on thinking about how someone internally is perceiving the system. In the moment I was like pissed. I was like, this is a waste of my time.

But coming away from that in my career, Right. It made me realize how much that is a valuable skill and a big part of being successful in an organization. Because organizations are made up of humans that are making decisions based on the data they have. And so if you don't think about how that data is being seen and understood, then you're going to have a really hard time getting the outcomes or like driving to the goals that you want to achieve in that organization.

And so that actually turned out to be kind of a catalyst moment.

Patrick Gallagher: Wow. So let's deconstruct a little bit about what you've learned from that moment.

And when you think back on all of your different past experiences, what have been some of the keys or the fundamentals that you've found for managing up?

The fundamentals of managing up

Jan Chong: I think there's three basic pieces that are at least how I think about it...

One is the visibility of the work that you're doing and how much the person in this case, your manager really understands it. In Engineering we're usually lucky in that for a really long time in our careers report to other people that have been engineers. And so they get the fundamentals of writing code and what are the challenges of bugs... and how, you know, you have to refactor and how you have keep code living and it needs tending. That's actually not truly understood if you're not an engineer sometimes.

Then there's how does your manager actually judge your work to be successful?

And this is the piece that people usually have a sense of the visibility and understanding. But they stop thinking a little bit about okay, how is it evaluated? Because we know our work so well that we think, "Oh, okay. If I've done a good job, it should be self-evident through the work. It should just be really obvious that this is now good and possible."

And we don't think, "Oh, Do other people have that same frame to think about it that way?"

And then the last one, which is even more I think advanced is how does the work that you're doing solve the problems that your boss have, or can help them in general?

I think people now that I'm in a leadership role, people come pitch me ideas all the time for projects or things we should do. And I think they sometimes leave a little bit frustrated if I'm not like, "Oh yeah! sometimes like, Oh, it's a good idea, but just not important enough right now."

And that's a great answer because you see your slice of the world so much, but you don't always see the whole slice of the world. So people are generally focused on solving their own problems. And they don't realize, A this problem is just not that important, actually relative to everything else that's going on. Or this part of the solution actually creates more problems for your boss in other places. Which is really, really common.

But if you can align that and create solutions that solve both of your problems AND your manager's problems, those are gold! Like I'll fund those in a heartbeat.

Patrick Gallagher: And the specific question you asked there is, how does this solve the other person's problem?

Making the world of management visible

Jan Chong: Yeah. Yeah. We have our slice and we have, in engineering particular because engineering is complicated and complex so often... and the details matter... so we're so trained to be in those details and think about that. That it actually is something we have to force ourselves to do almost as an exercise to step back and say, "Okay, how does this fit into the bigger picture? What is the thing that really matters?"

Another exercise, I sometimes tell young managers to do that's a regular practice, but it kind of lines into this is... when you have your one-on-ones with your boss, what you want to talk about as a manager, that's different from what you talk about as an individual programmer is you want to say, "Hey, these are the problems I'm going to solve this week. This is my priority. This is what I'm not doing in order to focus on those pieces. And this is kind of what I'm worried about on the long run, this is kind of what I see coming on the horizon that I think we might want to be thinking about in the future, but there's nothing to be done right now."

And what you're doing with that is making the work of management visible because often the work of management is not visible. What did you spend the whole week doing? You got people to align around a decision. That's not inherently visible other than people saying, "Oh, yes, I think we should do that now."

But it's hard to tie that back to, "Oh, I spent two hours talking to different programmers on the team to pitch that it was like a pro and a con for this particular decision..."

So this kind of helps make visible, like This is literally how I'm spending my week..."

And then management often can also be like, when things are going well, you don't always see all the work that's required to keep it go well. So then you're like, "Okay, why didn't you solve all the problems?"

Right. That's helped provide a context and framing us as like, "Okay, well, here's what I'm deliberately being forced to deprioritize in order to get these pieces done."

Patrick Gallagher: Can you talk a little bit more about the invisible world of management, because I think you're so right. It is so hard to make all of those things apparent to other people. How do you make some of those things in management more visible to your team in terms of how you're making decisions or why you're choosing to focus on different tasks or how you're answering the question of how are you spending your time?

What are some of the elements that you focus on?

Jan Chong: I think for your team and for your manager, it's very different. Your manager is usually focused on your outcomes, and then your specific time and ability to get to those problems. Often there, you kind of create a summary of this is what we were doing this week, and this is the key problems. And then you want to show your work as much as you can.

For your team. I mean, this is one of the challenges when you go from being an IC to a manager is realizing what your work is like. People ask me a lot about what that transition looks like, and you're like, well, "Do you feel good about the fact that the end of the day, you just sent a lot of emails? And then held a meeting?"

That's your work! That's your job!

I actually don't think that making your work visible as a manager to your reports is actually... I mean, you want to give them a sense of how much time you have for different things. But I don't actually think that making my problems, their problems on a regular basis is really a healthy thing to do. You actually want to give them the space to work best.

As a job, actually, I think your manager responsibility is a bit to filter. Or it can be a really noisy place and you kind of want to make sure they're getting the right information, but also are not being overwhelmed with all the information that might not be relevant to what they're doing.

And so I think having your manager seem like the quiet person that makes things happen is, kind of okay. So weirdly I think I would answer that, I don't think you have to think so much about making that piece of the work for your reports, but for up into your peers I think then it's quite important to say, "Hey, this is what I'm tackling, and this is what I don't have time for."

Patrick Gallagher: To go back to one of the questions you shared earlier, I just wanted to relate Jerry, technically is my manager. And so when you shared the question of how does this problem that I'm trying to solve, solve their problem? I can tell you the times where Jerry has been the most frustrated with me has been when I haven't answered that question on the front end.

And so just to speak to the power of asking that ahead of time, I know that it would have saved so much time between Jerry and I having the whole calibration conversation of the project I'm working on, is it worth it? We would have expedited that time so much and saved Jerry a lot of, a lot of hassle and, you know, pulling out his hair and stuff like that.

Jan Chong: That's good to hear. Good to hear.

Patrick Gallagher: Okay.

Jerry Li: That's a fun part of having a podcast of three of us so that we can go back into some of our challenges between our own team to serve as examples to illustrate the takeaways we have.

Patrick Gallagher: In our relationship, I would. Put myself in the category of the IC and Jerry being like the manager and CEO all at the same time. And the fun stories to tell are the ones where I make his life really tough. And what I learned from that experience and what he learns in working with me from there.

So...

The three categories of “managing up” and why you should align with your peers first

Jan Chong: It's interesting that you talk about categories because I think another aspect of managing up is that it's not always up. There's actually many different relationships you have to navigate in an organization and the same skillset sort of applies.

So for me, when I think about joining a new organization or initiating a major change in an organization, I actually think there's three categories.

I think of the peers that I'm working with, kind of to the side, if you're going to keep the directional analogy, right.

Up is the classic one of who your boss or your leadership team is.

And then down being the people who report to you.

There are actually three demographics or groups of people that I actually tactically think about how I'm going to align with and interact and in what order.

So I have this like strategy that I use whenever I come into a new position... or again, when I just make a big change where I strictly talk to my peers first and align with them first. Then I aligned with the management team, the leadership team above me. And then I turned to my organization and start to like, think more strongly about how to bring them into alignment there.

Now, in reality, you're kind of doing all of them at the same time. But I strictly prioritize those groups. And it's because I'm kind of lazy. I think a lot of my core management philosophy is how do you have the highest ROI pieces? And if having thought through the structure, I'm like, "This is the most efficient way to get through those pieces. So that the system works for you at the most number of steps rather than working against you."

So my theory behind that is this... when you align with your peers, which are the people who you don't have reporting authority over, but you really just have to collaborate with to get stuff done. So my career as an end consumer, I'm product engineering is often PM product management and design, then other eng teams or people that I just need to like be on the same page as me to get stuff done, but I usually can't order them to do that.

So then I spent a ton of time working with my peer leaders or whoever's a functional in that role to be like, "Do we agree on what the right next step priority or change is?"

And I have to say my PM partner at Twitter he's the one who kind of like, got me thinking about this because I joined his org that he was already leading taking over the eng position and he just came up to me and he was like, "I'm going to mind-meld with you..."

And he literally moved his desk like next to mine.

And he would be like, "We're going to be best friends!"

And he would DM me. Every night he was like, "What are you think about this? What do you think about that? I just don't get TikTok! What do you think about TikTok?!"

And at first I was like, "Oh my God, this is very overwhelming... but what it did was in a very short amount of time, we could speak for each other we could literally speak for each other. We could finish each other's sentences.

And so in meetings it was great, right? We didn't both have to be there. I trusted that he would be able to represent my concerns. He would understand what the engineering team wanted to ensure happened before something happened. And so it was just more efficient.

And because we were aligned on like, " Okay, this is what we see are the top three challenges for our organization that we should be tackling in that order. And that's the order of we're going to like do it."

Then when we went to go talk to our leadership team, because frequently you have more than one boss who ultimately has decision-making authority over any big project or thing you want to do... Now there were two of us making that argument! Right? And we were aligned in what we were pitching. And had thought about different perspectives and could answer a lot more questions, in a lot of different forums, even.

You know, for us, it was product management has its own series of meetings and leadership forums. And Engineering has its own series of leadership forums. And so now both of us were working at the same time to be like, "Hey, we really feel strongly that this is what we should be doing."

And then when you get that upward buy-in. That means when you go back to the folks that report into you, You've now having a very strongly aligned, "This is the path forward. This is the goal we're going to take."

And along the way, usually what happens is that you are talking to your own function about it. And so the functions are actually sort of already gradually drifting in that direction. And so when you can finally come out and say like, "Okay, this is the new plan. This is what we're all gonna aim for and help us figure out how to get there."

Right? You can come in feeling really good that it's not going to be something that you're going to have risk of changing your mind the next day or the week after, and have to come back and be like... "Actually... k... leadership didn't agree.... so now we're going left instead of right."

Which no one wants to do. That's kind of a bad experience for everybody. So that's my order. I feel very strongly about it.

Jerry Li: I wish I had know that earlier when I joined new organization or new teams because I believe a lot of people they may resonate to what you just mentioned, but it's hard to be aware to actually actively think about that. Be strategic when you transition into a new organization,

Jan Chong: just want to say, really quickly that it's hard also because when you join as a leader, you feel this responsibility to the people who report to you. At least if you're a human.

And so often you get sucked into that, just naturally. Because people see you as someone who can solve their problems and they bring them to you and you start to want to solve their problems and you have to fight that actually to do this. You have to really be like, I hear you, but I'm going to work on this instead. And that's hard.

Jerry Li: And also this relates to the notion that your first team is actually the peers that you collaborate cross-functionally. and this is, and then a reflection from that by prioritizing that relationship first

Jan Chong: yes, I actually this is Lencioni's first team concept. I actually loved Lencioni's books and his concept of first team. And I actually think to be an effective leader that because the job is hard and so complex and you have, what I call the "collective weight of human want" is on your shoulders. When you are a leader having a set of people that are working with you to solve that problem is so critical to doing that effectively.

My husband and I play a lot of video games we always say " We need to fight evil, not each other!" And that's sort of like building a space where you can fight evil and not each other is like super, super important. But also hard.

But the thing I have a problem with Lencioni's first team concept is like often we have multiple first teams. Often we have multiple spaces and I don't find them to be in strict conflict. a functionally organized organization where you're in product, you have the engineering product and design team that you have to work with. And then you have the engineering leadership team that you're usually on. And then sometimes you have kind of like your team with your directs. And you have to have that affiliation and trust on multiple levels.

And I've always struggled with trying to prioritize them so strictly.

Jerry Li: I think it makes sense to have multiple first team, depending on the scope of that project or ownership. So you can have within an engineering organization, for example, you may collaborate. If you aren't focused on product, you may collaborate with, engineering leaders running dev ops or infrastructure. So that's a first team. You can turn around and collaboratives product and design for the features that could be another first team.

Jan Chong: It's clear for exec teams where, they already kind of want to be clear, your loyalty should be, or your loyalty is like a weird word in a business environment. I think it's really you're focused on your collaboration and trust building should be on your peers at the executive level rather than your function. But for folks that are within that organization, I think it's less obvious.

Patrick Gallagher: I have a couple of followup questions specifically about the mind-meld. This is a little bit of a two part question,

Part one... Do you have thoughts on replicating the mind-meld now in a more remote or hybrid environment?

Two... are there key strategic counterparts you should be mind melding with? Like if you had to pick your top priorities of mind-meld candidates, who would they be?

Who you need to “mind-meld” with & how to replicate it remotely

Jan Chong: So I actually did this which is that we had a new VP of Product join at Tally, which is my current company. And I basically flipped the script and did the same thing to him, which I announced his first day. I was like, "I'm going to mind-meld with you."

And he was in New York city at the time and I am San Francisco based. So we did this where I literally put 10 minutes to half an hour Slack times three, I'm sorry, zoom sessions on his calendar every day for, I think the first 20 to 30 work days. And then we maybe dropped it to like twice a week or three times a week.

I use that time to not only just give him context about the company, my opinions on things. But to walk through a lot of decisions. So I would say, "Hey, what do you think about this? Do you... what is your standard for UI /UX? Is this their top priority concern? When you look at these three problems, how do you think about them? How would you approach them?"

And then I would kind of share what I thought kind of get a little bit more into what you do during the mind meld. But again, my goal was to get us to the point as quickly as possible that we'd feel comfortable speaking for each other in meetings. And then I think it worked really well because especially for product Engineering, where it is a cross-functional multi-stakeholder world that's really complicated. The more aligned you are, the better that whole operation goes.

And it actually makes it more efficient you know, when a new decision comes up, you can usually say " Oh yeah, I think we're going to go this way. This is how we're going to address it."

And then I'll tell her like, what's happening rather than always having to be like, "Okay, we're going to talk about it. We'll get back to you..." That just creates a little more friction in the system.

Jan Chong: So I have mind melded remotely. I actually liked it a little better, cause I find it really intense to have someone like physically next to me...! Part of it can be my PM partner Sriram, who I love is actually a really tall, a very tall, imposing human and I am not a very tall, imposing human. I am a very short unimposing female, so it was a little bit like, okay.

So I maybe liked it a little better over zoom in that space.

Patrick Gallagher: And then in the mind-meld have you found a specific agenda cause you mentioned a couple of things that you want to make sure that the context that you share and how you make decisions. Are there other elements that you would add to the agenda and is there a certain sequence, like you want to share this information first and then this information in day 20 or 30?

How to align & “mind-meld” with your peer leaders

Jan Chong: I generally start with context so that we're working on the same page. I'll be like, here's "What I'm worried about. Here's why. Here are the core fundamentals of how these pieces of the organization work."

And at our leadership level, there's both the internals that are a little bit easier because we both have visibility onto those pieces. And so then it becomes more about the stakeholders. So I'll be like, "Hey, this person's been really skeptical about these programs. And I think, we're going to have to do a bunch of work to win them over. Here's the context for why I think that and what their concerns are and where they're coming from..."

And I don't kind of impose that. I'm just like, here's what I see. And then it's like, why don't you go out? And you're going to talk to these people and you're new to this company. And so you're going to have your own impressions around this space. And then come back and let's talk about where do you disagree? Where am I wrong? Like where do you have different data for me so that we can kind of get onto the same page and let's talk about why, and then where that comes from.

That was kind of the first order of business. And then it came into like, okay now that you've heard a little bit about state of the world, it's usually there's something tactical that is already kind of occupying your execution.

So it becomes... "Well ok, can we pick that up? And then now that that's under your belt, what do you see as the next 60, 90 days? What is the first big problem or change that we think we might want to make here? Do you have enough data to make it? Do you think it's a big enough problem to kind of stir the pot right now? What are you willing to give up to make that change? Let's get on the same page about that. Do we think we have the right skillsets and talent in place in order to achieve what we want to do?"

That's kind of roughly, I would say the topics with a healthy sprinkling of just general inform each other... Sriram used to do a thing where he would just throw new products at me. Then he'd be like, you should do a product breakdown. "What do you think of how Snap is like doing this feature?"

Which was really fun. It was challenging me in a way that I hadn't been challenged before. And then it helped me definitely improve my product thinking and skillset on that front. And it kind of helps you align on kind of the more ineffable pieces I want to say, about, judgment and standards about how you evaluate products and user experiences.

Jerry Li: In that process at what point do you go a little bit deeper to talk about now beyond just the tactics or information, do you ever want to go a level deeper to talk about the underlying beliefs or values or work style so that people can get more synced up deeper down?

Jan Chong: Definitely. I mean, I think the underlying belief conversation, you both have early and then late, It's pretty superficial early on. You usually ask some form of it and part of the interview if you have the ability to interview someone and that's really helpful. And then later is like, when you really mean it and understand what those core beliefs mean.

Like one thing that Anthony, my VP of Product that I'm working with now, at Tally, we sat down and we were like, "What do we think are the product principles for the organization? And really they're product principles, not just for product management for, for how we think about product development and do product development?"

Which is cross-functional there. And that was like a pretty meaningful conversation to try to capture so that we could share it, not just with ourselves, but with the whole company.

The work style one is interesting.... You know, there's been a trend where people like to write the like, "Read Me", like, here's how, you know, I like to work.

I, when I first I've never done one, I thought about it. I thought it was really interesting. When I first read it, I was like, "Oh, that's really cute idea." And then I kind of shopped it around to some peers and friends internally, and they were like, horrified. They were like, "This is the worst idea ever. Why would you do that? This is garbage."

And I couldn't put my finger on it, but then I realized. I think what seems to sound like a cute analogy of how to use a software program is a little dehumanizing when you apply that to people like "You're a user, I'm like a program and you need to figure out how to like, operate."

But my fundamental discomfort with that I realized eventually was, know, if you're going to write one of those, you should be very self-aware in order to make sure it's accurate because otherwise, if you write something and it's not true... and this is an area we're particularly guilty, we often put things down what we wish were true about ourselves. There's not often true, then you're actually just leading your reports or your peers into a very unpleasant learning trap.

I'm actually curious what you guys think about. There's a, user manuals.

Patrick Gallagher: Well, I think that was some straight truth, Jan. That oftentimes we put down the aspirational qualities that we want to embody or how we wish we operated. But when in fact it's not the reality.

And so I think definitely align with you have to sort of either have the awareness or the honesty. Like the personal honesty to address certain things.

So I've never done like a personal operating manual or Read Me, but I have done a lot of like really explicit defining of my personal values and how to operationalize those into everyday tactics. And so that's something that I've, I've shared with Jerry.

Jan Chong: I think it might be helpful more as a conversation between you and a peer or you and a boss. I think it's probably a good basis for that. And where you can get to the real truth through that.

But I'm a little skeptical about what people put, unless ... I think it's probably most effective. If you have some kind of quirk that you just know that that's kind of like how you have to deal with, and you just want to save some time and put it out there. And have some recommended options to, to work with that.

Jerry Li: There are a lot of people actually is aware of that notion . And they're curious to learn more about how that works because on one side, can be really helpful, but also have the fears.

We probably just need to have an episode dedicated to that.

Jan Chong: Probably should get someone who uses it really well.

Patrick Gallagher: It's like the old project management phrase, "the best project management tool is the one you use." And so, it may be one of those situations.

So Jan we've, we've talked about, you know, managing up is about actively thinking about your work and performance through someone else's eyes and adjusting your work to fit that. And we've talked a little bit about the directionality. So up, down, and with your peers.

I was wondering if we could transition to a little bit to walk through some of the different scenarios or ways that this has been expressed across different company sizes or seniority levels.

For you having, experienced a really vibrant and wide variety of these different sort of dimensions, what have been some of the, the examples that you've seen, managing up the different dynamics or examples of that in startups or how those changed between startups and established companies?

Managing up at different levels of seniority

Jan Chong: Yeah, well, I think there's two dimensions there. One as your manager and you rise up in the management chain your manager usually has way less visibility of your work. Often way less understanding of it as well. Although in Engineering we usually have the luxury of reporting into other engineers for a really long time.

But you know, your CEO, you certainly don't expect the CEO of a company to have worked in every single function that he or she supervises. Right? So by definition, a very large number of those functions are going to report to someone who's never actually worked that job by themselves. And CEOs are usually quite busy dealing with much larger fires. And so they don't have the time to take a look at what you're doing day to day.

I don't know if I already mentioned this today, but I at Twitter worked for a boss who was promoted to Vice President of all of Engineering. He had both been my boss and been a peer, and we'd worked really closely together for several years. So I knew he knew my work well. We had a really good working relationship. We collaborated really well. But when he became VP of Engineering for all of Twitter, I became a really small slice of his world.

And it definitely changed in that management relationship. Before he knew so much context automatically because it was both our day-to-day and we could talk about problems on a much deeper level. And when things went wrong, which is usually where all these things come into play, right? He would sort of already know, I didn't have to do a lot of work to explain to him why I did what I did. And what was going on, what was my thinking? Cause it was self-evident.

But once he became head of all Engineering, a lot of it was like, "Are people quitting your org? Or people complaining about you or praising the work that's being done in your org? And are you hitting the company metrics that we need you to hit?"

Outside of that, he didn't have a ton of time to do that. So every time something went sideways, you had to spend a lot more time being like, "Okay, here's what's happening. Here's why..."

So that changed dramatically. And I think that's a huge thing that is very different as you go up the ladder. Your success criteria becomes much less defined, much more malleable, right. And people just don't have the time to come meet you where you are. That's a little bit what I'm saying. Like, "Hey, meet your manager halfway."

Actually, it's more like meet your manager 95% of the way. Cause they just don't have time to kind of come there.

Inside at a start-up though, it's kind of a different world where a lot of that stuff is a little more evident. A lot of that stuff is a little bit more transparent. Right? Because everyone can see, everyone has usually a lot of preexisting relationships because they've built the company from the ground up. They've hired people from the ground up. They have a lot more information on the ground, connections to people on the ground.

And you have a lot more time to talk through kind of what's going on with changing there. But often then the flip side is you have a lot of people who are not experts in their area coming in. A lot of times you're doing stuff for the first time.

I mean, that's the fun of a startup is you get to come in and like... I remember at OnLive they were doing a Windows client, And this was, I think my third week. And they were like, "Who knows anything about windows programming?"

And there was silence. And then my boss was like "Jan did an internship at Microsoft like once!"

I was surprised, like "You're the expert, go write the windows line."

Patrick Gallagher: That's a classic startup thing. You've done one thing, you know, one time and you're the resident expert at the startup.

Jan Chong: Yeah, and it's great! That's what's the fun of a startup in my opinion! But the flip side is that means you're dealing with a lot of people who aren't experts in that space and you have to do a lot of translation and bridging and explaining "Hey, this is the context for why we're doing this."

Yeah, I think that's one of the big pieces.

And that's also a part of when you go from being a head of function versus reporting into like Engineering. I think we forget, I've been running client engineering for a long time. I reported into a manager who came from a web background and there's a lot of friction there between understanding okay, Android is really different from iOS and it's really different from web when you're thinking about how to judge things.

Like an example is we were looking at crash rates. And he was like, "Oh, they should just be 99% crash free."

And you're like, "That is just not probably a goal we really want on early Android. This is back when we were like eclaire, donut, cupcake land. And you're like, "The long tail of crashes is really high. I think you'd probably rather have them working on new features..."

Right? And there's the kind of, that example of that natural misalignment that happens. But that actually pales in comparison to when you go from reporting to someone who isn't technical at all, who's never been an engineer and doesn't understand very basic things like, Oh, when you say you need to address tech debt, they're like, " What's tech debt. Why do you need more people to add no new functionality to the system?"

Right. That's what tech debt reads like when you're not in technical like, "Oh, I need to pay a lot of engineers, a lot of money and spend months working on something"

And they're like, "well, what do we get out of it?"

And you're like... "well, in theory, next time we do it, it'll be faster!"

They're like... "uh, huh...?" So you have to do way more bridging.

You know, my peers right now are the head of finance, the head of legal, the head of marketing, the head of HR, right? That's like a totally different set Than when I was in Engineering where my peers were other engineers or engineering adjacent functions, who had spent their whole careers working closely with Engineering and had a good understanding of the process.

And it's a little similar to how, from my perspective, I understand finance, which is not at all... right? It gets really complicated. There's lots of numbers. There's tax involved. It's huge. And it's I don't really need to know, but when something goes sideways, they have to kind of explain the broad strokes of why we did what we did and its kind of alien.

I think that's a very similar position to Engineering. Which is like, you don't actually need everyone to be an engineer, but you need to explain kind of the basics of " Okay, think of it like a spreadsheet. And if I change one number here that changes everything. We don't know which, you know, sheets are linked in or whatever."

Patrick Gallagher: Relating engineering to finance or what they need to understand in interfacing those different functions is really powerful.

Going back to what you said about the scenario of the manager that you have to meet 95% of the way. So we'll use the context of now you're primarily interfacing with the CEO and you need to meet them 95% of the way to be effective...

For somebody who is now managing up to that relationship, what does that manager need to know to be effectively managed up? Or what do you need to properly prepare for those meetings so to give them the information that they need.

What you need to do to “manage up” effectively

Jan Chong: In general, like the biggest differentiation there is that they just don't have time. So you need to have thought a lot about how to present to them. How to keep it snappy and get to the point.

You know, when people talk about executive communication, that's really why. Right? How do you lead with the ask? You don't want to waste anyone's time and then you give them enough background information and context that they can hopefully look off async to feel good about that decision.

But at heart you're really asking them just to Greenlight what you wanted or to like waive a requirement that you previously thought was really important.

So framing it to how they think about things becomes super important. And doing it in a time efficient way. And that can really mean stretching your calendar time. But it can sometimes be really rough to live that.

An example at Twitter, I once received some DMs at four in the morning and I was like, "What is happening? Why am I getting bug reports at four in the morning, or questions about the build?"

And I looked and it turned out the exec team was at Cannes Lions. And I think they had forgotten that I was not in Cannes Lions. And they were asking all these these questions cause they're in front of our big ad partners, right? So this is actually really quite important. They're trying to do major deals that are going to guarantee us revenue for the year and something's broken.

And so, in that time, you're like... you can quibble about whether it's fair or like good work life balance to get DMs at four in the morning. But when your boss in on the exec team, you're like, just answer the DM. Like just go open up the laptop and dig around and get the question answered.

Patrick Gallagher: Yeah. Sometimes the stakes between, you know, year long revenue and existence of the company and a 4:00 AM wake up call like, you know, the equation gets outweighed.

Jan Chong: The equation shifts a lot. Yeah!

And I think the other piece is we're all naturally I think in my opinion, either quant or qual, like intuition or data-driven. I mean we're also actually a blend of both, but I think most people instinctively trust their intuition. Or trust kind of a more rational analysis in order to make a decision.

And when you're an executive, because you have to make so many decisions of high impact with very little time, you sort of regress to your instinct. Whatever your natural inclination is.

That's really important!

If you're a human that makes data-driven decisions and you're reporting to a manager that is more intuition based, you need to learn how to report progress to an intuition based manager. It doesn't matter how many tables and OKR scores you present in front of them, they're going to look at that and kind of nod. And they're just going to evaluate your project success based on what customers or partners say or complain about in general or their own impression of the product as they use it.

And then vice versa: if you are someone who generally has a really strong intuition and feels that way, and you're reporting into someone that cares a lot about the OKRs or the KPIs, right? Guess what? Start getting really good in with your data science team or your Excel or whatever dashboard it is that generates those numbers. Because it's going to define how your success is evaluated.

Patrick Gallagher: And in this case the flippant comment that comes up is "Man... if only everybody could be really brutally honest with what makes them effective and understanding their intuition and had a totally honest and accurate "read-me" manual, then that would be easy.

But I have to imagine that that is the challenge is understanding what their preferences are, what is the base decisions that drive their intuition.

Jan Chong: Yeah. It's almost like the term data-driven almost has very low meaning? I think when people say it now, because who's going to say they're not data driven, right? Who's going to be like, "Oh no, I don't. I just go with my hunch!"

So that actually a shocking amount of people do that. Because they're driven by experience and they have a very good ability to like, process that in like a nonverbal, non-numeric way.

One of the things that one of the teams I worked with at Twitter talked about, was "How do we feed someone's intuition?"

We had an exec that definitely operated that way. So we were like, how can we nourish that? And how can we put the right data and influences in front of him or her so that you know, we start to see them align a little bit with our intuition or with what we want to do more, more tactically.

Unexpected differences of working with non-technical colleagues & Jan’s metaphors to explain engineering

Patrick Gallagher: I really wanted to zoom out a little bit because, you know we're, talking about this matrix of seniority, org maturity, up and down, and directionality from all of those different elements of managing up.

What have been some of the key mistakes that you've seen people make? And are there any unexpected mistakes that people make that they can avoid?

Jan Chong: I think that really big one is just aiming to please, instead of aiming for the right outcome.

And it's a personal pet peeve. I really want people to tell me when I'm wrong. To push back on bad ideas. And because the whole goal is to get to the best solution that incorporates both of what I know and what everyone who's working with me knows.

And if people are gonna just always agree with me, and I've actually had people literally strained to agree with me in a meeting where sometimes I... this is not my best trait... but sometimes I will just change my mind in a meeting to see what happens. And they will like flip flops to try to match that.

And I get really frustrated! Because I'm like, well what's, what's the point, right? Like I need two voices in the room so that they are drawing on different experiences. If you're just going to echo my voice, then... I don't really need your voice in the room, is actually the unfortunate way that I start to think about it.

Because that's actually not the job is to tell me. Yes. The job is to tell me when I'm wrong. And I think the challenge of managing up is doing it in a way that I can hear it. You can replace "I" with like your generic manager in that space.

Patrick Gallagher: Do you recommend people to change their decision, to test the conviction of their team? Is that a tactic that you recommend?

Jan Chong: Uh... that is a tactic I use... I feel it sometimes feels a little cruel when I'm doing it. So I don't know that I recommend it. But it's definitely one that I use.

I think a better one is to set the cultural standard of encouraging everyone to speak up and modeling it yourself and not punishing people when they give you an uncomfortable truth.

Patrick Gallagher: Yeah, definitely. That definitely makes sense. As that was more so, because I could see Jerry's wheels turning a little bit of like, "Maybe I could change my conviction just to test and see if Patrick just trying to please me."

So I'm I see you, Jerry. I see what's going on over there.

Jerry Li: How do you know I'm not already using it?

Patrick Gallagher: I don't, I have no certainty!

Jan as we're, kind of winding down towards the end of this conversation... what I'm thinking about is as people progress through their, leadership career, oftentimes the people that you're interacting with more are oftentimes more of your non-technical colleagues.

And so I was wondering if you could speak to transitioning to where you're working less with engineers or engineering adjacent colleagues and more with the non-technical colleagues.

What's different? What's important? What was unexpected for you? And what are sort of your keys to success here?

Jan Chong: Yeah, one thing that definitely happened that was surprising is how much it, first of all, it's becomes a huge part of your job. Like when you're in that role. So communicating, helping people understand engineering priorities and how engineering works on a very basic level is a very, very large part of what I do.

I don't know that that would be necessarily true across every company, if you have a more technical like founding team or like exec team I think you would have to do less of that. But in my particular case, that's definitely I think, 30% to 60% sometimes of what I spend doing a week is definitely when I first started is kind of representing my function, spreading awareness and understanding of what really matters.

I would say the thing that people kind of go wrong or that I definitely got wrong initially and had to scale back... is as engineers, we want everyone to understand everything. And you're, overexplaining all the really details, because you find them really fascinating and you care. And it turns out that doesn't really matter at all. You just need them to know the core, like the three core kind of truths, if you will, of how engineering works.

Which is like, " No, you it's really hard for us to come up with the date and that's probably going to change. So plus, or minus one week is actually probably really good. Depending on what the thing is."

"Yes, people will need to continually work on stuff, so that doesn't go stale essentially. Right.

I don't know. I can make up the third core truth. I don't have it on hand right now. But it's like, basics like that that are pretty fundamental axioms of the work where a lot of the pieces that I was communicating.

And then also, like it's not their function, how to keep their attention. So I ended up using, a lot of analogies. I think every single all company meeting for a couple of months, I'd be like, "Here's the new you analogy about how to think about tech debt! We built a house on a really corrupted foundation... or like you're renovating an old house in the Sunset District in San Francisco, you opened the wall and like, God knows what's in there!"

Right?!

"You went downstairs and you thought you were just going to like fix the sink and all of the bathrooms upstairs stopped working? Well, that's what it's like when you inherit a system with a lot of technical debt and everyone who wrote it is no longer here."

Patrick Gallagher: Hahaha!

Jan Chong: And I think probably one of my great contributions to Tally culture, our current startup, is that I have brought in a ton of animated gifs into every single presentation to try to kind of keep it lively because when you start the endless parade of "Oh, Jira, Tech Debt, EFTA, you know Kafka! People are like, "Whoa, what...?"

And you're like, "You know what, here's the house falling down. This is a good picture. Let's orient on that.

This is what happens if we don't invest in tech debt, we don't want that.

Here's a house that like is beautiful and it's really easy to remodel. It's made out of Legos. This is what we want."

Jerry Li: There might be a need to build a, like inventory of all those analogies. People can pull out from a back pocket when needed.

Jan Chong: Yeah, well, some of them were pretty bespoke to our technical problems. I mean we literally had a brainstorm, me and the EMs, about maybe like a month in. I remember we were saying one of our challenges. I mean, one of the challenges we had to do is get buy-in to have funding, to address these problems.

And really again, when you look at it from the external perspective of a PM, where I had a PM partner, he used to joke, he's like, "I'm an engineer, I'm just going to spend six weeks re-factoring something and it'll do the exact same thing it did, when I started, but it'll be better somehow."

Right? You're like, that's exactly what you sound like if you haven't explained the more, the deeper fundamentals of what's happening. So how can we kind of explain it?

And so for every one of our top five technical problems, we had an open brainstorm in this Google doc, or like, "What's the analogy?"

Right? Like "Your notifications are bespoke in every single part of taxation notifications different."

And you're like, "Okay, the house has custom windows everywhere. So you have to go to each room and close the window independently. There's no way to just close all the windows at once. And even if you're trying to do that, you have to like customize it to each window cause you have a bay window in this one and a sliding glass door in the back and you have a standard shutter window over there."

Right. So we did a bunch of that to try to convey kind of like the key constraints that we were working with in the system.

Patrick Gallagher: What an incredible team building exercise, but also a way to upgrade effectiveness of communication. I have to imagine that must have been so much fun diving into that with the team.

Jan Chong: I think they thought I was crazy initially. They were like, "do you want me to do what?" And I was like, "Just explain your problems. Then I'm going to like walk through them again so I understand them. And then I'm just going to brainstorm analogies."

At least one of my managers got really into it. He's been really good at them actually. At our one on one, he'd be like, "I thought of another one!

Like, "Oh, I love it! Let's hear it!"

Patrick Gallagher: Jan this has been so much fun. Thank you so much for such incredible stories and for sharing so many great lessons and insights with us. Thank you.

Jan Chong: Thank you, you guys are very kind and you make this very easy. So thank you so much for having me.