Prashant Pandey - Head of Engineering at Asana

(Joel Beasley at 00:00:00) Hello, my friends. I'm curious to know how many of you have a leadership pipeline. We know that great leaders grow companies because we talk to them here on the show every day. But what are you doing to create great leaders within yours? If you're a CTO, it is 100% your responsibility to grow and improve your people beyond just their coding abilities.

(Joel Beasley at 00:00:20) We've built a tool that improves your people in their craft and in leadership. Visit leaderbits.io to learn more. Today, we are talking to Prashant, the Head of Engineering at Asana, and we discussed the importance of setting context as a leader, structuring engineering teams to ensure speed with a high degree of quality, and how Asana's all-hands events help shape their company culture. All of this right here, right now on the Modern CTO podcast. Here we go.

(Joel Beasley at 00:00:49) This is the Modern CTO podcast. Well, speaking of my setups, man, Asana is unbelievably gorgeous.

(Prashant at 00:01:06) Thank you. Yeah, we work hard at it. We have a new team room going up, so we've been thinking about—we have an open space which doesn't work for everyone, so we want some team rooms. We want to try out a few different things to make teams the most efficient they can be.

(Joel Beasley at 00:01:27) Yeah, I loved going and visiting the office. You had the big beautiful sign. You're very proud of that because that's the new area, right?

(Prashant at 00:01:35) Yeah.

(Joel Beasley at 00:01:35) And I thought the Burning Man object—can you tell me that again?

(Prashant at 00:01:42) Yeah. So Dustin Moskovitz, who is our CEO, has been going to Burning Man for, I don't know, decades now. And he has this really cool piece of art called the Hive, which is this hexagonal object that you can climb into and hang off from. And it has no nuts, no bolts. You can flat pack it completely and put it together.

(Prashant at 00:02:12) And it's been—it's a piece of art that has sat in many different places in Asana over the years as we've expanded, and it's really become a cultural symbol. And it's cool.

(Joel Beasley at 00:02:27) Cool looking. It's beautiful, right? And then it could probably fit, depending on what type of people you got, it could probably fit ten, fifteen people climbing all over it, right?

(Prashant at 00:02:40) Maybe. Maybe. Small people. Maybe my kids.

(Joel Beasley at 00:02:45) Oh, sorry. You know what? That's funny because I have my little ten-month-old running around, so you could just get, like, twenty of them.

(Prashant at 00:02:50) Yeah, definitely. Thirty ten-month-olds. Yeah. And it's also a cool piece of engineering, so it fits the—it's beautiful. We are building a beautiful product. It's a piece of engineering which we care deeply about. So yeah, it fits with the Asana culture pretty well.

(Joel Beasley at 00:03:10) And then maybe next year, you will do mega hive, which will fit ten or fifteen people.

(Prashant at 00:03:15) Yeah.

(Joel Beasley at 00:03:17) Slash portable house, right?

(Prashant at 00:03:18) Sure.

(Joel Beasley at 00:03:18) So what are you up to today? What does your day look like as the CTO of Asana?

(Prashant at 00:03:26) Yeah. Actually, let's start with a couple of things—what Asana is, and then what I do here. So Asana helps teams work together effortlessly, and we're building a SaaS product that helps teams do exactly that. We allow people to have in one place who is doing what by when. And even used in the most simple way, that adds a lot of clarity to what teams do.

(Prashant at 00:03:57) My role as the person who leads engineering is to make sure that the engineering team is thriving and we build the best product as fast as possible. That's my role. And what that means day to day changes. Right now, we are heading into something we call Roadmap Week, where we decide for the next six months what each team will be doing. So essentially, in this season of three weeks before Roadmap Week, a lot of my conversations with teams are how are we going to configure teams, what are the highest priorities, what advice and context can I bring given that I have a view of more of the teams and more of the business priorities than somebody working on an individual project?

(Prashant at 00:04:50) What is that advice and what's the context that I can bring that helps them decide what they're working on? So a lot of conversations. And we have our investor from our last round, Generation Capital, coming in for a talk today, so I'll be going to that. I'm really excited about them telling us why they invested and why they see a bright future for Asana, and then we'll have a Q&A where we'll answer some questions from the team. So that's what's going on.

(Joel Beasley at 00:05:16) I love that. That's really smart, the way you're bringing in the investors to talk about that. It gets everybody pumped up and allows everyone to just take a look back at what they're doing. Do you often have people come in and talk?

(Prashant at 00:05:31) So we try to balance it because all-hands are really expensive. If you think about it, it's a 300-person company, so even a one-hour all-hands is 300 hours of human effort applied towards it, and that can be really powerful if you use it for the right conversations. So we've spread them out. We do an all-hands once every six weeks or so.

(Prashant at 00:05:59) And we use it for all kinds of things. So we do show-and-tells where each team has an opportunity to show off what they've been doing recently, and that's always extremely energizing. We have things like Ellen Pao or Eric Ries, people with a perspective that we care deeply about, whether it be how to build a lean startup or how to really do diversity in the tech world—speakers of that sort which will resonate with everyone in the company and give direction to us. That's the kind of person we'd love to have, and we bring them in once in a while.

(Prashant at 00:06:42) But as I said, it's a balance. There are a lot of talks which would be really useful, but if we were doing them weekly, we'd probably think we are spending a lot of time doing that.

(Joel Beasley at 00:06:53) No, I really like—I mean, that's life. Life's the balance, right? So you have a long history in technology, and this isn't your first go-around at being a part of a technology company or being a technology leader.

(Joel Beasley at 00:07:10) You were at IBM and then Amazon and then now Asana. Can you tell me a little bit about how you got started and the progression of your career?

(Prashant at 00:07:18) Sure. Yeah. So there's definitely not been a grand plan which has led to my current role. I really enjoy my current role, which is broad and leading an organization which has people working on infrastructure and mobile and web product and data science. So it's really brought people doing a lot of different things.

(Prashant at 00:07:43) But what has led up to this is I started off as a researcher at IBM, where I worked on what you would think of as the lowest levels of the tech stack. So everything from disk drives and how to get I/Os out of them as quickly as possible. So I was thinking in microseconds and how to optimize things at that scale of time. And then doing databases and file systems at that layer and thinking about how to make applications more efficient. And I learned a lot about technology and how to think of what the future will look like and really thinking about how the things we were building now and the speed of data that we were gathering would actually change them in the next ten years.

(Prashant at 00:08:32) So really long-term thinking, learned a lot about that. But also learned that thinking and building prototypes is not the fastest way to innovation, which is what I was doing at IBM. So I had a real itch to ship things quickly because I wasn't shipping things quickly for a while. So I jumped from there to a startup, and that was a huge culture shock and huge learning experience, and we were doing video advertising. So I did everything from JavaScript, CSS, mobile SDKs. So I was more of a technical leader, and then over time, we realized, oh, we also need a people manager.

(Prashant at 00:09:16) So I took on that role. It was kind of a crazy startup experience, which a bunch of people who take on leadership in the Valley—it ends up being something like that. Chaotic, and you're trying to build some purpose within that chaos. So that was, again, learned a lot of lessons, how to do things, how to not do things. Then went to Amazon, and there helped build DynamoDB, which is a NoSQL database service.

(Joel Beasley at 00:09:48) Everybody loves that.

(Prashant at 00:09:49) Everybody—I hope everybody loves DynamoDB. It is what AWS is built on, so it's a really core and important piece of technology. It is the base of the base of what everybody is building on now. So proud of that.

(Prashant at 00:10:07) And the thing I learned there was operational excellence. It's not just about building software. The way we are moving, the way our industry is moving, is software as a service. Nobody wants to install your software. You have to build software and operate it. It's the yin and yang. You have to do both of those things really well to provide something valuable to customers. And that's at least my view of the world. That's the kind of company I want to be part of, where you are building and operating software. That would actually be my advice to technology leaders and people who aspire to this—think about that.

(Prashant at 00:10:45) Think about where the industry is going and not think in silos of just building or just operating the whole life cycle.

(Joel Beasley at 00:10:54) I really like your culture. So from the moment I walked in the building and as you gave me the tour and as I got to speak to you—and it's so different, you know, speaking to someone in person. It's so amazing because you get to pick up on who they are, right? And from the dinner that you explained to me that they're having and just everything about it, the culture at Asana—the first question is, selfishly, do you have any materials?

(Joel Beasley at 00:11:22) Like, Netflix has their deck, their famous deck that they put out that explains about different types of culture and things there. Does Asana produce any materials? Because I've talked to about thirty people since our meeting in person, and I keep saying culture at Asana. Culture at Asana. And then they're like, well, do you have resources? I'm like, I don't know. I'm talking to Prashant in a couple weeks. I'll ask him.

(Prashant at 00:11:46) So if you go to Wavelength, which is a magazine that we put out, you'll see a lot, not just from Asana, but what we think are the best things going on in the industry. So if you think about Asana and our mission to help teams work more effortlessly, a key part of that is actually building the best-in-class know-how on how teams operate. So we're not just building the operating system for companies, but we are also collecting information on how to do well. So Wavelength is just a great resource. Just look for Wavelength Asana and you should find it.

(Prashant at 00:12:30) That's a continuing resource. But if you want to look at the core values, just search Asana values, and we have a page talking about the core things that inspired us and we aspire to. And also Asana engineering values is another place where from the engineering team's point of view, we talk about—it's a list of five or six things that we really focus on as being the key to being a good engineer and being a good engineering organization.

(Joel Beasley at 00:13:02) Excellent. Yes. Like, item one, ship code.

(Prashant at 00:13:07) Ship fast sustainably is—

(Joel Beasley at 00:13:09) Really?

(Prashant at 00:13:10) Yeah, I believe shipping fast is—

(Joel Beasley at 00:13:16) But that's on the list. I'm just joking. Oh, that's awesome. Yes. That should be on the list.

(Prashant at 00:13:22) Yeah. I mean, that's what we do. The purpose of an engineering organization is to build the product, right? And when you're a SaaS company, that doesn't just mean the surface area of the product, but everything down to infrastructure is part of what you are delivering, and the experience, which is not just the user experience, but security, reliability, performance—all of these are things you're building.

(Prashant at 00:13:52) Right? And we need to keep improving not just the product, but all aspects of the product continually. And we're not sprinting and judging our speed on a one-month basis. We are building a company for the long term. So how do we set up the systems which will allow us to not just ship fast today, but look at the volume of what we've produced over the next two years, and we are trying to maximize that, not what we ship tomorrow.

(Joel Beasley at 00:14:22) I love it. You're focused on the long term, not the short term.

(Prashant at 00:14:25) Yeah. And I mean, short term and the long term, not just the long term.

(Joel Beasley at 00:14:28) Oh, so we're back to balance again.

(Prashant at 00:14:30) Yeah. Balance is actually one of the Asana core values.

(Joel Beasley at 00:14:36) Is it? Yeah. That's honestly—so I'm in my early thirties now, and I would say something happened about, like, twenty-five, twenty-six, or four or five years ago. And this idea of balance, it was like this orbiting thing in my life where it would just come up. Big balance, like every couple of weeks, balance.

(Joel Beasley at 00:14:57) And then I realized this is an art to master for life. Like, it's something that you don't complete. It's a continuous learning and growth track that you must have around you at all times.

(Prashant at 00:15:11) Yeah. I think for a lot of decisions, I think we have this fallacy in terms of how we think of it that it's a dichotomy of this or this. And the truth usually is that you can get aspects of this and this. You can get all the way here or all the way here. You could, but that's probably not the right way to solve the problem.

(Prashant at 00:15:36) I'll just figure out where in the middle of those things—and it could be very close to the side. It doesn't have to be—balance doesn't mean being in the middle. Balance just means considering what is good about this and this, and how you can get as much possible from both of these.

(Joel Beasley at 00:15:54) You just made a point that gave me chills because I know it inside, but the way you articulated it was poetic. Balance does not mean centered.

(Prashant at 00:16:05) Right.

(Joel Beasley at 00:16:05) Right? Like, that is a misconception. People believe that by default. Oh, to me, balance means you've got to go back to the center, right?

(Joel Beasley at 00:16:13) But you are—that is so true. Everything is, I call it a spectrum, right? And I love what you said too because that is a truth I have found in life. If you find yourself rapidly sliding across the spectrum and bouncing, like, from one hard end to the other, that's probably not—there's something going on there.

(Joel Beasley at 00:16:32) To be aware of where both ends are and to see the gradient and to be able to adjust yourself and place yourself exactly where you need to be or a team or whatever it is, that is an awareness that is very valuable in life.

(Prashant at 00:16:47) Yeah. And you learn, and then you apply it, and then you get opportunity to still learn it again. So we've always had this value, but we built a huge piece of framework called Luna, which was when the company started, which was this front end to back end JavaScript all the way co-simulation going on. So basically, the server figures out the data to send to the client by actually running the code that runs on the client. Very forward-thinking, functional reactive programming framework that we built.

(Prashant at 00:17:25) And over time, we invested a lot in it. And over time, as the industry matured and open source emerged with solved pieces of the problem, we realized that that wasn't the best path even for shipping fast sustainably. And so we had to swing the pendulum to the side of, instead of working on trying to work on the framework and features in a balanced way all the time, what we're going to do is actually focus on doing this massive rewrite, and we are going to focus on the framework. We are still going to dedicate some energy to the surface area of the product, but a lot of the work will be unbalanced, and a conscious intentional decision to put a lot of energy into creating a new framework which would help us ship fast sustainably for the long term. So we built something called Luna 2, the most creative thing we could think of.

(Joel Beasley at 00:18:22) I love it. It works.

(Prashant at 00:18:24) Yeah. And it's amazing. It uses React. It uses TypeScript for the front end. It uses some degree of our special sauce because for our product, there are some things that we need to do that are just special to us. It doesn't make sense for that to be broadly used or open source. And then we built out the back end because nothing that exists in the open source world kind of matched what we needed. So we did a balance again of using as much open source as we can, using AWS for a lot of the layers in the back end, but then building our own custom thing on the back as well.

(Joel Beasley at 00:19:05) When I was leaving, right, going down the elevator, I got in the elevator with this awesome engineer, and she was telling me about how she learned programming with her brother. Right? And then she had learned it in another language, but then when she came to Asana, you actually saw that she was good at programming, but then you trained her on TypeScript. She didn't know TypeScript going in, but she was a programmer, and then you guys trained her. Do you do that a lot?

(Prashant at 00:19:37) Yeah. So we definitely don't think of any specific language or any specific technology as being essential to being an engineer at Asana. We think there are a core set of skills which include understanding of computer science and computer systems that are really useful for being a good software engineer. Knowing about the web stack is really useful because shipping installed software versus shipping software on the web are different beasts. And so the more you know about creating web software, the faster you'll be. But all those are nice to haves. But if you've really thought broadly about what you're learning, even if you're learning something that will not get directly used at Asana, if you've thought about it in a curious way and learned the patterns, we absolutely think of that as a transferable skill. So TypeScript is not popular enough that a lot of people know it coming in, but if you understand typed languages and you understand web technology, it's not hard to learn. So anybody coming into a new job is going to learn some stuff, and we devote a lot of energy to mentoring and teaching, and it pays off very, very quickly. So yeah.

(Joel Beasley at 00:21:03) I get asked a lot about peers. So for the C-level, this is the part of the audience that, 30% of the audience that's very similar in your shoes with a similar size company and similar size responsibilities. And they say when I reach out and talk with them about the things that they want to hear most about that are least discussed is what the relationships look like and anything that comes to mind as far as advice when interacting with your other C-level peers.

(Prashant at 00:21:40) Yeah. So good question. I think one of the important things to realize for a lot of roles in engineering management, not just if you're leading engineering, is figure out what the loneliness level of the role is. And a lot of leadership roles end up being lonely in the sense that you are making decisions and the work you're doing is not common work that everyone has the same shared context from. When you're thinking about career pathing for the group of people who you are the manager for, you can get some advice about it, but not all people, you don't have a team that has as much context as you on that problem. Whereas if you're working on building a particular feature, you're working with a PM, a designer, and other engineers who are all kind of trying to figure it out together. So definitely, as soon as you do management, you're doing something that is somewhat lonely. So the important thing is to figure out, what are my various peer groups and how can I get support?

So one thing that we did, I think a couple of years ago, was define something called the Company Planning Team at Asana, which is the head of business, the CEO, the head of design, JR, our other co-founder, head of people ops, and our CFO. And that's just a small group that meets regularly, maybe twice a month on average. And it's an important place to connect and just talk about how we're doing as a company, what are the important topics that are coming up. And we did something called a talent review where we just went through who our reports are, how they're doing, and just talking through what are the best ways to help this team and develop these people. And it's just so comforting to talk about it with a group of people who are really supportive and who you build trust with over time because you've talked to them where the stakes are lower. And so when the stakes are lower, when you develop that relationship, it's easier to have those high stakes conversations. So that's been an incredible tool for me. We hired a head of people ops who started this. And at the beginning, I was like, oh, another meeting on my calendar. But over time, I've realized the great value that it adds.

But that's not the only peer group that you should be building as a leader of engineering teams. We have something else called the EM Managers Board, which meets once every six weeks, I believe, is the cadence. That's every single EM manager at Asana for now, and that's getting to be a large team. But the main goal of that is, again, to create that set of peers, that community where you can look around and you're like, oh, your job is similar to my job, and we can talk about things like what do people care about, what do you do when people are in a tech lead role, how do I, as their manager, give them the right guidance? Are we doing compensation right? How are we thinking about recruiting? And how should each manager be contributing to recruiting? And how should every engineer be contributing to recruiting? Because as an engineering organization which is trying to hire the highest caliber engineers, if you don't have everybody engaged in that, that's an incredibly hard problem to solve.

(Joel Beasley at 00:25:37) You have recruiting. I see this at companies all the time. You have recruiting over here sitting next to HR, people ops, or whatever the name is, and then they're reaching out and they're usually not incredible. They're not full-time developers, right? Because they're recruiting. And then you have the developer sitting in these groups and meetups and these peer groups sitting right next to recruitable people. They're just like, yeah, we're good at selling. It's like, how do you make it so that they are aware of how to pull other great people in or that even communicating or transmitting the fact that there's a need? Just keeping that front of mind that, hey, we're always looking for great people at Asana, that way it's on their mind as a topic of conversation when they're in their peer group. Right?

(Prashant at 00:26:23) Yeah. So I think, in general, advice for leaders is your job is to always set context. And as an engineering leader, your job is to always remind people how important recruiting is to your organization. Right now, for Asana, given the rate at which the business is growing and our need to get more engineers to solve all the problems that our customers need us to solve, this is a message from the CEO that every week, every all-hands, every opportunity we get, we talk about, hey, recruiting is the most important thing we are doing. It's the number one priority. It's a P0 bug right now. Let's figure out how to get more people here, how to get them successful as quickly as possible, how to build more product quickly. It's P0. Let's get this done.

So reminding that, but also then having one-on-one conversations about what does that mean. Just knowing that something is important doesn't mean you can solve the problem. You can talk concretely about what is it that you can be doing to help with this. And there's a lot of things that engineers could be doing. They could be doing outreach. They could just be using every opportunity they have where they meet people socially or in technical groups to pitch and just authentically communicate how they enjoy working at Asana and use that. That's a pitch that works. If you see someone who really enjoys their job, you're like, wow, maybe I want to work there. And so we have a phrase called hashtag ABR, Always Be Recruiting. It's a meme at Asana. Everybody has heard it. Everybody knows what it means. And we have people we hired because somebody met them on a shared lift. Right? So, yeah, people really believe it.

(Joel Beasley at 00:28:17) That's awesome. Well, as a growing company, one of the things you need most of is a lot of great people. Right? So teaching your people how to do that is very important. I read your article about the five whys.

(Prashant at 00:28:32) Yep.

(Joel Beasley at 00:28:32) Right? And so I really enjoyed how your problem-solving methodology. Right? And I actually just noticed too, here in the notes, it's actually on wavelength.asana.com. I read it, you know, shortly after we met, but then I noticed here that it's actually on Wavelength and you mentioned that. So could you give a brief high-level, I'm not going to quiz you on the exact step-by-step ways, but the high-level overview of the five whys to get to the root of any problem?

(Prashant at 00:29:01) Yeah. So I think if you up-level from that, the important thing is creating space for reflection. Good things happen, bad things happen, and you can either go about just treating them as chance and moving forward, or you can set up time to reflect and say, why did the things happen the way they happen, and what can we learn from this? And if you have that learning mindset and if you believe in continuous improvement, then you will continuously improve. And at Asana, we do that through a variety of ways. So I talked about Roadmap Week, which is creating the space to reflect back on the previous episode, the previous six months, and also set the agenda for the next six months.

And five whys is another such exercise, which is, basically, if a fault happens, and it could be anything, it could be we had a candidate who was really engaged decline an offer. That's a good thing to just sit back, relax, talk about why that could be, what are the reasons, and what could we learn from this. If you had the site go down, that's an obvious place where you can run a five whys and understand. And five whys, the idea is pretty simple. It's start with the top-level why of why were our customers not able to access the website between 4:45 PM and 5:00 PM yesterday. And you're like, okay, the answer to that question is our web servers crawled to a halt, and so they were taking enough time that web servers were timing out, and then you could say why again and dig deeper.

There's obviously a fallacy here that there is a single root cause of the problem where reality is a lot more complex. So the important thing to remember is we are using this as a reflection tool, and the important thing is to kind of go broad and then identify action items and have an open mindset about what possible action items could be. And so you use the five whys and you explore some branches of what the reasons are, and then you identify action items. And then the next step is to actually figure out, are we going to do any of these actions? Just because you identify ways you could avoid this problem doesn't mean that, and the fact that you had the problem doesn't mean that you should do all of them or you should schedule all of them. They go into a prioritization mechanism out of which you might do the two most leverage things that came out of this discussion. But you log all of this in Asana, and so if a problem happens again and you identify the same action item, you actually now say, okay, we've talked about this three times that we should maybe do this action item. The priority of this is probably higher than before when we said we'll punt on this, and so let's do it this time. So really, the goal is to improve. The way we do that is through reflection, and five whys is one mechanism for reflection.

(Joel Beasley at 00:32:14) Now who can call a five whys? Can teams do it themselves?

(Prashant at 00:32:19) Yeah. Absolutely. I mean, that's how it gets used. It's not, the worst thing would be for it to be a top-down driven mandate of you should run a five whys on that. The idea is here's a tool. We'll teach you how to use it well when you join the company, and you should use it. And a lot of times, it feels too heavyweight, so you don't need to call a four-person meeting to do it. You can do it by yourself, and then you can document that for a small fault. Just say, this is how I reflected. This is what I learned. Here it is, and I used the five whys for that or not.

We also have a centralized repository of five whys notes, which people follow, and so you can learn from what other people learned from. So I see things come in there from engineering, from recruiting, from sales. When people run five whys, it all goes into the central place where other people can choose to read it and learn from it.

(Joel Beasley at 00:33:20) This isn't a core feature of Asana, is it?

(Prashant at 00:33:23) It's extremely easy to use Asana to run five whys, to have people get notified when new things get added to the project called Five Whys Notes. So it is not a core feature, but Asana is an extremely flexible tool which has a lot of structured information. So it's easy to set up processes of various kinds in Asana, including five whys.

(Joel Beasley at 00:33:52) You set up processes?

(Prashant at 00:33:54) Just yeah, just set up processes. Yep.

(Joel Beasley at 00:33:58) Oh, I didn't know about this. Tell me, I want to make sure I understand Asana. Right? Wait. So you can set up company processes?

(Prashant at 00:34:06) Yeah. It's a good way to just document that this is a template. Every time we do process X, it means identify participants, come schedule a meeting, take notes. There's a five whys template task that has a list of things that every five whys should do, and you can complete the ones that don't apply to this particular situation. And then when you want to run a five whys, you just copy that template into a new project and assign it to the right people, and then you can use it as a rinse and repeat.

(Joel Beasley at 00:34:43) That's awesome.

(Prashant at 00:34:44) And, yeah, this is used at very, very large scales by our customers. For if you want to launch in a new city, there are thousand-task templates for every time you launch a new service in a new city, you would just want to copy that and use that. And that ends up being a core value that Asana adds, is you don't miss anything. Everything is documented about how this will happen.

(Joel Beasley at 00:35:11) Wow. It's almost like, maybe this is just because my recent, you're always influenced by your recent environment, but I've been doing a lot with system and business processes, reading this book called The E-Myth Revisited. Have you read that?

(Prashant at 00:35:26) I have not.

(Joel Beasley at 00:35:26) Okay. I suggest it. The premise is this company has been helping in business for thirty-plus years and all they do is help business owners, like a girl that would own a pie shop.

(Joel Beasley at 00:35:39) Right? That's one of the long-running stories in the book, which is why it comes to mind—teaching her how to go from being the pie baker to owning the pie baking process and the scaling and the duplication of the pie bakeries so that she's working on her business, not in her business. And the analogies, everything going through, it just really relates to me from how I've scaled my career as a technologist. Right? Yeah.

(Joel Beasley at 00:36:09) So, yeah, I forgot my train of thought because I was so excited about that book. But what did we say before?

(Prashant at 00:36:17) We were talking about processes and how companies use it. But the pie baking thing—I mean, we have one of the customers we learned so much from and we're proud of serving is a company called Weisman. It's a German company, 100 years old, 11,000 plus people, and they're going through this digital transformation. And Asana is kind of becoming the core DNA of the company and the way to set up repeatable processes using a digital tool. And so, yeah, that's what I look for—is building a tool that really helps businesses change and takes away a lot of the work about work that they used to do and not do well sometimes, and to just be able to do it consistently and well every single time they do it.

(Joel Beasley at 00:37:08) That's interesting. I like that because I didn't get that from—that's very—this is a very—I might use Asana for this. We have, obviously, a lot of repeatable processes, and I've been looking for a tool because we know that when we go into a new vertical, like, for example, we've got this whole LeaderBits thing that we're doing. Right?

(Joel Beasley at 00:37:30) And so we have a couple of markets where we might enter, whether it's heads of learning or HR IT or CTOs, going directly to the CTO, or getting in advertising to an engineer and getting them to bring us in and take us up. So we had these four or five ways, and our deployment process to reach out to them was very similar. But to be able to process-tize that so I can scale it is what I've been looking at—something more than just putting them in a Google Doc. Right?

(Joel Beasley at 00:38:05) And you just explained that Asana might be very valuable for that for me. I'm gonna take a look at that after the call.

(Prashant at 00:38:12) Yeah. No. For LeaderBits, but also for a podcast, I assume that there is a playbook for this is what we need to do. Make sure that your fancy Yeti mic is working, for example. And you can put this into a template project.

(Prashant at 00:38:27) And Jake can be assigned here for a task, and Joel can be assigned here for a task. And when you're doing a new podcast, just copy that over. Depending on the location and whether it's in person, things will change. But it can all be in one place, and you can know who is doing what by when by just going through this one time, setting all of it up. And then the people who are responsible will just know who's doing what.

(Joel Beasley at 00:38:52) I really like that. I really do. It'd be very beneficial if we decided to become a podcast company and do podcasts. We have a lot. The podcast is something that we have process-tized, but with spreadsheets because of the fact that there's just one of us.

(Joel Beasley at 00:39:10) We only do one podcast. And so we all have the spreadsheets and we go through and do our essentially go-live checklist, right, of every single podcast. And then the editing sheet too—we have—you'd be surprised, there's 15 things that happen to a podcast between the time it's recorded and the time it's produced.

(Joel Beasley at 00:39:30) And then there's another 30 things that happen to actually publish it to all our networks. Micro content clips get created. There is a lot of stuff that happens in the podcast.

(Prashant at 00:39:39) Yeah. That's what you realize—that when you want to do things well, there is a lot of detail. And when there's a lot of detail, humans are very good at forgetting those details. So there's this fantastic book called The Checklist Manifesto which I'd recommend to your audience and to you—of the power of just having a checklist which you go through for—and it's written about the medical profession and what happens when somebody comes into an ER and just making sure that are you amputating the right organ, not the wrong one.

(Prashant at 00:40:21) Having—make sure that you look at this document to know and make sure you compare the armband to the actual procedure—is things that if you miss one of those, it's like, oops, huge problems.

(Joel Beasley at 00:40:39) It's very important. Yeah. I spoke to an embedded systems designer. He was telling me how he mentors kids in high school, middle school, on embedded systems. And he goes, because I just—one day I'm gonna be on one of those heart pacemakers or something. And he goes, I just wanna make sure there's no overflow and there's no crash. He's like, so I do my part and I mentor them on best practices with memory usage. It was fantastic. Advice to your past self. If you could go back ten years and give yourself one piece of advice, what would it be?

(Prashant at 00:41:15) Just one?

(Joel Beasley at 00:41:16) Just one. That's it. Just one.

(Prashant at 00:41:19) I would keep it simple. I'd say understand why you're doing something. Think about why you're excited about a project, company, and then throw yourself into it. If you understand the motivation, if you can really get to the why and say, yeah, that makes sense, let's just do this. And so, yeah, I don't—as I said before, it's not a grand plan. It's steps along the way. And for each step, if it's intentional and if it is for a good reason that you understand, it probably turned out well.

(Joel Beasley at 00:42:06) You know, that's really good advice because this week, right, because we've been doing the whole approaching the market with LeaderBits and trying different messaging, and then I was thinking—I was hanging out with my wife and we were thinking—I said, you know what, the why I'm doing this is because of the messages I get every day from the 60% of audience that are the next generation asking, how do I level up? How do I do this? How do I do that? If I wanna go ahead in my company, do I go spend four years at college on nights and weekends, or what do I do? How do I become more valuable in my company? All those things. And I was over here, you know, making it a little more complicated, being the engineering version of myself. I need to be making more features or more products or, you know, focus on the technology. And then I remembered this quote I heard from somewhere that rings in my head from time to time. It's like, it's about the people. Right? It's always about the people. It's never about the technology. And then I thought, how could I step back and what advice would I give myself if I were looking at myself from the outside? And I said, you know what? It's not about the details of how cool the point system is or the progression. It's not about that. What it's about is the experience the individual has as they come across. And then looking at my product—not looking at my whole company as a product, as something somebody would pick off a shelf, not just the little product inside of the product. Right? And then when I looked at it like that, it changed everything, and it made my actual software like 10% of what we do. And then the experience around it and walking that human down that path and the experience around that—everything changed.

(Joel Beasley at 00:43:55) The whole way we looked at it changed. We went from being a SaaS product to an annual technology leadership program where we actually walk these—we have the product, the thing that distributes the challenges and all that. But going and saying, hey, challenge, we're gonna give everyone challenges—everyone's like, oh, well, let's demo an individual challenge. I'm like, well, they're all 70 different, so you're not gonna get a real accurate idea of what the experience is like. And then I realized I'm selling the wrong thing. I'm communicating the wrong thing. What I need to communicate is we take this individual who wants more and we bring them in and we walk them through this program for a year. And throughout the entire thing, every single week they have progress that's been reported. And when I switched to that—I haven't even really pushed the whole message out to the market fully yet. We're doing it probably next week. But inside, the inside feeling I got was this is the right track. It's a better track than before.

(Prashant at 00:44:49) Yeah. But you can apply this to everything—is just step level up a little bit and understand what you're doing and why you're doing it.

(Joel Beasley at 00:44:59) Yeah. Keep the people at the center of it.

(Prashant at 00:45:01) Yeah. And we do it for building everything that we build, whether it be features for customers—why would somebody wanna use this? Why are we building this?—to an infrastructure change that we're doing. Why is the important question from this time.

(Joel Beasley at 00:45:20) And then you've got the tool for the five whys.

(Prashant at 00:45:23) Yeah.

(Joel Beasley at 00:45:23) Do you show that template publicly? Is that a template with five—

(Prashant at 00:45:26) I think that—yeah, I think that the blog post that you have should have a picture of it, but, yeah, we'd be happy to share it as well.

(Joel Beasley at 00:45:42) So does Asana come with a library of templates?

(Prashant at 00:45:45) It does. Yeah. There are both templates to start you off, whether you're doing a marketing process or another process that you get. But also you can create templates that anybody within your company can use.

(Joel Beasley at 00:46:02) So there are a lot of engineers that listen to the podcast, and I've been super in love with the culture at Asana. If they wanna know more and get in touch with you, what's your ideal as far as engineer? I know you mentioned before you're not super tied to language, but if you were just talking right now to all the engineers out in the world and hashtag ABR, what would you say?

(Prashant at 00:46:28) I think I want all of them.

(Joel Beasley at 00:46:30) All of them?

(Prashant at 00:46:32) All the engineers. Well, I think that we definitely—the people who thrive here are excited about the challenge that we are building. And that could take either the form of the mission of helping teams work together more effortlessly, which resonated with me and that's why I'm here. But also this problem of building something that is the core operating system for companies and making it both easy to use and extremely rich, which is an extremely hard product challenge. Making it secure because people are putting the DNA of the company in there, and we need to protect it better than they would be able to protect it on their own systems. It needs to be high performance because who wants to use a tool for making them work faster when the tool is slow? It needs to be available whenever they need it, and that's a challenging set of things to do all of the above.

(Prashant at 00:47:34) So that's exciting. And if you have the skills to build good web software, or you think you can pick them up fast, then, yeah, by all means, I'd love—we are based in San Francisco and New York because that's where our engineering teams are. I'd love to hear from more engineers.

(Joel Beasley at 00:47:55) Yeah. And then how would they go about reaching out?

(Prashant at 00:47:57) So LinkedIn is a good place where they could just reach out to anyone that they see at Asana. But sending an email to [email protected] is another way that they could just get in touch. Send us your profile, and then we'll definitely get back to you.

(Joel Beasley at 00:48:16) Awesome. Yeah. And I don't think I've ever done that before with a guest. I just—when you walk in the office and you're just like, this place is pretty cool, and we all need great people. So anything I can do, you know, let me know. I'll help in any way possible.

(Prashant at 00:48:31) Awesome. Thanks a lot, Joel. That is really gracious of you to allow me to plug Asana on your show.

(Joel Beasley at 00:48:39) Oh, yeah. I'm, you know, Team Asana. So whenever you need any favors or anything, just let me know and we'll mention what you guys are doing on the show or whatever. And we're here for you, man.

(Prashant at 00:48:51) Thank you.

(Joel Beasley at 00:48:52) Awesome.

(Prashant at 00:48:53) Love talking to you, and all the other stuff is cherry on the top.

(Joel Beasley at 00:48:58) Yeah. Have a fantastic day, Prashant. Thank you so much for setting this up, and I'll talk soon.

(Prashant at 00:49:05) Alright. Bye.

(Joel Beasley at 00:49:06) Bye. Thank you so much for listening to the Modern CTO Podcast. Share this. Get the word out. Thank you guys so much. I couldn't do it without you. I appreciate it. You guys are the absolute best.