How Agencies Innovate

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.

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.

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.

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.

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?

Speaker 1: Oh, yeah.

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.

Super happy to have you here. Nemanja, do you wanna, run through a quick intro from over at Workinco?

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.

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.

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.

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.

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.

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.

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?

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?

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.

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.

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.

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?

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.

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

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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?

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.

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.

Speaker 0: It

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.

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

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.

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?

Speaker 1: I think there's always challenges and issues. Yeah.

Speaker 0: A more notable 1. Yeah.

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.

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.

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?

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?

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.

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?

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.

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.

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.

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?

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.

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.

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.

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?

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.

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.

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.

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?

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.

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.

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

Speaker 2: who are

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.

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.

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.

Speaker 0: And then you're Good luck. There.

Speaker 1: What's that?

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.

Speaker 1: Yeah. Only the only the people that, they get crapped on tell you that it's good luck. Yeah.

Speaker 0: Only in the metaphor.

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.

So better to get that, you know, that heading right on target right from the beginning.

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.

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.

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.

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.

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.

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?

Speaker 1: Nemanja, why don't you go first?

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.

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.

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?

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.

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.

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.

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.

Speaker 1: Thanks so much for having us.

Speaker 0: Absolutely. Alright. Thanks, everybody.