• Shawn Jansepar on LinkedIn
• Khan Academy
• Square’s Engineering Growth Framework

Allen: Welcome to It Shipped That Way, where we talk to product leaders about the lessons that they’ve learned helping build great products and teams. I’m Allen Pike. Joining us today is Shawn Jansepar, director of engineering at the Internet’s very own Khan Academy. Welcome Shawn.

Shawn: Thanks, Allen. Excited to be here.

Allen: It’s great having you on. We’ve known each other for what? 15 years now?

Shawn: Yeah. All the way back to Simon Fraser University Comp Sci Student Society.

Allen: Yeah. I remember when you were fresh, just joining the university, it was your first week and how far we have come since then.

Shawn: I know. I remember reading your blog post. I forget what it was called. It’s a different one than the one you post on now, I think, but I remember thinking, “Wow, this guy is so pro.” You got to be like Allen Pike.

Allen: At that time I was not.

Shawn: But you were posting pretty quickly after that I thought.

Allen: To be clear, I was not pro yet. I was vlogging poorly 15 years ago. And then you keep at it for 15 years and eventually you get, I don’t know, do I qualify as okay now? Always improving.

Shawn: I would say that your blog post is often my most shared one amongst, I don’t know, work Slacks and whatnot. So I enjoy it.

Allen: Awesome. Well thanks, Shawn. I’m glad that that’s providing some help to you and your team. First, before we get into some of the things I want to talk about, building effective product teams, which is something that I’m just always interested to talk about, but I enjoy when we talk about that in particular. To give folks some context, how about you tell us a little bit about your background. How did you get to be director of engineering at Khan Academy and what is your primary focus in that role?

Shawn: Yeah, sure. Going all the way back, I mean, when I was in high school, my dream was build video games. That’s what I wanted to do. I ended up working at EA and realized I didn’t want to build video games, I just wanted to play video games.

Allen: Working at EA can do that to a person.

Shawn: I mean, to be fair I actually had a great experience there and I almost never had to do crunch. I was on a central online team. It was more like I ended up meeting a couple of my mentors who you know, John and Igor, who got really into kind of the mobile space and they were doing these things at SFU called Mobile Mondays where we had industry speakers talking about mobile tech. And this was prior to the iPhone days. We were talking about JAB applications on Nokia devices and I think I kind of just caught the entrepreneurial bug and got really excited about mobile tech. And I learned a ton at EA. I loved it. I worked there as an intern for almost, yeah, 16 months, or maybe even longer than that. But I realized that I wanted to get more into the entrepreneur and startup world. So I joined them at Mobify, the company they founded, worked there for six years, started as a junior developer, made my way to director of engineering. And throughout that time I just had this craving for getting more into the education space of computer science. It was just a passion of mine and I was getting a little bit less interested in the e-commerce space. And so I started, what are some outlets for how I can get more into education? I started teaching at a coding bootcamp called Lighthouse Labs, but then when I got promoted to director, I just had way too much on my plate, so I stopped mentoring at that bootcamp. I was missing that education aspect. So I ended up getting an opportunity to teach a web development course at SFU, which I think is the same course you taught.

Allen: I think I might have referred you for that role. I don’t remember for sure.

Shawn: I think you actually posted somewhere, maybe LinkedIn, maybe Facebook, looking for the next person to teach it. And then I saw your post and I reached out to you and I guess Greg, and ended up teaching that web development course, which was super fun, super rewarding. But I was probably working like 80, 100 hours a week and it’s not very sustainable. So I thought, how could I combine my passion for education and building software? I’d been a huge fan of Khan Academy. I’d watch Sal’s videos, I was like an evangelist of his. I would share his TED Talks with friends being like, this is the high education should be done. And then when I checked their website, they had an engineering manager role and I just thought, why not? I’ll apply. And that’s how I landed at Khan.

Allen: One little thing that we’ll get back to I think, is this, the growth through Mobify starting as startup startup, whereas a one digit number, maybe low two digit number of folks up to then being director and now since been acquired by Salesforce Enterprise, stuff going on there. I’m curious, tell us a little bit about what that role is because director of engineering can have different scopes and skills and priorities depending on the organization and even individual folks that are in the role. So what does that role look like to you? What is your focuses?

Shawn: In a lot of ways it’s grown, but in a lot of ways there’s a lot of similarities. So in where I think there’s a lot of similarities is when I started, I ended up inheriting a team to manage, and the company was going through a bit of a transition and how they organize, but we ended up moving towards a model where there’s an engineering manager who manages a team of engineers who own a specific area of Khan Academy. Previously it wasn’t like that, it used to be managers managing, either you’re a manager of all the front end engineers or you’re manager of all the mobile engineers, but they reoriented it around teams owning surface areas right around when I joined and I was tasked with managing the independent learner team at the time. I was managing that team and that team has evolved significantly since then, but I am still managing a team directly. So I think people would maybe think about a director of engineering as like, oh, you’re not managing individual contributors like senior engineers and whatnot, you’re maybe just managing managers and maybe at a larger org that might be true, but I still manage a team of engineers while managing a manager and probably more soon in the future.

Allen: Cool. So how do you think of, this is a question I always asking people because it gets different perspectives the way the different orgs are. So you describe this trade off in every organizational design. Which is like, do you have your units, your groups, your teams and teams of teams organized by the part of the product that they’re working on or by the skill that they have? So you can imagine, like you said, okay, well we have all the front end designers are all in one giant team and then they work on all the various things or everybody who’s working on this one particular product through the whole slice, which tends to be more common to do it based on the product organization in at least the kind of orgs that we work in. But how do you think about that skills piece in an org where it’s organized by product, product function in terms of getting mentorship and making sure that the people on your team are being leveled up and given great mentorship on the specific skills that each one of them has?

Shawn: There’s many ways to slice it and dice it, and I don’t think I’m necessarily someone who believes that there’s an objectively right way and it would objectively wrong way to do it, but in my experience personally, I found it to be much more productive to be, say a manager who is responsible for a part of the surface area and is therefore that manager is managing a set of folks who are taking ownership of that area and working with them on a pretty regular basis. Because I think that’s really the best way to get an understanding of how those people are doing and be able to… One of the ways I like to think about a huge role of engineering management is how can I always make sure that I’m putting people at their learning edge? Am I giving them tasks that are too difficult? Are they getting bored at work? I want to always give them that right level of challenge. And I think that is a lot harder to do when you’re not really directing the work. Let’s say I was managing all the front end engineers and all the front-end engineers were on cross-functional five different product teams and were cross-functional, I don’t have an insight into, it’s harder to get an insight of into what exactly those folks are doing. And I also wouldn’t have control of the work necessarily. Maybe I could determine who goes on what team, but I have less of an understanding of what are the challenges in that particular code base? What are the different architectural directions we want to move into? My lack of ability to have any control there would mean would make it really hard I think to navigate how do I put that person at their learning edge? I think that’s super important for, I don’t know, one important aspect of keeping folks engaged and happy.

Allen: And skilling them up, which is obviously valuable to everybody.

Shawn: If they’re not being skilled up, I think they’re going to go somewhere else to find those skills. So that’s what I mean by you, that’s in a very important aspect of engagement and it’s obviously important to any business, any organization to see the people that you’re invested in growing too. So it’s really a win-win.

Allen: To what degree, when we’re thinking about how we’re prioritizing product work, do you think it’s worthwhile or worth considering at least putting a little bit of weight into how it will or won’t engage the team when you decide what to work on? Or do you need to be still diligent about, okay, it’s customer first, the customers want this thing. If everybody on the team thinks this is boring, then it’s just my job as a leader to try to find a way to get them excited about it? Even if it’s like, yeah, it’s the fourth time we’ve done something like this, but that’s what, as far as our product understanding is, that’s what people are asking for. So that’s what we’re going to do.

Shawn: Yeah, I mean it’s such a tricky balance. I think in an ideal world and something that I believe in strongly is that teams and individuals on those teams are going to be significantly more engaged when they co-create the plan with you when you tell them what they have to do, not that doesn’t happen sometimes and potentially happen often depending on the circumstance. It’s like I internally with myself or with my management team, we have to feel like, ugh, this is the last option we had. Nobody wants to get to that point. But when you get to that point, you then have to do some of those activities around, well how do I make sure that I can help my team understand this decision as much as possible so that at least can get to the point where they can get as excited about it as possible, even if they’re not the ones who were initially involved in the co-creation of the plan. And that’s hard. I mean at Khan Academy, one of the trickiest things has been the fact that our big project, which is almost done and it’s been three and a half years long, is this project we called Goliath, which was we had to transition our entire backend from Python 2.7, which was no longer being supported on Google App Engine, and we made the decision, through a very lengthy process of writing an architecture decision record three and a half years ago, to move to services and to move to Go, which is going to pay dividends in the long run. But a lot of that has been some pretty, what’s the right word here? I don’t know. Not the funnest work. It was fun in the beginning.

Allen: You’re writing a brand new Go program from scratch and it’s an empty sublime text window or VS code and you’re just going. I’m sure that was fun.

Shawn: Totally. And figuring out, well, what are the right divisions between these services? Everything was in a monolith, so in the beginning and also tons of people didn’t know Go. And so it’s like, hey, we’re investing in helping all of you learn Go, level up in Go, and we’re kind of like going to invest in you. And so in the beginning it was super exciting. And when we finished that work, the first phase of that work, I think it was kind of this big relief. The harder part was actually the second phase of the work which we called Goliath endgame because it was like, Hey, let’s do the same thing, but for the not so important features, not that they’re not important, but there’s a reason why we phased the work. And so the second phase of the work was just the areas that were less critical to the business. We kind of phased it in terms of let’s get all the stuff that’s critical to the business done first in the event that all of a sudden Python 2.7 support disappeared, which we didn’t think was going to happen. We’re working with Google very closely, but it was always like, hey, why not de-risk things as much as possible? And so that was the first phase of the work and the second phase was the less critical, but still very important pieces.

Allen: That makes a lot of sense. And I like the epic code names and other, even in the way that you’re talking about it of evidence is the thought process of how do we try to get this to be engaging rather than just, all right, you’re all in a three and a half year march through the desert. Hope you don’t die. Let me know when you’re done.

Shawn: Yeah, definitely. It’s like how do we find the right balance of how do we help make this as interesting and challenging as possible? How do we slot in some breaks within this working on fixing some interesting or fun bugs or maybe even shipping a small feature? So that’s been keeping my team engaged throughout this has been a huge focus for a while and I’m very excited to not have to do that very soon.

Allen: It could just feel like we could just build on top of all this great work that we’ve done now.

Shawn: Yep, exactly.

Allen: One of the discussions that’ll come up sometimes when people are talking about building a engaging career paths for your product teams is this trade off in between the things that we’re talking about, trying to get folks work that is exciting and cool and new and engaging in that way versus building the muscle, which is debated as in how critical this is, but building the muscle of people wanting to and being willing to and being able to go in with vigor to go in and take in stuff that’s maybe a little bit less desirable or less new and fancy. So for an example, and this is one of the things that help clarify this as a thing that you can talk about and evaluate how important that is in this Square engineering leveling system which they published, which I think is great when companies publish these sort of internal documents. So then when you’re building your own leveling system, you can be, assuming you have a leveling system for how senior folks are, then you can look at, okay, well what decisions does Square make and how does that vibe with the way that we want to build our company? Even if you make totally different decisions. And in the Square system, once you get up to that kind of, you’re beyond intermediate level, then they start having things in the priorities of says that kind of identify whether or not you’re senior or how senior you are is whether or not you prioritize and value unknown and undesirable work. And that’s something that is I think a challenge on any team is sometimes there’s this thing that doesn’t get maintained and no one really wants to entertain it or it’s kind of blah, but it’s important. And so is that something that you think about when you’re thinking about how senior folks are or do you think that is a good or a useful metric to evaluate or a heuristic to evaluate whether or not people have a senior mindset or is that a little bit… The counterargument could be that’s just the engineering managers do not wanting to do the work of finding fun stuff for the people to do.

Shawn: Yeah, I mean I love the spin on it that you’re referencing from Square in that the reality is sometimes there is boring stuff to do and if you can make it such that one of the ways to get promoted is to get excited about doing, as you can, to do the, quote unquote, boring stuff that is going to incentivize your team in ways that I think are probably beneficial for the business. I don’t think we have that in our rubrics, not to say that it’s not a good way to go about it, but I think about it slightly differently, which is that, and I was talking to an intern about this today actually in a different context, but I always think about the more and more senior you’re getting as a software engineer, obviously it’s more you can write more complicated software maybe how to scale in certain situations, but I think about it more and more as you can take on more and more ambiguous problems and you more and more understand the needs of the business and can work backwards from that need. So when I think about software, I’ve had interns who come to me and they say, “I really want to be a mobile intern.” Or, “I really want to be a front end intern.” But I think it’s really important that interns come in and get a more breadth understanding of software. Because to me what software is more about is I can be given a problem and we can figure out together as a team of how to use a computer to make that person’s life easier. And sometimes that’s a user interface. Sometimes we need a database to solve that problem. And so I think about businesses have problems to solve for users and I want, not for me to have to go to my team and say, “Sorry, you’re going to have to work on the boring stuff now.” But I think the more and more senior somebody is, they should actually be able to come to me and say, “Hey, you know that boring stuff over there that no one’s doing? That’s actually really important and critical for our business and we’re ignoring it and we shouldn’t. Shawn, what can we do to solve that? How can we make that happen?” So what I like to remove is this notion of there’s some business people who know business and they know priority, and then there’s teams who are really good at computer science and programming and I sometimes have to give them the stuff that sucks. That’s not the way I want to see people grow. I want to see people understanding these problems as well as me so that I don’t want to be a bottleneck. I don’t think any manager wants to be a bottleneck. There’s things I’m going to miss and I want people to take on the leadership of being able to identify those areas and tell me what we should work on.

Allen: Yeah, I love that. And that’s one of the things I think almost all successful startups have some variance of that sort famously in the Agile Manifesto all going all the way back before we had Uppercase A at Agile where it’s like, here’s this book of all the processes you have to follow in order to be Agile. It was like let’s focus on people instead of the process and delivering customer value and give engineers the autonomy and accountability to try and solve problems as opposed to just giving them the spec. And so that seems basically what you’re describing and often one of the challenges of scaling a product organization is just maintaining that spirit as you grow and not letting it get crushed under, well, it would be easier if we just traded a whole bunch of engineers as interchangeable cogs who don’t understand the product.

Shawn: Yeah, for sure. I mean I honestly feel, and maybe I just haven’t looked this up recently and maybe it exists, but I do feel like there’s a missing opportunity in this space that’s like a boot camp that teaches you not just, okay, I’m going to either be a programmer, I’m going to be a designer who learns Figma or I’m going to go to product management school. Something that’s more holistic that you would maybe do all of those things because you want to become an expert in the craft of software.

Allen: And when you’re speaking my language. I think something that was frustrating to me and a lot of folks that go into computing science programs is that there is this idea of education, like longstanding classical idea of education about teaching about underlying concepts and things that don’t necessarily change from year to year that will then let you, you’ll go to bring that onto your industry or your research or whatever it’s that you’re doing. And the way that our program was, our university, which I think is similar in a lot of the better universities is that they do that by focusing often on the mathematical theories behind computing, which is still more or less, a lot of that stuff is still true. The relational math that lets you consider a union or a set is still true in the database 20 years later from when we took the course. But I feel like there’s also some underlying truths and axioms and theories behind how teams work together and how systems are designed and how you think through trying to accomplish product goals. And that’s the kind of stuff that I feel like, I mean maybe 15 years later they’re a bit better at that kind of stuff. But I feel like that stuff tends to be more thought of as vocational when a lot of it is pretty core human psychology and how do you rally people to do this stuff? So I don’t know. I love it. Let’s do it.

Shawn: I mean I think that’s just a byproduct of our education system where everything is teaching isolated skills. Let’s teach you math separate from let’s teach you computer science, let’s teach you humanities and whatnot. When the reality is, I use this as an example all the time. When we’re talking about the future even of computer science at Khan Academy or math that when I was in university, I remember I was just like, I’m good at math, I’ll get this stuff done, but I want to get it done as fast as possible so I can get to the interesting computer science courses. But then I feel like I started using certain mathematical concepts, not even because I really remembered them from my courses, but more so because I kind of just had to figure it out and then it was like, oh yeah, that’s very similar to this math course that I took before. And I always just feel so strongly that how much better would it be if I had to solve a practical problem maybe through programming and then it taught me the mathematical concept after. Maybe use programming to calculate the area under this curve and you would intuitively come up with drawing a bunch of tiny little bars and then adding them all up and then it’s like, hey, there’s this way of doing that. It’s called calculus. And there’s formal equations for that. You’ll be like, whoa, awesome. That’s what people, I don’t know, hundreds years ago came up with. And I think that’s such a better way of teaching.

Allen: I feel like I would certainly have been more engaged in my classes if we were figuring things out by like, okay, you want to solve this game, there’s this little level in a game and then you need to solve the problem. Oh you need calculus now. I’m like, okay, fine, I’ll learn calculus, teach me calculus, I want to know it now. But that’s just how my brain works.

Shawn: I think most people’s brain works like that. I don’t have the evidence in front of me to say that, but that’s my intuitive sense.

Allen: We touched on the sort of mentalities that go in and people bring into software projects and especially when you’re talking about the more ambiguous and ill defined ones. I want to give you a chance to share what you’ve learned around that. Is the idea of development methodologies or even we’re in a bit of a cyclical trend away from labeling them like, okay, we do Scrum TM exactly or we use this exact framework at our organization. Is that something that you feel like there’s anything missing there or are we all better off to just be like, yeah, everyone, your software gets developed using a hybrid ad hoc, lowercase a, agile iterative system that each company separately develops their own process and that’s good, that’s better and we should just stop trying to brand certain processes and methodologies?

Shawn: Yeah, I mean I think there’s something to branding different methodologies so that people have something to reference when talking about different concepts, but I think there’s also this danger of misinterpretation and then that misinterpretation permeates throughout an industry. And I mean I think agile is the perfect example of that, right? I think the spirit of agile was always this antithesis of, hey, let’s not try to plan everything for a year only to build something which fails in the market. What’s the minimum viable thing we could come up with to ship it to users to test, to get feedback and iterate our way towards success? But I feel like, and I’ve said this to a number of folks, that in some ways I feel like agile has been ruining our industry a little bit because I feel like people started to think about agile being just the opposite of what waterfall is in the sense that agile means no planning. If you are spending any time planning, you’re not agile. And I just feel like that’s a recipe for disaster because planning is still important. It’s not the planning you want to get rid of, it’s just like you want to be able to come up with that minimal viable product to test out with users. And also I feel like I take issue with the concept minimal viable product because while you might read a textbook definition of it and it sounds great, I think a lot of times people end up building really such a minimal product that they test it out with users and it doesn’t land very well and they’re like, okay, well that’s not a great idea. Whereas maybe getting it to a certain minimum level of polish might have really helped determine whether or not your product is viable, but you didn’t get it to that level. So the way I try to think about it is rather than minimal viable product, minimal lovable product. Literally keep the scope small, don’t cut quality, but you should ship what something you’re proud of. If you’re not proud of the thing that you ship, you probably shouldn’t ship it.

Allen: I think you know that my tendency is to agree with that strongly, but there also are smart people out there that say that if you’re not ashamed of the product then you shipped too late.

Shawn: I mean that’s the tough part, right? ‘Cause I don’t know, we can use the first iPhone is an example. Maybe somebody was ashamed of not providing the APIs for doing third party app development, but they were also probably pretty proud of that first thing they shipped as well. So it’s about finding that balance. I think you almost have to have both pride and shame at the same time.

Allen: I feel like that could be just a good motto for figuring out when to ship software. When you have a good balance of pride and shame.

Shawn: But I think the key thing there is you have to have some pride. If it’s all shame then you’re probably doing something wrong, but if it’s all pride and no shame, then you’re also probably doing something wrong.

Allen: Yeah, I think that I’ll agree with you on that metric. You mentioned planning, which I think is, as you say, I’m inclined to agree that, or I certainly have seen some organizations that are become so allergic to planning sometimes due to having bad experiences where you end up with a five year plan and then that ends up being a giant waste of energy or causes problems or whatever. But if you go back to the original Agile manifesto, not the giant book and course that you can get trained on, but just the single webpage with, I don’t know, 50 or 100 words on it that sort of posted this idea into the world. They talk not about avoiding making plans, they talk about prioritizing iteration and being adaptable over following the plan that has been made. And I think that that’s a difficult but incredibly valuable sort of thought technology, which is that plans don’t need to be followed to have been worth making. Going through the thought process of figuring out, okay, this is a path that seems plausible and if we were going to go down this path, what would be involved that this is path worth trying to go down based on what we know today? And then you refer to that plan as long as it’s useful and then you stop following it when it stops making sense. But just because you stop following doesn’t mean that there never should have been a plan at all as long as it wasn’t a 500 page in depth specification that tries to specify every single label and every screen of the app.

Shawn: Yeah, it’s not no plan, it’s evolving plan, right? It’s like first have that plan, but be, I mean, agile and be flexible. I almost feel like something that could have been really helpful maybe, and I don’t know, maybe you could say there’s a like, oh everyone should just read X book. But when that manifesto came out with all everything that was listed, when it comes to things like be adaptable instead of following the plan, I think what would be really helpful is here’s an exact example of how this has played out at a few orgs and how it has made that org more successful. Just so that I think people can really get grounded on how does this work in reality. Because I think a lot of this stuff ends up being abstract and because it’s abstract and maybe it’s ambiguous in some people’s minds or not everyone reads the manifesto, one person hears no planning and then they pass that along and then that second person never read the manifesto.

Allen: You get telephone tagged.

Shawn: Yeah, exactly. I’m sure if I go back and read the manifesto, it’s probably great, but I don’t think the issue… In a lot of ways, I actually think the problem is rooted in human behavior. This is not just a software problem. This is a problem with so many other things.

Allen: It’s like human behavior is what we’re trying to rally humans and with all their behavior quirks to build successful software. But then also we’re trying to teach humans with all their quirks on how to then rally other humans with all their quirks. And so it’s a human behavioral cake, layer cake. But I think one of the things that is a useful mental model that I find helps me teach my team better on we’re talking about process, is to try to overcome the human instinct. And this is disproportionately something the junior folks that are just learning tend to try and think of things this way, but you can teach people out of it or maybe give them this leeway when they’re just starting out and then kind of break them up the habit, which is to try and get people out of thinking of processes or tools as the one right way that, “Okay, oh now I figured out the software development methodology is you should have daily standups that are exactly this many minutes long and then you have exactly this many people and then you do exactly this process for prioritizing the backlog and you have the clients that are exactly quarterly.” Or whatever it is. But instead teach people a set of tools that accomplish goals and try to equip them with enough understanding of those tools, strengths, and weaknesses that then they can go apply them to problems that they see. So we have kanban boards, right? No, nobody’s mad at kanban boards the way some people are mad at Scrum, right? Because kanban boards were never, you have to, well I’m sure there’s some people who have a book that says you have to run your entire company on and here’s 10,000 things about how process you need to use around kanban boards. But a lot of people just learn, oh okay, yeah, here’s a way to organize our work and that it’s helpful. It’s a tool you can use in certain contexts and then people use it or they don’t and then that’s like we’re all better off knowing about this tool.

Shawn: I a hundred percent agree. I mean, I think the key thing, and I try to do this a lot with my team is even at Khan Academy, we have a defined end to end process to go from idea to something shipped in production, but really that it’s kind of a skeleton of a process. It’s not a rule set. You don’t have to follow every single part of this process. A lot of it is still ambiguous. We’re not going to define everything because there’s no way that we’re going to come up with a perfect process that makes sense for every team’s needs. I think it’s really about coming up with a structure that your whole team can maybe start with, but don’t be dogmatic with any sort of process in particular. Kind of explain these are really just guidelines. And I think something that I really try to do and model is every sprint retrospective and every project retrospective, my goal is to talk to the team about what works well and what can be improved. Because our process should be treated no differently than any product that you’re building. We should fix it in an agile fashion. Because what’s going to work for team A might be different from team B. And so team should still have the autonomy to make decisions as long as they’re staying maybe within the structure of how can we tweak things here and there. Something that’s really important to me as a leader is really building trust within my teams. I’ve seen retrospectives go really horribly where you have a retrospective and nobody’s really voicing their opinion. And often I find that that’s because when people won’t voice their opinion because of the fact that in the past when they voiced their opinion and they’ve made a suggestion, it hasn’t gone anywhere. So my kind of dedication to the team is always, if we as a team agree this is something we want to do or try, we shouldn’t argue about every little detail. Sometimes you should just experiment. I commit as the manager to making sure that we’ll follow up. And so I will often do a project retrospective where we come up with 20 action items and then I keep them updated every month in my staff meeting, like, “Hey, this is how we’re doing on those retrospective action items.” Because when people actually see that their concerns or suggestions that they’re heard and that they actually provide value, that they actually might be act on, they’re so much more likely to speak up in future meetings.

Allen: It builds trust in the process and of team, right?

Shawn: Exactly. Yeah.

Allen: Which is something you and I like to talk about is, I know that there’s not mentioning any names, but people out there in the world that run companies are not particularly concerned about the trust of their team. But it’s something that you and I both, I think a little bit, not call hobby horses, but to go back to a little bit about how can we build our processes or refine things or, I don’t know, is there any other things that you’d like to go to in terms of building or maintaining the trust on your team with this kind of stuff?

Shawn: One of the trickiest things as a manager to start out is you’re realizing you have this new position and maybe there’s certain things that you have to start keeping confidential, right? You’re finding about information, maybe it’s things about performance issues with somebody, or maybe somebody’s getting promoted or you have to deal with these tricky things around salary and everything. And there was a situation where somebody else on my team was promoted. There were certain things in going on in relation to that that were obviously confidential between me and that person that had mentioned it to somebody else. And so that person asked me a question kind of semi-directly about it, but because I felt like, ooh, this is confidential stuff, I’m going to pretend I don’t even know what this person is talking about. So I was like, oh, I’m not sure what you’re talking about. And that immediately broke trust with that person. What I learned from that experience after this person and I ended up patching it up. But what I really learned from that is I think what’s important is trying to be as transparent about everything that you can and then also be transparent about what you’re not able to be transparent about. So it’s in that scenario, what I should have said was like, “Yep, no, there is something going on. Clearly you caught wind of it, but that is between me and that person. So unfortunately maybe you’re talking to that person, but I can’t provide any details.” And that I’m sure would’ve gone a long way. It’s just like, okay, this person isn’t giving me the runaround and I wasn’t trying to give that person the runaround. It was just like, I didn’t know how to deal with situations like that. Because people talk about this a lot, going into being a manager is almost like 180 degree career shift. No one taught me how to be a manager when I went to computer science school, learning how to do data structures and algorithms. So a lot of these things are things you unfortunately end up learning on your own. Sometimes you can learn them through, I don’t know, books or podcasts or having a mentor or coach, but you’re going to also just make these mistakes yourself.

Allen: No, I like that. And then confidentiality is something that I think often gets learned, even if you got some training. Our mentorship as a manager, normally it’s around the routine things. And so then confidentiality, most organizations, at least the ones that I’ve worked in, try to be as transparent as we can, minimize the amount of confidential information. If it doesn’t need to be confidential, let’s try to be open about it. And so then sometimes it just sneaks in because of a little potential if something comes in where this promotion is being discussed, but it hasn’t been announced yet. And so that’s stuff you’re disproportionately likely to have had any training on. So I like that kind of mental model of be as open as you can, including being open about what you’re not allowed to be or you’re not able to be open about. One little habit that I’ve developed around that is getting the practice at, if somebody asks a question that I can’t answer, which is relatively rare, but sometimes it comes up, then being able to say, “Well, I can’t talk about a specific employee’s promotions or whatever. But if you’re curious or if it’s helpful, I could talk a bit about how we think about promotions in general.” We can’t talk about Steve, but when we’re doing promotions, this is what we tend to look for and here’s this document that’s public and that talks actually about our promotion process. And in general we would be following this process and then maybe you can go read this document and then maybe answer your question yourself, but I can’t tell you anything about this particular thing. So I find that to be a useful tool in the toolbox.

Shawn: Yeah, no, I love that. I mean, I think what you’re kind of getting to is, well, when someone asks you a question, maybe it’s specifically about someone else’s situation. It’s not because they necessarily so much care about that situation. It’s more about they’re thinking, well how does that impact me or in relation to me? And so how can we center it back around your growth, your career development?

Allen: Not to be cynical, but 95% of the time it really comes back to me when someone’s asking a question. And so if they’re asking a question then you’re like, oh, I can’t answer that. Then if you just ask, “Okay, you tell me a little bit more why you’re curious about that.” And they’re like, “Oh yeah, I’m just wondering, is my job safe?” And it’s like, “Oh God, yes. You’re amazing. You’re going to be here as long as you’ll stay because we love you.” And it’s like, oh, okay great. And that’s the thing that they are actually asking about, but then they don’t ask the thing directly.

Shawn: It’s always about getting to really the root of the thing that the person is asking. It might feel like something at the surface level, but when you dig one layer deeper, you can get to the heart of the matter.

Allen: That’s why we have recurring one on ones with a whole bunch of boiler plate questions and keep giving them space to do that. Otherwise that stuff just gets glossed over.

Shawn: I think one on ones are another area for me of building trust in that I try to really keep to one on ones. I find them to be my most important meetings. I try to make those to be the last calendar events I would cancel, just so people kind of have the sense that they can always rely on, I always have this time with Shawn every single week to raise issues, bring up concerns.

Allen: Yeah, I try to say they can cancel it, but I try not to myself. If the report is canceling it because they’re like, oh, I really want to try and accomplish this thing today or whatever. Then as long as they’re not feeling any pressure to do it, then it’s just like, yeah, it’s your one on one, so spend the time how you want.

Shawn: Exactly. It’s theirs. Yeah, that’s the key thing.

Allen: Well, thank you so much, Shawn. It’s been great having you on. Where can people go to learn more about you and your work?

Shawn: My org is Khan Academy, so you can head to khanacademy.org. If folks who don’t even know what Khan Academy is, we’re a company building a free world class education for anyone, anywhere. And to find me, I really actually need to work on my portfolio. I got rid of my website a long time ago, but.

Allen: You have a Twitter account?

Shawn: I have a Twitter.

Allen: Or maybe now is not the time to be promoting Twitter, but Mastodon?

Shawn: I did just sign up for Mastodon, yeah. You can also follow me or add me on LinkedIn. I guess the things that I’m really excited about right now are both the stuff we’re doing at Khan and I’ve also been just getting involved. I just recently got promoted to, or not promoted, elected as a member of a company called Modo Car Share Co-Op, elected by the members, so that’s something I’m involved in right now. And then also helping at a local education company called Ethos Labs. So just have my hands in a few things.

Allen: Awesome. Well, we’ll get links to those in the show notes. Thank you and so much, Shawn. It Shipped That Way is brought to you by Steamclock Software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steamclock. That’s it for today. You can give us feedback or rate the show by going to itshipped.fm or @itshippedfm on Twitter. Until next time, keep shipping.