this episode is brought to you by c t O dot Ai. You guys know that I interview a lot of great builders on this show, and one of the most important aspects of a great code story episode is how a team works together to continuously deliver a great product and not only just a great product, but one that will scale to meet growing demand. It's easy for growing teams to get overwhelmed by, you know, it complex tools, complex tools can be a major source of frustration across the team to spend all of your time managing tools instead of building great products. Mhm Meet cto dot ai. C T O dot ai is a workflow automation platform that simplifies developer operations. So you're growing team can improve their delivery velocity and hit their launch states. What I love about the platform is that it doesn't matter your experience level, you can be a junior dev, you can be a senior dev, it doesn't matter the platform allows any developer to build powerful workflow tools and share them across their team.
You can do this using their services, pipelines, commands and insights tools to create your singular workflow in a powerful way. You can easily release code anywhere directly from slack. It's where you live anyway. Automate live previews of new feature changes and measure your integration, your Ci cd Hayden's and stability of all of your products, so who uses cto dot ai the best and most sought after startups in the land cto dot ai has helped fast growing startups who have raised over half a billion dollars in funding to scale their software delivery workflows, find out how they can help your team workflow smarter. Not harder by visiting go dot c T O dot ai slash coat story. This episode is brought to you by courier. Your application speaks to your users with notifications. But what do you do when your users each respond better to a different channel? Building the event triggers is annoying enough.
But when you have to build templates for multiple channels, track delivery ability and performance and manage granular user preferences, you end up with overwhelming complexity that distracts your team from your core product. That's why courier built. It's a P I. And notification system as a surface. Courier is the fastest way to design, manage and orchestrate all of your applications notifications. Using a simple api. The U I is a powerful dragon drop editor to help you build and send templates over any channel while giving your users full control over their own preferences. Plug in providers like Twilio Sin grid, male gun and fire base to send email. SmS push in app or even direct messages like slack WhatsApp or M S T. S. It started today with 10,000 notifications free every month. No credit card needed. Just go to courier dot com slash code story. That's C O U R I E R dot com slash code story. I wanted to build something that was going to be stable. That allowed us to work on the product itself.
That's what led to my decision to build something very custom and very lightweight. No decision was like let's do some things that we know isn't going to scale an example of that is loading almost all of your data up front and then just keeping it in memory so that once you've taken that kind of cold load hit everything after that is basically instant. That decision like it allows us to put extremely fast product out there and I think that the speed of it was like kind of our secret weapon. My name is Andrew Child's, I'm the co founder and chief design officer of shortcut. Yeah, this is code story, the podcast bringing you interviews with tech visionaries who share in the critical moments of what it takes to change an industry and build and lead a team that has your back, I'm your host, noah lab part and today how Andrew Child built the best tool to bring the flow to your software teams, workflow, all this and more on coat story.
Mm uh huh Andrew Childs doesn't have a computer science background. He grew up in Philly and is currently based in new york city with his wife and six year old. His first computer experience was in 1984 with a macintosh plus with no internet, it was just a playground in the beginning but on it, he was able to explore design and learned pascal he attended Riz de in Rhode island an art school. His goal was to go into contemporary art but he quickly realized that he didn't know anything about how to approach the art world throughout the program he did learn a lot about how to think and how to look at things and how to be creative post. That. He ran a few web design and development agencies before being pulled into the start up world at a prior startup. The opinionated nature of project tools his teams using started to get in the way of their productivity not to mention it was not possible to get a bird's eye view of direction, progress etcetera across multiple projects. During a half day project. Andrew built a way to aggregate their tool into one single view.
It was then that it clicked and he and his co founder thought maybe they were on to something. Mhm. This is the creation story of shortcut. Shortcut is a collaboration product that is really built for software team. So not just not just engineering not just product but really a software team is being basically your entire R. And D. Organization and the people that R. And D collaborates with. So engineering, product design, C. X. Sales executive teams right? Like we're trying to build something that allows all of those different functional groups to come together and collaborate together on their roadmap managing and tracking their work and documenting their work all in the same kind of system of record, source of truth in a way that doesn't make you angry, doesn't make your team angry. And and it's hard to do that because engineers are grumpy group of people very opinionated and using bee to bee products is a very emotional thing, right?
And so we're trying to build something that is uh fast and delightful and it feels like it's it's approachable to people, not just in the interim team, but everyone kind of across the organization. On top of that. We're also trying to build something that scales with you and and kind of allows you to scale From, let's say, a team of five people all the way up to 50 to even to 500 people. Uh and there's a whole kind of art and science to trying to do that. Uh So pivotal Tracker was the tool that we were using under last last company and pivotal tracker was made by a pivotal labs, which is a consultancy. And tracker was a part of their package like that. They were selling to their clients and it worked well for us until it got to the point where the opinions and the methodology that was baked into the product kind of fell apart for us because as soon as we had, You know, let's say 50 people, we have people working across multiple projects and really no way to get a sense, high level sense of what was going on, you know, press forward two, uh the last six years, like we've heard from people coming from Trillo for example, It's very easy to spin up 100 Trillo boards, but it's very difficult to have any idea what's going on across all of them.
It got to the point where we just, it wasn't just the uh it was just the cross project thing was there was a lot of kind of issues that we're facing with it. And kurt uh at this point was the C. T. O. Became the CTO and said, okay, we need to move to jerod jurors, the industry standard tool, we export everything imported into jura immediately felt like a, an impact on our daily working lives. It was harder to use, it was confusing, nobody really wanted to use it, people were talking outside of the tool. And so this coincided, this move coincided with a hackathon that we did. And so I took it upon myself to build a, effectively like a trilogy ui on top of the civil tracker api that allows us to see a cabin board of multiple projects are all kind of on the same board. It worked and we ended up actually moving the entire engineering team to exporting everything out of your reporting it back into a pivotal and using this hacked a project which was crazy, crazy in hindsight.
It was kind of an interesting light bulb moment. Maybe there's something some, you know, there's an opportunity here. We kind of left it kurt and I left it and we ended up talking maybe a couple months later in the kitchen in the office, back when we have an office and we're like, you know if we were back out of the civil tracker FBI build our own FBI we can kind of go in our own direction, right? This is this is where you have to, we have to recognize the fact that this is a very competitive and crowded market but the reality is like all of these products have opinions baked into them and it just felt like there was nothing that really nailed it right? Like nothing that really worked for a scaling agile small a like software team that's how we ended up leaving that company and starting starting shortcut. Yeah. What I'd love to dive into is the is the M. V. P. And you kind of already set the stage of how that hack day product started.
But I'm curious if there's another M. V. P. After you left. So tell me about, you know, either one of those whichever one you want to jump into and kind of give me some ideas about how long it took you to build and and what sort of tools you use to bring it to life. This is an interesting subject for sure because the architecture of the original product, the M. V. P. It came out of the work that we were doing at our last company which was we like we had our own extra net right? Like our own web rails app that we were providing to our customers. But we also were building a very micro framework kind of library that we were placing on travel sites. You know, a big part of my whole philosophy was like let's build something small and kind of encapsulated and fast. The original framework was really like an extension of that that sort of style of working. And the original framework was very custom kind of NBC framework. There was a custom like collection model library.
There's a event binding library that I wrote. There's a template library that I wrote all of it was basically custom, you know, purpose built for this this product. And I was intentionally using boring unfashionable libraries because like this is a pretty unique product. It's not like we're destroying lists of stuff, right? Like it's not like kind of a generic application, this is something that involves like drag, drop and there's a lot to it. And I wanted to build something that was going to be stable that allowed us to work on the product itself, right in the user experience, not necessarily like spend all our time upgrading the core library core framework and then all the dependencies right around this time. Like Amber was getting a lot of heat, right? For being too complicated to upgrade angular was like seen as this massive framework and react was still very new. So that's what led to my decision to build something very custom and very lightweight.
So no decision was like let's do some things that we know isn't going to scale. An example of that is loading almost all of your data up front and they're just keeping it in memory. But so that once you've taken that kind of cold load, page load hit like everything after that is basically instant. That decision worked in that it allows us to put an extremely fast product out there and I think that the speed of it was kind of our secret weapon and still is speed is like a feature in my opinion. It's like a multiplier. It like impacts every single kind of business metric. So that that worked. But at the same time it also meant that you know 567 years later we're still grappling with that. It becomes obviously like a matter of scale. And once you do scale, uh you've got customers with like hundreds of thousands of stories right? Like how do you how do you manage that?
How do you decide what to show what the load and all that you touched on a couple of these already? But I want to dig into them a little more, you know, with any M. V. P. You got to make decisions and tradeoffs and you talked about the custom framework that you built And then you talked about loading all the data up front, how did you go about making those decisions and how did you cope with them? The reason that we went in this direction was because for me it's it's always much more about like what are you comfortable with versus like what's the cool new framework to try? Like this is not a side project kind of project. Like this is something that I wanted to be able to no the inside of that code. And when you're building effectively like on bare metal, you know, you can optimize all the way down to bare metal versus like when you're using something like angular or react or whatever, you eventually get to a point where you're trying to do something that doesn't want to do and you have to now figure out like how to break open that black box and start optimizing it, we're working around it.
So that makes sense. Do you feel like having to build a custom over using one of those frameworks were eventually you have to get down to the brass tacks to optimize it. Did it slow you down anyway? Oh yeah. Yeah, for sure. I mean, we obviously it worked great when it was a very very small team the reality and kind of looking back right, like it doesn't matter how fast or simple or successful that library is. If it's custom, even if you still have the person that wrote it sitting next to you right, like ready to help you eventually, you know, you build up a team right of engineers that they need to be able to go to sec overflowed, find solutions to the problem. And you know, they also like nobody wants to work on uh one of a kind kind of framework that they can't take with them, you know, to wherever they're going next. So like that's that's where obviously like the kind of industry weight behind react kind of pulls people into picking that right as a framework.
We've been moving to react since then. We've also been building, you know, uh design system and kind of a component library and doing all the things that like you should be doing. Yeah, that's a perfect segue actually into my next question. And so how did you progress the product? Right? How did you mature it? And then so with the things you're pointing out also, how did you go about building your roadmap and deciding this is the next most important thing to build, I will say it's been, it's been fascinating to watch our front end engineering team work and kind of pick apart my, my weird code that I wrote and standardize it and turned into something that resembles a modern application. Uh it's been fascinating to watch because there's there's there's a lot of like kind of fundamentally different ideas about kind of data fetching and holding on to state and things like that, that like they've had to kind of resolve and they've done it.
Like it's it's been really, it's been really cool to watch your question about like the road map. That's a super interesting topic. I would say. It changes like how we do road map has changed like every quarter uh for the last seven years. It very much depends on who's leading it. Who wants to lead a obviously like our product team has kind of matured very much taken the lead on defining it. Mm There's a tension at our company as I'm sure there is at every company where you as a leadership team want to make sure that we're going in the right direction, but you also want the team to feel empowered and trusted, right and autonomous to be able to make decisions. So that's where like us as a leadership team as executive team, like defining principles and values and the mission and business objectives, right? Like those are the things that once we have that in place, the teams can then make decisions that say like is this is this an alignment with these kind of foundational opinions that are being given to us in theory, right?
Like that's that's kind of the ideal situation where the team, the team has given the direction we want to go in figure out how to get us there. I'm also a big proponent in just and we're doing this ourselves actually as a design team right now, ensuring that you have backlogs, like specific backlogs, not just like a giant mountain of stuff because I think like a lot of people just want to pretend it doesn't exist and then they can kind of play with their tiny pile of stuff over here. But then you have to acknowledge that like there is 1000 things in the backlog and they're all good ideas. It's important that we try to break that down and try to say like, okay, what are the big features, the most impactful features that we want to work on? One of the most impactful kind of tech debt designed a product that that we want to pay down were the most problematic and most irritating bugs that we want to himself, right? And it's not about saying, okay, we're going to do this one this week, it doesn't really matter, right? Like which week or which iteration or whatever. Something that's done, it's about, is it somewhere in the backlog, right?
Where you can pull from? So having kind of discreet smaller broken down piles of work backlogs that you can pull from and having a, having a defined ratio right between those things I think is really important. The difference between saying we're going to spend 95% of our time on future development There are trade offs there, right? Same with saying we're only going to spend 30% of our time on feature development. Right? So the more explicit you can be about the ratio between like features and chores as we call them. But it's really just like improvements, right? And paying down tech debt and bugs bug fixing. There's no perfect ratio there, right? And no perfect method. But it's something that we're constantly experimenting with that is really interesting. The ratio like it makes a ton of sense when I, when I think about that and the types of backlog that you're essentially, you've got enhancements, bugs, feature work, core infrastructure, all that stuff.
But having that sort of defined ratio at least helps with the quick and dirty planning and maybe you decide as a team, hey, we're going to do more infrastructure this week or hey, we're going to do more feature work because because of X reason, but the baseline is that ratio, that's, that's really interesting. I would love for us to actually be doing that aspirational. But to me that's like that's the right way to do it. Well, let's, let's switch to team then. So tell me how you went about building your team and I'm interested in what you look for in those people to indicate that they were the winning horses to join you. I think there is, you could say values or behaviors or principles or whatever like that, things that you look for, right And in people and for me it's, it's a sense of curiosity, you know, an interest in improving yourself and and in proving the team right in the processes and thinking about that, like, being able to uh think deeply about problems.
I think it's it's important to be taking your time on on things and not, not try to plow through things too quickly. Another big one for me is humility and just how collaborative you are. That's a whole big topic itself. Right? What does it mean to be collaborative or, or humble? Right. And a lot of that's really just about how you disagree and like how you state your opinion on something in a way that doesn't end up with like a stalemate and also like being able to admit when you don't know or that you're wrong about something. I look for people that are professional that are, you know, operate in good faith, like our inclusive, that are able to kind of operate transparently right? Like in public versus having kind of backdoor dealings, you know, like to me it's it's important, especially for a product like this, that we capture what, what our opinions are and are transparent about what our opinions are. So that six months or a year or two down the road, we can go back and say like, oh, this is why we, this is what we thought this is why we made this decision.
So yeah, there's there's a bit of like, domain specific, like firsthand experience that look for, to write, Like have you worked with aggravating B two B products before? And have you worked on like a dysfunctional software team before and want to use that you know and make something better, make something better in this space? I bet you've had some interesting interview stories with that question. Have you ever worked for a dysfunctional software team? Tell me about that. Yeah, everybody's got a story and I mean yeah the reality is like a lot of places are dysfunctional and low trust. What's funny is that we're trying to build something that at least puts you on a path towards trusting your team a little bit more right? So like there's a little bit of we wanna push back gently towards our customers and say like maybe you don't need that feature. It's going to create this just dysfunctional dynamic between the manager and the engineer for example or across different departments.
This episode is sponsored by imagery. If you're ready to add photo or video editing to your application. Image lee is a great place to start. Imagery provides a software development kit that handles all the technology for adding photo and video editing right inside your application there? S D. K. S are fully customizable and can match your apps look and feel and support all major platforms. Let users share beautiful photos or videos create imagery for marketing campaigns, build photo books or even automate design with templates, their video and photo editor. SdK is used by Shopify Hoot suite shutterfly and hundreds of other companies helping them ship software faster. The image. The software development kit is the fastest way to add photo or video functionality to any application. Visit I M G dot L Y slash code story today to try the web demo. That's I M G dot L Y slash code story. This episode is sponsored by Ratelle. Are you interested in joining a team that encourages intellectual curiosity, problem solving and openness?
Not only that but one that provides the support and mentorship needed to succeed, learn and grow meat Row double. The team at Rattle has built a world class platform for modern bill payments payouts and invoicing rattle helps companies speed up their business payments using a secure invoice and bill payment system and not just for accounting groups. The company is solving problems for the CFO controller, the accountant and the developer rattle is engineering lead and fully remote. They're looking for the best engineers and operators to join their team and drive forward their mission of removing the burden of business payments to apply today. Go to rattle dot com slash about and click view. Open roles. That's R O U T A B L E dot com slash about. Check out rattle today and join a team who is changing the face of business payments. Mm Well let's switch to scalability and you and you talked about this a bit in the beginning but I wanna I wanna give room for the entire answer around scalability.
So Did you build this to scale efficiently from day one or are you fighting this as you grow? This is where our entire engineering team will just laugh because they know the answer to this question. We did a lot of things that didn't scale right? And one of those, as mentioned was loading too much data up front. Right. And that was that was again by design to create an extremely fast interface and extremely fascinating experience. Another another example, another like intentional decision was being okay with duplication. Code, duplication. To me, duplicated code is like that's an easy problem to solve, right? Like you can you can as an engineer look at Okay, these two files are 95% the same. But what happens is when you d duplicate code, you're creating a hard problem. You're trading an easy problem for a hard problem because now you have this nicely factored ball of complexity that now you're much less likely to change because you're you now have to look at, who knows how many different places to see if it's if it's broken, right?
Like that's how a lot of regression tests or regression bugs happen, right? Because you have this shared component that is everywhere and you only tested it in a couple places. But these other places you didn't look at. And that's also how code kind of like calcify eyes. it becomes really like, nobody wants to, nobody wants to to change it. We're scared to change it because they don't know. And this is also uh, directly coming from my experience that our last company where everything was like, don't repeat yourself. Like that was the kind of the motto particularly for rails and what that meant was like we had frankly that and the degree of, of code coverage of like test coverage that we had meant that The code just wasn't changing. It couldn't be changed once it was done. Like it was a massive amount of work just to change small things here and there because you had to look in 10 different places and test different things. So there was, and still is, I think a fair amount of duplication in the code specifically to avoid that.
Right, okay. It meant that bugs were isolated, they were easy to catch, we could evolve different pages easily, but you know, I got like, this is everything is about trade offs, right? Like there's no perfect answer here. It also meant that we started introducing a lot of inconsistency in the design and in the, in the UI from one pitch to another. So that's, that's something that we're actively working on it improving as you step out on the balcony and look across all that you've built with shortcut, What are you most proud of? I think a lot of it is is really about the team. I regularly sit in meetings with various people and I still can't believe that we have a team and organization of this size and caliber. You know the fact that this was this started out as just this hack day project and turned into an organization of this size with so many like sophisticated software companies using it back when people had offices. It was it was such a pleasure to tag along to like customer meetings with our R.
C. X. Team and walk in to you know this this big open as every office was open terrifyingly open. But then you'd see like all these people with your work on their computers on their screens it's like moments like that that make you realize like how how real it is because it's very easy to forget that let's flip the script a little bit so tell me about a mistake you made and how you and your team responded to it. Mhm. There are a couple I mean we've made a lot of mistakes. Uh huh over the over the years one of them is you know I took it upon myself to write you know a cashing layer and it worked, it worked great until we realized that it was creating bugs that were just completely impossible to diagnose because people you know put their computers to sleep, browsers go to sleep. They do very weird and unpredictable things when they're in that kind of half asleep state.
So cashing can very easily kind of get screwed up that to me was an example of how, you know, trying to solve things in a very complex way. Like you have to, you have to consider what you're getting yourself into with the optimizations that you make. I think that was a lesson for me was like don't over optimize another thing is just, you know, like we've had people delete the database. This is very early on. But what's important is I think one aspect of the high functioning team right, is like psychological safety and so people need to know that it's okay to big mistakes and take risks right? And know that you'll be you'll be okay, you'll you'll be trusted to learn from that. So what does the future look like for shortcut the product and for your team, the future of the product? I think there's, there's a ton left to do right? Like this this is a never ending project for us. We recently added kind of teams concept.
We're not just like adding things to the product, which is great. Like we're what I'm really excited about is the fact that we're editing the product project the products. Like we're removing things from it too. So an example of that is we have a concept of projects and we're slowly replacing that deprecating that in favor of more specific fields like custom fields and structured fields so that, you know, people know how it's supposed to be used, like that was one of the things that I think we would have done differently is naming right? Like naming things is hard, you know, we have like a fixed work hierarchy that you can you can use out of the box, right? Like that allows you to connect all the little stuff that you're working on back to the big initiatives and we're working on making that a little bit more flexible. There's a whole bunch of things that happened before and after the execution of work, right? Like there's the planning, product planning, there's the road mapping, there's the capturing of support tickets, capturing feedback on the work that you you release.
And so there's a lot of, a lot of work left to do to to solve that better. And I think the core thesis here for us is that all that work should all kind of coexist together and connect together, because otherwise you have, you end up with like, silos and miscommunication. So let's switch to you Andrew who influences the way that you work, you name a person you look up to and why? I would say my parents uh for one thing, I would also say, like I grew up watching Mr Rogers, I don't know, he's always been a role model for me, I think the way that he spoke about embracing what makes you different and unique, right? And embracing what's different about all of us, right? And uh, he spoke about, you know, the concept of a neighborhood in the community and how it's not about everybody agreeing with each other. It's about like the fact that we all can kind of work together and disagree and resolve our differences together and just live together.
His his message is so runs so counter to like the world that we live in today. And I still kind of hold on to the experience of growing up watching his show. We've watched it with our son Elliot, my wife and I, and it's, it's still like, it's so moving to watch it. Um, and it's still relevant. You know, like it's still, it's about stories, it's about how you feel about working through your feelings, things that are still just as relevant today. Well, last question Andrew. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing, the jazzed about it. They can't wait to show it off to the world. Can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit? I would say this looks cool. Can't wait to use it. My my feeling is like, don't worry so much about your own like developer experience. Like it's ultimately all about the user experience at the end of day, like nobody uses a product because of the tech stack, you know, that was used to build it, they use it because of the way it feels to use it and the, the value that they get out of it.
And I would say like, people tend to people tend to build things for the wrong audience, you know, like they tend to build for their, their peers, right? And people that they think are cool, right? And uh, example is like design agencies tend to, they tend to build things for to impress other designers, not so much to like to achieve the business goals of the client. My point there is like, don't feel like you need to build something using the coolest new technology, right? Like it's more about building something that works really well. Does that feels great. That has a great UX that solve somebody's problem really well. Right. It doesn't matter if there's only one person the start, if they love it, then that's then you're onto something. But don't don't worry so much about building it in the right way, right? Like if you're using a boring old piece of technology, don't worry about it. Like if it allows you to get to the a building a great product and that it was the right decision.
That's great advice Landry, thank you for being on the show today. Thank you for telling the creation story of shortcut. Thank you know, I appreciate being here. I know, and this concludes another chapter of Code story. Code Story is hosted and produced by Noah Lab Heart. Be sure to subscribe on apple podcasts, Spotify or the podcasting app of your choice. Support the show on patreon dot com slash code story for just 5 to 10 bucks a month. And when you get a chance, leave us a review. Both things help us out tremendously. Thanks again for listening. This episode of Code Story is sponsored by Cloud Ways. Cloud Ways is a managed hosting platform ideal for small to medium businesses, e commerce and agencies because with cloud ways they don't have to worry about managing or maintaining servers and can instead focus on their business.
Cloud Ways offers peace of mind to business owners with reliable 24 7 support and manage backups. Their custom stack has integrated cash and performance boosting tech that will improve page load times, which is super important with cloud ways, customers have the freedom and flexibility to deploy PHP apps from a list of five cloud providers in just a few clicks, those providers are a W S, digital ocean Lynn owed google cloud and Voltaire. They can scale their servers up or down anyway. They want cloud ways has a lot of features that makes development and deployment on the cloud much easier and faster features like integrated, give a staging environment, team collaboration tools, a pre configured composer and free ssl that's right. Free use the promo code Code 30 And get up to two months of free hosting with a $30 credit. That's promo code CODE 30. Take a look at their website today at cloud Ways dot com.