Treehouse for Teams
writes on September 4, 2018
“The fact was that we were building a company that looked just like the rest of Silicon Valley. It was not a diverse company, and at some point, just looking at experiences of companies that we want to grow up to be like and hearing about them saying ‘We wish we had started these efforts of really trying to become diverse earlier because it’s super hard when you’re not that and you’re big.’ And we’re like, ‘Oh, yeah, five years from now we’ll probably be saying the same thing because we haven’t started now.'””
Today on Engineering People:
Prashant Pandey is the Head of Engineering at Asana, where he leads its growing engineering organization toward high velocity, sustainability and quality. Before joining Asana, Prashant started and led the Bay Area team building Amazon DynamoDB, a fully managed NoSQL database service. He has also led Engineering for the mobile advertising start-up Vdopia and worked on storage systems at IBM Research. Prashant earned an M.S. in Computer Science from UIUC, and a BTech(Hons) in Computer Science from BITS, Pilani.
(Original episode released on September 4, 2018)
Show notes:
Guest LinkedIn: ppandey
The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz
High Output Management by Andrew Grove
Transcript, edited for clarity:
Ryan Carson: Welcome to Engineering People, the show where we interview the world’s leading engineering managers so we can learn from their experience and ideas. I’m Ryan Carson, the founder of Treehouse, and I’m your host.
At Treehouse, we have experience creating over 850,000 new developers and designers over the past eight years — so if your company is struggling to hire enough developers and product designers, that’s what we’re all about. Just head to teamtreehouse.com/go/talent.
But enough about us, let’s get to the show. I’m particularly excited about today because I am such a huge Asana user. I’m sort of part of the Asana religion, I would say. I’m joined by Prashant Pandey from Asana. Thanks so much for being with us.
Prashant Pandey: Awesome. That’s such a great start, saying that you love Asana, and that makes me happy.
Ryan Carson: I do. I was one of the super early users, and fell in love with the simplicity of it, the user experience, and it’s just gotten better and better. And I’m not being paid to say that. Honestly, I love the product. It’s great.
Prashant Pandey: Awesome. Thank you so much.
Ryan Carson: No problem. So let’s dig in and talk about what you’ve learned and who you are and everything above. Tell us what your job title is and more about Asana.
Prashant Pandey: At Asana, we de-emphasize titles quite a bit but it’s accurate to call me head of engineering. I have an area of responsibility, which is engineering lead. Essentially I’m responsible for ensuring that Asana has a productive, happy, engineering organization that’s building product at the fastest velocity possible and for the long term.
Ryan Carson: In case people haven’t heard of Asana, can you just describe what it is?
Prashant Pandey: Our mission is to help teams work together effortlessly. What that means is building software that helps teams work together, talking about what we have learned in the process of building that software in a way that helps other people pick the things that they love about how we work and incorporate that into what they do. But the software that we build, which is a SaaS product that, in a nutshell, allows people to know who is doing what by when. If you’re doing a project, if you’re doing a group of projects, you can use Asana to track what that means or is that composed of. You can put information about who the people are who are working on different things. You can assign due dates and you can have conversations about what’s going on and move things around when inevitably something new and unexpected happens.
Ryan Carson: I actually use it to manage my team and I keep track of all my one-on-ones in there. I have a one-on-one project that’s private for each person — and then Asana lets you create sections, so I usually create a couple sections. One is “Discuss.” I always tell my team if there’s anything you want to discuss, throw it on there. We’ll talk about whatever you want to talk about first. So we go through those checklists and then I throw things on there too that I want to remember to discuss. I also put a couple of other sections. One’s called “Behaviors of Trust.” I like to clarify with my directs, “What’s important to you, what behaviors can I demonstrate to build trust with you?” That way, in the one-on-one I always remember to look at it. It’s not a to-do, it’s more of a reminder.
And there’s a section called “Commitments,” and if I commit to do something I put the task and the due date, and assign myself. If they commit to do something then I say “When would you like to do that by?” And then it keeps track of this clear accountability without being heavy about it. It just makes it clear. So anyway, that’s kind of my unique use case for Asana. As the listeners probably know, we are a school and we create a ton of video content. We use it for all of our production.
Prashant Pandey: The one-on-one project is a great use case and we use it that way a lot. The beauty I’ve found when I started using Asana, and I think a lot of customers find, is the flexibility of anything from a 100-people team working together to launch a new service in a new city, the template for that and who is going to do what things and what the workflow is. You can track that in Asana. You can track a list of things that you think you’re going to do and nobody else knows about. Or you can have one-on-one tasks with two people on it and that’s something we do a lot here as well.
Ryan Carson: Yeah, it’s great. It’s cool. It’s a wonderfully flexible tool. I love it.
Why Asana doesn’t post its org chart
Ryan Carson: I think it’s helpful for the listeners to understand, because so many companies are different in the way they’re organized — engineering, leadership, etc. Can you roughly explain to me the company org chart and how you fit in?
Prashant Pandey: Yeah. That is an interesting question. We obviously have management and essentially a management hierarchy, which would lead to an org chart. We don’t post the org chart anywhere or talk about what’s the org chart and how are we organized.
Ryan Carson: Really? Like inside the company you don’t talk about it?
Prashant Pandey: Inside the company. Because the more important thing is who has what responsibilities, so we have a separate set of trees of relationship maps. I’m responsible for outgoing email, the technologies around that, and that is part of production systems. So who owns that? These might not be people who have management responsibilities who own these things, but there is a clear relationship that this system and the ownership of this process and the ownership of that have a relationship and it’s important to know who are the stakeholders and what we call the parent AOR [Area Of Responsibility]. That chart is just as important as the management hierarchy. What we’ve encountered as a group in other companies that we’ve been at is when you emphasize the org chart then everything flows through that — all communication kind of flows up and down the chain and decisions are deferred to just based on your position on this chart, which has the reason for it and the skills you have might be different than who’s the right person to make a particular decision.
We use areas of responsibility to clarify that and say that not every decision needs to be made with that. In many ways we are completely normal; we do have a hierarchy and there is accountability between reports and managers, but the primary nature of relationship between a manager and a report is that as a manager you’re responsible for your report’s career path through Asana. You’re responsible for managing performance and setting expectations and reviewing those expectations. But there are a lot of other relationships that have the form of the work that you do is really important for a broader responsibility than this other person has. In some cases they’re the same as the organizational relationship, and some cases they’re different.
Ryan Carson: So can you give us a practical example just to help the listeners visualize it?
Prashant Pandey: Yeah. So you could have an area of responsibility about the way we use databases. So we have a technical expert who has everything around what our deployment strategy is — how do we do upgrades, what libraries we use to access the databases — and that area of responsibility is contained within what we call the stability AOR, where stability is the area of responsibility which covers uptime of the site, essentially. So a lot of decisions that you make as the database AOR holder basically directly flow into whether the uptime of the site is high or not. So whether or not you’re doing a great job with the database AOR, the success criteria of that belong to the stability AOR holder so that relationship is really important and it’s really clarifying to have that relationship of parent AOR.
Ryan Carson: How interesting. So because that’s a little different than normal, it must take time to spin new employees up on how this works. What’s the cost you pay for that?
Prashant Pandey: It’s okay to default to talking to your manager or talking to the manager of the person who you have a request for. So that exists, that’s easy to find. So if you’re used to traditional using the management hierarchy, that works. There is nothing wrong with using that. We have that as a backup. And as I said, the way of thinking is not at all unnatural to people. It’s part of tribal knowledge, who is the expert that you really need to talk to to find out about X? This is not unusual. The thing that we do is we lay that out, there is an Asana project which is end responsibilities and it lays out with tasks each area of responsibility, and each of those has an assignee. Then within the task it describes what does ownership of this mean and that also says what the parent AOR is for that, so you can navigate through that as well. In a lot of ways you have a better guide on a lot of navigation of the org, because it is laid out in Asana, than at other orgs where it might be tribal knowledge.
Ryan Carson: Yeah. This makes sense. Just because you have fairly artificial departments — HR, engineering or talent acquisition — and it isn’t clear which responsibility do you own. So actually responsibilities do make more sense because you can understand them.
Prashant Pandey: Yeah. It’s absolutely not a zero cost thing. Because as you said, the onboarding for a lot of things this is a natural concept, but then you might have a decision which overlaps — where a decision has a security consequence and a product consequence — and who is the final decision maker if we don’t have that relationship between those to say which one overrides it, then there might be lack of clarity. We do have to work through those cases, but it makes 90% of things easier.
Ryan Carson: Right. That does make sense. The only downside I can think of is that if you’re defining responsibilities, what if you want someone to take on new responsibilities that they’re not currently owning? Like, how do you kind of incentivize that behavior of “I see something over there that needs to be done but it’s not my responsibility,” how do you encourage that?
Prashant Pandey: So a lot of roles, including mine — my AOR, as I said, is called “Eng Lead,” Engineering Lead — is defined as a “white space role.” What that means is that if you’re looking in engineering, if there’s anything that you can’t find in a well defined way, then that is my responsibility. Just because you found something doesn’t mean that I necessarily want to own it and now I feel the responsibility for, so in a lot of cases people are just “Hey, there’s this thing and it needs to be done.” I’m like “Great. Let’s talk about what that means and let’s create an AOR for that,” and if I feel that they are the right person to do that, then that can get done very, very quickly. Obviously, for everything in engineering, you don’t have to come to me at all. If you are doing something which is, “I’m improving tooling in this area. I want to start using this new tool that will make all of us more efficient,” then there are other people who have white space responsibility within the area of engineering velocity or tooling. Those are way better people to talk to about certain things than I would be.
Ryan Carson: Does the whole company operate this way or just engineering?
Prashant Pandey: The whole company operates this way. I think it’s applied in different degrees and different parts of the org. The tool is available everywhere but like many things, we don’t enforce any particular methodology to be uniformly applied everywhere.
Ryan Carson: Wow, thanks for explaining that. That’s unique and refreshing.
Important books for managing an engineering team
Ryan Carson: I’d love to know your favorite book or course or person that’s affected you as a engineering manager.
Prashant Pandey: I’ve learned from a lot of different sources over time. I followed Ben Horowitz’s career and I interned at Loudcloud. He was my boss’s boss for that summer. I doubt that he remembers me. A really interesting, thoughtful guy, and his book The Hard Things About Hard Things, super insightful. I learned a lot from that, including really thoughtful things about when you’re making decisions. So essentially, a lot of engineering management or leadership is you’re providing decisions as a service and when you’re making decisions obviously you’re thinking about what’s the right thing to do in this case — this is the situation, what’s the right thing to do? One of the things from that book that I try to apply for a lot of things is “Who are the stakeholders? And when I make this decision, whether I choose X or I choose the complement of X if it’s a binary kind of decision, how is that going to be viewed in terms of what does that say about my values? What does that say about the company’s values that we are choosing to take this course?” That boils down to doing the right thing but it really allows you to think about things in a more deep way than a simple pro-con analysis. It’s a different way of doing the pro-con analysis because you’re thinking about how does this impact various things. What that book talks about is how if you’re the CEO then everyone is a stakeholder for every decision you make — not to put any pressure on you. [laughter] and I find that extremely meaningful.
Ben’s favorite management book, I think, is High Output Management by Andrew Grove, and that’s a brilliant book. It’s some ways the document that Silicon Valley’s built on. I mean, a lot of companies, a lot of things that you see and say “Oh, that’s very progressive, the fact that managers should have one-on-ones and they should think about where their employees are and think about how to manage them.” at least in a written form, I believe it comes from that book. It’s decades old at this point, but a lot of it rings true. So as far as books go, those are a couple.
I’ve learned a lot from every manager that I’ve had, all the way from IBM Research, my first job out of grad school, to today and Dustin Mouskawitz. Every step I’ve found managers who were also great mentors, so I’m lucky in that way.
Ryan Carson: I can vouch for those two books too. They both had a big impact on me and I found it interesting to read High Output Management knowing that Intel has since made missteps and had trouble. It’s kind of fascinating having the benefit of decades of hindsight, which also to me was a learning lesson that, as amazing as Andy was and as big of an amazing company he built, it still had trouble later.
Starting out: Studying, interning, reloading the copier
Ryan Carson: I love to get a story from all of our guests about where they came from. I think it’s intimidating to hear about people who are as successful as you and my other guests, so to bring it down to be normal in a way and that helps other people know they could be an engineering leader someday. So, what is kind of the worst or funniest job you’ve ever had?
Prashant Pandey: I love when I hear stories from people about busing tables and a bunch of odd jobs. Growing up in India, there just wasn’t a culture of getting these kinds of summer jobs. Your job in summer was to study hard [laugher] to do well in the next grade and the next set of exams, and get into the best college that you could get into — so the path is laid out for you, just work hard and go down that path. So I don’t have the kind of stories that I really like to hear. [laugher]
Ryan Carson: That’s all right.
Prashant Pandey: But I started my career out of grad school at IBM Research and that was a dream job. I’d grown up reading IEEE Spectrum as the pinnacle of innovation, and so much stuff there came out of IBM Research — “they’ve done this cool new thing.” — that I’d always looked up to doing research as the best thing I could possibly do. Then I spent a bunch of time there, learned a lot of things about low-level systems, disk drives, etc. and then jumped straight to a startup. From a research environment, I jumped into a video-advertising startup. I think the second day on the job, I replaced paper in the printer. I took the huge, five-gallon water jar and put it into the water machine. I was like, “Yes. I’m at a startup. This is what it should feel like.” It’s not a terrible thing to have done. I feel great about having done those things. It was just such a prototypical “this is what you imagine startup life to be” and I’m living it.
Ryan Carson: Yeah, I’m putting in the big bottle of water and I’m putting the paper in the printer. And that’s true, there is kind of this, “Everybody pitch in and just do …” I’m still doing that, and I’m the CEO. I don’t if that’s a good thing or not, but I was literally replacing our bottle of water the other day.
Thanks for sharing that. It’s also cool to hear about the culture in India though and how it’s different than in America, where there’s a massive drive to college and the degree and the credential is the path to unlock all that.
Prashant Pandey: Yeah, and when I talk about India, I should be the last person giving wisdom about India because when I go back now it’s unrecognizable to me. I’ve been away for 18 years and so my memories of India are of two decade ago India, so I shouldn’t make claims about what it is like now. I see my nieces and nephews growing up in a very different culture, but that was what it was like when I was growing up.
Two important things that you need to know
Ryan Carson: So if you could go back in time, to when you first got into engineering management, and grab the younger Prashant and say “Hey, these are two important things that you need to know.” What would they be?
Prashant Pandey: Two things. One of them is that this is a real job. As I said, I’d been at IBM Research and I’d been a tech lead, I’d done project proposals, get them staffed, things of that sort, but I hadn’t been the engineering manager for somebody who was like “This is your manager now.” Then I went to a startup and I think within the first month the CEO was like “Hey, do you want to manage these people?” I was like, “Sure, let me do that,” and I was like “How hard can this be? Must be like the tech leadership stuff that I’ve already been doing.” A lot of things that I started doing, like one-on-ones, soon I was like, “Well, I’m not doing any real work. I’m not producing things. I don’t have that same feedback cycle I used to have.” This is my later thought process where I’m identifying those things, but it literally felt like I’m not getting anything done.
Ryan Carson: So you were working with people, but there’s no software output for that?
Prashant Pandey: Yeah. I was still technically leading projects at that time, so there was that — but still that came as reviewing design docs and giving people advice rather than actually going and building it and debugging things. Debugging was probably, as an engineer, my favorite activity, more than writing code.
Ryan Carson: Really? Wow. You’re rare. [laughter]
Prashant Pandey: So that’s one. The second thing is that as you get experience, when you’re talking to people and you’re trying to give advice to people and you’re trying to coach people, it’s very easy to filter out things that are obvious to you, as “obviously the other person has thought about this. Let me not talk about that thing. Let me talk about kind of the higher order things or things I learned recently.” For things I learned 10 years ago are very valuable in some contexts to my reports that are the people I’m talking to. So it’s important, especially when you’re early in your relationship, to try to not have a filter of “This is obvious.” Obviously there are ways you can say obvious things and be very patronizing so there is a balance. [laughter] But it’s important to say “Have you thought about this?” Or ask them to describe how they’d do something and then add in something that you might think of as obvious. A lot of times people come out of that conversation and say “That was really insightful.” That reminds me in my next one-on-one to be a little more open to saying obvious things.
Ryan Carson: Gosh, you’re so right on that. I find that regularly I haven’t communicated enough of what I thought was obvious. They’re like “I didn’t understand that.” And you thought “Oh, yeah, I thought that was obvious.” So that’s a great piece of advice. Thanks for sharing that.
Diversity and inclusion in your company’s culture
Ryan Carson: I know we talked about this before we record the show and I know Asana is very passionate about creating a diverse team and creating an inclusive culture. I’d love to hear about what you are doing at Asana that’s working.
Prashant Pandey: We have a real-talk series, which puts together things which help the company be more exposed to diverse parts of our population. People who are under-represented in our community within the company. So we have employee resource groups, one of which is called Gradient that’s for people of color. The talk we had yesterday was about being multiracial and how that impacts your life. It was completely internal, so this was people we know and work with every day sitting on a panel just talking about how their experience has been interesting and different and harder, more fun because of who they are and how they identify. The series is called real talk and it was real talk. A huge turnout, lots of people from the company attending. Just hearing somebody who is part Chinese being questioned about cultural appropriation when they use Chinese dresses for example, and how that’s a troubling experience but also something they understand because they have insights into both cultures. It was fascinating that people open up in that way and it was fascinating to see. I had looked around in the audience and just the rapt attention that a half of the company had who were there listening. You could feel you’re in an inclusive culture because not just this is really happening, we are talking about this stuff, but also how interesting it is to everyone.
Ryan Carson: So the question is, how have you created that inclusive culture? What are some key foundational principles that allow you to do that?
Prashant Pandey: I think that the early part of the company, the founders of the company, the early people in the company, mindfulness was always a value the company had. However, the company was formed in the way companies usually are, which is through people’s networks, which tend to be of other people who look like them. From the start, the company has been full of people who are really thoughtful, including about diversity. The fact was that we were building a company that looked just like the rest of Silicon Valley. It was not a diverse company, and at some point, just looking at experiences of companies that we want to grow up to be like and hearing about them saying “We wish we had started these efforts of really trying to become diverse earlier because it’s super hard when you’re not that and you’re big.” And we’re like, “Oh, yeah, five years from now we’ll probably be saying the same thing because we haven’t started now.” Then it basically came down to saying let’s start now, so we created an AOR for diversity lead, had somebody who’s really passionate about leading that and start to think about what that means and try to improve that in the company. We eventually found Sonja [Gittens-Ottley, Asana’s Diversity & Inclusion Lead], who’s an amazing leader in the space to come joining us and lead that. The mission of helping teams collaborate brings together people and our value of mindfulness brings people who are passionate about how do people work together, what’s the best team environment, and a lot of those people had a natural inclination and believed that diverse teams are better. So we had that good starting point, but we are by no means doing great in this area. We’re learning and trying.
Ryan Carson: Yes, but you are working hard on it. I think that’s one of the big differentiators. Because the results will come if the work consistently is given. So it’s impressive to hear that.
Prashant Pandey: Yeah. We think about inclusion, which is for the team that is here, how do we make sure everyone feels like they’re part of this team? And then there is also how do we become more diverse and how do we get to folks who are under-represented currently on our team? That’s through a lot of efforts in finding people and finding sources which look different than what traditionally we’ve got our team from.
The benefits of hiring outside of Computer Science
Ryan Carson: So do you hire now outside of computer science programs or how do you kind of practically do some of that stuff?
Prashant Pandey: Yeah. So we have a terrific record of hiring from universities that would come to your mind first when you think about computer-science programs: MIT, Harvard, we have really great alumni from those schools who are doing incredibly well at Asana, so we hire from those — but just because we’re good at hiring from those sources doesn’t mean we should restrict ourselves to that. We need to broaden our reach. There are great people who can be terrific teammates and great software engineers beyond those schools. So we’ve broadened where we look for talent.
With computer science as a degree, we think you learn a lot doing computer science and we appreciate that and we get those people in. We have broadened beyond that. We think that people who teach themselves computer science at whatever stage can do just as good a job. If you look at that pool, that pool might be more diverse, so you want to be open to that.
We started an internship program called Asana Up. We’ve got two people now who are not from traditional computer-science programs but have taught themselves programming and are interested in learning more, to the extent that they’re willing to be part of a six month program where they work on problems that Asana is trying to solve, with Asana software engineers and as software engineers on the team. That’s been a very enriching experience for the people they are working with and for the two apprentices we’ve hired in that program. Hopefully, they’ll learn a lot and they’ll be Asanas in the future.
Pebbles: The secret to balancing top-down planning and bottom-up innovation
Ryan Carson: That’s awesome. Thanks for sharing that. I know that you are really working on the team and making it better. So I know that we’re all struggling with the pressure to ship new features and to deliver business value, but that sometimes is diametrically opposed to being innovative and research. How do you balance the two at Asana?
Prashant Pandey: Good question. The first time we talked we talked about timeline view and how we love it. To me, that is an example of some amazing innovation coming out of Asana, which is it’s familiar, you know what a timeline is. It doesn’t look anything like a Gantt chart or something that you might think of when you think of a tool to solve the problem of visualizing what the timeline of a project is. So, when we think of shipping product features at Asana, we think the key to being successful with the kind of tool that we are building is to balance ease of use and power — so we need to allow incredibly complex workflows to happen, but we also want them to be drop-dead easy to use for somebody who has not used a “project management tool.”
I’d like to think that every single feature that we ship ends up needing a ton of innovation to get right. On top of that, when you think of “How does this all work? this is a huge,” if you think about it, the objects being managed by Asana make a huge word graph. There are all these views on top of it. There’s amazing query complexity going on to make all this data available very quickly to allow a lot of rich interactions. It’s a collaboration tool, so something that you change in the tool right now should be visible to anybody else looking at even a different view of that thing.
If you think about the stack, there’s a lot of innovation that goes into building that. “Every day needs innovation when you’re building something like Asana,” is something that rings completely true to me. On top of that, one of the things is to balance top-down planning and bottom-up innovation in the company, and that’s something that — from my vantage point, at least — we strike a very good balance of. We do a lot of, “What’s our two to five year vision and what’s next the 12 months? What is the thing that we want to build in the next 12 months?” A lot of that is done in a top-down way, with lots of input from our customer-facing teams, lots of input from sales, from our product vision — our founder, who’s a product visionary, and our product team. So there’s a bunch of that that happens in figuring out what we’re doing but we also have an Asana project called “Product Opportunities” that anyone at Asana can drop in a task and describe what they think will be a step forward for the product. There’s actually somebody going through and triaging that as which of these look interesting for things that we can build in the next six months. We actually take those and every team has signed up for using a percentage of what we call “program time,” building pebbles. So things that are identified in a bottom-up way can make their way into the roadmap in a very organic and planned way, where we have set aside space for doing that in addition to a lot of things that happen in a top-down way.
Ryan Carson: That’s great. Did you call them “pebbles?”
Prashant Pandey: I did.
Ryan Carson: I haven’t heard that term before.
Prashant Pandey: If you’re filling up your tank, you put the big rocks in first, and then you think you’ve filled up all the time or that big part, but you can still fit in some pebbles, and then on top of that you can pour in a lot of sand and that’s called “recruiting time.” [laughter] So we make sure that every nook and cranny is full of interesting work.
Ryan Carson: Wow. That’s cool. Yeah. That makes perfect sense. Neat. It’s great how you’re using your own product too to keep track of those requests and eating your own dog food that way.
Well, this has been really insightful and valuable for me and I’m sure for our listeners too, so thank you for your time. I really appreciate it. Where can our listeners find you online?
Prashant Pandey: I’m on LinkedIn and you don’t have to use a LinkedIn credit to send me a message there, so please reach out if you have questions.
Ryan Carson: How about on Asana, where should people go to find y’all?
Prashant Pandey: If you’re interested in an opportunity at an Asana and if you want to come build Asana and use Asana at the same time or want to have important AORs, you should go to asana.com/jobs, where you can apply. But yeah, depends on what question you have. If you’re trying to reach HR support team, asana.com/support is where you should go. [laugher]
Ryan Carson: Perfect. Great. Thank you again Prashant for your time, and look forward to speaking to you again some time soon.
Prashant Pandey: Thanks a lot Ryan. This was great.
