Summary:
Vibe coding can patch almost anything, but a duct-tape fix only holds until the water pressure changes. Amith Nagarajan and Mallory Mejias welcome Han-Shen (Han) Yuan, who built mobile at eBay and Netflix, led engineering at Upwork through its IPO, grew up alongside Amith in 1980s Silicon Valley, and is back at Berkeley earning a master's in data science. For association leaders weighing how much technical talent they need, they unpack where AI-built tools break down, explain why judgment under ambiguity still belongs to engineers, and challenge the assumption that every organization needs a full-time CTO. Han makes the case that the bigger gap may be product leadership, and he breaks down how tech companies use guilds, a one-thing-per-quarter rule, and an interview built around self-awareness, drive, and grit. He also argues that nobody has ever saved their way to prosperity and that AI's real return lies in growth.
🔎 Find Out More About Han-Shen (Han) Yuan:
LinkedIn ➔ https://www.linkedin.com/in/hanshenyuan
Post PC Labs ➔ https://www.postpclabs.com
Han's LinkedIn Post on AI and Software Engineers ➔ https://shorturl.at/7Coj0
Timestamps:
00:00 - Two Kids From 1980s Silicon Valley
06:50 - Vibe Coding and the Duct-Tape Fix
13:52 - Why AI Won't Replace Software Engineers
18:38 - Why AI Needs an Opinionated Codebase
23:33 - The Fractional CTO
30:19 - Why Product Leaders Matter
38:05 - Guilds vs. Committees
42:05 - How Han Hires for Grit
48:25 - Nobody Saves Their Way to Prosperity
👥Provide comprehensive AI education for your team
https://learn.sidecar.ai/teams
📅 Register for digitalNow 2026:
https://digitalnow.sidecar.ai/digitalnow
🤖 Join the AI Mastermind:
https://sidecar.ai/association-ai-mas...
🎀 Use code AIPOD50 for $50 off your Association AI Professional (AAiP) certification
📕 Download ‘Ascend 3rd Edition: Unlocking the Power of AI for Associations’ for FREE
🛠 AI Tools and Resources Mentioned in This Episode:
Claude ➔ https://claude.ai
Claude Code ➔ https://code.claude.com
Claude Fable ➔ https://www.anthropic.com/claude/fable
ChatGPT ➔ https://chatgpt.com
Gemini ➔ https://gemini.google.com
MemberJunction ➔ https://memberjunction.org
https://www.linkedin.com/company/sidecar-global
https://twitter.com/sidecarglobal
https://www.youtube.com/@SidecarSync
⚙️ Other Resources from Sidecar:
More about Your Hosts:
Amith Nagarajan is the Chairman of Blue Cypress 🔗 https://BlueCypress.io, a family of purpose-driven companies and proud practitioners of Conscious Capitalism. The Blue Cypress companies focus on helping associations, non-profits, and other purpose-driven organizations achieve long-term success. Amith is also an active early-stage investor in B2B SaaS companies. He’s had the good fortune of nearly three decades of success as an entrepreneur and enjoys helping others in their journey.
📣 Follow Amith on LinkedIn:
https://linkedin.com/amithnagarajan
Mallory Mejias is passionate about creating opportunities for association professionals to learn, grow, and better serve their members using artificial intelligence. She enjoys blending creativity and innovation to produce fresh, meaningful content for the association space.
📣 Follow Mallory on Linkedin:
https://linkedin.com/mallorymejias
🤖 Please note this transcript was generated using (you guessed it) AI, so please excuse any errors 🤖
[00:00:00:14 - 00:00:09:17]
Mallory
Welcome to the Sidecar Sync Podcast, your home for all things innovation, artificial intelligence and associations.
[00:00:09:17 - 00:02:21:09]
Mallory
Today I'm taking it back in time as we kick off this episode. So in the 1980s, two kids went to school together in Silicon Valley. One of those kids grew up to build software companies for associations and he now co hosts his podcast with me. The other kid grew up to build the mobile products at eBay and Netflix. And today, those two are coming back together again here on the Sidecar Sync podcast. Today's guest is Han Yuan. At eBay, Han helped turn mobile from a project inside an incubator into a platform doing billions of dollars in transactions up from hundreds of millions. And the iOS app his team built was demoed onstage by Steve Jobs. He went to Netflix to solve a problem people considered unsolvable, which was secure video playback on Android. And within three months, every Android user in the world could watch Netflix. He then spent four and a half years as SVP of engineering at Upwork and took the company through its IPO, where his team actually got smaller while revenue doubled. And right now, over 20 years into all of that, Han is back in school at Berkeley getting a master's in data science. His reasoning is the thread through this whole conversation. As AI takes over more of the execution, understanding how things actually work matters more, not less. In today's conversation, we get into the limits of vibe coding, explained with duct tape and a leaking pipe. Why what associations are missing may not be a technical leader at all, but a product leader. The interview technique he uses to hire engineers, and why he's never seen anybody save their way to prosperity. If you think about it, nearly all AI use cases that we see right now are about saving time or money. And Han's argument is that the real return is on the growth side. Everybody, please enjoy this conversation with Han Yuen.
[00:02:21:09 - 00:02:38:07]
Mallory
thank you so much for joining us on the Sidecar Sync podcast. In my research on your background, I saw companies like eBay, Netflix, Upwork. I'm curious if you could share a little bit about your background and kind of what has been the through line in your career thus far.
[00:02:38:07 - 00:02:43:10]
Han
First of all, it's awesome to be here. So thank you for having me. I've
[00:02:44:21 - 00:03:03:14]
Han
been in the industry for several decades. I'm kind of an incidental computer guy, just a kid that really loved computers when I was young. I don't have a computer science degree. I have a background in industrial engineering and operations research.
[00:03:04:19 - 00:03:15:23]
Han
But I did end up having a computer science minor that helped me essentially keep my GPA up. And I think in the ensuing decades, I've had
[00:03:17:12 - 00:03:34:04]
Han
an odd career. I spent 10 years in enterprise software. When mobile became big, I happened to be in the right place at the right time at two companies at eBay and Netflix. And then on the back half of my career, I went back to marketplaces,
[00:03:35:13 - 00:03:41:11]
Han
very focused on labor marketplaces in particular with Upwork. And since then,
[00:03:42:18 - 00:03:58:18]
Han
I continue a lot of my work in the digital space, usually at internet scale companies where I support both SaaS companies as well as typical D2C companies. Folks would generally consider to me to be a,
[00:03:59:19 - 00:04:03:11]
Han
I guess, internet scale software engineer.
[00:04:04:12 - 00:04:19:20]
Han
However, because of my unusual academic background, I typically code switch very well between both the engineering side as well as the business side. And so typical roles that I hold today involve running both product and engineering.
[00:04:21:10 - 00:04:27:12]
Mallory
Awesome. Amith, you know Han from a way back when, can you share with our listeners what the connection is there?
[00:04:27:12 - 00:04:44:16]
Amith
Yeah, we went to school together. So we were kids in California growing up in the 1980s. And we were growing up in Silicon Valley back when Apple was a fairly small company and there were fruit orchards fairly close to where we went to school. So that's how we know each other.
[00:04:46:02 - 00:04:56:16]
Mallory
I love that. Han, you said you had a minor in computer science when you were in college, but then looking at your LinkedIn, I saw, are you back in school now getting a master's in computer science? Is that right?
[00:04:56:16 - 00:05:41:14]
Han
I am getting a master's in data science. Wow. And yes, I am back in school. I am easily the oldest person in my cohort. And I went back to Berkeley. So I would effectively have three degrees whenever I finished this thing. I think a big reason for it, and I think maybe this is a good lead-in to maybe some of the things that we'll be discussing, is that I spent a lot of time managing people and I've been very grateful for my career and I've eventually moved up into very senior leadership positions. But what's really clear to me, especially as a technologist, is that we're at a time where
[00:05:43:13 - 00:06:02:21]
Han
the labor of management is being, in a lot of ways, being handled by AI because AI is such a great force multiplier when it comes to communication, that I think it puts a premium on professionals, like technologists, to get actually closer to the metal again, because
[00:06:03:22 - 00:06:07:19]
Han
you need to deeply understand how things work. And for me,
[00:06:09:00 - 00:06:38:07]
Han
I felt like now was the time to go back and effectively go back and it really retrained a little bit and make sure that I understand the fundamentals. With data science, which is really the foundation of modern day AI in a typical university data science program, we'll cover machine learning, generative AI, data engineering, data science, all those foundational topics around AI,
[00:06:39:14 - 00:06:45:22]
Han
I just thought it was something that was important for me. And plus, I'm just an incredibly curious person. So
[00:06:47:18 - 00:06:49:11]
Han
that's how I ended up back in school.
[00:06:50:24 - 00:06:54:01]
Amith
One thing I'll throw in there, I think it's super interesting because,
[00:06:55:04 - 00:07:16:23]
Amith
first of all, I totally agree with your intuition that getting closer to the technology makes a ton of sense, even for the most senior executives, even for those who don't necessarily have a background as technical as yours. And yet at the same time, it's actually the inverse of what I think the common is out there right now, where people are saying, "Well, code is free, you can get Claude to build anything, so who cares?"
[00:07:18:05 - 00:07:35:20]
Amith
And so I, for one, agree with the direction you're describing, but I'd love to have you talk a little bit about that perspective of the vibe coders out there thinking they can vibe code their way with current AI or AI even five years from now that's much better versus the perspective of getting closer to the metal, getting closer to the technology and understanding it better.
[00:07:36:22 - 00:07:41:05]
Han
You know, honestly, I don't know how vibe coding and where vibe coding is going to
[00:07:42:05 - 00:08:01:19]
Han
because I think if we spoke like last year, for example, we would be talking about vibe coding in the form of building little toys here and there that aren't very serious, but we could build like a webpage. And today, I think you look at companies like an Anthropic or
[00:08:03:00 - 00:08:08:00]
Han
even a Google, and they'll tell you that a significant amount of their production code
[00:08:09:02 - 00:08:20:10]
Han
sitting on hyperscale infrastructure is being automatically generated, is using automatically generated code, you know, effectively vibe coded. So,
[00:08:21:15 - 00:08:31:05]
Han
you know, the question is, you know, what actually breaks when a non-technical person tries to ship an AI-built tool? I think that is changing.
[00:08:32:12 - 00:08:35:17]
Han
But in practice, I would say the following.
[00:08:37:05 - 00:08:38:15]
Han
The first thing is that
[00:08:39:23 - 00:08:47:11]
Han
the way people vibe code today is usually through a single turn or multiple turns, and
[00:08:48:23 - 00:08:53:19]
Han
it's a human saying, this is what I want, or this is the problem that I have.
[00:08:54:20 - 00:09:20:22]
Han
And I think vibe coding is very good at answering that question. It is very good at solving that specific problem. And sometimes it will solve it in the most direct way. And the way I would describe it is, imagine if you had a leak in your house, like a pipe that happens to be leaking. One way to fix that leaking pipe is to go into your garage, get some duct tape, and then wrap it up, right?
[00:09:21:24 - 00:09:27:00]
Han
And that fix could very well get the job done for a very long time.
[00:09:28:05 - 00:10:02:00]
Han
The challenge that vibe coders are going to have is what happens when conditions change. What happens when you have more water pressure? Will your duct tape solution still hold? Or what happens if you want to remodel the house and you need a really, really different solution? And so those are the things that are not so straightforward. And an experienced engineer is going to have a perspective on how things change. And so typically what you'll find, you know, vibe coding or not is better have a sense of
[00:10:04:04 - 00:10:05:08]
Han
what the business needs,
[00:10:06:11 - 00:10:15:10]
Han
how things might change, and then how to design for that change. And you don't really get that out of the box when you basically say, "Hey, build me a to-do list app."
[00:10:16:12 - 00:11:22:12]
Amith
Yeah, that makes a ton of sense to me. I think even as AI models get smarter and smarter, I do think there's going to be tremendous value in knowing what's going on and having that understanding. Part of what we encourage here is to, you know, the curiosity to describe getting people to dig deep and go into a topic that isn't their, you know, their primary background in the past. So that's awesome that you're doing that with Berkeley. Well, you know, I would simply say one thing before Mallory takes the reins again and takes us down some other topics is that in my own experience with using a variety of these tools, whether it's, you know, Grok CLI or Google, you know, Google's Gemini or Cloud Code, obviously, it's exactly what you describe that you get a solution if you don't have a highly opinionated architecture that says, "This is how we want to build it." You get all sorts of interesting things. So creativity isn't a bug necessarily, but it's, you know, the duct tape solution is what you often get. So at some point, perhaps that changes, but I do think it's important for people to embrace the capability because it's quite magical that we have this at all, but to also understand kind of how it fits into the big picture.
[00:11:23:15 - 00:11:49:00]
Han
Yeah, and truthfully, I think because software is never perfect anyway, which is why we're always changing it and which is why we'd all get different versions with new features. I think understanding that I think is important because if you have something that requires quite a bit of change or is likely to suffer quite a bit of entropy over time, then you might need a different approach
[00:11:50:24 - 00:11:53:12]
Han
beyond just like a simple vibe code session.
[00:11:53:12 - 00:12:18:08]
Mallory
Oftentimes on this podcast, we hopefully try to empower our audience to even our non-technical audience to try out things like vibe coding, to empower them to believe they could build a prototype of something maybe that they want to roll out at their association. Amith, maybe this is more of a question for you, but should they be discouraged by what Han is saying where vibe coding could get you so far, but maybe don't be too confident in what you've created?
[00:12:18:08 - 00:13:51:01]
Amith
I don't think you should be discouraged at all. I think you need to frame it as a tool that's incredibly powerful for expressing your creativity. So as a business leader, up until basically very recently, last year or two, if you wanted to, first of all, build some type of an application, you'd have to go through really a classical software development lifecycle, which is requirements definition or a PRD and things like that, which is very, you know, it's a low fidelity way of expressing a concept. It doesn't really help you kind of iterate quickly or express creativity. And so as a business leader, in your mind, you might have an idea of how you want to solve a problem, but it takes a long time to get to something that you can actually relate to as a human, you know, from a user experience perspective or to see the flow of it. So the vibe coding, you can very quickly come up with something and even get something to kind of work. To Han's point, though, don't consider that done, right? You're still the role for taking that concept, almost think of it as like a new version of a requirements document, and then turn that into something that's production grade. And the other factor is, is even if you yourself don't wield the tool in your hand, knowing that these tools exist for professional developers should result in more software being available at a lower cost and, you know, faster timescales. We're seeing that 100 percent the case. So this benefits associations, even if the leaders that are listening to this podcast themselves do not necessarily use a ton of vibe coding tool. They should expect their partners, their vendors, their professional development staff if they have them to use these tools to accelerate progress.
[00:13:52:04 - 00:14:22:16]
Mallory
Han, Amith shared a post that you made on LinkedIn with me. That was actually what sparked the idea of bringing you on the podcast. And in that post, you highlighted a really insightful article basically arguing that AI would not replace software engineers. We kind of touched on that a little bit thus far with the fact that vibe coding can only get you so far. But I'm curious if you could speak to that, why you think AI would not replace software engineers and kind of what pieces are missing for now when so much of the execution can be handled by AI.
[00:14:22:16 - 00:14:30:12]
Han
You know, one of the sticky issues here is we probably just need to align on what is a software engineer. What
[00:14:31:13 - 00:14:32:05]
Han
do you think, Amith?
[00:14:32:05 - 00:15:03:11]
Amith
I think the software engineer, I think the way I define any job is what are the outcomes you create. So to me, that's functional, reliable, hopefully somewhat stylistic software or capabilities that can power a business, whatever that is. So to me, I'm paying software engineers to create those outcomes. The tools they use are less important to me. But I mean, since that's my background as well, I do care about that. From a business leader's perspective, I'm more focused on the outcomes.
[00:15:04:14 - 00:15:11:06]
Han
Isn't it interesting, though, that potentially a non-technical person could be a software engineer based on your description?
[00:15:11:06 - 00:15:27:14]
Amith
Totally. Yeah, I think that almost anyone can be a software engineer based on that description. I do think the term engineer is one that we have to kind of hold close and not necessarily guard it, but to think of it as maybe that next level of elevation to someone who can think beyond
[00:15:28:14 - 00:15:34:18]
Amith
just the basics. I'm not sure exactly how you define that. Classically, it's meant the person who's writing the code, I think. But
[00:15:35:19 - 00:15:50:15]
Amith
if that's not what we're doing, I mean, I myself have been writing code for I don't even know how long now, 40 years or something. And so and I love writing code. It's so much fun. But I enjoy using these AI tools to generate a lot of code, too. So I don't actually look at the code nearly as much as I used to.
[00:15:50:15 - 00:16:03:05]
Han
Yeah, I don't either. But I think here in probably lies the insight, which is there are probably things that you're doing when you're vibe coding that you do care about. But what would that be?
[00:16:03:05 - 00:17:24:13]
Amith
Well, for me, it's architecture. So what I care about, well, I care about the business outcomes, obviously, clearly, I want to make sure that what we're building is really well thought out, that it's not just solving a point problem, but thinking about the pattern. So I've always looked at it and said, look, we need a widget to do checkout to pay for this product. That's great. But let's think about the overall pattern and think about other places down the road where we might have similar needs. An association, for example, may say, hey, we're rolling out a new membership category. So let's build the functionality to support that. That's great. But how about what about other future membership categories that might have different entitlements associated with them or different features that members benefit from? So I think thinking slightly abstractly at times is important. And that is not something that AI systems will do automatically unless you push them for actually, us humans typically don't do that, right? If we hire a typical software engineer and say, hey, build a widget that has any membership category, that is exactly what you'll get. And when you want the next membership category, you pay for another one. I've always looked at it and said, how can we build kind of something that has at least one degree of of interaction there? So that's one piece. And the other part for me that's really important is architecture. I want to make sure that we have something that is super resilient, that's somewhat self-healing, robust scales, you know, as a lot of safety guardrails from AI perspective, obviously as a secure infrastructure. So those are the kinds of things I think about.
[00:17:24:13 - 00:17:29:07]
Han
Yeah, that makes sense. I totally agree with you. I
[00:17:30:12 - 00:17:40:03]
Han
feel like the reason that you need software engineers, and maybe this is incredibly reductive, is that a lot of times there are no right answers.
[00:17:42:01 - 00:17:43:10]
Han
But it's the
[00:17:44:21 - 00:17:51:20]
Han
way you navigate the ambiguity of running a business where there are no right answers looking into the future
[00:17:53:00 - 00:18:21:03]
Han
that require, you know, like software engineers who have seen a variety of different scenarios and have figured out, hey, if I do things this way and the business goes this way, then this is going to work anymore and I might need to ever rewrite it or redo it. And so there's a certain amount of judgment involved in terms of how the software evolves in light of ambiguity that I think
[00:18:22:10 - 00:18:38:18]
Han
AI today is not particularly good at solving that problem. It's really good at giving you answers when there probably is a right answer. It's not really good at helping you out when there are no clear answers or there are hard decisions to be made.
[00:18:38:18 - 00:19:59:11]
Amith
Yeah, I think that's right. And generally speaking, AI works in the context that you frame, just like you hire employees and you train them. Obviously, you have to have a certain raw capability set as a starting point, but then you train them to think a certain way. And AI models tend to work that way, certainly in these agent harnesses that have memories and access to, you know, lots of repositories of code and things like that. And what we find with our framework product, Member Junction, is a general purpose abstracted kind of framework for doing agentic AI and for doing, you know, data ingestion and building apps and all sorts of other things that we do with our clients in this market. So it's not an app that does a particular thing. It's a framework that does anything. And so when we get a higher grade model, like a Cloud Fable or even like, you know, Grok 4.6 or something like that, working against that code base, it actually does think the way you're describing where it starts to think in general patterns and abstractions. But that's because it's sitting on top of 10 million lines of code that work that way. But generally speaking, that's not how most people develop things. I think you end up with, you know, this explosion of single purpose widgets is a lot of what you get with vibe coding. And that's deeply concerning because then you have no matter how powerful they are, it's enormous tech debt, it's more cybersecurity attack vectors, it's all the other issues that I think people are worrying about.
[00:20:00:12 - 00:20:09:00]
Amith
And I think that my message continues to be for this market that this is extraordinary and this is going to be incredibly valuable for businesses. But you also have to be thoughtful about it.
[00:20:09:00 - 00:20:23:07]
Han
And therein lies, I think, some of the opportunity that you described because, you know, to your point, frameworks typically have opinions embedded in that. That again requires, you know, quite a bit of software engineering.
[00:20:23:07 - 00:20:25:22]
Amith
Yeah, totally. Having a strong point of view.
[00:20:27:07 - 00:21:20:13]
Amith
I mean, really good engineers come with those too, right? I think most of the engineers, you know, probably have pretty strong opinions. And so frameworks tend to reflect the opinions of their creators. And that tends to be helpful actually in building software because it may not be everybody's preference, but it is a way of doing it. And it could be there are many good ways of doing lots of things. But having a strong opinion and an approach to it is important. And that is, of course, another challenge with vibe coding when you don't have the types of talent that you're describing on is that you end up with lots of different varieties and flavors. You get the cornucopia of this basket of different approaches to software with different back ends and, you know, different coding languages and different network protocols and different off systems and all sorts of god awful things. And then over time, there's, you know, the solution that is, well, I don't want to break something, so I'm going to build another layer on top of it. And then, you know, with all sorts of interesting problems with that.
[00:21:20:13 - 00:21:43:02]
Han
There's a certain irony to all of this because I think all of us enjoy interacting with these agents because they're so agreeable. But the truth of the matter is that you need that disagreeability, the opinions in order to make something actually real and scale. And I think that's sort of an ironic limitation of AI itself.
[00:21:43:02 - 00:22:34:19]
Mallory
Yeah, I know Amith often has AI take the counterpoint to try to shred his ideas to pieces, but even so, it's always good to have that a different perspective on what you're working on. I would say many associations do not have a CTO on staff. Maybe they never will. They don't have someone like you on their team. And so maybe this is a question for both of you. But I'm curious what if a small organization, a nonprofit came to you, said we don't have a CTO, but we're looking for the minimum level of technical expertise on our team that we need to be able to really implement artificial intelligence across our organization. How would you speak to an organization like that? Is it having one good software engineer on your team? What do you how can you think about the level of technical expertise needed to go after this technology successfully?
[00:22:34:19 - 00:22:46:04]
Han
I think this question is really a question of scale, because even if you look at traditional software companies, when they have a CTO,
[00:22:48:00 - 00:22:54:06]
Han
that job is very different depending on if you have 10 people, 10 people, 20 people, so on and so forth.
[00:22:55:08 - 00:23:00:15]
Han
And so I think depending on the scale, there's that angle. There's also a question of the
[00:23:01:17 - 00:23:23:21]
Han
the core job to be done. Are you building software internally to make your internal operations just work more smoothly? Or are you building customer facing or member facing software that happens at and so there are these different dimensions to ultimately kind of think through.
[00:23:25:19 - 00:23:46:02]
Han
I would say that in a lot of cases, and I've spent some time doing some consulting on the side, I do a lot of fractional work is that what CTOs won't tell you is that in a lot of cases, that CTO job is candidly not a full time job.
[00:23:48:20 - 00:23:49:08]
Han
I
[00:23:50:09 - 00:24:00:15]
Han
took on a role like I would say last year where I told the client like this is not a full time job. They didn't really believe me. I signed up for 50 percent.
[00:24:01:17 - 00:24:19:16]
Han
And then later on, I cut my hours to 25 percent and it was still just fine. And the reason is because the job at somebody at the CTO level is really about the advice and that that's not a 40 hour job,
[00:24:20:17 - 00:24:23:06]
Han
a 40 hour a week job for most cases.
[00:24:23:06 - 00:24:31:01]
Mallory
Ameth, what's your take on that level of technical expertise and association should have or maybe should find from an external partner?
[00:24:31:01 - 00:24:46:08]
Amith
I struggle with the question. I think it's a really good question to be asking. But the reason I struggle with it is I think for a long time, associations have shied away from building any kind of software at all, whether it's for internal operations or for serving their members.
[00:24:47:10 - 00:24:58:11]
Amith
And that probably has historically been the right decision for most organizations at this size and scale because access to talent has been problematic. Obviously, just the rock and omics of it have been difficult.
[00:25:00:06 - 00:25:53:06]
Amith
And when you end up with a very small team, a team of one, perhaps, or a team of even a handful of people, you have an enormous amount of concentration risk traditionally with software engineers who know your business and they're the only people who know your business. And they're the only people who can keep it running. So that's one of the reasons that small team and mid-sized nonprofits have historically not been really advised to build software of any significance. You know, websites have been the one, you know, classical deviation from that advice because the website is, you know, definitionally bespoke and fitted to your organization. And that's also been one of the biggest pain points for the members of associations is to deal with, you know, rapidly aging software that doesn't work well and isn't kind of consumer grade, right, in terms of expectations. So what I struggle with is that's been a historical guidance. But for the very largest nonprofits that can have, you know, fairly large IT teams, that's been how most people have looked at it for, I'd say, the last 20 years or so.
[00:25:54:10 - 00:27:47:17]
Amith
The opportunity, though, and I think the necessity strategically for nonprofits is to serve their audiences with the same level of capability and the same level of quality, low friction that a consumer grade company is expected to provide, right? You're not going to use an app that is makes you take 10 steps to sign up for a webinar. Yet it is actually a thing that in the association market, it is difficult to pay for products. It is difficult to sign up for things. You can go on site to an association's conference and there might be like an add on paid, you know, session, right? And if you didn't sign up for it ahead of time, you often are out of luck. The association might very much want to allow you to pay right then and there, but they don't have like Square or Stripe or something like that where you can just pay for it and walk right in. They just say, nope, sorry, can't come in. I mean, that's literally what we're doing to our paying customers all the time in this market. So my comment there is, first of all, there's a lot of modern tech that's out there that can be integrated to make those things easier. But it does take work to connect those dots. You can't just say, well, I'm going to set up Square or Stripe or whatever, and it'll just work because you have to tie it into everything else. And that does require some level of technical talent. So I think the opportunity lies in lowering friction and improving kind of the consumer experience externally. I do care very much about how efficient associations are on the inside. What I care a lot more about is how they interact with their members and how they drive value to their members and how to also lower pain, which associations tend to be pretty bad at. So that's where I think it's really important to have some level of technical skill inside the organization or to have partners you work with closely or some mix that gives you some capability essentially. The absence of that means people are just going to leave. They're not going to keep buying your products or services if you make it painful.
[00:27:47:17 - 00:27:57:06]
Han
You know, one thought exercise might be how much of that job that you're describing a meath is a CTO job versus a chief product officer job?
[00:27:58:14 - 00:28:01:24]
Han
Because there could be a world where, to your point,
[00:28:03:00 - 00:28:12:10]
Han
I need an app. I need frictionless onboarding. Somebody needs to be able to hit our property and get through the entire onboarding experience in four clicks.
[00:28:13:16 - 00:28:30:02]
Han
That's a product requirement. That's a user experience. And I would prefer that I could see a world where if I type this in like enough times to my agent, eventually I might get something that I want. What do you think?
[00:28:30:02 - 00:28:53:24]
Amith
I mean, I think the idea of product as a first class role in this industry is a concept well overdue, actually. And I'd love to have you actually maybe talk a little bit about what a chief product officer does, because in this universe, I would venture to bet that most of our listeners are not familiar with that role and how that functions in tech companies. So that would be really helpful. But I'm like double thumbs up on the idea.
[00:28:53:24 - 00:29:04:19]
Han
I think the tech industry is shocking when you've been trying to figure this out for a very long time. And in a typical sort of tech organization, you have
[00:29:06:11 - 00:30:04:03]
Han
a split between the people who build the software, these are the so-called engineers, and the people who define what the software needs to do. And that's where the term product managers come from. The irony, I think, especially for older folks like you and me, are that when we were kids and we started writing software, we were computer programmers. We had a vision of we want the computer to do something. And so we were both the product managers as well as the software engineer. And today there's a bit of a duality. I personally have always found that to be super strange because I think people don't get into software because they want to take orders. People get into software because they want to make things. And those same people spend a lot of time playing with computers, playing with software. So most software engineers, especially the very good ones, have a sense of what they want the software to do.
[00:30:05:19 - 00:30:45:23]
Han
But in the tech industry, that split has existed for a while. I think what you've seen in the last five to 10 years is that as people evolve in their career, you'll find that product managers actually get more technical because they discover that, hey, a lot of times I'm asking for something that can't be built. So what is possible? And so they start to learn what the other side is doing. And on the flip side, the engineering managers, as they move up in their career, they start to go, like, how do I get closer to the business so that I design things that will actually help the business grow? And so these roles actually merge a little bit.
[00:30:47:15 - 00:31:18:23]
Han
But where you fall on that spectrum and sort of in what lane you actually end up doing, I think is not clearly defined the further you move up. But from what I'm hearing from you, a lot of what you're talking about, to me, strikes me as what is the thing supposed to do versus how it's built. And I think that is something that could be a gap regardless of whether or not AI is a thing or not.
[00:31:18:23 - 00:33:03:22]
Amith
Right. I think translating that a little bit into the landscape of associations, where there typically is not a product officer or a product management function, you have people who own specific areas of interaction. So the engagement is typically something like this, or the structure, I should say, something like this. You have a VP of membership, a VP of events, a VP of education. And so these are people who own specific subcategories of the experience. Sometimes there's something that overlays that, who owns the overall customer journey, but rarely is that really the case. It's usually separate. And in some organizations, they've embraced the idea of a high degree of operational autonomy for each of the areas. So you end up with these mini-fiefdoms, where the membership people have this one set of systems that provide people a certain way and provide certain functionality. And the same thing for the other functions in the organization. That's less the case for very small nonprofits that have, you know, just a handful of staff. But for people above, say, 40, 50 employees, that tends to be a pretty common pattern. And so part of the challenge is, is what is the vision for the customer journey? What is the product experience overall? What is the value we're trying to create? Where I've seen this most effective is actually where you have a CEO that has a very strong point of view, a CEO that is a vision that says, listen, the industry we serve, the profession we serve is going down a certain path. And the services and products these people are going to need in the future may or may not include a component of what we do now, but let's build what people are going to need from us and let's, you know, craft our vision based on what the market will need or where the market's heading, which is, you know, what the best product officers will do, too, is really deeply understand the customer and had a lot of empathetic listening. And obviously, couple that with some vision beyond what customers may even be asking for.
[00:33:05:02 - 00:34:09:23]
Amith
But I'd love to see more of that because that's definitely that's a business skill. That's not a technology thing. Just to add one more point, I've always found that the people who have the most impact in businesses I've been involved with, either as an investor or a founder or whatever, are the when I'm talking about technical talent, it's folks who do have what you're describing, Han, it's the people who can kind of wear both hats and understand the customer and what they're you know, out of a lot of people who haven't been in computer programming and related fields themselves actually don't necessarily really get what it's about. It's actually way more artistic and creative than it seems to be. And out of the STEM disciplines, I would venture to say that people who have kind of a knack for art and creativity tend to flock to computer science more than most other fields. And because the degrees of freedom you have just basically connecting your mind to a machine allows you to express that into it like you were describing earlier. And so the ones that I think that are really, really successful or have the ability to communicate and have the language of both the business side and engineering side. And that's that's at least what I've seen.
[00:34:11:01 - 00:34:35:05]
Amith
But but ultimately, I think in our market of nonprofits and associations, those are kind of unicorn like creatures. There's not a lot of people floating around in our world. And that's true in Silicon Valley as well. You don't have tons of people who speak both languages, but when you do find them, they're incredibly powerful. And I think those kinds of folks may be on a fractional basis really, really helpful in kind of crafting the vision and ensuring the architecture is good for for the nonprofit space, too.
[00:34:36:19 - 00:34:39:01]
Han
The organization design that you described
[00:34:40:06 - 00:35:43:12]
Han
is actually not that uncommon even in the tech world. I think in the tech world, they would sometimes break organizations into either, you know, business units or, you know, domains or industries, if you will. And so what ends up happening in those cases, just like, you know, what you described is that effectively you don't have a CTO or a CPO. In fact, when I was at Netflix, we we didn't have a traditional concept of a CTO. I think, right. Peters was the CTO at the time. But there were engineers and product managers in all kinds of groups across the company. And how organizations typically solve that problem in the tech world is they have what's called guilds effectively, where all of the head tech people of each fiefdom or have a head product people of each fiefdom, they get together and they they align on a central roadmap.
[00:35:44:13 - 00:36:15:11]
Han
And that that system can work quite well because it solves two problems, right? It creates autonomy where you need it, but unity, hopefully some kind of unifying, you know, control plane, you know, at the right level. I think when things really fall apart is there's no leader in the control plane. Right. And so then it gets kind of messy. And so, you know, figuring out who ultimately makes the shot, even in the guild, makes the call even in the guild, I think is important.
[00:36:15:11 - 00:36:30:01]
Amith
Han, you know, for our association listeners who are hearing you speak, they're going to be saying in their minds, yeah, that's really similar to what we do. We have committees and committees guild is just kind of a cooler, way cooler sounding term. We start using that for everything. Guild is way cooler than committee.
[00:36:31:02 - 00:37:01:09]
Amith
So, but the problem with a lot of the committees and these group based organizations in association land is that they tend to be consensus driven. So rather than having the leader that you briefly mentioned, you end up with essentially unanimous consent or near unanimous consent be required. As a result of that, they have a lot of debt. They don't kill things. They keep everything. Right. And so I think that's something maybe you could talk a little bit about in the best run guilds you've seen being able to have direction and make hard choices.
[00:37:01:09 - 00:37:17:02]
Han
I definitely see this all the time, especially running technical organizations. What typically what I find easier to do is to come up with heuristics up front that everybody can agree on. So, for example,
[00:37:18:07 - 00:37:34:14]
Han
we might go through a backlog exercise. What is the wish list that everybody agrees that we need to just go fix? Maybe it's unifying our the way we handle login, which is a pretty common thing across many platforms. Right.
[00:37:35:19 - 00:37:45:05]
Han
What are the sort of like big hairy goals? And I think aligning on the the objectives and getting the commitments up front is really important.
[00:37:46:11 - 00:38:32:20]
Han
And it could be just an operating protocol. The way I've run organizations in the past, even for larger technical teams, is let's just get like one thing done every three months. That's a very simple rule. Like one thing on our list done every three months. Can we all sign up for that? And I think it does something very simple. Right. Where if something feels achievable and it's something that we can all get behind that, that kind of rallies people to to a consensus. But without some kind of unifying protocol on how you make decisions, I think you'll find that decision making becomes generally a challenge. And ultimately, you know, for better or worse, I think it is important to to have somebody who who makes the ultimate decision.
[00:38:34:06 - 00:38:58:09]
Han
I think having some kind of leader in the in the the organizing organizing structure is really important. And short of that, I think it may very well be the case that that's a job that you might want to hire from the outside, like maybe even a consultant who ostensibly doesn't have skin in the game, because at least ultimately that in that case, you have an arbiter.
[00:38:59:13 - 00:39:40:02]
Amith
Yeah, that makes a lot of sense. And ultimately, I think making choices is key. And the absence of difficult choices means that you're essentially abdicating the responsibility. And, you know, what you said, I think it's a beautiful and very simple thing that you pick the thing that you're going to get done this quarter. And the absence of simplicity like that leads to saying, hey, let's go get these 10 things done and none of them get done or maybe two or three do get done. But they're not necessarily the two or three you would have chosen to get done out of the if you rank order them one to 10. So by picking the thing, you know, it's it's it's a very powerful way of forcing yourself to say what really is going to move the business forward the best in this time period.
[00:39:40:02 - 00:40:10:14]
Han
And I found that shockingly, when you tell this to teams, they can't get it done. They usually can't get it done that first quarter. They can't get the thing done the first quarter. But then, you know, maybe in the second quarter, they get it done and then they grow up and they go like, sweet, next time we're going to go do two things. And that's progress. So you don't always have to be stuck with only doing one thing a quarter. But being able to scaffold a group of people together so that we're all rowing in one direction,
[00:40:11:14 - 00:40:14:23]
Han
there needs to be a process for that. But it can't be done.
[00:40:14:23 - 00:40:56:14]
Mallory
Let's say we have an association listener, as we near the end of this episode, who says, you know, I want to get my guild structure, my committee structure in order. But I think we need more product talent in our membership team, in our education team, in our events team. We need to find a different type of talent. Han, in your LinkedIn bio, you probably didn't think I'd bring this up, but you did say assessing talent is your true superpower. So I'm curious if we have a leader, an executive director, CEO, listening to this thinking I've identified some gaps from this episode in our team and we would love to bring on some more talent. What would your advice be to them? And when you are assessing talent, what are you looking for?
[00:40:57:21 - 00:41:03:10]
Han
I'll tell you my general heuristic, which probably applies to any kind of hiring.
[00:41:04:23 - 00:41:16:21]
Han
The first thing that I really look for in any individual is some kind of self-awareness. And so historically, the way I test for that in the interview cycle is I will ask somebody
[00:41:18:05 - 00:41:40:14]
Han
what they think they're very good at. And then I will also ask them a question around that topic, around what they think they're very good at. And that helps me assess, like, are they actually good at what they think they are? But I will also ask them the opposite question, which is what are they not so good at? And then I will also ask them a question in an area where they're not so good at.
[00:41:41:14 - 00:41:45:06]
Han
And what I find is that people who tend to
[00:41:46:08 - 00:42:01:11]
Han
misfire on their own calibration tell me something, that they don't know themselves very well. And this is a problem because I think when you don't know your strengths and weaknesses as an individual, it's really hard to get better at something.
[00:42:02:15 - 00:42:07:00]
Han
So if you know yourself well, you know what you're good at and you know what you're not good at, that
[00:42:08:15 - 00:42:37:24]
Han
gives you a metric to actually improve. The second thing that I really look for is to the extent that you know what you're good at and what you're not good at, do you have any proclivities to go pursue the thing? Like, do you have drive, right? And that is more of a behavioral interview question. And then the third one is usually a test of grit. If you know what you're good at and you know what you're not good at, if you want something,
[00:42:39:01 - 00:42:46:03]
Han
are you willing to do the hard thing? And so when I've been very hands-on hiring software engineers in particular,
[00:42:47:04 - 00:42:50:13]
Han
my favorite way of hiring somebody is to bring them on site,
[00:42:51:14 - 00:42:53:19]
Han
give them a hard line, give them a computer,
[00:42:54:21 - 00:43:10:20]
Han
just say like, here's a programming problem, it cannot be done in the five or six hours. I will personally feed you, bring you the Diet Cokes, whatever you need, just hang out here and then show me what you got at the end of the day. And
[00:43:11:23 - 00:43:34:00]
Han
the kinds of people that I almost always end up hiring are the ones who are super excited at the end of the interview, despite the fact that, you know, by definition, they blew it, it couldn't get it done. But then after the interview, they send me the solution after the fact because they couldn't get it out of their head. And that level of determination, grit
[00:43:35:08 - 00:43:38:17]
Han
has been an almost foolproof way of hiring anybody.
[00:43:39:20 - 00:44:55:21]
Han
With that being said, I think your specific question around, you know, like, do they understand the craft? I think you're kind of stuck sometimes, honestly, I think when you're hiring because you're in a situation, and I think a lot of your associations are probably in this place where you're hiring for a role that is doing a job that nobody in the association is ostensibly good at that job. And so my advice oftentimes is for people to go and, you know, unfortunately hire a consultant who could do that, that technical vetting for you. And who doesn't have the skin in the game. And this happens all the time. Like executive recruiters will hire other CTOs to help them interview the CTOs for their clients, right? Because their clients, they're looking for, you know, a head of engineering or a head of product. But if they had the head of engineering or the head of product, they wouldn't be looking for a head of engineering or a head of product. So they actually don't know how to hire a head of engineering or head of product. And very specifically, they don't know what questions to ask. So they fall apart right at the very beginning of my rubric, which is they cannot tell,
[00:44:56:24 - 00:45:10:22]
Han
they can't ask the domain questions of what you're good at and what you're not because they don't even know what questions to ask. And so the interview ends up becoming all about the vibes. And that is a problem, especially when you're hiring for a functional role.
[00:45:12:03 - 00:45:47:23]
Amith
You know, one thing I wanted to point out about what Hans is describing is I think it applies not only to hiring employees within your association, but it also applies to how you think about getting people on to volunteer roles. So the volunteers in the association landscape shape so much of what associations become, how they accomplish their tasks, where they go, even obviously the decisions they're making at the highest level when you have volunteers on the board of directors. And very little thought goes into qualifications for board and even other volunteer roles in my experience. And some people may have
[00:45:49:03 - 00:46:34:15]
Amith
contention with that statement. The reason I say not that much is done with qualifications is that board positions in particular and other volunteer leadership roles often are a result of number of years spent in an organization. They're not necessarily as a result of certain skills or capabilities or accomplishments. And I think what Hans is describing is as important for the way you think about volunteer positions as it is for staff. I also think that in the age of AI, there may be ways to utilize AI to help with some of this. I'd be very thoughtful about it because, you know, there's all these issues with bias and so forth. But perhaps there are ways to start thinking about leveraging AI to support these kinds of processes and make them a little more approachable to you for non-technical folks.
[00:46:34:15 - 00:46:48:13]
Mallory
So it sounds like self-awareness, drive and grit are some of those personal core values that you look for, Hans. But then if you do need technical expertise that you don't have on your team, maybe bringing in an outside consultant could be a good idea.
[00:46:50:03 - 00:47:15:20]
Mallory
I'm curious as we wrap up this episode, do you have any advice for the association leader listening who has maybe done some piloting with AI? You know, everybody's got a Claude subscription, a chat GPT subscription. They're experimenting, but they haven't been able to make any meaningful transformation within their association, within their business utilizing AI. Do you have any general advice for that person listening to this episode?
[00:47:17:02 - 00:47:20:08]
Han
I would say this, and I think this is an industry-wide problem.
[00:47:21:19 - 00:47:29:20]
Han
I will make one observation, which is I've never seen anybody save their way of prosperity. And
[00:47:30:20 - 00:47:44:24]
Han
most of the use cases that you see people talk about with AI are about saving time, saving money. You're saving. But the other flip side is the growth side. It may not be,
[00:47:46:02 - 00:48:01:06]
Han
you know, in your world, it may not be about money, but there's a proxy for growth, right? So how do you use AI to grow? And I think in the long run, the true value of AI is going to be on the other side.
[00:48:02:21 - 00:48:06:08]
Han
Now, if you are hyper-focused on savings,
[00:48:07:24 - 00:48:36:22]
Han
then the first question that I think folks really need to ask is, what is the one thing that is slowing them down if you're trying to save time? Or what is the one thing that is costing you the most money? And that's what you should deploy AI against, because you could use AI against, you know, solving small problems here and there. It could be solving a small amount of time, automating something very simple, or it could be
[00:48:37:24 - 00:49:07:15]
Han
saving a little bit of money here and there. But that's just like AI theater at that point. If you're going to use it, then go use the thing. But you have to be very clear on what you're using it to solve, what problem you're trying to solve and what benefit you're going to get out of it. But if you're hyper-focused on what is it that is costing you the most time, costing you the most money, or what is the thing on the other side that can really help you grow,
[00:49:08:16 - 00:49:14:06]
Han
and then how do you use AI to leverage that opportunity? I think that's where you're going to get the outsized outcomes.
[00:49:15:08 - 00:49:20:20]
Han
And I'm sure it doesn't sound like a genius statement, but that would be my candid advice.
[00:49:20:20 - 00:50:20:13]
Amith
Well, the simplest path to the solution oftentimes is the best. And I would just layer on that what Hans is describing in terms of saving is, in fact, the majority of the conversation in our sector where people are talking about making it faster and easier for staff to, let's say, respond to a member to be able to process a request. Those are not unimportant things. Those are things that have value. But I would simply say that the layering would then be, if you have that additional bandwidth available from having saved the time, then go invest and drive the growth that he's describing, because the opportunities that are out there really are external. And the internal stuff in terms of optimization and efficiency, I know a lot of listeners are going to say, how can we go do this? Because we're so busy, we can't even keep our heads above water. Of course, AI can help you be more efficient and get a little bit of oxygen in the tank and then think that way. But if all you do is think that way, you're going to be missing out on the biggest upside, as as on described it. So I love that. I think it's it's so incredibly applicable to our space.
[00:50:20:13 - 00:50:42:06]
Mallory
No one has saved their way to prosperity. I think that's a really good line to wrap up this episode on. Han, thank you so much for joining us as a decidedly non-technical person myself. I know I've gotten a lot out of this episode, so I hope our audience has, too. We appreciate you taking the time to be on the Sidecar Sync podcast and let our listeners know where they can keep up with you. Thank you for joining us on LinkedIn, your website,
[00:50:42:06 - 00:50:47:15]
(Music Playing)
[00:50:58:08 - 00:51:15:07]
Mallory
Thanks for tuning into the Sidecar Sync podcast. If you want to dive deeper into anything mentioned in this episode, please check out the links in our show notes. And if you're looking for more in-depth AI education for you, your entire team, or your members, head to sidecar.ai.
[00:51:15:07 - 00:51:18:13]
(Music Playing)
[00:51:18:13 - 01:43:39:03]