[{"data":1,"prerenderedAt":465},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"tv-bridging-bytes":121,"tv-bridging-bytes-seasons":131,"tv-bridging-bytes-episodes":140,"sales-reps":213},{"items":4},[5,29,49,69],{"id":6,"title":7,"url":8,"page":8,"children":9},"522e608a-77b0-4333-820d-d4f44be2ade1","Solutions",null,[10,15,20,25],{"id":11,"title":12,"url":8,"page":13},"fcafe85a-a798-4710-9e7a-776fe413aae5","Headless CMS",{"permalink":14},"/solutions/headless-cms",{"id":16,"title":17,"url":8,"page":18},"79972923-93cf-4777-9e32-5c9b0315fc10","Backend-as-a-Service",{"permalink":19},"/solutions/backend-as-a-service",{"id":21,"title":22,"url":8,"page":23},"0fa8d0c1-7b64-4f6f-939d-d7fdb99fc407","Product Information",{"permalink":24},"/solutions/product-information-management",{"id":26,"title":27,"url":28,"page":8},"63946d54-6052-4780-8ff4-91f5a9931dcc","100+ Things to Build","https://directus.io/blog/100-tools-apps-and-platforms-you-can-build-with-directus",{"id":30,"title":31,"url":8,"page":8,"children":32},"8ab4f9b1-f3e2-44d6-919b-011d91fe072f","Resources",[33,37,41,45],{"id":34,"title":35,"url":36,"page":8},"f951fb84-8777-4b84-9e91-996fe9d25483","Documentation","https://docs.directus.io",{"id":38,"title":39,"url":40,"page":8},"366febc7-a538-4c08-a326-e6204957f1e3","Guides","https://docs.directus.io/guides/",{"id":42,"title":43,"url":44,"page":8},"aeb9128e-1c5f-417f-863c-2449416433cd","Community","https://directus.chat",{"id":46,"title":47,"url":48,"page":8},"da1c2ed8-0a77-49b0-a903-49c56cb07de5","Release Notes","https://github.com/directus/directus/releases",{"id":50,"title":51,"url":8,"page":8,"children":52},"d61fae8c-7502-494a-822f-19ecff3d0256","Support",[53,57,61,65],{"id":54,"title":55,"url":56,"page":8},"8c43c781-7ebd-475f-a931-747e293c0a88","Issue Tracker","https://github.com/directus/directus/issues",{"id":58,"title":59,"url":60,"page":8},"d77bb78e-cf7b-4e01-932a-514414ba49d3","Feature Requests","https://github.com/directus/directus/discussions?discussions_q=is:open+sort:top",{"id":62,"title":63,"url":64,"page":8},"4346be2b-2c53-476e-b53b-becacec626a6","Community Chat","https://discord.com/channels/725371605378924594/741317677397704757",{"id":66,"title":67,"url":68,"page":8},"26c115d2-49f7-4edc-935e-d37d427fb89d","Cloud Dashboard","https://directus.cloud",{"id":70,"title":71,"url":8,"page":8,"children":72},"49141403-4f20-44ac-8453-25ace1265812","Organization",[73,78,84,88],{"id":74,"title":75,"url":76,"page":77},"1f36ea92-8a5e-47c8-914c-9822a8b9538a","About","/about",{"permalink":76},{"id":79,"title":80,"url":81,"page":82},"b84bf525-5471-4b14-a93c-225f6c386005","Careers","#",{"permalink":83},"/careers",{"id":85,"title":86,"url":87,"page":8},"86aabc3a-433d-434b-9efa-ad1d34be0a34","Brand Assets","https://drive.google.com/drive/folders/1lBOTba4RaA5ikqOn8Ewo4RYzD0XcymG9?usp=sharing",{"id":89,"title":90,"url":8,"page":91},"8d2fa1e3-198e-4405-81e1-2ceb858bc237","Contact",{"permalink":92},"/contact",{"items":94},[95,101,107,113],{"id":96,"title":97,"url":8,"page":98,"children":100},"8a1b7bfa-429d-4ffc-a650-2a5fdcf356da","Cloud Policies",{"permalink":99},"/cloud-policies",[],{"id":102,"title":103,"url":81,"page":104,"children":106},"bea848ef-828f-4306-8017-6b00ec5d4a0c","License",{"permalink":105},"/bsl",[],{"id":108,"title":109,"url":81,"page":110,"children":112},"4e914f47-4bee-42b7-b445-3119ee4196ef","Terms",{"permalink":111},"/terms",[],{"id":114,"title":115,"url":81,"page":116,"children":118},"ea69eda6-d317-4981-8421-fcabb1826bfd","Privacy",{"permalink":117},"/privacy",[],{"description":120},"\u003Cp>A composable backend to build your Headless CMS, BaaS, and more. \u003C/p>",{"id":122,"title":123,"logo":124,"cover":125,"tile":126,"announcement_text":8,"description":127,"slug":128,"one_liner":129,"card_text":8,"status":130,"sort":8},"9f848853-05b6-463e-96de-3fef244613b5","Bridging Bytes","89f4bcdf-4e43-4751-be4f-4d2385ab92f2","835e1835-66b7-4a56-bd03-6ad8cd4052ce","41d22af0-1a92-46d9-ae97-dd6228b279a3","We bring together leaders from different corners or tech to discuss the past, present, and future of technology trends. It's packed full of great insights and tool from people in companies you know and love.  ","bridging-bytes","Panel discussions with tech leaders to discuss the past, present, and future of trends.","published",[132],{"id":133,"number":134,"show":122,"year":135,"episodes":136},"d0ae16c8-ec29-4076-87e2-f4e0ef7383ea",1,"2023",[137,138,139],"31c435b5-daf6-47c0-b158-9846dd808982","d74e3c5c-77dc-4f34-a247-2cb6cf7cee12","d7bb19ee-8843-4543-aa2a-b37a66806eea",[141,168,195],{"id":137,"slug":142,"vimeo_id":143,"description":144,"tile":145,"length":146,"resources":8,"people":147,"episode_number":134,"published":157,"title":158,"video_transcript_html":159,"video_transcript_text":160,"content":8,"seo":8,"status":130,"episode_people":161,"recommendations":165,"season":166},"creativity-in-code","893678493","A discussion on the evolution and future of online experiences, including practical advice on innovation, technology trends, and the role of AI and AR/VR.","dd93d010-869d-4513-a9a8-76f2daba48dd",68,[148,151,154],{"name":149,"url":150},"Ben Haynes","https://www.linkedin.com/in/contactbenhaynes/",{"name":152,"url":153},"Stewart Smith","https://stewartsmith.io/",{"name":155,"url":156},"David Somers","https://www.linkedin.com/in/jalada/","2023-12-22","Creativity in Code","\u003Cp>Speaker 0: Awesome. Well, super excited, to be diving into this. I think it's gonna be a really exciting conversation. Obviously, this is I've built my entire life around, like, the idea that we're talking about. I think we all kinda have, so it'll be hopefully some some interesting stuff to cover.\u003C/p>\u003Cp>Why don't we kick it off with some intros so everybody kinda knows who's who's chatting, and then we can get into the theme. Stu, do you want to kick it off with with an intro?\u003C/p>\u003Cp>Speaker 1: Yeah. Sure. Let's see. What's a good, succinct way to put this? I have both a graphic design background and a coding background, so design and engineering together, which is awesome.\u003C/p>\u003Cp>So I speak both both vocabularies. It didn't use to be awesome, I feel like, then when we were young. It made us kind of an outcast in both worlds. Maybe I'm speaking too much for myself. So I've worked at Google and Amazon and various other places, and I'm currently at Unity Technologies.\u003C/p>\u003Cp>Speaker 0: For the for the second time around. Right?\u003C/p>\u003Cp>Speaker 1: For the second time around. Yeah. I was pretty torn about leaving the first time around. I left to pursue something pretty interesting, and very happy to be back in the family with a lot of folks that I really enjoy solving tough problems with. And I should probably mention that spans like creative technologist stuff, augmented reality, virtual reality, a little bit of quantum computing thrown in there.\u003C/p>\u003Cp>But, yeah, it bounced around between product design, marketing, research work. It's all fun.\u003C/p>\u003Cp>Speaker 0: Definitely. Yeah. I've probably known for 20 20 years, over 20 years maybe. Going all the way back to the beginning, you know, talking about, like, getting trained, whatever, learning, you know, design and development. You definitely kinda get this sense of, like, not jack of old trades master, jack of 2, master of, like, hopefully both, like, freedom and technology.\u003C/p>\u003Cp>They're just no different. But, yeah, all the way back in the the Yukon days. David, how about how about you? Maybe back from where you are now.\u003C/p>\u003Cp>Speaker 2: Yeah. Great to be here. Thanks for having me. So I'm a head of engineering at a digital product agency, here in the UK called Pixielabs. We're London based.\u003C/p>\u003Cp>We design and build digital products, mostly web based or mobile based. We've been going for 10 years now. We had our 10 year party actually a couple of months ago, which was a lot of fun. And I've been with PixieLab since its inception, helping to initially writing all the code and increasingly my team not letting me write the code. And prior to that, I was, helping to kinda lead developments, at an innovation lab at News UK, or at the time it was News International, which is the publisher of The Times of London and The Sun, a big newspaper publisher here.\u003C/p>\u003Cp>And prior to that, my my background is very, traditional. I did computer science. I was I was a very traditional nerd and always have been, always will be. But, yeah, worked on a whole bunch of stuff under under the kind of pixielabs umbrella, everything from large companies, you know, people like Twitter and HomeServe, but also start ups and and smaller brands and everything, yeah, from, like, big platforms for Fitzy 100 down to cat food subscription websites. And we once made a thinking about, sort of like things that are the most creative, we once made a typewriter type by itself when you tweeted at it, for an art installation with in partnership with Twitter, which I get so much mileage out of in conversation forevermore.\u003C/p>\u003Cp>Like, that's like the one. It's like the one project where you're like, I can talk about this a lot forever.\u003C/p>\u003Cp>Speaker 0: Was that at a museum perchance? Like, was that a museum over on your\u003C/p>\u003Cp>Speaker 2: side? Yeah. It was like it was initially a there was like an art exhibition. They ran Twitter ran like a competition for ideas that were powered by tweets in some way, like any idea. Right?\u003C/p>\u003Cp>And people submitted everything from, like, pigeons flying around measuring and tweeting the air quality, all the way to the typewriter that was, like, typing out a a novel by through Twitter. And we had to, like, come up with some representation of all of these ideas that people had submitted or, like, 6 of the winning ideas. And then I think the typewriter ended up at the Globe Theatre as well, where it was typing the complete works of Shakespeare, but it would wait for the someone to someone in the world to tweet the next word that it wanted to type. It took months and I think really annoyed all of the staff like, in the corner, like, clacking away. This was a really loud old school typewriter.\u003C/p>\u003Cp>Speaker 0: Yeah. So just randomly for someone to, like, say the word betwixt, and then it could keep on Yeah.\u003C/p>\u003Cp>Speaker 2: Exactly. Exactly. And, you know, like it wasn't the I will admit it did have a time limit before it would just type the word and move on. Otherwise, I don't think it would have ever finished. I mean, you can\u003C/p>\u003Cp>Speaker 0: just sit there and, like, be the one to keep it moving along. But Right.\u003C/p>\u003Cp>Speaker 2: And that's the thing. You would stand in front of it. Right? And you could tweet the next word, and it would, like, tweet back at you saying that you'd you'd powered it. It\u003C/p>\u003Cp>Speaker 1: was wild. The idea of an impatient typewriter.\u003C/p>\u003Cp>Speaker 2: Yeah. It was. It was impatient. Yeah.\u003C/p>\u003Cp>Speaker 0: You should just start tweeting out, like, prompts. Like, okay. Listen. We gotta get this thing rolling.\u003C/p>\u003Cp>Speaker 2: Yeah. Please someone tweet this word.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. I did. So at my agency, which is called Ranger, we did something similar. It was with Google, and Teller, I believe, was, like, the creative side, that was pushing it.\u003C/p>\u003Cp>It was a museum, and they had oh, I don't even remember the one of those things you look through, the, periscopes, telescopes. Mhmm. But it was, like, all digital, and they had all sorts of, like, art museum installation stuff that was, connected to like, real world stuff that was connected to technology. So similar to what we're talking about today, you know, bridging the gap between the real world and digital, I think we're kinda getting more into the the creative and code or design and development depending on which alliteration you choose. I love it.\u003C/p>\u003Cp>Well, thank you both for for being here. This is, super exciting. So and then just kinda tap it off. So my I'm Ben Haines. I started, an agency maybe 15, 20 years ago, called Ranger out of Brooklyn, which is where Stu is right now, I think.\u003C/p>\u003Cp>So David's in the UK. Stu, you're in in Brooklyn. So I started in Brooklyn, really, with exactly what we're talking about. Like, I had seen a lot of development firms, and I had seen a lot of design agencies, and they were trying to communicate. And you just get a lot of the, the design hands off.\u003C/p>\u003Cp>It's like pixel perfect, you know, mock, or here's what we're here's what we're looking for. And, you know, the the development's like, oh, we built it. Here you go. But it's not really following the the design principles. They're not giving feedback on what's possible.\u003C/p>\u003Cp>Like, designers are really great at making things that look great, but not functional. So I tried to bridge the gap hiring designers and developers to build for, you know, Google, Snapchat, AT and T, Prada, US government, etcetera. But that's where this software Directus kinda stemmed from was, wow. Okay. So we're building these really innovative projects for those sort of companies, and, you know, smaller companies, culture institutions, etcetera.\u003C/p>\u003Cp>But we're building the same thing over and over and over again. How do you take maybe one of the more I mean, quantum computing, Stu, so you you got me there. But, like, the database is pretty technical. How do you make the database, you know, in the work of a a DBA, a database administrator, you know, how can you democratize that so the business user can do it and you you do it through design? You know, really strong intuitive UX and UI, giving you know, I I was inspired by PHP MyAdmin, which I think is maybe lacking design.\u003C/p>\u003Cp>I you know, Not not the best not the best system I've ever used. So I was like, oh, just take that and make it friendly and intuitive and safe. So that's where Directus, you know, our our software sort of stemmed from. But so today, we're we're kinda really covering the basis of, where all 3 of us live, which is are we gonna say design and development or creativity and code? I like I like both, I guess.\u003C/p>\u003Cp>Speaker 1: I think I'm leaning towards creativity and code. Okay.\u003C/p>\u003Cp>Speaker 0: Yeah. I would say design development, but creativity and code, I like it's not just design, I guess. So, yeah, that is probably better. So the intersection of those two things or the overlap even, I think we've all sort of built the whatever we've been doing for the last 10, 20 years has been has been right there. So, without further ado, why don't we jump in?\u003C/p>\u003Cp>So I guess to start off, Stew, you mentioned sort of, your history going through different large orgs, you know, AWS, Google, Yahoo, relatively structured companies or very large companies. I'm curious when we're talking about creativity and code going at the c's, how do you, like, encourage a culture of innovation at a company that's a little bit more rigid or, a little bit more red tape?\u003C/p>\u003Cp>Speaker 1: Wow. I guess, the answer varies quite a bit depending on which context. So for instance, Google is a huge company. Right? And there's a lot of rigid structure in place necessarily.\u003C/p>\u003Cp>But what was really cool about Creative Lab and also, the data arts team is they were little corners of the company that, folks like Andy Barrett, who runs Creative Lab, he had won the confidence of his fellow executives to, say, we're gonna go off and do something crazy over here. Here's why it's justified. Here are the business reasons and marketing reasons and whatever, but we're going to go be a little nuts and you're going to sit back and chill. And so I'm so glad that like in that context, there's a very strong leader standing between you and a lot of that process, and it allowed Creative Lab to be a little crazy. And I I haven't been there in, quite some time.\u003C/p>\u003Cp>I feel like there's a little bit of a trajectory where it started to become a little more formalized, probably also necessarily. But I also remember the more Wild West days, literally, with a sword and champagne bottles and stuff, just impromptu on like a Tuesday evening because everyone's working late and major projects are due. So there are a lot of good it was a place where there could be some irreverence and the space and time for some creativity. Of course, things have to get done and they have to get shipped and delivered, so it wasn't without pressure for sure. Whereas I would say Amazon was a very different case and ultimately, I don't think AWS is just so not geared towards a creative process.\u003C/p>\u003Cp>So I think I lost the battle a bit there within AWS, which is sad. Yes. There's some great people there. But,\u003C/p>\u003Cp>Speaker 0: I can imagine, like, just in the in the 2 you just described, you know, one has creative in the in the title, you know, in the team name and servicing. So, like, they kinda have maybe different focuses, maybe. But\u003C/p>\u003Cp>Speaker 1: Yeah. For sure.\u003C/p>\u003Cp>Speaker 0: Yeah. And that's that's pretty amazing. And I I feel also feel like, you know, the more emergent like, the newer the idea is for a team or for a company, regardless of how big it is, it's easier to be in that, like, divergent mindset and just be like, oh, we're gonna break things. We're gonna innovate. You know, that's one of the same.\u003C/p>\u003Cp>We're gonna be, like, super creative and just kind of push the envelope. And then over time, it's like, oh, we have real world things. We have to answer the investors, or we have to kind of rein it in a little bit and switch to convergent mode. Both of those are pretty established companies, but creative I don't remember when Creative Lab was formed, you versus\u003C/p>\u003Cp>Speaker 1: I don't know. I wanna say maybe there were seeds of it in 2006 or something, which is well before I joined. That would have been I\u003C/p>\u003Cp>Speaker 0: mean, it held on to that idea.\u003C/p>\u003Cp>Speaker 1: Very fuzzy about the yeah.\u003C/p>\u003Cp>Speaker 0: Yeah. I mean, held on to the the ethos of, like, create I mean, yeah, that's the purpose of the team. Interesting. And would you say the same thing for I think we we were talking recently. I think maybe there was some overlap at Yahoo between when you were there and when I was there, maybe not.\u003C/p>\u003Cp>But would you say the same thing for for Yahoo? Exclamation.\u003C/p>\u003Cp>Speaker 1: Well, I think, I, speaking of returning to places, so I had been at Lab, went to Yahoo for a few years, then went back to Creative Lab and Dana Hartstein, which is a whole other story. So I think I entered Yahoo with a different mindset. The context was that Marissa Meyer had left Google, and she had taken over as CEO, and it was still the early days of that, so there was a lot of this optimism that Yahoo had built this giant, I'm gonna use metaphors here, had built this giant ship, and it was a brilliant ship. It was a big battleship out on the sea, but over time, its facilities have been squandered and things were not going so well. So Marissa climbs aboard and says, I'm the captain now, and you could go do a startup or you could go do something else and you'd have to build your entire ship, and that is a difficult lift.\u003C/p>\u003Cp>Or you could jump on this ghost ship and take all the good parts and rebuild them, and that seemed to be the mentality. We're all here. It's a new era. We already have all of these products and services and things that generate revenue and just let's use it. Let's build anew, from this kit of parts.\u003C/p>\u003Cp>And, so it was a pretty exciting time. And there, maybe I'm speaking too much for myself, but it felt like there's a bit of this sort of pirate mentality of like, here we are. Let's blow things up and let's reinvent. And because of that, I started out in marketing, had some success there. My biggest success there already incorporated cutting edge research, early days of machine learning, Marketing, obviously, design is what I was bringing to the table.\u003C/p>\u003Cp>So it was all like engineering, marketing, and design altogether. And because of that, I was in marketing, then I was in product, and then I was in research. So I literally, like, bounced around the company kind of doing similar stuff at every turn but with a different hierarchy and sort of a different set of rules being bent in in a new direction.\u003C/p>\u003Cp>Speaker 0: I like that. I like that. So anybody on my team knows I'm a big fan of metaphors. And I I thought for sure, when you talk about breaking the ship apart, you're gonna go down the, like, the Theseus, paradox. Oh, right.\u003C/p>\u003Cp>Yeah. And I was like, oh, no. We're going pirates. We're doing pirates. I like it.\u003C/p>\u003Cp>That's that's amazing. Yeah. I think that that kinda makes I I I have always sort of worked at, my like, an agency, like self self employed with the exception of maybe a a year, year and a half at we were both, AOL, Verizon, Yahoo, which may or may not have had overlap with you. But, yeah, it was for me, they there was, like, creative freedom, but it was definitely, like, you can be creative until like, toward the end of the process, and then it's like, I hope you had fun because we're gonna shut that down, and we're gonna work on something, you know, something else that maybe is a little bit less fun. And which is almost more stressful because you get to work like, you get to take a project to 90%, and then they kinda scrap it.\u003C/p>\u003Cp>I just wasn't used to that way of working. It's like, oh, well, I guess that's that's how it's gonna be. So I I wanted a little bit more control and kinda stepped away. I was like, alright. I just need to be able to sail my own pirate ship, because even pirates, sometimes they're they're not hiring the way you wanna pirate.\u003C/p>\u003Cp>Speaker 1: Yeah. If you if you wanna lament some of those, Yahoo things, I got it to a 100%. We had a a very successful marketing campaign that resulted in a patent, which is weird for marketing, and some other interesting developments. And I thought, wow. Okay.\u003C/p>\u003Cp>Based on the back of this, now it's time to start my own team. And, with the right group of folks, we could bang out a few of these every quarter, and wouldn't that be a good thing? And, it was tentatively called the Marketing Innovation Group, and I was so excited to take this remit that I thought I had earned and like run full speed with it, and that turned out not to be the case. For some reason, it was like, well, that was successful, but the analysis was for none of the reasons you listed. And after that, they never had a project like that again.\u003C/p>\u003Cp>It was like, all right. So I moved to product for a while with some other very crazy folks.\u003C/p>\u003Cp>Speaker 0: Yeah. You get to meet different meet different teams. I was I was moving toward, like, the VR teams. We probably would have intersected at a certain point.\u003C/p>\u003Cp>Speaker 1: Oh, goodness. That would have been a lot of fun.\u003C/p>\u003Cp>Speaker 0: Yeah. Oh, yeah. Absolutely. But then I was where I was like, how far can I get down this road before whatever cool thing, you know, we dream up gets scrapped? So I I kinda stepped stepped away, but, I'm sorry.\u003C/p>\u003Cp>Well, so and, David, obviously so I shared some time, you know, with with the big companies like like Stu. You've been over a decade at your agency at Pixie Labs. I ran mine for a similar amount of time, and what I found or just in general, you know, agencies really have to stay at the bleeding edge of, you know, what's going on in terms of the tech stack, in terms of just everything from the the small, like, what's going on within the front end, you know, CSS and frameworks all the way up through larger trends, and things that you can pull into your process. Because you're not always like, the spec that you're giving from a given from a a customer or a client or whatever it is isn't. It's like the the goal, but how you get there and how you really push it is on the agency.\u003C/p>\u003Cp>And I'm curious. How are you making sure that your team stays on top of, you know, the creative and tech, staying ahead of the game and just leading, you know, leading that side of things. Yeah. Any any\u003C/p>\u003Cp>Speaker 2: specific I mean, like, as an agency, right, you're optimizing for being billable and kinda remaining ahead of the curve and doing experimentation and things like that can really kinda run counsel to that. It's funny, like, you actually mentioned, Stu, about sort of, like, you know, having a corner of the company that had won the the confidence of execs and and things like that. Like, you almost kinda have to do a similar thing with time, right, and enshrine a a a portion of time where you, you know, for us at Pixielabs, it's like a day a month where we've sort of set aside as non client time, which is not a lot of time to really get a lot done. And, naturally, I'd much rather it would it was a bit more. But, like, having some time that is a little bit enshrined that you're like, this is the day when everyone feels okay with putting down the client work that they're on, you know, and which can be tough with deadlines and things like that and and try and, you know, use that time for a bit of experimentation.\u003C/p>\u003Cp>But, also, I think, like, there are some areas you can be flexible in an agency on projects. So I kinda try and look for opportunities project by project. Right? And sometimes it can be a bit of an exercise of bargaining with a client as well. So if you've got something where the budget's a little bit low, or maybe it's a for good thing and you're being asked to kind of, like, help, you know, help out something that is more charitable or something like that, maybe maybe that client might be a bit more receptive to you actually doing a bit of experiment you know, experimenting on that project.\u003C/p>\u003Cp>Right? Trying something that's a bit unfamiliar and just being open with that and saying like, hey. Maybe we're gonna try something a bit new here or work with something that's a bit more unfamiliar to us or, like, we have this idea that we don't know if it's gonna work, but we wanna try it and, you know, depending on the parameters of the project. I think that that there's an opportunity then. Also having, like, good relationships with clients, especially long standing relationships can help with that, especially if you're you know, one of the things that you do in an agency is, like, how can we get more out of a client?\u003C/p>\u003Cp>Right? Like, how could an existing client, how can we unlock more more spend, more investment in us? And having some ideas, having some things that are experiments, and I'm kinda trying to sell that as an as a kind of joint experiment. Right? And being like, well, let's experiment with this thing together that we see there's a potential for your business, and, like, we can help that make that happen, I think is also is also a way to do it.\u003C/p>\u003Cp>And I think thinking about the engineering team as well, just in general, like, you do have to make sure that the experiments kinda in some way, I think, align with, like, our goals and vision. Right? Like, if we're, like, we're primarily doing stuff sort of web and mobile. And so, you know, I don't know if I would be comfortable with it with one of my team, like, going wild and doing some experimentation with something hardware based or electronics based or or something like that. Like like, maybe, but I think that that feels a little bit too off piste, and a little bit of a challenge to justify.\u003C/p>\u003Cp>And instead, it's like, okay. Like, if there's something that's slightly out of our lane, but not massively out of our lane necessarily, unless that was something that we were like, as a business, we also wanted to move into. Right? There are definitely things, you know, that we're seeing on the horizon, like, that you you're sort of alluding to, that are like things that we're like, we do wanna try and move into that area. So those opportunities then maybe are a little bit more left field that then the team can kind of like explore a bit more as well.\u003C/p>\u003Cp>But, like, having a little bit of alignment, I think, is useful, especially in a small team and especially where you don't have a lot of time to do it. You don't wanna go too off piste. What do you think\u003C/p>\u003Cp>Speaker 0: like, in terms of some of those things that might be on that horizon? I'm just curious.\u003C/p>\u003Cp>Speaker 2: Trends. Yeah. Like, one of the one of the things that I'm increasingly thinking about is about Apple moving into the AR and VR space with VisionPRO and thinking about how big of a deal that is for that kind of side of things compared to even I remember when I was at news and we were doing stuff to do with augmented reality and scanning QR codes and putting 3 d models on bus on the sides of bus stops and things like bus shelters and things like that. And, like, nothing has really moved along for a very long time in my opinion. Like, it's sort of you know, there's not sort of been like a huge like, it was novel then.\u003C/p>\u003Cp>It feels a bit novel now still. But I wonder about, I pay a lot of attention to the fact that Apple are really moving into that space. And so that is something that as a business, we're like, that feels quite out of our lane compared to web and mobile, like, even though it is sort of adjacent. And so that is something that strategically I'm like, there's some there's some thinking to do here.\u003C/p>\u003Cp>Speaker 0: Yeah. Oh, for sure. Yeah. I like it. I like that.\u003C/p>\u003Cp>And so it's interesting. So you're saying almost like you're you've got this I think, like, Google also had a lot of companies have had this, like, idea of, like, white space where 20% of your time or whatever they can afford, is given to their their teams to say, like, hey. Just build. Like, come up with the cool stuff. It doesn't it should be generally on task, but, you know, more proof of concept.\u003C/p>\u003Cp>But you kinda scope that to the projects, and you kinda budget it in and said, hopefully, if if there a client is looking for something a little bit more innovative, it's like, well, we're we're gonna kinda go off and do some like, a little r and d sprint as part of the budgeted time, or how did you structure that?\u003C/p>\u003Cp>Speaker 2: Yeah. That's yeah. That's we're kinda talking about 2 different 2 different approaches there. Right? On on one hand, you've got the the, like, time that is for us specifically that we're kind of enshrining as non client time.\u003C/p>\u003Cp>But then on client projects, it's really about, trying sort of keeping keeping things in the back of your mind of, like, things that you'd like to do or things that feel interesting or worth exploring and trying to find opportunities to to kind of worm them into a project or trying to, like, sell them into to an idea that a client has or a problem that a client has and being like, oh, like, we actually think that that this, like, new thing that we've that we've seen that we wanna do a bit of experimenting with, you know, it's you've got a you know, finding something small that we can that we can, like, experiment with something on. And I'm thinking specifically there about new tools or new frameworks or things like that rather than anything too major, just sort of like really about kind of staying at the edge of, you know, the tools using the right tools and using the best tools, to to get the job done. Right?\u003C/p>\u003Cp>Speaker 0: Yeah. I like I like that. So I guess that kind of is is pretty interesting. That kinda segues in. I would almost throw it back to to either of you, I guess, at this point.\u003C/p>\u003Cp>But, on that the tech side, you know, in terms of the stack, are there specific tools or platforms, that have been, like, pretty pretty crucial in building out the different projects that, either of your you know, you or your teams have been have been pushing? Specifically through the lens of, like, this intersection of creative and technology. Obviously, there's plenty to to go through in the tech stack, but I think this is a more nuanced space. Well, of course, Unity. I\u003C/p>\u003Cp>Speaker 1: mean, I I do agree with Unity. Just, you know yeah. I'll leave it there. I won't pitch for my own company too much or the company I'm a part of. But so other than that, I would say, 3.\u003C/p>\u003Cp>Js. My goodness, Ricardo and team over the years, that was really the real entryway for me because I started out as a web guy. I started to mess around with 3 d, didn't understand it so well. And then after banging my head against 3. Js and relearning matrix multiplication and all that good stuff, it's it's paid dividends as, the web has become more powerful, WebGL and now WebGPU, and WebAssembly, you can do a whole lot of stuff.\u003C/p>\u003Cp>David, you had mentioned the there being a gulf between AR, VR, and, and the web and mobile. But I found with things like like the quest, I could do it so much through the web. It was really exciting. And that was one of the things that I worked on at Amazon was, their Sumerian product, which was pretty interesting. To me, the most powerful thing, it was all in browser, sort of like Unity lite in browser.\u003C/p>\u003Cp>The most powerful thing was the blue publish button on the top. You can make any experiment you want. And then the moment that you were ready to share it with the world, you hit that button, and it takes a few seconds, maybe like 10 seconds. And in that 10 seconds, it is taking your project and replicating it on all of Amazon's servers with all of its 9.9 whatever uptime, and you can immediately share that URL out to anyone. And I thought that was so\u003C/p>\u003Cp>Speaker 0: cool. 9.9 uptime is not that great, Stu.\u003C/p>\u003Cp>Speaker 1: Well, 99 whatever. Yeah.\u003C/p>\u003Cp>Speaker 0: They do the they do the best replacement. Yeah. Yeah. But I mean, 3 JS, I mean, it's crazy. I mean, I guess similar to Directus, you know, what I've been working on, it's been around for a long time, but its relevance kind of can still be in the future.\u003C/p>\u003Cp>Like, it can become more relevant over time depending on I mean, 3 JS has just been, like, just such an amazing thing to not just follow along, but just to use, like, just browsing through the demo pages and all that and just being like, oh, I could kind of fork this idea and just run with it. It's such an amazing platform. I think there's all and then obviously being it's open source. I think it's MIT, obviously. Oh, yeah.\u003C/p>\u003Cp>Yeah. Yeah. Like, I think that's a big any open source tooling, is is a big win in my book.\u003C/p>\u003Cp>Speaker 1: I've contributed tiny like, a tiny, tiny bit.\u003C/p>\u003Cp>Speaker 0: For 3. Js? Yeah. Oh, wow.\u003C/p>\u003Cp>Speaker 1: It's it's not really worth mentioning, because it's so small in the scheme of things. There are real contributors.\u003C/p>\u003Cp>Speaker 2: You're doing it anyway.\u003C/p>\u003Cp>Speaker 1: It's like, okay. Yes. I gave back a tiny bit to this tool that has helped me.\u003C/p>\u003Cp>Speaker 0: We'll we'll call it a micro maintainer.\u003C/p>\u003Cp>Speaker 1: There we there we go. Yeah.\u003C/p>\u003Cp>Speaker 2: I\u003C/p>\u003Cp>Speaker 0: like it. How about how about you, David?\u003C/p>\u003Cp>Speaker 2: I think, like yeah. It's interesting. I I had some notes about thinking about tooling of things like 3 JS and and stuff in kind of Webexa land. Like, I think for for things that are around, like creative and bringing creative ideas to life, I try and think of, like, what are the tools that are like one person tools, right, where you can go from nothing to done. Like, you were just describing right where you're talking about, like, building, you know, working on an experiment and then publishing it, right.\u003C/p>\u003Cp>And you've got all of that tooling in place, that means that you as one person can go from idea to execution to deployment and, like, live and and actually in in the real world. Right? Like, it's boring, but we use, Ruby on Rails, right, as a as a web framework for for most of the stuff that we do, all of the web apps that we're doing. And that has the same kind of idea. Like, in fact, the the founder, David Heinemann Hansen, was saying this at the conference the other week of, like, it's like a one person framework.\u003C/p>\u003Cp>Right? It's like one person can do the front end, the back end, the deployment, the maintenance. Like, the tooling is designed to be used by one person and actually make, like, make a lift as one person rather than having something that is inherently complex or has multiple moving parts or you need to add more moving parts to it to bring it to life. Right? So that if you're sort of building something yourself from scratch in, I don't know, some some JavaScript framework where like, some back end JavaScript framework where you've gotta also work out the hosting and, you know, you've gotta decide, is it is it is it microservices based?\u003C/p>\u003Cp>Is it am I gonna put it in a cluster somewhere? Am I gonna you know, how do I how do I get this live? What do I need to think about? Like, those things start to turn into, like, things that you naturally split up into multiple people or you need, you need a person just keeping an eye on it every day and that kind of thing. And and so I really like, like, that's the kind of thing that I that I think about, of, like, what are what are the tools that are, you know, that are that are good for, like, one person that that cover everything from from from start to\u003C/p>\u003Cp>Speaker 1: finish. Well, I feel like here's where we could also segue into direct us, which is\u003C/p>\u003Cp>Speaker 2: I did have that I did have that written down that, like, you know, directors is kind of a bit of a one person tool, right, in the sense that it there we go. In the sense that it wait. Where can I get one of them? I haven't I don't have one of those on my desk. What is it?\u003C/p>\u003Cp>Hang on.\u003C/p>\u003Cp>Speaker 0: I always have, like, a 1,000 of them printed, like, today, so we'll we'll touch base. Great.\u003C/p>\u003Cp>Speaker 2: Yeah. Like, in the same way. Right? In in in the you know, it's like database. You've got APIs.\u003C/p>\u003Cp>Like, it's giving you all of the it's giving you the front end layer to work in. It's giving you the API layer to work in. There's a director's cloud hosted environment. Right? Again, like it is.\u003C/p>\u003Cp>It's it does feel like that kind of thing of, like, tool tool of tool of 1 team you know, 1 person teams kind of thing. Yeah. And I think, like and then, otherwise, I was thinking a little bit about, like, what tools do I use just to, like on the very creative end when I'm thinking about just, like, coming up with ideas? And I have to plug I have a special place in my heart for Excalidraw. Do either of you use Excalidraw for, like, for, like, putting together little diagrams of stuff?\u003C/p>\u003Cp>Speaker 1: No. The comics\u003C/p>\u003Cp>Speaker 0: at the end of, of Yeah.\u003C/p>\u003Cp>Speaker 2: But it's it's I don't know what it is. It's something it's so aesthetically pleasing to use. You you open up Excalidraw, and it's like a blank it's like the classic, like, infinite whiteboard, infinite canvas type tool, but, like, everything looks like you've scribbled it. And there's and it has just the right amount of shapes and colors and lines and sizes that everything you make just looks I don't know. I look over my old Excalidraw drawings, and I'm like, these are all so nice.\u003C/p>\u003Cp>They all just it just makes everything look it's like just it's like just loose enough. It gets kind of reminds me of, like, balsamic mock ups, but I always felt like balsamic mock ups, the aesthetic of that never really kind of vibed with me. I think that is too Comic Sans of of mock ups, but something about Excalidraw, I just\u003C/p>\u003Cp>Speaker 0: might Yeah. We we use that a lot just for, like, quick, like, oh, let's just go in there. I think, hilariously because I I believe, if I'm remembering the tool the tool correctly, it gives you, like, a one of those random names, whenever you join until you, like, register and say this is your actual name. Right. And the first time I logged in, I'm in with, you know, 20, 30 people, on the direct score team, and it it assigned me Tremendous Beaver, was my my written name.\u003C/p>\u003Cp>And I I think that still floats around in our Discord server. So, but, yeah, I think it's that balance. I mean, right there is a balance of, like, looseness and, like, get things done. Right. Striking that balance is really difficult.\u003C/p>\u003Cp>It seems easy, like, just with with design. Like, design becomes transparent when it's done really well. I feel like a tool like that, just makes it seem effortless. Hopefully, that's what we're trying to do with Directus as well. And you you mentioned sort of it's a good tool for 1 engineer, and I think another aspect or facet of that is when you can make that one engineer, that one creative technologist, whatever it is, seem like 10.\u003C/p>\u003Cp>You know, it's not just effective. You can do it yourself, but giving them the abilities of, like, oh, I'm just, you know, just front end. It's like, oh, this kinda allows you to be full stack and kind of build, at a full stack level. There's some marketing stuff in there somewhere. Yeah.\u003C/p>\u003Cp>You're right about that. Is there, like, a good way to assess? I mean, you have emergent tech. You've got, you know, AI. You've got all these amazing things that are kind of flowing out.\u003C/p>\u003Cp>And how can you use them, incorporate them into your workflow, be more efficient. But, also, sometimes when you're building it into the stack, especially the stack of a client, that might you're gonna build it and sort of deliver it, and it's gonna exist and maybe you have to maintain it for months here, how do you ensure that the tech that might be a little newer is actually stable enough? You know, it's, obviously, it's out of beta. It's all that. But, like, how do you know that it's the right decision?\u003C/p>\u003Cp>Or do you just say, like, well, we'll we'll learn from this, and maybe we won't use it for the next project. Maybe we'll have to rip it out, you know, 6, 12 months later. But anything in terms of that evaluation process?\u003C/p>\u003Cp>Speaker 2: I think you've kinda talked you kinda started to touch on it, really. I I think that it's all about experimentation, and it's about time boxing and making sure that you have some time to evaluate at the end or or to have some kind of retrospective either as an individual or as a team of, like, how do we feel it when using that new technology or experimenting with that new paradigm or new approach? Like, did we like it? Did it did it and, you know, upfront deciding, like, is this gonna speed us up? Is the plan that is gonna you know, it's gonna make us happier to do whatever it is we're doing?\u003C/p>\u003Cp>You know, and and really making sure to be critical of the of the the work that you've done and the process you've gone on and be like and be willing to discard it. Right? And be willing to go, no. That was shit. Let's never use that again.\u003C/p>\u003Cp>Right? It it it really, like, it really slowed us down, or it was really error prone. Or, you know, we learned things like kinds of things. I was trying to think of examples of that, and I was like, we tried to experiment building something largely using serverless functions, right, on on AWS with with Lambda functions. And we were like, let's never do that again.\u003C/p>\u003Cp>Like, that was horrendous. Like, it just slowed us down. It was like that we didn't see the benefits of the you know, that we that we were expecting to see. Let's let's let's not do that again. Like, making sure to do that, right, and have that process.\u003C/p>\u003Cp>And, yeah, I think there is that concern of, like, if you've baked something in and now, like, do you need to rip it out if if it's not great? But I have an element of pragmatism of, like, if something works, then it's prob like, you maybe don't need to worry too much about the thing that you've built if it's not working, like, especially on the engineering side as engineers. Engineers love things to be, like, perfect and and technically correct and engineeringly, like like, neat and tidy up. And I strongly push against that all the time. Like, as much as I can, I try and push against that because I think that it's too easy to fall down that hole versus just being like, well, what you know, is it really valuable for it to be perfect?\u003C/p>\u003Cp>Or, sure, it might be a little bit unmaintainable, but, you know, how long is it gonna last anyway? Like and is that thing gonna completely change in in 6 months or a year because the business has moved on, the idea has moved on, the product has moved on? Maybe you're gonna get an opportunity in 6 months to just throw it away anyway because the value the direction has shifted. So I wouldn't worry preemptively about kind of refactoring something just because you're worried that it's gonna be a bit less maintainable.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. I guess it depends if you're building whatever the tech stack is or the project at, like, the foundational level or more the facade, you know, that's gonna just like, a ephemeral, microsite or something like that, or product that's gonna be I I think it was also a piece of it is, like, even if you like it, you know, David or Stu or your teams are like, oh, this is amazing. You know, 3 JS, not a good example here, but, you know, the kind of the rug being pulled out from under you if it's like it stops being so popular, and something else kinda comes in. Like, oh, Sketch is the right meme.\u003C/p>\u003Cp>Sketch is the right tool, and then you go over to Figma. I was on I love Sketch, and then suddenly I was like, no Figma's Yeah. Absolutely where where the future is. And then there's been lots of projects where, like, an open source maintainer just disappears and then Mhmm. Love it, but it just isn't available or it's just not the right tool.\u003C/p>\u003Cp>Or you've got the the niece of the the client, kinda recommend some some tech tech, and they're like, oh, this is what we have to use. This is a requirement. I'm like, oh, well, why? That's not Mhmm. The right job.\u003C/p>\u003Cp>Speaker 2: I mean, the thing with the thing with, like, stuff being abandoned or whatever, like and the and the risk of that is, like, well, like, how much were you sped up by using that thing in the first place, and how much are you now being slowed down by it being abandoned? Right? Like, you gotta you gotta look at the whole picture. And, like, you know, you you can't necessarily tell what's gonna what's gonna, like, be less supported or is not gonna be the the favorite going forwards. And it's like, you know, if it helps you at the time and at the time you evaluated it and you had a good evaluation process that you can kinda stand behind and you're like, yeah.\u003C/p>\u003Cp>We decided that that was the right thing at the time. And now in hindsight, it was a terrible choice. But also, like, we were sped up at the time, and we got the job done, and we delivered the project. Like, what, like, where do you wanna be? Like, do you want the thing or not?\u003C/p>\u003Cp>We could also stay at decision paralysis at the start of the project forever and just wait to see which thing comes out as the best. That is true.\u003C/p>\u003Cp>Speaker 1: This is part of the reason I like to, comment my code so heavily to document those decisions\u003C/p>\u003Cp>Speaker 0: poor,\u003C/p>\u003Cp>Speaker 1: you know, whether they turn out to be better in the future. Also, because it may seem altruistic at first, but it's mostly for me,\u003C/p>\u003Cp>Speaker 0: you know,\u003C/p>\u003Cp>Speaker 1: 6 months down the road looking at your own code being like, why? Yeah. Why did I do this?\u003C/p>\u003Cp>Speaker 0: And then to read like,\u003C/p>\u003Cp>Speaker 1: oh, this, you know, this very minor edge case is gonna be\u003C/p>\u003Cp>Speaker 0: There's nothing worse than, like, you go into your old code, and you're like, that's not the way that should be.\u003C/p>\u003Cp>Speaker 1: Why did I\u003C/p>\u003Cp>Speaker 0: do that? And then you, like, try to fix it. And then, like, 2 days later, you're like, oh, that's why I did that.\u003C/p>\u003Cp>Speaker 2: Yeah. I can't oh, yeah.\u003C/p>\u003Cp>Speaker 0: That makes sense.\u003C/p>\u003Cp>Speaker 2: I always I'm always writing comments and encouraging the team to write a comment. You know, if you're just, like, hacking a fix in, but it's because you've got no time, add a comment being like, hey. Hey. I know this isn't great, but, like, I'm I'm under time pressure right now. Right?\u003C/p>\u003Cp>And just and just, like, being being nice to your past self and and your past team selves when you're looking at code and you're like, what the hell are they thinking? And it's like, well, maybe they were, like, under super client pressure at the time or, like, you know, didn't have the full picture of what was going on, and and now you do. And it's like like, that's the like, software is the the clue is in the start, but it's soft. Right? You can change it.\u003C/p>\u003Cp>It's Okay. If it's bad today, you can someday, if it's so bad, you can fix it. You can do something about it.\u003C/p>\u003Cp>Speaker 0: Yeah. And you're not, I mean, you're not really intimating unless you're breaking things. Yeah. Right. You gotta just document those breaks, why those breaks are there intentionally and with nice fun emojis right there in the comments and the GIF.\u003C/p>\u003Cp>Yeah. So I'm curious, you know, when starting the creative process, you know, Stu, I'll I'll throw this over to you, and, you know, there's obviously Jed's other point. You have lots of things that, you know, back when we were, like, I like, living together and you were working through these really exciting projects, and now there's probably more enterprise y, large scale projects. But regardless, when you're starting a project like that from scratch, you're sort of in the initial ideation, you know, r and d\u003C/p>\u003Cp>Speaker 1: Yeah.\u003C/p>\u003Cp>Speaker 0: Phase? Like, how what does that look like for you, like, moving through that process from, you know, 0 plus?\u003C/p>\u003Cp>Speaker 1: Yeah. Well, in some ways, I feel like such a dinosaur that I'm almost embarrassed to to talk about it. But, I'm I'm really into physicalizing ideas. And, obviously, I'm a tech guy. Right?\u003C/p>\u003Cp>I don't think we'd be having any of this discussion were it otherwise. But, and yet, pen on paper, Sharpie, just, you know, paper's recyclable. It's cheap. You can burn through ideas. The worse the scribble, maybe the better.\u003C/p>\u003Cp>And then being able to physically tape up or pin up that stuff so that your your memories are anchored physically around you, and you can refer to a cluster of ideas. And so I know it feels like most people don't work that way in 2023, and it feels like a very old, mammalian kind of, you know, I need to physically represent things in a certain time and place, but, yeah, that's that's how I'll start to formalize the very cloudy ideas in my head. And then from there, I'll start, you know, sketching in, maybe in Figma, if we're really honest, sometimes illustrator still, or directly in code. And, you know, code's so wonderfully flexible that, yeah. So, yeah, for me, it still begins with a a physical process.\u003C/p>\u003Cp>Speaker 0: Interesting. Yes. I like, I've seen a lot of that, like, working with companies like IDEO. They're big on, like, sticky notes. I remember back in, like, school so are you is it, like, printout paper, like, no lines, line paper, grid paper, field notes?\u003C/p>\u003Cp>I'm so curious.\u003C/p>\u003Cp>Speaker 2: Like,\u003C/p>\u003Cp>Speaker 0: paper is pretty tense about a space stationery. Sticking up to your walls.\u003C/p>\u003Cp>Speaker 1: You know, back back when we lived together, ancient times and, and Yukon, really, I mean, I was all about those, Rhodia grid pads. You know? I needed the grid. Yeah. I'm sure you have some within reach.\u003C/p>\u003Cp>Probably.\u003C/p>\u003Cp>Speaker 0: There's a lot. I have, like, literally just from, like, from those times and just I'm like, in my head, like, yes. That's exactly what I need. It's just pads, field notes, grid paper, like, just every sort of paper. Like, yes.\u003C/p>\u003Cp>Right tool for the right jobs. Like, sometimes you need a grid, sometimes you don't. It's like an home and joy.\u003C/p>\u003Cp>Speaker 1: Yeah. I I started to migrate, around I guess when I when I went back to school, I realized I started getting all of these notebooks that were just, blank paper, just blank, no grid. Yeah. Just no rules. No no constraints.\u003C/p>\u003Cp>Oh, there must be speaking of, like,\u003C/p>\u003Cp>Speaker 0: the design the intersection of design development, sorry, Code and creative. I feel like there's the intersection of, like, sticky notes in a in a notepad, like, in a, like, spiral notebook. There has to be I mean, I guess maybe it is just a sticky pad, but something a little bit more formalized. So it's like a book, but you can just pull it out and it's got the sticky Mhmm. Right there on it.\u003C/p>\u003Cp>We'll we'll get there. I like that. So, David, any thoughts on that? Like, when you're starting starting your process, anything specific beyond sort of taking into the world with with stickiness?\u003C/p>\u003Cp>Speaker 2: Yeah. I was thinking actually about that that thing where you said, like, the worse the sketch, the better. It reminded me of, you familiar with the process shape up from, from base camp and 37 signals. They have like a whole dot. There's a, if you Google it, you'll find it.\u003C/p>\u003Cp>And they, they talk about thick marker wireframes, Right? So using, like, a really thick pen to draw a wireframe so that no one can get bogged down in the detail of, like, how you know, is this thing this size or that size? Is it adjacent to that thing or above it or or to the left of it? Like because it's like the you've used such a thick marker that you can't tell the detail. You can just kinda get an idea of the rough shape, is like a that's what it made me think of when you were like, the worse the sketch, the better.\u003C/p>\u003Cp>I'm like, yeah. I definitely see the value in this.\u003C/p>\u003Cp>Speaker 1: Engineer that. So working on some very early was yeah. Wow. This was web based VR stuff in, Creative Lab around, like, 2015, I guess, maybe 2016. So, we were kicking around some ideas, potential product tie ins, things like well, I won't mention what we were working on exactly, but it involved us making some sketches of things in VR and these were early prototypal things that we were going to use to excite the people with the money in the company and then get the budget so that we could outsource and bring in you know, modelers and and, you know, hardcore VR engineers, and then we could start to build the thing.\u003C/p>\u003Cp>But the problem was making these prototypes. They looked terrible. You know, they're mostly, you know, low poly things that we could make quickly And that was lost on a lot of our higher ups and executives. They'd put on the headset and they'd be, why is it so terrible? And we kept trying to say, this is a sketch.\u003C/p>\u003Cp>Don't you understand that that looseness and terrible, you know, the slow it looks like, you know, lawnmower man because we're not spending money or too much time on this. And no matter how many words we tried to use to verbalize it, it didn't come across as a sketch. And this was, shortly after Google had acquired, Tilt Brush. And Tilt Brush did not have a scaling feature in it yet. It was early days, and we were making this cityscape and it looked terrible.\u003C/p>\u003Cp>So I had this idea, we need to do the napkin sketch for VR. So what if, just in my living room at home, I had my own VR rig. What if I could use Tilt Brush to hand draw the cityscape so it looks like a sketch? But you needed to be inside of it, and you couldn't do that yet. You could only draw as tall as you could reach.\u003C/p>\u003Cp>That was the, you know, the limitation of Tilt Brush. But now I knew these folks. They were part of the Google family, so I was able to just email them and say, hey, I need to scale up these drawings. How could I do this? And they were able to send me, you know, some Python code and and walk me through how their, Tilt Brush files were organized, how I could break them apart, you know, increase the size of all the vectors, which is pretty easy operation.\u003C/p>\u003Cp>It just wasn't in the interface yet. Put it back together and then open it. And so ultimately, that's what we did. The next walkthrough was literally a sketch of what we were trying to make. So it was really like the reverse pretending that it's still on the napkin.\u003C/p>\u003Cp>Yeah. I think that communicated a little better that this is a stand in for the real idea. And if you like this, give us the money, and we'll go do the real idea.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. I love that. First of all, Tilt Brush is amazing. I remember the same thing just in there just building.\u003C/p>\u003Cp>I think I feel like they had a scale feature or maybe not, actually. Yeah. Probably not.\u003C/p>\u003Cp>Speaker 1: I think they know. They didn't or before\u003C/p>\u003Cp>Speaker 0: They chose the app. It's never happened to you.\u003C/p>\u003Cp>Speaker 1: Yeah. Oh, yeah. Now, I mean, by the time that app was deprecated, it was trivial to scale things up and down. Yeah. But in the moment, we had to\u003C/p>\u003Cp>Speaker 0: I think it's important. Like, the idea of, like, a rough knock or, like, those prototypes where it's like you have to enforce the rough because if you go too far, I was guilty as, like, a perfectionist. I'm like, oh, I'm making these these mock ups or whatever it might look like in the really early just pitching things. And if you, polish it too much, it's it just seemed it comes off as like a design that they start nitpicking like, oh, how do we change that? Like, we're not even looking at that.\u003C/p>\u003Cp>We're looking at, like, broad strokes here. But the more detailed and accurate you make it, then they start focusing on different elements of it. So it almost helps to have, like, Tilt Brush. I'm just gonna swap this out there and just, like, see you know, just only comment on what you can see. And when you start adding and predifying it, becomes a very different conversation is is what I found.\u003C/p>\u003Cp>Speaker 2: I also think it reminds me, like, as a as an engineer, like, I think about these things maybe with like, I draw a lot of technical comparisons. And I think about, like, when you're coming up with ideas and trying to, like, come up with a solution to a problem or or come up with an idea, I think about it as, like, not locally optimizing down one path. Right? And it's, like, going to if you go too detailed too early, I sort of think about it as, like, I don't know if you're familiar with this sort of, like, approaches for for for sort of, like, machine learning or finding finding optimum solutions to problems of, like, the difference between, like, a hill climb algorithm versus simulated annealing. Right?\u003C/p>\u003Cp>You may be familiar with these. Like, the idea of a hill climb is like if you're sort of, like, searching through a problem space, you just go to the next best problem the next best, like, answer and then the next best answer and the next best answer. And eventually, you get to the top of where of the answer, and you're like, that's the best one. But what you didn't know was that the other side of that hill, there was another much bigger hill that was like an even better solution that was just totally different. But you couldn't get there because you were just, like, going down the better and better path and you weren't, like, exploring other options.\u003C/p>\u003Cp>And then simulated annealing is the idea where of, like, when you start trying to find the solution, you have an element of randomness where you're always just like, you're sort of you know what the best you found so far is, but you then also randomly just kinda, like, go wildly off piste and try something completely different and go, is that better? And then you're like, no, no, never mind. This is actually the better thing. And then sometimes you find those completely different solutions, and you go and explore. So yeah, right.\u003C/p>\u003Cp>Very similar. Very similar.\u003C/p>\u003Cp>Speaker 1: Yeah. You're also describing I'm not going to do this justice, but the difference between gate based quantum computing and annealing Oh, really? D Wave does. Yeah. And their, gate based is winning for sure, but, there's some pretty good arguments, I think, for quantum annealing still.\u003C/p>\u003Cp>Right. But it's the same, I won't derail this further, but it's the same sort of math.\u003C/p>\u003Cp>Speaker 0: So like,\u003C/p>\u003Cp>Speaker 1: you know, I mentioned, like, having to learn to multiply matrices again and, like, you know, reteaching myself linear algebra for 3 d stuff. And, you know, all that computation is best handled by a GPU, you know, massively parallel small computations. And then you start to realize it's actually pretty similar similar for, artificial intelligence and machine learning, you know, model training. And then it turns out, again, it's the same old story for quantum simulation. So, yeah, that's how that's how I bounce through those things.\u003C/p>\u003Cp>But I'll\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah.\u003C/p>\u003Cp>Speaker 1: I'm derailing. So What's more\u003C/p>\u003Cp>Speaker 0: what's more exciting than quantum I mean, I don't I know nothing of quantum computing, but what could be more exciting than than going off the rails there?\u003C/p>\u003Cp>Speaker 2: I once, I once met someone who was at a at a wedding who's, like, doing research in quantum computing, and I was like, oh, this will be interesting to talk about. Like, I I'm a you know, I'm an engineer. I know a little bit about this kind of stuff maybe. And And I was like, so tell me a little bit about what you're working on. And I think I got a best one in 10 words that he said.\u003C/p>\u003Cp>I was like, I have not like, you have just immediately lost me. Because he was in some kind of, like, world to do with, like it was something to do with about how you measure the output, and there was some very specific detail of what he was looking at. And I obviously cannot remember it. I did not understand it at the time. It was fascinating to just hear someone talk about it and realize that I'm like, I I'm getting 1% of this.\u003C/p>\u003Cp>Speaker 1: Yeah. But if if you think it's an exciting topic, I have a recommendation, which is, this guy who was at Microsoft at the time, Andrew Hellwer, I think is his name. I think it's h e l w e r. He gives this lecture that you can find on YouTube, and it's named after clearly his favorite book on the subject, which is a great book. It's called Quantum Computing for Computer Scientists, And, I've forced myself through the book.\u003C/p>\u003Cp>His lecture is so much more to the point and beautiful in its simplicity. He throws away all of the bad metaphors about, you know, cats in boxes and, you know, pizza bagels. Is it a pizza? Is it a bagel? It throws that away, and it gives you the very basic math, from a computer scientist perspective.\u003C/p>\u003Cp>And from there, that's that was my entryway because I was trying to figure out, like, what is the super cool quantum, quantum computing, quantum physics, whatever superposition? And because of him, I can now give some pretty concrete answers about what's a cubit and how does it work, at least from a mathematical perspective. The actual physics of this stuff is\u003C/p>\u003Cp>Speaker 2: Of how that stuff works is, yeah. It's I feel like\u003C/p>\u003Cp>Speaker 0: I'm in much easier to get the Schrodinger side than the math side. I'm a visual No. No. No.\u003C/p>\u003Cp>Speaker 1: A a cubit is just two values. That's it. It's just a pair of numbers, and then you can build from there. That's it. Yeah.\u003C/p>\u003Cp>It's just a pair of numbers.\u003C/p>\u003Cp>Speaker 0: It's only that easy. We're just period and then end of end of the whole lecture. Yeah. So to kinda, like, bridge quantum computing, which is I'm not gonna say inaccessible until you listen to that lecture and you really understand all about it. So, like, AI and something that is, for a lot of people, you know, very inaccessible in terms of really understanding how it's all happening behind the scenes.\u003C/p>\u003Cp>But there is sort of a resurgence or not resurgence, but a continued resurgence of, you know, AR and VR and AI, all these things kinda, like, coming to a to a front. I'm curious, what do you think so specifically on the on the ARVR side because I think there's probably more experience there. Stu or David, any thoughts on how that's gonna change the landscape in terms of, building online experiences?\u003C/p>\u003Cp>Speaker 2: I mean, I just I That's definitely one for handle, you know, like, can't\u003C/p>\u003Cp>Speaker 0: stand those people with community on its name. You know, from from professional to prosumer to consumer and then just keep working its way down the tree. I'm curious what your thoughts are on, like, what do what do think the the issues might be, the challenges, the opportunities, the cool stuff that might start flowing and maybe when, in the ARVR space?\u003C/p>\u003Cp>Speaker 1: Well, I I think it'll take me a moment to process\u003C/p>\u003Cp>Speaker 0: what I\u003C/p>\u003Cp>Speaker 1: can talk about and what I can't talk about. So I'll I'll start with a story from the the pandemic, or, well, let's say lockdown. It's still a pandemic, right? We're still anyway, in fact, I'm almost officially, one line again on the COVID test Just\u003C/p>\u003Cp>Speaker 0: a\u003C/p>\u003Cp>Speaker 1: Yeah. That was my past week. So we were we were working on something at Amazon, a side project that had to do with warehouse spaces and developing a sort of kiosk that would be for internal use for, you know, a specific task. And we're all working from home. We're all trying to figure out how to do that and also work on projects together.\u003C/p>\u003Cp>And, to develop this kiosk, I really what I really needed was to have, like, a bunch of different TV screens and things delivered to my home and to have someone prototype these things together. And then I could say, like, you know, this is too big, too small, in the wrong place, whatever, and that just wasn't happening. We just weren't at that point as a society to make that possible, nor do I really have warehouse space in my small Brooklyn apartment. But what I could do was very quickly mock up all of these things, using Amazon Sumerian, put on the headset, and walk around in that space and and get a sense, you know, style, in relation to the size of my own body and feel like, oh, okay. So if this is proper scale, this one feels right.\u003C/p>\u003Cp>This one doesn't. You know, this is somewhere in between. And it's an immediate gut reaction, and it cuts out all of the guesswork just being able to be virtually in that space, without having to pay for any of the hardware, have it shipped, have it set up. So that that may be a safe way to start to tiptoe into answers here to that question, hopefully.\u003C/p>\u003Cp>Speaker 0: Yeah. No. I mean, a 100%. I mean, I've it's it's interesting just the spatial side of it because you're you know, obviously, it's immersive, but that means, you know, we are directional as a as a animal. You know, we see this way, but it's you know, there's things going on behind you, and so it's just a whole different landscape.\u003C/p>\u003Cp>You know, what you what you kinda mentioned, I think, kinda ties into the fact that, you know, it's it's just a completely different ballgame. It'll be a different mindset for how you develop and build in that space. How do you hint to somebody that, like, you're supposed to be looking behind you? So, like, maybe maybe turn around and go look at that call to action or whatever whatever that might look like.\u003C/p>\u003Cp>Speaker 1: Yeah. Oh, for that, I mean, shout out to, former colleague, Jess Brillhart, who's a big name at Creative Lab and now continues to be a big name on the West Coast. She gave the keynote at South by Southwest a while ago for immersive experiences. She's a filmmaker by education, and has a lot to say about directing attention and focus in a 3 60 degree medium, and I say 360 because at the time, it was really 3 60 film. So it really it really was like rails in a circle around you, and, of course, immersive is, you know, that on all axes.\u003C/p>\u003Cp>Speaker 0: Yeah. The 360 day, that was the project that I was working on at, that large company that got 90% of the way there and then got scrapped because of video content being lacking. So ARVR is pretty exciting because the content doesn't lack. You just create it. It's a little bit more generative, so that's, a different different space.\u003C/p>\u003Cp>But, so we're coming up on an hour. There's a a bunch of questions that came in, but I don't know if we're gonna have time for those. But, yeah, any any what's that?\u003C/p>\u003Cp>Speaker 1: Oh, no. I feel I feel bad. We should get to Well,\u003C/p>\u003Cp>Speaker 0: I some of them. Let's throw we could throw one in because I think it kind of brings us back to that sort of the intersection space, which the question was, do you have any strategies around fostering collaboration culture between designers and developers? And I'll just quickly like, I this is a big thing for me at Ranger, my my old agency, because, I I was both. So I was, you know, I was the intersection, and I just tried to hire people that were the same, you know, that had the same sort of, like, training or or background skills, that I had. And And so I was able to avoid that altogether.\u003C/p>\u003Cp>You know? And I kinda even pitched that in meetings. I was like, oh, there's the Harvard, like, oh, we're gonna have the seating chart. You know, and we're gonna have our designers here and developers there, and here's how they work in pods and all that. And I was like or you could just avoid the communication altogether and just make them all, you know, it's kind of pre creative technologies, you know, as you turn.\u003C/p>\u003Cp>Any thoughts on how you can foster that? Like, if you have teams of, like, strictly developers and strictly designers, how you can, marry the 2 of those for either of you?\u003C/p>\u003Cp>Speaker 2: I've been thinking about this a lot at the moment. Because as an as an agency, we don't have any designers at the moment on us on staff. So we work a lot with third party designers or design teams or freelancers. And so I've been thinking about this a lot because we've it's always been a challenge. We've never quite hit on the right process, and we still haven't hit on the right process.\u003C/p>\u003Cp>But some of the things that I think about is, like, I think the best devs are the ones that know a little bit of design or, like, good UX and goods, like, like, understand what, you know, some of the, like, just kind of, like, basic underlying principles about what's good and bad design. And the best designers are the ones that understand a little bit about what are the limitations of the medium that I'm delivering into. Right? My worst experiences of working with designers are people who are print designers by trade and haven't really adapted to the web and that but are just doing some web design stuff as well. And it's like that is just such a different world that, like, it it doesn't align.\u003C/p>\u003Cp>Similarly, I've worked with devs or or or, like, helped look after devs who don't who just don't intrinsically understand anything about good or bad UX. And so as a result, we'll, like, implement designs badly or, like, not even put the right kind of boilerplate and skeleton in place to kinda unlock further development on top. And then, otherwise, I think, like, just a lot of side by side work. Right? Like, just making sure that things are iterative, making sure that it's about, like, responding to challenges, especially when it comes down to kind of delivery.\u003C/p>\u003Cp>The worst projects are the ones where delivery of designs is a cutoff point. Okay. Now start the designs. Now start the implementation. Sorry.\u003C/p>\u003Cp>And the best ones are the ones where, like, every small stumbling block of, like, oh, this is actually really hard to lay out on the page, or this is actually really hard to bring to life. Like, but if you just change would it be like, if we just tweak this, it'll be way easier to do. And then, you know, having that kind of that process of, like, it's not about, like, criticizing the designs being wrong. It's about, like, work working within each other's limitations, the space of delivery, and the space of design. I think that that works best, which is maybe a maybe an obvious answer.\u003C/p>\u003Cp>Speaker 0: Yeah. No. But an important one. I mean, again, like, not to get into methodologies, but, like, the waterfall, you know, especially if the designers are just not aware of what they can or can't do can be really problematic. They have to progressively enhance, and they have to know the limitations.\u003C/p>\u003Cp>And if you only find that out once things are done and polished, you're you're in a bad bad spot. But Yeah. Stu, any any thoughts on that one?\u003C/p>\u003Cp>Speaker 1: Well, I feel like I have a similar experience as you. So educationally, I think we're both taught print design, but, of course, with, that's not our trade at all. You know, we're in the code from an early age, so that sorted itself out. Still big love for good print design though.\u003C/p>\u003Cp>Speaker 2: Yeah. For sure.\u003C/p>\u003Cp>Speaker 1: But like you, I'm that intersection and I kind of, my present team excluded because I love my team, so I don't wanna give the impression that I don't. I think outside of my team, what I've experienced in the past is that, like, it's the 2020s. Why are these things still separate? They should all be me. That sounds very narcissistic or very arrogant.\u003C/p>\u003Cp>I mean, like, I accidentally somehow had these two influences and I'd like to think it was special. That should no longer be special. It's the kids coming up today really ought to have a foot in both worlds and may specialize in 1 or the other, but it's just so weird to me to meet young folks who don't, who seem to be firmly in one camp or the other because it just seems like evolutionarily, that that's just how it should be today.\u003C/p>\u003Cp>Speaker 2: Yeah. And you can actually see\u003C/p>\u003Cp>Speaker 0: When I would hire people at Ranger, I was I used to talk about, like, this t shaped tire. You know, you've got, a deep dive in their area of specialty, but then a crossbar of understanding so they can communicate with the other teams. You know? I'm a I'm a friend developer, but I can talk to the designers in the back end database. But Yeah.\u003C/p>\u003Cp>Now I feel like I need to update. Maybe it's like a capital m, and it's like you got a couple deep dives, a little bit more, you know, jack or jill of all trades. You you understand this and that. You're kept but you're a little bit more sprawling with the adjacent sides of you know, print design can be super relevant in how you do digital design, which can be really key in how you do UX and UI. And, you know, I think it all is really just makes a more robust, experience in person, when they're a little bit more multifaceted.\u003C/p>\u003Cp>But\u003C/p>\u003Cp>Speaker 1: yeah. I just wanna reiterate again, love my team. It's just it's in the back of my head because we were our team was having this discussion recently. And so, you know, shout\u003C/p>\u003Cp>Speaker 0: out to Yeah. That's a huge one. I I completely agree. I I watch sci fi movies all the time. I'm like, man, this is I watched the old sci fi movies.\u003C/p>\u003Cp>Like, they're saying, like, by 2020, we're gonna be in a very different place than where we are actually. I saw one last night with a creator, which was very timely with, you know, the AI stuff, and it was and it had some amazing not print design, but sort of that feeling to it. So I think, yeah, there's lots of ways all this can get pulled together. I but I think it all comes down to that intersection. Whether intersection is inside of one person, you know, they're they're both as, you know, I think the 3 of us are, or you can foster and bring together multiple people across a team and make that team sort of the the whole of of this idea of that intersection.\u003C/p>\u003Cp>I as I mentioned, I love metaphor, and I'll leave I'll leave us with, a story from when Stu and I used to live together. So we, you know, probably riding around the kitchen with on a unicycle or something. But, at one point, we had a a microwave, and it was, you know, just a throwaway junkie microwave we found. We're like, well, we're not gonna use it. We're just gonna trash it.\u003C/p>\u003Cp>And so we're like, well, what can we microwaves, you know, as as as younger people do? And so we we put, like, soap in there, and, like, soap was doing cool stuff and all that. And then we figured out, the the, you know, the ultimate test was this grape. And we just cut a grape in half, and you sort of leave the two halves of the grape just slightly connected. And it essentially the sugars or whatever it is, it forms plasma, and this ball of plasma rose to the top of the microwave and literally was melting the metal.\u003C/p>\u003Cp>But it just came to me while we were talking, and I was thinking back through all those those sort of things that happened. I was like, that's the intersection of design development. You have just, you know, 2 things to these 2 halves. This could be very different, but just you have that connection, and then suddenly you've got this plasma ball that's burning right through the top. You're innovating to the point where you're breaking things, and that's what we're all trying to do.\u003C/p>\u003Cp>Speaker 2: So And then your microwave explodes.\u003C/p>\u003Cp>Speaker 0: And then the microwave explodes. And then\u003C/p>\u003Cp>Speaker 2: it was I\u003C/p>\u003Cp>Speaker 0: burned up the the I burned up the Yeah.\u003C/p>\u003Cp>Speaker 1: I had the cord, you know, just ready to pull out anything whenever\u003C/p>\u003Cp>Speaker 0: At least we had yeah. We had the the fire extinguisher and the cord ready to get pulled, but, no, it was awesome. And I'm just trying\u003C/p>\u003Cp>Speaker 2: to work out where that was going as you were saying that. I was like, where is this where where is this coming back\u003C/p>\u003Cp>Speaker 0: You just We made it again. Awesome. Well, a little over time, but I this was super like, just I love just meandering through these these different topics, and and, I I think that's what it's what it's all about. How can you be creative if you had everything super structured? So, yeah, David, Stu, thank you so much for for hopping on and chatting through this.\u003C/p>\u003Cp>Hopefully, we can we can do it again sometime. This was this was awesome. Yeah. Make sure it happens.\u003C/p>\u003Cp>Speaker 2: Cool.\u003C/p>\u003Cp>Speaker 0: Alright. Thanks, guys.\u003C/p>","Awesome. Well, super excited, to be diving into this. I think it's gonna be a really exciting conversation. Obviously, this is I've built my entire life around, like, the idea that we're talking about. I think we all kinda have, so it'll be hopefully some some interesting stuff to cover. Why don't we kick it off with some intros so everybody kinda knows who's who's chatting, and then we can get into the theme. Stu, do you want to kick it off with with an intro? Yeah. Sure. Let's see. What's a good, succinct way to put this? I have both a graphic design background and a coding background, so design and engineering together, which is awesome. So I speak both both vocabularies. It didn't use to be awesome, I feel like, then when we were young. It made us kind of an outcast in both worlds. Maybe I'm speaking too much for myself. So I've worked at Google and Amazon and various other places, and I'm currently at Unity Technologies. For the for the second time around. Right? For the second time around. Yeah. I was pretty torn about leaving the first time around. I left to pursue something pretty interesting, and very happy to be back in the family with a lot of folks that I really enjoy solving tough problems with. And I should probably mention that spans like creative technologist stuff, augmented reality, virtual reality, a little bit of quantum computing thrown in there. But, yeah, it bounced around between product design, marketing, research work. It's all fun. Definitely. Yeah. I've probably known for 20 20 years, over 20 years maybe. Going all the way back to the beginning, you know, talking about, like, getting trained, whatever, learning, you know, design and development. You definitely kinda get this sense of, like, not jack of old trades master, jack of 2, master of, like, hopefully both, like, freedom and technology. They're just no different. But, yeah, all the way back in the the Yukon days. David, how about how about you? Maybe back from where you are now. Yeah. Great to be here. Thanks for having me. So I'm a head of engineering at a digital product agency, here in the UK called Pixielabs. We're London based. We design and build digital products, mostly web based or mobile based. We've been going for 10 years now. We had our 10 year party actually a couple of months ago, which was a lot of fun. And I've been with PixieLab since its inception, helping to initially writing all the code and increasingly my team not letting me write the code. And prior to that, I was, helping to kinda lead developments, at an innovation lab at News UK, or at the time it was News International, which is the publisher of The Times of London and The Sun, a big newspaper publisher here. And prior to that, my my background is very, traditional. I did computer science. I was I was a very traditional nerd and always have been, always will be. But, yeah, worked on a whole bunch of stuff under under the kind of pixielabs umbrella, everything from large companies, you know, people like Twitter and HomeServe, but also start ups and and smaller brands and everything, yeah, from, like, big platforms for Fitzy 100 down to cat food subscription websites. And we once made a thinking about, sort of like things that are the most creative, we once made a typewriter type by itself when you tweeted at it, for an art installation with in partnership with Twitter, which I get so much mileage out of in conversation forevermore. Like, that's like the one. It's like the one project where you're like, I can talk about this a lot forever. Was that at a museum perchance? Like, was that a museum over on your side? Yeah. It was like it was initially a there was like an art exhibition. They ran Twitter ran like a competition for ideas that were powered by tweets in some way, like any idea. Right? And people submitted everything from, like, pigeons flying around measuring and tweeting the air quality, all the way to the typewriter that was, like, typing out a a novel by through Twitter. And we had to, like, come up with some representation of all of these ideas that people had submitted or, like, 6 of the winning ideas. And then I think the typewriter ended up at the Globe Theatre as well, where it was typing the complete works of Shakespeare, but it would wait for the someone to someone in the world to tweet the next word that it wanted to type. It took months and I think really annoyed all of the staff like, in the corner, like, clacking away. This was a really loud old school typewriter. Yeah. So just randomly for someone to, like, say the word betwixt, and then it could keep on Yeah. Exactly. Exactly. And, you know, like it wasn't the I will admit it did have a time limit before it would just type the word and move on. Otherwise, I don't think it would have ever finished. I mean, you can just sit there and, like, be the one to keep it moving along. But Right. And that's the thing. You would stand in front of it. Right? And you could tweet the next word, and it would, like, tweet back at you saying that you'd you'd powered it. It was wild. The idea of an impatient typewriter. Yeah. It was. It was impatient. Yeah. You should just start tweeting out, like, prompts. Like, okay. Listen. We gotta get this thing rolling. Yeah. Please someone tweet this word. Yeah. Yeah. I did. So at my agency, which is called Ranger, we did something similar. It was with Google, and Teller, I believe, was, like, the creative side, that was pushing it. It was a museum, and they had oh, I don't even remember the one of those things you look through, the, periscopes, telescopes. Mhmm. But it was, like, all digital, and they had all sorts of, like, art museum installation stuff that was, connected to like, real world stuff that was connected to technology. So similar to what we're talking about today, you know, bridging the gap between the real world and digital, I think we're kinda getting more into the the creative and code or design and development depending on which alliteration you choose. I love it. Well, thank you both for for being here. This is, super exciting. So and then just kinda tap it off. So my I'm Ben Haines. I started, an agency maybe 15, 20 years ago, called Ranger out of Brooklyn, which is where Stu is right now, I think. So David's in the UK. Stu, you're in in Brooklyn. So I started in Brooklyn, really, with exactly what we're talking about. Like, I had seen a lot of development firms, and I had seen a lot of design agencies, and they were trying to communicate. And you just get a lot of the, the design hands off. It's like pixel perfect, you know, mock, or here's what we're here's what we're looking for. And, you know, the the development's like, oh, we built it. Here you go. But it's not really following the the design principles. They're not giving feedback on what's possible. Like, designers are really great at making things that look great, but not functional. So I tried to bridge the gap hiring designers and developers to build for, you know, Google, Snapchat, AT and T, Prada, US government, etcetera. But that's where this software Directus kinda stemmed from was, wow. Okay. So we're building these really innovative projects for those sort of companies, and, you know, smaller companies, culture institutions, etcetera. But we're building the same thing over and over and over again. How do you take maybe one of the more I mean, quantum computing, Stu, so you you got me there. But, like, the database is pretty technical. How do you make the database, you know, in the work of a a DBA, a database administrator, you know, how can you democratize that so the business user can do it and you you do it through design? You know, really strong intuitive UX and UI, giving you know, I I was inspired by PHP MyAdmin, which I think is maybe lacking design. I you know, Not not the best not the best system I've ever used. So I was like, oh, just take that and make it friendly and intuitive and safe. So that's where Directus, you know, our our software sort of stemmed from. But so today, we're we're kinda really covering the basis of, where all 3 of us live, which is are we gonna say design and development or creativity and code? I like I like both, I guess. I think I'm leaning towards creativity and code. Okay. Yeah. I would say design development, but creativity and code, I like it's not just design, I guess. So, yeah, that is probably better. So the intersection of those two things or the overlap even, I think we've all sort of built the whatever we've been doing for the last 10, 20 years has been has been right there. So, without further ado, why don't we jump in? So I guess to start off, Stew, you mentioned sort of, your history going through different large orgs, you know, AWS, Google, Yahoo, relatively structured companies or very large companies. I'm curious when we're talking about creativity and code going at the c's, how do you, like, encourage a culture of innovation at a company that's a little bit more rigid or, a little bit more red tape? Wow. I guess, the answer varies quite a bit depending on which context. So for instance, Google is a huge company. Right? And there's a lot of rigid structure in place necessarily. But what was really cool about Creative Lab and also, the data arts team is they were little corners of the company that, folks like Andy Barrett, who runs Creative Lab, he had won the confidence of his fellow executives to, say, we're gonna go off and do something crazy over here. Here's why it's justified. Here are the business reasons and marketing reasons and whatever, but we're going to go be a little nuts and you're going to sit back and chill. And so I'm so glad that like in that context, there's a very strong leader standing between you and a lot of that process, and it allowed Creative Lab to be a little crazy. And I I haven't been there in, quite some time. I feel like there's a little bit of a trajectory where it started to become a little more formalized, probably also necessarily. But I also remember the more Wild West days, literally, with a sword and champagne bottles and stuff, just impromptu on like a Tuesday evening because everyone's working late and major projects are due. So there are a lot of good it was a place where there could be some irreverence and the space and time for some creativity. Of course, things have to get done and they have to get shipped and delivered, so it wasn't without pressure for sure. Whereas I would say Amazon was a very different case and ultimately, I don't think AWS is just so not geared towards a creative process. So I think I lost the battle a bit there within AWS, which is sad. Yes. There's some great people there. But, I can imagine, like, just in the in the 2 you just described, you know, one has creative in the in the title, you know, in the team name and servicing. So, like, they kinda have maybe different focuses, maybe. But Yeah. For sure. Yeah. And that's that's pretty amazing. And I I feel also feel like, you know, the more emergent like, the newer the idea is for a team or for a company, regardless of how big it is, it's easier to be in that, like, divergent mindset and just be like, oh, we're gonna break things. We're gonna innovate. You know, that's one of the same. We're gonna be, like, super creative and just kind of push the envelope. And then over time, it's like, oh, we have real world things. We have to answer the investors, or we have to kind of rein it in a little bit and switch to convergent mode. Both of those are pretty established companies, but creative I don't remember when Creative Lab was formed, you versus I don't know. I wanna say maybe there were seeds of it in 2006 or something, which is well before I joined. That would have been I mean, it held on to that idea. Very fuzzy about the yeah. Yeah. I mean, held on to the the ethos of, like, create I mean, yeah, that's the purpose of the team. Interesting. And would you say the same thing for I think we we were talking recently. I think maybe there was some overlap at Yahoo between when you were there and when I was there, maybe not. But would you say the same thing for for Yahoo? Exclamation. Well, I think, I, speaking of returning to places, so I had been at Lab, went to Yahoo for a few years, then went back to Creative Lab and Dana Hartstein, which is a whole other story. So I think I entered Yahoo with a different mindset. The context was that Marissa Meyer had left Google, and she had taken over as CEO, and it was still the early days of that, so there was a lot of this optimism that Yahoo had built this giant, I'm gonna use metaphors here, had built this giant ship, and it was a brilliant ship. It was a big battleship out on the sea, but over time, its facilities have been squandered and things were not going so well. So Marissa climbs aboard and says, I'm the captain now, and you could go do a startup or you could go do something else and you'd have to build your entire ship, and that is a difficult lift. Or you could jump on this ghost ship and take all the good parts and rebuild them, and that seemed to be the mentality. We're all here. It's a new era. We already have all of these products and services and things that generate revenue and just let's use it. Let's build anew, from this kit of parts. And, so it was a pretty exciting time. And there, maybe I'm speaking too much for myself, but it felt like there's a bit of this sort of pirate mentality of like, here we are. Let's blow things up and let's reinvent. And because of that, I started out in marketing, had some success there. My biggest success there already incorporated cutting edge research, early days of machine learning, Marketing, obviously, design is what I was bringing to the table. So it was all like engineering, marketing, and design altogether. And because of that, I was in marketing, then I was in product, and then I was in research. So I literally, like, bounced around the company kind of doing similar stuff at every turn but with a different hierarchy and sort of a different set of rules being bent in in a new direction. I like that. I like that. So anybody on my team knows I'm a big fan of metaphors. And I I thought for sure, when you talk about breaking the ship apart, you're gonna go down the, like, the Theseus, paradox. Oh, right. Yeah. And I was like, oh, no. We're going pirates. We're doing pirates. I like it. That's that's amazing. Yeah. I think that that kinda makes I I I have always sort of worked at, my like, an agency, like self self employed with the exception of maybe a a year, year and a half at we were both, AOL, Verizon, Yahoo, which may or may not have had overlap with you. But, yeah, it was for me, they there was, like, creative freedom, but it was definitely, like, you can be creative until like, toward the end of the process, and then it's like, I hope you had fun because we're gonna shut that down, and we're gonna work on something, you know, something else that maybe is a little bit less fun. And which is almost more stressful because you get to work like, you get to take a project to 90%, and then they kinda scrap it. I just wasn't used to that way of working. It's like, oh, well, I guess that's that's how it's gonna be. So I I wanted a little bit more control and kinda stepped away. I was like, alright. I just need to be able to sail my own pirate ship, because even pirates, sometimes they're they're not hiring the way you wanna pirate. Yeah. If you if you wanna lament some of those, Yahoo things, I got it to a 100%. We had a a very successful marketing campaign that resulted in a patent, which is weird for marketing, and some other interesting developments. And I thought, wow. Okay. Based on the back of this, now it's time to start my own team. And, with the right group of folks, we could bang out a few of these every quarter, and wouldn't that be a good thing? And, it was tentatively called the Marketing Innovation Group, and I was so excited to take this remit that I thought I had earned and like run full speed with it, and that turned out not to be the case. For some reason, it was like, well, that was successful, but the analysis was for none of the reasons you listed. And after that, they never had a project like that again. It was like, all right. So I moved to product for a while with some other very crazy folks. Yeah. You get to meet different meet different teams. I was I was moving toward, like, the VR teams. We probably would have intersected at a certain point. Oh, goodness. That would have been a lot of fun. Yeah. Oh, yeah. Absolutely. But then I was where I was like, how far can I get down this road before whatever cool thing, you know, we dream up gets scrapped? So I I kinda stepped stepped away, but, I'm sorry. Well, so and, David, obviously so I shared some time, you know, with with the big companies like like Stu. You've been over a decade at your agency at Pixie Labs. I ran mine for a similar amount of time, and what I found or just in general, you know, agencies really have to stay at the bleeding edge of, you know, what's going on in terms of the tech stack, in terms of just everything from the the small, like, what's going on within the front end, you know, CSS and frameworks all the way up through larger trends, and things that you can pull into your process. Because you're not always like, the spec that you're giving from a given from a a customer or a client or whatever it is isn't. It's like the the goal, but how you get there and how you really push it is on the agency. And I'm curious. How are you making sure that your team stays on top of, you know, the creative and tech, staying ahead of the game and just leading, you know, leading that side of things. Yeah. Any any specific I mean, like, as an agency, right, you're optimizing for being billable and kinda remaining ahead of the curve and doing experimentation and things like that can really kinda run counsel to that. It's funny, like, you actually mentioned, Stu, about sort of, like, you know, having a corner of the company that had won the the confidence of execs and and things like that. Like, you almost kinda have to do a similar thing with time, right, and enshrine a a a portion of time where you, you know, for us at Pixielabs, it's like a day a month where we've sort of set aside as non client time, which is not a lot of time to really get a lot done. And, naturally, I'd much rather it would it was a bit more. But, like, having some time that is a little bit enshrined that you're like, this is the day when everyone feels okay with putting down the client work that they're on, you know, and which can be tough with deadlines and things like that and and try and, you know, use that time for a bit of experimentation. But, also, I think, like, there are some areas you can be flexible in an agency on projects. So I kinda try and look for opportunities project by project. Right? And sometimes it can be a bit of an exercise of bargaining with a client as well. So if you've got something where the budget's a little bit low, or maybe it's a for good thing and you're being asked to kind of, like, help, you know, help out something that is more charitable or something like that, maybe maybe that client might be a bit more receptive to you actually doing a bit of experiment you know, experimenting on that project. Right? Trying something that's a bit unfamiliar and just being open with that and saying like, hey. Maybe we're gonna try something a bit new here or work with something that's a bit more unfamiliar to us or, like, we have this idea that we don't know if it's gonna work, but we wanna try it and, you know, depending on the parameters of the project. I think that that there's an opportunity then. Also having, like, good relationships with clients, especially long standing relationships can help with that, especially if you're you know, one of the things that you do in an agency is, like, how can we get more out of a client? Right? Like, how could an existing client, how can we unlock more more spend, more investment in us? And having some ideas, having some things that are experiments, and I'm kinda trying to sell that as an as a kind of joint experiment. Right? And being like, well, let's experiment with this thing together that we see there's a potential for your business, and, like, we can help that make that happen, I think is also is also a way to do it. And I think thinking about the engineering team as well, just in general, like, you do have to make sure that the experiments kinda in some way, I think, align with, like, our goals and vision. Right? Like, if we're, like, we're primarily doing stuff sort of web and mobile. And so, you know, I don't know if I would be comfortable with it with one of my team, like, going wild and doing some experimentation with something hardware based or electronics based or or something like that. Like like, maybe, but I think that that feels a little bit too off piste, and a little bit of a challenge to justify. And instead, it's like, okay. Like, if there's something that's slightly out of our lane, but not massively out of our lane necessarily, unless that was something that we were like, as a business, we also wanted to move into. Right? There are definitely things, you know, that we're seeing on the horizon, like, that you you're sort of alluding to, that are like things that we're like, we do wanna try and move into that area. So those opportunities then maybe are a little bit more left field that then the team can kind of like explore a bit more as well. But, like, having a little bit of alignment, I think, is useful, especially in a small team and especially where you don't have a lot of time to do it. You don't wanna go too off piste. What do you think like, in terms of some of those things that might be on that horizon? I'm just curious. Trends. Yeah. Like, one of the one of the things that I'm increasingly thinking about is about Apple moving into the AR and VR space with VisionPRO and thinking about how big of a deal that is for that kind of side of things compared to even I remember when I was at news and we were doing stuff to do with augmented reality and scanning QR codes and putting 3 d models on bus on the sides of bus stops and things like bus shelters and things like that. And, like, nothing has really moved along for a very long time in my opinion. Like, it's sort of you know, there's not sort of been like a huge like, it was novel then. It feels a bit novel now still. But I wonder about, I pay a lot of attention to the fact that Apple are really moving into that space. And so that is something that as a business, we're like, that feels quite out of our lane compared to web and mobile, like, even though it is sort of adjacent. And so that is something that strategically I'm like, there's some there's some thinking to do here. Yeah. Oh, for sure. Yeah. I like it. I like that. And so it's interesting. So you're saying almost like you're you've got this I think, like, Google also had a lot of companies have had this, like, idea of, like, white space where 20% of your time or whatever they can afford, is given to their their teams to say, like, hey. Just build. Like, come up with the cool stuff. It doesn't it should be generally on task, but, you know, more proof of concept. But you kinda scope that to the projects, and you kinda budget it in and said, hopefully, if if there a client is looking for something a little bit more innovative, it's like, well, we're we're gonna kinda go off and do some like, a little r and d sprint as part of the budgeted time, or how did you structure that? Yeah. That's yeah. That's we're kinda talking about 2 different 2 different approaches there. Right? On on one hand, you've got the the, like, time that is for us specifically that we're kind of enshrining as non client time. But then on client projects, it's really about, trying sort of keeping keeping things in the back of your mind of, like, things that you'd like to do or things that feel interesting or worth exploring and trying to find opportunities to to kind of worm them into a project or trying to, like, sell them into to an idea that a client has or a problem that a client has and being like, oh, like, we actually think that that this, like, new thing that we've that we've seen that we wanna do a bit of experimenting with, you know, it's you've got a you know, finding something small that we can that we can, like, experiment with something on. And I'm thinking specifically there about new tools or new frameworks or things like that rather than anything too major, just sort of like really about kind of staying at the edge of, you know, the tools using the right tools and using the best tools, to to get the job done. Right? Yeah. I like I like that. So I guess that kind of is is pretty interesting. That kinda segues in. I would almost throw it back to to either of you, I guess, at this point. But, on that the tech side, you know, in terms of the stack, are there specific tools or platforms, that have been, like, pretty pretty crucial in building out the different projects that, either of your you know, you or your teams have been have been pushing? Specifically through the lens of, like, this intersection of creative and technology. Obviously, there's plenty to to go through in the tech stack, but I think this is a more nuanced space. Well, of course, Unity. I mean, I I do agree with Unity. Just, you know yeah. I'll leave it there. I won't pitch for my own company too much or the company I'm a part of. But so other than that, I would say, 3. Js. My goodness, Ricardo and team over the years, that was really the real entryway for me because I started out as a web guy. I started to mess around with 3 d, didn't understand it so well. And then after banging my head against 3. Js and relearning matrix multiplication and all that good stuff, it's it's paid dividends as, the web has become more powerful, WebGL and now WebGPU, and WebAssembly, you can do a whole lot of stuff. David, you had mentioned the there being a gulf between AR, VR, and, and the web and mobile. But I found with things like like the quest, I could do it so much through the web. It was really exciting. And that was one of the things that I worked on at Amazon was, their Sumerian product, which was pretty interesting. To me, the most powerful thing, it was all in browser, sort of like Unity lite in browser. The most powerful thing was the blue publish button on the top. You can make any experiment you want. And then the moment that you were ready to share it with the world, you hit that button, and it takes a few seconds, maybe like 10 seconds. And in that 10 seconds, it is taking your project and replicating it on all of Amazon's servers with all of its 9.9 whatever uptime, and you can immediately share that URL out to anyone. And I thought that was so cool. 9.9 uptime is not that great, Stu. Well, 99 whatever. Yeah. They do the they do the best replacement. Yeah. Yeah. But I mean, 3 JS, I mean, it's crazy. I mean, I guess similar to Directus, you know, what I've been working on, it's been around for a long time, but its relevance kind of can still be in the future. Like, it can become more relevant over time depending on I mean, 3 JS has just been, like, just such an amazing thing to not just follow along, but just to use, like, just browsing through the demo pages and all that and just being like, oh, I could kind of fork this idea and just run with it. It's such an amazing platform. I think there's all and then obviously being it's open source. I think it's MIT, obviously. Oh, yeah. Yeah. Yeah. Like, I think that's a big any open source tooling, is is a big win in my book. I've contributed tiny like, a tiny, tiny bit. For 3. Js? Yeah. Oh, wow. It's it's not really worth mentioning, because it's so small in the scheme of things. There are real contributors. You're doing it anyway. It's like, okay. Yes. I gave back a tiny bit to this tool that has helped me. We'll we'll call it a micro maintainer. There we there we go. Yeah. I like it. How about how about you, David? I think, like yeah. It's interesting. I I had some notes about thinking about tooling of things like 3 JS and and stuff in kind of Webexa land. Like, I think for for things that are around, like creative and bringing creative ideas to life, I try and think of, like, what are the tools that are like one person tools, right, where you can go from nothing to done. Like, you were just describing right where you're talking about, like, building, you know, working on an experiment and then publishing it, right. And you've got all of that tooling in place, that means that you as one person can go from idea to execution to deployment and, like, live and and actually in in the real world. Right? Like, it's boring, but we use, Ruby on Rails, right, as a as a web framework for for most of the stuff that we do, all of the web apps that we're doing. And that has the same kind of idea. Like, in fact, the the founder, David Heinemann Hansen, was saying this at the conference the other week of, like, it's like a one person framework. Right? It's like one person can do the front end, the back end, the deployment, the maintenance. Like, the tooling is designed to be used by one person and actually make, like, make a lift as one person rather than having something that is inherently complex or has multiple moving parts or you need to add more moving parts to it to bring it to life. Right? So that if you're sort of building something yourself from scratch in, I don't know, some some JavaScript framework where like, some back end JavaScript framework where you've gotta also work out the hosting and, you know, you've gotta decide, is it is it is it microservices based? Is it am I gonna put it in a cluster somewhere? Am I gonna you know, how do I how do I get this live? What do I need to think about? Like, those things start to turn into, like, things that you naturally split up into multiple people or you need, you need a person just keeping an eye on it every day and that kind of thing. And and so I really like, like, that's the kind of thing that I that I think about, of, like, what are what are the tools that are, you know, that are that are good for, like, one person that that cover everything from from from start to finish. Well, I feel like here's where we could also segue into direct us, which is I did have that I did have that written down that, like, you know, directors is kind of a bit of a one person tool, right, in the sense that it there we go. In the sense that it wait. Where can I get one of them? I haven't I don't have one of those on my desk. What is it? Hang on. I always have, like, a 1,000 of them printed, like, today, so we'll we'll touch base. Great. Yeah. Like, in the same way. Right? In in in the you know, it's like database. You've got APIs. Like, it's giving you all of the it's giving you the front end layer to work in. It's giving you the API layer to work in. There's a director's cloud hosted environment. Right? Again, like it is. It's it does feel like that kind of thing of, like, tool tool of tool of 1 team you know, 1 person teams kind of thing. Yeah. And I think, like and then, otherwise, I was thinking a little bit about, like, what tools do I use just to, like on the very creative end when I'm thinking about just, like, coming up with ideas? And I have to plug I have a special place in my heart for Excalidraw. Do either of you use Excalidraw for, like, for, like, putting together little diagrams of stuff? No. The comics at the end of, of Yeah. But it's it's I don't know what it is. It's something it's so aesthetically pleasing to use. You you open up Excalidraw, and it's like a blank it's like the classic, like, infinite whiteboard, infinite canvas type tool, but, like, everything looks like you've scribbled it. And there's and it has just the right amount of shapes and colors and lines and sizes that everything you make just looks I don't know. I look over my old Excalidraw drawings, and I'm like, these are all so nice. They all just it just makes everything look it's like just it's like just loose enough. It gets kind of reminds me of, like, balsamic mock ups, but I always felt like balsamic mock ups, the aesthetic of that never really kind of vibed with me. I think that is too Comic Sans of of mock ups, but something about Excalidraw, I just might Yeah. We we use that a lot just for, like, quick, like, oh, let's just go in there. I think, hilariously because I I believe, if I'm remembering the tool the tool correctly, it gives you, like, a one of those random names, whenever you join until you, like, register and say this is your actual name. Right. And the first time I logged in, I'm in with, you know, 20, 30 people, on the direct score team, and it it assigned me Tremendous Beaver, was my my written name. And I I think that still floats around in our Discord server. So, but, yeah, I think it's that balance. I mean, right there is a balance of, like, looseness and, like, get things done. Right. Striking that balance is really difficult. It seems easy, like, just with with design. Like, design becomes transparent when it's done really well. I feel like a tool like that, just makes it seem effortless. Hopefully, that's what we're trying to do with Directus as well. And you you mentioned sort of it's a good tool for 1 engineer, and I think another aspect or facet of that is when you can make that one engineer, that one creative technologist, whatever it is, seem like 10. You know, it's not just effective. You can do it yourself, but giving them the abilities of, like, oh, I'm just, you know, just front end. It's like, oh, this kinda allows you to be full stack and kind of build, at a full stack level. There's some marketing stuff in there somewhere. Yeah. You're right about that. Is there, like, a good way to assess? I mean, you have emergent tech. You've got, you know, AI. You've got all these amazing things that are kind of flowing out. And how can you use them, incorporate them into your workflow, be more efficient. But, also, sometimes when you're building it into the stack, especially the stack of a client, that might you're gonna build it and sort of deliver it, and it's gonna exist and maybe you have to maintain it for months here, how do you ensure that the tech that might be a little newer is actually stable enough? You know, it's, obviously, it's out of beta. It's all that. But, like, how do you know that it's the right decision? Or do you just say, like, well, we'll we'll learn from this, and maybe we won't use it for the next project. Maybe we'll have to rip it out, you know, 6, 12 months later. But anything in terms of that evaluation process? I think you've kinda talked you kinda started to touch on it, really. I I think that it's all about experimentation, and it's about time boxing and making sure that you have some time to evaluate at the end or or to have some kind of retrospective either as an individual or as a team of, like, how do we feel it when using that new technology or experimenting with that new paradigm or new approach? Like, did we like it? Did it did it and, you know, upfront deciding, like, is this gonna speed us up? Is the plan that is gonna you know, it's gonna make us happier to do whatever it is we're doing? You know, and and really making sure to be critical of the of the the work that you've done and the process you've gone on and be like and be willing to discard it. Right? And be willing to go, no. That was shit. Let's never use that again. Right? It it it really, like, it really slowed us down, or it was really error prone. Or, you know, we learned things like kinds of things. I was trying to think of examples of that, and I was like, we tried to experiment building something largely using serverless functions, right, on on AWS with with Lambda functions. And we were like, let's never do that again. Like, that was horrendous. Like, it just slowed us down. It was like that we didn't see the benefits of the you know, that we that we were expecting to see. Let's let's let's not do that again. Like, making sure to do that, right, and have that process. And, yeah, I think there is that concern of, like, if you've baked something in and now, like, do you need to rip it out if if it's not great? But I have an element of pragmatism of, like, if something works, then it's prob like, you maybe don't need to worry too much about the thing that you've built if it's not working, like, especially on the engineering side as engineers. Engineers love things to be, like, perfect and and technically correct and engineeringly, like like, neat and tidy up. And I strongly push against that all the time. Like, as much as I can, I try and push against that because I think that it's too easy to fall down that hole versus just being like, well, what you know, is it really valuable for it to be perfect? Or, sure, it might be a little bit unmaintainable, but, you know, how long is it gonna last anyway? Like and is that thing gonna completely change in in 6 months or a year because the business has moved on, the idea has moved on, the product has moved on? Maybe you're gonna get an opportunity in 6 months to just throw it away anyway because the value the direction has shifted. So I wouldn't worry preemptively about kind of refactoring something just because you're worried that it's gonna be a bit less maintainable. Yeah. Yeah. I guess it depends if you're building whatever the tech stack is or the project at, like, the foundational level or more the facade, you know, that's gonna just like, a ephemeral, microsite or something like that, or product that's gonna be I I think it was also a piece of it is, like, even if you like it, you know, David or Stu or your teams are like, oh, this is amazing. You know, 3 JS, not a good example here, but, you know, the kind of the rug being pulled out from under you if it's like it stops being so popular, and something else kinda comes in. Like, oh, Sketch is the right meme. Sketch is the right tool, and then you go over to Figma. I was on I love Sketch, and then suddenly I was like, no Figma's Yeah. Absolutely where where the future is. And then there's been lots of projects where, like, an open source maintainer just disappears and then Mhmm. Love it, but it just isn't available or it's just not the right tool. Or you've got the the niece of the the client, kinda recommend some some tech tech, and they're like, oh, this is what we have to use. This is a requirement. I'm like, oh, well, why? That's not Mhmm. The right job. I mean, the thing with the thing with, like, stuff being abandoned or whatever, like and the and the risk of that is, like, well, like, how much were you sped up by using that thing in the first place, and how much are you now being slowed down by it being abandoned? Right? Like, you gotta you gotta look at the whole picture. And, like, you know, you you can't necessarily tell what's gonna what's gonna, like, be less supported or is not gonna be the the favorite going forwards. And it's like, you know, if it helps you at the time and at the time you evaluated it and you had a good evaluation process that you can kinda stand behind and you're like, yeah. We decided that that was the right thing at the time. And now in hindsight, it was a terrible choice. But also, like, we were sped up at the time, and we got the job done, and we delivered the project. Like, what, like, where do you wanna be? Like, do you want the thing or not? We could also stay at decision paralysis at the start of the project forever and just wait to see which thing comes out as the best. That is true. This is part of the reason I like to, comment my code so heavily to document those decisions poor, you know, whether they turn out to be better in the future. Also, because it may seem altruistic at first, but it's mostly for me, you know, 6 months down the road looking at your own code being like, why? Yeah. Why did I do this? And then to read like, oh, this, you know, this very minor edge case is gonna be There's nothing worse than, like, you go into your old code, and you're like, that's not the way that should be. Why did I do that? And then you, like, try to fix it. And then, like, 2 days later, you're like, oh, that's why I did that. Yeah. I can't oh, yeah. That makes sense. I always I'm always writing comments and encouraging the team to write a comment. You know, if you're just, like, hacking a fix in, but it's because you've got no time, add a comment being like, hey. Hey. I know this isn't great, but, like, I'm I'm under time pressure right now. Right? And just and just, like, being being nice to your past self and and your past team selves when you're looking at code and you're like, what the hell are they thinking? And it's like, well, maybe they were, like, under super client pressure at the time or, like, you know, didn't have the full picture of what was going on, and and now you do. And it's like like, that's the like, software is the the clue is in the start, but it's soft. Right? You can change it. It's Okay. If it's bad today, you can someday, if it's so bad, you can fix it. You can do something about it. Yeah. And you're not, I mean, you're not really intimating unless you're breaking things. Yeah. Right. You gotta just document those breaks, why those breaks are there intentionally and with nice fun emojis right there in the comments and the GIF. Yeah. So I'm curious, you know, when starting the creative process, you know, Stu, I'll I'll throw this over to you, and, you know, there's obviously Jed's other point. You have lots of things that, you know, back when we were, like, I like, living together and you were working through these really exciting projects, and now there's probably more enterprise y, large scale projects. But regardless, when you're starting a project like that from scratch, you're sort of in the initial ideation, you know, r and d Yeah. Phase? Like, how what does that look like for you, like, moving through that process from, you know, 0 plus? Yeah. Well, in some ways, I feel like such a dinosaur that I'm almost embarrassed to to talk about it. But, I'm I'm really into physicalizing ideas. And, obviously, I'm a tech guy. Right? I don't think we'd be having any of this discussion were it otherwise. But, and yet, pen on paper, Sharpie, just, you know, paper's recyclable. It's cheap. You can burn through ideas. The worse the scribble, maybe the better. And then being able to physically tape up or pin up that stuff so that your your memories are anchored physically around you, and you can refer to a cluster of ideas. And so I know it feels like most people don't work that way in 2023, and it feels like a very old, mammalian kind of, you know, I need to physically represent things in a certain time and place, but, yeah, that's that's how I'll start to formalize the very cloudy ideas in my head. And then from there, I'll start, you know, sketching in, maybe in Figma, if we're really honest, sometimes illustrator still, or directly in code. And, you know, code's so wonderfully flexible that, yeah. So, yeah, for me, it still begins with a a physical process. Interesting. Yes. I like, I've seen a lot of that, like, working with companies like IDEO. They're big on, like, sticky notes. I remember back in, like, school so are you is it, like, printout paper, like, no lines, line paper, grid paper, field notes? I'm so curious. Like, paper is pretty tense about a space stationery. Sticking up to your walls. You know, back back when we lived together, ancient times and, and Yukon, really, I mean, I was all about those, Rhodia grid pads. You know? I needed the grid. Yeah. I'm sure you have some within reach. Probably. There's a lot. I have, like, literally just from, like, from those times and just I'm like, in my head, like, yes. That's exactly what I need. It's just pads, field notes, grid paper, like, just every sort of paper. Like, yes. Right tool for the right jobs. Like, sometimes you need a grid, sometimes you don't. It's like an home and joy. Yeah. I I started to migrate, around I guess when I when I went back to school, I realized I started getting all of these notebooks that were just, blank paper, just blank, no grid. Yeah. Just no rules. No no constraints. Oh, there must be speaking of, like, the design the intersection of design development, sorry, Code and creative. I feel like there's the intersection of, like, sticky notes in a in a notepad, like, in a, like, spiral notebook. There has to be I mean, I guess maybe it is just a sticky pad, but something a little bit more formalized. So it's like a book, but you can just pull it out and it's got the sticky Mhmm. Right there on it. We'll we'll get there. I like that. So, David, any thoughts on that? Like, when you're starting starting your process, anything specific beyond sort of taking into the world with with stickiness? Yeah. I was thinking actually about that that thing where you said, like, the worse the sketch, the better. It reminded me of, you familiar with the process shape up from, from base camp and 37 signals. They have like a whole dot. There's a, if you Google it, you'll find it. And they, they talk about thick marker wireframes, Right? So using, like, a really thick pen to draw a wireframe so that no one can get bogged down in the detail of, like, how you know, is this thing this size or that size? Is it adjacent to that thing or above it or or to the left of it? Like because it's like the you've used such a thick marker that you can't tell the detail. You can just kinda get an idea of the rough shape, is like a that's what it made me think of when you were like, the worse the sketch, the better. I'm like, yeah. I definitely see the value in this. Engineer that. So working on some very early was yeah. Wow. This was web based VR stuff in, Creative Lab around, like, 2015, I guess, maybe 2016. So, we were kicking around some ideas, potential product tie ins, things like well, I won't mention what we were working on exactly, but it involved us making some sketches of things in VR and these were early prototypal things that we were going to use to excite the people with the money in the company and then get the budget so that we could outsource and bring in you know, modelers and and, you know, hardcore VR engineers, and then we could start to build the thing. But the problem was making these prototypes. They looked terrible. You know, they're mostly, you know, low poly things that we could make quickly And that was lost on a lot of our higher ups and executives. They'd put on the headset and they'd be, why is it so terrible? And we kept trying to say, this is a sketch. Don't you understand that that looseness and terrible, you know, the slow it looks like, you know, lawnmower man because we're not spending money or too much time on this. And no matter how many words we tried to use to verbalize it, it didn't come across as a sketch. And this was, shortly after Google had acquired, Tilt Brush. And Tilt Brush did not have a scaling feature in it yet. It was early days, and we were making this cityscape and it looked terrible. So I had this idea, we need to do the napkin sketch for VR. So what if, just in my living room at home, I had my own VR rig. What if I could use Tilt Brush to hand draw the cityscape so it looks like a sketch? But you needed to be inside of it, and you couldn't do that yet. You could only draw as tall as you could reach. That was the, you know, the limitation of Tilt Brush. But now I knew these folks. They were part of the Google family, so I was able to just email them and say, hey, I need to scale up these drawings. How could I do this? And they were able to send me, you know, some Python code and and walk me through how their, Tilt Brush files were organized, how I could break them apart, you know, increase the size of all the vectors, which is pretty easy operation. It just wasn't in the interface yet. Put it back together and then open it. And so ultimately, that's what we did. The next walkthrough was literally a sketch of what we were trying to make. So it was really like the reverse pretending that it's still on the napkin. Yeah. I think that communicated a little better that this is a stand in for the real idea. And if you like this, give us the money, and we'll go do the real idea. Yeah. Yeah. I love that. First of all, Tilt Brush is amazing. I remember the same thing just in there just building. I think I feel like they had a scale feature or maybe not, actually. Yeah. Probably not. I think they know. They didn't or before They chose the app. It's never happened to you. Yeah. Oh, yeah. Now, I mean, by the time that app was deprecated, it was trivial to scale things up and down. Yeah. But in the moment, we had to I think it's important. Like, the idea of, like, a rough knock or, like, those prototypes where it's like you have to enforce the rough because if you go too far, I was guilty as, like, a perfectionist. I'm like, oh, I'm making these these mock ups or whatever it might look like in the really early just pitching things. And if you, polish it too much, it's it just seemed it comes off as like a design that they start nitpicking like, oh, how do we change that? Like, we're not even looking at that. We're looking at, like, broad strokes here. But the more detailed and accurate you make it, then they start focusing on different elements of it. So it almost helps to have, like, Tilt Brush. I'm just gonna swap this out there and just, like, see you know, just only comment on what you can see. And when you start adding and predifying it, becomes a very different conversation is is what I found. I also think it reminds me, like, as a as an engineer, like, I think about these things maybe with like, I draw a lot of technical comparisons. And I think about, like, when you're coming up with ideas and trying to, like, come up with a solution to a problem or or come up with an idea, I think about it as, like, not locally optimizing down one path. Right? And it's, like, going to if you go too detailed too early, I sort of think about it as, like, I don't know if you're familiar with this sort of, like, approaches for for for sort of, like, machine learning or finding finding optimum solutions to problems of, like, the difference between, like, a hill climb algorithm versus simulated annealing. Right? You may be familiar with these. Like, the idea of a hill climb is like if you're sort of, like, searching through a problem space, you just go to the next best problem the next best, like, answer and then the next best answer and the next best answer. And eventually, you get to the top of where of the answer, and you're like, that's the best one. But what you didn't know was that the other side of that hill, there was another much bigger hill that was like an even better solution that was just totally different. But you couldn't get there because you were just, like, going down the better and better path and you weren't, like, exploring other options. And then simulated annealing is the idea where of, like, when you start trying to find the solution, you have an element of randomness where you're always just like, you're sort of you know what the best you found so far is, but you then also randomly just kinda, like, go wildly off piste and try something completely different and go, is that better? And then you're like, no, no, never mind. This is actually the better thing. And then sometimes you find those completely different solutions, and you go and explore. So yeah, right. Very similar. Very similar. Yeah. You're also describing I'm not going to do this justice, but the difference between gate based quantum computing and annealing Oh, really? D Wave does. Yeah. And their, gate based is winning for sure, but, there's some pretty good arguments, I think, for quantum annealing still. Right. But it's the same, I won't derail this further, but it's the same sort of math. So like, you know, I mentioned, like, having to learn to multiply matrices again and, like, you know, reteaching myself linear algebra for 3 d stuff. And, you know, all that computation is best handled by a GPU, you know, massively parallel small computations. And then you start to realize it's actually pretty similar similar for, artificial intelligence and machine learning, you know, model training. And then it turns out, again, it's the same old story for quantum simulation. So, yeah, that's how that's how I bounce through those things. But I'll Yeah. Yeah. I'm derailing. So What's more what's more exciting than quantum I mean, I don't I know nothing of quantum computing, but what could be more exciting than than going off the rails there? I once, I once met someone who was at a at a wedding who's, like, doing research in quantum computing, and I was like, oh, this will be interesting to talk about. Like, I I'm a you know, I'm an engineer. I know a little bit about this kind of stuff maybe. And And I was like, so tell me a little bit about what you're working on. And I think I got a best one in 10 words that he said. I was like, I have not like, you have just immediately lost me. Because he was in some kind of, like, world to do with, like it was something to do with about how you measure the output, and there was some very specific detail of what he was looking at. And I obviously cannot remember it. I did not understand it at the time. It was fascinating to just hear someone talk about it and realize that I'm like, I I'm getting 1% of this. Yeah. But if if you think it's an exciting topic, I have a recommendation, which is, this guy who was at Microsoft at the time, Andrew Hellwer, I think is his name. I think it's h e l w e r. He gives this lecture that you can find on YouTube, and it's named after clearly his favorite book on the subject, which is a great book. It's called Quantum Computing for Computer Scientists, And, I've forced myself through the book. His lecture is so much more to the point and beautiful in its simplicity. He throws away all of the bad metaphors about, you know, cats in boxes and, you know, pizza bagels. Is it a pizza? Is it a bagel? It throws that away, and it gives you the very basic math, from a computer scientist perspective. And from there, that's that was my entryway because I was trying to figure out, like, what is the super cool quantum, quantum computing, quantum physics, whatever superposition? And because of him, I can now give some pretty concrete answers about what's a cubit and how does it work, at least from a mathematical perspective. The actual physics of this stuff is Of how that stuff works is, yeah. It's I feel like I'm in much easier to get the Schrodinger side than the math side. I'm a visual No. No. No. A a cubit is just two values. That's it. It's just a pair of numbers, and then you can build from there. That's it. Yeah. It's just a pair of numbers. It's only that easy. We're just period and then end of end of the whole lecture. Yeah. So to kinda, like, bridge quantum computing, which is I'm not gonna say inaccessible until you listen to that lecture and you really understand all about it. So, like, AI and something that is, for a lot of people, you know, very inaccessible in terms of really understanding how it's all happening behind the scenes. But there is sort of a resurgence or not resurgence, but a continued resurgence of, you know, AR and VR and AI, all these things kinda, like, coming to a to a front. I'm curious, what do you think so specifically on the on the ARVR side because I think there's probably more experience there. Stu or David, any thoughts on how that's gonna change the landscape in terms of, building online experiences? I mean, I just I That's definitely one for handle, you know, like, can't stand those people with community on its name. You know, from from professional to prosumer to consumer and then just keep working its way down the tree. I'm curious what your thoughts are on, like, what do what do think the the issues might be, the challenges, the opportunities, the cool stuff that might start flowing and maybe when, in the ARVR space? Well, I I think it'll take me a moment to process what I can talk about and what I can't talk about. So I'll I'll start with a story from the the pandemic, or, well, let's say lockdown. It's still a pandemic, right? We're still anyway, in fact, I'm almost officially, one line again on the COVID test Just a Yeah. That was my past week. So we were we were working on something at Amazon, a side project that had to do with warehouse spaces and developing a sort of kiosk that would be for internal use for, you know, a specific task. And we're all working from home. We're all trying to figure out how to do that and also work on projects together. And, to develop this kiosk, I really what I really needed was to have, like, a bunch of different TV screens and things delivered to my home and to have someone prototype these things together. And then I could say, like, you know, this is too big, too small, in the wrong place, whatever, and that just wasn't happening. We just weren't at that point as a society to make that possible, nor do I really have warehouse space in my small Brooklyn apartment. But what I could do was very quickly mock up all of these things, using Amazon Sumerian, put on the headset, and walk around in that space and and get a sense, you know, style, in relation to the size of my own body and feel like, oh, okay. So if this is proper scale, this one feels right. This one doesn't. You know, this is somewhere in between. And it's an immediate gut reaction, and it cuts out all of the guesswork just being able to be virtually in that space, without having to pay for any of the hardware, have it shipped, have it set up. So that that may be a safe way to start to tiptoe into answers here to that question, hopefully. Yeah. No. I mean, a 100%. I mean, I've it's it's interesting just the spatial side of it because you're you know, obviously, it's immersive, but that means, you know, we are directional as a as a animal. You know, we see this way, but it's you know, there's things going on behind you, and so it's just a whole different landscape. You know, what you what you kinda mentioned, I think, kinda ties into the fact that, you know, it's it's just a completely different ballgame. It'll be a different mindset for how you develop and build in that space. How do you hint to somebody that, like, you're supposed to be looking behind you? So, like, maybe maybe turn around and go look at that call to action or whatever whatever that might look like. Yeah. Oh, for that, I mean, shout out to, former colleague, Jess Brillhart, who's a big name at Creative Lab and now continues to be a big name on the West Coast. She gave the keynote at South by Southwest a while ago for immersive experiences. She's a filmmaker by education, and has a lot to say about directing attention and focus in a 3 60 degree medium, and I say 360 because at the time, it was really 3 60 film. So it really it really was like rails in a circle around you, and, of course, immersive is, you know, that on all axes. Yeah. The 360 day, that was the project that I was working on at, that large company that got 90% of the way there and then got scrapped because of video content being lacking. So ARVR is pretty exciting because the content doesn't lack. You just create it. It's a little bit more generative, so that's, a different different space. But, so we're coming up on an hour. There's a a bunch of questions that came in, but I don't know if we're gonna have time for those. But, yeah, any any what's that? Oh, no. I feel I feel bad. We should get to Well, I some of them. Let's throw we could throw one in because I think it kind of brings us back to that sort of the intersection space, which the question was, do you have any strategies around fostering collaboration culture between designers and developers? And I'll just quickly like, I this is a big thing for me at Ranger, my my old agency, because, I I was both. So I was, you know, I was the intersection, and I just tried to hire people that were the same, you know, that had the same sort of, like, training or or background skills, that I had. And And so I was able to avoid that altogether. You know? And I kinda even pitched that in meetings. I was like, oh, there's the Harvard, like, oh, we're gonna have the seating chart. You know, and we're gonna have our designers here and developers there, and here's how they work in pods and all that. And I was like or you could just avoid the communication altogether and just make them all, you know, it's kind of pre creative technologies, you know, as you turn. Any thoughts on how you can foster that? Like, if you have teams of, like, strictly developers and strictly designers, how you can, marry the 2 of those for either of you? I've been thinking about this a lot at the moment. Because as an as an agency, we don't have any designers at the moment on us on staff. So we work a lot with third party designers or design teams or freelancers. And so I've been thinking about this a lot because we've it's always been a challenge. We've never quite hit on the right process, and we still haven't hit on the right process. But some of the things that I think about is, like, I think the best devs are the ones that know a little bit of design or, like, good UX and goods, like, like, understand what, you know, some of the, like, just kind of, like, basic underlying principles about what's good and bad design. And the best designers are the ones that understand a little bit about what are the limitations of the medium that I'm delivering into. Right? My worst experiences of working with designers are people who are print designers by trade and haven't really adapted to the web and that but are just doing some web design stuff as well. And it's like that is just such a different world that, like, it it doesn't align. Similarly, I've worked with devs or or or, like, helped look after devs who don't who just don't intrinsically understand anything about good or bad UX. And so as a result, we'll, like, implement designs badly or, like, not even put the right kind of boilerplate and skeleton in place to kinda unlock further development on top. And then, otherwise, I think, like, just a lot of side by side work. Right? Like, just making sure that things are iterative, making sure that it's about, like, responding to challenges, especially when it comes down to kind of delivery. The worst projects are the ones where delivery of designs is a cutoff point. Okay. Now start the designs. Now start the implementation. Sorry. And the best ones are the ones where, like, every small stumbling block of, like, oh, this is actually really hard to lay out on the page, or this is actually really hard to bring to life. Like, but if you just change would it be like, if we just tweak this, it'll be way easier to do. And then, you know, having that kind of that process of, like, it's not about, like, criticizing the designs being wrong. It's about, like, work working within each other's limitations, the space of delivery, and the space of design. I think that that works best, which is maybe a maybe an obvious answer. Yeah. No. But an important one. I mean, again, like, not to get into methodologies, but, like, the waterfall, you know, especially if the designers are just not aware of what they can or can't do can be really problematic. They have to progressively enhance, and they have to know the limitations. And if you only find that out once things are done and polished, you're you're in a bad bad spot. But Yeah. Stu, any any thoughts on that one? Well, I feel like I have a similar experience as you. So educationally, I think we're both taught print design, but, of course, with, that's not our trade at all. You know, we're in the code from an early age, so that sorted itself out. Still big love for good print design though. Yeah. For sure. But like you, I'm that intersection and I kind of, my present team excluded because I love my team, so I don't wanna give the impression that I don't. I think outside of my team, what I've experienced in the past is that, like, it's the 2020s. Why are these things still separate? They should all be me. That sounds very narcissistic or very arrogant. I mean, like, I accidentally somehow had these two influences and I'd like to think it was special. That should no longer be special. It's the kids coming up today really ought to have a foot in both worlds and may specialize in 1 or the other, but it's just so weird to me to meet young folks who don't, who seem to be firmly in one camp or the other because it just seems like evolutionarily, that that's just how it should be today. Yeah. And you can actually see When I would hire people at Ranger, I was I used to talk about, like, this t shaped tire. You know, you've got, a deep dive in their area of specialty, but then a crossbar of understanding so they can communicate with the other teams. You know? I'm a I'm a friend developer, but I can talk to the designers in the back end database. But Yeah. Now I feel like I need to update. Maybe it's like a capital m, and it's like you got a couple deep dives, a little bit more, you know, jack or jill of all trades. You you understand this and that. You're kept but you're a little bit more sprawling with the adjacent sides of you know, print design can be super relevant in how you do digital design, which can be really key in how you do UX and UI. And, you know, I think it all is really just makes a more robust, experience in person, when they're a little bit more multifaceted. But yeah. I just wanna reiterate again, love my team. It's just it's in the back of my head because we were our team was having this discussion recently. And so, you know, shout out to Yeah. That's a huge one. I I completely agree. I I watch sci fi movies all the time. I'm like, man, this is I watched the old sci fi movies. Like, they're saying, like, by 2020, we're gonna be in a very different place than where we are actually. I saw one last night with a creator, which was very timely with, you know, the AI stuff, and it was and it had some amazing not print design, but sort of that feeling to it. So I think, yeah, there's lots of ways all this can get pulled together. I but I think it all comes down to that intersection. Whether intersection is inside of one person, you know, they're they're both as, you know, I think the 3 of us are, or you can foster and bring together multiple people across a team and make that team sort of the the whole of of this idea of that intersection. I as I mentioned, I love metaphor, and I'll leave I'll leave us with, a story from when Stu and I used to live together. So we, you know, probably riding around the kitchen with on a unicycle or something. But, at one point, we had a a microwave, and it was, you know, just a throwaway junkie microwave we found. We're like, well, we're not gonna use it. We're just gonna trash it. And so we're like, well, what can we microwaves, you know, as as as younger people do? And so we we put, like, soap in there, and, like, soap was doing cool stuff and all that. And then we figured out, the the, you know, the ultimate test was this grape. And we just cut a grape in half, and you sort of leave the two halves of the grape just slightly connected. And it essentially the sugars or whatever it is, it forms plasma, and this ball of plasma rose to the top of the microwave and literally was melting the metal. But it just came to me while we were talking, and I was thinking back through all those those sort of things that happened. I was like, that's the intersection of design development. You have just, you know, 2 things to these 2 halves. This could be very different, but just you have that connection, and then suddenly you've got this plasma ball that's burning right through the top. You're innovating to the point where you're breaking things, and that's what we're all trying to do. So And then your microwave explodes. And then the microwave explodes. And then it was I burned up the the I burned up the Yeah. I had the cord, you know, just ready to pull out anything whenever At least we had yeah. We had the the fire extinguisher and the cord ready to get pulled, but, no, it was awesome. And I'm just trying to work out where that was going as you were saying that. I was like, where is this where where is this coming back You just We made it again. Awesome. Well, a little over time, but I this was super like, just I love just meandering through these these different topics, and and, I I think that's what it's what it's all about. How can you be creative if you had everything super structured? So, yeah, David, Stu, thank you so much for for hopping on and chatting through this. Hopefully, we can we can do it again sometime. This was this was awesome. Yeah. Make sure it happens. Cool. Alright. Thanks, guys.",[162,163,164],"e4a54717-cd97-427f-ac7a-4aab1adb0f1a","3658ff72-9402-4151-9ba5-fa9025000027","3a344ee7-f2f6-44d7-9cc2-4e5e9d78bf3d",[],{"id":133,"number":134,"show":122,"year":135,"episodes":167},[137,138,139],{"id":138,"slug":169,"vimeo_id":170,"description":171,"tile":172,"length":173,"resources":8,"people":174,"episode_number":183,"published":184,"title":185,"video_transcript_html":186,"video_transcript_text":187,"content":8,"seo":8,"status":130,"episode_people":188,"recommendations":192,"season":193},"open-source-outlook","923062947","A discussion on the past, present, and future of open source, including what it means to be \"Post-Open\" and build sustainable businesses.","863084c0-77cc-4b22-af18-9d7af9ca6165",69,[175,177,180],{"name":149,"url":176},"https://directus.io/team/ben-haynes",{"name":178,"url":179},"Steven Tey","https://twitter.com/steventey",{"name":181,"url":182},"Bruce Perens","https://twitter.com/BrucePerens",2,"2024-03-14","Open Source Outlook","\u003Cp>Speaker 0: Let us kick it off. So this is the second episode of Bridging Bytes. This time, we have we have bridged from the last episode of the intersection of design and development, and now we are talking about, the open source Outlook. So, obviously, a very important topic, something that's near and dear to my heart, having worked on Directus now for 2 decades, over half of that as an open source maintainer. And then we have some amazing, guests here that are gonna be leading the chart in terms of this conversation.\u003C/p>\u003Cp>So I'll be moderating the the chat. I can give a quick background, and then I'll introduce our 2 our 2 guests. So, my name is Ben Haines. I am CEO and founder of Directus, the open source, data management platform. And I've been I built the platform originally in 2004, and we actually open sourced it in around 2010, 2011.\u003C/p>\u003Cp>So we'll get into more of the history of of what we did in our open source journey. But, I'd like to next introduce Bruce Perrons, who is sort of the the godfather, I think we were calling him, of open source. Bruce actually created the open source initiative, which I think was in 1997. Give her we'll let him\u003C/p>\u003Cp>Speaker 1: 87.\u003C/p>\u003Cp>Speaker 0: When was it?\u003C/p>\u003Cp>Speaker 1: 1987 was the creation of the open source initiative in the open source definition. And the document actually came about, I think, 8 months before, it was then the Debian free software guidelines.\u003C/p>\u003Cp>Speaker 0: Yep. Obviously, there's some interesting aspects of using the word free versus the term that was actually chosen, which was open source. But yeah. So we have Bruce Perrons here, who is the cofounder of the Open Source Initiative. And, you know, great thanks to your work, I believe, within, Debbie.\u003C/p>\u003Cp>Basically, Bruce, why don't you give a quick, overview of your background and and and what brought you here?\u003C/p>\u003Cp>Speaker 1: I I'm sorry. It really was 97. I'm just going over the calendar in my head. So, 87 was actually when I got to Pixar, and, I started as a filmmaker, was one of the founders of computer graphic 3 d feature film animation, and worked at Pixar and their predecessor in New York for 19 years in total. Have a credit if you go on IMDB on a couple of films.\u003C/p>\u003Cp>And in, 97 we'll get that right now. I wanted to define what Debian, included, and we created something called the Debian free software guidelines. And then a little later, a group met and said, well, let's market free software to business and call it open source. And, so that happened. And I was called up the next day and I said, well, great.\u003C/p>\u003Cp>I'll take my Debian free software guidelines and make them the open source definition. And so there we go. It's been a long time, and it's been incredibly successful. If I had said to you, back then, we're going to, give away our software and completely take over the industry by doing it. And we're going to make an encyclopedia, and it's going to be the first thing to put a Microsoft product and Carta out of business.\u003C/p>\u003Cp>If I had told you that, you would have just said, well, I wanna smoke that dope too. So, so it it's been a long strange trip. Hasn't it?\u003C/p>\u003Cp>Speaker 0: Yeah. Well, I here I am sitting here, you know, so excited to be 20 years in, to the entirety of my project, Directus. And you've got, you know, 20 years under your belt just, you know, with, you know, elements of your your history. So thank you so much, Bruce. It's really exciting to have you here.\u003C/p>\u003Cp>Lots of knowledge, obviously, spanning back to the the mid nineties and even before with, you know, your work on those projects. I think next, I'd like to introduce Steven Tay who's joining us. Stephen, I'll let you give a quick background from what you did with with Vercel and what you're doing now at dub.co.\u003C/p>\u003Cp>Speaker 2: For sure. It's an honor to be here. I feel incredibly humbled by the the the wealth of experience that you guys bring to the table. I think Bruce was talking about how he he he did that DBL thing in 97. I'm like, that was the year I was born.\u003C/p>\u003Cp>So it was like a little bit of a it it feels very humbling. But, yeah, my name is Steven. I was, a developer advocate at Vercel for the last two and a half years. I started in 2021. It was there where I got, introduced to the open source community, got to actually learn and became a better developer.\u003C/p>\u003Cp>Before that, I was doing a lot of, like, data science, coding in Jupyter Notebooks, not really building any, like, software that's used by the end user. So I I learned a ton through my time at, Vercel. I built a lot of open source templates, open source, guides technical guides that people can use to learn about Vercel's technologies like Next. Js, Turbo, Rebo, etcetera. And, it was actually through Vercel.\u003C/p>\u003Cp>So we we dub this company that I started back in December of last year, it came about as a side project that I built when I was at Versal. I I had this need to, like, be able to share links, on on social media with really nice preview images, and it started from a very niche use case, but then eventually blossomed beyond that into a full link management tool. So, it was in December when I when I started talking to a lot of our users and realized that the market opportunity behind Dubb, It's a start company around it, and here we are.\u003C/p>\u003Cp>Speaker 0: I love that. Thank you so much, Steven. That's a it's an awesome intro. I mean, obviously, we have, you know, different levels of experience, with open source, with building, but that's kind of how open source works. You know, you've got maintainers and contributors and users.\u003C/p>\u003Cp>You have some projects that are out there and they're just small little packages or libraries like an SDK, you know, with one hobbyist sort of kind of maintaining it on the weekend versus things like Directus and, you know, even larger operating systems or platforms supported by tens or hundreds of developers. And I think, you know, in the last few years, we've seen all sorts of things happen, that really showcase the importance of of open source, vulnerabilities like Log 4J or just the the escalation of different open source platforms, like, really taking hold in the ecosystem. So it's obviously a very timely conversation. Specifically, my passion is around I I've spoken with Bruce for a while about this actually, is about how to build I think it's a nice acronym, SOS, but sustainable open source. Of course, SOS being, you know, talking to how important this is to get right and to do it timely.\u003C/p>\u003Cp>But I think we can kinda dive in. The purpose of this, Bridging Bytes episode is really to talk about this theme of open source, past, present, and future. You know, we we, of course, have Bruce here to to really help us understand the roots and how this came to be. We made our our platform open source a decade ago, you know, obviously based on the WordPress license using GPL. And then we are we relicensed about 10 months ago.\u003C/p>\u003Cp>So there's all sorts of things happening in the past and present. And, of course, you have to be really mindful of where do things go next. You know, how do we actually make open source sustainable? I've heard some pretty interesting ideas from Bruce that I'm sure he'll share around his ideas of what he's calling post open, at least as a working title for now. We'll figure out what that might look like.\u003C/p>\u003Cp>But, yeah, so I think we should we can dive in. And my first question would be for for Bruce. Bruce, I'm curious, in all the experiences that you've had, maybe you could share how those have shaped your views, of the evolution and impact of open source over such a long tenure over over these decades since 1997, not 87, but through now. How do you think that those experiences have shaped, you know, your views on on that evolution?\u003C/p>\u003Cp>Speaker 1: Well, I should just say a long, long time ago as if I'm telling a story because it feels like forever. But, so I I started out, working for a film company, and I I had fun. I mean, we did something for the first time. You know, we we made our IPO. They let us have our IPO at the same time that we put out the first three d feature animated film, which was crazy.\u003C/p>\u003Cp>And so it it was a really interesting ride, but I started at this point to work on Linux because, we were using Unix at Pixar, and the PC was coming out. The PC started to be capable of running Linux. And then, Steve Jobs for a while had his office right across from mine. This was not because I was important, but because they wanted to keep an eye on me. And so, one day, Steve made his peace with Bill Gates, and the next workstation stopped being on Steve's desk, and there was a Windows laptop.\u003C/p>\u003Cp>And Steve would tell us that, you know, eventually, we'd switch off of Unix, and we'd all be using Windows to do our animation. And no one was very happy with that, and especially then because before Linux was really big, the quality of Windows was very poor because they could afford to have very poor quality. They were essentially the only game in town. And so I started working on Linux and tried SLS and a few other things, you know, ancient distributions, and and then landed on Debian. And at the time, my idea was making a Linux system for amateur radio operators, ham radio.\u003C/p>\u003Cp>And the reason for that was there was a lot we could do with software, and I thought we could put it all together. Well, that never happened, but I became Debian project leader along the way. And I think it was becoming more important than my work at Pixar. And the real moment for me was one day I got an email from someone and they said, I wanna use Debian with a serial console. Do you can you tell me how?\u003C/p>\u003Cp>And that wasn't a feature at the time. And I thought it was interesting, and I I sat down at Pixar, you know, when I should have been working and figured out how to do it and sent this fellow an email. And he wrote back and said, that works great. This is going on the next space shuttle flight. And so I walked all around Pixar looking for someone to tell this to.\u003C/p>\u003Cp>The only person there who knew about Linux was working from home that day. And so, it came a time when people would say to me, well, you're having such an exciting life. You've come out with a film, and your company has an IPO. And isn't this so exciting? And I'd say, yeah.\u003C/p>\u003Cp>But my hobby project is orbiting in space. And at that point, I sorta decided maybe I would eventually leave Pixar and work on Linux and open source full time. And so we have had a history of that sort of serendipity. I mean, the hobby project of a students. You know, Linus was a student and maybe a lecturer, takes over the operating system world, and the industry software is taken over by amateurs who give away their software.\u003C/p>\u003Cp>I mean, at this point, none of them were working for companies. And IBM abandoned AIX in favor of this hobby project. So all of these amazing things were happening and why the world was ready. There was a a market vacuum, and this came along and filled it. And people don't realize that this is all straight economics.\u003C/p>\u003Cp>It's it's no you know, some people call it freakonomics, but there's nothing freaky about it. It's just economics.\u003C/p>\u003Cp>Speaker 0: Yeah. I mean, it it goes without saying, you know, by some estimates, you know, open source power is 80% of modern code. So, you know, there's quotes from people over at Google, Filippo Valsorta, who had said something. I've had this quote here. He said, open source software runs the Internet and by extension the economy.\u003C/p>\u003Cp>And I think that kind of really qualifies like how large open source has become. Obviously, in the early days when you're working, on defining it, Bruce, there was all sorts of there was the, I think you mentioned in Debian, you had the Debian Social contract, in 93. And there's the SPI, which was, you know, software for the public interest. You did the OSI, the Open Source Initiative. There's all sorts of, like, what's the term gonna be?\u003C/p>\u003Cp>What are the rules? How do we, you know, really label these things? And what we got from that is essentially ten sort of rules or guidelines for what is open source, which is right there, you know, on opensource.org. It was how did you guys come up with those 10 terms? I mean, I I I've looked at them quite a bit because we have an open source source spirit.\u003C/p>\u003Cp>You know, our ethos has been that since the beginning. But, of course, with a license change and trying to stay true to the terminology of source available versus open source versus whatever new terms we come up with, there's always gonna be those 10 terms sitting there within the OSI. So was that was that an easy or difficult thing to, you know, sort of memorialize for the world?\u003C/p>\u003Cp>Speaker 1: Well, first, I don't wanna take all the credit. We are standing on the shoulders of Richard Stallman and the free software movement. And, Richard and I were actually speaking at a UN Summit in Tunisia, and I said we're standing on the shoulders of Richard Stallman, and he goes like this. And so, I think that we've had a lot of, different words for what we're doing. And because of that, the concept of having a brand came up.\u003C/p>\u003Cp>You know, there was free software and there was Shareware. Remember Shareware? And\u003C/p>\u003Cp>Speaker 0: Shareware and Freeware. There was, like, all the wheres. And it's interesting thinking of, like, how the word free left. Like, you still have thos, you know, free and open source software. But, you know, the freeware versus open source and the difference in perception, again, something that we deal with when we're now selling licenses for, you know, we've for years, been selling licenses for open source software through our cloud SaaS and, you know, breaking the perception of from free to paid is an interesting gap to kind of, cross.\u003C/p>\u003Cp>But\u003C/p>\u003Cp>Speaker 1: So so I'll give you another word that everyone's forgotten, consortium. It used to be that real software products were made by consortia, which was a collaboration of companies. And the problem was that they all had their own different interests and that the engineers did not control the operation. So the consortia had a lot of trouble getting along. And my very favorite, consortium story is the X Window System Consortium decided one day that they would not have a canonical user interface for x.\u003C/p>\u003Cp>And Microsoft, of course, ate their lunch because they did. And and what the x consortium was trying to do at that point was allow each of the different Unix workstation manufacturers to differentiate their work station and also to lock in their customers by having a different user interface for that version of Unix. And they didn't realize that if they didn't work together, Microsoft would just take over the market and, you know, go find a Unix workstation today that isn't a a Linux or BSD system on a PC. So we had all of these economic issues, and we also had the need to create a brand. And so the open source initiative came by because, in Debian, we wanted to say what Debian was, and also we wanted to elucidate our social contract with the community.\u003C/p>\u003Cp>And so we, wrote the Debian social contract and the Debian free software guidelines. I sort of created and edited it, and we had a 1 month discussion with the Debian developers about it and then publish the results. And this, part of it became the open source initiative, definition. The Debian social guidelines is still very prominent on the Debian site, and you can see the other part that became the open source definition at the end of it.\u003C/p>\u003Cp>Speaker 0: Yeah. No. And that's something I think referred to quite a bit, especially as new licenses come out, you know, making sure they check all 10 of those boxes, to truly call themselves open source, you know, and not have some big glaring asterisk. Yeah. That's it's amazing just to hear the history of, like, all this tumultuous, like, what is this you know, there's just a huge landscape that was not defined.\u003C/p>\u003Cp>So it's exciting to hear it was defined. Same issues that we're still facing today in terms of how you get financing and make sure you have an authoritative, list of of defining what this is, and that that's being, fostered by people who actually care about what it what it's supposed to mean and not just guiding it based on commercial endeavors. Steven, I'd like to, start over to you. Obviously, you've had, 2 sort of key roles that that you highlighted in your intro. Obviously, going from DevRel over at Vercel, to now founding, dub.co.\u003C/p>\u003Cp>I'm curious how your perspectives of open source, you know, in the development of those those open source projects has changed, and evolved over that transition of your your career.\u003C/p>\u003Cp>Speaker 2: Yeah. For sure. I think there's there's definitely been quite a shift in terms of, like, the way open source, I guess, the way we view open source personally. But one thing has always stayed true, and I can go through the distinctions there. So when I was at Vercel, we basically maintained this fairly popular React framework called Next.\u003C/p>\u003Cp>Js. It's basically a framework for you to build with React, service side rendering, and basically an entire full stack applications with batteries built in, like API routes. You can even do stuff like, having a middleware to do redirects, rewrites, and all these different things that regular React would, you know, it'd be harder to build with that. And through Next. Js, it we were able to tap into a massive customer group and and not, I guess, not exactly customers, but, like, potential users that could be converted to customers.\u003C/p>\u003Cp>Folks like, let me see here. Like, folks like, Netflix. I I I remember tweeting at one time that 4 of the world's largest streaming platforms, Hulu, max.com, Amazon Video, Netflix, they were all using XJaaS, which is kinda cool to see. And, through that sort of, I guess, user base, we're able to expand our enterprise, pipeline because we are able to tap into engineering managers who are using X. Js and and sort of pitch them our host of solution and give them a sort of white gloved approach to spinning up and and maintaining that Next.\u003C/p>\u003Cp>Js applications. So in that sense, the symbiotic relationship between Next. Js and Resell was very clear. It was like, you know, you have this open source framework, MIT licensed, and you have this proprietary hosted solution that basically, does your Next. Js hosting for you, and you have you have to worry about stuff like Kubernetes maintenance and stuff like that.\u003C/p>\u003Cp>So that was that that sort of relationship was very interesting. And the work that I did there was also sort of different because, I wasn't working a lot on Next. Js specifically. I was mostly more working on developer efficacy, which is building open source templates, and that sort of, like, drew me to gravitate towards another side of open source, which is building templates and also products that are open source, but at the same time, licensed under AGPL, which would give you, the the maintainer or the the company behind the project a certain level of ownership and control, over how the prod the the code is distributed. So, that sort of drew me to to basically build Dubb as an open source, first project.\u003C/p>\u003Cp>It started as a project, and it's it's our company. And, so the relationship here is slightly different. Right? It's it's more of a we we call ourselves a cost, which is like a commercial open source, software, which is similar to what, for example, MongoDB started back in the day with, like they had their open source database system that people can easily clone and just run it themselves. And then now it sort of evolved into the wave of, companies like cal.com, which is an entirely open source company sorry, open source product that's, they have their repo, it's out in the public, and they also run that for the hosted service.\u003C/p>\u003Cp>And they also have, like, a directory that is enterprise only. So if you want to use code in that directory, you would have to buy an enterprise license. And that's sort of the direction that we're going towards, and it certainly has changed quite a bit about how I think about licenses, how I think about getting contributor permissions, and stuff like that. There's so much nuance to to this whole ecosystem that, honestly, I'm still trying to figure out. I'm working with a few lead councils to understand where we should be, you know, what sort of precautions should we take, what sort of, licenses should we potentially change to in the future.\u003C/p>\u003Cp>So, yeah, very excited to to to discuss this with you guys more and and sort of get your thoughts and and advice on this this whole, space and how we we should move forward.\u003C/p>\u003Cp>Speaker 0: Yeah. No. That that's awesome. I think I mean, I've seen I've lived several of those different iterations of, like, how you commercialize, how you make that more sustainable. Seemed like you were describing sort of like an open core model.\u003C/p>\u003Cp>Sometimes, you know, you can also work that and call it like an icing on the cake model. There's also the support, like the professional services where you have almost like an agency that leverages it and to get that support and the authoritative maintainers, you know, access to them. That's a paid service. Of course, that can be difficult to scale because you have to scale humans, and not just scale the software out, as you distribute it. So it's interesting to hear, you know, all the different methods.\u003C/p>\u003Cp>And it kind of ties me into there's a few other questions I'd like to run through before we open it up to the audience. But maybe we'll we'll rapid fire these so that we can actually make sure we we work our way through it. But I think the next one that I think is interesting in this, you know, mid nineties all the way through the mid 20 twenties, where we are now, what would you either of you say are some of, like, the biggest milestones that have significantly impacted this open source landscape? You know, whether it's for maintainers, users, and awareness of, you know, open source as a whole. I'm just curious.\u003C/p>\u003Cp>I'll I'll leave that pretty broad. But any big developments or milestones that, you guys can think of regarding open source?\u003C/p>\u003Cp>Speaker 1: Well, I'll talk about myself. In 2005, I wrote a paper called the emerging economic paradigm of open source. And I think that it's very relevant to business and so called costs or commercial open source businesses because it explains how the economics work and goes into the business differentiator of your business. And every business has differentiators, which make their business appear different directly to the customers than others. And, you know, one of your differentiators is you've got dub.c0, and other people have 7 or 8 long, character URLs.\u003C/p>\u003Cp>And so, we can open source everything but our business differentiators and collaborate with our very worst competitors on everything but our business differentiators because they're probably the people who need the same infrastructure we do. But we shouldn't open source our business differentiators until they rot. And over time, they will no longer be differentiating your business because other companies will have them. And at that point, it makes perfect sense, for that to be open source. So I think this perception of where open source could actually fit in a business and that you were not creating economic suicide and joining the communist workers' paradise by, taking it up, was a a very important one, and and I think that it was pioneered by the big Internet companies.\u003C/p>\u003Cp>And so when Google and others take up open source, everyone else notices and says, well, these guys are making tons of money, and maybe there's something we should do there too. Another thing I talked about in that paper was a sort of 80 20 phenomenon, which is 80% of the software in your business is non differentiating. So you have a choice of how you make it. You can build it yourself because you have not invented hear disease, and you think everything you do in your company is better. This used to be a a more prevalent thing than it is today.\u003C/p>\u003Cp>Or you can get it from the open source community. So say you use open source to reduce the cost and risk of developing that 80% of non differentiating software. You take the money that you saved on that, and you move it into making your business differentiators better. And it was the development of economic perceptions like this that I think made it smooth for a company to participate in open source. And and I'm not taking the credit.\u003C/p>\u003Cp>I think everyone could have made the same observations. But if you, go back and look at that paper, I think it's still very relevant to businesses today.\u003C/p>\u003Cp>Speaker 0: Yeah. No. And certain certainly a large milestone. Steven, any thoughts on other other milestones in the open source world?\u003C/p>\u003Cp>Speaker 2: Yeah. I'm I was struggling to come up with one because, I'm fairly new to that open source space, but I I just wanna comment on what Bruce mentioned. I think it's very, very, interesting to hear about that 80 20. It's sort of like the paradox principle where you you take the the you basically leverage open source as a way to collaborate with other amazing developers. And I feel like for us personally at Dubb, the 3 sort of main benefits of being open source is 1, you get to tap into this massive talent developers and people that are, you know, constantly, contributing to open source code, and as a result, your code base becomes more secure.\u003C/p>\u003Cp>I believe Mark Zuckerberg came up with this quote in an interview a long time ago is that open source software is generally more secure. So that's one. And secondly, there's also the aspect of tapping into larger enterprise customers that you never would have been able to work with if you're not open source. So in our case, Dubb is actually used, we're currently working with the government of Malaysia, which coincidentally is where I'm from, to basically, they're they're forking our our code base to build, like, a official government link shortener for the employees to be able to use, and that's something that we could never have done if we were closed source and they will have to subscribe to our software. So that's something that's really cool to be able to collaborate with all these different, like, agencies that have much larger, like, bureaucratic red tape, stuff like that.\u003C/p>\u003Cp>And thirdly, definitely the the aspect around open source and the trust and transparency that goes into it is also massive. Like, you cannot just be putting spyware or, like, you know, like, ads and, like, what's it called, privacy invasion software into your code base just because you wanna, like, track your users or, like, I don't know, find a way to sell ads and stuff like that because your code is fully out there and people are scrutinizing it. So and as a result, like, companies are willing to trust and use the software more and goes through procurement much easier than if it was closed sourced. So Yeah. I feel like those are the 3 that we've seen so far.\u003C/p>\u003Cp>Yeah.\u003C/p>\u003Cp>Speaker 0: It's interest yeah. And I it's interesting to think of how much trust you can get. You've made your source available. You've made it open source, you know, through the license. These these steps are amazing to make to give you the transparency you need, which as you said, like, there's no hidden code.\u003C/p>\u003Cp>There's no black box, and it's like, oh, what happens there? You're sending, you know, telemetry back to the mother ship or something weird and you're just unaware. But it's interesting that that transparency, while it does give you the ability to audit the code, you know, we at Directus were actually in use in the public sector. So the Department of Defense in the US and the Department of Energy. You know, we couldn't really do those things if they couldn't see the code end to end.\u003C/p>\u003Cp>But at the same time, smaller open source organizations, almost always underfunded, really can't afford the security analysis or security researchers, to actually formally ensure that it is the code is audited audited. You know? So auditable and audited are 2 different things. And I think one milestone that comes to mind for me was sort of that big moment with log for 4 j or log you know, from the log 4 shell, vulnerability where people suddenly were very aware of how reliant, everything in the world was to open source, you know, specifically this one package. But, that I think was a really big moment for beyond just open source maintainers that are aware of their own value, of course, but everybody leveraging their systems to be also aware of how critical open source is to what they're building.\u003C/p>\u003Cp>Speaker 2: So It's crazy. It's I was chatting with this, the he's a product manager at TypeScript of TypeScript at Microsoft, and, we were talking about this, it's a funny analogy where that's I think it's like the what's it called? Like, p k p x p xcd comic or something where it's like p xcd? SKCD comic. Exactly.\u003C/p>\u003Cp>Where it's like this entire world that's, like, balancing on the shoulders of one big\u003C/p>\u003Cp>Speaker 0: wall. Yeah. It's a very famous it's a very famous one. You've got this, like, Jenga Castle, and then suddenly there's, like, one little piece that could not be removed, which\u003C/p>\u003Cp>Speaker 1: is They buy a hobbyist in Ohio.\u003C/p>\u003Cp>Speaker 0: Yeah. So exact exactly. It's one of the probably the most popular xkcd comics if if editing can, like, toss it somewhere on here so everybody can see what we're talking about. But, super, super interesting to kind of visualize exactly what we're talking about here. And I think before, you know, some of those bigger vulnerabilities, people just weren't aware of it.\u003C/p>\u003Cp>Now they are, and, of course, we're trying to remediate how do we solve that. Not always the easiest thing to resolve, but I think the visibility and awareness of, open source, whether it's commercial or free or otherwise, it needs to be sustainable. This is not only a hobbyist project for people. This is, you know, supporting big enterprises and and therefore, you know, big parts of the economy.\u003C/p>\u003Cp>Speaker 1: I think there's another point that's really important about security especially is that the size of the code base that we use increases exponentially. So when open source started, a 100000 line code base was a large code base. Debian, I think, is now 1,500,000,000 lines. And so as the size of the code base increases, of course, the attack surface increases as well. And, thus, we are now at the point where no company can look at everything with their own employees regardless of the size of the company.\u003C/p>\u003Cp>Speaker 0: To your point, Bruce, the scale of everything is getting so big. I mean, I forget figured was it called everything or whatever that NPM package was that had a dependency of everything? The dependency trees. You know, when we go through our institutional financing, there's big checks to make sure that we've done everything appropriately, and you have to provide for your software the full dependency tree. Those things just get so enormous, you know, to your points.\u003C/p>\u003Cp>Everything depends on other things. And then you have some crazy joke, like, whatever that everything package, I think that's what it was called, That suddenly you can't remove because it is a dependency on so it becomes very complex very quickly. And how do I get out of this complexity and make things sustainable? I I guess it's sort of the next question Yeah. That I'd love to cover is, you know, you have these open source projects, hobbyists or otherwise.\u003C/p>\u003Cp>Obviously, we're talking about how heavily relied upon they are. How can those projects and maintainers transition to commercial viability, to sustainability, to supporting themselves? And as the project grows, again, myself and Drake, you know, created this, you know, 10 years ago. We were working on it together, just the 2 of us, as an open source org. Now there's 30 people at the company full time that it takes, to kinda support this this project.\u003C/p>\u003Cp>Those are full time salaries. That's a big, big cost. I'd love to hear your, both your thoughts on how these open source projects can transition to, a you know, to be commercially viable.\u003C/p>\u003Cp>Speaker 1: Well, I think they do it kind of poorly today. And so let's take support because support is the way that a lot of companies try to make money, and open source companies don't do support very well. Why is that? Because they support their own program. Okay?\u003C/p>\u003Cp>Now say you're a customer, an enterprise customer, and you have 200 important open source programs in your business, then maybe you have 200 support entities. And your job when a bug comes up is to isolate the bug, figure out which of those support entities to call, and then convince them it really is their fault while they all point at each other. And so, open source support, I don't think works all that well, and people get IBM support contracts because IBM says we're gonna support everyone. So that's one of the big problems that we have.\u003C/p>\u003Cp>Speaker 0: Saying support is not a good option. What would be, like, what would be a an actual like a viable commercial option then for these maintainers to, bootstrap themselves?\u003C/p>\u003Cp>Speaker 1: Well, continuing to talk about how open source does it today, we also have the widget frosting paradigm, which is you take a, open source thing and then you sell a proprietary enhancement to it. And so that is the way I believe that your company operates beside its support revenue and that a lot of companies do it. You don't have to do it right now in Dubb because you own Dubb. But if you had a whole lot of different, link aggregation companies doing the exact same thing, you'd have to sit back and say, well, I'm gonna have to strategize again. So we've really been doing open source for a long time, and it is time to sit back and re strategize open source to achieve some of the things that we haven't achieved.\u003C/p>\u003Cp>Okay. So number 1, if the developer does not work for, one of these companies like Google that actually pays developers to do open source, they're probably not compensated. If they don't work for Google, they don't work for your company. And I've had people say to me, well, open source is mostly in companies today. That's a symptom.\u003C/p>\u003Cp>It's a symptom of the fact that there's no other way to support your family than working for one of these companies that pays you to be an open source developer. Okay. Another problem that we have is we only program for ourselves, and this is actually a diversity, equity, and inclusion problem is we're great systems programmers, and we make really sophisticated applications for people like us. And thus, the the person on the street may not have heard of open source. They probably heard of blind.\u003C/p>\u003Cp>And if you look at what applications they're using, they are using applications on their phone from Apple and Google, and the infrastructure of those things is open source. So Apple and Google, you know, they they consider the customer to be the product, and the main way that they make revenue is surveilling that customer and presenting advertising to that customer. And, so what we see is that the customer is somewhat abused by these companies, and we enable it. The open source community provides all of the infrastructure for it. So here we are with a world where privacy is concerned while open source stands for privacy.\u003C/p>\u003Cp>Security is a concern, and and we stand for that too. And why aren't we making the applications that everyone uses? Because the developers want to write for themselves and people just like them. And so, well, maybe we need to pay those developers so that they're right for other people. So I I sat down with these ideas and said, okay.\u003C/p>\u003Cp>Maybe it's time to transition beyond open source to something I call post open. And that may not be the permanent name because the permanent name has to be trademarkable. So post open is free for the person that we want to help, which is the common person, the individual, the small business. This is a business with revenue under $5,000,000. End user revenue has to be end user because it's too easy to circumvent otherwise.\u003C/p>\u003Cp>You know, when I worked for a film company, they used to tell us, if your film makes a profit, you're doing your accounting wrong. So end user revenue to prevent circumvention. So if you're a company that makes over that $5,000,000 line or you wish to make proprietary modifications or you wish to put the post open software in a product that you sell, whether it's a device or a service or or a piece of software that you ship, then you have to get a paid license. And once you have a paid license, you pay about 1% of your end user revenue. And once a year, you audit what software you're using and you tell us, and that's compliance.\u003C/p>\u003Cp>If you do the audit, you write a check, and you're done with compliance for the year. Now this is gonna be really important to companies because right now they have $7,000,000 per year open source compliance departments, and and some of them would actually spend less on post open. So now we've got a revenue stream. Okay. We give that revenue back to developers.\u003C/p>\u003Cp>One of the ways that we do it is we instrument their Git repositories and we see who the contributors are. And we've seen from our users what they're using, and thus, we have some idea of how to apportion the money and give it back to the developers. Now in practice, this is more complex because there are people like colonel janitors and architects who might end up having time cards because you don't measure them by lines of code. So we're paying these people. We can also start paying them to write applications for the common person and start to reach that market and maybe displace some of the people who aren't working in the interest of that kind of person today.\u003C/p>\u003Cp>The other thing that we can do is post open is a collection. It's all the software that you put under a post open license, and we can offer support for the entire collection because there's a centralized organization behind this. And the centralized organization offer support for the whole post open collection behind the scenes uses the project maintainers to do maintenance, but they aren't talking to the support customer directly anymore, and they'd be more comfortable that way. They're only in the support business to make money. We funnel the support revenue back to them as well.\u003C/p>\u003Cp>So this is more complicated. It has PR and trust issues because there is a central organization and everyone has to trust it. If it forks a hundred different ways, it won't work for everyone for anyone. It's a very complex idea. I sat down and I wrote the post open license and it was 325 lines.\u003C/p>\u003Cp>And there are actually 4 more documents that go with it. Okay. So there's one for the paid user. There's an operating agreement among the developers, and there's a process for infringers to come back into compliance. So I will end up with well over a 1,000 lines between all of these.\u003C/p>\u003Cp>Fortunately, you don't have to read all of them, just the one that applies to your situation. This may be too complicated to ever happen. This may not gain share, but I think it's an interesting idea. And one of the ways that I would win over the current open source developers and companies like yours is you can dual license post open. So you can continue to be open source, but anyone who's paying for post open now is has got your open source under that agreement and you start getting paid the open source, they start getting easier compliance support, etcetera.\u003C/p>\u003Cp>So, you know, consider a company like yours, when you started today or tomorrow with PostOpen, you could say, I'm going to invest in developing this software, and I'm going to get a lot of users through PostOpen, and I'm going to get revenue through that paradigm. And all of my software can be disclosed. It can be free for everyone for whom it counts that it's free. You know, once you make over $5,000,000 a year, it's not important that something's free any longer. And, so I think there are a lot of reasons that this is very compelling and I'm actually getting very little pushback on the idea that the pushback I'm getting is, well, today, open source is mostly business, and Bruce doesn't realize that.\u003C/p>\u003Cp>Well, that's a symptom. That's not the way it should be. So I'd I'd love to hear, you know, how you feel about this, whether you think it's a total pipe dream.\u003C/p>\u003Cp>Speaker 2: Yeah. You and I spoke\u003C/p>\u003Cp>Speaker 0: about this, Bruce, for a while. The the show is called Bridging Bites, but I think you just bridged questions. Because I think you actually that was a very comprehensive answer, but it actually was an answer to the next two questions that I was gonna ask. So, that was super, super helpful. Obviously, there's strong alignment with what we've done at Directus with our unique usage grants within BSL.\u003C/p>\u003Cp>But before I kinda kinda we chat through that, I'm curious, Steven, what what license are you currently using, for for for Dubco? And I guess just and in response to that, sort of Bruce had kinda called out I think you called it frosted widgets, which sounds like a a really fun cereal.\u003C/p>\u003Cp>Speaker 1: Widget frosting. Actually, Eric Raymond made that up.\u003C/p>\u003Cp>Speaker 0: Oh, well, we called it icing on the cake model. We actually tried that, And we found we were focusing too much on the icing, which is part the part we sell. And the cake, the open source core, was suffering. And so we actually changed our model to this this new licensing strategy based on having tried that. Again, 2 decades, we've tried a lot of different things.\u003C/p>\u003Cp>But, Steven, maybe you could give me your your what what license are you currently on?\u003C/p>\u003Cp>Speaker 2: We're yeah. We're currently on AGPL, which basically means that you can own and host your own, version of Dubb and even keep it close, as long as you keep it open source. If you wanna keep it close source and make changes to it, you have to purchase like an enterprise license. And to to respond to the point about like, you know, monetization and open sources, notoriously really, sort of open source maintainers have been notoriously underpaid and under, you know, loved in a way because there are so many packages out there that's just like people just maintaining it tirelessly, especially if you're not getting paid by a company like Microsoft or Vercel. Vercel does a really good job in in the sense, like, for for, you know, open source repos, like, you know, projects like Turborepo, Next.\u003C/p>\u003Cp>Js, and a few other projects. But if you're not part of that sort of privileged group of developers, you just generally just go out and compensate it. The way we sort of monetize this, we basically have a SaaS offering that is actually not icing on the cake model. It's 1 to 1 exactly, like if you purchase a plan on that, versus if you self hosted, you get the same exact features, but we're sort of moving towards the direction of what telecom is doing, where if you need, like, enterprise features, like, I don't know, RBAC, where it's like role based access access controls or SAML and SSO, all these different, like, enterprise fee feature features, we will put that behind, like, enterprise license. And if you want to use those features, you will have to, you know, purchase, like, a license key, and that's a very, you know, smart model.\u003C/p>\u003Cp>It's sort of an icing on the cake model, but in general, like, there's not exactly discrimination if you're self hosting versus if you're, you know, paying for a subscription. There's also another model that I think is really interesting, which is once.com, the one that's launched by the founders of Basecamp, 37 signals. They're they're doing this model where it's like pay once and use forever, And you it's sort of like that whole story of how software is sort of like a pendulum goes from licensing software to SaaS and now back to licensing. So it's a very interesting model. I personally think it's I don't know how, like, sustainable it is, how scalable it is, but I think there's a lot of potential there.\u003C/p>\u003Cp>And I think as the world thinks more towards, like, privacy, owning own data, I think and as people get more technically savvy and have the infrastructure to do so, I think that's, where this kind of model will will flourish. But as of today, like, I I'm that that's why we're going with, like, the SaaS model where if you really want, like, you know, super easy sign up, create a link, you can just use our SaaS product. And then if you're more technically savvy, you wanna own your own data and privacy or whatever, you can self host it. So that's why we went with that.\u003C/p>\u003Cp>Speaker 0: Yeah. And that's a that's a really strong model. I mean, we again, we had that sort of gated icing. I've I've listened to to Kyle Poyer, at OpenView, RIP, sort of talk about product led growth and usage based pricing and and also how you can gate those features. He had really interesting ideas around how you really shouldn't gate, the features that people real are gonna resonate with users.\u003C/p>\u003Cp>But, you know, people know what SSO is. They they potentially know what RBAC is and how they can leverage it. So to enable those enterprise features at a as a paid offering, I think is a really smart way to do it. It it it's, you know, just really up to you. Like, does that work for your business model or not?\u003C/p>\u003Cp>Does that sort of unlock enough commercialization or not? But yeah. No. That's, I think that's really interesting. Do you have any thoughts before I wanna switch into the sort of q and a.\u003C/p>\u003Cp>And anybody in the audience, feel free to start throwing some comments or some questions in and then we'll we'll get to them in the the last few minutes here. But, what you had described, Bruce, in terms of post open, you know, name pending, seems almost like a multi tenant version of what we did at Directus. Again, just for those who weren't part of our enormous GitHub discussion where we talked about this in public with the community before we made the license change. We basically said, here's the problem. This needs to be sustainable.\u003C/p>\u003Cp>Mouths to feed, you know, as Bruce said with the family. Everyone's got families, that need, to be supported. We said, here's the problem. Here's some solutions. One of which was the BSL license.\u003C/p>\u003Cp>And then we used, interestingly, the same sort of model in parallel with what Bruce said. $5,000,000 and up, and you are sort of this commercial entity that most likely can afford to contribute. You know, again, developers and individuals and hobbyists contribute through code and docs and testing. The large enterprises weren't contributing. So it holds them and makes them, you know, beholden to that commercial license while the majority of users below 5,000,000 can actually use it effectively as free and open source software.\u003C/p>\u003Cp>We did that in public, you know, with some radical transparency to make sure that everybody understood exactly what we're doing and why. And if there are any other options people had, you know, throw them out there and let's let's consider them. In the end, of course, we went with BSL with that usage grant for if it's under $5,000,000, you're completely good. You know, effectively open source for production, commercial, however you wanna use it. But I'm curious, you know, the model that Bruce described, Steven, would that sort of work for you, the sort of multi tenant?\u003C/p>\u003Cp>You use a dual license and then potentially, you know, it's it's sort of a unified system or it's it's one centralized, I don't know if if what you would call it yet, Bruce. But this idea of them collecting revenue from the end user, or or fees and then distributing it. I can imagine it'd be so difficult to have, attribution and, this idea of, like, the composition of who which maintainers get how much revenue. There's a lot of questions to solve there. But any thoughts on that, Steven?\u003C/p>\u003Cp>Just because that's what was my question, like the future of open source. Bruce has sort of pitched this grand idea. I wanna give you a second to respond.\u003C/p>\u003Cp>Speaker 2: Yeah. I think that's definitely very interesting. We've we've definitely considered that in the past, and I personally have start like, tried to do, like you know, there's this there's this really cool tool called Algora that basically allows you to do, like, what's it called? Like, bounties where if if an open source contributor solves one of the bugs or or reports a bug and fixes it or creates a new feature, you can pay out bounties directly to them using using you just need to, like, mention the bot and say, tip a $100 or something like that, and that's really cool. That's it's a really cool way to do it.\u003C/p>\u003Cp>We haven't thought much into, like, obviously, being able to take the end user profits and basically compensate officers maintainers, primarily because we haven't really gotten a lot of, like, contributions so far. I think that's something that we want to sort of encourage and do more in the future. We've definitely got a few really good ones, but I think, as of right now, we haven't invested a lot of introduction to that because of that. But I do think there's also a really interesting distinction between software that you can potentially self host and basically, for example, if you're building, like, I don't know, project management software and that is open source, and you basically are able to take that and just run it on your own instance or whatever, like, a cloud provider that you have versus something that would require a lot of, like, usage based like, I think you mentioned use usage based pricing and stuff like that. Basically, if you're building, like, an AI app that requires, you know, OpenAI, API calls, and that basically costs money to maintain, That's something that's a little bit different because it's like you rely on, like, a proprietary, you know, software, and that's why people are looking into also using open source, providers for LLMs as well, like, Ollama, which is a good one, I think.\u003C/p>\u003Cp>So, basically, there's this interesting sort of bifurcation between open source software that you can easily maintain on your own VM versus one that relies on proprietary APIs, and that's sort of the, sort of we we we're actually currently trying to move away from relying on these, like, providers to something that you can truly own and self host. But but as of right now, it's not fully all the way there yet. So\u003C/p>\u003Cp>Speaker 0: Yeah. And that's again, I think Bruce mentioned the idea of 80 20 rule. That's something that we we've been using, at Directus for a long time, 10 plus years where we the core software is is aiming to solve 80% of the use case and the functionality. And then the last 20% is, you know, configuration and extensions and and custom code. And that's exactly the problem that was that we were trying to solve is you have these, like, paid API keys and and integration with services that might be paid.\u003C/p>\u003Cp>So we make sure those all go into the extensions to avoid that exact issue. So, yeah, it's it's interesting to see sort\u003C/p>\u003Cp>Speaker 2: of that\u003C/p>\u003Cp>Speaker 0: alignment across all these different things that we've been doing, you know, more siloed. There's a few a few questions here. I think we're over time, but let's see if we can get at least to 1. Alec Bass from Efficient. App had asked a few questions.\u003C/p>\u003Cp>One was about, you know, how you figure out what is OpenCore versus maybe, the the gated side. I think we touched on that. So let's ask it go through a second question which was, how do you know if someone is using, you know, say, Dubb or Directus privately within their SaaS or within their system without a license. I'll quickly give my take on that because this is something that we have and continue to talk through at Directus. When we made the change to BSL, much like, of course, that was created by, Maria DB with the original author of the license, Hashicorp and Cockroach and Couchbase and Surreal.\u003C/p>\u003Cp>They've all made that change. That usage grant means that people can use an open source under 5,000,000. But if you're over 5,000,000 or otherwise, how do you keep people honest? You know, we today use an honor system where it's like, that's the license. We hope that you honor it.\u003C/p>\u003Cp>Typically, if you imagine the people who would be the commercial license over 5,000,000, maybe they're more motivated as a larger company to stay true to the legal document. But we've been also exploring the idea of like a key registration system and telemetry that actually, you know, opt in, opt out for GDPR reasons. But let's understand who's using the software. Let's, you know, error reporting or all these different pieces of information can help you give a sense of who's using your software, how they're using it. But obviously, especially with developer tooling where that network traffic is always monitored and should be, You have to be really judicious in what information you you try to send back to yourself to understand who's using the software or how.\u003C/p>\u003Cp>Steve, I guess the question was to you at at Dubb. Do you have any thoughts around how you're doing that now?\u003C/p>\u003Cp>Speaker 2: Yeah. That's incredibly I actually had the had a similar, train of thought as well. We currently don't do telemetry for, like, self hosted versions of Dubb, which can get a little tricky. Like, how do you find people who are self hosting? And that's sort of something that we we want to, like, try and do and bake it into our license in the future where it's, like, it's completely anonymized telemetry simply just to detect, like, how much link redirects that you've used within your self hosted version of Dubb.\u003C/p>\u003Cp>That's 1. And then secondly, I wanted to point out, it's very interesting. Recently, we found a few, like, clones of doubt. They basically took our repo and just ran, like, a commercial service that's completely closed source, and it's, like, a full violation against our license. So that was something that very interesting that we had to deal with.\u003C/p>\u003Cp>We had to, like, I was consulting with my legal counsel, and we wrote, like, a letter to the the hosting provider and say, you know, this is sort of like a DMCA takedown because they're not compliant with the license. So there's a lot of, like, I feel like dealing in open source sort of makes you like a like a legal candidate. You can you can basically, you know, pass the bar now. You know? You learn a lot of these, like, legal stuff, and I definitely learned a lot myself, in terms of, like, evaluating different licenses.\u003C/p>\u003Cp>And I think telemetry is a very good point that you that you pointed out, and I think that's something that we definitely wanna go, in the future. Think cal.com does that really well too. They they basically log, the number of bookings in, like, the the open source self hosted versions that people run-in their servers. And if you cross a certain amount, that's when you need to have, like, enterprise license. It's really smart to have that threshold, as well.\u003C/p>\u003Cp>So yeah.\u003C/p>\u003Cp>Speaker 0: Yeah. No. That that's a that's a huge point.\u003C/p>\u003Cp>Speaker 1: Go ahead, Bruce. So my consulting business, helps the infringer come back into compliance. So this is the company that used open source outside the license, usually got caught, and, now they have to fix it preferably without being sued or spending too much money. And one of the things that I really find surprises to companies is the community knows what is in your compiled software, that out in the open source community, not only the developers, but their users will see something comes out and they'll say, oh, well, this functionality looks like such and such an open source program. And they look inside, which is easier than a lot of people realize, and they see it's there.\u003C/p>\u003Cp>I have in fact found my name in a number of commercial products. And so, if if you make a distributed product containing open source, you're gonna get caught, especially if it's a consumer product because the consumer products are the ones that a lot of people see and care about. It might not happen quite as often in the b to b In a, software as a service business like Dubb, it's a little harder because you might have to look at things like, well, what are the Internet responses here to HTTP, etcetera, and say, well, that's exactly the way that my software would do it. But it it is much easier to get caught than anyone realizes, and it usually happens. Now\u003C/p>\u003Cp>Speaker 0: There will always be workarounds. Right? Like, whatever sort of pricing model or licensing system you put in place or telemetry that, you know, you can always just air gap it, turn off your network, and, you know, it's easy to work around all these things. So you have to incentivize users to do the right thing. And hopefully, you can do that by just having an amazing community and premium software that works well and people want to see continue.\u003C/p>\u003Cp>But, yeah, it's a it's a very slippery slope. I think it's it's really interesting to see, like, how this will progress in the future. We touched on post open, Bruce's idea about, you know, how this could be centralized and sort of funded, in a multi tenant way. We touched on, like, the direct us and and to an extent how Dubb is doing it. I can think Dubb is a little bit more, Steven, correct me if I'm wrong, but sort of this, open core model where you're taking the same software, but you also have, paid features that are gated on the enterprise side and trying to identify exactly what goes in that bucket, and selling those services.\u003C/p>\u003Cp>And then Directus, we've kinda got that unique BSL license similar to kind of both sides, where we are trying to say, you know, the larger players, let's make sure they can shoot contribute. It's an honor system. But at the end of the day, I think what we can all agree on is whatever license or strategy becomes sort of the the really the holy grail of of open source or post open or or free and open source software, whatever the names and terms are, it needs to have critical mass. I think we've seen that in the naming conventions decades ago. We're seeing it now.\u003C/p>\u003Cp>It's really difficult with, you know, the the directest license, you know. It would just be so hard to get, traction there. So whether it's post open or BSL or some, you know, flavor or anything in between, we need we need to get that critical mass. And, of course, that comes with a lot of complexity. We talked about the legal complexity and cost of getting, you know, attorneys to sort of review these documents, trying to make it succinct so people can read it.\u003C/p>\u003Cp>Bruce, you touched on having a lengthy license and how do we sort of distill that down to something that, both legal and developers can, you know, if you're not a lawyer, you can still understand exactly the implications of the license. There's so much sort of at stake here and there's so many people working on how we can solve it. But it's really exciting to have both of you here on Bridging Bites talking about, you know, what this could look like. I think it's gonna have to be a little bit of a TBD to see where we end up. Lots of great questions in the, in the audience.\u003C/p>\u003Cp>Sorry we didn't get to get to all of them. But hopefully we'll be able to circle back on one of the future episodes episodes and cover some more. And of course, we will start texting some of the folks in here and see if we can give some manual responses as well. But I did want to thank, Bruce Perrons, and Stephen Tey for joining, this episode and talking about the past, present, and future of open source. Thank you everybody for for watching, and we'll we'll make sure that this is recorded so everybody can can catch up soon on, Directus TV.\u003C/p>\u003Cp>So that'll be super exciting. Thank you both for joining.\u003C/p>","Let us kick it off. So this is the second episode of Bridging Bytes. This time, we have we have bridged from the last episode of the intersection of design and development, and now we are talking about, the open source Outlook. So, obviously, a very important topic, something that's near and dear to my heart, having worked on Directus now for 2 decades, over half of that as an open source maintainer. And then we have some amazing, guests here that are gonna be leading the chart in terms of this conversation. So I'll be moderating the the chat. I can give a quick background, and then I'll introduce our 2 our 2 guests. So, my name is Ben Haines. I am CEO and founder of Directus, the open source, data management platform. And I've been I built the platform originally in 2004, and we actually open sourced it in around 2010, 2011. So we'll get into more of the history of of what we did in our open source journey. But, I'd like to next introduce Bruce Perrons, who is sort of the the godfather, I think we were calling him, of open source. Bruce actually created the open source initiative, which I think was in 1997. Give her we'll let him 87. When was it? 1987 was the creation of the open source initiative in the open source definition. And the document actually came about, I think, 8 months before, it was then the Debian free software guidelines. Yep. Obviously, there's some interesting aspects of using the word free versus the term that was actually chosen, which was open source. But yeah. So we have Bruce Perrons here, who is the cofounder of the Open Source Initiative. And, you know, great thanks to your work, I believe, within, Debbie. Basically, Bruce, why don't you give a quick, overview of your background and and and what brought you here? I I'm sorry. It really was 97. I'm just going over the calendar in my head. So, 87 was actually when I got to Pixar, and, I started as a filmmaker, was one of the founders of computer graphic 3 d feature film animation, and worked at Pixar and their predecessor in New York for 19 years in total. Have a credit if you go on IMDB on a couple of films. And in, 97 we'll get that right now. I wanted to define what Debian, included, and we created something called the Debian free software guidelines. And then a little later, a group met and said, well, let's market free software to business and call it open source. And, so that happened. And I was called up the next day and I said, well, great. I'll take my Debian free software guidelines and make them the open source definition. And so there we go. It's been a long time, and it's been incredibly successful. If I had said to you, back then, we're going to, give away our software and completely take over the industry by doing it. And we're going to make an encyclopedia, and it's going to be the first thing to put a Microsoft product and Carta out of business. If I had told you that, you would have just said, well, I wanna smoke that dope too. So, so it it's been a long strange trip. Hasn't it? Yeah. Well, I here I am sitting here, you know, so excited to be 20 years in, to the entirety of my project, Directus. And you've got, you know, 20 years under your belt just, you know, with, you know, elements of your your history. So thank you so much, Bruce. It's really exciting to have you here. Lots of knowledge, obviously, spanning back to the the mid nineties and even before with, you know, your work on those projects. I think next, I'd like to introduce Steven Tay who's joining us. Stephen, I'll let you give a quick background from what you did with with Vercel and what you're doing now at dub.co. For sure. It's an honor to be here. I feel incredibly humbled by the the the wealth of experience that you guys bring to the table. I think Bruce was talking about how he he he did that DBL thing in 97. I'm like, that was the year I was born. So it was like a little bit of a it it feels very humbling. But, yeah, my name is Steven. I was, a developer advocate at Vercel for the last two and a half years. I started in 2021. It was there where I got, introduced to the open source community, got to actually learn and became a better developer. Before that, I was doing a lot of, like, data science, coding in Jupyter Notebooks, not really building any, like, software that's used by the end user. So I I learned a ton through my time at, Vercel. I built a lot of open source templates, open source, guides technical guides that people can use to learn about Vercel's technologies like Next. Js, Turbo, Rebo, etcetera. And, it was actually through Vercel. So we we dub this company that I started back in December of last year, it came about as a side project that I built when I was at Versal. I I had this need to, like, be able to share links, on on social media with really nice preview images, and it started from a very niche use case, but then eventually blossomed beyond that into a full link management tool. So, it was in December when I when I started talking to a lot of our users and realized that the market opportunity behind Dubb, It's a start company around it, and here we are. I love that. Thank you so much, Steven. That's a it's an awesome intro. I mean, obviously, we have, you know, different levels of experience, with open source, with building, but that's kind of how open source works. You know, you've got maintainers and contributors and users. You have some projects that are out there and they're just small little packages or libraries like an SDK, you know, with one hobbyist sort of kind of maintaining it on the weekend versus things like Directus and, you know, even larger operating systems or platforms supported by tens or hundreds of developers. And I think, you know, in the last few years, we've seen all sorts of things happen, that really showcase the importance of of open source, vulnerabilities like Log 4J or just the the escalation of different open source platforms, like, really taking hold in the ecosystem. So it's obviously a very timely conversation. Specifically, my passion is around I I've spoken with Bruce for a while about this actually, is about how to build I think it's a nice acronym, SOS, but sustainable open source. Of course, SOS being, you know, talking to how important this is to get right and to do it timely. But I think we can kinda dive in. The purpose of this, Bridging Bytes episode is really to talk about this theme of open source, past, present, and future. You know, we we, of course, have Bruce here to to really help us understand the roots and how this came to be. We made our our platform open source a decade ago, you know, obviously based on the WordPress license using GPL. And then we are we relicensed about 10 months ago. So there's all sorts of things happening in the past and present. And, of course, you have to be really mindful of where do things go next. You know, how do we actually make open source sustainable? I've heard some pretty interesting ideas from Bruce that I'm sure he'll share around his ideas of what he's calling post open, at least as a working title for now. We'll figure out what that might look like. But, yeah, so I think we should we can dive in. And my first question would be for for Bruce. Bruce, I'm curious, in all the experiences that you've had, maybe you could share how those have shaped your views, of the evolution and impact of open source over such a long tenure over over these decades since 1997, not 87, but through now. How do you think that those experiences have shaped, you know, your views on on that evolution? Well, I should just say a long, long time ago as if I'm telling a story because it feels like forever. But, so I I started out, working for a film company, and I I had fun. I mean, we did something for the first time. You know, we we made our IPO. They let us have our IPO at the same time that we put out the first three d feature animated film, which was crazy. And so it it was a really interesting ride, but I started at this point to work on Linux because, we were using Unix at Pixar, and the PC was coming out. The PC started to be capable of running Linux. And then, Steve Jobs for a while had his office right across from mine. This was not because I was important, but because they wanted to keep an eye on me. And so, one day, Steve made his peace with Bill Gates, and the next workstation stopped being on Steve's desk, and there was a Windows laptop. And Steve would tell us that, you know, eventually, we'd switch off of Unix, and we'd all be using Windows to do our animation. And no one was very happy with that, and especially then because before Linux was really big, the quality of Windows was very poor because they could afford to have very poor quality. They were essentially the only game in town. And so I started working on Linux and tried SLS and a few other things, you know, ancient distributions, and and then landed on Debian. And at the time, my idea was making a Linux system for amateur radio operators, ham radio. And the reason for that was there was a lot we could do with software, and I thought we could put it all together. Well, that never happened, but I became Debian project leader along the way. And I think it was becoming more important than my work at Pixar. And the real moment for me was one day I got an email from someone and they said, I wanna use Debian with a serial console. Do you can you tell me how? And that wasn't a feature at the time. And I thought it was interesting, and I I sat down at Pixar, you know, when I should have been working and figured out how to do it and sent this fellow an email. And he wrote back and said, that works great. This is going on the next space shuttle flight. And so I walked all around Pixar looking for someone to tell this to. The only person there who knew about Linux was working from home that day. And so, it came a time when people would say to me, well, you're having such an exciting life. You've come out with a film, and your company has an IPO. And isn't this so exciting? And I'd say, yeah. But my hobby project is orbiting in space. And at that point, I sorta decided maybe I would eventually leave Pixar and work on Linux and open source full time. And so we have had a history of that sort of serendipity. I mean, the hobby project of a students. You know, Linus was a student and maybe a lecturer, takes over the operating system world, and the industry software is taken over by amateurs who give away their software. I mean, at this point, none of them were working for companies. And IBM abandoned AIX in favor of this hobby project. So all of these amazing things were happening and why the world was ready. There was a a market vacuum, and this came along and filled it. And people don't realize that this is all straight economics. It's it's no you know, some people call it freakonomics, but there's nothing freaky about it. It's just economics. Yeah. I mean, it it goes without saying, you know, by some estimates, you know, open source power is 80% of modern code. So, you know, there's quotes from people over at Google, Filippo Valsorta, who had said something. I've had this quote here. He said, open source software runs the Internet and by extension the economy. And I think that kind of really qualifies like how large open source has become. Obviously, in the early days when you're working, on defining it, Bruce, there was all sorts of there was the, I think you mentioned in Debian, you had the Debian Social contract, in 93. And there's the SPI, which was, you know, software for the public interest. You did the OSI, the Open Source Initiative. There's all sorts of, like, what's the term gonna be? What are the rules? How do we, you know, really label these things? And what we got from that is essentially ten sort of rules or guidelines for what is open source, which is right there, you know, on opensource.org. It was how did you guys come up with those 10 terms? I mean, I I I've looked at them quite a bit because we have an open source source spirit. You know, our ethos has been that since the beginning. But, of course, with a license change and trying to stay true to the terminology of source available versus open source versus whatever new terms we come up with, there's always gonna be those 10 terms sitting there within the OSI. So was that was that an easy or difficult thing to, you know, sort of memorialize for the world? Well, first, I don't wanna take all the credit. We are standing on the shoulders of Richard Stallman and the free software movement. And, Richard and I were actually speaking at a UN Summit in Tunisia, and I said we're standing on the shoulders of Richard Stallman, and he goes like this. And so, I think that we've had a lot of, different words for what we're doing. And because of that, the concept of having a brand came up. You know, there was free software and there was Shareware. Remember Shareware? And Shareware and Freeware. There was, like, all the wheres. And it's interesting thinking of, like, how the word free left. Like, you still have thos, you know, free and open source software. But, you know, the freeware versus open source and the difference in perception, again, something that we deal with when we're now selling licenses for, you know, we've for years, been selling licenses for open source software through our cloud SaaS and, you know, breaking the perception of from free to paid is an interesting gap to kind of, cross. But So so I'll give you another word that everyone's forgotten, consortium. It used to be that real software products were made by consortia, which was a collaboration of companies. And the problem was that they all had their own different interests and that the engineers did not control the operation. So the consortia had a lot of trouble getting along. And my very favorite, consortium story is the X Window System Consortium decided one day that they would not have a canonical user interface for x. And Microsoft, of course, ate their lunch because they did. And and what the x consortium was trying to do at that point was allow each of the different Unix workstation manufacturers to differentiate their work station and also to lock in their customers by having a different user interface for that version of Unix. And they didn't realize that if they didn't work together, Microsoft would just take over the market and, you know, go find a Unix workstation today that isn't a a Linux or BSD system on a PC. So we had all of these economic issues, and we also had the need to create a brand. And so the open source initiative came by because, in Debian, we wanted to say what Debian was, and also we wanted to elucidate our social contract with the community. And so we, wrote the Debian social contract and the Debian free software guidelines. I sort of created and edited it, and we had a 1 month discussion with the Debian developers about it and then publish the results. And this, part of it became the open source initiative, definition. The Debian social guidelines is still very prominent on the Debian site, and you can see the other part that became the open source definition at the end of it. Yeah. No. And that's something I think referred to quite a bit, especially as new licenses come out, you know, making sure they check all 10 of those boxes, to truly call themselves open source, you know, and not have some big glaring asterisk. Yeah. That's it's amazing just to hear the history of, like, all this tumultuous, like, what is this you know, there's just a huge landscape that was not defined. So it's exciting to hear it was defined. Same issues that we're still facing today in terms of how you get financing and make sure you have an authoritative, list of of defining what this is, and that that's being, fostered by people who actually care about what it what it's supposed to mean and not just guiding it based on commercial endeavors. Steven, I'd like to, start over to you. Obviously, you've had, 2 sort of key roles that that you highlighted in your intro. Obviously, going from DevRel over at Vercel, to now founding, dub.co. I'm curious how your perspectives of open source, you know, in the development of those those open source projects has changed, and evolved over that transition of your your career. Yeah. For sure. I think there's there's definitely been quite a shift in terms of, like, the way open source, I guess, the way we view open source personally. But one thing has always stayed true, and I can go through the distinctions there. So when I was at Vercel, we basically maintained this fairly popular React framework called Next. Js. It's basically a framework for you to build with React, service side rendering, and basically an entire full stack applications with batteries built in, like API routes. You can even do stuff like, having a middleware to do redirects, rewrites, and all these different things that regular React would, you know, it'd be harder to build with that. And through Next. Js, it we were able to tap into a massive customer group and and not, I guess, not exactly customers, but, like, potential users that could be converted to customers. Folks like, let me see here. Like, folks like, Netflix. I I I remember tweeting at one time that 4 of the world's largest streaming platforms, Hulu, max.com, Amazon Video, Netflix, they were all using XJaaS, which is kinda cool to see. And, through that sort of, I guess, user base, we're able to expand our enterprise, pipeline because we are able to tap into engineering managers who are using X. Js and and sort of pitch them our host of solution and give them a sort of white gloved approach to spinning up and and maintaining that Next. Js applications. So in that sense, the symbiotic relationship between Next. Js and Resell was very clear. It was like, you know, you have this open source framework, MIT licensed, and you have this proprietary hosted solution that basically, does your Next. Js hosting for you, and you have you have to worry about stuff like Kubernetes maintenance and stuff like that. So that was that that sort of relationship was very interesting. And the work that I did there was also sort of different because, I wasn't working a lot on Next. Js specifically. I was mostly more working on developer efficacy, which is building open source templates, and that sort of, like, drew me to gravitate towards another side of open source, which is building templates and also products that are open source, but at the same time, licensed under AGPL, which would give you, the the maintainer or the the company behind the project a certain level of ownership and control, over how the prod the the code is distributed. So, that sort of drew me to to basically build Dubb as an open source, first project. It started as a project, and it's it's our company. And, so the relationship here is slightly different. Right? It's it's more of a we we call ourselves a cost, which is like a commercial open source, software, which is similar to what, for example, MongoDB started back in the day with, like they had their open source database system that people can easily clone and just run it themselves. And then now it sort of evolved into the wave of, companies like cal.com, which is an entirely open source company sorry, open source product that's, they have their repo, it's out in the public, and they also run that for the hosted service. And they also have, like, a directory that is enterprise only. So if you want to use code in that directory, you would have to buy an enterprise license. And that's sort of the direction that we're going towards, and it certainly has changed quite a bit about how I think about licenses, how I think about getting contributor permissions, and stuff like that. There's so much nuance to to this whole ecosystem that, honestly, I'm still trying to figure out. I'm working with a few lead councils to understand where we should be, you know, what sort of precautions should we take, what sort of, licenses should we potentially change to in the future. So, yeah, very excited to to to discuss this with you guys more and and sort of get your thoughts and and advice on this this whole, space and how we we should move forward. Yeah. No. That that's awesome. I think I mean, I've seen I've lived several of those different iterations of, like, how you commercialize, how you make that more sustainable. Seemed like you were describing sort of like an open core model. Sometimes, you know, you can also work that and call it like an icing on the cake model. There's also the support, like the professional services where you have almost like an agency that leverages it and to get that support and the authoritative maintainers, you know, access to them. That's a paid service. Of course, that can be difficult to scale because you have to scale humans, and not just scale the software out, as you distribute it. So it's interesting to hear, you know, all the different methods. And it kind of ties me into there's a few other questions I'd like to run through before we open it up to the audience. But maybe we'll we'll rapid fire these so that we can actually make sure we we work our way through it. But I think the next one that I think is interesting in this, you know, mid nineties all the way through the mid 20 twenties, where we are now, what would you either of you say are some of, like, the biggest milestones that have significantly impacted this open source landscape? You know, whether it's for maintainers, users, and awareness of, you know, open source as a whole. I'm just curious. I'll I'll leave that pretty broad. But any big developments or milestones that, you guys can think of regarding open source? Well, I'll talk about myself. In 2005, I wrote a paper called the emerging economic paradigm of open source. And I think that it's very relevant to business and so called costs or commercial open source businesses because it explains how the economics work and goes into the business differentiator of your business. And every business has differentiators, which make their business appear different directly to the customers than others. And, you know, one of your differentiators is you've got dub.c0, and other people have 7 or 8 long, character URLs. And so, we can open source everything but our business differentiators and collaborate with our very worst competitors on everything but our business differentiators because they're probably the people who need the same infrastructure we do. But we shouldn't open source our business differentiators until they rot. And over time, they will no longer be differentiating your business because other companies will have them. And at that point, it makes perfect sense, for that to be open source. So I think this perception of where open source could actually fit in a business and that you were not creating economic suicide and joining the communist workers' paradise by, taking it up, was a a very important one, and and I think that it was pioneered by the big Internet companies. And so when Google and others take up open source, everyone else notices and says, well, these guys are making tons of money, and maybe there's something we should do there too. Another thing I talked about in that paper was a sort of 80 20 phenomenon, which is 80% of the software in your business is non differentiating. So you have a choice of how you make it. You can build it yourself because you have not invented hear disease, and you think everything you do in your company is better. This used to be a a more prevalent thing than it is today. Or you can get it from the open source community. So say you use open source to reduce the cost and risk of developing that 80% of non differentiating software. You take the money that you saved on that, and you move it into making your business differentiators better. And it was the development of economic perceptions like this that I think made it smooth for a company to participate in open source. And and I'm not taking the credit. I think everyone could have made the same observations. But if you, go back and look at that paper, I think it's still very relevant to businesses today. Yeah. No. And certain certainly a large milestone. Steven, any thoughts on other other milestones in the open source world? Yeah. I'm I was struggling to come up with one because, I'm fairly new to that open source space, but I I just wanna comment on what Bruce mentioned. I think it's very, very, interesting to hear about that 80 20. It's sort of like the paradox principle where you you take the the you basically leverage open source as a way to collaborate with other amazing developers. And I feel like for us personally at Dubb, the 3 sort of main benefits of being open source is 1, you get to tap into this massive talent developers and people that are, you know, constantly, contributing to open source code, and as a result, your code base becomes more secure. I believe Mark Zuckerberg came up with this quote in an interview a long time ago is that open source software is generally more secure. So that's one. And secondly, there's also the aspect of tapping into larger enterprise customers that you never would have been able to work with if you're not open source. So in our case, Dubb is actually used, we're currently working with the government of Malaysia, which coincidentally is where I'm from, to basically, they're they're forking our our code base to build, like, a official government link shortener for the employees to be able to use, and that's something that we could never have done if we were closed source and they will have to subscribe to our software. So that's something that's really cool to be able to collaborate with all these different, like, agencies that have much larger, like, bureaucratic red tape, stuff like that. And thirdly, definitely the the aspect around open source and the trust and transparency that goes into it is also massive. Like, you cannot just be putting spyware or, like, you know, like, ads and, like, what's it called, privacy invasion software into your code base just because you wanna, like, track your users or, like, I don't know, find a way to sell ads and stuff like that because your code is fully out there and people are scrutinizing it. So and as a result, like, companies are willing to trust and use the software more and goes through procurement much easier than if it was closed sourced. So Yeah. I feel like those are the 3 that we've seen so far. Yeah. It's interest yeah. And I it's interesting to think of how much trust you can get. You've made your source available. You've made it open source, you know, through the license. These these steps are amazing to make to give you the transparency you need, which as you said, like, there's no hidden code. There's no black box, and it's like, oh, what happens there? You're sending, you know, telemetry back to the mother ship or something weird and you're just unaware. But it's interesting that that transparency, while it does give you the ability to audit the code, you know, we at Directus were actually in use in the public sector. So the Department of Defense in the US and the Department of Energy. You know, we couldn't really do those things if they couldn't see the code end to end. But at the same time, smaller open source organizations, almost always underfunded, really can't afford the security analysis or security researchers, to actually formally ensure that it is the code is audited audited. You know? So auditable and audited are 2 different things. And I think one milestone that comes to mind for me was sort of that big moment with log for 4 j or log you know, from the log 4 shell, vulnerability where people suddenly were very aware of how reliant, everything in the world was to open source, you know, specifically this one package. But, that I think was a really big moment for beyond just open source maintainers that are aware of their own value, of course, but everybody leveraging their systems to be also aware of how critical open source is to what they're building. So It's crazy. It's I was chatting with this, the he's a product manager at TypeScript of TypeScript at Microsoft, and, we were talking about this, it's a funny analogy where that's I think it's like the what's it called? Like, p k p x p xcd comic or something where it's like p xcd? SKCD comic. Exactly. Where it's like this entire world that's, like, balancing on the shoulders of one big wall. Yeah. It's a very famous it's a very famous one. You've got this, like, Jenga Castle, and then suddenly there's, like, one little piece that could not be removed, which is They buy a hobbyist in Ohio. Yeah. So exact exactly. It's one of the probably the most popular xkcd comics if if editing can, like, toss it somewhere on here so everybody can see what we're talking about. But, super, super interesting to kind of visualize exactly what we're talking about here. And I think before, you know, some of those bigger vulnerabilities, people just weren't aware of it. Now they are, and, of course, we're trying to remediate how do we solve that. Not always the easiest thing to resolve, but I think the visibility and awareness of, open source, whether it's commercial or free or otherwise, it needs to be sustainable. This is not only a hobbyist project for people. This is, you know, supporting big enterprises and and therefore, you know, big parts of the economy. I think there's another point that's really important about security especially is that the size of the code base that we use increases exponentially. So when open source started, a 100000 line code base was a large code base. Debian, I think, is now 1,500,000,000 lines. And so as the size of the code base increases, of course, the attack surface increases as well. And, thus, we are now at the point where no company can look at everything with their own employees regardless of the size of the company. To your point, Bruce, the scale of everything is getting so big. I mean, I forget figured was it called everything or whatever that NPM package was that had a dependency of everything? The dependency trees. You know, when we go through our institutional financing, there's big checks to make sure that we've done everything appropriately, and you have to provide for your software the full dependency tree. Those things just get so enormous, you know, to your points. Everything depends on other things. And then you have some crazy joke, like, whatever that everything package, I think that's what it was called, That suddenly you can't remove because it is a dependency on so it becomes very complex very quickly. And how do I get out of this complexity and make things sustainable? I I guess it's sort of the next question Yeah. That I'd love to cover is, you know, you have these open source projects, hobbyists or otherwise. Obviously, we're talking about how heavily relied upon they are. How can those projects and maintainers transition to commercial viability, to sustainability, to supporting themselves? And as the project grows, again, myself and Drake, you know, created this, you know, 10 years ago. We were working on it together, just the 2 of us, as an open source org. Now there's 30 people at the company full time that it takes, to kinda support this this project. Those are full time salaries. That's a big, big cost. I'd love to hear your, both your thoughts on how these open source projects can transition to, a you know, to be commercially viable. Well, I think they do it kind of poorly today. And so let's take support because support is the way that a lot of companies try to make money, and open source companies don't do support very well. Why is that? Because they support their own program. Okay? Now say you're a customer, an enterprise customer, and you have 200 important open source programs in your business, then maybe you have 200 support entities. And your job when a bug comes up is to isolate the bug, figure out which of those support entities to call, and then convince them it really is their fault while they all point at each other. And so, open source support, I don't think works all that well, and people get IBM support contracts because IBM says we're gonna support everyone. So that's one of the big problems that we have. Saying support is not a good option. What would be, like, what would be a an actual like a viable commercial option then for these maintainers to, bootstrap themselves? Well, continuing to talk about how open source does it today, we also have the widget frosting paradigm, which is you take a, open source thing and then you sell a proprietary enhancement to it. And so that is the way I believe that your company operates beside its support revenue and that a lot of companies do it. You don't have to do it right now in Dubb because you own Dubb. But if you had a whole lot of different, link aggregation companies doing the exact same thing, you'd have to sit back and say, well, I'm gonna have to strategize again. So we've really been doing open source for a long time, and it is time to sit back and re strategize open source to achieve some of the things that we haven't achieved. Okay. So number 1, if the developer does not work for, one of these companies like Google that actually pays developers to do open source, they're probably not compensated. If they don't work for Google, they don't work for your company. And I've had people say to me, well, open source is mostly in companies today. That's a symptom. It's a symptom of the fact that there's no other way to support your family than working for one of these companies that pays you to be an open source developer. Okay. Another problem that we have is we only program for ourselves, and this is actually a diversity, equity, and inclusion problem is we're great systems programmers, and we make really sophisticated applications for people like us. And thus, the the person on the street may not have heard of open source. They probably heard of blind. And if you look at what applications they're using, they are using applications on their phone from Apple and Google, and the infrastructure of those things is open source. So Apple and Google, you know, they they consider the customer to be the product, and the main way that they make revenue is surveilling that customer and presenting advertising to that customer. And, so what we see is that the customer is somewhat abused by these companies, and we enable it. The open source community provides all of the infrastructure for it. So here we are with a world where privacy is concerned while open source stands for privacy. Security is a concern, and and we stand for that too. And why aren't we making the applications that everyone uses? Because the developers want to write for themselves and people just like them. And so, well, maybe we need to pay those developers so that they're right for other people. So I I sat down with these ideas and said, okay. Maybe it's time to transition beyond open source to something I call post open. And that may not be the permanent name because the permanent name has to be trademarkable. So post open is free for the person that we want to help, which is the common person, the individual, the small business. This is a business with revenue under $5,000,000. End user revenue has to be end user because it's too easy to circumvent otherwise. You know, when I worked for a film company, they used to tell us, if your film makes a profit, you're doing your accounting wrong. So end user revenue to prevent circumvention. So if you're a company that makes over that $5,000,000 line or you wish to make proprietary modifications or you wish to put the post open software in a product that you sell, whether it's a device or a service or or a piece of software that you ship, then you have to get a paid license. And once you have a paid license, you pay about 1% of your end user revenue. And once a year, you audit what software you're using and you tell us, and that's compliance. If you do the audit, you write a check, and you're done with compliance for the year. Now this is gonna be really important to companies because right now they have $7,000,000 per year open source compliance departments, and and some of them would actually spend less on post open. So now we've got a revenue stream. Okay. We give that revenue back to developers. One of the ways that we do it is we instrument their Git repositories and we see who the contributors are. And we've seen from our users what they're using, and thus, we have some idea of how to apportion the money and give it back to the developers. Now in practice, this is more complex because there are people like colonel janitors and architects who might end up having time cards because you don't measure them by lines of code. So we're paying these people. We can also start paying them to write applications for the common person and start to reach that market and maybe displace some of the people who aren't working in the interest of that kind of person today. The other thing that we can do is post open is a collection. It's all the software that you put under a post open license, and we can offer support for the entire collection because there's a centralized organization behind this. And the centralized organization offer support for the whole post open collection behind the scenes uses the project maintainers to do maintenance, but they aren't talking to the support customer directly anymore, and they'd be more comfortable that way. They're only in the support business to make money. We funnel the support revenue back to them as well. So this is more complicated. It has PR and trust issues because there is a central organization and everyone has to trust it. If it forks a hundred different ways, it won't work for everyone for anyone. It's a very complex idea. I sat down and I wrote the post open license and it was 325 lines. And there are actually 4 more documents that go with it. Okay. So there's one for the paid user. There's an operating agreement among the developers, and there's a process for infringers to come back into compliance. So I will end up with well over a 1,000 lines between all of these. Fortunately, you don't have to read all of them, just the one that applies to your situation. This may be too complicated to ever happen. This may not gain share, but I think it's an interesting idea. And one of the ways that I would win over the current open source developers and companies like yours is you can dual license post open. So you can continue to be open source, but anyone who's paying for post open now is has got your open source under that agreement and you start getting paid the open source, they start getting easier compliance support, etcetera. So, you know, consider a company like yours, when you started today or tomorrow with PostOpen, you could say, I'm going to invest in developing this software, and I'm going to get a lot of users through PostOpen, and I'm going to get revenue through that paradigm. And all of my software can be disclosed. It can be free for everyone for whom it counts that it's free. You know, once you make over $5,000,000 a year, it's not important that something's free any longer. And, so I think there are a lot of reasons that this is very compelling and I'm actually getting very little pushback on the idea that the pushback I'm getting is, well, today, open source is mostly business, and Bruce doesn't realize that. Well, that's a symptom. That's not the way it should be. So I'd I'd love to hear, you know, how you feel about this, whether you think it's a total pipe dream. Yeah. You and I spoke about this, Bruce, for a while. The the show is called Bridging Bites, but I think you just bridged questions. Because I think you actually that was a very comprehensive answer, but it actually was an answer to the next two questions that I was gonna ask. So, that was super, super helpful. Obviously, there's strong alignment with what we've done at Directus with our unique usage grants within BSL. But before I kinda kinda we chat through that, I'm curious, Steven, what what license are you currently using, for for for Dubco? And I guess just and in response to that, sort of Bruce had kinda called out I think you called it frosted widgets, which sounds like a a really fun cereal. Widget frosting. Actually, Eric Raymond made that up. Oh, well, we called it icing on the cake model. We actually tried that, And we found we were focusing too much on the icing, which is part the part we sell. And the cake, the open source core, was suffering. And so we actually changed our model to this this new licensing strategy based on having tried that. Again, 2 decades, we've tried a lot of different things. But, Steven, maybe you could give me your your what what license are you currently on? We're yeah. We're currently on AGPL, which basically means that you can own and host your own, version of Dubb and even keep it close, as long as you keep it open source. If you wanna keep it close source and make changes to it, you have to purchase like an enterprise license. And to to respond to the point about like, you know, monetization and open sources, notoriously really, sort of open source maintainers have been notoriously underpaid and under, you know, loved in a way because there are so many packages out there that's just like people just maintaining it tirelessly, especially if you're not getting paid by a company like Microsoft or Vercel. Vercel does a really good job in in the sense, like, for for, you know, open source repos, like, you know, projects like Turborepo, Next. Js, and a few other projects. But if you're not part of that sort of privileged group of developers, you just generally just go out and compensate it. The way we sort of monetize this, we basically have a SaaS offering that is actually not icing on the cake model. It's 1 to 1 exactly, like if you purchase a plan on that, versus if you self hosted, you get the same exact features, but we're sort of moving towards the direction of what telecom is doing, where if you need, like, enterprise features, like, I don't know, RBAC, where it's like role based access access controls or SAML and SSO, all these different, like, enterprise fee feature features, we will put that behind, like, enterprise license. And if you want to use those features, you will have to, you know, purchase, like, a license key, and that's a very, you know, smart model. It's sort of an icing on the cake model, but in general, like, there's not exactly discrimination if you're self hosting versus if you're, you know, paying for a subscription. There's also another model that I think is really interesting, which is once.com, the one that's launched by the founders of Basecamp, 37 signals. They're they're doing this model where it's like pay once and use forever, And you it's sort of like that whole story of how software is sort of like a pendulum goes from licensing software to SaaS and now back to licensing. So it's a very interesting model. I personally think it's I don't know how, like, sustainable it is, how scalable it is, but I think there's a lot of potential there. And I think as the world thinks more towards, like, privacy, owning own data, I think and as people get more technically savvy and have the infrastructure to do so, I think that's, where this kind of model will will flourish. But as of today, like, I I'm that that's why we're going with, like, the SaaS model where if you really want, like, you know, super easy sign up, create a link, you can just use our SaaS product. And then if you're more technically savvy, you wanna own your own data and privacy or whatever, you can self host it. So that's why we went with that. Yeah. And that's a that's a really strong model. I mean, we again, we had that sort of gated icing. I've I've listened to to Kyle Poyer, at OpenView, RIP, sort of talk about product led growth and usage based pricing and and also how you can gate those features. He had really interesting ideas around how you really shouldn't gate, the features that people real are gonna resonate with users. But, you know, people know what SSO is. They they potentially know what RBAC is and how they can leverage it. So to enable those enterprise features at a as a paid offering, I think is a really smart way to do it. It it it's, you know, just really up to you. Like, does that work for your business model or not? Does that sort of unlock enough commercialization or not? But yeah. No. That's, I think that's really interesting. Do you have any thoughts before I wanna switch into the sort of q and a. And anybody in the audience, feel free to start throwing some comments or some questions in and then we'll we'll get to them in the the last few minutes here. But, what you had described, Bruce, in terms of post open, you know, name pending, seems almost like a multi tenant version of what we did at Directus. Again, just for those who weren't part of our enormous GitHub discussion where we talked about this in public with the community before we made the license change. We basically said, here's the problem. This needs to be sustainable. Mouths to feed, you know, as Bruce said with the family. Everyone's got families, that need, to be supported. We said, here's the problem. Here's some solutions. One of which was the BSL license. And then we used, interestingly, the same sort of model in parallel with what Bruce said. $5,000,000 and up, and you are sort of this commercial entity that most likely can afford to contribute. You know, again, developers and individuals and hobbyists contribute through code and docs and testing. The large enterprises weren't contributing. So it holds them and makes them, you know, beholden to that commercial license while the majority of users below 5,000,000 can actually use it effectively as free and open source software. We did that in public, you know, with some radical transparency to make sure that everybody understood exactly what we're doing and why. And if there are any other options people had, you know, throw them out there and let's let's consider them. In the end, of course, we went with BSL with that usage grant for if it's under $5,000,000, you're completely good. You know, effectively open source for production, commercial, however you wanna use it. But I'm curious, you know, the model that Bruce described, Steven, would that sort of work for you, the sort of multi tenant? You use a dual license and then potentially, you know, it's it's sort of a unified system or it's it's one centralized, I don't know if if what you would call it yet, Bruce. But this idea of them collecting revenue from the end user, or or fees and then distributing it. I can imagine it'd be so difficult to have, attribution and, this idea of, like, the composition of who which maintainers get how much revenue. There's a lot of questions to solve there. But any thoughts on that, Steven? Just because that's what was my question, like the future of open source. Bruce has sort of pitched this grand idea. I wanna give you a second to respond. Yeah. I think that's definitely very interesting. We've we've definitely considered that in the past, and I personally have start like, tried to do, like you know, there's this there's this really cool tool called Algora that basically allows you to do, like, what's it called? Like, bounties where if if an open source contributor solves one of the bugs or or reports a bug and fixes it or creates a new feature, you can pay out bounties directly to them using using you just need to, like, mention the bot and say, tip a $100 or something like that, and that's really cool. That's it's a really cool way to do it. We haven't thought much into, like, obviously, being able to take the end user profits and basically compensate officers maintainers, primarily because we haven't really gotten a lot of, like, contributions so far. I think that's something that we want to sort of encourage and do more in the future. We've definitely got a few really good ones, but I think, as of right now, we haven't invested a lot of introduction to that because of that. But I do think there's also a really interesting distinction between software that you can potentially self host and basically, for example, if you're building, like, I don't know, project management software and that is open source, and you basically are able to take that and just run it on your own instance or whatever, like, a cloud provider that you have versus something that would require a lot of, like, usage based like, I think you mentioned use usage based pricing and stuff like that. Basically, if you're building, like, an AI app that requires, you know, OpenAI, API calls, and that basically costs money to maintain, That's something that's a little bit different because it's like you rely on, like, a proprietary, you know, software, and that's why people are looking into also using open source, providers for LLMs as well, like, Ollama, which is a good one, I think. So, basically, there's this interesting sort of bifurcation between open source software that you can easily maintain on your own VM versus one that relies on proprietary APIs, and that's sort of the, sort of we we we're actually currently trying to move away from relying on these, like, providers to something that you can truly own and self host. But but as of right now, it's not fully all the way there yet. So Yeah. And that's again, I think Bruce mentioned the idea of 80 20 rule. That's something that we we've been using, at Directus for a long time, 10 plus years where we the core software is is aiming to solve 80% of the use case and the functionality. And then the last 20% is, you know, configuration and extensions and and custom code. And that's exactly the problem that was that we were trying to solve is you have these, like, paid API keys and and integration with services that might be paid. So we make sure those all go into the extensions to avoid that exact issue. So, yeah, it's it's interesting to see sort of that alignment across all these different things that we've been doing, you know, more siloed. There's a few a few questions here. I think we're over time, but let's see if we can get at least to 1. Alec Bass from Efficient. App had asked a few questions. One was about, you know, how you figure out what is OpenCore versus maybe, the the gated side. I think we touched on that. So let's ask it go through a second question which was, how do you know if someone is using, you know, say, Dubb or Directus privately within their SaaS or within their system without a license. I'll quickly give my take on that because this is something that we have and continue to talk through at Directus. When we made the change to BSL, much like, of course, that was created by, Maria DB with the original author of the license, Hashicorp and Cockroach and Couchbase and Surreal. They've all made that change. That usage grant means that people can use an open source under 5,000,000. But if you're over 5,000,000 or otherwise, how do you keep people honest? You know, we today use an honor system where it's like, that's the license. We hope that you honor it. Typically, if you imagine the people who would be the commercial license over 5,000,000, maybe they're more motivated as a larger company to stay true to the legal document. But we've been also exploring the idea of like a key registration system and telemetry that actually, you know, opt in, opt out for GDPR reasons. But let's understand who's using the software. Let's, you know, error reporting or all these different pieces of information can help you give a sense of who's using your software, how they're using it. But obviously, especially with developer tooling where that network traffic is always monitored and should be, You have to be really judicious in what information you you try to send back to yourself to understand who's using the software or how. Steve, I guess the question was to you at at Dubb. Do you have any thoughts around how you're doing that now? Yeah. That's incredibly I actually had the had a similar, train of thought as well. We currently don't do telemetry for, like, self hosted versions of Dubb, which can get a little tricky. Like, how do you find people who are self hosting? And that's sort of something that we we want to, like, try and do and bake it into our license in the future where it's, like, it's completely anonymized telemetry simply just to detect, like, how much link redirects that you've used within your self hosted version of Dubb. That's 1. And then secondly, I wanted to point out, it's very interesting. Recently, we found a few, like, clones of doubt. They basically took our repo and just ran, like, a commercial service that's completely closed source, and it's, like, a full violation against our license. So that was something that very interesting that we had to deal with. We had to, like, I was consulting with my legal counsel, and we wrote, like, a letter to the the hosting provider and say, you know, this is sort of like a DMCA takedown because they're not compliant with the license. So there's a lot of, like, I feel like dealing in open source sort of makes you like a like a legal candidate. You can you can basically, you know, pass the bar now. You know? You learn a lot of these, like, legal stuff, and I definitely learned a lot myself, in terms of, like, evaluating different licenses. And I think telemetry is a very good point that you that you pointed out, and I think that's something that we definitely wanna go, in the future. Think cal.com does that really well too. They they basically log, the number of bookings in, like, the the open source self hosted versions that people run-in their servers. And if you cross a certain amount, that's when you need to have, like, enterprise license. It's really smart to have that threshold, as well. So yeah. Yeah. No. That that's a that's a huge point. Go ahead, Bruce. So my consulting business, helps the infringer come back into compliance. So this is the company that used open source outside the license, usually got caught, and, now they have to fix it preferably without being sued or spending too much money. And one of the things that I really find surprises to companies is the community knows what is in your compiled software, that out in the open source community, not only the developers, but their users will see something comes out and they'll say, oh, well, this functionality looks like such and such an open source program. And they look inside, which is easier than a lot of people realize, and they see it's there. I have in fact found my name in a number of commercial products. And so, if if you make a distributed product containing open source, you're gonna get caught, especially if it's a consumer product because the consumer products are the ones that a lot of people see and care about. It might not happen quite as often in the b to b In a, software as a service business like Dubb, it's a little harder because you might have to look at things like, well, what are the Internet responses here to HTTP, etcetera, and say, well, that's exactly the way that my software would do it. But it it is much easier to get caught than anyone realizes, and it usually happens. Now There will always be workarounds. Right? Like, whatever sort of pricing model or licensing system you put in place or telemetry that, you know, you can always just air gap it, turn off your network, and, you know, it's easy to work around all these things. So you have to incentivize users to do the right thing. And hopefully, you can do that by just having an amazing community and premium software that works well and people want to see continue. But, yeah, it's a it's a very slippery slope. I think it's it's really interesting to see, like, how this will progress in the future. We touched on post open, Bruce's idea about, you know, how this could be centralized and sort of funded, in a multi tenant way. We touched on, like, the direct us and and to an extent how Dubb is doing it. I can think Dubb is a little bit more, Steven, correct me if I'm wrong, but sort of this, open core model where you're taking the same software, but you also have, paid features that are gated on the enterprise side and trying to identify exactly what goes in that bucket, and selling those services. And then Directus, we've kinda got that unique BSL license similar to kind of both sides, where we are trying to say, you know, the larger players, let's make sure they can shoot contribute. It's an honor system. But at the end of the day, I think what we can all agree on is whatever license or strategy becomes sort of the the really the holy grail of of open source or post open or or free and open source software, whatever the names and terms are, it needs to have critical mass. I think we've seen that in the naming conventions decades ago. We're seeing it now. It's really difficult with, you know, the the directest license, you know. It would just be so hard to get, traction there. So whether it's post open or BSL or some, you know, flavor or anything in between, we need we need to get that critical mass. And, of course, that comes with a lot of complexity. We talked about the legal complexity and cost of getting, you know, attorneys to sort of review these documents, trying to make it succinct so people can read it. Bruce, you touched on having a lengthy license and how do we sort of distill that down to something that, both legal and developers can, you know, if you're not a lawyer, you can still understand exactly the implications of the license. There's so much sort of at stake here and there's so many people working on how we can solve it. But it's really exciting to have both of you here on Bridging Bites talking about, you know, what this could look like. I think it's gonna have to be a little bit of a TBD to see where we end up. Lots of great questions in the, in the audience. Sorry we didn't get to get to all of them. But hopefully we'll be able to circle back on one of the future episodes episodes and cover some more. And of course, we will start texting some of the folks in here and see if we can give some manual responses as well. But I did want to thank, Bruce Perrons, and Stephen Tey for joining, this episode and talking about the past, present, and future of open source. Thank you everybody for for watching, and we'll we'll make sure that this is recorded so everybody can can catch up soon on, Directus TV. So that'll be super exciting. Thank you both for joining.",[189,190,191],"0501891e-d646-498e-bffe-91877013200a","79c00d61-59b0-416a-a5c6-b4676b1f76f5","4e4da556-c78e-4e05-8106-a8f9baf2adcb",[],{"id":133,"number":134,"show":122,"year":135,"episodes":194},[137,138,139],{"id":139,"slug":196,"vimeo_id":197,"description":198,"tile":199,"length":173,"resources":8,"people":8,"episode_number":200,"published":201,"title":202,"video_transcript_html":203,"video_transcript_text":204,"content":8,"seo":205,"status":130,"episode_people":206,"recommendations":210,"season":211},"how-agencies-innovate","964703470","A discussion on how agencies source and assess technology, including the process of technology sourcing, evaluating technology for clients and addressing client concerns.","d2ea6ed3-0c8e-4257-b763-45fde6f07a76",3,"2024-07-02","How Agencies Innovate","\u003Cp>Speaker 0: Today, we are doing another Bridging Bytes episode, in the midst of our of our Leap Week, Leap Week 3, over at Directus. So an exciting time for multiple reasons, but, super super jazzed to be here, joined by Steven Majid and or Megitt, sorry, and Nemanja, Nićiforović. We are gonna be running through how agencies innovate, something very, you know, important to me. This is how I kinda got started with Directus, got started in general. So, yeah, we'll be spending next hour or so running through all things agencies, sort of the the primer, the the history of Directus, and then diving into all the, so the nuance of, you know, the overlap between agencies and how you choose your software, how you, you know, build out these projects, oftentimes very, very different projects for different clients.\u003C/p>\n\u003Cp>So I think it would probably make sense. Why don't we dive in with some introductions? I can go first just kinda lay you know, set the stage for, again, you know, how I got started with Directus, with my agency, that I started about 20, 20 some odd years ago, called Ranger Studio out of New York City. We were headquartered in Brooklyn. It was, truly, you know, going back to 1 of our previous bridging bytes episodes, it was the intersection of design and development.\u003C/p>\n\u003Cp>So we were lucky enough to do builds for some of the amazing, you know, marketing and design studios out there, you know, IDEO, Wolf Allens, Pentagram, Interbrand, etcetera. And we would work to basically be the hands, to build out their their projects for amazing clients. You know, we worked with Google and Snapchat, AOL, AT and T, the US government, just doing really white glove amazing projects, you know, thus Directus because we needed to find software that would actually fit the bill for all of those. But ran that studio for about 15 years, until it sort of transitioned into into Directus, formally. But, yeah, it was it was a very interesting you know, we'll we'll get into it, I think, more in this episode, but it's very interesting sourcing, technology, especially back then 20 years ago when technology was very different.\u003C/p>\n\u003Cp>There was far less to choose from. There wasn't as much information about what you were choosing. But that's really how I how I got started with Directus was building software that would make, our internal development more efficient, give us administrative tools we could hand off to those end customers, that wasn't strictly, a head you know, a CMS. They didn't even have have headless back then, or was it something completely custom? That's really what we ended up doing constantly.\u003C/p>\n\u003Cp>It was just building custom, solutions and back ends for every project, which is inefficient. So today, we're gonna be diving into how people do it today, the modern way of approaching this problem. So why don't we start off, Steven Meggitt, who is over from, if you wanna give give an intro. Sounds good. Awesome.\u003C/p>\n\u003Cp>Speaker 1: Sounds good. Ben, that was AAA good intro and backstory for, the genesis of of Directus. It seems that, you're not the only agency that started out that way. 37 signals, I think, comes to mind of a similar trajectory. So it's it's interesting to hear that.\u003C/p>\n\u003Cp>Pleasure to be here, Ben, Manja. Great to connect with you as well. Thanks for Directus for for having me on having us on. So I've been at for, close to 5 years now. I've spent my career designing, developing, and delivering really, really unexpectedly clever customer experiences that generate return on investment.\u003C/p>\n\u003Cp>I started in 2, 001 in my parents' basement, and then built a small but highly focused digital agency. Ben, you talked about the intersection of design and development. I like to add in 1 more element to that, where my agency was highly, highly focused on research, user experience and design and development. And that eventually led to me growing the the agency pretty organically and built a small but highly focused agency on those elements. And that led to an acquisition by in 2019, to help build out, what was then a, city centric design studio capability, which then was was then grown into a national practice.\u003C/p>\n\u003Cp>So now I'm a partner in the customer transformation practice, which brings together the work that I do in the studio, along with everything that I'm passionate about, which is helping organizations really build sustainable value and growth by making every touchpoint in the customer journey an exceptional 1.\u003C/p>\n\u003Cp>Speaker 0: That is awesome. Yeah. And, you know, 37 signals, obviously, that's a great sort of template. You know, was taking very close looks at them back in the day and, you know, III are they still around?\u003C/p>\n\u003Cp>Speaker 1: Oh, yeah.\u003C/p>\n\u003Cp>Speaker 0: Yeah. I I get I get whiffs of, like, you know, the there are, different product suites every once in a while, but I can never can never quite tell. Some people are a little bit more ephemeral. But, thank you so much, Steven. That's that's a great great intro.\u003C/p>\n\u003Cp>Super happy to have you here. Nemanja, do you wanna, run through a quick intro from over at Workinco?\u003C/p>\n\u003Cp>Speaker 2: Yep. Hi, everyone. My name is Nemanja, and I'm a technology partner at, Workinco. I've been with WorkingCo since December 2013, joined as developer number 4, and, it's been quite a ride. I've been, meddling with almost any technology project that we've ever worked on.\u003C/p>\n\u003Cp>From Virgin America that, made Working Code what it is, over through NBA, Disney, Google, CBS, more recently Contentful and Decathlon. As far as, my trajectory goes, I started coding, straight out of high school, like 2, 002. And I was always fascinated by hands on work, clean architecture, design patterns, and I was fortunate to have great mentors before Workingco and during Workingco. So 1 of the things that made me stick around for for as long as I have is that Working Group partners, in particular, are very hands on, so I get to do what I love every single day still.\u003C/p>\n\u003Cp>Speaker 0: Little known. I don't even think we talked about this, Nemanja, but I actually when I was when I moved to the city and I was figuring out exactly where I was gonna be, you know, working next, I actually went over to Work and Co. I knew some of the partners over there at the time, and applied. I was like, I would love to work here. This is an amazing, amazing shop.\u003C/p>\n\u003Cp>Things went a different direction. I ended up starting my own, my own agency, but I certainly what that is what you described is exactly what resonated with me is all the partners were super hands on. There was no, you know, okay. All these, you know, lower level junior designers are gonna go out and do the grunt work, etcetera. Everybody was really active in, you know, building out, the project.\u003C/p>\n\u003Cp>And, again, not just amazing clients, but amazing projects for those clients. Excellent. So that's basically intros. I think again, just to reiterate, today, we're gonna be really going through, the agency side, how we how we sourced different technologies, which, of course, can be very disparate. You've got, depending on the agency, some are a little bit more.\u003C/p>\n\u003Cp>This is, you know, lather and repeat exactly what we do, you know, bread and butter. And then others are more divergent, in in the types of project they take on. And, of course, that means that the tech that you use to build those projects can be all over the place. And so sourcing, assessing, you know, and making recommended, recommendations to those clients can be can be very tricky. There's a lot to sort of cover there.\u003C/p>\n\u003Cp>Maybe we kick it off. Steve, I'd love to hear a little bit more about how, you know, you, your team, and and navigates, you know, the process of recommending that that tech, for your clients. You know, especially given your role, that dual role as an auditor, and also a consultant.\u003C/p>\n\u003Cp>Speaker 1: Yeah. It's a tough 1. Or sometimes it can be a tough 1, especially if we audit the clients. So, generally speaking, you know, the the audit side of the house and the consulting side of the house remain separated. It's sort of the the only way that that it can work.\u003C/p>\n\u003Cp>We end up if if they're intertwined, then we end up in a situation where we could be auditing our own work. And from a conflict of interest perspective, that doesn't really work. It it reduces our integrity, and it reduces our objectivity from as an auditor. So, I think we tend to be a little bit more on the risk averse side. And oftentimes, you don't actually recommend, technology to our client.\u003C/p>\n\u003Cp>We take a very empathetic approach and try to understand, what our clients' business objectives are, and we try to understand what their current state is from a technology posture is. So what are the legacy tools that they've got in place right now? What are their growth ambitions? What is gonna prevent them from achieve helping them achieve those growth ambitions? And then we sort of lay out a criteria for understanding, okay, who are the possibilities that might help them either leave their legacy architecture in place and and do a bolt on to newer technology, or we identify a path forward that, you know, involves slowly removing that legacy, technology.\u003C/p>\n\u003Cp>But we we talk through this with the client, and we under and we get them to understand what does the road map look like and then how we would chunk out that road map and reduce risk for them along the way, reduce spend, for them along the way, and just overall make sure that we are paying attention to their, you know, strategic objectives and their regulatory environment, as well as, you know, the industry that they're operating in. I think that is primarily the place that plays, is really just taking that empathetic approach, knowing that we operate in almost every single sector globally, and knowing really, really key, insight around regulatory environment, strategic objectives of an of an organization, as well as their technology posture and sort of taking that big lens and then identifying what the route forward is going to be.\u003C/p>\n\u003Cp>Speaker 0: Yeah. That makes it. I'm curious. You kinda you mentioned sort of digital transformation at the enterprise level. When you see that type of modernization, do you is it more often than not that people are looking to do it, you know, pretty swiftly, like rip the band aid off approach, or are they sort of 1 1 foot at a time?\u003C/p>\n\u003Cp>Like, let's do this incrementally. Let's look at phase 1 and sort of, like you said, maybe it's getting bolted on to the side. Maybe there's some technical debt. Maybe it's more expensive to do it, you know, incrementally. But what seems to be, sort of best practice, or what do you what do you see more of these days within that?\u003C/p>\n\u003Cp>Speaker 1: It's a really good question. I I think very rarely is it ripped the Band Aid off because when you're talking about digital transformation, I know it's a term that's probably often maligned at this point. It's just it's just transformation at this point. It's really hard to just cut over and make something new because the way that we look at everything, it's it's people, process, and technology. And if you're changing technology, there's a really good chance that you're changing process.\u003C/p>\n\u003Cp>And if you're changing process, it's gonna impact people. And so whenever you rip the band aid off or make that very, very quick change, you have to have a very, very robust change management work stream that's attached to a project. And, you know, being we're in a fortunate enough position that we've got technology consulting, business consulting, people advisory consulting. We bring this massive amount of expertise in large scale transformations that can sort of safeguard and risk mitigate the, the areas where it could get a little hairy. And more often than not, the technology isn't the hard part.\u003C/p>\n\u003Cp>It's the people part that makes it really, really difficult for adoption and for new process knowledge transfer and for change management. So, I guess, long winded way of saying, rip the Band Aid off to your detriment if you don't include a change management work stream.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Oh, absolutely. And, again, like, rip the Band Aid off isn't necessarily you know, it's just a 1 and done. It's it's still, like, how expeditious are you trying to be? It's probably it's always gonna be phased out Yeah.\u003C/p>\n\u003Cp>Or or done in phases, I should say. But, yeah, no. That that makes a lot of sense. I I like the sort of the people process in tech, more of a holistic view of, you know, how you approach these problems. Nemanja, I'm curious.\u003C/p>\n\u003Cp>So at Work and Co, you know, how do you how do you guys balance, like, the innovation and responsibility when you are selecting, you know, technology for for your clients?\u003C/p>\n\u003Cp>Speaker 2: Yeah. The eternal question. I wish I knew. But joking aside, innovation, as you know, is inevitable in our line of work. It's impossible to be in technology and not to innovate, or else to be named the dinosaur by everyone else in the industry very, very quickly.\u003C/p>\n\u003Cp>And, we are where we are because we innovate constantly. There are a couple of ways. I identified 3 as the main equally important ways of balancing responsibility, which is proper planning. And I cannot emphasize this enough. We pride ourselves in a really, really thorough planning and discovery phase before we even get to, any actual engineering work where you can, mitigate these risks and, create strategies, about how you're going to implement.\u003C/p>\n\u003Cp>Steven said a wonderful thing, which is changing technology. Technology is simple. That's why I like it. Technology is very straightforward, and it's an exact science. Everything that comes as a side effect, as a consequence.\u003C/p>\n\u003Cp>Adoption by people, some cost fallacy, pushback by the clients' teams, those are the real problems to solve. And these are most often at least tackled during the planning planning phase. So a very, very comprehensive planning phase, then validating as a second point, validating the ideas we get to, through the planning phase via prototyping. 1 of our 1 of our paradigms at Working Call is, prototypes, not presentations. And I can't stress how amazing that is.\u003C/p>\n\u003Cp>Playing around with a new technology and making something work, discovering ups and downs throughout the journey, There's no white paper that can that can beat an actual working prototype and that can give you a sense and a feel about the community, about the usage, about the tooling. So, definitely, prototyping is the second point. And then, last but not least, agility in its purest form and in its purest sense, the context is the ability to rapidly adapt and respond to changes. Many times, these innovations, like if you balance responsibility with innovation, it's inevitable that you'll miss the mark quite a few times. It's really important to be agile, and it's really important to then change course, to have, an open, direct, and candid conversation with all the stakeholders and to course correct to something that's better for the the the work, the client, and everyone involved.\u003C/p>\n\u003Cp>So being truly being truly agile and nimble when hurdles inevitably come is what helps balance out the constant call of innovation, especially now when the newer the newer lineage of developers just rush to every new innovation because there's this appeal, And, it's really enticing to use cool new tools. So\u003C/p>\n\u003Cp>Speaker 0: Yeah. I mean, as a as a developer myself, like, you know or in our entire team at Directus, it's like there's always this. It's like, oh, I just wanna try it out. You know? Especially because we're open source.\u003C/p>\n\u003Cp>People have this. You know, typically, open source is like nights and weekends, and it's like you can do whatever you want. And then when that becomes your day job, it's, you know, that balance is a little bit more interesting. You know, we're obviously very small, you know, had a full time head count of, like, 30 plus, but, Work and Co, a lot larger. And obviously, a lot even larger still.\u003C/p>\n\u003Cp>Nemanja, you mentioned sort of agile. I always used to kinda refer to that, as, like, a really important facet of of our agency, etcetera, but always, you know, mention the lowercase a so not to be confused with the methodology. I like nimble. Do you feel is do you feel like it's more important for for Work and Co, you as, as the agency? You find it more easier for you as an agency to be nimble, and and does that sort of align with your clients a lot, or are they a little bit, like, who where would you say the balance is there?\u003C/p>\n\u003Cp>Because I could imagine, you know, you you get your sort of things locked in, and you're ready to change at any moment, but maybe even after you've done run through some prototypes and you've gone through what things might look like, maybe they have more of a a set vision and they're not as nimble, once you get into the process? Or what what would you what are your thoughts on that?\u003C/p>\n\u003Cp>Speaker 2: Yeah. III think the the word I like even more than agile is candid. I think it's really, really important to get to the bottom of why. Like, 1 of our partners, 1 of our founding partners, Joe Stewart, said when we did Virgin America, the clients know their business a 1000 times than we a 1000 times better than we ever will. There's always a reason for pushback.\u003C/p>\n\u003Cp>And as I said, it could be sunken cost fallacy. It could be the teams not being ready to adopt new technology. It could be because the technology is so deeply ingrained in the process, in the staffing, in everything that Steven mentioned. It it it's just really hard to pull out, like, a LEGO block and then replace with a nicer 1. So when things like this happen, when the other side, the the clients aren't as nimble, I think it's our responsibility as their partner to figure out why, and then to try to build a relationship and a sense of joint ownership.\u003C/p>\n\u003Cp>So the decision we land at is the decision that's best for the product and that's best for the work. I feel like very rarely is there irrational pushback. 9 out of 10 times, it's very good reasoning that's hidden behind business decisions and, people decisions. It's it's not as simple as it looks. That's why I like technology.\u003C/p>\n\u003Cp>Technology is super simple. Like, this is the perfect database to store this type of data, and that's where it ends. With business, it's much much more complicated.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Much I mean, the tech is is purely objective and that that at least removes it not removes it from the equation, but makes it an easier part of the equation. But I would say, you know, we talk about all these different intersections. There's certainly an intersection of people and tech. You know, specifically, when you're building out a project, that technology will be used by people.\u003C/p>\n\u003Cp>And, again, something that I'm aware of, 1 of the big reasons we built Directus was, you know, unifying you. This great shift from, like, the monolithic ERP systems to microservices was was amazing, but it also means, you know, those people might now have a lot more complexity in their day to day of, you know, 10, 20 different portals they log into and different APIs they have to, you know, go into references for, etcetera. So it's I I guess that sort of leads into the next question, which I'm curious, for both of you, your respective agencies. You know, how when you're really just getting started, how you do that initial sourcing of of tech, you know, for the stack of a project or for a whole company depending on the scope. Like, what is the key criteria you look for?\u003C/p>\n\u003Cp>You know, through the lens of the tech is simple, you know, you know, in a way, but the people in the process are are a bigger part of the of the problem to be solved, but also very interrelated with the technology choices. And open for open for either of you.\u003C/p>\n\u003Cp>Speaker 1: Well, I think it I think it has to it has to start with business value. I I think that's the the most logical place to start. Inherently, I think you you have to go under the assumption that if if a client is engaging you, they're engaging you for a reason, that their business isn't where it wants to be. And they're either trying to streamline internal processes and backstage, goings on, or they're trying to enhance and improve the front stage experience for their customers. And so the only reason really to consider new technology or new engagement is going to be the, you know, the additive business value that the technology is going to bring.\u003C/p>\n\u003Cp>And so for us, I mean, Nemanja said it actually quite well in the in the previous in the previous question, where he's talking about, you know, there's there's always gonna be pushback, and there's always gonna be things that people are not telling you. And all of that is gonna come down to you, the client, or you, the vendor, working with the client, trying to establish trust in a relationship, and you can really only move at the speed of trust. And so the faster that you can develop that trust with the client, you're gonna get the whole story, and you're going to get the underlying reasons for considering a change. And that helps to understand how to move forward. You know, there's there's not a whole lot of rocket science here.\u003C/p>\n\u003Cp>We're talking about technology being simple. I think we often need to boil down business into more simplified terms where people just like doing business with people they like. And, usually, when you like someone, you're going to be open and trusting that they have your best interest at heart and that they're coming from a place of abundance that just wants to be helpful. And I think that's the benefit of working at is that I get to turn off, you know, this, agency owner cash flow mentality and turn on, well, how can I be the most helpful partner for this client? And I think that's really, you know, where it starts is truly understanding the the the place that they're in, the place that they wanna get to, and how new technology is going to unlock new value for them with the challenges that they're facing.\u003C/p>\n\u003Cp>Speaker 0: A 100%. Yeah. And, like, absolute the idea that people wanna spend time with, do business with, whatever the the relationship is, like, they you people wanna spend time with people that they respect, that they that they like. You know? That you're gonna be interacting with people on a daily basis.\u003C/p>\n\u003Cp>You're gonna be getting good news and bad news. You're gonna have to have the, you know, the agility, and and with that comes, you know, the trust that's very much resonates with me. I I found that that was, 1 of the best ways to ensure really solid communication was just establish that trust, at the onset of even before you've, you know, closed the job. You know, when you're in the RFP state and you're trying to make sure that that you're, you're getting awarded that bid is be the most likable client. Like, they just want to have another meeting with you.\u003C/p>\n\u003Cp>Like, even just starting there is is is a pretty great place to be.\u003C/p>\n\u003Cp>Speaker 1: It it's funny you it's funny you say that, because I'm probably gonna be giving away 1 of my, my own secrets here, but that's okay. I'm coming from a place of abundance and being helpful. But to your point, Ben, you'll always get like, every single agency pitch team, will get the question, you know, why should I choose you, in the presentation stage? And it's always someone who's, like, asking the question and then sitting back in their chair waiting for you to squirm. I have found that answering that question in a way that just sort of lays everything bare to that point and creates a foundation for trust is the reason why we've been successful in those stages.\u003C/p>\n\u003Cp>And, you know, my my template answer for that question, it it it's essentially look. Everyone you're gonna speak to is gonna have a great body of work and great case studies and a great portfolio. We do too. Everyone is gonna come to the table with a methodology and something that is going to help derisk the project. We do too.\u003C/p>\n\u003Cp>But what you're not going to get in everyone and what you are going to get in us is going to be a team that is advocating for your business outcomes and your audience, and we'll have arguments with you. And we will have passionate discourse about the best possible solution, but we're also gonna be able to come back to the table the next day and like each other and continue to work together and make your project a success.\u003C/p>\n\u003Cp>Speaker 0: Yeah. And that that is, like, the respect. It's like that radical transparency. We're not just gonna say what you wanna hear. You know, if you gotta hear the latest trend of technology, like, yeah.\u003C/p>\n\u003Cp>Oh, I know that you're gonna be jazzed by hearing this. So, like, it's really about having the trust, that the can and the candor to be able to say what's needed to be said to to get that project. Because, again, if it's not successful project for them, certainly won't be for you. You're not gonna have the client, you know, as a repeat business. Yeah.\u003C/p>\n\u003Cp>It won't be a great case study, etcetera. Nemani, I'm I'm curious your thoughts on that that same question, you know, how, how you over at Work and Co, you know, find find that initial tech and what you're really, assessing assessing it against.\u003C/p>\n\u003Cp>Speaker 2: Yeah. So, for us, the most important thing is to really truly understand our clients' long term value objectives. I think that's the fits really nicely into the narrative of business requirements often being a lot more complex than the tech ones. We make sure that we establish a vision for the experience that we're building for both the team and the end users, and then we work with the clients to determine the KPIs. After we are sure that we agree on what problems we're trying to solve, we can guarantee that we're not trying to use technology to dictate how we're gonna solve the problem, but it that it's the other way around, that we're gonna use technology as a tool.\u003C/p>\n\u003Cp>And then there are several critical criteria that we use to evaluate technologies. Number 1 is always efficiency and effectiveness in solving the problem. Not every technology is good at solving everything. We've learned about that with Clojure, for example, an amazing language who solve a lot of really complex data manipulations, not great at other stuff. And user base and community adoption equally important.\u003C/p>\n\u003Cp>Are there people that you can talk to when you hit a a wall? Is there a is there a lot of libraries? Is there an open source community? Are there people that are evangelists for the technology actively speaking and promoting their their their tech? And then availability of resources and documentation, of course.\u003C/p>\n\u003Cp>Once all of this finds a like, an average market that's good, we try it out. We either build the proof of concepts that I've mentioned, trying to solve specific parts of problems, or we use the tool to, work on an internal initiative we have. We do this a lot, where we have a bunch of internal internal tools, where we try technologies or stacks out that fit seem like they could fit the problem nicely, and that gives us firsthand experience in some of the newer stuff that we wouldn't feel comfortable trying out with clients immediately. It's an investment, but it's a well well worth investment.\u003C/p>\n\u003Cp>Speaker 0: Yeah. A 100%. It's interesting too. I think you kinda led by saying, you know, focusing on on the long term vision, the long term solution, etcetera. What how do you quantify that?\u003C/p>\n\u003Cp>Like, when I was, you know, working through similar projects, everyone has a different idea of long term. Some people, you know, sit on a digital experience that's built for a decade, then they come back like, hey. It's not working because things got deprecated. It's not even supported or whatever. Other people have a very rapid, you know, iterative cycle.\u003C/p>\n\u003Cp>But, also, there's, like, strata to what you're building. You know, to what what we build for clients, there's foundational levels that can, you know, have the longevity to to survive and sort of support multiple iterations of a project. And maybe the facade, you know, the front end or what have you, maybe that does change and this that's part of the stack gets swapped out more frequently. But, you know, on the whole, like, what when you're talking about, like, long term vision, I'm curious I'm curious what that means, to you in the in that dialogue with your clients.\u003C/p>\n\u003Cp>Speaker 2: In that sense, it means more whether the emphasis is going to be on like, long term vision for me particularly means scale and performance more than anything else. Like, how do we see the platform, grow over time? Do we see a huge surge in in the number of users, the number of visits? Do we see the data spiraling out of the the capabilities of the current platform? So we have a very honest conversation at the beginning about life cycle of technologies and stacks, about the the need to update libraries and platforms and the need to maintain as if you would maintain any other machine.\u003C/p>\n\u003Cp>The fact that it's software and that it's abstract does not remove the the reality of it being a machine. But the context there is more of a are we building a small tool for a discrete number of users? Do you see this growing? Do you see this expanding both in terms of people using it, the data living in it, and the number of features? Do you see your business expanding into other areas, out of which this part that we're building now will be a, foundational framework for or maybe a part of a larger system?\u003C/p>\n\u003Cp>All these things help a lot with decision making. Overoptimization is the root of all evil, said someone really smart. I can't remember who. But the point is you are not gonna build a an insane event bus orchestration layer with Kafka for an app that's gonna be used by 100, maybe 1, 000 of people. It's redundant and unnecessary and a huge waste of time.\u003C/p>\n\u003Cp>So aligning on on what the build is the build strives to be down the road, helps a lot with cost, helps a lot with effort, and with the the technology choices as well.\u003C/p>\n\u003Cp>Speaker 0: Yeah. No. A 100%. You said over optimization never I also think that optimizing too early. I mean, there's there's all sorts of gotchas, you know, in there.\u003C/p>\n\u003Cp>But now I'm I'm curious. Is there an example, you know, that that you can think of that you've, like, you know, pretty recently where you maybe had some issues that you had to overcome with with a client in these in this decision process?\u003C/p>\n\u003Cp>Speaker 2: Yeah. 1 of 1 of the examples that, comes to mind is working, with a client partnering to transform their legacy technical ecosystem, making sure that it can better serve the needs of their increasingly digitally focused user base. And then a critical decision point was choosing between building separate mobile apps using bespoke technologies like Swift and, Kotlin, or going through a cross platform mobile framework like Flutter that we really, really like or, React Native. And, the decision was complex. It involved a lot of a lot of moving parts.\u003C/p>\n\u003Cp>The existing team capability, their goals, their capacity, their performance, and that long term vision that we mentioned, which is how they see the the product moving forward. Also, security, a really, really important point. Yeah. So the way we approach it is we set the stage by really clearly defining the opportunities and challenges of all the approaches and making sure they understand the context and the impact each approach will take. We define proposed architectures based on the feedback that we got from them.\u003C/p>\n\u003Cp>Again, developed a lot of proof of concepts to show how different technologies on different devices behave when solving the same problem, and then went with a decision that I think all of us, the clients and us included, were very, very satisfied by and got a great outcome. And it was a it was not an easy process, I would.\u003C/p>\n\u003Cp>Speaker 0: It\u003C/p>\n\u003Cp>Speaker 2: was really, really tolling to get to a point of mutual satisfaction, but I think what got us there is a very close collaboration. And, again, I'm like a parrot now, but a lot of really honest candid conversations where you have to be really clear. Yes. This is 5% faster and better, but it is going to increase the development time 2 fold or 3 fold. Or maybe saying this is faster, but once you hit, 1, 000 or 2, 000 concurrent users, we are gonna start seeing problems.\u003C/p>\n\u003Cp>So having these conversations happen in real time and being ahead of the curve and making sure that all the angles are met greatly helps with\u003C/p>\n\u003Cp>Speaker 0: Yeah. Situation with this. And a lot of knowledge that you as an agency who has gone through this process at different scales, different customers iterated through, you know, okay. We built this, and now here's version 1.1 or 2.0 and the adjustments we had to make make. There's a lot of, you know, institutional knowledge there that you can give to, that client and make sure that you keep things on the rails that requires that trust.\u003C/p>\n\u003Cp>You know, they they have to understand that you have gone through this before, and you can, you know, hopefully learn just like in life. You can learn from those mistakes before you make them, you know, whenever possible. Steven, how about same thing for you. Like, have you have you had, a project recently where you were sourcing that tech and it just there was some sort of challenge or issue that you that you ran into that you had to try and figure a good way to work around?\u003C/p>\n\u003Cp>Speaker 1: I think there's always challenges and issues. Yeah.\u003C/p>\n\u003Cp>Speaker 0: A more notable 1. Yeah.\u003C/p>\n\u003Cp>Speaker 1: I yeah. I I think we have been doing or, about to conclude a project that is a, a commerce, transformation, retaining legacy ERP and then migrating, the entire experience off of 1 commerce platform to another. And, you know, someone told me once the the, really great analogy. The organization has been speaking French, for, like, years, for however long they've been using this commerce platform. And they know French, and it's second nature to them.\u003C/p>\n\u003Cp>And moving on to another another commerce platform, yeah, it does the same thing. It's still a commerce platform. It's gonna do cart. It's gonna do checkout, but it's in Spanish. And so now they have to think in French and then translate to Spanish.\u003C/p>\n\u003Cp>And sometimes the way that you've been speaking and the way that you've been working for so long, even though it's a very similar context, it's an entirely different language, and you have to learn an entirely different language. And so 1 of the things that often comes up in in these scenarios is a client essentially saying, you know, but I wanna do it this way. And there's a limitation of the technology because of the opinionated nature of that technology that's essentially saying, well, you can't do it this way. And so then we need to come together as, you know, vendor or service integrator and and client and have a conversation about what is really driving, you know, this request and what is really driving this requirement. And when you understand what it is, then you can identify maybe a way to work around that.\u003C/p>\n\u003Cp>And then what you what ends up happening is to to Nemanja's point, a real candid conversation around the value of that workaround. And so it's, you know, we found in 1 of the in what in this example that about 5% of their revenue needed to perform a function that they were requiring. It came from this, you know, servicing of a customer. And so do they really wanna spend, you know, AAAA pretty hefty amount relative to the overall project cost to incorporate something that's gonna take in 3 to 5% of their revenue when they could probably just live without it and then find ways of servicing the customer in a different way that they won't find an impact on. So I I think it's again coming to, you know, really ensuring that you've got future proof and scalable technology from several factors.\u003C/p>\n\u003Cp>You know, the technology's adaptability to the evolving industry standards or the regulate regulatory environment, its ability to integrate with other systems, and really the provider's commitment to continuous improvement and support. And we look at all of that and its potential to leverage emerging technology. I mean, we're all talking about AI these days, and, you know, Directus has also gotten into the, into the AI game as well. And then looking at those regular reviews and updates, the technology road map, all of that coupled with those candid conversations and trying to find POCs that are going to help create workarounds, but then evaluating the POCs based on return on investment, I think that's, like, the way that that we approach it, and that's the way that we go. And that's a relatively recent as of, like, 2 weeks ago example.\u003C/p>\n\u003Cp>Speaker 0: Yeah. It's a it's a big 1, and it's it can be hard to kinda make those decisions when you want to be improving. You wanna sort of modernize every ask you know, every corner of of your business, your process, etcetera. And sometimes, like, the ROI is not there. And, you know, when is the right time to kind of remove that technical debt, that legacy, part of the stack?\u003C/p>\n\u003Cp>You know, or, you know, do you ever you know, do you just kinda band aid it, add infinitum until, the ROI changes or it just no longer functions or, you know, there's there's a lot to that. It's interesting, though. I think you both have mentioned sort of this idea of, like, being opinionated or unopinionated. I'm curious, you know, Steven, you just mentioned making something future proof, which I I always I'll always kinda throw quotes around air quotes around that, and scalable, which I think is a big part of being future proof. You don't know how you're gonna scale necessarily.\u003C/p>\n\u003Cp>I mean, in an ideal world, you don't know because you could think things are gonna go amazing, they go even better. But how do you ensure that the the tools that you source are future, you know, future proof. And, you know, when you're thinking of things like, you know, the words like unopinionated or opinionated, I think both have, you know, pros and cons. You know, does that tie into this thinking, this, like, methodology for for choosing the Oh, yeah. The the tech?\u003C/p>\n\u003Cp>Speaker 1: Yeah. Yeah. I I think that everything that I just mentioned around, understanding the technology's ability to, incorporate emerging technology, its evolving nature with industry standards, as well as, you know, regulatory standards. All of that, like, it has to it it creates the the the foundation and the guardrails for businesses to be operating in. And selecting a technology that doesn't take into account those guardrails or those foundational aspects of the business operating environment, I think, is a surefire way to surefire way to choose the wrong technology.\u003C/p>\n\u003Cp>Speaker 0: Do do you feel that, like, again, just do you feel that something choosing tech that is opinionated and follows those specs, you know, that compliance and just, like, checks those boxes, you know, out of the box, so to speak, off the shelf versus maybe a tool that's more unopinionated, that allows you to take those those paths when needed or if those paths change, if there's a new spec that's introduced to you. You feel like there's a benefit to either of those options, or do they both kinda have their place, depending?\u003C/p>\n\u003Cp>Speaker 1: I think they both have their place. I I think it's gotta be fit for purpose. Like, commerce is a great example. You do want it to be opinionated to some degree. Like, you don't want to be messing around with the world's best commerce platform, and then find out that your conversion rate is suffering.\u003C/p>\n\u003Cp>So in some respects, like, if you want to maintain your legacy stack, but you want to change your commerce platform as part of your architecture, then getting the benefit out of that commerce platform, you're going to have to find a way to make your technology stack and architecture work with that platform, if you want to reap the benefits of that. So that's, you know, a very, very purposeful and intentional incorporation of opinionated technology. But then in areas where you don't really know what the end goal is and you have a good inkling as to how you can foundationally get off the ground very quickly with an unopinionated and flexible piece of technology, then that's a a really, really big benefit. So something like Directus is a really, really great place to start because most people can create a frame of reference around Directus as, like, a CMS. And so when you're, you know, doing any kind of project, most projects require a CMS.\u003C/p>\n\u003Cp>And so you can anchor onto that frame of reference, but then because Directus is so amorphous, it can literally be anything you want it to be or need it to be. And it's got a very friendly microservices architecture. There's really no sort of cookie cutter approach to what you're gonna use Directus for. So that's a a really you know, in my in my experience, that's a good example of leveraging opinionated architecture for what it's intended for and then leveraging something that's as unopinionated as can possibly be to help you grow to what's next.\u003C/p>\n\u003Cp>Speaker 0: Yeah. And then, ideally, both sides of the coin have strong points of integration so that they work well together. Exactly. Obviously, you wanna, you know, mitigate as much negative space as possible because that's where, you basically just have to start building custom to kinda fill in those gaps. So if you can have things bookend nicely together, and and play both sides of of that, that's sort of the ideal state.\u003C/p>\n\u003Cp>And, you know, side side note, you we we spoke a week or 2 ago, and you had mentioned you used that word amorphous to describe direct us, and I ran back to the team, and probably end up in all sorts of our our marketing collateral. It was just like a a really great way of describing it. Similar to sort of like nebulous, but nebulous has this kind of like more pejorative, like, what are we? What is this? And amorphous is is is just a great term.\u003C/p>\n\u003Cp>I love that. Nehemiah, you you had kinda mentioned a second ago, I think it was like prototypes, not presentations. When you are, you know, going out and and sort of pitching to clients, may could you talk a little bit more about that? Like, I'm I'm so curious about, like, that process. Like, what does that look like?\u003C/p>\n\u003Cp>You know, very aware of, like, what a prototype is, you know, versus a more traditional presentation. But how does that typically go with clients, and and how do they how do they receive that?\u003C/p>\n\u003Cp>Speaker 2: Very well. I think the first of course, that's never the first step. The first step is gathering requirements and hearing about the problem, aligning on what we need to solve and what needs to be tackled. As we're focused on products a lot, very often, it's a an exciting segment of, the the customer's business or a new feature or a new, new product within their ecosystem. Then we go back to the drawing board, and we build something that we we show the clients.\u003C/p>\n\u003Cp>And I think that leaves the best impression, by far, seeing something, work. And we have amazing, extremely talented designers that can, in a very, very, I would even say, absurdly short time frames produce amazing work. Once, once you see something that you only have in your head, in front of you on a screen, that helps immensely. I I have never seen I've never seen feedback after a a, like, a keynote presentation as I have after a couple of framer framer prototypes. Then the tech comes into play, and then we have a very, very thorough and deep, initial discussion where we try to understand the the tech team composition, the capabilities, the current infrastructure, architecture platforms, and everything that's there in order to better propose a solution.\u003C/p>\n\u003Cp>But, yes, the the prototype comes not as a first, but as a very close to first step, where it's the wow effect that, really brings it home. Because, we are visual beings by nature. And, that's why I feel like every developer, every engineer needs to I am let's put it like this. I'm com I used to be completely void of any sense of aesthetics. So math, math, math, then physics and electronics in in university.\u003C/p>\n\u003Cp>And then I worked through it because we are visual beings and to be in the line of work we are, which is digital, everything is very, very aesthetic, and people respond to, amazing inspiring interfaces. So, that's where I think prototypes are key. Again, seeing these ideas that we all talk about in presentations come to life is the same with features. There's a lot of talk about AI now and the capabilities of LLM and the conversational platforms. Seeing a happy path prototype often says a lot lot more than a bunch of keynote slides illustrating our general capability.\u003C/p>\n\u003Cp>Just seeing a happy pet alum consult you on which product to buy, I think it sends a really strong message about capability, preparedness, and the the the talent within the team.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Definitely, if you go into it with the mindset of getting that massive knowledge transfer, like truly understanding, you know, the problems, the root the root, you know, things that need to be solved, the goals, etcetera. And you understand the business, the team. Once you have all that, you know, over at work and co or or UI, like, I think then you can kind of jump into that. It's it's interesting, though.\u003C/p>\n\u003Cp>I agree. You know, humans are so visual. Like, the idea of, like, inspiring through, like, you know, pen to paper, so to speak, is huge. But at the same time, like, I started thinking because that that's how I operate. You know, I'm very quick to get in and start just divergently coming up with with UX, UI, like prototypes.\u003C/p>\n\u003Cp>And I feel like that conveys so much, so much more than a presentation if you have that, you know, the initial work ready, you know, informing that process. But, also, it makes me think of, like, books to movies. I watch a lot more movies than I do read books. I you know, just time wise. But there's this idea of, like, you read a book and we're also imaginative creatures.\u003C/p>\n\u003Cp>Does it ever backfire? Because when you kinda go in with a prototype, that's like the movie. Right? You're sort of saying, like, this is this is what this could look like versus a book, and it's like, oh, that's I read the book, and then it was so different in the movie. And I don't know how I feel about that.\u003C/p>\n\u003Cp>Once you've kind of gone that direction of a prototype, do you ever feel like you are locked in because they've seen it and it's like, oh, this this is what we want, and then it that agility, that flexibility becomes a little bit more difficult?\u003C/p>\n\u003Cp>Speaker 2: That's where the the experience of years of pitching like this comes in really, really handily. We build prototypes to solve specific problems, sometimes even specific parts of specific problems. So it's not such a, such a heavy buy in or such a huge commitment. The prototypes often are, vital and instrumental at solving this 1 key thing. And, 9 out of 10 times when we do show a prototype, we know that that's the direction that's ultimately the best for the product.\u003C/p>\n\u003Cp>So showing a prototype solving that 1 key thing isn't completely selling you into 1 solution. It's a learning experience, and, it's articulated by us being a lot more diverse and potent prototypes that were selling us into solutions. Now it's a a good balance of both. You explain, show capability, demonstrate previous. As Steven said, we all have really nice case studies to fall back where everyone's impressed at how we solved really complex problems for really great really great clients, but then for specific segments or of specific problems, I feel like that's the sweet spot sweet spot for prototypes.\u003C/p>\n\u003Cp>Not to committing, but great at showing capability and putting like, giving a visual aspect to the solution.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Oh, I mean, a 100%. Steven, I'm curious. So when we're talking about, like, we're we're presenting to the client, you know, sometimes thing things backfire. When when a client comes in, maybe they already have preconceptions.\u003C/p>\n\u003Cp>I guess this could apply to to either of you, but they have a preconception. This happened to me a lot. You know, I I used to joke, with with our team that it was, you know, 1 of the executives, like, they had a niece that, like, worked for a company. It's like, this is the bet. Like, I've heard so much about this and, like, that is the preferred stack or tech tech choice.\u003C/p>\n\u003Cp>You know, I think Carlo had a, who just posted in the in the audience questions had a similar, you know, how do you manage client expectations when the recommendation recommended technology has a steep learning curve? I I think there's, you know, all of these sort of questions around how do you get past, you know, when there's tech that might not be a good fit for the company or it is a good fit, but you're just not aligned. And and maybe trust isn't quite getting you there. You have to really dive in and and, you know, sort of or cover that somehow and and help bridge the gap of, like, yes. I understand that this is, you know, the the latest, you know, hype train tech, or I understand that you've heard a lot about this this other thing from a family member or whatever it might look like.\u003C/p>\n\u003Cp>But any thoughts on that, like, how you navigate that?\u003C/p>\n\u003Cp>Speaker 1: So many thoughts. I do like, I I just wanna go back to, Nemanja's comments about, prototyping. I I think prototyping has a huge, huge amount of value in the work that we do for clients. Ben, I'm I certainly don't wanna poo poo your analogy on, you know, books and movies, but I think the important thing there is that, people can either create their own context or the people that they are hiring as experts can help create a better context. And if you leave someone to read the book, then they're creating their own context.\u003C/p>\n\u003Cp>They're creating their own imagination. They're filling in the gaps for themselves. Whereas the movie is telling them, like, this is what it is, and there's no imagination here. There's nothing, you know, left untold. This is the story, and, you know, you should pay attention to to this story.\u003C/p>\n\u003Cp>David Kelly, from IDO has got a great quote about prototypes. If a picture is worth a 1, 000 words, a prototype is worth a 1, 000 meetings. And so, like, you know, IIII do love the idea of prototypes because it does create that on ramp to trust. If a client's got a problem that is, you know, in their mind, immutably solve unsolvable, then, you know, a prototype from a experienced and professional team coming in to, you know, help highlight how it could be solved with proof of concepts or prototypes that, like, that accelerates the engagement massively. It creates a huge amount of trust.\u003C/p>\n\u003Cp>It helps solve a problem. It creates business value, and it's 1 of those things that clients can easily get behind because, again, going back to people, like, doing business with people they like, the person who you're working with has to look good in front of someone. And if you're helping them look good in front of their boss, like, that just solidifies and galvanizes the relationship because you're solving a business problem that goes beyond them. So I'll say that on on prototypes.\u003C/p>\n\u003Cp>Speaker 0: Well, I just and IIII do agree because, again, we're hired as agencies to it's a full service agency, typically. You know, you are delivering a full suite of deliverables. And I think the the book and or, you know, the the the story itself is 1 piece of that, but it's our job as, you know, on the UX side, the UI side, the all these different pieces to be the cinematographer, to be the director, to to kinda give them the entire experience. Otherwise, you know, you're leaving it up to them. And maybe they're they're great and they have some great visions, but you're also probably gonna end up with a roomful of people\u003C/p>\n\u003Cp>Speaker 2: who are\u003C/p>\n\u003Cp>Speaker 0: all interpreting things quite differently. And And then you're gonna be navigating the people problem of, okay. Now we gotta try and wrangle everybody to the same page.\u003C/p>\n\u003Cp>Speaker 1: Yeah. So I I think the the way the way that that we try to solve that is really trying to be proactive, right from discovery. I there's 2 things that, I will do within my engagements every single time. The first is is, an exercise called the graphic game plan. And, it was initially invented by, Grove Consultants, And, I leveraged this sort of storytelling visual of, hey.\u003C/p>\n\u003Cp>We're all we're all in our in our car, on our road trip heading towards this destination. The destination is project completion. What is going to be the measure of success for project completion? And then we put everyone everyone, including our team, the client team, puts their measures of success right in the center of that target. Then around that, you've got primary and secondary objectives.\u003C/p>\n\u003Cp>What do we want this experience to be? How do we wanna feel when we're doing the work? All of these sorts of things, We get them up there on the target as well. Then in the car are gonna be all of the stages and tasks that we need to do in order to achieve our objectives and achieve our our measure of success. Below the car, there's these bumps.\u003C/p>\n\u003Cp>And those are gonna be the challenges that we're gonna be facing along the way. And then the wheels on the car are gonna be the success factors. If everyone gets into a room and starts talking about success factors, challenges, all of the things that we have to do, the resources available to us, the objectives that we're trying to hit, then everyone owns the scope collectively. There isn't 1 side that owns the scope. And when you both share the scope, that's when you avoid things that I lovingly call climbing Mount Death March, where it's the vendor that is figuring out the scope of the project because it was ill defined at the beginning while they're developing.\u003C/p>\n\u003Cp>And, like, that is just the worst place to be in. So that's the graphic game plan. And the second thing that I'll do is ensure that we have stakeholder interviews from everyone in the company that could say no even at the 11th hour on the project strategy and the project direction. Because the 1 thing that every project should try to avoid is the swoop and poop. And that's, you know, when you're at a beach having a great day, team's doing great job, and a seagull flies in, shits all over your picnic, and then flies away.\u003C/p>\n\u003Cp>Speaker 0: And then you're Good luck. There.\u003C/p>\n\u003Cp>Speaker 1: What's that?\u003C/p>\n\u003Cp>Speaker 0: I've heard that's good luck. That's a good thing to say. Trying to make you feel a little better about it.\u003C/p>\n\u003Cp>Speaker 1: Yeah. Only the only the people that, they get crapped on tell you that it's good luck. Yeah.\u003C/p>\n\u003Cp>Speaker 0: Only in the metaphor.\u003C/p>\n\u003Cp>Speaker 1: Yeah. So those are the 2 things that we'll do to make sure that we've got alignment, right from the beginning. And that is probably the most important thing. Because if you take a flight around the world, around the equator, and you're 1 degree off course, by the time you get around, you're gonna be 500 miles off target. And that's 1 degree of deviation.\u003C/p>\n\u003Cp>So better to get that, you know, that heading right on target right from the beginning.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Yeah. I mean, it becomes rocket science. I mean, you the the more off you are, the earlier you're off, that just kinda compounds and you you're scaling problems. So if you can mitigate that, that's definitely something to be very aware of, in that early process.\u003C/p>\n\u003Cp>Yeah. Nemanja, I'm curious. Do you have anything similar, like, where you you've kinda had to deal with this issue of people coming in with preconceptions or trying to wrangle, you know, someone away from this idea that really just wouldn't work, but they're they're just struggling to to see the vision and to have that trust.\u003C/p>\n\u003Cp>Speaker 2: Yeah. More oftentimes than I would like. But, I think that, you can't win them all. Sometimes just having a having done all of your homework, having done an extensive discovery phase, having validated your assumptions, done all the prototyping in the world, shown capability, discussed caveats, her hearing the client out and hearing their reasoning, seeing that there is no greater mystery behind why someone's as adamant as they are about a certain technology or not adopting a certain technology, the conclusion might, in the end, be that it's someone's need. And, that's okay.\u003C/p>\n\u003Cp>What we do in these situations is that we establish a very, very loud and very clear communication channel throughout the process from the first meeting where things are we're an agency, and we eventually perform a service for our clients. So if you've exhausted all of your options and if there is no other way to argue your point, you just have to be very, very clear and very direct and to communicate very frequently what the risks and consequences of a decision you believe are is suboptimal are. So making sure that this 1 degree deviation that everyone knows that it's gonna be 500 kilometers by the time we get back and alerting date, like, an alarm clock every hour. Like, saying in every retrospective meeting or every time there's an opportunity to discuss technical depth or to discuss progress, just making sure everyone understands the consequences of the choices that we believe were suboptimal. 100%.\u003C/p>\n\u003Cp>As I said, you can't win them all. There's no way that everyone's always gonna be aligned regardless of how good your argumentation is. But I think it's our responsibility as partners to make sure that we alert to these consequences as often and as early as possible.\u003C/p>\n\u003Cp>Speaker 0: Yeah. No. A 100%. And I think, again, when things go south, the best thing that can happen is to already have established trust. You know, they they understand why the communication is there, and at least then it's you know, you you can hopefully navigate, through the project or whatever that ends up looking like.\u003C/p>\n\u003Cp>But, yeah, I we've kind of mentioned that word so much. I it really, you know, going back to, I think, the beginning of this, Steven, you had said you can only move at the speed of trust, which I took a note of. I think that's I think that's an amazing, sort of, like, way to kinda think about this and highlights the importance of that trust and communication, and it connects it to something that's very real. Like, when you're building a project, you've you know, speed. Speed is important.\u003C/p>\n\u003Cp>You can't you when I was running my agency, there was kind of 4, sort of levers that you really had to work with, and they were all I I think there's even a website where you can turn certain ones on and off. It was speed, scope, cost, and quality. And, of course, any good agency is gonna take quality off the table and say that's always gotta be good. We're we're not gonna sacrifice that. So you have these 3 toggles that you can kinda, you know, choose to choose your own adventure.\u003C/p>\n\u003Cp>And it's great to know that trust is a huge part of of the speed of the process, because, really, in the beginning when you're figuring out the scope and you're, you know, setting up what the cost looks like, you just efficiency and speed is is the name of the game. You know, how can you get through and and help to establish that and help the client really understand what their options are, that you are the right vendor, or, you know, partner to help them get through this. And I guess it all just comes down to to to that trust. So, we we've said that word a lot, and that's I think that's we we could probably rename this episode into, you know, establishing trust and, you know, the importance of trust at the agency level. But, you know, we we we ran over time a little bit, which is which is always good.\u003C/p>\n\u003Cp>We didn't even get through through all of our questions here, or, you know, I think there was a few that were thrown into the chat. But, any final thoughts, Steven Steven or Nemanja?\u003C/p>\n\u003Cp>Speaker 1: Nemanja, why don't you go first?\u003C/p>\n\u003Cp>Speaker 2: Yeah. I was just gonna say because it piggybacks nicely off of what you've just said. It's not only trust, I would say, it's partnership. Like, 1 of the things that got me, when I was deciding whether I'll go into agencies and service work or whether I'll go into, like, building a product startup or something like that was agencies, at their core, help solve problems, and you can't help if you're in an adversarial position. I really every relationship that we've had with a client that was hugely successful and that brought a lot of, for lack of a better word, happiness to me after the resolution was when we were true partners.\u003C/p>\n\u003Cp>So it's not like we're warning you this will fail because you're not listening to us. It's like, how do we make sure that since these are the the axioms that we have to work against, we fail less as a team. Like, being a partner to our clients is, I think, a lost forgotten art. Sometimes we get into a mindset of us versus them. I don't think that's a good mindset for agencies or tech providers at all.\u003C/p>\n\u003Cp>We serve technologies is there to serve solve problems. And, like, at its core, what we do is we facilitate. We use amazing tools to change the world. So partnership and not pointing fingers. The name of the game for me.\u003C/p>\n\u003Cp>Speaker 0: That's hon. I that's exactly right. Open, trust, you know, those are all key things, but really the goal of those things is to, establish a partnership where you're you're in it together because, I mean, you truly are at the end of the day. Yep. Steven, thoughts on that or, just, you know, closing closing thoughts?\u003C/p>\n\u003Cp>Speaker 1: Yeah. I I mean, I, I feel like Nemanja and I drink the same Kool Aid. It's 1 of those things where, for me, there was a very, very defining moment earlier on in my agency life where I I really just took on this mantle of being a designer is the most important thing in the world, and I would tell my clients, you know, the overarching responsibility of a designer and and how we're, you know, empowered to create amazing tools. The bottom line is they really didn't give a shit, about my my little speech about, you know, design. And it really sort of came to a head when I started changing the language that I was using around the value of the work that we do and what we bring to the table.\u003C/p>\n\u003Cp>And it was speaking my client's language, being empathetic to what their needs were and how they were articulating their business problems. And it was all in the language of business. And so if you can get out of your own way and stop speaking the language of design or stop speaking the language of technology and speak the language of business and how the tools that you wield are going to help solve their problem in a way that makes sense to them, that's when you actually engender really good partnership and really good, foundation of trust. And so I think that was a a really key moment for me in my, in my sort of growth and learning, as a agency owner and now someone who's in the, you know, the big 4 consulting world.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Couldn't could have said it better. I I again, these are all just huge pillars in how you how you kind of establish and foster, those those relationships. And then again, the the benefit of that is then you end up working with these clients, over and over and over again, and they just become huge advocates, for not only the stack that you help them select, you know, which, you know, we're a great great in a great position to be chosen by such a great you know, by so many great companies, but also, you just get to, have that repeat business and long enduring, partnerships with with great companies. So excellent.\u003C/p>\n\u003Cp>Steve and Damania, this was has been an awesome chat. Again, probably, we'll have to, like, circle back and maybe think about another 1 because a lot more. Again, this is the, you know, the whole reason for me being here, was was how how to solve these problems within an agency and trying to find the right tooling. And it's not always direct us. It's not, you know, that's the name of the game is, you know, just finding finding the right tool for the right job, which is not easy, as we say in an hour and 8 minutes in.\u003C/p>\n\u003Cp>But thank you both so much for joining, and we'll be seeing you at the rest of Leap Week for everybody else who's who's watching now.\u003C/p>\n\u003Cp>Speaker 1: Thanks so much for having us.\u003C/p>\n\u003Cp>Speaker 0: Absolutely. Alright. Thanks, everybody.\u003C/p>","Today, we are doing another Bridging Bytes episode, in the midst of our of our Leap Week, Leap Week 3, over at Directus. So an exciting time for multiple reasons, but, super super jazzed to be here, joined by Steven Majid and or Meggitt, sorry, and Nemanja, Nichoforovich. We are gonna be running through how agencies innovate, something very, you know, important to me. This is how I kinda got started with Directus, got started in general. So, yeah, we'll be spending next hour or so running through all things agencies, sort of the the primer, the the history of Directus, and then diving into all the, so the nuance of, you know, the overlap between agencies and how you choose your software, how you, you know, build out these projects, oftentimes very, very different projects for different clients. So I think it would probably make sense. Why don't we dive in with some introductions? I can go first just kinda lay you know, set the stage for, again, you know, how I got started with Directus, with my agency, that I started about 20, 20 some odd years ago, called Ranger Studio out of New York City. We were headquartered in Brooklyn. It was, truly, you know, going back to 1 of our previous bridging bytes episodes, it was the intersection of design and development. So we were lucky enough to do builds for some of the amazing, you know, marketing and design studios out there, you know, IDEO, Wolf Allens, Pentagram, Interbrand, etcetera. And we would work to basically be the hands, to build out their their projects for amazing clients. You know, we worked with Google and Snapchat, AOL, AT and T, the US government, just doing really white glove amazing projects, you know, thus Directus because we needed to find software that would actually fit the bill for all of those. But ran that studio for about 15 years, until it sort of transitioned into into Directus, formally. But, yeah, it was it was a very interesting you know, we'll we'll get into it, I think, more in this episode, but it's very interesting sourcing, technology, especially back then 20 years ago when technology was very different. There was far less to choose from. There wasn't as much information about what you were choosing. But that's really how I how I got started with Directus was building software that would make, our internal development more efficient, give us administrative tools we could hand off to those end customers, that wasn't strictly, a head you know, a CMS. They didn't even have have headless back then, or was it something completely custom? That's really what we ended up doing constantly. It was just building custom, solutions and back ends for every project, which is inefficient. So today, we're gonna be diving into how people do it today, the modern way of approaching this problem. So why don't we start off, Steven Meggitt, who is over from, if you wanna give give an intro. Sounds good. Awesome. Sounds good. Ben, that was AAA good intro and backstory for, the genesis of of Directus. It seems that, you're not the only agency that started out that way. 37 signals, I think, comes to mind of a similar trajectory. So it's it's interesting to hear that. Pleasure to be here, Ben, Manja. Great to connect with you as well. Thanks for Directus for for having me on having us on. So I've been at for, close to 5 years now. I've spent my career designing, developing, and delivering really, really unexpectedly clever customer experiences that generate return on investment. I started in 2, 001 in my parents' basement, and then built a small but highly focused digital agency. Ben, you talked about the intersection of design and development. I like to add in 1 more element to that, where my agency was highly, highly focused on research, user experience and design and development. And that eventually led to me growing the the agency pretty organically and built a small but highly focused agency on those elements. And that led to an acquisition by in 2019, to help build out, what was then a, city centric design studio capability, which then was was then grown into a national practice. So now I'm a partner in the customer transformation practice, which brings together the work that I do in the studio, along with everything that I'm passionate about, which is helping organizations really build sustainable value and growth by making every touchpoint in the customer journey an exceptional 1. That is awesome. Yeah. And, you know, 37 signals, obviously, that's a great sort of template. You know, was taking very close looks at them back in the day and, you know, III are they still around? Oh, yeah. Yeah. I I get I get whiffs of, like, you know, the there are, different product suites every once in a while, but I can never can never quite tell. Some people are a little bit more ephemeral. But, thank you so much, Steven. That's that's a great great intro. Super happy to have you here. Nemanja, do you wanna, run through a quick intro from over at Workinco? Yep. Hi, everyone. My name is Nemanja, and I'm a technology partner at, Workinco. I've been with WorkingCo since December 2013, joined as developer number 4, and, it's been quite a ride. I've been, meddling with almost any technology project that we've ever worked on. From Virgin America that, made Working Code what it is, over through NBA, Disney, Google, CBS, more recently Contentful and Decathlon. As far as, my trajectory goes, I started coding, straight out of high school, like 2, 002. And I was always fascinated by hands on work, clean architecture, design patterns, and I was fortunate to have great mentors before Workingco and during Workingco. So 1 of the things that made me stick around for for as long as I have is that Working Group partners, in particular, are very hands on, so I get to do what I love every single day still. Little known. I don't even think we talked about this, Nemanja, but I actually when I was when I moved to the city and I was figuring out exactly where I was gonna be, you know, working next, I actually went over to Work and Co. I knew some of the partners over there at the time, and applied. I was like, I would love to work here. This is an amazing, amazing shop. Things went a different direction. I ended up starting my own, my own agency, but I certainly what that is what you described is exactly what resonated with me is all the partners were super hands on. There was no, you know, okay. All these, you know, lower level junior designers are gonna go out and do the grunt work, etcetera. Everybody was really active in, you know, building out, the project. And, again, not just amazing clients, but amazing projects for those clients. Excellent. So that's basically intros. I think again, just to reiterate, today, we're gonna be really going through, the agency side, how we how we sourced different technologies, which, of course, can be very disparate. You've got, depending on the agency, some are a little bit more. This is, you know, lather and repeat exactly what we do, you know, bread and butter. And then others are more divergent, in in the types of project they take on. And, of course, that means that the tech that you use to build those projects can be all over the place. And so sourcing, assessing, you know, and making recommended, recommendations to those clients can be can be very tricky. There's a lot to sort of cover there. Maybe we kick it off. Steve, I'd love to hear a little bit more about how, you know, you, your team, and and navigates, you know, the process of recommending that that tech, for your clients. You know, especially given your role, that dual role as an auditor, and also a consultant. Yeah. It's a tough 1. Or sometimes it can be a tough 1, especially if we audit the clients. So, generally speaking, you know, the the audit side of the house and the consulting side of the house remain separated. It's sort of the the only way that that it can work. We end up if if they're intertwined, then we end up in a situation where we could be auditing our own work. And from a conflict of interest perspective, that doesn't really work. It it reduces our integrity, and it reduces our objectivity from as an auditor. So, I think we tend to be a little bit more on the risk averse side. And oftentimes, you don't actually recommend, technology to our client. We take a very empathetic approach and try to understand, what our clients' business objectives are, and we try to understand what their current state is from a technology posture is. So what are the legacy tools that they've got in place right now? What are their growth ambitions? What is gonna prevent them from achieve helping them achieve those growth ambitions? And then we sort of lay out a criteria for understanding, okay, who are the possibilities that might help them either leave their legacy architecture in place and and do a bolt on to newer technology, or we identify a path forward that, you know, involves slowly removing that legacy, technology. But we we talk through this with the client, and we under and we get them to understand what does the road map look like and then how we would chunk out that road map and reduce risk for them along the way, reduce spend, for them along the way, and just overall make sure that we are paying attention to their, you know, strategic objectives and their regulatory environment, as well as, you know, the industry that they're operating in. I think that is primarily the place that plays, is really just taking that empathetic approach, knowing that we operate in almost every single sector globally, and knowing really, really key, insight around regulatory environment, strategic objectives of an of an organization, as well as their technology posture and sort of taking that big lens and then identifying what the route forward is going to be. Yeah. That makes it. I'm curious. You kinda you mentioned sort of digital transformation at the enterprise level. When you see that type of modernization, do you is it more often than not that people are looking to do it, you know, pretty swiftly, like rip the band aid off approach, or are they sort of 1 1 foot at a time? Like, let's do this incrementally. Let's look at phase 1 and sort of, like you said, maybe it's getting bolted on to the side. Maybe there's some technical debt. Maybe it's more expensive to do it, you know, incrementally. But what seems to be, sort of best practice, or what do you what do you see more of these days within that? It's a really good question. I I think very rarely is it ripped the Band Aid off because when you're talking about digital transformation, I know it's a term that's probably often maligned at this point. It's just it's just transformation at this point. It's really hard to just cut over and make something new because the way that we look at everything, it's it's people, process, and technology. And if you're changing technology, there's a really good chance that you're changing process. And if you're changing process, it's gonna impact people. And so whenever you rip the band aid off or make that very, very quick change, you have to have a very, very robust change management work stream that's attached to a project. And, you know, being we're in a fortunate enough position that we've got technology consulting, business consulting, people advisory consulting. We bring this massive amount of expertise in large scale transformations that can sort of safeguard and risk mitigate the, the areas where it could get a little hairy. And more often than not, the technology isn't the hard part. It's the people part that makes it really, really difficult for adoption and for new process knowledge transfer and for change management. So, I guess, long winded way of saying, rip the Band Aid off to your detriment if you don't include a change management work stream. Yeah. Oh, absolutely. And, again, like, rip the Band Aid off isn't necessarily you know, it's just a 1 and done. It's it's still, like, how expeditious are you trying to be? It's probably it's always gonna be phased out Yeah. Or or done in phases, I should say. But, yeah, no. That that makes a lot of sense. I I like the sort of the people process in tech, more of a holistic view of, you know, how you approach these problems. Nemanja, I'm curious. So at Work and Co, you know, how do you how do you guys balance, like, the innovation and responsibility when you are selecting, you know, technology for for your clients? Yeah. The eternal question. I wish I knew. But joking aside, innovation, as you know, is inevitable in our line of work. It's impossible to be in technology and not to innovate, or else to be named the dinosaur by everyone else in the industry very, very quickly. And, we are where we are because we innovate constantly. There are a couple of ways. I identified 3 as the main equally important ways of balancing responsibility, which is proper planning. And I cannot emphasize this enough. We pride ourselves in a really, really thorough planning and discovery phase before we even get to, any actual engineering work where you can, mitigate these risks and, create strategies, about how you're going to implement. Steven said a wonderful thing, which is changing technology. Technology is simple. That's why I like it. Technology is very straightforward, and it's an exact science. Everything that comes as a side effect, as a consequence. Adoption by people, some cost fallacy, pushback by the clients' teams, those are the real problems to solve. And these are most often at least tackled during the planning planning phase. So a very, very comprehensive planning phase, then validating as a second point, validating the ideas we get to, through the planning phase via prototyping. 1 of our 1 of our paradigms at Working Call is, prototypes, not presentations. And I can't stress how amazing that is. Playing around with a new technology and making something work, discovering ups and downs throughout the journey, There's no white paper that can that can beat an actual working prototype and that can give you a sense and a feel about the community, about the usage, about the tooling. So, definitely, prototyping is the second point. And then, last but not least, agility in its purest form and in its purest sense, the context is the ability to rapidly adapt and respond to changes. Many times, these innovations, like if you balance responsibility with innovation, it's inevitable that you'll miss the mark quite a few times. It's really important to be agile, and it's really important to then change course, to have, an open, direct, and candid conversation with all the stakeholders and to course correct to something that's better for the the the work, the client, and everyone involved. So being truly being truly agile and nimble when hurdles inevitably come is what helps balance out the constant call of innovation, especially now when the newer the newer lineage of developers just rush to every new innovation because there's this appeal, And, it's really enticing to use cool new tools. So Yeah. I mean, as a as a developer myself, like, you know or in our entire team at Directus, it's like there's always this. It's like, oh, I just wanna try it out. You know? Especially because we're open source. People have this. You know, typically, open source is like nights and weekends, and it's like you can do whatever you want. And then when that becomes your day job, it's, you know, that balance is a little bit more interesting. You know, we're obviously very small, you know, had a full time head count of, like, 30 plus, but, Work and Co, a lot larger. And obviously, a lot even larger still. Nemanja, you mentioned sort of agile. I always used to kinda refer to that, as, like, a really important facet of of our agency, etcetera, but always, you know, mention the lowercase a so not to be confused with the methodology. I like nimble. Do you feel is do you feel like it's more important for for Work and Co, you as, as the agency? You find it more easier for you as an agency to be nimble, and and does that sort of align with your clients a lot, or are they a little bit, like, who where would you say the balance is there? Because I could imagine, you know, you you get your sort of things locked in, and you're ready to change at any moment, but maybe even after you've done run through some prototypes and you've gone through what things might look like, maybe they have more of a a set vision and they're not as nimble, once you get into the process? Or what what would you what are your thoughts on that? Yeah. III think the the word I like even more than agile is candid. I think it's really, really important to get to the bottom of why. Like, 1 of our partners, 1 of our founding partners, Joe Stewart, said when we did Virgin America, the clients know their business a 1000 times than we a 1000 times better than we ever will. There's always a reason for pushback. And as I said, it could be sunken cost fallacy. It could be the teams not being ready to adopt new technology. It could be because the technology is so deeply ingrained in the process, in the staffing, in everything that Steven mentioned. It it it's just really hard to pull out, like, a LEGO block and then replace with a nicer 1. So when things like this happen, when the other side, the the clients aren't as nimble, I think it's our responsibility as their partner to figure out why, and then to try to build a relationship and a sense of joint ownership. So the decision we land at is the decision that's best for the product and that's best for the work. I feel like very rarely is there irrational pushback. 9 out of 10 times, it's very good reasoning that's hidden behind business decisions and, people decisions. It's it's not as simple as it looks. That's why I like technology. Technology is super simple. Like, this is the perfect database to store this type of data, and that's where it ends. With business, it's much much more complicated. Yeah. Much I mean, the tech is is purely objective and that that at least removes it not removes it from the equation, but makes it an easier part of the equation. But I would say, you know, we talk about all these different intersections. There's certainly an intersection of people and tech. You know, specifically, when you're building out a project, that technology will be used by people. And, again, something that I'm aware of, 1 of the big reasons we built Directus was, you know, unifying you. This great shift from, like, the monolithic ERP systems to microservices was was amazing, but it also means, you know, those people might now have a lot more complexity in their day to day of, you know, 10, 20 different portals they log into and different APIs they have to, you know, go into references for, etcetera. So it's I I guess that sort of leads into the next question, which I'm curious, for both of you, your respective agencies. You know, how when you're really just getting started, how you do that initial sourcing of of tech, you know, for the stack of a project or for a whole company depending on the scope. Like, what is the key criteria you look for? You know, through the lens of the tech is simple, you know, you know, in a way, but the people in the process are are a bigger part of the of the problem to be solved, but also very interrelated with the technology choices. And open for open for either of you. Well, I think it I think it has to it has to start with business value. I I think that's the the most logical place to start. Inherently, I think you you have to go under the assumption that if if a client is engaging you, they're engaging you for a reason, that their business isn't where it wants to be. And they're either trying to streamline internal processes and backstage, goings on, or they're trying to enhance and improve the front stage experience for their customers. And so the only reason really to consider new technology or new engagement is going to be the, you know, the additive business value that the technology is going to bring. And so for us, I mean, Nemanja said it actually quite well in the in the previous in the previous question, where he's talking about, you know, there's there's always gonna be pushback, and there's always gonna be things that people are not telling you. And all of that is gonna come down to you, the client, or you, the vendor, working with the client, trying to establish trust in a relationship, and you can really only move at the speed of trust. And so the faster that you can develop that trust with the client, you're gonna get the whole story, and you're going to get the underlying reasons for considering a change. And that helps to understand how to move forward. You know, there's there's not a whole lot of rocket science here. We're talking about technology being simple. I think we often need to boil down business into more simplified terms where people just like doing business with people they like. And, usually, when you like someone, you're going to be open and trusting that they have your best interest at heart and that they're coming from a place of abundance that just wants to be helpful. And I think that's the benefit of working at is that I get to turn off, you know, this, agency owner cash flow mentality and turn on, well, how can I be the most helpful partner for this client? And I think that's really, you know, where it starts is truly understanding the the the place that they're in, the place that they wanna get to, and how new technology is going to unlock new value for them with the challenges that they're facing. A 100%. Yeah. And, like, absolute the idea that people wanna spend time with, do business with, whatever the the relationship is, like, they you people wanna spend time with people that they respect, that they that they like. You know? That you're gonna be interacting with people on a daily basis. You're gonna be getting good news and bad news. You're gonna have to have the, you know, the agility, and and with that comes, you know, the trust that's very much resonates with me. I I found that that was, 1 of the best ways to ensure really solid communication was just establish that trust, at the onset of even before you've, you know, closed the job. You know, when you're in the RFP state and you're trying to make sure that that you're, you're getting awarded that bid is be the most likable client. Like, they just want to have another meeting with you. Like, even just starting there is is is a pretty great place to be. It it's funny you it's funny you say that, because I'm probably gonna be giving away 1 of my, my own secrets here, but that's okay. I'm coming from a place of abundance and being helpful. But to your point, Ben, you'll always get like, every single agency pitch team, will get the question, you know, why should I choose you, in the presentation stage? And it's always someone who's, like, asking the question and then sitting back in their chair waiting for you to squirm. I have found that answering that question in a way that just sort of lays everything bare to that point and creates a foundation for trust is the reason why we've been successful in those stages. And, you know, my my template answer for that question, it it it's essentially look. Everyone you're gonna speak to is gonna have a great body of work and great case studies and a great portfolio. We do too. Everyone is gonna come to the table with a methodology and something that is going to help derisk the project. We do too. But what you're not going to get in everyone and what you are going to get in us is going to be a team that is advocating for your business outcomes and your audience, and we'll have arguments with you. And we will have passionate discourse about the best possible solution, but we're also gonna be able to come back to the table the next day and like each other and continue to work together and make your project a success. Yeah. And that that is, like, the respect. It's like that radical transparency. We're not just gonna say what you wanna hear. You know, if you gotta hear the latest trend of technology, like, yeah. Oh, I know that you're gonna be jazzed by hearing this. So, like, it's really about having the trust, that the can and the candor to be able to say what's needed to be said to to get that project. Because, again, if it's not successful project for them, certainly won't be for you. You're not gonna have the client, you know, as a repeat business. Yeah. It won't be a great case study, etcetera. Nemani, I'm I'm curious your thoughts on that that same question, you know, how, how you over at Work and Co, you know, find find that initial tech and what you're really, assessing assessing it against. Yeah. So, for us, the most important thing is to really truly understand our clients' long term value objectives. I think that's the fits really nicely into the narrative of business requirements often being a lot more complex than the tech ones. We make sure that we establish a vision for the experience that we're building for both the team and the end users, and then we work with the clients to determine the KPIs. After we are sure that we agree on what problems we're trying to solve, we can guarantee that we're not trying to use technology to dictate how we're gonna solve the problem, but it that it's the other way around, that we're gonna use technology as a tool. And then there are several critical criteria that we use to evaluate technologies. Number 1 is always efficiency and effectiveness in solving the problem. Not every technology is good at solving everything. We've learned about that with Clojure, for example, an amazing language who solve a lot of really complex data manipulations, not great at other stuff. And user base and community adoption equally important. Are there people that you can talk to when you hit a a wall? Is there a is there a lot of libraries? Is there an open source community? Are there people that are evangelists for the technology actively speaking and promoting their their their tech? And then availability of resources and documentation, of course. Once all of this finds a like, an average market that's good, we try it out. We either build the proof of concepts that I've mentioned, trying to solve specific parts of problems, or we use the tool to, work on an internal initiative we have. We do this a lot, where we have a bunch of internal internal tools, where we try technologies or stacks out that fit seem like they could fit the problem nicely, and that gives us firsthand experience in some of the newer stuff that we wouldn't feel comfortable trying out with clients immediately. It's an investment, but it's a well well worth investment. Yeah. A 100%. It's interesting too. I think you kinda led by saying, you know, focusing on on the long term vision, the long term solution, etcetera. What how do you quantify that? Like, when I was, you know, working through similar projects, everyone has a different idea of long term. Some people, you know, sit on a digital experience that's built for a decade, then they come back like, hey. It's not working because things got deprecated. It's not even supported or whatever. Other people have a very rapid, you know, iterative cycle. But, also, there's, like, strata to what you're building. You know, to what what we build for clients, there's foundational levels that can, you know, have the longevity to to survive and sort of support multiple iterations of a project. And maybe the facade, you know, the front end or what have you, maybe that does change and this that's part of the stack gets swapped out more frequently. But, you know, on the whole, like, what when you're talking about, like, long term vision, I'm curious I'm curious what that means, to you in the in that dialogue with your clients. In that sense, it means more whether the emphasis is going to be on like, long term vision for me particularly means scale and performance more than anything else. Like, how do we see the platform, grow over time? Do we see a huge surge in in the number of users, the number of visits? Do we see the data spiraling out of the the capabilities of the current platform? So we have a very honest conversation at the beginning about life cycle of technologies and stacks, about the the need to update libraries and platforms and the need to maintain as if you would maintain any other machine. The fact that it's software and that it's abstract does not remove the the reality of it being a machine. But the context there is more of a are we building a small tool for a discrete number of users? Do you see this growing? Do you see this expanding both in terms of people using it, the data living in it, and the number of features? Do you see your business expanding into other areas, out of which this part that we're building now will be a, foundational framework for or maybe a part of a larger system? All these things help a lot with decision making. Overoptimization is the root of all evil, said someone really smart. I can't remember who. But the point is you are not gonna build a an insane event bus orchestration layer with Kafka for an app that's gonna be used by 100, maybe 1, 000 of people. It's redundant and unnecessary and a huge waste of time. So aligning on on what the build is the build strives to be down the road, helps a lot with cost, helps a lot with effort, and with the the technology choices as well. Yeah. No. A 100%. You said over optimization never I also think that optimizing too early. I mean, there's there's all sorts of gotchas, you know, in there. But now I'm I'm curious. Is there an example, you know, that that you can think of that you've, like, you know, pretty recently where you maybe had some issues that you had to overcome with with a client in these in this decision process? Yeah. 1 of 1 of the examples that, comes to mind is working, with a client partnering to transform their legacy technical ecosystem, making sure that it can better serve the needs of their increasingly digitally focused user base. And then a critical decision point was choosing between building separate mobile apps using bespoke technologies like Swift and, Kotlin, or going through a cross platform mobile framework like Flutter that we really, really like or, React Native. And, the decision was complex. It involved a lot of a lot of moving parts. The existing team capability, their goals, their capacity, their performance, and that long term vision that we mentioned, which is how they see the the product moving forward. Also, security, a really, really important point. Yeah. So the way we approach it is we set the stage by really clearly defining the opportunities and challenges of all the approaches and making sure they understand the context and the impact each approach will take. We define proposed architectures based on the feedback that we got from them. Again, developed a lot of proof of concepts to show how different technologies on different devices behave when solving the same problem, and then went with a decision that I think all of us, the clients and us included, were very, very satisfied by and got a great outcome. And it was a it was not an easy process, I would. It was really, really tolling to get to a point of mutual satisfaction, but I think what got us there is a very close collaboration. And, again, I'm like a parrot now, but a lot of really honest candid conversations where you have to be really clear. Yes. This is 5% faster and better, but it is going to increase the development time 2 fold or 3 fold. Or maybe saying this is faster, but once you hit, 1, 000 or 2, 000 concurrent users, we are gonna start seeing problems. So having these conversations happen in real time and being ahead of the curve and making sure that all the angles are met greatly helps with Yeah. Situation with this. And a lot of knowledge that you as an agency who has gone through this process at different scales, different customers iterated through, you know, okay. We built this, and now here's version 1.1 or 2.0 and the adjustments we had to make make. There's a lot of, you know, institutional knowledge there that you can give to, that client and make sure that you keep things on the rails that requires that trust. You know, they they have to understand that you have gone through this before, and you can, you know, hopefully learn just like in life. You can learn from those mistakes before you make them, you know, whenever possible. Steven, how about same thing for you. Like, have you have you had, a project recently where you were sourcing that tech and it just there was some sort of challenge or issue that you that you ran into that you had to try and figure a good way to work around? I think there's always challenges and issues. Yeah. A more notable 1. Yeah. I yeah. I I think we have been doing or, about to conclude a project that is a, a commerce, transformation, retaining legacy ERP and then migrating, the entire experience off of 1 commerce platform to another. And, you know, someone told me once the the, really great analogy. The organization has been speaking French, for, like, years, for however long they've been using this commerce platform. And they know French, and it's second nature to them. And moving on to another another commerce platform, yeah, it does the same thing. It's still a commerce platform. It's gonna do cart. It's gonna do checkout, but it's in Spanish. And so now they have to think in French and then translate to Spanish. And sometimes the way that you've been speaking and the way that you've been working for so long, even though it's a very similar context, it's an entirely different language, and you have to learn an entirely different language. And so 1 of the things that often comes up in in these scenarios is a client essentially saying, you know, but I wanna do it this way. And there's a limitation of the technology because of the opinionated nature of that technology that's essentially saying, well, you can't do it this way. And so then we need to come together as, you know, vendor or service integrator and and client and have a conversation about what is really driving, you know, this request and what is really driving this requirement. And when you understand what it is, then you can identify maybe a way to work around that. And then what you what ends up happening is to to Nemanja's point, a real candid conversation around the value of that workaround. And so it's, you know, we found in 1 of the in what in this example that about 5% of their revenue needed to perform a function that they were requiring. It came from this, you know, servicing of a customer. And so do they really wanna spend, you know, AAAA pretty hefty amount relative to the overall project cost to incorporate something that's gonna take in 3 to 5% of their revenue when they could probably just live without it and then find ways of servicing the customer in a different way that they won't find an impact on. So I I think it's again coming to, you know, really ensuring that you've got future proof and scalable technology from several factors. You know, the technology's adaptability to the evolving industry standards or the regulate regulatory environment, its ability to integrate with other systems, and really the provider's commitment to continuous improvement and support. And we look at all of that and its potential to leverage emerging technology. I mean, we're all talking about AI these days, and, you know, Directus has also gotten into the, into the AI game as well. And then looking at those regular reviews and updates, the technology road map, all of that coupled with those candid conversations and trying to find POCs that are going to help create workarounds, but then evaluating the POCs based on return on investment, I think that's, like, the way that that we approach it, and that's the way that we go. And that's a relatively recent as of, like, 2 weeks ago example. Yeah. It's a it's a big 1, and it's it can be hard to kinda make those decisions when you want to be improving. You wanna sort of modernize every ask you know, every corner of of your business, your process, etcetera. And sometimes, like, the ROI is not there. And, you know, when is the right time to kind of remove that technical debt, that legacy, part of the stack? You know, or, you know, do you ever you know, do you just kinda band aid it, add infinitum until, the ROI changes or it just no longer functions or, you know, there's there's a lot to that. It's interesting, though. I think you both have mentioned sort of this idea of, like, being opinionated or unopinionated. I'm curious, you know, Steven, you just mentioned making something future proof, which I I always I'll always kinda throw quotes around air quotes around that, and scalable, which I think is a big part of being future proof. You don't know how you're gonna scale necessarily. I mean, in an ideal world, you don't know because you could think things are gonna go amazing, they go even better. But how do you ensure that the the tools that you source are future, you know, future proof. And, you know, when you're thinking of things like, you know, the words like unopinionated or opinionated, I think both have, you know, pros and cons. You know, does that tie into this thinking, this, like, methodology for for choosing the Oh, yeah. The the tech? Yeah. Yeah. I I think that everything that I just mentioned around, understanding the technology's ability to, incorporate emerging technology, its evolving nature with industry standards, as well as, you know, regulatory standards. All of that, like, it has to it it creates the the the foundation and the guardrails for businesses to be operating in. And selecting a technology that doesn't take into account those guardrails or those foundational aspects of the business operating environment, I think, is a surefire way to surefire way to choose the wrong technology. Do do you feel that, like, again, just do you feel that something choosing tech that is opinionated and follows those specs, you know, that compliance and just, like, checks those boxes, you know, out of the box, so to speak, off the shelf versus maybe a tool that's more unopinionated, that allows you to take those those paths when needed or if those paths change, if there's a new spec that's introduced to you. You feel like there's a benefit to either of those options, or do they both kinda have their place, depending? I think they both have their place. I I think it's gotta be fit for purpose. Like, commerce is a great example. You do want it to be opinionated to some degree. Like, you don't want to be messing around with the world's best commerce platform, and then find out that your conversion rate is suffering. So in some respects, like, if you want to maintain your legacy stack, but you want to change your commerce platform as part of your architecture, then getting the benefit out of that commerce platform, you're going to have to find a way to make your technology stack and architecture work with that platform, if you want to reap the benefits of that. So that's, you know, a very, very purposeful and intentional incorporation of opinionated technology. But then in areas where you don't really know what the end goal is and you have a good inkling as to how you can foundationally get off the ground very quickly with an unopinionated and flexible piece of technology, then that's a a really, really big benefit. So something like Directus is a really, really great place to start because most people can create a frame of reference around Directus as, like, a CMS. And so when you're, you know, doing any kind of project, most projects require a CMS. And so you can anchor onto that frame of reference, but then because Directus is so amorphous, it can literally be anything you want it to be or need it to be. And it's got a very friendly microservices architecture. There's really no sort of cookie cutter approach to what you're gonna use Directus for. So that's a a really you know, in my in my experience, that's a good example of leveraging opinionated architecture for what it's intended for and then leveraging something that's as unopinionated as can possibly be to help you grow to what's next. Yeah. And then, ideally, both sides of the coin have strong points of integration so that they work well together. Exactly. Obviously, you wanna, you know, mitigate as much negative space as possible because that's where, you basically just have to start building custom to kinda fill in those gaps. So if you can have things bookend nicely together, and and play both sides of of that, that's sort of the ideal state. And, you know, side side note, you we we spoke a week or 2 ago, and you had mentioned you used that word amorphous to describe direct us, and I ran back to the team, and probably end up in all sorts of our our marketing collateral. It was just like a a really great way of describing it. Similar to sort of like nebulous, but nebulous has this kind of like more pejorative, like, what are we? What is this? And amorphous is is is just a great term. I love that. Nehemiah, you you had kinda mentioned a second ago, I think it was like prototypes, not presentations. When you are, you know, going out and and sort of pitching to clients, may could you talk a little bit more about that? Like, I'm I'm so curious about, like, that process. Like, what does that look like? You know, very aware of, like, what a prototype is, you know, versus a more traditional presentation. But how does that typically go with clients, and and how do they how do they receive that? Very well. I think the first of course, that's never the first step. The first step is gathering requirements and hearing about the problem, aligning on what we need to solve and what needs to be tackled. As we're focused on products a lot, very often, it's a an exciting segment of, the the customer's business or a new feature or a new, new product within their ecosystem. Then we go back to the drawing board, and we build something that we we show the clients. And I think that leaves the best impression, by far, seeing something, work. And we have amazing, extremely talented designers that can, in a very, very, I would even say, absurdly short time frames produce amazing work. Once, once you see something that you only have in your head, in front of you on a screen, that helps immensely. I I have never seen I've never seen feedback after a a, like, a keynote presentation as I have after a couple of framer framer prototypes. Then the tech comes into play, and then we have a very, very thorough and deep, initial discussion where we try to understand the the tech team composition, the capabilities, the current infrastructure, architecture platforms, and everything that's there in order to better propose a solution. But, yes, the the prototype comes not as a first, but as a very close to first step, where it's the wow effect that, really brings it home. Because, we are visual beings by nature. And, that's why I feel like every developer, every engineer needs to I am let's put it like this. I'm com I used to be completely void of any sense of aesthetics. So math, math, math, then physics and electronics in in university. And then I worked through it because we are visual beings and to be in the line of work we are, which is digital, everything is very, very aesthetic, and people respond to, amazing inspiring interfaces. So, that's where I think prototypes are key. Again, seeing these ideas that we all talk about in presentations come to life is the same with features. There's a lot of talk about AI now and the capabilities of LLM and the conversational platforms. Seeing a happy path prototype often says a lot lot more than a bunch of keynote slides illustrating our general capability. Just seeing a happy pet alum consult you on which product to buy, I think it sends a really strong message about capability, preparedness, and the the the talent within the team. Yeah. Definitely, if you go into it with the mindset of getting that massive knowledge transfer, like truly understanding, you know, the problems, the root the root, you know, things that need to be solved, the goals, etcetera. And you understand the business, the team. Once you have all that, you know, over at work and co or or UI, like, I think then you can kind of jump into that. It's it's interesting, though. I agree. You know, humans are so visual. Like, the idea of, like, inspiring through, like, you know, pen to paper, so to speak, is huge. But at the same time, like, I started thinking because that that's how I operate. You know, I'm very quick to get in and start just divergently coming up with with UX, UI, like prototypes. And I feel like that conveys so much, so much more than a presentation if you have that, you know, the initial work ready, you know, informing that process. But, also, it makes me think of, like, books to movies. I watch a lot more movies than I do read books. I you know, just time wise. But there's this idea of, like, you read a book and we're also imaginative creatures. Does it ever backfire? Because when you kinda go in with a prototype, that's like the movie. Right? You're sort of saying, like, this is this is what this could look like versus a book, and it's like, oh, that's I read the book, and then it was so different in the movie. And I don't know how I feel about that. Once you've kind of gone that direction of a prototype, do you ever feel like you are locked in because they've seen it and it's like, oh, this this is what we want, and then it that agility, that flexibility becomes a little bit more difficult? That's where the the experience of years of pitching like this comes in really, really handily. We build prototypes to solve specific problems, sometimes even specific parts of specific problems. So it's not such a, such a heavy buy in or such a huge commitment. The prototypes often are, vital and instrumental at solving this 1 key thing. And, 9 out of 10 times when we do show a prototype, we know that that's the direction that's ultimately the best for the product. So showing a prototype solving that 1 key thing isn't completely selling you into 1 solution. It's a learning experience, and, it's articulated by us being a lot more diverse and potent prototypes that were selling us into solutions. Now it's a a good balance of both. You explain, show capability, demonstrate previous. As Steven said, we all have really nice case studies to fall back where everyone's impressed at how we solved really complex problems for really great really great clients, but then for specific segments or of specific problems, I feel like that's the sweet spot sweet spot for prototypes. Not to committing, but great at showing capability and putting like, giving a visual aspect to the solution. Yeah. Oh, I mean, a 100%. Steven, I'm curious. So when we're talking about, like, we're we're presenting to the client, you know, sometimes thing things backfire. When when a client comes in, maybe they already have preconceptions. I guess this could apply to to either of you, but they have a preconception. This happened to me a lot. You know, I I used to joke, with with our team that it was, you know, 1 of the executives, like, they had a niece that, like, worked for a company. It's like, this is the bet. Like, I've heard so much about this and, like, that is the preferred stack or tech tech choice. You know, I think Carlo had a, who just posted in the in the audience questions had a similar, you know, how do you manage client expectations when the recommendation recommended technology has a steep learning curve? I I think there's, you know, all of these sort of questions around how do you get past, you know, when there's tech that might not be a good fit for the company or it is a good fit, but you're just not aligned. And and maybe trust isn't quite getting you there. You have to really dive in and and, you know, sort of or cover that somehow and and help bridge the gap of, like, yes. I understand that this is, you know, the the latest, you know, hype train tech, or I understand that you've heard a lot about this this other thing from a family member or whatever it might look like. But any thoughts on that, like, how you navigate that? So many thoughts. I do like, I I just wanna go back to, Nemanja's comments about, prototyping. I I think prototyping has a huge, huge amount of value in the work that we do for clients. Ben, I'm I certainly don't wanna poo poo your analogy on, you know, books and movies, but I think the important thing there is that, people can either create their own context or the people that they are hiring as experts can help create a better context. And if you leave someone to read the book, then they're creating their own context. They're creating their own imagination. They're filling in the gaps for themselves. Whereas the movie is telling them, like, this is what it is, and there's no imagination here. There's nothing, you know, left untold. This is the story, and, you know, you should pay attention to to this story. David Kelly, from IDO has got a great quote about prototypes. If a picture is worth a 1, 000 words, a prototype is worth a 1, 000 meetings. And so, like, you know, IIII do love the idea of prototypes because it does create that on ramp to trust. If a client's got a problem that is, you know, in their mind, immutably solve unsolvable, then, you know, a prototype from a experienced and professional team coming in to, you know, help highlight how it could be solved with proof of concepts or prototypes that, like, that accelerates the engagement massively. It creates a huge amount of trust. It helps solve a problem. It creates business value, and it's 1 of those things that clients can easily get behind because, again, going back to people, like, doing business with people they like, the person who you're working with has to look good in front of someone. And if you're helping them look good in front of their boss, like, that just solidifies and galvanizes the relationship because you're solving a business problem that goes beyond them. So I'll say that on on prototypes. Well, I just and IIII do agree because, again, we're hired as agencies to it's a full service agency, typically. You know, you are delivering a full suite of deliverables. And I think the the book and or, you know, the the the story itself is 1 piece of that, but it's our job as, you know, on the UX side, the UI side, the all these different pieces to be the cinematographer, to be the director, to to kinda give them the entire experience. Otherwise, you know, you're leaving it up to them. And maybe they're they're great and they have some great visions, but you're also probably gonna end up with a roomful of people who are all interpreting things quite differently. And And then you're gonna be navigating the people problem of, okay. Now we gotta try and wrangle everybody to the same page. Yeah. So I I think the the way the way that that we try to solve that is really trying to be proactive, right from discovery. I there's 2 things that, I will do within my engagements every single time. The first is is, an exercise called the graphic game plan. And, it was initially invented by, Grove Consultants, And, I leveraged this sort of storytelling visual of, hey. We're all we're all in our in our car, on our road trip heading towards this destination. The destination is project completion. What is going to be the measure of success for project completion? And then we put everyone everyone, including our team, the client team, puts their measures of success right in the center of that target. Then around that, you've got primary and secondary objectives. What do we want this experience to be? How do we wanna feel when we're doing the work? All of these sorts of things, We get them up there on the target as well. Then in the car are gonna be all of the stages and tasks that we need to do in order to achieve our objectives and achieve our our measure of success. Below the car, there's these bumps. And those are gonna be the challenges that we're gonna be facing along the way. And then the wheels on the car are gonna be the success factors. If everyone gets into a room and starts talking about success factors, challenges, all of the things that we have to do, the resources available to us, the objectives that we're trying to hit, then everyone owns the scope collectively. There isn't 1 side that owns the scope. And when you both share the scope, that's when you avoid things that I lovingly call climbing Mount Death March, where it's the vendor that is figuring out the scope of the project because it was ill defined at the beginning while they're developing. And, like, that is just the worst place to be in. So that's the graphic game plan. And the second thing that I'll do is ensure that we have stakeholder interviews from everyone in the company that could say no even at the 11th hour on the project strategy and the project direction. Because the 1 thing that every project should try to avoid is the swoop and poop. And that's, you know, when you're at a beach having a great day, team's doing great job, and a seagull flies in, shits all over your picnic, and then flies away. And then you're Good luck. There. What's that? I've heard that's good luck. That's a good thing to say. Trying to make you feel a little better about it. Yeah. Only the only the people that, they get crapped on tell you that it's good luck. Yeah. Only in the metaphor. Yeah. So those are the 2 things that we'll do to make sure that we've got alignment, right from the beginning. And that is probably the most important thing. Because if you take a flight around the world, around the equator, and you're 1 degree off course, by the time you get around, you're gonna be 500 miles off target. And that's 1 degree of deviation. So better to get that, you know, that heading right on target right from the beginning. Yeah. Yeah. I mean, it becomes rocket science. I mean, you the the more off you are, the earlier you're off, that just kinda compounds and you you're scaling problems. So if you can mitigate that, that's definitely something to be very aware of, in that early process. Yeah. Nemanja, I'm curious. Do you have anything similar, like, where you you've kinda had to deal with this issue of people coming in with preconceptions or trying to wrangle, you know, someone away from this idea that really just wouldn't work, but they're they're just struggling to to see the vision and to have that trust. Yeah. More oftentimes than I would like. But, I think that, you can't win them all. Sometimes just having a having done all of your homework, having done an extensive discovery phase, having validated your assumptions, done all the prototyping in the world, shown capability, discussed caveats, her hearing the client out and hearing their reasoning, seeing that there is no greater mystery behind why someone's as adamant as they are about a certain technology or not adopting a certain technology, the conclusion might, in the end, be that it's someone's need. And, that's okay. What we do in these situations is that we establish a very, very loud and very clear communication channel throughout the process from the first meeting where things are we're an agency, and we eventually perform a service for our clients. So if you've exhausted all of your options and if there is no other way to argue your point, you just have to be very, very clear and very direct and to communicate very frequently what the risks and consequences of a decision you believe are is suboptimal are. So making sure that this 1 degree deviation that everyone knows that it's gonna be 500 kilometers by the time we get back and alerting date, like, an alarm clock every hour. Like, saying in every retrospective meeting or every time there's an opportunity to discuss technical depth or to discuss progress, just making sure everyone understands the consequences of the choices that we believe were suboptimal. 100%. As I said, you can't win them all. There's no way that everyone's always gonna be aligned regardless of how good your argumentation is. But I think it's our responsibility as partners to make sure that we alert to these consequences as often and as early as possible. Yeah. No. A 100%. And I think, again, when things go south, the best thing that can happen is to already have established trust. You know, they they understand why the communication is there, and at least then it's you know, you you can hopefully navigate, through the project or whatever that ends up looking like. But, yeah, I we've kind of mentioned that word so much. I it really, you know, going back to, I think, the beginning of this, Steven, you had said you can only move at the speed of trust, which I took a note of. I think that's I think that's an amazing, sort of, like, way to kinda think about this and highlights the importance of that trust and communication, and it connects it to something that's very real. Like, when you're building a project, you've you know, speed. Speed is important. You can't you when I was running my agency, there was kind of 4, sort of levers that you really had to work with, and they were all I I think there's even a website where you can turn certain ones on and off. It was speed, scope, cost, and quality. And, of course, any good agency is gonna take quality off the table and say that's always gotta be good. We're we're not gonna sacrifice that. So you have these 3 toggles that you can kinda, you know, choose to choose your own adventure. And it's great to know that trust is a huge part of of the speed of the process, because, really, in the beginning when you're figuring out the scope and you're, you know, setting up what the cost looks like, you just efficiency and speed is is the name of the game. You know, how can you get through and and help to establish that and help the client really understand what their options are, that you are the right vendor, or, you know, partner to help them get through this. And I guess it all just comes down to to to that trust. So, we we've said that word a lot, and that's I think that's we we could probably rename this episode into, you know, establishing trust and, you know, the importance of trust at the agency level. But, you know, we we we ran over time a little bit, which is which is always good. We didn't even get through through all of our questions here, or, you know, I think there was a few that were thrown into the chat. But, any final thoughts, Steven Steven or Nemanja? Nemanja, why don't you go first? Yeah. I was just gonna say because it piggybacks nicely off of what you've just said. It's not only trust, I would say, it's partnership. Like, 1 of the things that got me, when I was deciding whether I'll go into agencies and service work or whether I'll go into, like, building a product startup or something like that was agencies, at their core, help solve problems, and you can't help if you're in an adversarial position. I really every relationship that we've had with a client that was hugely successful and that brought a lot of, for lack of a better word, happiness to me after the resolution was when we were true partners. So it's not like we're warning you this will fail because you're not listening to us. It's like, how do we make sure that since these are the the axioms that we have to work against, we fail less as a team. Like, being a partner to our clients is, I think, a lost forgotten art. Sometimes we get into a mindset of us versus them. I don't think that's a good mindset for agencies or tech providers at all. We serve technologies is there to serve solve problems. And, like, at its core, what we do is we facilitate. We use amazing tools to change the world. So partnership and not pointing fingers. The name of the game for me. That's hon. I that's exactly right. Open, trust, you know, those are all key things, but really the goal of those things is to, establish a partnership where you're you're in it together because, I mean, you truly are at the end of the day. Yep. Steven, thoughts on that or, just, you know, closing closing thoughts? Yeah. I I mean, I, I feel like Nemanja and I drink the same Kool Aid. It's 1 of those things where, for me, there was a very, very defining moment earlier on in my agency life where I I really just took on this mantle of being a designer is the most important thing in the world, and I would tell my clients, you know, the overarching responsibility of a designer and and how we're, you know, empowered to create amazing tools. The bottom line is they really didn't give a shit, about my my little speech about, you know, design. And it really sort of came to a head when I started changing the language that I was using around the value of the work that we do and what we bring to the table. And it was speaking my client's language, being empathetic to what their needs were and how they were articulating their business problems. And it was all in the language of business. And so if you can get out of your own way and stop speaking the language of design or stop speaking the language of technology and speak the language of business and how the tools that you wield are going to help solve their problem in a way that makes sense to them, that's when you actually engender really good partnership and really good, foundation of trust. And so I think that was a a really key moment for me in my, in my sort of growth and learning, as a agency owner and now someone who's in the, you know, the big 4 consulting world. Yeah. Couldn't could have said it better. I I again, these are all just huge pillars in how you how you kind of establish and foster, those those relationships. And then again, the the benefit of that is then you end up working with these clients, over and over and over again, and they just become huge advocates, for not only the stack that you help them select, you know, which, you know, we're a great great in a great position to be chosen by such a great you know, by so many great companies, but also, you just get to, have that repeat business and long enduring, partnerships with with great companies. So excellent. Steve and Damania, this was has been an awesome chat. Again, probably, we'll have to, like, circle back and maybe think about another 1 because a lot more. Again, this is the, you know, the whole reason for me being here, was was how how to solve these problems within an agency and trying to find the right tooling. And it's not always direct us. It's not, you know, that's the name of the game is, you know, just finding finding the right tool for the right job, which is not easy, as we say in an hour and 8 minutes in. But thank you both so much for joining, and we'll be seeing you at the rest of Leap Week for everybody else who's who's watching now. Thanks so much for having us. Absolutely. Alright. Thanks, everybody.","4b21caf7-40e8-4f5a-b7b4-7d23c2aba06e",[207,208,209],"10147a57-dc26-4090-b5ea-d5ff4b089b04","a334f73f-c0c0-4021-8a9f-4f874eefea24","56797030-83a9-41f3-b194-791d0979c2d5",[],{"id":133,"number":134,"show":122,"year":135,"episodes":212},[137,138,139],{"reps":214},[215,271],{"name":216,"sdr":8,"link":217,"countries":218,"states":220},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[219],"United States",[221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270],"Michigan","Indiana","Ohio","West Virginia","Kentucky","Virginia","Tennessee","North Carolina","South Carolina","Georgia","Florida","Alabama","Mississippi","New York","MI","IN","OH","WV","KY","VA","TN","NC","SC","GA","FL","AL","MS","NY","Connecticut","CT","Delaware","DE","Maine","ME","Maryland","MD","Massachusetts","MA","New Hampshire","NH","New Jersey","NJ","Pennsylvania","PA","Rhode Island","RI","Vermont","VT","Washington DC","DC",{"name":272,"link":273,"countries":274},"Michelle Riber","https://meetings.hubspot.com/mriber",[275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,252,463,464],"Albania","ALB","Algeria","DZA","Andorra","AND","Angola","AGO","Austria","AUT","Belgium","BEL","Benin","BEN","Bosnia and Herzegovina","BIH","Botswana","BWA","Bulgaria","BGR","Burkina Faso","BFA","Burundi","BDI","Cameroon","CMR","Cape Verde","CPV","Central African Republic","CAF","Chad","TCD","Comoros","COM","Côte d'Ivoire","CIV","Croatia","HRV","Czech Republic","CZE","Democratic Republic of Congo","COD","Denmark","DNK","Djibouti","DJI","Egypt","EGY","Equatorial Guinea","GNQ","Eritrea","ERI","Estonia","EST","Eswatini","SWZ","Ethiopia","ETH","Finland","FIN","France","FRA","Gabon","GAB","Gambia","GMB","Ghana","GHA","Greece","GRC","Guinea","GIN","Guinea-Bissau","GNB","Hungary","HUN","Iceland","ISL","Ireland","IRL","Italy","ITA","Kenya","KEN","Latvia","LVA","Lesotho","LSO","Liberia","LBR","Libya","LBY","Liechtenstein","LIE","Lithuania","LTU","Luxembourg","LUX","Madagascar","MDG","Malawi","MWI","Mali","MLI","Malta","MLT","Mauritania","MRT","Mauritius","MUS","Moldova","MDA","Monaco","MCO","Montenegro","MNE","Morocco","MAR","Mozambique","MOZ","Namibia","NAM","Niger","NER","Nigeria","NGA","North Macedonia","MKD","Norway","NOR","Poland","POL","Portugal","PRT","Republic of Congo","COG","Romania","ROU","Rwanda","RWA","San Marino","SMR","São Tomé and Príncipe","STP","Senegal","SEN","Serbia","SRB","Seychelles","SYC","Sierra Leone","SLE","Slovakia","SVK","Slovenia","SVN","Somalia","SOM","South Africa","ZAF","South Sudan","SSD","Spain","ESP","Sudan","SDN","Sweden","SWE","Tanzania","TZA","Togo","TGO","Tunisia","TUN","Uganda","UGA","United Kingdom","GBR","Vatican City","VAT","Zambia","ZMB","Zimbabwe","ZWE","UK","Germany","Netherlands","Switzerland","CH","NL",1773850416662]