Code[ish] logo
Related Podcasts

Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.


  • leadership
  • communication
  • trust
  • career growth

28. Effective Leadership Development

Hosted by Shirley Xiaolin Xu, with guest Trey Ford.

We tend to think of engineering as a field with graduations. You start off as a junior, and as you develop your skills, knowledge, and understanding of technical systems, work your way up to a senior, then climb to the top as a principal. Leadership is not very different. An individual headed down the career path of a leadership might be an inspiration to their colleagues, then they might manage a team, and then eventually lead a department in an organization. Trey Ford is a Vice President of Product Management in Heroku, and while moving from an IC to a manager to a leader, he's spent a lot of time thinking about what makes a leader effective. He joins Shirley Xiaolin Xu to talk about what he's learned during his career to make teams and individuals happier, confident, and more productive.

Show notes

Trey starts the conversation with Shirley by noting the difference between being a manager and being a leader. Managers are a framework for discussing pay, onboarding and offboarding, HR interactions, and so forth. Leadership is about inspiring others to unite together to work behind a purpose. Any IC, for example, can be a leader for just a handful of his teammates. Being a good leader means knowing what's important, conveying that to someone else, and executing on it.

To do that, Trey emphasizes that a foundation of psychological safety is essential. Allowing people to speak up when they disagree with an issue, or admitting your faults when you've made a mistake, is an incredible method of breaking down barriers between people and fostering a culture of truth. Fostering individual growth is also a good strategy, as people generally want to continue improving, whether it's learning a new programming language or a new technical system they're curious about. Removing obstacles to people achieving their goals is key as a leader.

Shirley notes that the role of a leader requires an immense amount of mental and emotional energy, as your concerns are not just your own, but also those of the people who rely on you. Trey responds by emphasizing health as an important priority that's often neglected. Individuals will take better care of their pets than themselves. By demonstrating that he is not infallible, by taking vacations, encouraging exercise, or ensuring enough hours of sleep, his team in response understands that taking breaks is a good decision, not a dangerous one.

Finally, communication is always necessary. If there are too many distractions that prevent you from accomplishing an objective, you should tell your team you'll need some quiet time, rather than silently disappear. If you're concerned about a path a company is embarking on, you should tell a leader you feel comfortable talking with. Communication breeds trust, and that's the foundation of any successful relationship.

Trey recommends several books on effective leadership:


Shirley: Hi, my name is Shirley. I am an engineer on the web services team at Heroku and today I am joined by Trey Ford. Trey, would you like to introduce yourself?

Trey: Hi, my name's Trey Ford. I'm vice president in product management and responsible for platform trust.

Shirley: And today, Trey and I are going to talk about leadership development. So Trey, what is leadership development?

Trey: What is leadership development? Well, we should probably talk about first what leadership is. Leadership is often confused with management. Thinking about management, individual contributors versus management, very different career paths. So understanding subject matter expertise, becoming a craftsperson and an expert in a field of expertise, whether that's development or architecture or networking or anything else, management is about leading teams. Management's ultimately, in my mind, a framework and a structure, I assure you it's harder than it sounds, and moving towards leading non-deterministic systems. Humans don't always respond the way that we expect they will. Management's often full of failure.

Trey: So thinking about that in contrast to leadership. Leadership, I think it's the apex of what management should be all about. In a one-on-one level, it's about coaching; and at the team level, it's about harmonizing key character qualities in the team and harmonizing their focus and their attitudes around what needs to be done, the why matters.

Shirley: So you're saying the difference between leadership and management is that management is about harmonizing the strengths of the team.

Trey: Management is specifically managing people. Managing people is actually the structure of making sure we're all on task, making sure work's getting done, handling the HR paperwork, onboarding/offboarding, helping with the pay, the review, the HR load that goes with that. Leadership is more about the hearts and the minds, actually inspiring and driving towards something I think we all care about on a higher level.

Shirley: So what got you interested in leadership and management as a subject?

Trey: Frankly, I think, starting off as a manager, I was horrible and I probably still am, but I think it was getting a passion around helping my people achieve their full potential. I had the opportunity to work some absolutely phenomenal people and realizing that, with a little bit of coaching, a little bit of support and investment, we could help them achieve the peak of their capability. And the sum of the parts was much greater. I'd hate to draw platitudes like 1+1=3 but, in all seriousness, helping bring the very best out of everyone and helping everyone play to strengths and creating safety for them to know that perfect success and perfect execution isn't always required and that taking some audacious bets allows us to do absolutely phenomenal things. It's really neat to see people outperform their own expectations.

Shirley: Were you an IC before you became a manager?

Trey: Yeah. I imagine any good manager or leader was.

Shirley: Were these things that you learned along the way by being a manager or did you do a lot of research and studying while you were an IC?

Trey: I think I always had a desire to do this. I think, again, separating out leadership from management, as an IC, you can still be a leader. So in any IC or individual contributor grouping, there's still going to be your principals and your leads, the folks that are able to mentor and coach, and I always had a desire to do that. I think what captured my interest was seeing it done really well, people that I really looked up to, people that had the ability to lead groups of low-performing teams to outperform the teams you're expected to lead, to win competitions or to outperform in whatever metric mattered and then move-

Shirley: Like an underdog story.

Trey: Yeah. I mean, like legitimately, leadership and the establishment of the character qualities and the focus and the personal accountability and the accountability to each other, you can set a tone that absolutely changes the aspects of how the entire team operates. Everyone outperforms if they're well-led, well-coached, well-supported and cared for.

Shirley: So did you come to us today with some advice and guidance on how to make that happen?

Trey: So first thing I think's interesting is the notion of psychological safety, and I think that's a tone ultimately set by leadership, the importance of the team knowing what is important and knowing that if we execute on that, everything else is ultimately going to work itself out. I think that the ability to say, "I'm not sure. I don't understand," even the safety to ask or push back or say, "I don't know if I can do this," that ultimately falls with the leader of the group. And if the leadership or management doesn't create that atmosphere, you've got a dangerous place to be working in. We've all, I think, operated, at some point in our lives, in a place where we were afraid to say, "I'm not comfortable," or, "I don't think I can do that," or, "I think that deadline's too early." I think creating that space is really, really important.

Shirley: Yeah. Psychological safety is a concept that I heard a lot actually here at Heroku pop up and this is the first organization that I've worked in actually, that has had such an explicit focus on it. But it's something that I find really interesting too, is that how do you create psychological safety for such a diverse group of people?

Trey: Especially a remote workforce like what we have here at Heroku. I think there's a couple different pieces. First is... Well, I think on my second day of work, I got to sit through something we refer to as faultless retrospectives. So Heroku's real big on retrospectives on projects and incidents. So when there is a platform incident or when there's an unexpected failure, even on projects that we thought were successful, there's always opportunity to improve.

Trey: But seeing our general manager of the business unit for Heroku step forward and open the call with his failures and his missteps, the assumptions that he made, without apology, without making excuses, "Legitimately, this is what I did. This fed in. This is where I believe I set other people up for failure. And this is what I think I can do to improve." And we all were able to discuss that objectively and talk about how to grow creates a tone and I think it starts at the very top. And I think it takes a commitment of everyone present to foster that and protect that. That's a very fragile thing.

Shirley: Okay. So the takeaway is the approach that you've seen is for the leader and the person in the highest position of power to be the first to show vulnerability.

Trey: I think it's best when it starts at the top. I think that leadership structures can create it even if it's not there at the very top. That feeds into other leadership concepts like success belongs to the team. Failure actually falls to the leadership, leading from the back and stepping forward to own the blame.

Trey: One of the books that one of my employees pushed me to read was Extreme Ownership, Jocko Willink and Leif Babin. Interesting read, very military-focused, a lot of testosterone in that book. But one of the fascinating things about that read was the notion that it starts and ends with the leader. The leader's ultimately responsible.

Trey: What's neat about that is, for instance, I think anyone working in the public cloud, we've all done something, whether it's old-school data centers where you accidentally killed a network rule on the firewall, or you accidentally set a setting that killed a service or knocked something offline off the internet. We've all done it. We've created an atmosphere or technology that allows one single person to not be human. Human error is natural. It's part of our creation. It's our part of our existence. And there's a scenario where one person, with no check, no balance, no protection, no safety net, can make a mistake with massive impact.

Trey: And so the ability for leadership in the organization to say, "Hey, we don't want those single points of failure. We don't want those single points of collision. No single human should be tasked with that," creates an atmosphere of saying, "Hey, how do we do this together?" If you're going to go big, you go together.

Shirley: So how would you hold someone accountable for their mistakes and to make sure that they're working out the rest without making them at fault for their mistakes or singling them out?

Trey: Right. Well, accountability is important. So if we're making the same mistake day every day, week after week, continually, that's not growth. A commitment to excellence, a commitment to growth, that growth mentality, requires that we take next steps. So part of the retrospective process is identifying how we're going to prevent this from happening and assigning ownership and figuring out how we're going to work as a team, as individuals, as an organization, to close those gaps, to engineer around that.

Trey: So more than allowing a continuous failure in the same way, failure does happen, mistakes happen, but I don't think that failure's actually the right word. Technology, we talk about failures, I think it's a very loaded word, but failure doesn't always have to be final. If we're talking about a process and maintain that growth mentality, we're committed to that, the notion that we can fail forward, we can identify something that didn't work out, something that's gone wrong, and work to close that gap. If we have someone that has no interest in improving or growing or trying not to make those mistakes or looking to solve those problems, that's a very different management problem that has to be managed out. That has to be addressed.

Shirley: Yeah. What you're saying resonates with me because I've held leadership roles before, where the reason why I volunteered for it was because I wanted all the glory. And then I was voted in and I realized I got none of the glory but anytime anyone screwed up, it was all on my head.

Trey: Glory's a challenging thing, and there's got to be space for people to be human, but if you're in it for your glory, I think that's... If I could steal from Ben Bergeron, he talks about levels of coaching, you're coaching from a position of title. You're wearing the coach T-shirt and so "you should listen to me because of my title."

Trey: And if you're moving towards the more mature end of what that leadership function really looks like, that coaching relationship looks like, you're doing this because you want to see that person achieve their real potential, maximize what they have available and help them exceed their own expectations. You're doing that not to compare yourself, not to raise yourself. It's all about the person you're investing in..

Shirley: Yeah, yeah. That resonates with me as well. Because from that experience, I learned that me, at the time, was not a good leader.

Trey: We're all on a path. We're all growing.

Shirley: Circling back to what we were talking about, how do you avoid that single point of failure then in a team?

Trey: Oh wow. Single points of failure are hard. So there's the hero focus. A lot of times, you'll have an individual that steps forward and answers every Slack ping in the channel, they answer every page, they respond to every distribution list email. And it's great to have zeal and hunger but there's a number of other pieces. One, humans need to sleep. It's the most important thing for knowledge workers. Sleep deprivation's actually more dangerous than drunk-driving at a certain point. Imagine writing code that could blow up. I mean, that's a problem.

Trey: I think one of the old axioms we had for Heroku engineering leadership was if you're going to go fast, go alone. So think about a proof of concept or a spike. If you're going to go big, you go together. And so when we talk about addressing single points of failure, when we start thinking about addressing individuals or scenarios where you've got that, again, single point of failure, you've got to think about how the team balances. Don't email me, email my team. Those sorts of patterns.

Shirley: So how, as a leader, do you enable everyone on your team to be better, to not have that hero complex, to work better as a team while not letting themselves fall into the background and not falling behind?

Trey: I think there's a couple of pieces. I'm going to steal again from Jocko and, if possible, I'll throw in some links into the podcast notes to some of the books I'm referencing. Management, leadership: One's transactional, one's really about driving a vision. And so from a leadership standpoint, Jocko talks about owning commander's intent, giving the team a massive why to rally behind, what are we actually trying to achieve? And so when we think about that, part of that means enabling decentralized command or allowing people that aren't the leader or the manager at the top of that grouping to be the one making the decisions. You want to decentralize decision-making. So if everyone in the team, in the organizational unit, understands what we're trying to achieve and how and why, you're enabling the people closest to the technology, closest to the problems, closest to the situation, to make informed decisions because they're aligned with what the whole team's working towards. And that's a really great thing.

Trey: One easy example for this in day-to-day application. So I had I think four or five key groups when I was running Heroku security and we had team leads meetings, where my leadership team would meet, but when we had the full team meeting, my leads, the managers of each of those teams, didn't actually represent their teams. They had one of the ICs represent that team. So when the platform security team was presenting, it wasn't Wade delivering the update. It was one of the team members representing, at a leadership level, the rest of the team.

Trey: What's great was if someone's sick, offline, has something to deal with, life happens, you have a group of folks that are capable of speaking to one, the overarching reason why; two, the status; and allows cohesiveness across the team. So, again, it's not about leaving anyone behind. Our job as leaders is to do only what we could do and create space for everyone to grow.

Shirley: I do have a question about giving ICs and people on the team more autonomy. How do you handle a situation when someone may not agree with the fundamental vision?

Trey: So agreement is hard and I think clarity's expensive. So let's start with clarity first.

Shirley: Hold on. Yeah.

Trey: So getting a clean understanding, like you remember the old game of telephone where you're passing an idea from person to person to person?

Shirley: Mm-hmm (affirmative).

Trey: When you're working on confirming commander's intent, so when product and engineering and design and management leadership for Heroku is talking about a strategy or a decision, making sure that we have the correct understanding and we're propagating this down through the levels of engineering, of management, of product and design, these things take time. Getting that clear, making sure you've read back correctly what we're trying to achieve, that's expensive. That takes time and it's an investment. And there are really high costs with getting it wrong so that takes time. So then getting alignment with it, that's difficult.

Shirley: So do you try to find alignment and agreement before that expensive process occurs?

Trey: At the highest levels, sometimes a management decision has to be made. So Jason used to use something called voices, votes and vetoes. So everyone gets a voice. When we're making a decision or we're voting on an epic, everyone has a voice. Sometimes, everyone gets a vote. That may be a management thing. That may be all the way up at the executive tier. There's going to be a discussion. Sometimes, due to lack of time constraint, we may not be able to gather enough data, sometimes a decision has to be made. The veto is actually the person that's going to make the decision and we're just going to have to figure it out. You make the best decision you possibly can as a group and it falls to that person anyway. Remember, if the team fails, who owns it?

Shirley: The leader.

Trey: In this concept, it's the leader. And so that happens at every organizational group, all the way up to senior leadership. And so ultimately, if Marc Benioff decides tomorrow we're doing, I don't know, something, he's not going to call me, he's not gonna call you. He makes a call and the whole company rallies behind him because he's our leader and we're going to make that decision. We're going to figure out like, "Okay, this is complicated. We're going to make some hard decisions but here's the timeline that's set ahead of us. Let's figure it out. Let's go do it. We understand the commander's intent. Let's go to work on it." So voices, votes and veto.

Trey: Sometimes there's a time for discussion, sometimes there's enough time for a merited decision but then there's disagree and commit. You and I may not agree but someone gave us a direction. Well, we'll log what we thought was useful. And it's not about keeping score, it's, "We've all been heard but now we're going to go to work on this. We're going to go down that path." It may be a dead end. It may be the right solution in the end. But we make the best decision we can with the information available at the time.

Shirley: Have you ever encountered situations where you've had to have that difficult conversation and get someone to see the bigger picture?

Trey: Oh, absolutely. And earlier in my career, as the hardheaded guy that had a real hard time dealing with that. And we're all on a path, we're all on a journey and, at a certain point, it sinks in and connects. And some decisions are more emotional, a lot harder to stomach. And some decisions are literally not a factor. It's, "Okay, I don't think that's the best way but you're calling the shots. Let's make it happen. Let's go to work." And we do the thing.

Shirley: So what if we do a demo? Okay, Trey, I am the lead for Project X and I strongly disagree with what management has decided. And based on my experience, I don't think that this is the right decision and it's not what I personally want to do for my career.

Trey: Okay. So there's two sides of this. And let's assume that this is a one-on-one discussion that you've come directly to me, outside of the team working on this.

Shirley: Okay. After this, can we also do a scenario of a team discussion?

Trey: Sure, sure, absolutely. In the best possible case, positive feedback happens in a larger group. As a leader, you don't want to dress someone down in front of a group if you can help it. But if there's contextual things you want to go deep on, sometimes spending everyone's time to go deep on it may not be the best investment but we'll circle back to that.

Trey: So one-on-one, if I'm talking to you directly, my initial thought, Shirley, would be this: "Is this a personal thing that you are personally against or is this organizationally dangerous and you're aware of some impact to the company that maybe we haven't seen and we need to make sure that leadership's aware of before we confirm and lock and execute on this vision?"

Trey: It's important that the subject matter's... again, when I talk about decentralized command, the idea that you, at the edge, have the best picture of the situation, of the technology, of the market environment, of any of these variables. If you've got information that's material to the business that maybe we didn't see, my job's to champion that and run it up the flagpole. Now, I may get a black eye for it. It may legitimately like, "Hey, we don't have time for this discussion. We're on an insane deadline. I've made my bed. We got to go do this." I'll come back, we'll discuss it and we're going to go to work.

Trey: If there's time for that discussion... One of the hardest parts of leadership is knowing on a timeline does a decision have to be made now or do we have time to do some level of analysis? And sometimes there's not enough time. And so, as a business, we have to make a very large bet where we're throwing X number of resources at a project on a timeline and we're going to get it done.

Shirley: So it sounds like, in that situation, a good leader would kind of step back and see the big picture and see what the timeline of how everything's happening and whether or not there is space for discussion and then try to separate the personal issues from what's important and whether or not this individual has information that would actually impact a project.

Trey: Yeah, always. I think it's unbelievably important. You want to listen to your experts. You want to support the people. We're talking about humans. Again, this is non-deterministic engineering. This isn't something I give a computer and the computer gave me what I expected back. You've got better perspective. You're closer to a problem. We need to make sure that we've seen everything.

Shirley: Wait a second. Engineers are human? I thought they just put a chip in our body when we get hired. Okay, okay. So how would you navigate that difficult conversation when it's in a group? Would you also candidly ask them if they have more information or whether it's personal?

Trey: That's a hard one to call. Depends on the group and it depends on the individual. You don't want to eviscerate and skewer someone and put them on the spot. They may or may not, depending on their personality, their profile, their comfort, the health of their relationship with the team, respond well to that. They may feel that you're personally assaulting them, questioning their intelligence or their integrity or their rational thinking. And it's been my privilege to serve a lot of amazing engineers, that's one of my favorite parts about Heroku, and working with these engineers, a lot of us are on the autistic spectrum and so that's not going to bode well for how someone fields a response. It's not going to bring their very best out.

Trey: It may very well be that you've got a high level of trust in the team, a very cohesive team, a lot of psychological safety, where you're able to say, "Hey, tell me what I'm missing. There's probably more in this group that haven't spoken up. What am I missing? Understand this is time-constrained but there's something dangerous, if this is something personal, we need to go one-on-one, say the word. But if I'm missing it, I need to make sure I bring this back up to leadership. What do you got?" I hope that I'd have the presence of mind to sound that rational at the time but these things are hard when things are real.

Shirley: Yeah, yeah. I didn't mean to put you on the spot with a live-action demo.

Trey: That's exactly how it is in real life though.

Shirley: So how, as a leader and a manager, do you keep yourself together? You have to devote so much mental, emotional energy into pulling others up and connecting all different layers of the organization. Do you have any advice?

Trey: I would compare this a lot to the notion of constraints. Everyone, everyone listening to this podcast, everyone I work with at Heroku, everyone at Salesforce, I think most of the customers I've interacted, deal with constraints, whether they're artificial or real. We all have more work than we're able to get done and I think we need to be reminded that constraints are a good thing. They force us to prioritize, determine what's most valuable, what's the most important thing I can do today and how do we maintain priority?

Trey: So taking a step back on how you deal with this, one of the most important things in the Heroku V2MOM is Ohana. One of the most important things in my team, when I ran security for Heroku, was actually team health and wellness. And as silly as this sounds, the type of folks that we've interact with, as Heroku customers, I can tell you Heroku engineering at large operates with a very high level of drive.

Trey: You don't ask them to show up for work. They love what they do. They believe in what they do and we know that it matters. I believe personally that creating a platform that's not only the fastest way to go from idea to URL, but is the safest way to do it, is huge to me, massively important to me as a security professional. But, with that in mind, I've got folks in my org, or did, I don't lead that team anymore, that would work 20 or 40 hours in a day if they could squeeze it in. And we had a number of folks that pushed themselves to a point where, despite our best inputs, literally had to take some time off to get well. And burnout's a real thing. We all talk about it.

Shirley: Really?

Trey: Oh yeah. Well, in the security world, we work with incidents and of course we have VSR and the production engineering philosophy here. So with total ownership and how we've applied that, we have this idea of total ownership on platform incidence. So you have a group of teams that are showing up that are working a problem and, in the best case, you've got a well-staffed team that's able to work around the clock and hand off after a number of hours on IC. And that's a great thing. But when you're running an incident, and the security teams are usually pretty small, we tend to work some really long days.

Shirley: And incidents don't wait.

Trey: Incidents don't wait and neither does sleep. At a certain point, you're doing more damage than value. So, for me, I started with prioritizing health and team collaboration. I wanted physical health to be important for the initial contributors in my organization. That makes us better teammates, better friends, better coworkers, better family members, but ultimately it improves your work product. And, as silly as this sounds, if you're prioritizing some sort of physical activity, and I don't want to go tech bro because I don't think that's the right attitude, but the notion of doing something that's good for you, I don't care if it's yoga or meditation or CrossFit or anything else, you've got to be deliberate about investing in your wellness. Doing that's going to force you to eat a little better. We all know how to take care of ourselves. You eat better, you rest a little more, drink a little more water, maybe a little less alcohol.

Shirley: Hey, hey, hey.

Trey: The process is pretty clear. Right, right. But doing this allows us to bring our best, best to the team. It allows us to be in a less stressed state, allows us to respond and take things that are off-balance or, we're human, sometimes people say things and it comes out wrong. And so it allows a little more grace, a little more space to receive and process what happened and realize there's a human at the other end of that email or that Slack message or that page, and they're simply looking for guidance or wanting to do the right thing.

Trey: I haven't worked with anybody here at Heroku that has legitimately gone out of their way to create pain for other teams. Most businesses don't run that way. And so remembering that we are working with humans and we are investing in these relationships and we are trying to find a path.

Trey: To answer your question directly, starting off with taking care of yourself and pushing your team to do that allows them to bring a better version of themselves. If you're making time to rest and you're making time to train, you're making time for your family and your personal relationships and spiritual investments or anything else you're doing for you, you're bringing a whole person to work.

Trey: That also creates the space to say, "Here's my priorities." Salesforce uses the V2MOM strategy. Heroku's aggressive about trying to maintain clean priorities, report back on that. That's how our town halls work. That's how all of our engineering planning rolls up. We try to be clear in our priority and understand the work we're investing in, how does it map back to the team? And so that allows us to make those tradeoffs and creates, again, the psychological safety to say, "Hey, I would love to do that. I'm actually really interested in that. But in the current priority stack and what my team's depending on me and the external dependencies across the teams, I can't take that on right now." And it creates space for that.

Shirley: But how do you, especially on a remote team, you know, sometimes I might see that my teammates are tired or it seems like there's something off about them but I would feel awkward to ask. And how do you not be intrusive but still monitor everyone's health?

Trey: So that's a sensitive one and every organization has its own HR posture on this. I think of this in two ways. First, I think it's important to address unhealthy patterns and to speak openly about it and I think that's a cultural thing. And there are cultures around the world and HR systems that maybe that's not a great idea.

Trey: What I instituted with my crew that I've personally found really great value from was this. So we use something called Standup Bot or something like that. It was a bot that we had in Slack that would pop up and ask us a series of questions.

Shirley: Oh, Geekbot.

Trey: "What are you working on today?" Geekbot! There it is. So "what'd you do yesterday? What are you doing today? Do you have any blockers?" And in leadership, blockers are our primary responsibility. If something comes up, our job is to block, tackle, create space or deal with the problems. Most important thing you can do for your management is make sure they never get surprised so blockers early and often is a great thing for us to be aware of.

Trey: But we instituted one more separate Geekbot question sequence that asked "what have you done today or what have you done this week for personal wellness?" And there are folks that would blow it off and there would be people that would report back in specific ways that would raise your eyebrows. And so I would meet with my leads directly, be like, "Hey, I saw that so-and-so was having this pattern or this issue," or, "this person, we talked in their last one-on-one. They were going to invest in this aspect of their personal health and I haven't seen anything about this. Can you check in on this?"

Trey: And what's fascinating about this is a deeply-rooted human trait. People will treat their pets better than they will treat themselves. People will spend an amazing amount of money for the care and support of and the medications for their animals but they won't do it for themselves. They won't go to the doctor. They won't get a second opinion. They won't go to physical therapy. The things it takes, they know how to get better or they know how to find the experts to get the answers, but they won't make the investment for themselves. And more than just the team, more than just themselves, it affects their family and everybody they care about. And-

Shirley: Well, arguably, it's more expensive and difficult to do it for a human than an animal.

Trey: Yes. And I imagine we probably have better... Well, I'm very grateful for Salesforce benefits but most companies that have some level of benefits probably have better human-based benefits than they do critter-based benefits.

Shirley: That's true, that's true.

Trey: But pushing people to do a few things for themselves and checking in and asking pointedly, periodically I think's a great thing and it allows the... again, for me, in my experience, I saw that it drove conversation about this. And so whether it was within the team or if you have a friend in the group that sees this and checks in on you, the bottom line is people often need to be pushed. They need push to take care of themselves. And no one's going to do it for you. I can't work out for you, Shirley. I can't eat my broccoli for you.

Shirley: Aw man.

Trey: These are things you have to do for yourself. And sometimes you just need a little push. But the bottom line is, and again this is another Salesforce thing, we talk about Ohana but this is an extension of our family. And the way that we treat each other at work will propagate into how we treat others in our life.

Shirley: So, as an IC, do you have any advice or strategies that you've recommended to your ICs that have been helpful to help them be more productive?

Trey: Focus is hard. Again, we talked about how clarity's expensive. The idea of being able to go deep on something... individual contributors, especially in software engineering, often have to load a whole bunch of disparate context into their head. With Heroku, we have so many services that power the platform. There's no one human that has a full picture of the state, current architecture and responsibilities and operational patterns, of the whole platform. I can't imagine how some of our core services and other teams build. It's amazing. But that's not something that, if I walk over, "Hey, Shirley! Hey Shirley! Shirley! Hey!"

Shirley: What's up?

Trey: You're never going to keep all that loaded in your head if you can't sit still and focus for a period of time. And it's going to vary by the person and the workload.

Trey: So something we tried to institute with my team, and I've done this at a couple of jobs, is this notion of dedicated focus time. We called it Icarus focus. It's a real bad James Bond reference. They had this laser beam that would gather, with a bunch of crystals, all the sunlight and turn it into a big laser. The idea was this. The team would block and tackle for someone that had an Icarus icon, an agreed upon thing, with the team.

Trey: So they would go dark for a period of hours so they could read up or go deeper or do some development or troubleshoot something. And they would drop out of Slack, we knew how to blow them up on their phone and we had PagerDuty or anything else we needed to get ahold of you in an emergency situation, but the idea was the team knew that Shirley's going dark to try to troubleshoot a reimplementation of something for this one service and so she needs a couple of hours and may take a couple of cycles of that. So use a Pomodoro timer or whatever operational pattern you find that helps you maintain focus to go deep. But the team would block and tackle to create space for rotating members to go on focus. And so you kind of break up your tasks.

Trey: Someone would be on Icarus Focus and someone else would be monitoring the channel and responding to transactional requests for the team or the email and that kind of thing. Other people would be working on strategic work, working on documentation or other stuff. You kind of rotate your duties and so you'd be on a cycle where you have a week where you're going deep on specific types of development or pairing or whatever else you're doing but the idea that you create space for each other to do that is so valuable and so important.

Shirley: I really like that idea. But I have a question about it because a lot of the times engineers work in flow states or they're very temperamental about how they work. So do you kind of have a schedule and a rotation, where you're scheduled to be in Icarus focus or is it when someone feels the motivation or feels like they need to get something done, they can drop in the Slack and ask for this time?

Trey: I love how humans are so uniform in our behavioral patterns and thinking. You're going to work as a team to figure out what works best for you. Some people find their flow certain times of day. I've known people that do polyphasic sleep, where they're always, seemingly always awake. They only sleep for like an hour or two at a time. I don't understand any of this. The bottom line is people are all different and so you're going to find what's going to be best for your team.

Trey: And, again, in a leadership capacity, your job is to harmonize that team and so you find a way to do that. Once you have a level of trust, understanding and you've built that relationship across the team, you're going to know how to play to each other's strengths and create space for people to bring their very best. That's the outcome.

Shirley: Okay. So the takeaway is adapt it to the team.

Trey: Yeah. I mean if you can. Maybe it's on schedule. It may be like, "Hey, I just had an idea. Can I get 30 minutes to go do this? Can I steal two hours? Could I blow off this meeting?" If you're communicating, that's probably a great thing. What's perhaps unhealthy is, out of left field, Shirley sends a ping to the channel and disappears for a day or two.

Shirley: Yeah, peace out.

Trey: And it happens every week. Trust and communication are probably the foundations of any relationship. And so creating the context, investing in the people, understanding each other and then communicating where you're at, what you need, what you're trying to achieve, that's I think the starting place.

Shirley: So do you have any recommendations for an individual contributor? Resources to be a better leader and, if they're thinking about management, to start training themselves to be a good manager?

Trey: I think the best leaders are really good followers. You can't be a great leader if you can't follow. As a follower, it's your job to ask and confirm and make sure you've got an understanding of what the team's trying to achieve. Again, that Jocko commander's intent piece. Part of being a good follower is being able to lead and so if you've got a group of folks where you're rotating in and leading on projects and taking leadership responsibilities for different efforts, I think's a great thing.

Trey: There's a body of books, so Chasing Excellence from Ben Bergeron. Apologies, it's a cross-fit book. It's on coaching but Ben focuses all of his athletes. His coaching starts with teaching character qualities. You can't achieve your very best if you can't get to a strong character posture. And so it's actually a really, really great book.

Trey: The Score Will Take Care of Itself. I'm spacing. It was the 49ers head coach. That's probably the longer-form version of Chasing Excellence.

Shirley: Bill Walsh.

Trey: Yes, Bill Walsh. That's right. Extreme Ownership and Dichotomies, the follow-up book by Jocko Willink and Leif Babin. Phenomenal read. If you want an extra taste of testosterone, listen to the podcast because it's just awesome.

Shirley: Talking to the wrong person, buddy. I'm just kidding.

Trey: It's absolutely hilarious. Well, you're listening to a couple of Navy SEALs share their lessons from the battlefield so it's an absolute trip.

Shirley: Oh, that sounds exciting.

Trey: Yeah. Drive by Pink. How to Win Friends and Influence People, Dale Carnegie. Crucial Conversations is probably the Kung Fu, weaponized version of How To Win Friends. These are classic books. And there's so many books written on communication and leadership and business but these are on my short list of favorites. Then there's another one called Slack. I'll drop a link for this as well.

Shirley: Perfect. Well, Trey, thank you for joining us today. And that's all folks. Hopefully, this podcast has inspired you to be a better leader and a better manager.

About code[ish]

A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.

Hosted by


Shirley Xiaolin Xu

Software Engineer, Heroku

She traded closing deals in heels for the command line interface.

With guests


Trey Ford

VP, PM - Platform Trust, Heroku

Dad. Product VP, security nerd, mediocre typist.

More episodes from Code[ish]