About This Episode
In this week’s episode of Full Stack Leader we’re talking with Paul Gebheim of Dapper Labs. Paul has played an instrumental part in developing some incredible technology over the span of his career. Primarily focused on blockchain development, Paul an his team are creating amazing experiences and developing on the brink of what we know is possible with Web 3. His insight gives us a look into the world of a Web 3 developer and the challenges of leading teams through uncharted digital territory.
Paul’sTop 5 Leadership Tips:
Below is a summary of the Top 5 Leadership tips shared during the interview this week. Take a listen to the episode to learn more about the thoughts behind these tips –
- Work Is About Connections, Deliverables, Or Outcomes
- How You Feel About Your Work Matters
- Being Vulnerable As A Leader
- Say Hard Truths Early On
- Don’t Run Boring Meetings
We hope you enjoy the episode. You can find even more Full Stack Leader episodes here:
https://www.wondermentapps.com/fullstackleader/
Show Transcript:
Ryan: Hello everyone. And welcome to this week’s episode of the full-stack leader. This week, we’re here with engineering leader, Paul Gebheim. I’ve had a chance to work with Paul over the last couple of years on a number of different projects. And he’s got some exciting capabilities, especially in the new world of blockchain. Welcome,
Paul: Paul. hi. Nice to be here.
Ryan: Awesome. Nice to have you, maybe tell us a little bit about what you’ve done in the past. What got you to this point?
Paul: now so much has gotten me to this point. I mean, I was thinking about this when people were coming here and I was like, when did I actually start programming? You know, I started programming when I was 12. I realized this, because I wanted to put a guest book on my green day and Nirvana fan. So that was really my introduction. I was writing Perl for CGI scripts for the web and, in a weird way, I think the path of my career has been. An extension of that, like the vast majority of what I’ve done has somehow come down to the same basic tools of, reading some texts from somewhere, transforming it in some way, writing it to a file or a database reading it back later. So I think in a lot of ways my tech world started with Pearl when I was 12. And what. I ended up doing for me as a kid was that I felt like a certain form of empowerment with technology and with my ability to build things with my ability to make things happen. And I think I felt that that was something that other people didn’t really understand or have, but I knew that I felt good about being able to do those things. I actually remember one of my first, programs that I wrote that put graphics on a screen. I showed to my dad and it was just like a circle that, moved across the black screen. And I was really proud of it, cause I had made this thing work and his response was, what does it do? And I was like, well, that’s what it does, and so there’s something here , about. For me with working with technology it’s I have an internal sense of joy. I’m making things work. You know, after that I worked at, a lot of places where that was really, my job, from my first job was running a actual database engine. Uh, like my first professional job was running a database engine, worked
Ryan: on justifiably and probably a continued conversation with the business teams about what does that. It seems like a common discussion point between business
Paul: and tech. Oh geez. What does it do if we could just come to that decision once and for all, and on many things that it would make sense, but the reality is these things are conversation. You know, so I, I worked there, we worked, I worked at a company called Justin TV for a long time. You might know them as Twitch now. did that, I worked on, a lot of web projects and kind of what I found, as I entered this, like later part of my career here, and I’ve been working in the Ethereum ecosystem for the last four years, is that the reality is, I was more interested in having a larger lever and being able to get more done than I could as an individual contributor. These questions of what do we build are often more important than how do we build it because the, how do we build it as something that, generally can be accomplished? We know this, , we have turning machines, but what do we build is really hard and trying to map have people. Worked through that process has been, something which is, much more at this stage of my career. More interesting. Right. The problem has moved from how do I make something work to, how do I have a group of people? Make something work. And, honestly it’s been a very humbling experience, but one that I’m, still currently getting a lot of joy out of
Ryan: And are they working on the right thing?
Right. That’s another big part of that.
Paul: They’re never working on the right thing right now. Um, it does seem like that sometimes that doesn’t it. I don’t know when you’re, when you’re looking at these projects, do you ever just to risk a, how did we get here? Like where. What sort of turns did we take?
Ryan: They always have a journey to them. That is for sure. Yeah, for sure. Just have to pick and choose. It’s the choose your own adventure of, tinkering with all kinds of technology, and I th I think that’s a big part of the leadership and it is like actually discerning how do I guide the teams towards the right thing?
Paul: Indeed. And, it’s been a hard road, honestly, for me is figuring out how I even know if I’m driving toward the right thing. And I don’t know, I was making some notes here before this. And one of my first thoughts on this topic was that like, just building on the edge of reality. , and building on the edge of reality is hard for a lot of reasons. One is because the, maybe the technology is unknown or the product space is unknown, but also because like just what you’re going to go through while actually trying to create this thing is.
Unknown. And
Ryan: Even how to measure it’s unknown.
Paul: And a lot of it did it, did it, does it work? Like how do we even know that? You know? And so the leadership role in there becomes interesting because it requires a certain. Desire to look into yourself and understand what your own motivations are, understand how you know, things, like epistemological questions, uh, how do you know things? How do you know that this thing is right? And then to be able to communicate that to a group of people and have them feel inspired and motivated to keep on. So yeah, I think that this is like one of the major things that’s very difficult right now for people in the crypto world, because although it sounds like you’re, it looks like , from the outside that, oh, there’s all this activity. And all this stuff is figured out. The reality is most of it’s very young and almost every project that starts has no idea if what they’re going to build with. and in a very existential way, not just like a, can we execute it, but is it even possible?
Ryan: So what I was going to say to one of the questions that I see is like, how does it fit in, that even in the big puzzle of that space,
Paul: Great. How does it fit into the space? Will people want that? Will there be. Will the government make some decision three years from now that makes the last three years of my life no longer legally viable will. Which is a big risk
Ryan: What it could be. Cause because the idea of tech leadership often comes down to thinking about okay, do we have good project management system in place? Do we have good code repository and check-in process and review? In past episodes that I’ve talked about, include security. They include like kind of deeper level team resources, the organization, but in this particular one, You’re really exploring completely new grounds in a world that where a lot of money is at play. So I imagined the legality and the processes in it are very tricky leader.
Paul: They’re very tricky. I think it like with my most recent project, so I’ve been working at, , auger for the last four years. Recent. switch jobs. I’m not working at dapper labs, which is the company that makes the flow blockchain and has made NBA top shots, which people have heard of. And one of the real difficulties with that for years was that. When I entered, I thought, Hey, this is going to be really cool technology. And I’m going to be able to build really cool things. And all this stuff is going to be unlocked and work. And I was thinking about it, from the perspective of how do we build a piece of software, but the actual problems that we encountered through it were rarely software problems. And a lot of them do end up being these legal questions. And how do we navigate that in such a way that users that want to use , these projects still get a good user experience? Or how do we, communicate engineering priorities to an open community of participants. When there are these kinds of, legal regulatory concerns. there’s really easy examples of this as every single project on, in the crypto space that you see right now, since 2016, there’s just been this obvious, Hey, let’s just launch a token, right. This idea that I can just use it, the ICO, , an auger. We were the first, you know, arguable ICO. And. There was this concept like, oh, like at any time I can just create this new financial thing this token and I can use it. But what we discovered over the years is that there’s been a lot of legal scrutiny around how token launches are done. There’s a lot of gray area right now in what it even means if you do that. And there’s very little guidance. So. I found that a large part of my job ended up being, having these conversations and finding out what do we know is in a certain legal, gray area, what do we know is on a certain side of risk and how can we continue to move forward anyway, like how do we move through this?
Ryan: Yeah, it’s an interesting spot kind of challenging the way we look at centralized versus decentralized, but it’s also looking at the way that we look at centralized versus decentralized investment. And I think those two things run in parallel with each other and the decentralization of the technology is wildly tricky. But then similarly on the investment side, you’re pushing the grounds of pushing the edge of what has historically been very heated by the sec. , and having, that style of investment happening. So it’s interesting to see it push these edges and how much it’s going to be accepted.
Paul: Yeah. And so there’s just, there’s a lot of boundary pushing happening there, right? We’ve made new programming languages. So we had to make new tools for those programming languages. One of the funny things about the Ethereum ecosystem, which I’ve been building in for years now is when we started, there were no tools, like not at all. And so there’s like just a discomfort from starting a new, but at the same time, there was no regulations. There was no precedent for how these things were gonna get. And I think this is a place where people, think that they want complete and utter freedom and they want like Greenfield, but man, is that scary, just to be sitting there and think, okay, we don’t know how this is going to go on.
How do I make those decisions? And
Ryan: yeah, I think that that’s a really important question. How do you lead through that particular scenario?
Paul: Yeah, I think for me, what I’ve really been coming to is that leadership is this very internal process. And there’s a way that I’ve had to learn how to trust my own internal. Intuitions and feelings and a bit of a softer side of the world. when you’re navigating questions of how you put something brand new into the world, where there’s not a lot of information about how it’s going to go, it’s a lot less about the processes and the numbers. And it’s a lot more about how comfortable. Is everybody that’s building this with it going forward. How [ do we think it’s going to work? I have a really great example. So. Otter is this decentralized prediction market. It has one major feature, which is that it allowed users to report on a true fact about the world and say what they believed the truth was, this is a very difficult problem. It’s called the Oracle problem. How do we know that the information that somebody says happened to the outside world actually is true. And yeah, that’s a good one. So arguable, this very complicated solution to it uses, game theory, economic theory in order to manage it. And as a part of that whole set of theory, we wrote a paper on it and there’s a number of various variables that you can tweak in the system in order to create. Generate some sort of security threshold where you believe that the true outcome will actually be written to the blockchain. And the part of this that really, has always stood out to me is that this system works assuming a lot of things. And there’s so many assumptions that are built into how. The security models of these systems are built, that even, if you look at it and you say, okay, given these assumptions, we know it’s secure. You still need to make the gut check of whether you agree with those assumptions. And that’s a little different than in the kind of web two world I was in. Right, right. Yep. Because the security there didn’t depend upon, economic factors, security. There depends upon the execution of a team, properly securing a server. But here it’s relying upon the actions of a large group of people and having it be that you designed your system to properly take into account how those people will act.
Ryan: well I think it’s, I think it’s interesting because in the web two world, there was a lot of. Yes. And there’s a number of companies that took that challenge on and embedded it into the central part of services. So a lot of other people didn’t really have to worry about the compliance element, right. And you can just buy into those services. You have PCI compliant, transactions at this point. And it’s. , but that’s not the case in blockchain, the stuff that’s being done here.
It doesn’t have that kind of regulation around it,
Paul: yeah, I think that’s one of the things that we’ve started to see change yeah, as more and more players are entering that world, There’s just more tools. There’s more ways that, that artists, that starting to exist. So that’s starting to pick up and we’re right now at the edge of where, like a normal web two developer might be able to pick these things up and kind of build while staying within their same mental. It’s not totally true yet. One of the things that I have been reminding the engineering organization at the opera is that as we hire more web to native developers, there’s actually quite a lot of change in how to think that needs to happen. But it’s getting closer, right? It’s getting closer to this world where somebody with an old model can come and actually map it onto this.
Ryan: I love the way you describe it as the web mental model, because it really is like a way of thinking around development and around the creation of things. that’s running across most of the consumer environment, but then when you get into these kind of different, different segmented worlds, especially what we’re calling web three, now you really have to do look. You have to look at it a different way and you have to take those same engineers and get them to see that must be.
Paul: It is hard. And the example that I have here is that where we’ve ended up in web two is that the model is a lot about what we call on a financial system, rent seeking. How can I set up my system so that I am the biggest beneficiary of what’s happening on. And that business mindset has like direct impacts on how you develop systems. it has impacts on how you do access control. It has impacts on how you allocate resources. It has impacts on how much you think about things like moderation and how communities actually organize them. If you’re set up for resource extraction, you want to make sure that everything is alignment. So is in alignment so that everywhere down the line of your product and everywhere in your tech stack, you can measure the things you need to measure to extract the money and that people are going through the process where the most money is made. This is the Facebook problem, right? This is how that optimization. Went through world, as, at least as it stands down was very different because you’re flipping this on its head and you’re building from a, the core principle being that the assets and, resources that are represented on this blockchain are. Usable by the users outside of your application, you need to find a way to provide values to users without just capturing them without just having it be that they purchased through you.
And now they will never, now they will never move. And so the thing that you need to build is actually very different. It’s I think the it’s encapsulated best by platforms, not product. Right. Like, yeah, it makes sense. And that’s a, it’s really tricky. Of it, I think everybody that’s been, everybody that’s developing right now, basically grew up in a world where it was. The major driving force was centralization. The major driving force is rent seeking by large corporations. And the major driving force is like protectionist behaviors, in order to ensure that those things occur and, turning that on a Ted and having a public, interaction, having everything that you do be visible, is really a big mental.
Ryan: Yeah. And even in the description of it, it has all these kinds of nuanced undertones as to the difference. I think what you just said between product and platform, what is the nuanced difference within that? And understanding that is kind of looking at this new paradigm. And I think people even getting into this like very seasoned technologists that I know they’ve run into challenges, even comprehending these ideas.
Paul: Yeah. I agree. One of the engineers I’m working with at my current job who is very seasoned security engineer, but somewhat new to two blockchains. We were talking about, you know, a certain security model and. He was like, it’s so weird. Not just being able to know that nobody can get into the server, right? Like security model, like, so at flow, we’re building a blockchain, right? And the security model of building a blockchain is that people are in the blockchain trying to harm you. They are trying to be bad actors and the chain needs to work. Right. So you’re assuming bad actors instead of assuming everybody’s good. And there’s like an access control layer that keeps the bad.
Ryan: how do you, like, how do you actually, on the leadership front though, this is a good topic and you talk to the security guy, how do you like get people to shift into this mindset and begin to see that? Like, how have you guided people into that in the
Paul: past? I think it’s a light process of discussion. There’s a lot of having to be very right in mind, knowing of what that thing is. And just consistently, slowly, gently pointing out where the mindset is different. when they say the thing. Being like, Hey, actually in this world that has to work differently because X, Y, and Z, and just doing the reminders, most engineers are actually really quite good at picking up new systems. That’s one of the core skills of an engineer is being frustrated and picking up a new system, but you need enough reminders. I found that I need to be. A lot ahead. This is actually, uh, uh, one thing with this kind of blockchain leadership right now is like you, you have to be pretty far ahead of where the actual builders are. Or else he can’t direct them. This isn’t the world where everything you’ve done has been done 15 times and everybody knows the solutions and you’re mostly just making sure that they’re doing it. It’s the world of, being able to introduce concepts to them over time. So this is one-on-ones lots of conversation. One of the, one of the main things here is that. Especially in this remote world is how do you actually create is just ensuring that you’re creating enough time for conversation, that you’re actually talking to everybody that people like each other enough, that those conversations feel good. Because you are kind of going to warrior con you’re going to war with knowledge. You have to go and learn something brand new. So you can’t just be on autopilot. In this particular case with this engineer, we talked about it and I said, oh yeah, but this needs to be different. He was like, oh, that’s right. Like he knew it right away and was able to switch into that mindset. But he did need the reminder.
Ryan: Yeah, going to war. Had you just put that, going to war with knowledge base or going to go into
Paul: war with knowledge, with your own knowledge, right. With your own knowledge base yet. Right. How do I shift? How do I change? It’s an old, what’s the, what do they call that? In management theory, change management. But it’s change management within yourself. , how do I like make myself think differently? And what does that do to me as a human? I’ve actually changed drastically in the process of understanding how to build these financially secure systems.
Ryan: Yeah, it’s almost like the, it’s interesting in our industry in particular, you are in a constant state of looking for disruption. And then oftentimes the biggest disruption is in the way that you’re thinking, because that the state of consistency, that your perception of how to do something is limits your ability to innovate. So you have to keep disrupting that thought process and keep disrupting from the.
Paul: As you , do you have to, I think it just all comes down to you first. This is a very strange, or maybe it’s a very Western thing to say, but my perspective, at least within the current engineering organizations, how do I say this? Maybe it’s something close to like the product as a reflection of the people that build it. So if you, as a leader and thus your team don’t feel aligned with the goals of the thing you want to build, if they don’t actually believe that’s going to work, then the product will feel that way. It’ll feel like it was built by a team that wasn’t aligned. It’ll be weird. They’ll be strange cases because yeah. Something like the product is the outcome of the team of the, of the team becoming aligned on who they are and what they’re building.
Ryan: As a tech leader in the often challenging field of blockchain, Paul reminds us that it’s incredibly helpful to have an internal sense of joy for making things work. The idea that technology is still very much a playground can help cultivate both innovation and sustainability. More importantly, it can help provide the intangible glue for a team that is creating things on the edge of reality. And Paul reminds us that a leader should be helping guide teams through the unknowns of complicated concepts, like web three decentralization, but it’s the ability to tap into a deeper sense of knowing the direction that can help facilitate the true innovation and success in forward thinking tech environment.
All right. Welcome back, that was an amazing look at a very complex subject areas. We appreciate you giving us some perspective on, how you think about developing from the inside and bringing that out into these really innovative cities.
Paul: Thank you very much. It made me think more. I feel like, I feel like maybe I should write some of these thoughts down, sir.
Ryan: You should at least have written five top tips that you want to share with everybody. Awesome. So we’re going to do your five top leadership tips now and, I’m excited to hear these, so what’s number one.
Paul: Okay. So number one for me is that work is about connections and deliverables our outcomes. I guess this is kind of what I said at the end of the last segment there too. Right. My first one and the reason I think this is important is that I’ve jumped on countless meetings where the manager, gets on that call. And the first thing they do is, what’s everybody’s task list. Did everything get done? Okay. Thanks. Bye. And. If that’s the way that you’re approaching, your team, then they’re only going to be trying to show you outcomes. But so much of software development is like writing a novel together. It’s not the outcomes, it’s the questions. It’s the, how do I do it? How did I get there? That really matters. So I think the major thing to focus on is fostering a sense of connection, within.
Ryan: Great. That’s amazing. it’s just a great way to look at it it’s not really about the outcomes of any individual chapter or summary of the book, but it’s really about the entire novel and creating it. And how do you ask those questions to get there? It’s pretty impactful because it opens up a different way to look at managing people in general.
Paul: It’s like, if you’ve organized the people right, then the software will produce it.
Ryan: Yeah, , that’s a really good look. Okay. Let’s jump in. What’s number two
Paul: for you. Number two for me is how you feel matters. And this one’s really tricky, especially for software engineers that become managers. Feelings are a little bit hard for many people that end up in this industry, but the truth of the matter is that when you’re trying to make something that is good for an end-user. And you’re trying to communicate that to people on your team. The majority of what they’re picking up is not your work. It’s not your arguments, but it’s how you feel. Are you somebody that they actually want to listen to and to follow? Are they somebody that they trust to have their best interest in heart? And so, as a leader, the work is much about this internal job of feeling good about what you’re doing as it is about making the right checklist and having the right product plan in place with the right timelines.
Ryan: Yeah., it’s like the tone of the. Is as important as the words that are coming out of the mouth or more yeah, or more, and it’s true. It’s true. I mean, I think that it goes for every relationship is that 80%, , the energetics within it, really impact people’s willingness to, , put trust in you and follow you , and have passion
Paul: for the same thing.
Indeed. Agreed.
Ryan: All right. Awesome. Let’s look at number three.
Paul: Number three, be vulnerable, being vulnerable. It’s the worst one, right? Or the best one? I actually recently had this experience. I was personally just having some difficult times in my life and my relationship, my wife and I were trying to buy a house. It was really hard. I was really stressed and, I was just being ineffective for a few weeks in my job. And finally, one of my engineers reached out and he was like, what’s going on? And I told them the truth, I was like this, all this stuff is happening and it’s being really hard and it’s impacting my ability.
And his response was like, oh, that’s fine. We can help. But didn’t you tell us earlier and he just stepped right up. I love that. I love that, you know, like this idea that you’re alone in the world, that as the leader, you’re on top, that your title, you know, imbues you with some like set of magical capabilities or responsibilities. It’s just not true. The reality is that, if you fostered a good team, everybody’s going to be able to help. And the only way that they’ll know that you need it is by vulnerary.
Ryan: Yep. And that vulnerability really allows them to get to know you and create a tighter bond with you too. So even in moments of emergency, like the one you brought up, it makes sense. But also just going through the natural process of like, why is he giving me this task or why is taking us in this direction over here? And hopefully that vulnerability has said, Hey, I’m also, I have some fear around that, but we’re gonna try. Yeah,
Paul: exactly. Which is a more human process. It’s admitting the humanity behind what you’re doing. You know, we may be building robots, but we’re not robots.
Ryan: I love that. Okay. Number
Paul: four, say hard truths early, I think this is one. Probably shows up in every management book in some way or another, where they say , make sure you have regular meetings with your people, right?
Yep.
Ryan: The regular,
Paul: the regular meeting. Isn’t the important part. The important part is being able to say the truth, being able to say, Hey, it doesn’t feel like you really want to be working on this right now. Is that true? How can we change? , the meeting is a container, which gives you a chance to say these things, but you have to be able to say them. And in order to be able to say them, you have to have practiced vulnerability and you have to feel good. Like if you don’t feel good within yourself and you don’t have that, buy-in a vulnerability with the other person. It’s so much harder to say things which you feel are true that the other person needs.
Ryan: This is a hard spot, I think, for a lot of tech where you have, you have people who are often really skilled in their particular. Their particular skillset, how they’re they really know how to, to code, or they really know how to create, dev ops environments or, you know, whatever the case is, but like , the actual human communication of being able to vulnerably look, someone in the face and share maybe a hard truth or even share a great truth that’s not something that people are trained
Paul: For you. For sure. I mean, I have a high schooler right now and he’s taking lots of classes, none of those classes do they sit down across from each other and say you’re appreciated or that hurt my feelings. Um, but those, but that’s like the meat of what actually building things together.
Ryan: I love that. All right. And the last one, number five, bring it in, bring it home.
Paul: I’m number five. I’m going to bring it home with a very easy one, which is don’t run boring meetings. Ask interested questions. Meetings, especially in soft tech teams. Like there’s all this thought that, oh, our meetings are terrible and all they do is waste my time. If you can ask one interested question of every person that’s on that meeting, or at least one person, if you can actually show real connection and caring with a problem they’re having, or even something personal that’s happening. Oh, I saw you got a haircut, what, why did you choose that one? Anything like that can turn that meeting from being something that is a wasted piece of time into one where people become engaged.
Ryan: The connection within the meeting is almost as important as the content within the meeting.
Paul: 90% of it’s the connection. Right. We spend most of our time talking about how to get our microphones connected, not actual, like on the Tesla.
Ryan: Yeah. And I think once that connection happens, people are open to receive like the, and open. And that’s where the collaboration really kicks in. So suddenly we’re collaborating, it’s not a boring meeting. It’s actually a highly productive and environment.
Paul: Yeah. It’s more fun. Let’s have some fun, our meetings, Ryan and fun.
Ryan: Yeah. We had a fun, I want to have a lot more fun. We’re just going to keep doing that. And that doesn’t mean we’re going to the water slides every time, sometimes it, or whatever, crazy, like tech adventure that, your company. It means in the most mundane meetings, there’s still ways to have fun and still waste there is.
And, you know,
Paul: I have that, we used to have a once weekly like team meeting at Augur and the first half hour was like, check-ins from everybody and, updates on projects. And the last 10 minutes of every meeting was just, what’s something new and interesting. And. Somebody that found something new. Let’s talk about it. And there’s a lot in there too. Yeah. Right. , we were a small team. We all knew all the projects that like project update wasn’t super important, but man, was it fun to just, find out that somebody had, , found some new yield farming scheme or whatever to move into. And it taught me.
Ryan: All right. That’s amazing. This was such an insightful and awesome episode. It really made us look at how you lead within these very forward-looking and uncharted environments. , and you’ve done a fair amount of that over the course of time. We really appreciate your insight and your thoughts and, excited to have had you here today and as always as great talk to,
Paul: yeah, it was great talking to you, Ryan.
Thanks for having me.
Ryan: during his top five, Paul thoughtfully points out that software development is not about the outcomes, rather. It’s about the questions and those questions come up between restart. During this top five, Paul thoughtfully points out the software development is not about the outcomes, rather. It’s about the questions. And often those questions come up between you and the team you were working with. He reminds us that leading with a combination of vulnerability and direct honesty is a formula that always leads to constructive growth. No matter where someone is.