 And so, you know, by default, I mostly see bad projects. I mostly don't see good ones. But oh my goodness, I see so much bad Drupal. And bad Drupal is good for all, bad for all of us, because the clients hate Drupal. And usually not because of Drupal, but because the implementation they got. And then as a last resort, the companies start drawing Drupal under the bus, right? Oh, Drupal can't do that. Or that's really hard in Drupal. I'll have to charge you more money. And these things have caused Drupal to flatline in terms of growth. And none of us want to be in a sector that's flatlined. So I come and I talk to you guys because I want you all to be better. And I want you to share this wisdom and knowledge with people. I have no right way of doing things. These are just a way. And you'll find your own voice inside of all this. So who is here? How many of you are with a company of five or under? 10 or under? 20 or under? Wow, that's awesome. How many are over 100? Okay, how many are C-level people? Nice, how many salespeople? Oh, nice. How many project managers? Yay. Now, let me tell you my belief. I believe that project managers should make more than engineers. And all the CEOs are going, wow, I hate that woman so much. But when you see what I expect of a project manager and the authority that you as the owner must give to them, they may not want the job because it's a really big job. So someone tell me why you're here. Like, there's a lot of cool sessions that I'm up against, really other great sessions. Like, what do you want out of today? Somebody. Oh, okay. This is going to be pretty mid-level process, business process stuff. So if you're, yes. Yes, new strategies, great. And who are you with? Oh, nice, okay. So I love WonderCraft because I agree with all my stuff. So that works out great for me. So one of the things that I mostly see is that Drupal shops work on a cashflow basis. Now, who here knows what cashflow basis means? A little bit. So to clarify, it means that I take in $50,000 for this web project. I'm kind of tracking it, but not really. And I've actually burned through all the hours I've sold. But I sell another project. I take the money from that project and that new money is actually funding my old project. And then I don't have enough money to finish this project. So my next new project is funding the second project. So most Drupal shops work on a cashflow basis. And how many of you seen a shop go from five to 25 and then they disappeared off the face of the earth? That's really, really common. And that's a cashflow company. And what happened is project number five stalled. It didn't come in when it was supposed to. And now all of the back debt has caught up with them. So we're gonna cover everything from sales to developer tickets. So we've got a fast journey. So let's get started. So out of the last 10 side audits I've done, the people are actually seriously considering leaving Drupal as a platform and many of them have. They've gone to Jumla. Like how bad do we have to be as a community to lose to Jumla, right? And this is from W3Tech. And this is the growth of Drupal. Okay, it's really shocking and we have to stop it. And the way we stop it is that we get better at Drupal. So how do you break the cycle of cashflow basis? And part of it is you have to know how to manage a project and to actually make each project its own discrete. Come on in, come on in. I have no problems of how to be profitable with each project. It's a project by project basis. You can't throw all your money in a big pot and go, woohoo, I'm rich, doesn't work that way. So I have five golden rules. Wow, should have worked on designing. And what's that contrast? So number one, say no. Too many, too many companies take on projects they shouldn't. Sometimes you think, oh, if I get this one, I'll get this next cool one. It's good for my portfolio, but don't kid yourself. If you cannot win at a project, you do not take it. You might share it with somebody else. You might allow for a subject matter expert to be hired on the project, but you just don't say yes to projects because you can't. And if you don't have business goals, there was a great panel with Jeff Walpole, CEO of phase two and the CEO of Wunderkraut and Deeson and some others. Go listen to that one about business goals. But in short, that's a summary and you can read that on your own. So Drupal alone is not a metric for success. How many of you had a business before you did Drupal? So not that many. So there's a difference between a business that does Drupal and Drupalers that do business. And most of you are in the boat of Drupalers that do business, which means that you're letting your engineering skills dictate and drive your business objectives. And that's not always the best thing to do. It can be, it can absolutely be. But you need to know that you and choose that as a path and a business strategy. And then that's different than being a business that just happens to do Drupal. And so what we want to do is think about Drupal plus process. The other part where people fail and in the last session I went to with Wunderkraut, they talked about failure and the majority of it being 98% being communication failure. 2% being this was too hard for me to code. How many of you have actually said this project, the actual technical merits of the project are too hard for me? How many of you have hated your client and wish they would disappear into a big black abyss? Yeah, yeah, like that's where it is. When I had a shop a long time ago and we started out doing small websites because that's where you start, it was eight hours to build the Drupal site and 32 hours to handhold the client. And I tracked hours like very early on and that's pretty much what it was. And that's why we had to charge 40 hours for a five page brochure site. But customers do not know out of the box how to be a good client. You have to teach them. You have to teach them how you do business. And part of the problem is you don't know how you do business or you don't have enough process to share with your client and you knowing all the tickets in your head is not a process. So your job is to train the client and we'll talk a lot about that. And I cannot make you code. I can come stare at you all day at your desk but at the end of the day I cannot make you write a line of code. How many of you have worked on bad tickets? You don't actually have to, that's your choice. And so one of the things today is that I'm very strong about empowering each part of the development team, the QA, the PM, the developers, to push back and demand the right process so that you can succeed. How many of you like recoding things? Very few, you need to work in support. So basically just don't do development without the docs. And the same for a project manager, like you just stop right there, say we're not ready to move in development, I can't plan my sprint, yes. Yes, we'll go into that a little bit, yes. And then we talked about that. Okay, so there's a gap. The problem that everybody raised their hand on the client and very few people raised their hand on the engineering side is because there's a gap. One is what you know and the other is what the client knows. So the clients know all about their stuff and I know you guys, how many of you are actually engineers even though you're holding other jobs? Yeah, the majority of you. You sat in these long, endless conference calls and people are rattling on about how they do this and what they want for that and all this and you've tuned out. You're like, please just tell me what you want and I will build it. The trouble is they don't know what they want because they don't know what's possible. Like to them, the entire world is open to them. They don't understand where their boundaries are. So they know their stuff. It's actually your job to figure out what their stuff is. Like that is actually your job. And then you know what you know. But they talk in a language that isn't meaningful to you and you talk a language that is not meaningful to them and that's where the project manager is the translation manager. And that's a combination between project manager, sales engineer, sales person. It's kind of all in that triad and every organization will handle it a little differently. And you've got to create this overlap and it's in this overlap that success comes. Without this overlap, there is no success and you can't have this much entanglement without process. Otherwise they're just all up in your tickets, aren't they? Okay, so I have this idea and I don't know if someone else has coined this phrase but it's where you guys as a team are all standing with your backs to each other and you're all looking out at the project landscape and you're working as a team in a 360 degree fashion. And the reason a trampoline or a drum works is because there's the appropriate tension on all sides. And almost always when I go in to assess a company around their processes, they have big flat spots. The engineers don't push back, the PM has no real authority. It just goes on and on and on. It's all of the things as we grow organically without enough process, we don't know who should do what. But it looks something like this. The PM is at the conductor, they're the central force and they pivot everybody else around them. And so sales comes in and there's a handoff into beginning discovery and architecture and all these different events happen. And that's the PM that starts to be the central point for all of this communication. So when you have this down, you have incredible velocity because now you have a wheel with no flat spots. You actually can go instead of this. This is mostly what I see on projects. Everybody kind of doing their own thing. You have one part of the team, it's like, oh, we built this and it's like, well, it doesn't integrate with anything over here. Design came first. I mean, the litany of ills that happen kind of goes on and on. And they're the same, that's the good part. So everybody is really comfortable in number three. Most people start a project by getting a deposit and starting development. And you can see that there's got to be a whole lot of other stuff. And I think someone said in the last thing and I thought this is so true, there's a misconception that agile means you don't have to plan. Agile means you do a different kind of planning, but it's not a lack of planning. And then if we take those three chunks down and we break it down, it looks something like this. And there's a lot of things that happen before the first ticket gets worked on. And this is where so much falls apart is that there's a complete lack of transparency inside the organization, what they're trying to build. Does anybody do all this? Yay, yay, good for you. The other thing where I've worked with a lot of projects on kind of this budgeting process. If your tickets are weak, you can't ever do a good estimate. How many people know what I mean by that? Yeah, if your developers are not estimating accurately on a ticket and then hitting those marks on the ticket, then you can never do a successful estimate because you never know how long anything takes you. Like, I know that this developer takes two hours to build a view and it rocks. I know this developer will take four hours and we're gonna QA it three times because that's the way we track their tickets. And then in fog bugs it does this magical thing. It knows which engineers underestimate and overestimate. Like, that's pretty wicked. So without estimating and really tracking tickets, and I see owners all of the time using some big global tools where at the end of the day the engineers put in the tickets they worked on with some fake hours and then they're like, I so know what's going on in my company. And they're so pleased with themselves. They're like, oh, I know this, we're at this burn rate and I know I'm this profitable and I look at the tickets and it's like, no you don't. It's a lie. It's a really big, fat lie. So a lot of people say, well, Susan, I can't possibly actually charge my clients for this. It's only a $10,000 project. Well, there's no dollar amount up there, but I'm saying that for every $10,000 you bring in, this is what you're gonna spend and you spend that time whether you charge for it or not and if you aren't doing the planning times, your post-launch stuff goes up to 25% of the budget. Like all the money and effort gets spent anyway. The question is, do you wanna do it in advance and have happy clients or you wanna wait till the stuff hits the fan and they're mad at you and they don't wanna come back? Like that's the question. It's not about whether or not my metrics are right. It's about you either do the planning and prepare and execute well or you do the best you can and you hope it all works. Those are the two options. Does anybody who actually tracks numbers have any different metrics around this? So if you look, engineering, design and theming is only 60% of the budget and the bigger the project, the more you're gonna spend in architecture. So that's a really hard number and clients don't want, how many clients have had, I only wanna pay for development hours? Walk away from them. They are so bad. That is such a bad client. We actually, I was at a company and this was a really big, big international company and they just wanted to pay for a developer and they looked at me and said, we will not pay for QA. I was like, well first of all, are you idiots? But it's like fine. So they paid for an engineer to do QA. Like they paid double because that's what it takes, right? So anyway, so you spend all this time one way or the other and I think this is a real eye-opening thing when you can actually get paid to do discovery, you can actually get paid to do architecture, you can actually get paid to do UX. Like you don't have to sell in one monolithic thing called a project. You can sell services out of it. Okay, who doesn't use Basecamp? Okay, start using Basecamp. That's number one. Who doesn't use a ticketing software? Oh, good, much better. Who's embarrassed to raise their hand on that one? Who uses FreshBooks or some other automated tooling? So how many of you do recurring payments versus milestone payments? Okay, so I don't have time to ask questions. Normally I get a lot of engagement but we get too much to cover. So the reason that you wanna do recurring is that salvage is your cash flow. If you do things based on milestones, you're always arguing with the client whether that milestone got completed. Like if I tell you this project's gonna take me six months, you're gonna make six payments to me. You hold the last one until we're done. That just solves everything. They tell accounting, you're gonna get these checks. Like we don't have to go to the mat at the end of every sprint to say we completed features. Quit making your payments based on milestones. That doesn't value who you are as a company. And those milestones can change. Sprint to sprint. They're like, oh, well, this is some new thing. It's like, okay, well, now what do you do? Or how are you gonna shift those payments? So no milestone payments is just based on time because that's how you pay your people. You don't pay your people based on milestones. Sales, who's in here in sales? So one of the things about sales is your job is to say yes. But I would actually argue that the C-level people need to sit down with the sales people and actually the whole team. And say what is a good sale? And you need to get incentivized to go find the good sales. I don't care whether you bring in a million dollars in business. If it's bad business, we're all gonna suffer. I'm gonna lose 30% of my development team because they get burned out and they hate me. It's not going to make us better in year two. You just gotta go out and kill new giants and it's hard work. But we need to decide what is a good sale for our company? What is our business model? How are we trying to grow? What are we trying to grow? What are we trying to gain expertise in? And how many sales people knew that this client was horrible? Yeah. And you need to have the permission and the authority as a salesperson to say I walked away from this deal because they were bad clients. And people need to go yep, that's exactly what you should have done. Rather than no, no, no, you need to call them back. We need the money. Like you can see if you're getting that kind of feedback of a salesperson, like you're already setting the team up to fail. The one guy who doesn't have to work with them doesn't want to work with them, right? Like sales people can go, I'm out of here, I'm off to the next thing. And even they don't like them. So how is this going to get better? How many of you have gone on a bad first date and went, wow, we should get married because it's going to get better? But that's what we do, right? This client's horrible. But we're going to say yes to them. Sales is the right time to start being the expert on how the business works. How many sales people in here are Drupal site builders? Yay to that one person. So you cannot sell that which you do not know about. So every one of you should be a decent Drupal site builder. You should be able to build content types, build out views, know how image cache works. You should throw in some modules, break a few sites. And then you have the confidence to understand what's getting built. You cannot sell something to a customer and sound like the expert. Your closing rate will go up tremendously once you can talk Drupal. I promise you, I guarantee you. And your team will love you. Okay, so and the reason that comes into play here is because of the features and the requests. You have to know how Drupal works. Drupal does things exactly the way Drupal wants to. And when you start going against the grain and selling features that go against the grain or Drupal, you have made a roomful of people really unhappy. And your client is not gonna be happy because they've taken on technical debt. They didn't know they took on. And we'll talk a lot about that. So anyway, you have to start assessing at the sales, at the first conversations, are the features they're making reasonable within the right timeframe and in the right budget? And you need to start massaging that and being consultative about that upfront. Wondercrow's premise is to say, nope, go away, you can't afford us. It's great, right? And people call that. Okay, so we talked about sales of a web project is not a monolithic thing. It's so easy to sell a site audit. You talk to someone, we have a bad site. Oh, that's so terrible for you. We have so much compassion. Let us do a site audit and explain to you what's wrong with your site. Such a brilliant sale. Maybe $1,200, $800. Maybe you do it for next to nothing, but you get to come back as the expert and you can create site audit docs that go through the whole random list of things. A lot of it's really dead simple. You copy the module list, but you know what? Most people have no idea how many modules they have. So it's a really good value point and you get to know the site. There are sites you should not actually take on because they're so poorly built. You're gonna be responsible for everything. It's the Jenga of websites, right? Architecture, you can sell architecture. Let us do the architecture. And only if you're capable of doing the architecture. And then you're free to move on if you don't think this is a good engagement for you. But you make more margin on site audit discovery and architecture than you do on development by law. So it's not about the quantity of projects for companies. I mean, at the end, yes. But it's about the win and it's about the margin on that project. And it's about you as a salesperson really being the sales engineer, being consultative, understanding how to tear apart their site and talk with them realistically about their expectations. So as a company, you should sit down and ask these questions of every sales that comes in and then your commission gets weighted on the number of yeses. So you bring in a bad project, you make less than if you bring in a good project. But let me tell you, all of a sudden, the good projects are going to really start coming in the door because we've agreed on what a good project is. It's not like you're out there trying to find bad projects but you've never agreed on the distinctions of what makes one project better than another. Any questions? And then after you've decided, yep, this is a good project, this is a good client, you need to start talking to them about what their site is supposed to do. You are going to be the one in there kind of doing the business analysis. And you have to understand what a user story is. You have to start actually, this is the beginning of the architectural document. And you can see how what you're doing now is going to start flowing into the bigger picture. And so it's why it's so important for you to be trained up on Drupal. How many of you have built a whole site and then at the end the customer comes back and go, where are my reports? Yeah, where's all the data? Where's this? Where's that? In Drupal we build two websites. One for the visitor and the other for the content managers and we forget that. There's a whole bunch of stuff missing for people who have to manage a Drupal site. You have to build them a dashboard. So sales is also the right time to start managing expectations. Remember we talked about how the failures are not technical, the failures are communication based. And part of it is they don't know, like if I asked you to go buy me a submarine, how would you start? You'd Google buying a submarine. But do you know anything about the process? Do you know who you have to get clearance from? Do you know how long it's gonna take? Do you know how much you should spend? No, do you know how to test if a submarine is a good buy? No, and your clients don't necessarily know how to work successfully inside of the process. I met with a team and they had this big website they were gonna build and they had like $80,000 left. And I'm like a team of 12 people and at a big department, like why do you only have 80,000 for this project? Well they burned through 980,000, 920,000 of it on a Jive installation. But they knew when they went to the presentation that it would not meet their needs. But as a company, this department didn't have the right to raise their hand and put a stop on the play. So as a CEO, as C-level people, like you have to allow, like when your PM comes up to you and go, this project's at risk for us. Like you have to not go, well push it through and like get all over on them, you have to really stop and listen to them and say why, what's going on. And when your engineering team comes and says I've got a big impediment and I see this as a problem, like these are the red flags and we have to give our teams permission to raise red flags and stop development. It's really, really important. We are all brilliant people in this room and sometimes we don't have the, we have the responsibility, but we don't have the authority to pull that trigger. And then as an engineer, like you have to demand that right. How many of you feel like you really have authority to pull a full stop on a million dollar project? Yeah, very, very few of you, very few of you. So, so yeah. And then the other thing is the reason we sell things in little discrete packets called discovery side audit is sometimes clients seem okay and then it doesn't quite turn out that they are and you can bail. It's good to bail. Like I gave the session, I have a first part of the session and someone ran up to me at the last conference and go, oh my God, I told the owner not to take this because I told him we should say no. And he's like, yeah, we should have said no. So once you see this and you can look at your roster of current clients, if you had the authority to say we should not take this project, how many of your headaches would be gone instantly? And the thing is is that you're selling your hours anyway, sell them to the people that deserve them and you wanna work with. Like it's an opportunity cost. Like you're losing out on something else by being over here in this entanglement. Who knows why I keep telling people to post in base camp. It's tracked, it's transparent, but also it's the best self managing group mechanism because people that will email you 20 times a day and name stupid stuff that just clutters your inbox, won't post it on base camp because their manager is watching. Like it saves you and then at the end, when you post the outcomes of every call and every meeting, there's no, well, you said that you were gonna build this for free. Like that happens, right? Fair amount, okay. So, site audits and discovery allow you to be experts and it allows you to test the waters and it allows you to have a win. There's no downside to getting into doing site audits and discovery. And you are now the expert on their needs, they've bonded to you, the likelihood they'll go somewhere else, pretty no. I've never lost a discovery client. And so a site audit looks something like this and I'll be posting this PDF so you guys can see that. And you can add whatever else is appropriate for you. And then discovery. So discovery means you've got all these business ideas and your marketing team wants this and your sales team wants that and your finance people want here and you've got all these needs, right? But they don't have the, I've never run into anyone that has the budget for all of their future requests. And so discovery is when you really start prioritizing what's important, like what is critical and what can we build in phase one? What's the tiniest component of all your future requests? Given that they're on a budget, can we get out the door that makes them happy? And we don't ask that, do we? Like we like, okay, let's start and then we'll get it all fit in and then no we don't and then everybody's unhappy. You start talking about the stakeholders and user stories. So I work with a team, now these are internal Drupal people. They brought me a three page word document and said, okay, these are user stories. We're clear on what that is. And then by the time I was through with them and discovery we had 12 more users and a lot more workflow. So this is really critical. How many of you feel like you do a good job in the user story part of a project? Not enough of you, so good on the people that do but not enough of you. We don't move on a project without user stories, yes. Why emphasize user stories? This is part of that communication gap. Like they're not gonna understand anything that you're doing in Drupal but if we can agree on who's coming to the site and what they're doing, because they do know that, that's their stuff. It gives us the basis of starting to translate that into Drupal. So you can, yes. I'll show you how I do user stories. Okay, and so business rules. So one of the things that happens often is that they have no business rules. They kind of do things the way they do them and then you ask them how they do them and they're like, well, we decide to have an event and then Polly puts it on the calendar and then we have some meetings and then we make some spreadsheets and there are some PDFs emailed around and that's how we do event registration. So that's not a business process even for them as a business, right? And now we're trying to get them to get from nowhere within their own company into a business process we can translate onto the web. And let me tell you something, they're not going to get there by themselves. They aren't going to have any success by themselves. If they could, they'd be a better business and when you ask them how they did event registration they give you a cohesive answer. But because you didn't get one, I'm telling you now that you're gonna have to do it for them and that's where usually it's the project manager trying to painfully pull this stuff out, information out for them. So content, you guys all know about that. It's terrible, we hate it. But there's a thing for why discovery documents are so important. Discovery documents become the basis for user acceptance testing and user acceptance testing becomes the criteria for saying we built everything you asked for, go away and pay us. And that's really, really important. It also prevents scope creep. Right here in this discovery document is your guaranteed insurance against scope creep. Because if you didn't discover it you couldn't have possibly agreed to build it. If it's not in the discovery documents it doesn't exist as a feature to be built. But you have to tell them that, like this is part of that ground rules. You have to explain what this discovery document is, what UAT is, blah, blah, blah. But isn't that brilliant? Like it doesn't become, you said, he said, oh I talked to Tom the engineer and Tom said that he would build it for me. Well Tom didn't know. Like when did he say, hey, you look at the sales contract. Okay, so now we're moving into engineering architecture, any questions? Okay, good. All right. I picked this up from some great company and I wish I could remember who, but they have pre-mortems. So they actually call their team in after they've done discovery and they have plenty of information and they go, okay, when we're here in 12 weeks what are we gonna bitch about? What do we think is gonna explode? What are we already seeing as problems? How many of you have actually, as an engineer, seen the problems but nobody cares, nobody asked you so just kind of went with it? Most of you, that guy slinking in the middle so much aggravation he has caused me. He comes back, throws down a document, won't work, throws back a ticket, not working on it, not enough information. And so by working with someone who just is insistent on good process is how we started really getting better and getting into this. And so pre-mortems are really, really important. It gives your team the time to vent, look out, maybe come up with some better ideas and they can say, oh, you know, I did something like this in my last job and blah, blah, blah, right? And then you go back to your client. This is your opportunity, salespeople, to say we sat down, we talked with the team and they saw some obstacles and then you can renegotiate, you can do more discovery. Like it gives you the opportunity to constantly be going back and refining the conversation. Who knows what I mean by an MVP? Yay, okay. How many of you only build MVPs? Oh, not enough. Okay, so how many of you in the future after this session will only build MVPs? No, more everybody. So why would I insist on this? Because people who are looking at the money often go, I'm not walking away from it. So you're not walking away from it forever, you're walking away from right this moment. And I think of it more as a phase one. And what you're doing is you're actually building and repeat business by starting from the very beginning going, we're gonna build this part in phase one, we're gonna build this part in phase two, you're gonna build this part in phase three, you're actually gonna get more money. Yes. Oh, I'm sorry, a minimum viable product. It's the smallest unit of stuff you can cobble together on a Drupal site and push out the door. It's about velocity, it's about gaining trust, it's about having a win with the customer. And usually the first project is a hybrid between agile and fixed bid, right? It's somewhere in between there, you give them a range, you try to stay within the range. But if you do it really well, by the time you get to phase two, you will be full agile or time of materials because they trust you and you've done well by them. There's a reason for them to then trust you because agile is built on trust. And if you're a wonder crowd and you have a big enough presence but not all of us can sell full agile out of the box. So, and you can't sell full agile unless you have awesome tickets in process. So, it's kind of cart dog, cat horse, whatever that thing is, chicken egg. Okay, so docs. So this is what I kind of mean by docs. They're user stories, they're storyboards, they're wireframes, they're designs. I only allow design after development begins. And I believe in building first, designing second or last. And you can come talk to me more about that if you feel strongly, it'd be interesting. But websites are about data and you can't design the data which you do not know yet exists. And so that's what I feel about that. But these are what they are and I use storyboards a lot. And it's because I hate to read. I hate SOWs, I'm sorry, RFPs because I have to read and parse them and I hate them. If they drew me a picture, it'd be better. So this is how I do user stories after talking with the client. Very simple, really straightforward. This is how I do storyboards. Storyboard is the life of a piece of content. So if you have a content type, you make a storyboard for each. And one storyboard equals one piece of content and one user. So you do this storyboard from the point of view of each user. And this is because every single one of you in here could look at those things without having a legend and tell me what's going on on the site. You could be very clear about that. And I do this for the customer because I don't care how beautifully you write. If you send them two paragraphs of this, because this is usually sent back in a Word doc, they don't read it, they don't understand it, and you're on the hook for whatever they believed it said. Like there's a big gap between what you said and what they didn't read and wanted it to say. So that's where the first breakdown in communication really starts to show up. So the teacher goes to their dashboard, they look at their messages, they go and do something with those emails, and they, or they email their organic group, and then other people can do stuff. So, oops, so the same thing. And you can do, you know, this will have your own company's flavor. This is just what we did. And wireframes are essential to call out features and like that, but the only wireframe I really focus on in this phase is the user dashboard. Because at the end of the day, it's that senior person sitting at the dashboard that decides whether or not they love the site. And they only love the site if they can do what they intended to do and see what they intended to see. And they don't know that. And that's what makes this so hard is you have to pull it out of them and craft it out of thin air because they've never had a dashboard before. They used to use their email box and Dropbox and maybe they use Basecamp or they use Stickies or the whiteboard in their office. Like they didn't have a thing before and you're building it from them and you have to let them imagine how to do it. Design, don't do it until later, deployment. So deployment is an interesting thing. That has to be talked to, yes. Like a lot of times, Drupal shops will get a whole set of PSDs. And they go, this is the website that we want. Go build it. That is just insane because you can't build Drupal from a PSD because you're really trying to reverse engineer engineering from a Photoshop file and that doesn't make any sense. Documents that develop a build are called blueprints. Oh, okay, you would call this design. Oh, okay. So in some ways, yes. And so then good for you. Too much design I see comes from like having the perfect amount of pixels on a Photoshop file. Yeah, good, thank you. Deployment, deployments talked up front. Performance is talked about up front. If you build a nice new site, you're gonna have a lot more traffic, scaling, okay. So the biggest job that PMs do is they manage expectations. In companies where a process is weak, the PMs are running around with their hair on fire and they end up kind of fibbing to customers. And they're doing it because it's the best they can do. It's all, it's all, it's all, it's their tool set. We'll just kind of make it up as we go and hope for the best. But this is what the PMs or the sales engineer or the salesperson, however you wanna break it down, should do. But they ask the client to do a lot of homework. If the website is gonna be 1,000 hours, you guys are gonna invest 1,000 hours, the client's gonna invest 1,000 hours. It has, I've never seen a website go up well where the customer goes, just call me when it's done. Doesn't work that way, especially on big sites. And so you need to know what the client risk temperature is, are they willing to like go out on a limb because they've got budget, they're a startup, they want it to rock, or they're like, yeah, not so much, we got a board. So you need to know who they are and how they wanna handle risk and what they're willing to be at risk for. And process training, like how do you work as a company and how are they expected to fold into that? And if you have this conversation up front, then later when they're being a bad customer, you can go, remember when we had that conversation about our process, we are committed to it because it leads to success. And we need you to be part of that process and that success. You need to talk, who knows what I mean by a burn rate? Okay, how many of you tell your customers what their burn rate is on a project? Okay, I promise you, you will not have to suffer through those conference calls anymore. If you explain to them, the burn rate, if our team sits in on a conference call is $800 an hour. We're willing to have as many of those as you wish. But understand that's coming out of your development budget. We give you some grace around some of the time, but once we go past 10 minutes on a conference call, the clock starts running. You'll never have another three hour conference call. And if it's that long, if it's that long, there's more discovery that needed to be done, yes. Nice. So what he's saying is that there are actually tools you can put up on the conference call thing that you put the burn rate in and then it just starts to run like a little taxi meter. That's very effective because I'm willing for cabs to drop me at nearest corners, right? So, and then actually talking about the launch and all the stuff around it. So when you work for Qualcomm or some of these big companies of big firewalls, you don't get to deploy on their servers and it's a problem when you just throw tar bowls over the fence, right? Technical debt, who knows what I mean by that? Okay, how many of you make your clients aware of every decision they make in the technical debt they incur? Okay, not enough, so good, we're gonna change. How many of you now will? Yeah, so I explained to clients it's something like this. Every decision that we make on this project will incur technical debt. Some of it will be small, some of it will be large, but all the technical debt belongs to you. It's not our responsibility to pay for your technical debt. It's our responsibility to make you aware of the technical debt and then you let them decide. So how many of you have had a client that said we must now have this new feature and it must work like this and that's not the way Drupal works? Yeah, right? Like why can't they blah, blah, blah? And then you jump through hoops trying to engineer it some magical way but the problem is you never told them the technical debt that they're gonna incur for this massive custom module that you gotta build to make that happen. And they're not gonna be happy on the back end when they didn't know that that's what was gonna happen and now nobody can maintain that magical custom module. Yes, technical debt, so let's say that I decide to buy a cheap used car but now I have a lot of maintenance and I have to replace the tires and things like that. That's my technical debt on buying a used car. So in the end, I have to decide whether I want technical debt or the cost of a new car. So that's one example. I'm sorry, I should have asked who didn't know that. So this is the sprint cycle and where I see most companies kind of skipping is updating the docs. One of the things when the PM is really doing a robust job managing four, five, six, eight, 10 projects may or may not be feasible in the size of the project. Like just updating the docs at the end of a sprint can take a week but it is the most critical thing that happens at the end of a sprint. So somebody has to do it. Maybe you hire a documents person and it's a little lightweight person that you pay $20 an hour and they learn how to use Omnigraphil and they learn how to update docs. I don't know. Like you have to come to whatever resolution this is. Maybe it's your engineer said update the docs but somebody has to update the docs. Yes. All of the docs that we've talked about, the discovery document, the architecture documents, user stories, all the diagrams. Yes. Shouldn't the team be updating them? I have mixed feelings about that because it's expensive work and I'm not always fond of dumping things like that on engineers. Mm-hmm. Well, that's a good question. He's asking is he the only person looking at the docs? So you as a company have to decide how you want the docs to be documented. I like training up project managers to do it and then they review it with the architect and the team because it falls sometimes precariously close to busy work and I don't like putting those kinds of things on engineers obviously for a very complex project, right? You can't have the PM doing it but for most projects where it's like they want another view, they added a user, like these are not big things and if you do one or two week sprints there's a lot of updating to do but they always have to run it by the engineer, they don't get to sign off on them but we'll talk about the other thing. So and then the other thing at the end of every sprint is project managers have to make sure the tickets are carrying all this information. Now engineers are responsible for estimates and then if they busted estimates and things like that but the original sales estimate and then tracking actual hours and all these other reporting tools so now that as a CEO you're actually looking at real data not artificial data you can actually do and then the other critical thing is like getting your change orders in. So how many of you have like you do a sprint how many of you actually sprint? Okay and you release it out to the client and then the client sends you back a three page word document, right? And usually what happens is that gets parsed into tickets and gets called this thing called backlog and never ever ever use that to be a generic bucket again because backlog implies you agreed to do it and you're gonna do it and it's not gonna cost me anything else, okay. How many of you have had this conversation? We talked about it, do you remember? We talked about it and somehow that talked about it implies now that you're on the hook for it. So things get classified in four different ways. There are bug fixes and that you can call backlog, right? We built something, it had some bugs, we're gonna fix them, that's on us. In scope request, like you forgot there was something in the discovery, you forgot a user, you forgot to put on the event calendar, perfect. Out of scope request, they go oh where's our fill in the blank and you're like look at the discovery document, there is no fill in the blank and they go but we really must have it that is central to our business and it is critical. You're like okay but it's an out of scope request. Now this may be the first time some of you are actually distinguishing an out of scope request and you're gonna create a change order and you've already told them up front when you did the training how change orders work and so now there's gonna be a change order, they're gonna agree on the price and someone's gonna update all the documents. Now some out of scope request are going to require discovery and architecture again and so then you have to say if this recovers discovery or architecture, a revisit to those two countries we've already left, we're going to say that it's out of scope. You can build it in phase 1.1, the day after you launch it you will immediately work on it and start it over but you have to decide whether or not you're going to ruin your MVP but those are the four areas and don't use just backlog, right? Like you can see there's gotta be a distinction on the feedback you get back from the client then this is posted into Basecamp. Of your three page were a document and 112 items, 14 of them were bug fixes, 62 were in scope that we had not yet gotten to, three were out of scope and we're gonna catch them in a change order in the next sprint and three are out of scope, yes. Oh, okay, that's okay. Yeah, he's saying he's never had a backlog item where the client bigger than 12. Oh, well I think everybody's different, somebody, yeah. Yes, but how do you get paid for the new ones? So, yeah, so you're true agile and that is okay but most people are not. So it depends on your style, yeah, yeah, yeah. So it depends on how you run your business, absolutely. So one of the things with Google Docs and Basecamp and everything, people start distributing information and I don't care where it lives in your organization but the link or the actual document lives in the ticket so when your engineer opens up, he has to go nowhere else, they're lazy. Good engineers are lazy, they're supposed to be lazy. They will not go hunt for stuff that they wish was right there. How many of you are engineers and say that's true? Yes. So remember we were talking about technical debt and this is how I talk with technical debt with clients. So let's say that they, and it features even because it helps prioritize. So they have 12 features that they want to build for this web project and then what you do is you just take 12 of these little things and then you just tell them where in the scale this fits. That's a very low risk thing that Drupal does out of the box. Boom, we will add that for you or that's a very high risk maneuver and it's going to involve a lot of custom work and incur a lot of technical debt, do you want it now? And you know, most of the time they don't. Like they will, you can propose to them a lighter simpler way that is in this green area and most of the time if you visually show them this, they will back out of their demand. And you can do this with technical debt and say this is a minimal debt way, this is a high debt way and then because you've already had the conversation about technical debt they know what you're talking about. So we're doing pretty well on time, we're gonna be right at 315. So this is now starting development and look how long it's taken us to get here. I believe this is like slide 71. So we've done 70 other things before we started development and this is the biggest thing I wanted to impress on you is stop developing right after you get that deposit check as tempting as it is, don't do it. Do discovery whether they pay you to do it or not. You're going to spend those resources one way or the other. And it's also a good time to stop. Let's say you didn't intend to stop but all of a sudden you're seeing that their funding got pulled or your advocate left and now you have some other random person who is terrible managing the project. I actually talked with a company and they're like our project's miserable, why go a project manager with a former massage therapist? She doesn't know anything about technology. So that might be a good time to bail. And at the very least, you may not want to bail on the project but you might want to have a in-depth discussion with a client, you know. And these are the things inside of development and most of you guys have this but I have a thing called feature polish. So depending on the sophistication of the client and how many screens you're building for this, that or the other thing, they're always going to get to the end. Now they've been user acceptance testing with a small team and now they distribute it out to a bigger team. There are going to be things, it's not that they're not wrong, it's just that they want it a different way. And if you don't allow any budget and time for it and now you're trying to charge them for every little thing that they want, you can do 99% of the project great and they're going to hate you now. They're out of money, they're out of time, they're tired of this process because they've invested their time. And they just don't want to hear it. They just don't want to hear that you need another $1,000 or $1,500. So just budget it in. You know you're going to have to do it. I've never launched a site where the customer didn't go, oh, can you add this little thing? Can we have another view? Can we do whatever? So just put it in the budget and get over it. And then if they don't use it, guess what? Margin. And then we're going to start phase two. So if you don't have tickets, so let me ask you a question. Who is responsible for writing tickets? Yes. Team stakeholders and the project managers. Okay, who else has an answer? Yes. The product owner? The product owner? Okay. Who else? Yes. Engineers, and that's the right answer. So the project managers do the top line, I call them roll up tickets, I don't know what you call them, but it's the big ticket that says implement solar, 80 hours. Because that's what we sold. We sold solar for 80 hours. They're responsible for that. They're responsible for having a lot of information in there. And then all the sub-tickets belong to the engineers. The architects can structure out some big tickets if they're complicated or whatever, but engineers have to be responsible with tickets. That is their domain. Nobody messes with the tickets. The PM goes in there to organize them, and I have a lot to say about ticket organization and management, but not today. And how long should a ticket be? I know shops that'll let tickets be 48 hours, two weeks, tickets are four hours long. Because how do you know you're gonna bust a ticket if it's a 48-hour ticket? You won't know until the end of the week, and then it's too late. So four-hour tickets means that you break down things into small bits that you can fit on a sticky, oh, scrum, yeah. And then at hour one, you know if you're gonna bust the ticket. And busting the ticket is what tells us if we're over or under budget, if we need to go back and work with the client, if we're having impediments, we don't realize. Like without this small incremental check, you're just running wild. Now, when your team gets more sophisticated, you can get to eight-hour tickets, and if you've got a developer that rocks, you can maybe go to a two- or three-day ticket, but nothing over that, and in the beginning, four-hour tickets. It's a pain, because it makes so many tickets, but you'll get really good at it, it won't be as bad as you think. So this is not a ticket. How many of you work on tickets like this? This is not a ticket. Like you should not work on this. This tells you nothing. So Carl started this. He pushed back a bunch of tickets. It's going, not working on them. I'm like, what do you mean not working on them? And so he goes, look at what it says. And he's like, oh, because I'm like management. I'm like, oh, I see your point. So we started doing snippets. Like if you go to the view screen, there's about what, 30 different configuration things. Do you want the field hidden? Do you want the field not hidden? Is it a link? Is it how many characters? What is this? You have all of those controls on there. Do you want this to be a block? Do you want it to be a node? And so I had one of the engineers type up all of the variables that are on a view. And now a view has all that information on there. Exactly which image cache profile they're supposed to use, exactly what it's supposed to link out to, whether we're doing a more or a pager. Like all that stuff's in the ticket because we have a template for it. And so now guess what? Every engineer can open that and tell me how long it's gonna take them to build. And that's a ticket. That's a good ticket. And that's the way you have to run. So when as a business owner, go in and look at your tickets. And if all you saw was that, your whole mythology about the money you're making on your business is a lie. So companies that don't run efficient have no idea whether or not they're making money. They don't know who's good. They don't know what parts of the development process went well and everything that they're accruing is false data. That makes me really popular. Phase two. So now we've launched successfully. The client did not have separation anxiety because you told them that there'd be a phase two. But a lot of companies now say, oh, we know everything about the project. So we're skipping discovery and architecture. Don't do it. Don't do it. You start from the beginning. This is phase two, not phase 1.1. So yes, you had a question. Yeah, he's saying so by the time you write that ticket, you could have built the view. And that is true if you are a team of one. If you are a team of two or a team of 12, and now how does the QA person test against this? What are you asking them to QA? They can't QA that. The only way they can QA is by going through this checklist. And so you can't write any formal way methodology to have QA. And oh, by the way, my PMs and my salespeople do QA, right? But they need to come to this ticket to see if this got built the way it said. So yes, it takes more time, but this is the other thing that happens. You build the view the way you want to without these specs. You send, it goes through QA, it goes, yeah, it looks like a view. You send it out to the client. The client sends back all this information. Now that's gonna get put into another ticket and then you have to rebuild it. And now somebody over here on theming already started theming that view because everyone said, yep, that's a view. And that's what we got. And then now the whole team is running in circles around a view that didn't get built well the first time. And then when you start getting into features, right? Oh, now we gotta start rolling back stuff. And now we've spent, instead of the 20 minutes it took to do this, now we've burned up 2.5 hours. And so that creates that problem. So yes, but your process isn't scalable and that's where all of you are. You are mostly with big companies and you're trying to scale. And without this process, you can't scale. You can't scale on this. You can't hire remote people. You can't manage anything. So that's the thing. And so when you're small and sometimes even with a team of four, like you guys have worked together and you've built enough sites together, like you go view, you go, yeah, view. And everybody knows what that means. And so it can work. It can work. It just won't scale. And so then if that engineers out, how are you gonna tell another engineer to pick this up and build this ticket? You can't. So that's what it is. And that's a really good question because I get that pushback a lot. Like if I spend that much time, I could have just built the thing because you're fast, right? But it makes other problems. It makes the other parts of the system go flat. And that's what we wanna avoid. Any questions? Oh, can you go up to the microphone? I'm supposed to make you go up to the mic. And it is now 315, which is our agreed upon end time. So if anybody wants to leave, please feel free to do so. It's during the break. Yes. I can't quite reach the mic there. Do you, the exception's criteria. So the details are in the ticket. We agree for each ticket, those with the client. Do you follow the same process? So take the client through each individual ticket and make sure everyone's on the same page? No, because if you did the wire frames, it's the wire frames that are driving the view parameters. Yeah, yeah. Good question. Anything else? Yes. Yes. Why? Again, for communication and scaling. Yes, absolutely. Absolutely. If I have a team of 20 engineers and no one gives me an estimate, how do I know how much capacity I have? Oh, it doesn't matter where you put it. Like, you personally can put it wherever you want. But to me, I like having a ticket-driven development company because engineers live and march on tickets and that's where they are. But yeah, you can choose to do it separately. Yeah. Anybody else? Okay, did you guys get value from today? Yeah. So what is something that you're going to implement? You look very attentive all day, Bjorn. Nice. Who else is going to take home something and do it? Project documentation and updating. Yes. Yes. Yes. Yeah. Discrete project pieces. Much easier to sell too. And more profitable. Yes. Excellent. Yes. How do I sell discovery? So I actually explain that gap. I actually talk to them about their business requirements and I explain to them that once they go through discovery they'll have a much richer understanding of what they're asking someone to build and it's a document that they can take with them to go get other bids. Because when you write a good discovery document it's really like the world's best RFP. Because you'll have gone through all the user stories and the storyboards. You'll know how many content types. You'll know all that kind of stuff. Yes. Uh-huh. Oh yes, they're asking about the clients that come to you with the PSD somehow assuming that's an engineering document. That's a training thing and that may be a client you have to say no to. If they're really fixated on that you may have to actually say that's not a good client. And you can just tell them, you know this isn't a blueprint, it's a photograph of a nice house. Yeah, exactly. Any questions over here? You guys were attentive too? No? It's something you're gonna take away and start using. You. Yes. Oh. Oh. Well you can look for shops that actually have good process. Right, so now when someone says oh we'll just, you can start seeing red flags because they don't know how to really bid on your project, right? So you can start looking for companies with process. Sometimes it is a little more expensive but it's more important to be successful. You know, at $50,000 then unsuccessful at 35, right? So anybody else, any more questions? Yes. So there's a bof over there at 1015 working with the clients. So yeah, no, plug away. Would anybody like to continue this as a bof? Raise your hands if you want to. Okay, I'll see if there's a bof room and I'll put it up if there is. Thank you guys so much. It's been wonderful.