Jack: Hi everyone. You're listening to Scaling Devtools. The show then investigates how devils go from zero to one. I am really excited about today's episode because I'm joined by Shawn Wang, um, who is known on the internet as Swyx, um, and has been someone that I've looked up to for a long time and read pretty much everything that he's put out on the internet.
Shawn is a writer, a speaker. Head of developer experience at Airy chief editor of dx.tips, which is one of the best resources out there for developer experience and developer growth. Shawn, thanks so much for joining today.
Shawn: Thanks for having me, Jack. Excited to, uh, chat about, uh, today's topic, which, uh, I actually have in my bio and you're the first person to ask me about it.
Jack: Amazing. And so the topic in your bio is Crossing the Chasm. Could you tell us a little bit about Crossing the Chasm?
Shawn: Maybe I'll, I'll bounce this off of you. Uh, did you hear about crossing the chasm before in, in, in the context of tech?
Jack: I had a vague kind of feeling that I've heard of it, but it's also now hard to disentangle like what I knew before reading about your stuff. Um, but I'd say no.
Shawn: It, it's interesting because I feel like it, every person in tech needs to understand this very, very basic concept, which is, uh, there is a technology adoption cycle. Uh, things get invented and then they filter out into the broader, broader population. Some technologies fail to get mass adoption.
Some technologies get mass adoption very quickly and essentially understanding. Uh, succeeds and what doesn't is the primary goal that you should have as a technologist, whether or not it is choosing where to work, whether or not it is choosing what tools to adopt, uh, or whether or not it is, uh, starting your own if you have those ambitions someday. This is a very general purpose, skillset that you should develop, uh, basically throughout your entire tech career. Uh, because. It's extremely valuable. Choose understanding what to work on and how to pick and how to encourage things that that eventually cross the chasm.
The chasm describes, uh, a, a gap in the adoption cycle. The intellectual history of this goes back to the, the Rogers curve, which is basically a bell chart, uh, con conception of how, uh, pe uh, people adopt technologies. It was created in 1957, uh, and it basically divides the entire population from zero to 100% of population into innovators, early adopters, early majority, late majority, and laggards.
People who are innovators start the technology to people who are early adopters. Uh, you know, fast follow, and then the, the majority, uh, population comes along. And then the, the laggards, uh, bring up the tail. And you, so you sort of describe all technology like this. Um, but the primary innovation that Jeffrey Moore had, uh, in his book on Crossing the Chasm, it's, it's literally titled Crossing the Chasm.
Very, very influential book. , He basically observed that the transition between stages is not all created equal. There's one particular stage where a lot of products fail, which is the chasm between early adopters and early majority. And why is that? My framing of it is that early adopters are, tend to be very forgiving and imaginative, and early majority, , need a lot of documentation and use cases, , before they would jump aboard, right?
So in other words, you can get very far with a minimum viable product, and make a bunch of early adopters happy. Well then you hit this ceiling in, uh, in adoption un unless you break through into the, uh, the earlier majority and, and then the rest, uh, come along. So it is in your interest to understand how to break through those.
It is my job to help companies break through those and, um, I think, uh, you know, the world. Hopefully be a better place if you can understand, uh, what drives this and, and, and how to make it happen con consciously rather than accidentally.
Jack: That's an amazing, uh, explanation. And you said kind of documentation and use cases. Could you talk a bit about like why this is so hard for companies to do?
Shawn: Well, because it's not core to the product. A lot of technologists wants to believe, "oh, we just build the best product and then the rest will come". The Americans would say, this is a very field, field of dreams idea. Like, build it and they will come. Most people find out that that is not the case.
Sometimes it is actually the case that you build something that the world just needs overwhelmingly, and you, you never have to think about anything else. That is the, the, the privileged few that, uh, they luck into something that the world just wants so desperately that they get to skip that path, uh, part.
But most people, uh, they build the thing and then they have to market the thing. Uh, and it's always this. Back and forth between products and distribution that, uh, uh, people always find. And in fact, uh, this plays out not just over the, the course of one company. It plays out over a course of multiple companies.
One very famous observation from Paul Graham, um, is that, uh, first time founders obsessed about products is second time founders obsessed about distribution. Uh, because the second time founder knows they can build products, but they fail because , they forgot distribution or they couldn. Uh, uh, couldn't, couldn't unlock it.
Being able to write documentation , and demonstrate use cases that, uh, help the less imaginative and less creative or more risk averse people. to see the benefit of your technology. Whatever the tool you are, you're working on, uh, and dedicate some time into it.
Every single dev tool adoption is a choice. And is is someone choosing to forego something that is probably more tried and tested in favor of something that is newer, uh, because. Of some story you sold them or some need that they have that isn't being fulfilled, whatever that is, helping them understand that what you do to help them, uh, is your, it should be your primary job.
And it essentially is my distillation of what an ideal developer relations person does.
Jack: So they kind of, is it. Help meet those needs? Or is it that they sort of make everything else so good that it doesn't matter that there aren't like strong use cases, say for comparable organizations?
Shawn: Yeah, I think it's a mix of both. Um, sometimes they have, people have needs and, uh, they don't realize your products fulfills those needs. So, so basically you're just gonna. unearthing, uh, existing latent demand. Um, but otherwise, uh, other times, yeah, you are, you are, uh, you know, crossing the gap and, and bringing that feedback about use cases back into the products so that they can, uh, work on the products as well.
What I just described. Geoffrey Moore's Chasm, uh, is about 30 years old. Um, if you want to be a professional at this, you should probably develop a finer tuned.
Philosophy on that. Uh, and that's where I start to develop my own type of taxonomy on, on how people, uh, cross the chasm, right? Because, uh, in my mind, um, if I told you about the innovators, early adopters, early majority, late majority, do you know the difference between them? It's very hard to describe.
Apart from. I don't know, like . Uh, so some of these are more demanding than others, and some of these are later than others. Uh, that's, so that's pretty much it. Uh, and it's, uh, it's, it's very, it's very hard to sort of distinguish like what stage you should be focusing on. Um, so, uh, one framing or reframing, uh, they've been working on is essentially this sort of, uh, Renaming for more intuitive treatments.
Um, so, uh, let's say we have enthusiasts, we have pioneers, we have pragmatists, pragma, pragmatists. We have conservatives, and we have skeptics and newbies. So the enthusiasts will do it because we can, they'll spend their nights and weekends and they'll do it for free. Uh, the pioneers will see a pressing need.
They'll buy the vision of the tool. They'll, they're willing to build What's missing, like the tool tools that are new are typically incomplete, um, and require a lot of extra loving support and care, uh, to, to fill in the blanks. Uh, but the pioneers in exchange, they want to be part of the founding story.
They want to say, I was, I was early in that technology and, uh, you know, I will associate myself with that career, that career, right. Uh, they'll, they'll, they'll call their themselves ex engineer, um, and, and the engineers sort of, uh, associated with your tool, right? So like, I'm a Figma developer, I'm a, uh, Kubernetes, you know, DevOps person.
You know, they, they like, it's literally in their job title and in their identity. Um, that, that's, that's how, um, closely. They, they tie it, uh, to, to themselves. Um, then the pragmatist, uh, , how do you say pragmatist? Um, they're, they're, they're much more about, uh, things as they are today. They're not so willing to give you credit for things that don't exist yet.
Uh, the things that are on the roadmap, they just want what's. What makes sense today? Uh, the, it's very much about cost and benefit. Uh, they want, uh, well document, well-documented, uh, technology, then well-tested, well supported, uh, all the licensing figured out, um, everything that needs to be done for, uh, adoption network.
Uh, because if you don't have any of that figured out, you are literally no value to them. Um, cuz they, they just don't have time to, to help you figure out anything. , the conservatives of the fourth one, uh, conservatives, uh, you know, are even more conservative. Uh, they need certifications. They need social proof.
They, they need you to win popularity surveys. They need to see adoption at big companies that are bigger than them to go, oh yeah, you know, it's good enough for them, is good enough for me. They need to see a healthy job market where a lot of, uh, you know, other people, it's easy to hire in that technology.
Uh, and they need to see, uh, good third party ecosystems that. Plug into that, right? They, so they just need to see a lot more work done by other people before they put in their work, um, . So, you know, it's, uh, they're, they're not willing to go first. And, and that's fine. That's in fact that that should be the, the default position for a lot of, uh, people, uh, on a lot of technologies.
Otherwise, you waste your time getting, uh, cutting yourself on cutting edge stuff. And then finally, it's the skeptics and the newbies who understand everything that conservatives understand. They see all the, uh, cost and benefit, and they're, they still don't like the technology. And the only reason they adopt it is cuz they don't have a.
Or they don't want to do research. They're just like, just tell me like what everyone uses. I'll use that. I, I, I have no time to do any research whatsoever. So, so that's, that's kind of like my interpretation of the Rogers curve, um, which is five stages that are probably named a bit better and more focused on dev tools because once you've understa understood these, these grouping of people, then your strategy evolves a accordingly.
So for example, uh, if your earlier stage. , the tech is the story. Um, all these people who are, who are saying like, oh, we built X with rust. Like, why does it matter that something is built with rust? It actually doesn't really like, but because you're early stage, people love to understand how you work and what you do.
Uh, open the hood up for, for me, the tech is the story. The cost doesn't matter. And in the later stage, the tech is no longer a story. The result is the story and costs. You want to optimize and, and get. So the, the marketing changes, the, uh, the way you, you know, uh, the way you tell your story and the, the way the, the words that you choose, the, the use cases and the demos and the documentation, even, uh, all that changes based on where you are in the adoption curve.
Jack: That's so interesting. So it's like kind of the, you know, the hacker news phase where you're trying to get those early adopters and, and things like what language and tech stack you use is, , is it important? And then yeah, as you progress, it becomes more about, yeah, budget and use cases and Gartner reports.
Shawn: Yeah. So, so that's my explanation. You know, I think every, every um, dev tools person needs to have a mental model of, uh, what the, what, what, where they are in the journey. Um, and, you know, these journeys progress through different phases as well. So, um, I think some, I think another thing to, to understand as well is sometimes the product itself has to change dramatically.
Like it doesn't survive, uh, stage change within in the same format like, um, , sometimes the product has, has itself, has to change dramatically to reach the next level. Um, and understanding and studying how other products do that helps you to work on your product. Um, and I, I think that is something that I'm, I'm in very interested in.
I, I wouldn't never say I'm an expert at it, but I think recognizing that there's something to be learned here, uh, is step one,
Jack: Yeah. And so let's say like you're just like airdropped into a company, a dev, like how are you gonna go about figuring out like what stage um, they're at on the adoption cycle?
Shawn: Um, yeah, I, I think that's, that's super interesting. Um, quite to a quite close approximation. Uh, you can just go by a number of users and, uh, that will be a very, very good metric already, because by definition, uh, The, the, the number of enthusiasts will be small, uh, and the number of conservatives will be very large.
Um, so if you have, uh, in the tens to hundreds of users, they're all enthusiasts. Um, if you ha, if you have the thousands to tens of thousands, you're probably pioneers. Uh, if you're in the hundreds of thousands, you're pragmatists. Uh, and if you're in the millions, uh, you're in the conservative and skeptic space.
Also having some firmi estimates of like, numbers of like number of users for each different platform, uh, gives you a really good idea. I have, I have a longer post on like pop population developers in uh, um, On DX tips if, uh, people wanted to read that. Um, but so a rough estimate of number of people in Hacker News would be 6 million developers.
And rough estimate, uh, GitHub says in the state of octopus that they have 95 million, uh, developers. Uh, that's complete nonsense because, uh, that is just the number of GitHub accounts and not. Everyone who has a GitHub account is a developer, and not every, not every, uh, and some people have multiple GitHub accounts for work and personal.
Um, if you're a developer tool, that, that, that is it. Like you're not, you're not going to hit into the tens and hundreds of millions probably because uh, nothing ever gets there. Um, so, so that's, um, I think that's, that's realistic. And, um, and, and then you sort of phrase your story, um, the, the way that you like, well, so sometimes as well, uh, your, your audience is also a.
Smaller, depending on the type of tool you are. Um, so let's say you're not just about languages, you're also about the role within a company, right? So, um, if you are, uh, in, in, uh, infrastructure tool or like a DevOps tool, um, you know, a large company like Twitter, maybe you would have like 200. Um, DevOps then, then yes.
Like that is basically your, your total adjustable market as well. So, uh, just kind of scaling your expectations by like the, the, the rough population size I think is, is super useful. Uh, and then understanding, um, that that is also a moving target. Sometimes, uh, the populations do increase and you want to have, um, Some amount of, uh, built-in expectation of like how different parts of the, the, the, the enterprise are growing.
Uh, so for example, uh, one thing I'm focused on at Airy is, is the data engineer, uh, which did not used to be a job title, uh, five years ago, and now is, uh, a pretty thriving community of, uh, let's say a hundred thousand people. Um, and so that's not big, you know, but, uh, itself is growing. It's probably doubling every year.
Uh, and uh, it doesn't take that long.
Jack: Yeah. That's interesting. And could you talk a bit about air bite and like kind of the phase phase that you're at, um, and like kind of how that's impacting the decisions that you're making?
Shawn: I would say probably a, uh, Airbyte is in the pioneers phase, right? That's the second phase where, uh, people adopt it because they have a pressing need for, uh, for your stuff because, uh, no one else does it. Uh, so everybody is a open source. Um, Uh, data pipelines tool. Uh, it has the largest community of open source, uh, integrations with, uh, all sorts of data, uh, data sources into your data warehouse.
Um, and that's a very fundamental, uh, need that you have to perform ELT into your data warehouse, uh, so that you can do analysis, and sometimes to drive, uh, business impacts as well. Whatever it is, if your data warehouse is growing, uh, you know, Amazon Redshift is the fastest growing, um, uh, Amazon service, uh, for the past, like 10 years now.
Then you need to fill your data warehouse with stuff. And either you write your own scripts or you take a, you take an open source tool, uh, like Airbyte. Um, oh, well, you can also go for a, a paid tool, but, uh, the, the point is open source. It is still not V 1.0.
Um, and people wanna be part of the story. So like giving out, uh, you know, labels like. Uh, early Airbyte contributor, like you're part of the story for like our first 1000 stars. Like that, that kind of stuff is, is all part of building the community around, uh, the open source project. Um, and so, yeah, I mean at some point we will cross over into the pragmatism stage where, uh, cost benefit also does make sense.
Uh, so we, we are trying to peel on the cost benefit side, um, but that is not. as important as the the pressing need that we do things that, uh, other, other companies don't do. Um, and so that, that puts you squarely in the pioneers, uh, cap.
So I'll, I'll give you, I'll give you a couple of other, uh, things to think about. Um, so we already talked about how the products itself might need to change in order to reach a broader audience. Um, so sometimes you may need to write wrappers around it. You might need to write a low-code version of your tool versus a, a higher code.
Like, basically like to offer. Multiple levels of offerings, uh, for different levels of technicality and, and customizable needs. Uh, so, uh, one, one very, uh, one experience that you and I, uh, talked about before this recording. Uh, you know, previously I worked at Netlify, whereas, uh, helping to maintain, uh, the Auth library, um, and people who open up the off library might be surprised to find that we have four packages for our, for NFI off.
And so do you want styles or not? Do you use reactor? Do you , you know, do you code or not? And, and so you have all these offerings to try to reach, uh, multiple people. And the product does, uh, take on different forms in order to serve different, uh, needs and different audiences. Uh, explaining that, uh, does take a take some time.
So there is something to be said about refusing to do that until you absolutely have to. Um, so I, I do think that I was a little bit too eager. Giving all these offerings because that, uh, conflate confused the story and people, uh, came away with a ne negative impression that it was too complex. Uh, when really I was just trying to make multiple people happy.
Jack: Hmm. So maybe at the beginning it's like you just focus in on that one
Shawn: the one offering.
Shawn: Right, because that, so that, that, that people don't have this extended conversation about the different offerings that you have because, uh, I think a lot of people when they, they need work in dev tools, they, they try to say like, oh yeah, we can do everything. Like, you know, we're, you're so flexible, we're so capable.
That's because they have lack of conviction on who their target audience is. Um, and we definitely had that. Um, we still have that , but, uh, the, uh, you know, the other thing , is that the company that wins the, uh, enthusiast and pioneer phase may not be the company that wins the rest.
Uh, so the company may not capture the value of the technology that it creates, so that the canonical example used to be Docker, uh, Docker Inc. Um, used to be, uh, you know, a company itself and, and, and then, uh, underperformed expectations. Uh, it was recently revived and I, I hear actually they, they seem to be doing well under new management.
Uh, but Docker, Inc. Itself definitely failed to achieve its potential despite revolutionizing, um, , everyone's virtual machines, . Um, you know, and, uh, and, and, and so sometimes, a lot of times, especially if you, uh, create a successful standard, uh, the work still has to be done to build a platform around it such that you capture the value, uh, or you, or you let go of it.
Uh, so another example in the backend world is, uh, open telemetry, which is, uh, come to come from nowhere, like in basically a very, very short time like, The past three years to become the industry standard for, uh, telemetry, for tracing. Um, and the company that w that was the biggest large, largest champion, uh, biggest contributor, uh, LightStep, um, didn't, uh, failed to monetize and, and eventually, uh, got acquired and sold out, uh, and all the, all the, all the core people have left.
Um, and, uh, so it's, it's, it's an awkward conversation in, in the industry because everyone loves the technology, but the, the people that were most responsible for it, Didn't get the credit and , and, and you see occasion occasionally. This happens here and there. Um, and I think, uh, for people who are choosing to work in dev tools and choosing to work really hard and pushing things along the curve, um, you need to be thinking about, um, how you're not going to.
essentially have all your work thrown away, um, by some strategic, uh, misstep. I don't know what, like I don't have the complete answer, but all I know is like, there, there are these examples there. Everyone in the industry wonders about them. It's one of those things where like you just kind of have to try to learn from as many examples as possible.
Cuz it's, it's kind of really hard to, to know the truth because you also have. Basically work there to understand the full picture. And all we have are snippets of like, comments from people, you know, sometimes whispered in, uh, hallway conversations rather than the, in the official press
We're all interested in, uh, working hard in technology, but also benefiting hopefully from our success and, and when, when, when people work really hard and fail to succeed. That is interesting. that is, that needs to be discussed. And, uh, I no one in, in, no, in most cases, no one saying they could have done any better.
All we're just trying to do is that we're, we're fellow travelers and we're trying to learn, um, and, you know, any port in the storm. And you try, you try to learn from what's, uh, what's available out there.
One more thing I'll, I'll offer you. So, uh, what I've. Documented here, uh, the, the whole Rogers curve enthusiasts, pioneers, pragmatist, conservatives, skeptics, and abuse.
These are, this, this is, uh, elements of demands like the people who are, who are users of the technology. Um, uh, another dimension that you should, should think about, uh, interest of development of, of any technology, uh, is the development of the supply of that technology. Um, so there's a, another concept called the wardley map.
Have you heard of it?
Jack: No, I haven't.
Shawn: It's by Simon Wardley, who's a, who's a Brit. Um, he tends to document these very complicated charts of entire industries. Um, so I'll just kind of visually, I'll just kind of like verbally describe it, but I highly recommend people check it out. Um, so on the left you have value chain, um, going from invisible on the bottom to visible at the top, which is basically, um, at the top.
It's closer to humans to closer to. At the bottom is closest to machines. Uh, and then, uh, that's the vertical. axis. And then the, the horizontal axis on the left is Genesis. The, the, the original inception of this, the, the technology, and on the right is commodity, uh, which is, um, uh, the, the more com, the more commoditized version of that technology, right?
So from invention, uh, so his stages on the horizontal axis are Genesis custom built. Product and commodity. So in, in, basically in, in increasing orders of commoditization from invention towards, uh, every, every company, custom building in-house towards buying off the shelf as a service from other companies.
And then finally, uh, a commodity service where you don't even care what brand of, of, of thing you're, you're buying. You just, to me, like, you know, I have a mouse. I don't care what what brand it is, I just need a. Um, so, so that's, that's the, that's the chart of like, from, of, of any technology and, and basically the, the main observation.
Uh, the main takeaway I have from this is that the tendency of technology is to start from invention, uh, going into custom building, going into, uh, product productization and going into commodity. Uh, and there's a, there's a lot of money to be made from every single stage change there. Uh, it does parallel a little bit, um, the Rogers Curve that we talked about.
Uh, but instead of a single company getting adoption, this is more about entire industries getting. getting distribution. Um, and finally understanding like what hap what's moving in relation to others, right? So if other parts of your, your stack, whatever your stack is in delivering technology to end users, if other parts of your stack are moving towards com, uh, a more com commoditized direction, um, that's actually good news for you because your, uh, your part of the stack becomes more valuable.
Um, so the choosing where to be in the stack, uh, is, is very valuable. And then choosing to understand. What parts of the stack you can commoditize while also making sure that other parts commoditize faster than you, uh, is the entire name of capitalism.
Jack: and. The facts that other parts become more commoditized, that makes your part more valuable because that's where people differentiate themselves. Is it or
Shawn: Yep. Um, so, uh, I, hi. There's this, there's another, uh, canonical essay in this topic. Uh, it's called Strategy Letter five,
Jack: That's a fantastic name.
Shawn: Letters one through four. Uh, not as useful, but strategy. Letter five was the good one. Uh, it is one Joel Spolsky, the founder of StackOverflow. Uh, and. There you go. Um, and, uh, you know, it is basically the rule of commoditize your compliments. Um, every, uh, if you've, you've, you've seen this, uh, diagram in a hundred different landing pages, which is your tool at the center of the universe and every other tool on the left and on the right, uh, you know, we can, we plug into everything and we, we deliver to everything, right.
that is essentially airb byte, uh, but also like a, a billion other tools. Uh, uh, Matt Slotnik, who, uh, uh, who I think attracts the data ecosystem, calls this the hardest working graphic in software because every single , every single, um, company says we're special. You know, we we're not like the other tools.
They're, everyone else is commoditized, but we're the only ones that do, uh, x, Y, Z, um, uh, to the extent like, you know, that's obviously not true in some, in some cases, but you want to find. Uh, the, the pockets where it is more true than others, and that's where you make, uh, money. Uh, but so, so here's the, here's the main, uh, you know, um, insight that I, you know, I wanna offer people like try to develop a two dimension, two-dimensional map of where your industry is.
Uh, use whatever adoption curve you want. Use whatever value metric that you want. Understand where your dev tool is, is in relation to all the others. Um, and you will have. , better insight on how to market and, uh, and develop your tool, uh, than most, because most people have never thought about tech in this way.
Jack: I'm gonna take that on myself. Where, where can people learn more about this? Uh, Shawn
Shawn: So I haven't written about it yet. I, I, uh, I've done.
Jack: people need a
Shawn: I know exactly. So I did a, uh, so this has been cooking in my, in my drafts for like two years. Uh, I did a talk about this at the, the recent felt summit. So this felt Summit is one, uh, example that I've been taking on as essentially a project to understand, uh, how to get a dev tool.
And, uh, then the talk was like, okay, we, we have 10 x over the past three years. How do we 10 X from here, uh, to the next thing? And, and do we want to, uh, because, uh, that that's an, that's an interesting, uh, Um, part of, of open source communities and networks that, uh, doesn't get talked about enough, which is sometimes, uh, bigger isn't always better.
Uh, sometimes there isn't optimal size for, for a thing. Um, the only reason bigger is always better is because of VCs. They always want you to grow like a cancer. Uh, but. , and sometimes there's a natural size to things and, uh, trying to push it beyond its size actually ruins the core technology. Um, and, and so I think that that was a, that was a very honest discussion that we had, uh, at the summit.
And, um, I, I, I basically presented like five different models of growth there. Uh, that is essentially the talk version of the blog post that I would be eventually putting out, uh, on the xip.
Jack: I'll put a, I'll put a link out in the description as well. Okay. I'm gonna wash that right now, I think. Um,
Shawn: It's a, it's a very fast talk. I have decided to, um, optimize for YouTube and to go extremely fast, but then leave breadcrumbs for people if they want to, uh, if they want to learn more, because then I get to cover a lot more.
Jack: I think that's a good approach. I found that in general, like a lot of your articles, like I read it, but I'm like, whoa, this feels like a whole section of knowledge I had. I know nothing about that I need to just dig into.
Shawn: Yeah. So it is, it is arguably not a good principle of communication. Uh, there are other people who are, have broader reached than me, that dumb things down, essentially for clear communication. And I, and I'm, and I'm probably, uh, missing out on doing that just because I have this like inherent pride or narcissistic tendency, whatever you call it, of like trying.
Leave everything on the table, like just to put down everything that I know so that you can get into my head, uh, or you can correct me if I'm wrong. Um, whereas, uh, you know, a lot of people when when they write, uh, they're, they tend to, uh, be very concerned with being a fully formed version of themselves with, uh, with no flaws.
Um, and I kind of disliked that, so I, I tried to reflect that in my work.
Jack: Yeah, I think it, it comes across really well, like I. I mean, your background was like hedge funds right before,
Shawn: Yeah, so I used to work in hedge funds,
Jack: kind of you, it feels like you're kind of bringing that approach and thinking very analytically and strategically about the whole space
Shawn: Yeah. I don't know if it's annoying, but like, yeah, I, I, um, , I can't help it. So I'm I'm not gonna change it. But, um, yeah. But so I, I do think that most people haven't seen the, the depth of analysis that is typical in financial, uh, investment reporting. Uh, and then most people haven't taken that philosophy and tried to apply it to all forms of decision making, including technology decisions.
What we're talking about is like, um, going telescoping from the micro, which is individual company, uh, development phases and the philosophies around like, the how, getting your word out there and like, you know, this is, this is what sort of dev drell is on a, on a very sort of quotidian basis, but really when you think about it on a, like a strateg strategic level, it's about entire industries.
Um, and if you want to make an impact, you have to do that. Um, and so there, um, the formal term for this is, um, In, in is industrial organization. There are entire branches of economics that study this. Uh, and so I, I encourage you to, like, I'm, I'm only basically, uh, the amateur at this. You know, I, I pick and choose from, uh, the theories that I, that I happen to.
Like, uh, another thing that you should think about is vertical versus horizontal, uh, splits in industry and, um, how these develop over time. Um, I have a fuller treatment in my book, uh, I think you can read it for free. The, the chapter that is relevant to. Uh, business and tech. Um, so you just go to learninpublic.org, um, and look at the free chapters.
It's, it's the fourth one.
Jack: That's all we've got time for. Shawn, thanks so much for joining. Um, I've wanted to have you on this podcast for a really long time, so it's a big, um, milestone for me. So thank you so much.
And, uh, where can people, um, more, um, if they want to hear more from you?
Shawn: Ah. Um, so I've been making a conscious effort to not say Twitter because I think, uh, there's a decent chance that Twitter may not be around, or I may not be around on Twitter forever. Um, so the permanent site would be swyx.io, which is my, my main blog. I have two other blogs because I have a problem. Uh, so one is DX Tips, uh, literally dx.tips, and that is my focused, uh, dev and dev experience, dev tools, writing.
And then two is, uh, my AI blog, uh, which is L space. Uh, Go on my site and you'll see how the lakes
Jack: Amazing. And thanks everyone for listening, and we'll see you again next week.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.