But measuring urine levels of industrial toxins is more useful than measuring food levels, since it indicates how much of the pollutants are actually absorbed into the body. So in one sense, it's telling you what kind of levels are circulating in your body. At the same time, it's telling you how much your body is successfully getting rid of through the kidneys. Ideally we'd like to measure levels in human tissues. Like how much is actually lodged in one's breast tissue, for example?  Why not test surgical samples of removed breast tissue? Women get fibroids removed. We can test those, too—fresh autopsy samples. And hey, what about liposuction? How did the levels of polybrominated diphenyl ethers, flame retardant chemicals in the breast tissue of California women compare to various tissue samples taken from women around the world? Where do these flags fit? Which of these bars represents the levels found in Belgian women, Brazilian women, Californian, Czech, French, Hong Kong, Japanese, New Yorkers, Singaporean, or Spanish women? Do we wish they could all be California? No. Look at that spread. Two orders of magnitude. The breast tissue of California women had nearly 10 times more than women in any other country. And compared to the lowest levels, autopsy samples of Japanese women, 100 times higher levels found in New Yorker liposuction.


This paper proposes a new methodology to estimate ground-level PM2.5 concentrations using satellite-derived 500M AOD data. The methodology combines the simplified high-resolution MODIS aerosol retrieval algorithm, CERA, AOD product with meteorological variables such as PBLH, RH, WS, and temp extracted from weather research and forecasting, WRF, a simulation to depict the spatiotemporal dynamics in the PM2.5 AOD relationship. The GTWR model provides ground-level PM2.5 concentrations with 500M resolution at the MODIS satellites overpass moments twice a day, which can be used for air quality monitoring and haze tracking at the urban and regional scale. This article was authored by Yang Bai, Lee Sin Woo, Kai Chen, and others.


I will be talking about winning and retaining long-term clients, so if you're thinking this is about development, you're definitely in the wrong place. So a little bit about me, I'm Owen Lansbury, I'm one of the co-founders of previous NEXT. You might know us as good co-contributors to the Drupal Project. We are in fact a very small team in Australia, 20 people or so, and we've been an independent agency for the past 10 years, and we generally work with large government clients, large education clients, some enterprise customers, so probably quite similar to a lot of you here. And if you are sitting here, then I would expect that you're a number of things or potentially a number of things. You might be thinking of starting your own agency, you might run a smaller agency and you're thinking about how to grow that, you might work for a larger agency, but you're frustrated by a client turnover and you want to try and instill some stability there. But no matter who you are, this talk will hopefully have some universal themes that are applicable to all of you, and I think the point that I'd like to make is I wish someone had told me these things 10 years ago. So in terms of what we will be talking about, I don't want to labour on any cliches, but we will be talking about seeding, nurturing and growing the right types of clients for your business, and rather than use business clip art, I'm going to use a gardening theme here. So before we get stuck into the detail, I want to ask a question around what does make your business sustainable in the long run, and what things you could be focusing on to keep it that way. And yes, we should all be working on things that we love, but as a business owner or as a business leader, ultimately the most important thing that you're doing is paying your staff's mortgages for them and putting food on their table, which is a huge responsibility. And as a leader within that business, having a focus on the numbers that keep your business running is ultimately the most important thing that you can be doing. So who here does have their own agency? Yeah, and who's thinking of starting one? Or maybe you're sitting next to your boss, so. You shouldn't answer that question just yet. But I think the important thing is to think about what is your capacity model? And by that I mean most of us are probably primarily services companies, and we can only make money out of the number of head hours that we can build to a client. And just by way of example, you might have a five person agency, you might have yourself as the founder, and your billable capacity as a founder is going to be limited by all of the administration that you need to do, all of the new business work that you might be doing. And ultimately you might only be 30 to 50% billable across any client projects. But then if you think about your team, you might have a designer, you might have three developers. All of those should be around about the 80% plus billable mark. And if you are able to achieve those types of numbers across a whole year, you should be able to fulfill around 6,000 hours of billable work. And that should turn you into a million dollar company or a million euro company. And that's just a baseline to think about what you could be capable of as an agency of that size. And then we start thinking about profit. So with that million dollars of revenue, about 50 to 60% of that will probably be going to wages. And I should make the point that as a founder, you should be paying yourself. It's often one of the things that kind of get left by the wayside as a person starting a company. But unless you're sustainable yourself in the money that you're paying yourself, things will become very complicated very quickly. About 20% of your costs will be operating costs and that leaves about 20% that you should be targeting for profit. So out of the million dollars, about $200,000 of that should be what you're targeting for profit. And I think being an altruistic community as the Drupal community profit can be a bit of a dirty word. But just remember that profit is your safety buffer and without that profit, you can't make any other decisions about your company. And if you do make profit, that's a fantastic thing because then you can choose what you might do with that profit. You might have a profit share scheme for your employees. You might reinvest it back into Drupal development contributing code to core. Or you might just be reinvesting that back into the business. But without that profit, you can't do any of those things. And by letting the numbers decide helps you put a lens around big decisions. So you might think, oh, I need to hire someone new to fulfill a certain function. Well, are you making a million dollars? And if you're not making that million dollars, you can't afford to go off and hire someone else. If that revenue that you have drops below that 80% mark and you're not making any profit, you're essentially just breaking even as a company. You might need to make the hardest decision as a small company and that's to let someone go. And while it's a very tough decision to make at that point, ultimately you're saving another four jobs by letting that person go at the right time. And I've seen that with many companies as they hold on and hold on to make that decision and ultimately everybody suffers in that mix. And like I said, these are very, very tough decisions to make as a business leader but you need to have the confidence to make those decisions at the right time. And if I just look at our own history as a company, like I said, we've been going for 10 years and in our own first year, like many small agencies, yes, we took every client that we could get and didn't say no to anybody. And at the end of that first year, we had two clients that accounted for two thirds of our revenue. You think, oh, that sounds great. But if one of those clients leaves, where it's suddenly 30% down on our revenue and we'll be making those tough decisions about letting people go, luckily we didn't have to do that. But I think more importantly by saying yes to every client that came knocking, we ended up with most of our clients being billed very small amounts and those clients that have been billed very small amounts still take up a lot of your time and I still remember our lowest billing client throughout that period was calling me up to ask how we could fix his iPhone. And of course, I was saying, yes, this is what you do and that was taking time out of my day when I should be focusing on going after some bigger clients. And then we go five years down the track, we've got a nice little orchard blooming now and by that stage, we had about 20 clients that accounted for almost 90% of our revenue and that's obviously a great way to defray the risk of one of those 20 clients drops out that's not going to have a huge impact on the business. But of course, we kept saying yes to clients through this period and I went back and looked through our books and at that point in time we had 50 clients in addition to those top 20 who were all being billed under $10,000 a year and you've just got huge complexity in managing that number of very small clients over the course of a year and all of their individual demands. And then finally, we had our 10th anniversary about six months ago and one of the decisions that we made a few years ago was to retire a lot of those smaller clients. And I think the classic situation is that you're not really wanting to work with these clients, they can tell. And it's actually a much better option for both of you to say, okay, there's another smaller agency getting on their feet down the road, they're looking for clients, they're a good fit for you. We're gonna transition you to that new vendor and then the client's being serviced by someone that really wants to work with them. And so now we're at a point where we have about 10 big clients who account for 80% of our revenue and then we've only got about 30 clients in total and only a very small proportion of those are very long-term legacy clients that aren't billing large amounts. And very importantly, we put a big focus in on repeat revenue from clients, clients that were paying retainers for services where they're paying in advance the hours that you will fulfill in the future. And I'll talk a bit more about that in a moment, but we're now at a point where about 50% of our billings, we receive that at the beginning of the year and then we burn down off that through the year. So that gives us huge stability as a company to be able to then burn down those hours. We've got the money in the bank and the client also has the confidence that we will be there to fulfill those hours when we need them to or when they need us to. And we've consciously stayed around 20 staff as an independent company. I'm sure many of you have heard that as soon as you go above 20 staff, then you start putting in layers of middle management who aren't billable and that adds a huge amount of complexity to the organization and doesn't necessarily increase your profit. So there's this gap between about 20 and 40 clients where you're increasing your head count. You've got a lot more stress in terms of managing that pipeline of work and ultimately your bottom line at the end of the day hasn't dramatically improved. So that's been a conscious decision on our part. That's gonna be different for different types of companies. I'm just saying what's worked for us. So like I said at the beginning in our first year, we just took what had a client that came through the door. And the lesson from that for us is that we needed to be very clear, quite fast about what types of clients we wanted to work with and what sectors we wanted to specialize in. So we focused in on Drupal quite quickly. We realized that there was a lot of work in government and higher education, implementing those services and we went quite confidently into those sectors. But I think you can easily fall into the trap that the clients themselves will define the type of company that you are. So it's quite important early on to define what your ideal clients are and how you're going to go after them. And a very wise person said to me once, think of a potential client and the first project that you're going to do with them as 10% of what you expect to build with them over time. So that first project is just going to be leading to more and more projects with them through the future. And it's a great lens through which to view opportunities with clients. And while I'm not saying use this to discount every client that you have an opportunity with, it does help you identify the golden clients that you will be able to work for on a very long-term basis. And these long-term clients, they all share very similar attributes. So number one is they all have very complex needs. They've got a big mix of technologies. Drupal might be part of that technology mix, but it's not going to be the only thing that they have. These types of clients generally have multiple divisions working on different projects concurrently. And they often have large internal teams that are working internally on those projects, which might include other Drupal developers that you need to integrate your team with, as well as things like designers and strategists and product managers, those types of things. And one common thing to all of them is that they've all got ambitious targets, whether that's sales or customers or product releases. And with the ambitious targets, that requires significant technology budgets. And you will be very well placed to help them identify how they can spend those technology budgets in your engagement with you. And as I mentioned quite early on, all of these clients will require retainer-based services for the certainty of having a vendor that can provide them with services when they need them on a consistent basis. So unless you like herding cats, reselling to these existing large clients is always going to be much easier than trying to establish a relationship with a new client. And so one of the things that we've often done as a company is to say, okay, we've got our forecast for the next quarter. We can see that there's a little dip coming up. What can we be doing with our existing clients to extract more revenue from them before we go out and talk to new clients and hope that that's going to fill the gap? And more often than not, our big long-term clients will be more than happy to have that conversation with us and help us identify where they do have revenue to be able to spend. And I think the best example to use is what's going to be easier for you as a company to fulfill is that two projects worth $500,000 or is it 50 projects worth $20,000 each? And it's an obvious answer that two projects is going to be much easier than 50. And what we do when we do have opportunities with new clients is that we go through a client pre-qualification checklist internally before we even talk to a client. So we'll receive an RFQ from a client. We'll go through this checklist in terms of what the opportunity is to us. Do they have a big program of work in the longer term? What's our likelihood of winning in the first place? Are they talking to 10 vendors or are they talking to three vendors? Have they specified Drupal as their preferred CMS or are we going into a situation where there's a CMS showdown and we have to prove Drupal is the right choice for them before we even prove that we're the right choice? And I think this process is as much about you identifying that you're wanting to work with a client as it is about them wanting to work with you. And it saves you a huge amount of time in terms of responding to proposals if you do an exercise like this up front and say, yep, this kind of ticks all the boxes, let's pull all of our effort into it rather than spending two weeks on a proposal that you've got 5% chance of winning. And so now that you've defined the types of clients you wanna work with them, how do you win them? So it's all about how do you see these preferred clients and for lack of a better metaphor, what point do you fit into the client's purchase cycle? So large organizations, they're often going to engage a separate firm to do their digital strategy and help them identify what technologies they should be working with. Many of them still view UX and design as a separate engagement and they might have gone off and engaged a design firm and they come up with a whole range of beautiful designs.  So it's always preferable for us if clients already specified that Drupal is their preferred CMS. And I think the risk that we do have as smaller agencies is that these big clients are often looking for someone to come and implement Drupal for them, which is less than ideal in terms of a relationship. So they've often identified all of the things that they wanna do upfront, they've done all of their designs and now they're looking for some to come and build it. And so what we try and do in all of these opportunities is to have conversations around how Drupal meets their requirements and modify those requirements based on the selection of Drupal early on in the piece rather than trying to have that conversation down the line where we say, well, actually what you've specified here is just isn't gonna work with Drupal. So have those challenging conversations as early as possible. So then we get more into the marketing side of things. How are these types of clients going to find you? So what we've found very effective is what is our profile within their industry sector? So like I said, previous next as a company, we're focusing on government, higher education and enterprises our preferred clients to work with. And hopefully clients within those sectors will be aware that we have expertise within those sectors. Second in terms of importance is our profile within the Drupal community. So you might have seen in Dries' slides this morning, there was a big typeface for Acquire and then just below that was this little company called previous next in terms of contribution. And that is as much about us marketing ourselves as Drupal experts and investing in Drupal contribution to build that profile as it is about contributing code to the community. And that might sound a little bit harsh, but it's very effective for both Drupal and for us at the end of the day to take that approach. The other thing that we do a huge amount of is content marketing simply by writing blog posts across a range of different topics related to Drupal and the types of services that we do. And that'll often throw up good search engine results when people are looking for expertise. So Drupal and personalization, large scale Drupal, Drupal and Kubernetes, et cetera, et cetera, these types of topics that complex customers will be concerned about. And in tandem with that, we put a lot of effort into what we call expert marketing, which is coming and talking at conferences like this. More often than not, it's our developers who are giving these types of presentations and we can point to our clients and we can say, all of our people have been giving talks at conferences around the world on Drupal demonstrating our expertise. And that obviously instills a huge amount of confidence with our clients. As we work down the list, personal referrals within industry sectors are vitally important for us. So you might have a client contact who has a friend or a colleague that works for another organization and their colleague says, hey, I'm trying to build this big new website in Drupal, who should I talk to? And of course they're gonna talk to their friends about who's done a good job for them in the past. So we've found that to be particularly important for us, just that personal referral. And as we move down the list, things that we find relatively ineffective, the first one is business networking. So going to networking events and putting up our banner and saying, hey, clients come and talk to us, we really don't find that very effective in terms of actually generating solid leads for us. We find it's just as important to just turn up at a conference and have coffee with someone and talk to someone in the lunch line. And at the absolute bottom of the list is cold calling clients. And in fact, I don't think we've ever done that. So I think if you've reached the point that you're cold calling clients, your business is probably in a lot of trouble as a services business. That's obviously different for things like hosting and that type of thing. So the clients found you and why would they then choose you if you've gone through a proposal process with them? And I come back to that notion of your company profile. Good big clients, they like to say that they're hiring the best people to fulfill their projects. And it's actually very important that your client can tell their colleagues that they've hired the best firm for the job that reflects very, very well on them in terms of their own career. But most importantly is demonstrating that you understand the client's needs. So we have fallen into the trap in the past as a company to think, oh, we're one of the biggest contributors to Drupal. These clients should know who we are. And of course they don't. So when you do go through a proposal process, make sure you take the time to really understand their requirements and the goals that they have for the project and demonstrate why you would be the best choice in terms of understanding their needs and fulfilling them.  And that's been the most consistent feedback that we've had in terms of why we haven't won projects. It's like, well, you just said you were good at Drupal but you didn't say you knew what we were trying to do. Obviously demonstrating that we have relevant experience within a certain sector and then expertise and the technology is key. And then again on the personal side of things, the personal impressions that you leave with the client and the relationships that you're building with them through the early stages of a sales cycle. So do they feel relaxed and comfortable with you?  And it can't be discounted how important that is. So I think again, one of the traps that you can fall into is there's all this business all the time but ultimately people base their choices on the relationships that they've established. And as we get to the bottom of that list of why clients will choose you is price. And we've actually rarely found the prices a factor in why clients haven't chosen to work with us. And we've tended to always try and price ourselves at what we feel is a fair market value and really don't use pricing as a negotiation tactic early on in winning a client. So this next section I'm gonna talk about the types of clients that you can win who do fulfill these large client categories. So I think the obvious thing that we all try and aspire to is yes, we wanna work with the big global brands. And I think that the challenge that you have as a small independent agency is that these big global brands, they're not making their decisions about technology in Dusseldorf or Antwerp. They're making them in headquarters in New York or LA or wherever they might be based. And then they're working with major global digital agencies to implement those programs of work for them. And even if they've chosen Drupal, they're more than likely to go to their local office of that global agency to fulfill that work and then sure that local office might come to you for your Drupal expertise and ask you to partner with them. But I think the important point to note is that you will never own that big relationship unless you are that big global agency. And while it's fine for one-off projects, it's a bit of a trap to fall into that we're partnering with this big global agency and they're delivering us all of this work. At some point, if there's enough work there, they're gonna hire their own people and replace you out as quickly as they can. So where we have found a lot of opportunity as an independent firm is to work with challenger brands who are going up against those big global brands. So a good example is we worked with a relatively small telecom firm in Australia that was just starting out, gaining customers, working against the Vota phones of the world. And they stuck with us and now they've got a million customers all using their Drupal website to sign up. And I think the message and the lesson with these challenger brands is that they're much more willing to work with independent agencies and they're much more willing to use open source technologies as a competitive advantage to move fast and to counter their big global competitors. And as I mentioned, we do a lot of work with the public sector. So that includes government, includes libraries, museums, higher education facilities, et cetera, et cetera. And one of the good things about most governments is they often have policies to work with local firms and you can use that to your advantage. And they'll often have pre-qualified vendor panels that you can get onto. So while there are a lot of work to go through and to open up all of your financials for them and to buy the right insurance policies so that you can tick the boxes to be on their preferred panels, once you're on those lists, it's very hard to fall off them. And once you've worked out how to play that little game with government to tick all of their boxes and show that you're a reliable vendor, then you'll be qualified to respond to the proposals and RFQs that they put out requests for. And while it can be frustratingly cane to go through their tender processes with them, they might take months, if not years, to sometimes go through, government will often be more transparent than a corporation around the decisions that they've made and their preparedness to give you feedback if you're not successful. So if we aren't successful with a tender that we've gone for, we'll always go back for details, feedback on why we didn't win that and we feed that back into our learning processes. So you won a project, now what are you gonna do? So the first thing that we do is we put up a big fence and we set parameters around how we're going to engage with these projects. And so we start every big engagement with what we call project charter and that essentially just outlines, this is the process we're using, these are the people involved, this is when someone's going on maternity leave at some point during the project, this is the responsibilities that you as a client has and one of the other very important things that we do is we try and establish multi-tiered relationships between our organization and theirs. So for example, our managing director, would ideally have a relationship with the director of marketing or the CIO or someone like that at a high level and then our product or our project managers will have a direct relationship with the project managers on the project. And what that sets up is our ability to have those complex and tough conversations at a high level if things aren't going well but we've at least got that relationship there. If we're only relying on our project manager talking to the client's project manager and things start going awry, there's very limited options for us to be able to have a conversation around, well, what should we be doing better and should we be switching some people around to get a better working relationship? And I think the other point around that is make sure you've got the right people managing those relationships. So sure, I started the company and it's gone quite well but I'm not very good at managing those types of relationships and I've put a lot of effort into hiring the right type of people to manage those relationships. And I think that's a good lesson as a founder is know what your strengths are and hire people into those positions that you need special expertise that you might not necessarily have. As a founder, you're not necessarily gonna be the best person for that all the time. And then in terms of the relationship that you try and set up with a client, you want to establish a sense of partnership around a project. And I think as a small agency moving into these big organizations, it's very easy to fall into the trap of this adversarial client-vendor relationship where they've got all the power and they're holding up these 200-page contracts pointing at various line items about what you said that you would do. And if you start a relationship like that, it's never gonna get better without a lot of work. So I think it's very important to have this notion that you're all in it together, you're all working towards the same goals and that there's a partnership approach to achieving success there. And bear in mind that the first project that you do get with these big clients is as much about them deciding whether they want to work with you in the long term as it is about you wanting to work with them. And we've definitely had situations where we've done our first project with a client that's been incredibly testing and painful for all parties concerned and we've finished the project, delivered it and said, great, we're gonna refer you onto our colleagues over here that might be better suited to working with you. So be prepared to make those calls at certain times because the end result is that you'll probably start losing staff if they're working with a client that's particularly painful and you can't rectify that relationship. And I think another lesson from that is try not to compromise your own internal processes based on the client's direction to you. So you might have gone into a project and said, we're running this as agile. A project manager from the client comes in and says, no, we're running this as waterfall. That's like, we won this project saying it was agile. This is what we specified. If you now want to change that, that's a completely different conversation and we need to go back to our project charter and redefine that. And that's the benefit of having that project charter in place. Big organizations, new people are always coming in with their own ideas about how things should be. And if they do want to have that conversation, it's not a conversation about we're going to now switch the way that we're managing this project. It's a conversation about we need to go back and change the project charter because we're going against what we originally agreed to. And then we get to the good stuff. So value adding to a client is critical through all of the phases if you're engagement with them. And as I said, when you're writing the proposal to them, you want to demonstrate that you understand how you're going to fulfill their goals. Once you're working on the project, you want the whole team to understand what the client's goals are and the strategy that they're employed to deliver that and that you're demonstrating at each step that yes, we are fulfilling the goals that you've defined. And I think as a small company, you can often be very precious about the ideas that you take to a client. This idea might be worth $50 million. Well, the idea is they're cheap. That's the implementation that's hard. And if you do deliver great ideas to a client, who are they going to look to to implement it? So it's definitely your best interest to be open and free with those ideas. And like I already touched on, working collaboratively around those ideas is vital to build up this sense of teamwork and partnership around the project. And in many cases, it's the client looking to you to provide them guidance to fulfill their own goals. Now, working with these big clients can be incredibly frustrating at times. And what I wrote here is that you need to be the Zen masters through your engagements with them. These large organizations, they're always in flux. There's always new managers coming in. They're always restructuring their internal teams. They've always got revised strategies. And all of this can seem completely chaotic on the client side at certain times. And in many cases, your team is keeping the lights on for their most important public facing outlet. And so I think the lesson that we've tried to instill with our team is ensure that we're always viewed as being indispensable as the trusted vendor that's going to be the rock throughout all the change that a client might be going through. And that just builds up huge trust with you and the client over a long period of time. And in some cases, we've worked with clients for six or seven years and there's been five or six different managers that have come through and complete restructures and restructures on top of that. And we're still there, keeping the lights on in the background. So we've built up this trust and good relationship with the client. What we then want to move into is how can we be insuring repeat revenue from them? So the ideal situation that you want to get into is that they are paying you a retainer for your services and that might be as simple as, if you guarantee us 20 hours a month over the course of the year, we'll give you a 10% discount on head-out rates. Everyone wins. And it just establishes huge certainty for both you and the client in that situation and you're not going back to them every month with he's another quote for that project that you want to do. It's a case of, well, you've got 20 hours this month and we can do this within those 20 hours. And in some cases, it might be 200 hours. You might essentially be their outsourced web team. And that can become incredibly lucrative for you in the long term and also very satisfying to be building out these big platforms. And a component of that is support and hosting. So as a small agency, you can often think, well, supports just a total pain in the proverbial and hosting where we don't really have the technical expertise to manage large infrastructure. But the lesson that we've learned the hard way is if you hand over that relationship to a third party firm, then you've broken or you've confused your relationship with the client. So even if you are outsourcing that side of things to a third party, it should always be white labeled and you should always be the one that's maintaining the relationship. And it establishes your company as being the owner of everything that a client might be doing with Drupal. As soon as you start fracturing that and introducing third parties who have their own agendas about what they might want to be doing, things can quickly go awry. And you do need to be prepared for those hiccups. So things are always gonna go wrong on projects. There's gonna be security updates that don't work as well as you'd hope they would and there'd be cyber attacks or who knows what. So getting back to what's the most important thing to write out those crises is your relationships with the client. So like I said before, if you have these multi-tier relationships, the actual project team and the client project team, they might be completely freaking out, but your managing director and their CNO or their CTO, they're looking at the project from a higher level and they can see ways to fix that without destroying your relationship. But what we've always found is the biggest risk to us is when our key contacts within the client do get moved on and someone new comes in and they come in with their own preconceived ideas about how things should be working. And the important thing is that we have a transition approach in place about how we're going to introduce our team to this new person, going back to our project charter about how we've been working together successfully over the past few years. And that just sets up a good relationship with that new person ideally. In some cases, it's not gonna work all the time, but just be aware that that's often the most critical issue that you're going to face. And then the other part of things that your own internal team is gonna change over time as well. So if you are talking about working with a client for five, six, seven years, how many of your team members are gonna be wanting to work on that one project the whole time? So people do tire of working on the same thing forever, but on the flip side, clients get very attached to their key contacts within your team. So in the same way that if a client contact moves on, you need a transition process. If you need to restructure your own internal team, you need a transition process around that. And because you've got a partnership with your client as best to include your clients in that conversation to talk about the reasons this person's moving into a new team, who's gonna be replacing them and familiarizing them with that change before it actually happens with their agreement. And again, that's not always gonna work perfectly, but if you're taking the approach of it being a transition rather than an abrupt change that they have no control over, they'll have trust in you. And then you've got competitive pressures. So the big vendors, the extensions of the world and the deloits and all of the other 300,000 people firms, they're paying a lot of attention to Drupal now. And the thing to understand about those types of organizations is they probably already have a relationship with this big client that you're working with. And they're always gonna be looking to expand their footprint within those client organizations if they can. And really the only defense that you have against that is to always be demonstrating great value to your clients and to have those trusted relationships in place where at a project level, that team is saying, no, we can't work with a new vendor. We wanna keep working with previous next or whoever they might be working with.  And then finally, the other risk that you have is that these big clients, they've adopted Drupal, they're spending hundreds of thousands of dollars with you. Oh, we should have our own Drupal team. And this is something that we come up against consistently. And as a good vendor, you need to work with them cooperatively around that. You can't fight against it. That's what they've decided to do at a strategic level within that organization. And the best that you can do is help them identify how those internal teams might be built and how they might interface with your team. And again, that means going back to defining how your team has clear parameters to work with their internal teams so that you don't end up in a, he said, she said it was them that deployed that code that broke the site and that can always end quite badly. And I think the reality is is that these internal teams will usually only be capable of sustaining business as usual for a client. And they're always going to be coming back to you for the heavy lifting on complex projects. So sure, your revenue overall might have diminished but you still have an engagement with them. And the best news is that most of these clients that try and internalize their teams, they might try it for two or three years and those internal teams dissipate and they lose some key people and who are they coming back to reinstate their services? It's going to be you if you're still in the mix there. So don't lose heart if that happens and work cooperatively with your clients around that. And finally, everything has a shelf life. So the relationships that you have with clients sometimes come to a natural end and you just have to accept that that's the case. They've chosen a new technology at a strategic level and Drupal's not it and there's not much that you can do to fight against that. But the other thing that you need to be aware of is that clients are always looking for good value and they'll often go back out to market to put pressure on you to demonstrate that you can still deliver that value. And the biggest thing that you can often slip into is complacency around your ability to re-win that work.  Don't assume that you're automatically going to win. So I'm just going to wrap up with five key takeaways from what I've talked about today. So going back to square one, know what your billable capacity is as a team and work towards that. That's going to set the parameters around having a successful business. The second thing is actively define the types of clients that you know you want to work with and then put the energy into going and winning them and that'll set you up in terms of great clients to work with. The third thing is establishing structured multi-tier relationships with your clients to weather the storms of individual relationships. And the fourth thing is when you have the opportunity to retire those smaller clients that might have been kicking around for a number of years and not really paying you a lot of money in favor of the larger long-term relationships that you might have established and the retainer-based fees that come with those. And then finally, as I mentioned, approach all of your long-term clients as if every project is your first one and always be demonstrating that value. So just on time there, we've probably got five minutes for comments and questions if anyone has any critiques. Oh, we've got the microphone here. Thank you. To see if you can answer. What's the percentage of time on sales or an unbillable project management? Your case, yeah. So, I'll use this microphone. The question was how much time you put into sales. And I think of that more in terms of billable percentages of key staff. So our managing director is primarily responsible for sales and overall client management. We don't expect him to be billable. He's keeping the engine running and then everyone below him is expected to be around 80% billable and that varies on roles. So project managers, they'll be spending a bit more time on proposals so they might be around 65, 70% billable. Developers, they might be up around 85 to 90% billable if they're not contributing code to Drupal. So I think that's a different conversation but for our developers, we have an 80% billable target and then 20% of their billable time or their paid time can be used towards Drupal contribution or other things that they might be interested in. We'll just use the microphone for the recording. Thank you for your speech. How much time you needed to get to the moment when your company doesn't need to talk for clients when the clients comes to your company? That's a good question. So at what point don't you need to look for new clients? And I think the answer is never. But it's more a case of if you forward forecasting and can see three months in advance in terms of what your revenue is and you can see that being fulfilled by existing clients, there's less pressure to be responding to lots of RFQs. And as we see that next quarter diminishing in terms of pipeline, that's when we start putting more effort into responding to RFQs. I think because we do work with the public sector, they'll often invite us to respond to proposals but many times we're having to still keep an eye on what's going out to market. They don't have a direct contact with us when they do release those proposals. If you wanted to say it, I'll repeat the question. It's for my voice, yeah, can you hear me? Yeah. So my question is around the long tail of customer that you talked about having top five, 10 customers that are large, beloved clients and then the long tail, which is not giving you too much revenue right now. And I think I also saw your metrics where you give a zero or one saying future business. Yeah. Had there been an event where you lost a customer because there was no immediate opportunity but then there was something big happening in the last few months, six months and how do you make that decision? So the question was around the long tail of clients as they taper off and then the second part of the question was, have we lost? When do you know that it's time to go on? Yeah, so I think with the long tail, essentially if you've built out everything that a client needs for that immediate point and they've then moved into potentially hosting with someone else and they've got an internal team doing their business as usual and they're just coming back to you for minor requests every now and then, then at that point it's a case of, well, you'd be better served working with someone else potentially because responding to you becomes more trouble than it's worth. And that's just a judgment call but we'll often give it like months to reach that point before we make that decision. And like I said, we had a point a few years ago where we said, okay, well, we've got 30 clients who are paying under $10,000 a year for services that we're giving them. They're still taking up a lot of our time. That time could be better invested in our other clients and we just did a wholesale cull of these old clients moving on to another agency. And we didn't have any pushback against that either. With regards to the projects after, is that a binding agreement with the clients and if not, what type of documents do you actually get or managing scope? Yeah, so the question is the project charter, is that a binding agreement? And from a legal perspective, I think yes. So we outline here's the goals of the project, here's who's working on it, here's their responsibilities, this is the reporting structure, et cetera, et cetera, et cetera, and then both of us sign that. And that becomes an agreement. And I mean, I think the attitude that I take to contracts is that they're only as strong as your ability to defend them in court. And so ultimately, it's your agreement with the client. And if they choose to say, well, we don't care about that anymore, you really have no power to counter that in most cases. You're not gonna take them to court because they've breached their agreement. So that's more around setting those parameters and expectations and you've at least got a reference point. And so the example I gave was someone comes in halfway through a project and says, we're running this as waterfall now and the conversation rather than being, oh, well, we don't wanna run it as a waterfall project. The conversation goes back to, well, we have a project charter, do you wanna revisit that project charter and renegotiate that before we have that conversation? And in many cases, the client would just say, oh, no, actually, you just keep doing what you're doing. In terms of scope definition and control, we use agile. And the ideal that we have with the client is that we basically scope out a project in terms of sprints. And so we say, this project's gonna be 10 sprints. Each sprint is gonna cost $25,000 or whatever the case may be. And then we're just burning down off that budget and showing that we're delivering value against it. So that was a long process to get to that point. But with the clients that it works well with, it works fantastically. And the clients that it doesn't work well with, they're usually the clients that we at some point move on from. And it comes back to that notion of, do you have a partnership with the client? Do they view you as equals? Are they coming to you for your expertise because you know, how to run these types of projects? We are just on six o'clock. I know people probably want to drink beer. One more question at the back there. So we sell support on paid pay charts and clients who buy fixed amount hours per week or per month. Yeah. Do you sell both? And I do have any preference? So we have fixed price on managed hosting and that includes a number of hours to support for the hosting infrastructure. And then we have what we call enhancement hours which are on retainer as well. So a typical client might have 20 hours a month of enhancement hours and then a fixed price on their ongoing hosting and we then build that annually in advance. So a customer like that might pay $100,000 at the beginning of the year and then we just burn down from that. Have I made you an enhancement hour or have I planned on a fixed date for example? No, we generally have a planning meeting at the beginning of each month with the client and it's essentially the project manager saying, okay, we've got 20 hours for this month, what's your priorities and let's work on those tickets. And because we're using agile, we have a backlog of stories that we can work through and if we get through some of them fast, we do more work in that month. Yeah. So I'll leave it there. If you do have further questions, feel free to talk to me afterwards. If you need to contact us, you can find us on Twitter at previous next and I'll be around the conference for the next couple of days. Thank you for coming. Appreciate it.


All right, I think they're getting us going and getting us started and there was light I'm John Gruber with F5 Networks. I'm in our product management. This is Rick Masters, and I'm in our architecture group I'm a senior director of product development. So when we talk about open stack things Obviously the networking component of open stack was very very important to us But you also see things that involved compute you saw all sorts of things to range the whole catalog of things the first time F5 published solutions with open stack was for neutron LBAS and it was last year that we came out and said Hey look an LBAS solution should be flexible no matter what your deployment was because we saw a bunch of LBAS solutions that Could do very well if they were running in compute could not do very well If they were to graft in to open stack as a network device, so we talked a lot about that and We'll continue to talk about that because one of the functions that is a necessity is To run LBAS in a multi-tenant way We all know that open stack supports multi-tenancy, right? We all know that that tenant model is very well-defined if you think about the resource consumption of a load balancer There are many many many many many use cases where it makes no sense to burn all those resources to launch one VIP There are also you score use cases where you have to deploy where for us It made sense to concentrate a bunch of time to be able to give you load balancing across our catalog Because think about open stack itself Open stack itself was built as a framework that could be deployed in many different ways to support many different work loads right sometimes launching a multi-tenant virtual edition of our appliance and doing Tunneling from that to do multi-tenancy was what made sense Sometimes running clusters of our appliances makes sense.  What happens when you have use cases that legitimately call for a VIP at 40 gig? What could you do? That's why it was very important for f5 to say that our LBAS solutions for open stack Supported our entire product line including our own virtualized appliances our VCMP instances So we spent a bunch of time and a bunch of work to make sure that when you got LBAS from f5 you didn't get a VE LBAS You got an f5 LBAS Across our product lines and across our product offerings because your workloads may not make sense to run in a VE Your workloads may make sense to something where the a hundredth connection Connects at the same reliability and with the same timing as the millionth Open stack should support those ecosystems and network setups and workloads. So should we now that didn't mean we were stuck with multi-tenancy We can also do single-tenant LBAS So for the use case where you just wanted to launch a VE and you want to hand it off to that tenant Can the LBAS solution work with it? Yes. Do we have solutions that are smart enough to know the difference?  SDN is a critical component in open stack, right? so Your big IPs are VTEPs Now what does that mean? That means that it's not just a load balancer It is now a full-fledged VTEP as part of the neutron network Which means we have to update fib tables when you add a when you add a you know you add your guests over here We have this beautiful service called L2 populate Well now we have to pay attention to it like we were an L2 solution and be able to graph those things in as VTEP Now get this this is something that that Rick and I spent a lot of time looking at some of the core vendors And said no no no no no our Vee is on a VTEP Right, which is a little unusual which was unusual, but we're like no you need to support that Can we launch some Vees up there in a multi-tenant fashion go right through? The security groups because the VTEPs the address it's routing to and still support that device having a bunch of multi-tenant tunnels on top of it. Yes Can you do multi-tenancy with us with just Vees? Yes It is a VTEP that joins into the network with your compute nodes. That was the heavy lifting because again the point was ADC the way you wanted to see it in your specific open-site cloud to support your workloads Does that make sense to everybody? You see why it's a little larger definition than saying I can launch a Vee and Put a VIP on it There's a lot involved Now we know that Vees are very important specifically to NFV So on our virtual edition so on our software based Virtual editions we knew there was a lot of things we had to do to be able to support to take advantage of the ecosystem That is OpenStack. OpenStack provides a tremendous amount of information about those Nova instances right I can tag in with metadata. I can do all sorts of good things Now the first thing we had to do was like a lot of network vendors we have a virtual appliance Does that make sense? It's a virtual appliance, which means there's some black box nature to it because you you ship it as an appliance It's not an Ubuntu or CentOS image that you add packages to Now there's a reason for that. We have security certifications. We've got all sorts of hardening. We've done There's all sorts of pieces, but when you go to downloads.f5.com You see virtual edition this speed this stuff when our marketing terms and our stuff and all these things So one of the first things we had to do was translate Translate into OpenStack speak because to use our virtual edition should you be should you have to be experts on f5? marketing speak and Licensing speak no You should be an OpenStack person So one of the things we did is translate those into appropriate Glance images and appropriate flavors. Do you know why you need unique flavors for ADCs? Because they're unique workloads right? Could you deploy an ADC and because you pick the standard flavor be very inefficient in your cloud? Yes, so do you need to see the flavors that match to the ADC workloads? Yes, so we did that work There's also this notion of high availability in your load balancer. How many want a single point of failure load balancer? right F5 platforms support clustering Now those clustering Like to put that cluster in that's an exercise that we normally shake hands with our lovely certified F5 Engineer and the engineer knows how to set up our clusters and do all that work and they say yes I can get that done and there's a thousand knobs you can tune a thousand ways to get it to work great In OpenStack because we know so much about the environment we can put it all together for you and build those clusters for you on the fly And that's the work we've done now What kind of workloads? 20 mag 200 mag 1 gig 3 gig instances those all pretty much can work as Sitting on top of most software networking solutions, but I'm going to ask How well are the v-switches working at higher speeds 5 gig and 10 gig? How we doing? What Rick what what did what did neutron add in Juno? SRIOV so you think we should do that of course we should do that So do you have SRIOV support in your software load balancer? You should and We have SRIOV support to get you to the 5 gig and the 10 gig instances of our software appliances Does that make sense all stuff the community supports all stuff that we should track Now There's also this notion that not all network implementations of neutron look the same do you appreciate that? We go with the stock we go with the reference implementation with OBS or Linux bridge We've got all this data we can collect and do stuff We work with the particular SDN controller and maybe those neutron extensions aren't supported Not if you understand what I'm talking about There can be a lot of source of truth issues about where things are For instance, I want you to think about a complex cluster setup of virtual additions across three different compute nodes This is just the network part.  What's that mean? Well, that means we have a lot of dynamic on-the-fly multi-tenant L2 binding To every device Depending on how you set it up. I could have two legs. I could have five legs. I could have a hundred legs now Is your load balancer an L2 device? No It's actually higher than that goes up the stack So do I need to graft L3 onto those L2 and by the way does neutron give me Subnets and all that all the IPAM data sure it does so should I be able to do that? Yes So there's L3 bindings. Well, what all does that mean? Well, that means I have to give things fixed addresses for the cluster I have to go through things how many people know that snap pools should travel with cluster addresses for high availability So you don't have connection failures when you have a failover device Or how many people know that you'd like to have more connections and 60 and then 64,000 So you don't run out of port exceptions So should you have to dynamically build your snap pools and should you dynamically have to be able to place your services so that they fail Appropriately cross-ter clusters. Yes Think about and by the way the failing in an L2 cluster requires allowed address pairs in the reference implementation, right? Think about all the complexities of binding L2 and L3 in a fully clustered solution We've orchestrated all that works great with the reference implementation works great with people who are ML2 compliant if you're not Our agent has very distinct L2 and L3 bindings broken out. Why do you think that is? So you can tell me who you're working with so we can shake their hand and we can get it to work Does that make sense? How many of you have open-site clouds that are not the reference implementation for your v-switches? Oh, we love you guys Little work to do Tony put your hand up. I know you do So does this make sense to everybody there's a lot devils in the detail you always appreciate that The details are important and we've worked very hard to make sure those details were covered now What do we do behind beyond LBAS? How many people want more features than what's in LBAS v1 or v2? How many people know that we support a lot more features than are beyond LBAS v1 or v2? Our devices do a lot more things than that. However, let's ask are the underlying network primitives that are supported by LBAS v1 and v2 Good enough for 80 plus percent of your use cases is a good enough to do the L2 binding and the L3 binding into neutron Yes Now what do you want us to do beyond that? Well, it would make sense that you'd want us to bring the full weight and bearer of F5's application proxies to OpenStack So LBAS is one service definition At F5 we have a templating language that we've spent a lot of time and money and energy to be able to do Application service templates. It's called IAPS So enterprise vendors for a long time have been working with us to say I have this templated deployment that simplifies out how I do a complex application in a templated fashion for big IP Now I'm going to ask if we already have all the network primitives and all the plumbing and all the L2 and L3 plumbing done for OpenStack Do you think we should be planning on bringing our IAP templates as service definitions down to that plumbing? So that we can give you advanced services inside of OpenStack That's the way your LBAS is running now It's already a service definition We prepped for that beginning. We built service definitions inside of Neutron we pushed it out the agent played it next step was move it to an IAP Now that we have is in an IAP. Do you think we can start templating other services for you? We can so In our little bit of time we had with you today what we wanted you to appreciate is one network grafting into OpenStack and into the use cases and workloads that OpenStack could support isn't trivial There's work to be done We spent a lot of time doing that work across the F5 products to On our virtual editions for NFE and for other things There's a lot of work to be done to be able to say that we can onboard them correctly make them look like proper OpenStack resources, not just a vendor resource. We've done that work Where the community supports higher speed options. We've done that work When you talk about other service definitions beyond LBAS that we can support with our application proxies We have already architected our LBAS plugin to be able to take the top end of that service Replace it with another IAP and fit on top of all the work we've done to cluster and get the plumbing right Does that make sense everybody? Did we do the right thing for you? We're trying We're trying very hard to make sure that the full weight of advanced network services comes in a tested Supportable across multiple platforms your workload your way type of Service definition and deployment That was our LBAS. It's a lot of work Absolutely Do you guys have any questions on stop? You have any questions about the specific stuff that's inside the goodness. Please come see us if you do Specifically any questions you have about the SDN grafting or big IPs acting as full VTEPs inside of your clouds Specifically questions about what do I do when my company has the following 12 services that I want to build into IAPs And I want to graft into open stack Because we can tell you how we're working through that specifically in private cloud. Okay We're taking the red hat model to that kind of you know how red hats the 90-day delay to watch the blood spill on it So the answer that is No, we haven't released it. Oh, yes, absolutely And and so the LBAS V2 for us gives us more flexibility and even the next stuff That's coming for Liberty to be able to say that we've completely decoupled the pools in the VIPs Again for us. That's just another Reorganization of the service definition. Yeah box does it right? Right, right and and we'll continue to keep up with what's released To be able to say that all of the standard services, of course will work Because if you just wanted to do LBAS It's simple. We'd love to do that if you want to do an advanced service or I guess our statement to you guys is let's let's Templatize it as an IAP and then graft it into the existing network architecture with neutron that we've put together Now we're going to have to do proprietary solutions with proprietary SDN vendors that don't put all the Data model in neutron. We're going to do it So as customers come to us and they say hey, I've got this proprietary SDN vendor. I need you to go do this We're going to work it into the model I'm going to ask once the SDN has been worked into that model. Does that change the IAP at all? No So all the services deployable across different SDN vendors. Sure. We just have to figure out how to do the L2 and L3 plumbing Your way the reference implementations are done the ML2 implementations are done And it's worth mentioning that we have a partnership with New Osh and we have a reference architecture Right to be included in their reference architecture and there's documentation on at our booth about our New Osh integration Right, and I have to I have to I mean I'll speak to that a little bit our friends at New Osh, too We're kind enough To say hey look there's some of these API calls that we can simply support using the Neutron APIs and not make you do some things and they've been very good to us to say yes They should be supported for instance allowed address pairs A lot of address pairs should be a neutron call doesn't necessarily have to be a proprietary call So we're working with them and we're always going to try to push into a community solution So that the API calls would look the same whether using the reference implementation or something else We will always try to promote that Right, it's good to see things like the L2 gateway right that we can take advantage of and Vlan aware via VMs Things like that will allow us to expand our solution and we're talking. We're talking with the folks that did the hierarchical port Demonstration for for you saw that that presentation there for hierarchical port so that if you didn't want us to be the V tap We could simply do Vlan taggings and let somebody else do that work So we're going to try we're going to try to be the community member and try to promote the open way of doing this But still bring the richness of templated services to what you can do with our product Make sense Good. Thank you for your time. We appreciate it moments