 All right, everyone, thank you for coming. This is quite a turnout for a business track talk, so excited to see you all here, and thanks for joining us. If any of you are in town for a medical conference and saw this slide and happened to wander in, this talk is about Drupal, so it's about to get super confusing. So this talk is called, You Wouldn't Choose the Cheapest Brain Surgeon. Let's see if I can go to the next slide here. Maybe. Yay, maybe not. Ah, okay. Up and down. It is up and down that moves to the next slide. Excellent, all right. Please join for Contribution Sprints of Your Developer. They're really important. It's Friday, April 13th, from 9 a.m. to noon in Room Stoles 2. I am Nelson Harris. I'm a business development strategist at Elevated Third. And I'm Joe Flores. I'm a senior developer at Elevated Third. And you can find me on Drupal.org as Mojifris. And we both work at Elevated Third, which is a Drupal-specific website design and development agency that's based out of Denver, Colorado, or about 30 people. And we have a booth here at number three of six, so if at any time you guys wanna come chat with us about anything or this talk, please feel free to stop by the booth and we'd love to meet you all and speak with you. So before we begin, I just want to start with a little bit of a disclaimer. If anyone is a Drupal hobbyist or sort of more into the Drupal community for the sake of the project, that's awesome. And you're a big part of the community and we appreciate you, but this talk is really geared towards the business track. We assume that you are all in the audience because you either sell Drupal services as an agency or you buy Drupal services as an organization and with the goal of sort of getting the best possible value. So that's our quick disclaimer. If you're a hobbyist, we don't wanna offend you with some stuff that we're gonna say, but cool. So let's explain this topic of the cheapest brain surgeon. We wanted to start with this analogy because it kind of underpins the whole concept that we're gonna be talking about as we go through the talk. So I think this will help us kind of get on the same page. So the scenario is that you've just found out that you have a terminal brain aneurysm and you are going to die if you don't have brain surgery and it's treatable, but you do have to have brain surgery on it. And let's say for the sake of our hypothetical here that you don't have health insurance. I hope that this happens to absolutely none of you. But in this case, you have $100,000 to spend on a brain surgeon to help you with this problem. And so in this scenario, you see two different brain surgeons. One of them is a brain surgeon who says, I can do this for your budget of $100,000. She lists the team of doctors and nurses and support staff that she'll have that will help you with this brain surgery and she'll talk about the recovery time that you'll spend in the physical therapy you'll go through and the things that you'll be able to do after the surgery and compared with the things that you were able to do before the surgery if there are any sort of complications that happen and sort of talk you through all the risks. And then the other one says, I can do it and for half the price and it'll be quick and it'll be easy and it'll be awesome. Which one would you choose? It's yeah, it's obviously kind of a silly example, right? It's not even a question. It's your life on the line. You would choose the brain surgeon with the highest price and you would frankly be pretty offended that somebody offered you a deal on brain surgery and said, hey yeah, I can do it. It's quick and easy, no worries. And so there are a lot of risks in brain surgery. There are a lot of things that can go wrong and there has to be a plan going into brain surgery. It's specifically tailored for your case. There's a consultation. There are sort of repercussions that can things that can go wrong and you really do wanna pay more because you wanna feel as though your risks are mitigated and you wanna feel as though you're choosing somebody that has the highest chance of saving your life. And in addition to that, you'd also want a surgical team. You'd want a team of staff that is well trained in addition to the brain surgeon that you're putting your trust in. You'd wanna know that they have the best tools. You'd wanna know that there's millions of dollars of equipment that's highly specialized and they're not just gonna cut up in your skull with a hacksaw and that you're actually gonna get this tailored experience. And so we argue that shopping for Drupal services is has sort of the same general ideas behind it and the same rules tend to apply. Yeah, so as the developer position here, for many years, the Drupal community has talked about and compared Drupal to other CMSs. We've talked about how it's more complicated or more powerful I should say than WordPress. It's easier to use than Drupal. It's open source and less expensive than Adobe experience manager. Every year for the last few years at DrupalCon, the Drees note and multiple sessions have discussed how we could achieve feature parity of the market or the market reach of other CMSs. And as the release of Drupal8 grew nearer, things kind of started to change in the Drupal community. There's more talk about headless Drupal. Drupal is more than just content management but content relation and content architecture management. And excitement really grew with the possibilities and extensibility of D8 beyond just being a simple CMS. And then last year at the DrupalCon Europe in Vienna, Drees showed this slide which talked about how Drupal was built for ambitious digital experiences. Suggesting that with Drupal8, blog sites or basic marketing sites were too simple for Drupal. And this is where we agree. So we've spent a lot of time as a company thinking about what Drees has said about Drupal. And we've embraced the notion that Drupal has changed and grown and is now meant for enterprise builds and more ambitious digital experiences. And over the last few years we've experienced some interesting results from thinking a little bit differently about how Drupal is or what it is meant for and we've been able to cement this notion, this idea into a thesis. And that thesis is this. Because building in Drupal is subject to complexity and carries with it a costly risk of failure, we have a responsibility to not treat it like a commodity. This thesis is the core of what we're going to be discussing today. So we're going to break it down a little bit. So first let's talk about complexity. And we're not talking about how Drupal is complex to use or complex to configure. Drees talked about the core initiatives to address these concerns at the Drees note just yesterday. And personally as a developer I really don't think that they're an issue. As a company we've built a base build called Paragon to spin up sites quickly. We happily use Composer in configuration with no problem. And we're not scared by the API and object oriented programming changes in Drupal. What we're actually talking about is that Drupal is complexity ready. So let's say that the average website is a square hole. You've got a lot of tools that can fit inside that square hole. Now the complexity comes in when you have a slightly different shape to your hole. And solutions that previously worked filled that square hole might still fit in there but not fit the shape perfectly. Some parts are still uncovered. So what we're talking about, the complex part of Drupal is its extensibility. Drupal is not complex but it's subject to complexity. And with the advent of Drupal the complexity is now nearly limitless. We now have the ability to integrate APIs, interface with systems, go headless and provide value through this complexity quicker and easier than ever before. You can still build a simple Drupal site or you can build a complex one. It's really up to you or more accurately up to what the needs and requirements of the project or the ambitiousness of the client dictate. Since Drupal is so customizable and capable it can be built to fit into a company's digital ecosystem which may be very complex. That's what we're talking about when I'm talking about complexity. Anyway, due to this ability there's a complexity to the user experience and some deeper development requirements that led us as a company to realize that there is a floor on the level of complexity of the website and the web project that can be built in Drupal. If a project is under that level of complexity it probably makes more sense to build it in a tool that isn't built for complexity. If you only have a square hole maybe it makes more sense to fill it with a square peg that already just fits in there. You should seek out the weirdly shaped holes instead of filling square ones. So back to our main analogy here of the brain surgeon. The brain surgeon goes through all the same anatomy classes as any other med student but then she takes a few more years of schooling to specialize in the brain, specialized schooling. You wouldn't go to that brain surgeon if you had a sore throat or needed a tonsillectomy. It's overkill. She's going to charge you too much and really honestly going to your everyday general practitioner is going to be better because they're better at the diagnosis of sore throats because they see them 100 times a day. Yeah, so as we kind of continue to break this down Joe just spoke about complexity. We're gonna kind of talk about each of these sort of bolded areas of our thesis to make a little bit more sense of it. The next one is this idea of a costly risk of failure. And so in Drupal development, it's pretty costly to mess up. Not as costly as in brain surgery, which is life or death but it's high stakes. A lot of times, so I'm on the business development side a lot of times when we meet with new clients that are looking at a full rebuild and or replatform into Drupal 8 it's because they've got a new CMO that's come in and they're trying to shake things up and they're trying to make a name for themselves and really innovate in their industry. And a lot of times the website is sort of the only portal that a user has or the most important portal that a user has of seeing what their brand is and kind of relating to that. Oftentimes it's a website is at the center of the digital ecosystem for the entire brand. So their marketing automation is hooked into it and they're gathering leads and all of these things are happening. And so it's a lot on the line and it's a lot to sort of have on your shoulders as an agency or as CMO that's coming in and shaking things up. And so the risk of failure is costly. It's not so much that it's necessarily high but it's that it's very costly and something that could go wrong probably will go wrong and you need to have a plan sort of to adapt for those things. So that's the idea of this costly risk of failure part of our thesis. Regarding the responsibility portion, doctors and surgeons have this very heavy responsibility because these things are true for their profession. They have the complexity and they have the costly risk of failure. And so I can't as an individual that's not trained in medicine administer care to myself. I can't perform brain surgery on myself. And so a doctor has what's called a Hippocratic Oath right that they have to take this responsibility to their patient for this complex thing that they're trying to administer so that there's a level of trust and understanding there. And we find that in any profession where there's a high level of complexity and a costly risk of failure, think about a financial professional's fiduciary duty, the same thing. And so we would argue that Drupal professionals need to hold themselves to a similar standard and not cut corners when they're administering services to a client that either they can't administer themselves or they've trusted in you to administer as an agency. And finally when all of these above things are true, complexity, high cost and risk of failure and a responsibility, the service that you're providing is no longer a commodity and it shouldn't be treated as such. And this is the reason that we all sort of reacted the way that we did intuitively to the rather goofy example of the brain surgeon that says they can do it for half the cost is because you have a scenario that creates cognitive dissonance. You've got a professional saying, I am going to commoditize my service to you and I'm going to sell it short and say, anyone can do it, I can do it for cheaper and I can do it just as well, which everyone is going to call bullshit on, right? No one's going to believe that. And so we would argue that in the same way that that made everyone feel a little uncomfortable and if that was a real scenario, you'd feel very uncomfortable. We should all be feeling a little uncomfortable about the idea of providing Drupal services and building in this very subject to complexity CMS that we all love when that's the case. So, go ahead. Yeah, so this kind of led us to this, what we believe, you know, talking about the thesis and here's what we believe. We believe as a company that we all have a responsibility to not cut corners. So you don't go cheap on your brain surgery. You shouldn't go cheap on your Drupal build. We believe that Drupal is built for ambitious digital experiences, not necessarily the simplest sites out there. And we believe that we, not just us, but all of you are the Drupal experts. You can leverage the knowledge of Drupal to sell the complexity. You're the brain surgeons, so you should go out and sell some brain surgery and stop trying to treat sore throats. Most importantly, we believe that embracing robust and custom solutions over cheap, quick ones, planning over doing just the lowest bid and building fewer but much more ambitious digital experiences instead of simple, easy to copy marketing sites is really the way of the future. So, you know, we used to sell Drupal like everyone else. We were building simple little brochure sites, trying to sell it as the cheapest solution developed as quickly as possible. We weren't selling ambitious digital experiences. We were selling mediocre digital blandness. And in the last few years, we've changed our approach to selling, to planning, to estimating, and most importantly to development. Away from this, we'll do it fast and cheap to, we'll build this better, make sure it's feature complete, hit our estimate, and provide the best value. So as a result, in the last couple of years, we've increased our billable rate significantly and saw an increase in business. We've increased the proposed scope of our projects and saw increases not just in gross but also in net profits. We've been able to provide our clients with more value. We've stopped treating Drupal like a commodity. We stopped treating our sites like something that anyone can build and copy. And apples to apples comparisons which only have one distinguishing feature, which is cost. Yeah, and so we don't really want this to come across as preachy or as a pitch or anything like that. But the idea is that there are these sort of two different ways that you can think about Drupal and administering Drupal services which Dries really alluded to when he talked about creating ambitious digital experiences. And we think that if the community as a whole sort of followed this idea of let's think about Drupal in a sort of a different way and administering services in a different way, it will change all of our behaviors. And as Joe kind of alluded to, as we've implemented these things as an agency and as a sales team, in the last couple of years that I've been a part of the company at Elevated Third, we've really been putting these things into practice. Like you said, we've seen a lot of very counterintuitive things like raising your hourly rate or increasing the scope or total size of projects that we take on and having different client relationships. We've seen these things turn out very positively for us and ultimately not for us only but for our clients which is the most important thing. And so they're getting the most possible value as well. And so here we wanna kind of go through and talk a little bit about the different behaviors that you might take if you have a commodity mindset thinking about something not as brain surgery it was more of like a sore throat or a tonsillectomy and then thinking about things in an ambitious way in a brain surgeon's way, sort of in a consultative way. And so these are sort of the commodity behaviors are gonna be here on your left side and I'm bad with switching myself around. And on your right side, the consultative behaviors are gonna be kind of running through. And so really in a commodity mindset, like I said, it's everything's a tonsillectomy. So a lot of people in this room have probably had their tonsils taken out. It was a pretty simple procedure. Nothing really goes wrong very often. You get some ice cream at the end of the day and you go home and everything's fine. Whereas on the other side of it, consultative behavior, it is thinking about it as brain surgery. You have to have a plan. You have to be ready to adapt. You have to have things that are ready to change as you're going through the project. On a commodity side, you're set up already for sort of an adversarial relationship with your client because in a commodity world, as soon as you're talking to a customer, you're negotiating on price. And it's a low trust relationship because in a world where every widget is exactly the same, a commodity environment, if my price is higher than somebody else's price, you're going to assume that I am being untrustworthy or I'm trying to gouge you or I'm doing something that's untoward as far as establishing trust in a sort of consumer to agency relationship. But if you're thinking in a consultative way, you're thinking of your services as a collaborative way to find the best possible solution and provide the best possible care, you're invested in your client's satisfaction and your client's happiness. And it's a relationship that's built on trust because your client knows that they can't do brain surgery on themselves and they shouldn't and they're putting their trust in you to perform it. So the first of these two different types of behaviors that are sort of contrasting with each other is an idea of bulk versus efficiency. So in a commodity mindset, you're thinking about things in bulk and each commodity is more or less the same as one another and so things are standardized and they're generic and each of these things that you're creating, you can do if you standardize and generic and make them generic at a faster rate and at a lower cost and there's only one size and it fits everybody. But in a consultative mindset, you're finding this sweet spot between quality and speed or quantity, which is reaching the state of efficiency, which is providing the client with not what just what they think that they need, which the requirements they give you or their RFP that they give you, but you're actually kind of digging in deeper and you're explaining off options that you have and you're giving them what they actually need, which is the best possible care and it's something that's collaborative and it's not just a low trust relationship of let's hold this one up to the light and make sure it's the same as the other one and why are you charging me more money? Yeah, so and I've been with the company for quite a while, so I'm going to provide a little bit of background and some of the developer examples here. So we used to have a real adversarial relationship with our clients, but their future requests, their budget, and therefore their value. The client would come at us with a list of requests and a lot of times if they're out of scope, we would shoot them down or deny them because we were trying to build as many sites as possible within our lowest bidder budget that we had. For example, one time a client came to us and they wanted to customize commerce checkout process. Now to save hours though, we convinced them that their budget was more important than an improved commerce checkout UX. So we actually advocated for worse UX, for worse experience because it fit the budget. Getting out as many sites as possible was more important for our company's bottom line than building something excellent and providing the client value. But now what's happened is that the most important part of our process is ensuring that we're providing the best value to the client. And if that means that the client's commerce site requires a more complicated UX, something that isn't possible without of the box commerce, we actually build our estimate with that assumption and build for efficiency. So our bid might be considerably higher than our competitors, but the right client sees that we're thinking not just of the requirements and needs, but we're providing a valuable service. And so we're coming in, we're doing more than just coming in with the lowest cost. We're building for efficiency for them. So this idea of sort of coming in at the lowest cost leads us to this next point, which I assume that probably a number of you, if you work at agencies, there are plenty of you that do fix bid, our elevated third is a completely time and materials agency, and we've seen that it works for our clients. And so we've kind of have this idea that thinking from a commodity perspective, you're going to take on projects with a fixed bid. And when you think about it, fixed bid is a pricing structure that it's inherently sort of assumes a commoditized process because the only way that you'll actually be able to completely accurately guess how much money and how much time and how much effort it would take to deliver a project from end to end without having gone through an extensive discovery process, without getting under the hood and understanding that on a deeper level. It's only possible if you think about it as sites are the same and we crank them out and that's all we do is just the same process over and over and over again. So you're able to pull comparisons and things to create your estimate and that's just how you're developing. In a time and materials mindset with sort of a consultative mindset, it assumes that you're going to be building software, which is subject to change and evolution as the project progresses. And it's something that allows a long-term relationship to really be created where innovation and sometimes even a drastic project scope change can be sort of encouraged in the course of the project. And we're always looking for ways to add value as opposed to ways to cut the costs of the work that we're doing. Yeah and one of the worst parts of the commodity-based bids that we used to put together was of course running into things that were out of scope. You know, my experience, just about every large-scale project will have some kind of out of scope surprise. And under a fixed bid, these out of scope items inevitably became points of contention, an argument with the client. We didn't want to provide the value, which is what was going on, because under the fixed bid project, it didn't make sense for our bottom line, and so we're fighting the client. On one project, we realized in QA that we had missed this huge sizable section that was kind of mentioned offhandedly in the proposal, but hadn't made it in the assigned SOW. And it was an essential part of the site. But because we were already close to the end of our tight, really tight fixed bid budget, we had to fight against including it into the project. And because it would have significantly impacted our bottom line. And that's not providing value to the client, and it's not doing yourselves any favors. Because really, if you have something like a $200,000 project, what the client wants is a $300,000 website, and you're trying to build a $100,000 website. There are some clients that like this fixed bid because they don't have to trust you. They have a document that they can throw at you. But you risk missing out on opportunity. When somebody thinks of something that adds value to the project, if you think of something that adds value to the project, in a tie-in materials mindset, you can actually be nimble and react to that. You can actually provide better value to your clients. Being in a fixed bid budget and not providing that value isn't positive for anyone. Client doesn't get what they want. We sour the relationship just to pay our bills. And the worst part is that a vast majority of those at-a-scope requests never show up in the proposal or statement of work. They just come about naturally. You find them, somebody finds something missing and brings it to the team's attention. And no matter where it originated, under that fixed bid mindset, every single one was a problem for the budget and we'd have to push back on it. It was never an option to like build an ambitious digital experience. So instead, we switched to tie-in materials. Suddenly paying for new at-a-scope tasks was moved back to the client to have a concern about and it became a concern for the whole budget and timeline and not just ours. And this actually changed our relationship immensely and changed the way that we worked immensely. So conversations suddenly shifted to, we know we want this, but we have to find the budget. It was no longer, we want this, find out how you're going to do it within your budget. It's let's find out how we're going to fit this in the budget. The client began treating us as collaborators on their project and not adversaries. Seeking your best advice on how we could best implement something that they had missed, that's really key. So switching to tie-in materials, let's stop worrying about the budgetary side of the scope and focus and instead focus on the value that we provide to the client, the value of that scope. So as I kind of alluded to earlier, again in this mindset sort of related to the time of materials versus fixed bid mentality is this idea of just running pulling comps, rough comps versus a discovery and validation process of working with a client. And so if every site is the same, it's easy to assume that your experience with one issue or integration or project is going to be the same as your next experience with that issue or integration or project. And you can just present them numbers from the last time you did it and I'm sure you'll be fine because we did it before and it was the same and there's really no need for any more consultative or custom of a process. In a consultative role as an agency, you're anticipating this complexity. You're a brain surgeon who knows that things can go wrong and change, can and will happen in the procedure and that's sort of the nature of it. And you will make a plan and you'll plan for that plan to eventually change. That's what doing a discovery process really affords you. You gain information from the client in discovery and then you need to go and validate that information through your own research and get it to gathering your own data. And so we often perform a site audit and have our developer go in there and actually make sure that when they're telling us this is how our website is structured and these are the integrations that we have that we believe you but we're gonna check as well and make sure that everything is sort of up to best practice because you say it is and everything is kind of working the way that we would expect it to because it's just very costly to have a developer sort of take a wild guess without verifying and planning for these things. And the same token that should be a paid process because if you're not paying your consultant to look into these things and verify this information through a paid discovery you're gonna get the B team or no team at all to look into this. You're going to try to do it as fast as possible. Because as an agency doesn't matter who you are you're trying to balance your risk and your cost and all of these things and so it makes so much more sense as a paid engagement to ask that a developer from the A team from a team that's gonna be on the implementation of the actual project take a look at it and give you some sort of deliverable give you an audit that is going to move things forward in the project as opposed to uncovering red flags when they're actually working on the code and they're trying to improve and build the project. Yeah and you know as a developer rough comps were great on a brochure wear site for little one off marketing sites and making a quick copy of something that you've built before and that's how we used to do a lot of things. We didn't put in a paid discovery so we're doing fixed bid and we'd have couple hours to put together an estimate based on what we've done before for somebody's site. And this really falls apart when you build anything ambitious. And as an example I once estimated an SSO for a customer based on another different SSO that we had built before. You know making a whole bunch of assumptions based on some previous experience that had little relation to the client's site. And looking back on that it was crazy it's insane. But my goal was to meet the client's feature request and give them a rough budget but that they could approve in as little hours as possible because no one was paying for it. That was just going down the drain. So we tried a couple hours, we'll make them an estimate. So we provided this huge range of hours and there's a problem with that as well because if I say something's going to take 50 to 100 hours the client's going to look at that and they're always going to assume that you can do it in 50 hours. Anything over that 50 hours is my fault. No matter how many I could come in at 80 and they're still going to be like well but you didn't do it in 50. And so even if you do come in under budget it hurts your standing with the client. It hurts your trust with the client because suddenly instead of investigating what you've done or investigating what you're supposed to be building you've just shot something off, said it's going to take me between this and this based on what I know about it. And it hurts everyone's, it hurts the whole project, hurts everyone's part of it. So instead taking responsibility to know the technical aspects of the project puts you back in a position of respect and trust with the client. If you know all the possibilities, all the various disparate parts of what you're building you get back to that point. So in the last six months I bought four different SSO integrations and everyone went through them, every one of them went through an extensive discovery process that was paid for. We spent time investigating identity providers, APIs that the SSO provided, working out user flows and at the cost of those hours up front we're able to deliver a much more nuanced estimate with higher certainty and the client is actually happy to pay those 80 hours because then the range is only within a couple because I knew all the different parts and we set ourselves up as the experts and set ourselves up with the client as in a position of trust. So when it comes to assembling a project implementation team for a website development project you have these two different behaviors as well. So on the commodity side it's sort of easy to throw something together because the commodity is the same every time. You're starting to see some recurring themes. There's no need to plan and match skill sets. Everyone on your team can do all the work the same way everyone that's a developer can develop on each and every site because it's all the same work and we can just pull somebody off the bench and have them start is really a commodity mindset on a consultative sort of mindset if you're a consultative service provider you think through the plans and you think through the team and you think through who has the right set of skills who has experience in this industry or this project or something similar and you plan out their schedule well in advance you make sure that they're available for this project and they can start and you undergo the discovery up front with the right players in the room from the very beginning and ultimately move them on to the project team later on. Yeah, and this kind of relates back to what I was talking about before. The City or Pants team really came about because we didn't do a really great estimate process. We had rough comps so we've got somewhere between 100 and 300 hours that we need to spend so you try to allocate what we thought was the agile process the least number of resources to make sure the project got done and only allocating more when the project started going south or when we suddenly realized this is going to be a 300 hour project instead of a 100 hour project and because we were trying to finish sites as cheaply and quickly as possible the less people on something the better. So when things went wrong we were never prepared timelines could suffer with the littlest bit of chaos and once again we were in an adversarial relationship with our clients because we just did everything by the seat of our pants. So what happened was what we realized is much like that brain surgeon a solid project needs a solid team the entire team. So resourcing became an important part of our process and as part of that discovery we're also planning out resourcing usually months in advance. It's actually a lot like Moneyball so instead of like one or two superstars in every project hopefully that project actually gets the superstars we actually built a project team composed of people's strengths or people's strengths and weaknesses because one person can't finish the project alone but the team provides great value and so we've switched from just throwing people at it and then throwing people more people at it in a very unplanned process to this very much more almost seems like waterfall still agile process of making people making sure we have the right people at the right time. So another thing that we've really worked on especially as a sales team is this idea that Drupal really isn't always going to be the perfect fit for every project. It's a very specific CMS it has very specific use case and that's okay and we should embrace that and lean into that and that's really been a lot of what I've done as a part of the sales team of Elevated Third is a lot of my day is telling people you don't really need Drupal in fact I've had a couple people that have called and have asked that we build them a site on Drupal even though it's not a good fit and I've just told them you really all you need is Squarespace you just need somebody to pick up the phone and call you and you don't need any integrations so don't waste your money working with us. And so a commodity mindset and I realize too I assume a lot of you are agency people and work in the real world in not the most perfect world where you sometimes have to take on work anyway and it's just a product of necessity at some time but when you're starting out as an agency you have to take on all these different projects but as you start to get to a point where your cash flow is working out and you've got a good team and you can be a little bit more picky it makes sense to not just be a hammer and treat everything like a nail and just assume that at Drupal is sort of the right fit for every single project. So as a consultant yeah you're thinking about this particular use case is Drupal the right fit? Don't fit a square peg into a round hole because clients who need Drupal as we've come to find really need Drupal. They have this idea of how they want their website to work or what integrations they need and how they wanna generate leads on their website or whatever if it's kind of a B2B client and they usually can't find anything else that exactly fits their needs and so when we have a project that's a good fit for Drupal and we talk to them about why Drupal's a good fit and they agree and it works for them they walk away saying man I'm so glad I did this on Drupal and then they end up referring other folks to us who really need what we do and a happy client just kind of creates a happy positive net promoter score which is just so much better than building sites that don't need to be built in Drupal. Yeah and a lot of this is also about building trust and a great collaborative relationship with their client and being the Drupal experts if you're building in Drupal you should know what you're building because there's a time that we would take every client that passed in front of us. I've built some really crazy stuff. iPhone apps, I've built PHP like little mini sites and that's great and we also would shoehorn Drupal to many things that it didn't fit into little tiny static micro sites that were never updated there's no reason for that site to have an admin UI and we started thinking more about it that we're trying to position ourselves as experts we're not an expert in iOS app design that's somebody else's vertical but we know a lot about Drupal and if we want our clients to trust us if we don't want to just treat it as a commodity whatever comes in we need to buy and we need to sell and we need to have them pay us that instead we're really selling something that is worthwhile and we're making value and that it's valuable to the client it makes much more sense for us to just focus on Drupal so instead there are times that instead of building those things that could easily fit on WordPress or Squarespace or some crazy Unix application that no one's ever going to see we're really tuning it down and tuning our workflow just to work within Drupal and really to focus the team on what it's good at because we found that the market for Drupal is large and the market for solutions for people don't care what technology they use as long as it works is probably even larger but when we build the site for someone that really truly needs Drupal and that it really fits for them and all the benefits that it provides we actually see happier clients who are net promoters for us and who send us regular referrals which you can probably speak more to. Yeah, cool so yeah I think just ultimately this is sort of the sum it up right to talk about sort of how Drees has spoken about Drupal if you think in a commodity way you're thinking in brochure where sites and if you think in ambitious digital experiences you're being more consultative and brochure where sites are a commodity digital, ambitious digital experience aren't a commodity it doesn't really matter who builds a brochure where site or how and the biggest concern for brochure where sites are usually things like SEO and sort of the marketing that you're doing and your user experience and your level of complexity are dependent really just on how much it costs to add that on. For an ambitious digital experience a poor build with cut corners equals a poor experience and so good UX, third party integrations data gathering, personalization all of these things are part of what makes an ambitious digital experience and so we should build accordingly. So just to kind of recap and show you guys this thesis again we've explored this we've kind of talked through each of the parts of the thesis and then we've talked through our commodity and consulting behaviors and our mindsets and really how we think of things that elevated there and we kind of wanted to share a few takeaways that we thought might be helpful for you all if this is something that whether you're an agency that's kind of trying to figure out the best way to sell Drupal services or operate in this world or if you're someone who's looking to purchase a Drupal website or work with a new vendor just some of the things that you might think of as you kind of walk away. Really we think that instead of shying away from the fact that Drupal isn't word space I'm just gonna leave that word space. We should embrace that. We should embrace the fact that Drupal is different. It's more complex. It's able to create these ambitious digital experiences and we shouldn't sell short what we can do with it. We need to be proud of the fact that we can build ambitiously. Secondarily as an agency mitigate this costly risk of failure and as an evaluator of Drupal services make sure that you're working with an agency that's mitigating this costly risk of failure. Make sure that you're assessing your clients as an agency and that you're going through the proper amount of discovery and planning. Validate your assumptions for this specific use case whether Drupal is really the right fit. Make a plan for the project and then plan for that plan to change just like in a brain surgery and take an agile approach and build it into your process to allow for this. Next we would implore you all to accept the responsibility of if you're an agency of really thinking of this as a profession, right? We're responsible for the outcome and the things that we provide to our clients who've trusted in us and just like a doctor who has to take a Hippocratic oath we need to take our profession seriously and realize that we have a responsibility to really do this right and the people are depending on us to do so. And then finally just don't treat Drupal like a commodity. Put yourself in a consultative frame of mind and don't choose the cheapest brain surgeon or be the cheapest brain surgeon. And at this point I'm sure you're all saying like these ideas are very theoretical and you've sort of been up here pontificating about how we should all behave but we live in the real world, right? There's not always a chance to make these things that are very ambitious or sort of ideal state actually happen. And so part of what we wanted to do and we have plenty of time for us to do this is that we wanna hear from you. We wanna know, you know, because again, I'm sure a lot of you are at agencies or at companies that have done a fixed bid before and have been very happy with the results. This is how we do it and this is how we have started and we're not fully there yet. We're starting to move ourselves more into this consultative mindset and trying to sort of reconcile some of these dissonances between the two but we really wanna hear from you and we want you to kind of poke holes in this and tell us that we're wrong and tell us that I have a better way of doing this and this is my experience and you're kind of just blowing smoke about this idea or that idea. And so we just really want this to be an open and sort of collaborative discussion because the idea behind this is we kind of wanted to ruffle some feathers. We kind of wanted to put this out there and say this is an ambitious way of doing things and this is the ideal state but obviously reality has to happen. With that said, at Elevated Third we have employed almost every one of these things that we've said or we're working towards those things and we've seen really, truly positive results as an outcome here and so we'd like to invite you all to use the mic and come up and talk to us and let us know if you have questions about the talk in general but also just what have you seen about sort of each of these different behaviors and do you just completely disagree with what we have to say in which case we invite that. And then before we do just a quick note again we're Elevated Third and our booth is 306 so if you do want to talk offline with us and meet us at the booth, please do come by and here's our talk survey page so you guys can leave a comment and rate us so please do that as well and I'll leave this up here as we go through Q&A and discussion. So if anyone has any thoughts or reactions or wants to tell us off, please do so. I'm from a perspective of an agency. I work in an enterprise environment with a team that has employed the strategy from the previous group account and there's no estimates to talk about that. I went to that, yeah. So we try to do that as much as possible on our team so in regards to choosing a different platform we have done things like show the WordPress for a brochure wear site where later unforeseen amount of time goes by they want to, with the same brand, make it become something more ambitious and at that point does this approach kind of act fire on a project like that where it's, you basically have to rebuild it into something like Drupal? I can just quickly jump in. I think as far as, especially from the sales perspective and I'd like to hear what you have to say to you but in almost every case where we're going through this consultative sales process with a client I'm asking them that question. I'm saying, what are we doing with this site in three years? And that's partly because I want to know are you going to Drupal 8 with it? Are you, if you're building in Drupal 7 or are you planning to upgrade it? Are you planning to take it somewhere? And so I think it's also partly our responsibility as an agency to know the client and to say like, this is a client that may have future ambitions. They may get an investment of capital or they may be growing rapidly or something like that. And so if you have a B2B SaaS company that's about to get acquired or something like that like you probably want to anticipate that they're going to need a more scalable solution. And so if scalability is a priority to them then Drupal does sometimes make sense in those smaller cases. But I think that's part of what our discovery process should sort of uncover is like how much of a priority is scalability for you and should we build that into the process and maybe you pay a little bit more for a more complex or like available to be more complex solution now when WordPress seems like a fit for that future state. But... Yeah and from the developer perspective there was a point where we were kind of doing the same thing with legacy sites because we do have a lot of clients that we've had for many years. Some from, you know, I'm still on Drupal 6, Drupal 7 and occasionally they'll have features that come up that they want to implement. And for a long time we would try to treat these as purely agile. We were just like, okay we'll build this and not necessarily think about what we're doing in the future. And it's still true of like smaller things but if it's something larger like they want to add on an entire big ambitious piece of the website we'll actually then pull that back into a discovery process and try to figure out maybe this is time to rebuild. Maybe this is time that you're not using three quarters of the stuff that we built for you. Maybe it's some time to shrink down. You know, doing something like that. So I mean I feel like there is definitely a spot for that and in a single software, a single piece of software DevShop that's much easier to do with no estimates where you know, you kind of know where everything is rolling. We obviously have a lot more a lot more irons in the fire. And so we definitely almost have to do estimates on everything only because of the resourcing because we need to know like which developer is going to be used at which point like often to the future with so many clients. So yeah, it's a necessity process. So and that's helped a lot because you know, doing it where we were just kind of rolling with whatever came up on every website. There was some, there was times where we where we just couldn't do something. We had to tell a client, well, it's gonna have to wait because we didn't have the resources to do it. So yeah. That's a good question. Thank you very much. Yeah, thank you. Okay, so getting paid to do the discovery makes a lot of sense in that low risk. And then I'm starting to get what you mean by no estimates. You're just basically building by the hour. You say, hey, we've got a little piece of work. Yeah, it's 20 to 40 hours and there's something you can do it. And then you just do it and you build them. Is that what you're basically saying? Yeah, I think that's... No estimate theory? Yeah. Yeah, I think, yeah. Yeah. Well, I don't think that we're a proponent of that, of that theory at all. As soon as we get it in a little bit, well, actually, it doesn't matter how big you are. You need to know if you're talking to a client and you're gonna be done in time because they need that project to start. Yep. They need that project to be alive by a certain time. So no estimate. Suppose there's a way to work if you have lots of resources and you can just pull from 100 different people at any time and you have a lot of empty resources. Yeah, if I remember correctly from that talk that was a firm that just was a straight just development agency. And I think they worked in a very purely agile format where there was just line item user stories for every single thing. And that's how they kind of did the no estimate thing as they just said. We have this general idea of a user story and then we think it might take this much time and we have a pool of 100 developers and so we just kind of throw somebody on it. So I went to that talk, I thought it was interesting and very sort of like rousing talk as far as thinking differently and kind of putting your mind in a different state. But we don't employ that strategy. We do an estimate for literally everything and that's how we're able to be time in materials because we are able to say this is what we expect. We're pretty close most of the time when we estimate to what we actually perform and that's how clients who are more comfortable with a fixed bid or obviously everybody needs to know what they're spending on the work, right? Has to have something to bring their boss to say get this budget approved. That's how we navigate that. Yeah, because of our discovery process I've actually seen more projects come in under time than anywhere else I've ever worked. I mean, it's pretty amazing that when things come in and I've been on a couple of projects where we've added features that like nice to haves the client had because we had this discovery process and we actually made it, we did it well enough that everything came in nice and smoothly which is a big change and that was a paid discovery like the client paid for it and we positioned ourselves as a place of trust. Sorry. Okay, no worries. I wanted to ask a follow-up question because I know there's something behind me. So what percentage of your contracts are fixed prices in? Zero percent. None, no. We are completely time in materials agency and we have been for probably about four years I think. Yeah. Yeah, so if someone says it's a requirement of our. We started about four years ago and I think it's been the last couple that we're finally like completely, yeah. I've only been with the company for two and a half years and so I only have that amount of context but I've never sold a fixed bid project in my entire time at the company. What do you say to the people who say I need a fixed bid for them? Not to exceed number. So in every case I've ever and I talk about this a lot so a lot of people say well I need a price and I say great I've got an estimate for you here's that estimate when our developers have hit that amount of work and when our account manager has managed to that level of the project which by the way is completely open to our clients they see the burn down on a daily, weekly however much sort of cadence they want to be able to see it. We will stop work. We won't bill you a single dollar over your budget and we'll tell you exactly how much sort of time we have that we need and so the entire time we're reprioritizing their project. So our account managers are really good at this. They sit down with the client and they say on their weekly status call hey we're burning hot here, we're doing well here and this is how this is going and then they go okay cool. We're burning too hot here so we need to deprioritize some other level of the project to put it to a phase two do something else but we're always shipping an MVP we're always shipping functional fully QAID software we plan ahead for that and we build a little bit of extra onto the top of the hours that we estimate to just in case something goes wrong but this is what we were talking about where it's not a commodity mentality because if you're going through brain surgery and something goes wrong you don't want the doctor to stop because you don't want to have to pay any more money. You want them to fix the problem because you came into the brain surgery wanting an outcome and that's so important when you sit down with a client and you prep them from the very beginning to have that mindset. With you this is a journey that we go on together and it's not for everybody. We turn away clients sometimes that say I don't care if that's a great pitch but we don't want to work that way we want to work fixed bid and we say great good luck to you because we don't want that business and it never works out for either party in our experience. And so we we found it it's just a way better way to work. Thank you. Someone related to that actually so I've been trying to do this for a couple of years with mixed success. Standing back. I run into a couple situations and if you have any feedback or anybody else has any ideas one of the things I run into is in a yet new scenario where what's called the BT-98. They're really cool we'll do everything in the world versus the local real estate now on the G. Here's a fixed price here's your let's make it wow. They always seem to go for that money always seems to fan us everybody faces that and when you deliver that disappointed they did this. A how do you react to that because I'm in a low net promoter scores and if I died in the second one because they might be related the second part of that is when I go this direction. Today we'll find someone else in this room or in the hallway or out the sidewalk or somebody who need to come to triple time who is going to do it cheaper and I lose the business all together. Yeah that's a bad thing too so I understand like I get it and I have turned down business as well but at the same time you've got to stay in business we've got to keep it. Totally. That is the first thing to balance those so any input or advice you guys have if you appreciate it. Well for the first part I think a lot of that has changed with our discovery process and that I mean you know trying not to put the A team on everything and spread people out part of the discovery process is that we've kind of shifted a lot of those 18 people into discovery process so our director of development used to do a lot of development he was part of the A team. You know if something was you know there's some crazy thing that needed to be built he was the one to do it. And what's instead shifted was that he's a lot of times building out architecture and laying out his thoughts as part of that paid discovery process so for another developer to bring it up on I mean I hate to use B team and A team but like a junior developer a lot of times more complex things the site architecture has already been worked out by members of the A team and so it kind of makes you know a B team member like an A minus because maybe some of the things that they wouldn't be thinking about that they wouldn't be planning for had already been planned out and paid for by the client so I think it's more of like how we're thinking about the discovery process and the deliverables there it's more than just a deliverable for the client in terms of like this is what we're building you and this is what we've discovered it's also that we're making internal decisions about like how this should be architected and so it's because we have run into some of the same things there's always going to be a limited number of you know people that can do certain things I'm one of those people with like SSO and API integrations but I've actually helped a lot of my co-workers that haven't done things like that before by laying that out and specifically kind of you know look at this example code that I built before this is how we did it before these are the things that you that you should be thinking about and then scheduling as part of the discovery process realizing oh maybe this person hasn't built this before so they're going to we're going to require 10 extra hours to work with Joe so that he can work this out and so it's I think it's part of that's part of doing the 18B team kind of or the dream team and the strong team the smart team yeah I just want to quickly rephrase the other part of your question or like repeat it back to you so I'm sure I'm understanding what you're asking so basically you're saying like I go into these processes I give them sort of these these two options of like we or or like they're they're saying like we could do it on the cheap or we can do it the as you called it the wow or the whiz bang way and they're always choosing the cheap option right is that underpin what you're saying okay yeah yeah yeah right budget sir they want to know upfront yep they tend to go to build in that wow factor totally when they're only they're capping me on how much they're willing to spend and when I go in a bit of those like I said that's back to the second question someone else is promising on the wow bang you and I know people who have experience know they're not going to deliver it right matter they've got the deal they've got the sale and then when they fail sir they chalk it up that they don't care about NDS stores right right right we're in this for the long haul we do we have you have good luck with this in the long term and and maybe kind of related and I'm looking behind me and I show nobody's waiting when you give them when you do your discovery approximately what percentage of people don't follow up and say yeah just we we always allow people the option to leave us after discovery and I think we've only had that happen one time and it was just because they decided that they didn't have the ability to take on the project at the time it was just too much so yeah well no and I want to address that because I think it's it's a fear that we all have right it's and it's totally valid but but I think that the most important part is like what caliber of client do you want to work with and and also bad IT is super expensive right and so that's kind of what I talked to them about often and it's a consultative process like they say hey we want to do it cheap this is what we have I get that I I know that you can't find money under the couch cushion but it's not only the difference between cheap and whiz bang and like everything gold-plated it's cheap and bad and cut corners or just like good value like it's not even just that it's wow factor and like let's be ambitious which I know we talked a lot about but it's also just like can you build it in a way that in one year from now you're not looking for another one because we have that come to people come to us all the time and say I had this site built on the cheap and now I'm I'm in trouble because I have a problem and I can't fix it because it's a home-made system and and so really the the retort is kind of hey bad IT is super expensive we're going to do a good job if you want a cheap site and you want somebody to do it poorly and some people can do it cheap and do it well it just it just isn't very often and even the people that are able to do that ever can't really do it consistently because they outsource and they do all these other things and so I just ask if they'd like some if they'd like their site to be scalable and to last and if they want to redesign in a year because it's it's too difficult to use or less than a year then then great you'll just spend that same cheap cost two times and three times and four times so pay for the good IT I think as part of that it's been a it's been a process for us too so there was there is a period kind of in between period there where we were taking still doing fixed bid and you know quick quick easy projects and we started phasing them out and realizing that that we were much better when we would take that project fully estimated and build it out and so I think what what started happening as we as we adapted this more and more and started just making sure that our projects were always being well estimated and had a discovery process I think we've been weeded out by some of the the clients that just want the cheapest website possible and that's good and weed us out so it's and that's part of this is that this was an instant thing it was over a couple of years that we saw like you know we started saying we're we need a discovery process and some people would be like okay you know no big deal we're stepping off and and so that's very true we've so that's we might be just a little bit beyond there I just want to mention I know we're over time so thank you all for coming we really appreciate it if you need to leave I totally understand you want to send us but I should like yeah please do thank you all yeah how did we do RTD yeah so this may not be the answer you're looking for but we just don't do it we used to be you know more open to higher ed government we used to kind of even specialize in some of those but we started to realize that our cost of sale was so high that it just doesn't really make a lot of sense for our business model if you specialize in that business model and I'm a government or higher ed provider then I think it's more about just kind of figuring out your sort of system that you like what is your unique value that is it that you can cut your costs and that's what you're able to do in a you know stand up good IT but do it on the cheap and that's what they're looking for there's a niche for that for sure but I would say like our you know sort of focus has turned to enterprise B2B because they have the budget they don't necessarily make the process so difficult for you but again you know in those cases like if you can just try to establish a relationship with the client themselves so if you go into a blind RFP process and you're not allowed to speak to anybody I always send an email immediately that says I'm sorry but this is unreasonable and we won't be bidding if you were not allowed to speak to a human being and so if they don't let us speak to a human being we're glad to walk away but if they do it's sort of like oh wow like we can have a conversation with them talk about all the concerns and I've had so many cases where I've pushed back on specific requirements of RFPs through email or through a phone call and I've had people and I've said we're declining to bid on this one thank you very much and then I've had people come back and email me and say we're willing to address all of your concerns please bid and so like the people will conform to your process more than you think they will is my experience oh yeah no we can chat up separately thank you all very much sad death we don't offer anything other than your call we just say no thank you okay okay because I was like my question was do you guys have a different to break when you offer some part of that college it's a good question but you are not their professional that I have yes we probably would actually I would assume if we ever did if we did it but we don't do it yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah