by Seth Brown on December 20, 2012 // Short URL

Mistakes Agencies Make: A Story in Three Acts

It's easy for web agencies to fall into these classic traps: learning to recognize and sidestep them is critical for long-term success.

There's a Niels Bohr quote that I love: "An expert is a man who has made all the mistakes which can be made, in a narrow field." After ten years working as a development manager at web agencies, I feel like I've made more than my fair share. What follows are three different mistakes that I've either made or seen other agencies make in hopes that I might save you, my generous reader, the trouble of making them yourself.

Act I: The Blood of Unicorns

" is a monstrous thing, to slay a unicorn. Only one who has nothing to lose, and everything to gain, would commit such a crime. The blood of a unicorn will keep you alive, even if you are an inch from death, but at a terrible price. You have slain something pure and defenceless to save yourself, and you will have but a half-life, a cursed life, from the moment the blood touches your lips." — J.K. Rowling, Harry Potter and the Chamber of Secrets

While in Berkeley last month for Badcamp, I met a designer friend for breakfast. Despite the hip, sun-drenched, vegan-friendly vibe, the excellent espresso and the excitement of the camp ahead, my friend seemed forlorn, and not fully present.

My friend is that rare breed of graphic designer who also knows Drupal theming, markup, CSS frameworks, and jQuery...and understands UX...and responsive design...and PHP..and rapid prototyping. This makes him that rare, mythical beast known as a UX unicorn.

“What’s wrong?” I asked my friend.

“I’m thinking about going out on my own again.” This troubled me as I had recommended my friend find an agency job when he became burned out on the 80-hour weeks that go with running your own freelance business. I pushed for details and found out that my friend was literally booked for 85 billable hours per week on the schedule. Yes...85. He blamed his resourcing manager, but, as I probed for details, another story emerged. It turns out the resourcing manager was just caught in the crossfire between sales and production. It turns out that the agency had a disproportionately large sales organization, a much too-small production team, and rampant opportunities.

My friend’s agency, let’s call them Acme, had grown up in an area where web talent was hard to find and expensive. Instead of holding back sales, the company opened the flood gate, hiring junior developers, interns, and a legion of “account managers” to help manage client expectations. These teams would provide the illusion of service while waiting for the few talented engineers and creatives to free up. The account managers, ostensibly hired to protect the developers from clients, turned on their besieged production team, jockeying with each other for the attention of designers and developers for their respective clients.

In the end, according to my friend, Acme had quality control problems even though they were building fairly simple projects, and, while they were able to sell lots of web projects in the $15K - $30K range, their client retention was poor, and they didn’t have a reputation that would allow them to start taking fewer, larger clients—a typical path to sanity for smaller agencies.

Acme’s problem lies in the disparity between its prodigious sales talent and paucity of engineering talent. They were figuratively drinking the blood of unicorns to sustain their business, but at what cost? Low quality, a poor reputation, low morale, high employee turnover, and a higher cost of sales since there are fewer repeat customers. So how to solve Acme Agency’s problems?

Finding Solutions

First of all, they need to discipline their sales effort. At Lullabot, we’ve created a capacity chart. This is the photo negative of the typical manager’s resource utilization chart. Instead of showing who’s booked on what, it shows the sales team what availability can be sold. Once that availability is removed from inventory it’s gone and sales doesn’t try to sell into it. At Lullabot, we try to book our team no more than 30 hours per week. There are occasional exceptions of course, as we still exist in the real world of unexpected technical hurdles, client-driven delays, and late launch nights, but it’s important to us to protect the sanity of our team. We don’t do this out of altruism. We do it because human beings and organizations need slack in the system. As Tom DeMarco says, in his fabulous book Slack: “Slack is the natural enemy of efficiency, and efficiency is the natural enemy of slack. There are things you can do to make an organization more efficient that interfere with its ability to change and reinvent itself later.”

What does our Lullabot team do with this slack in the system? Many of them spend hours working in the Drupal issue queue or on their contributed modules, others learn new technologies, and build their own projects and products. (We’re even starting up an internal art and science fair this year to showcase our mutual creations this summer.) Obviously, most people have heard of Google’s 20 percent time, so this should be nothing new. But in addition to allowing us to innovate and adapt as an organization over time and retain good people, it also means our quality is higher (since our people aren’t overworked, they’re less likely to sacrifice quality for speed and, in their own time, they’re constantly researching and playing with the latest technologies).

As quality improves, reputation improves, and, as your reputation increases you can take on bigger and bigger projects. With bigger projects comes the opportunity to book people solely on one project. Human beings are not fungible commodities like oil that can be horse traded in bits and pieces between projects. Task switching incurs an enormous penalty on efficiency. Some theorists estimate efficiency losses as high as 15% for each marginal project. If you can avoid it, don’t spend precious efficiency subdividing your people between a thousand different clients.

Finally, the tools exist to manage your people virtually. If Acme were to relax their in-office requirement they might be able to find more Drupal talent wherever it exists, which would allow them to grow their overloaded production team. Find the best talent where it exists. Lullabot is a fully distributed company, which means we can hire the best Drupal developers wherever they choose to live. Throwing inexperienced production staff—or worse yet, account managers—at your technical debt just because they’re the best you can find locally is not a reasonable solution.

  • Don’t overschedule your resources, the pursuit of efficiency can be the enemy of flexibility, retention, and sustainability.
  • Discipline your sales effort and make sure it matches your capacity
  • Consider a capacity report that shows your sales team exactly what they have to sell.
  • Hire talented people wherever they are, don’t limit yourself geographically.

Act II: Of Hubris and White Whales

“Talk not to me of blasphemy, man; I'd strike the sun if it insulted me. For could the sun do that, then could I do the other; since there is ever a sort of fair play herein, jealousy presiding over all creations. But not my master, man, is even that fair play. Who's over me? Truth hath no confines.” —Moby Dick

“I would strike the sun if it insulted me!” I remember reading these words with adolescent awe and thinking, “F’ yeah.” I loved Ahab’s outrageous hubris. It was similar for me with Neitzsche and with every nihilist protagonist in Russian literature who would occasionally break their studied silence to play Vodka-fueled Russian Roulette to the great distress of some adoring tragic heroine. Clearly my judgement had a way to go. Hubris is after all tragic flaw numero uno.

Earlier this year, Lullabot was referred to a really sexy opportunity. This was way BIG for us…and our standard fare of clients like The Grammys, Sony Music, and Martha Stewart is not exactly small potatoes. With fame, fortune, and a wee bit of hubris in our eyes, we flew out to a major Eastern seaboard city and made our pitch. After hearing more about the opportunity, we decided to go for it. Marshalling a large part of the team’s energy, we put together a 100-page proposal, providing an architectural roadmap and recommendations for how we would do the project. A week later we heard back, we were a finalist! Even better, one of two finalists. We were ecstatic. We headed out East again with about 10 Lullabots to do a second round of presentations. During this time, I had a niggling, yucky feeling at the back of my mind. Because of the short timeline and massive scope, this project as we had proposed it was going to take nearly all of our resources, and involve some of our partner network of companies.

We were ignoring the fundamental rule of risk mitigation: diversification. Portfolio theory 101 tells us that risk and reward are inextricably linked. Because humans like reward and abhor risk, we diversify. In financial terms, risk is essentially volatility. Projects are inherently volatile, but they are differently volatile. By having multiple projects, an agency mitigates risk. Some projects will go great, others will drag you down, but having a healthy mix means a lower exposure to volatility in any particular direction. But why make it so complicated? Our ancestors walking out of the cave with two separate baskets of eggs knew this principle. It’s common sense. But we were intent on this figurative white whale, swayed by the collective excitement of doing something big and unparalleled.

A week after our visit, there was ominous silence from the potential client. We knew this wasn’t a good sign, but it wasn’t until a week later till we heard we’d lost the project to another, larger agency. We’d spent $10K chasing that whale, but we also felt strangely relieved as we returned to business as usual. Sadly, that’s not the end of the story. We found out a couple months later that the BIG CLIENT ended up purchasing a major existing web asset to fill the gap and terminated the project after a month or so, leaving the winning vendor in an awkward position. We’d dodged a bullet on that one. To ramp up for a project this big and long, we likely would have slowed our sales effort, gotten into agreements with partner agencies, and committed the bulk of our team. Extricating ourselves from that mess may have proved difficult.

Lessons Learned

Thinking back on the experience, it’s not only the lesson of diversification that I learned. In Moby Dick, Starbuck, the Pequod's charismatic first mate, tries to save the ship, questioning Ahab's monomaniacal obsession with the whale. I feel like my inner Starbuck was trying to warn me all along, but I was unwilling to listen. If you find yourself chasing whales, make sure to engage in a broad, open and honest conversation with your team and examine your own instincts. Don’t quelch dissent by simply labeling it as pessimism. And, if you still decide to harpoon a Leviathan, make sure you’re capable of enduring the downside, not just the up.

  • If you’re going to go chasing whales, check your hubris at the door and make sure you’re consciously assuming the risk.
  • If you’re risk averse think of your project portfolio as you would your 401K and diversify, diversify, diversify
  • Allow for healthy dissent in your company, and in your own mind. Listen to those niggling discomforts in the back of your mind and bring them to the forefront to be analyzed.

Act III: The Ponze Ain’t Cool

“How sad it is! I shall grow old, and horrible, and dreadful. But this picture will remain always young. It will never be older than this particular day of June. . . . If it were only the other way! If it were I who was to be always young, and the picture that was to grow old! For that-for that-I would give everything! Yes, there is nothing in the whole world I would not give! I would give my soul for that!” —Oscar Wilde, The Picture of Dorian Gray

Dorian Gray trades his soul in order that the damage from all of the years of sin and debauchery accrue to his portrait instead of himself. While the portrait shuttered up in the attic grows blacker and more hideous with each passing year, Dorian retains his youthful, innocent beauty. Of course, eventually things come home to roost, but I don’t want to spoil the ending. How does this relate to a mistake that an agency might make?

When I started out with my first agency in 2003, we were three people renting the extra space in a server room from a larger area software company. We were eager to make a dent in the marketplace and build some awesome websites. We wanted to make dreams happen, especially our own.

Like many small businesses, we didn’t have a lot of money to spend on accountants or process so we used Quickbooks and set up a basic chart of accounts. In cash accounting, you recognize cash as it comes in and goes out. It’s that simple. This seemed far less complicated than accrual accounting so it seemed like the right choice for us.

Being the savvy business people we were, we didn’t want to get scammed so we decided on a policy of 75% up-front and 25% on launch. Because our sites were small, most of the business people we wanted to work with could afford this, and we didn’t want to work with the ones who couldn’t. Life was good. This policy saved our bacon a couple of times, both because it protected us from unscrupulous players, but, also because there’s a time value to money and cash sooner trumps cash later. With lots of cash up front, we were able to bring on additional resources as the jobs got bigger and we didn’t suffer liquidity problems. At least in the beginning.

Soon, problems began to emerge. It seemed like we could never finish projects and there were too many jobs to do, with new ones piling up at the door. Still, top line revenue growth was off the charts, which suggested to us we should keep doing more of the same. We grew and grew, hired and hired. Because we weren’t tying revenue to work, the only incentive was to take more work, regardless of capacity. Eventually it becomes like an addiction, a Ponzi scheme. You can’t afford to pay people to finish your current projects until you’ve secured new work, but the new work is paying for work you should have done in the past.

Avoiding the Pitfalls

Growth can be a Faustian bargain, camouflaging a host of problems. If you’re going to grow, do it carefully and fund it with cash reserves from profits you’ve booked in the past, not with the revenues from future projects. There’s such a thing as a maximum financeable growth rate if you’re growing without the benefit of outside capital. It’s beyond the scope of this article to explain how to make these calculations, but I was able to get a handle on this stuff after taking Guatum Kaul’s excellent, and free Intro. to Finance class, which is being offered again in January. Coursera is also offering another promising January course called Grow to Greatness: Smart Growth for Private Business, Part I, where these topics will be explored in greater depth.

In the end, Ponzi schemes by their nature come crashing down. When you’re oversold, your efficiency eventually seizes up, just as too many cars on a highway leads to a traffic jam. At a previous company we recognized the problem before it was too late and switched to accrual accounting. In addition, we took a more studied approach to growth, but only after a period of illiquidity and diminishing profits caused us to do some real soul searching and self-education.

Even if you’re a young company, try to tie revenue to work. Structure your payments into a third at project start, a third at the midway point, and a third at project completion, or tie payments to multiple milestones in the project. If you want the litmus test of money up front as we did, talk to your accountant or bookkeeper about how to stick the revenue on the balance sheet and then recognize it over time as you work the hours.

Another strategy that Lullabot uses is to work with clients on an agile basis and have them pay per sprint for a set amount of resources. Our sprint model—based on a combination of scrum and rapid prototyping—typically involves a cross-functional team of three full-time resources for a series of two-week sprints at a fixed cost. Ideally, the team has a UX unicorn, a back-end developer, and a front-end developer. The client controls the backlog and dictates what we work on in each sprint. By being cross-functional, small, dedicated, and proficient with Drupal, we’re able to bring projects to market quickly, and for much less than comparable scope waterfall projects. In addition, we solve the cash flow problem. Each team earns a regular two-week paycheck for the previous two weeks of work. How might you structure deals to avoid the cash flow roller coaster?

  • You don’t have to fully convert to the complexity of accrual accounting to tie revenue to work.
  • Learn about SFG (maximum financeable growth rate) and maintain adequate working capital in the business.
  • Growth, like Dorian Gray’s portrait, can conceal a host of ills. Pace yourself and be careful not to disguise project or resource problems with growth. It will catch up with you in the end.


The pitfalls discussed above don't appear out of nowhere; they often come alongside opportunities. Learning to sidestep them helps mature web agencies to make the most of the good without suffering from the bad.

Wood engraving image from the Illustrated London News in 1847

Seth Brown

Chief Operating Officer

Want Seth Brown to speak at your event? Contact us with the details and we’ll be in touch soon.



All is not well with Drupal shops

This is interesting to me as a freelancer picking up Drupal maintenance work and wondering how Drupal shops with a decent looking portfolio can get their Drupal work so wrong, and wondering how things look from inside a Drupal shop.

When a client has an unrealistically low budget, there are people out there who say "yes we can" and if necessary sign a contract. Someone like me with no sales angle apart from being upfront and says "the budget is tight, you need to scale back expectations, or up the budget" will not get the job. I am left wondering whether the sales people who always estimate on budget actually talk to engineers with specific Drupal skills before agreeing to work for unrealistically low budgets? The above post seems to point to the opposite problem of having more than enough work, presumably at realistic rates.

Second point, Drupal shops are using engineers with a range of web dev skills but often with inadequate Drupal skills, writing odd and buggy custom code where it is not needed, either because they do not know how to use Drupal properly or because they can charge more for their custom code.

I am left with the impression that /the majority/ of new Drupal clients are in for a painful experience. Only those who understand the value of paying several times the lowest estimate will be well served. However, this may be self-selecting, because I only see sites where there are problems.

Obviously I know Lullabot are fantastic. I will actually say to a client "if you can afford a Drupal shop at that level, you will get great value". But on the ground, for the SME work which is out there, the landscape is NOT populated with comparably credible Drupal shops, it is populated by people who take the money and deliver a poor product (and somtimes, literally, no usable product at all). The Drupal world would be a better place if all Drupal shops had the skills, and the luxury of success, to match the high standards of Lullabot.



SME Drupal is tough...

When thinking about SMEs doing small sites in the $2 - $6K range, I wonder if Drupal is even the right solution. If it needs to be Drupal to allow for future extensibility, maybe something like Drupal Gardens is the right place to start. I'm also a big fan of Wordpress for smaller sites that are primarily pages and posts.

Thanks for the kind words about Lullabot!


Amir Simantov

So right!

I second Seth's opinion that small sites should not be built with Drupal unless there is a known path or intention to further develop them.

Being a Drupal evangelist, I do not hesitate to tell peers and prospects that about 80% of the content-related sites do not need Drupal and should rather use WordPress. Drupal overhead is high due to the complexity of the system - as it had a fatter abstraction layer - hence should be used only for projects that actually need the complexity and capabilities.



Garrett Albright

As a developer who's mostly

As a developer who's mostly worked with agencies throughout my career, I think you might be being a little hard on agency programmers here. Yes, sometimes bad developers happen, especially when the person in charge of hiring is not enough of a developer themself to be able to determine if a potential hire is a decent developer or not (and/or doesn't ask the decent developers already on board for their opinion). And yes, sometimes sales people over-promise. But even if the contract is realistic and the developers are talented, I've seen a lot of projects go off the rails, or nearly so, due to that classic project-killer (and something I'm surprised hasn't been mentioned in the article or comments henceforth), scope creep.

When the client tells us that they cannot launch without this henceforth-unknown largish requirement which is going to require twenty-plus hours to implement, and by the way the site is scheduled to launch in eight, six, four, two weeks, developers sometimes have to implement things shoddily in order to just get it done and out of the way, whereas had they more time, they could implement it more cleanly - and had they known about it from the very beginning, the entire project could have been engineered with that requirement in mind. I will certainly confess that I've written a lot of code that I'm not proud of under conditions like that. Bad devs write bad code, but sometimes good devs write bad code too.

That's why I think it's important that clients know what scope creep is and why it's so important that it be avoided as much as possible - that it will not only negatively affect the cost of the site, but also the quality (unless the launch date is not an issue). And yes, that means a higher initial project estimate, but they need to think of scope creep as a hidden cost that might be present in those lower-price estimates from other dev shops that didn't ask for as many pesky details about implementation.

I don't think the client is entirely to blame, though. I think sales people and PMs also need to know to ask the right questions of clients. In the clients' mind, if they're asking for an e-commerce site, of course they need quarterly recurring payments and integration with a wholesaler's crappy almost-but-not-quite-REST API that sometimes returns XML and sometimes returns CSV - but they're not aware that they need to explicitly say that. A good sales or PM person will know that they need to suss those details out of the client so they can be passed on to the devs now rather than later. Unfortunately, I don't think having the talent to do that comes from anything other than experience…



Scope Creep Out of Scope

Hey Garrett,

You make a vital point. That said, I feel like scope creep, it's ills and cures merits a whole separate article. I also feel like it's not so much a "mistake" that an agency or a client make, but rather a constant that every project must face. We try to engage with our client in an "Agile" manner, where we're retained per sprint for as many sprints as the client needs to get the work done at a fixed cost. Ideally these agreements aren't tied to deliverables or scope in the first place, negating the problem. In a world of fixed bid, deliverables-based commercial agreements and waterfall projects scope creep is a *huge*, arguably impossible problem to solve. Humans are not particularly good at forseeing the future, or grasping a thousand complex, minute details all at once. That said, it's not going away, and I think you've given me a great topic for a future article.





Beautifully written and

Beautifully written and informative article.
The literary comparisons made this such a refreshing change from the usual '5 pitfalls to avoid' blog posts that pervade our newsfeeds.
Thank you for sharing.



Thanks Simon!

I ended up stripping out some of the literary nerdiness because it felt like it could be a speed bump for a lot of readers. Appreciate the kind words :-)



Great Article From an Up-And-Coming Shop

Thanks for the great (and finally useful) insight into growing a Drupal shop. I run a relatively young Drupal outfit, and your experiences and advice fall directly in line with what we are going through right now. Nowadays, the Drupal work is so plentiful that it's really tough not to fall into the trap of taking on more work than our resources can (reasonably) handle. Your article is a great reminder to take a step back and focus on a growth strategy that is sustainable and sane. Thanks again!


Ryan Szrama

Wonderful article, Seth.

Tucking this away in the business bookmarks folder for future reference. And you can't put too many literary references in an article to put me off - though I must confess I'm pretty sure I got bored with Moby Dick before I got to that part. ; )



Great words of advice

Thanks for that article. I like your somewhat abstract use of literary analogies!

I've run two small Drupal shops in the UK over the past four years, and everything you say is spot on!
It is really difficult to to turn down work when you're a young company, but so much money, time and stress can be saved by being selective with work.

I'd also suggest that small/new agencies should consider focusing on vertical markets, in order to build up 'experience' (as perceived by clients) in specific sectors. What is your opinion on this?



Great advice on building experience in a "vertical"


Great point on learning a "vertical." It's a great filter for enforcing discipline on your sales effort, and an easy one to implement. Both Lullabot and my previous company have particular business areas that we specialize(d) in. I think it's perhaps the greatest competitive advantage you can build for yourself. My previous company, Blue Tent, was a leader in vacation rental companies and most of our business came from our expertise in that field. For Lullabot, we mostly focus on enterprise-level media, news, and entertainment properties. In both cases, our knowledge of the business domain is easily as important as our knowledge in Drupal. Or, put another way, it's the intersection between those two where we really shine.




Ross G

Vital importance of good Project Management

Yes, great "reminder" article for newbies and "old hands" like myself (nearly 13 years owning and running a web agency).

As indirectly alluded to by Garrett in reference to scope creep... IMHO the importance of good project managers/management cannot be understated, and therefore needs to be explicitly stated.

A great project manager will successfully manage/balance:

1. The need for the company (his/her employer) to make a profit
2. Demands/expectations placed on the designers/developers
3. Demands/expectations from the client - including the virtually inevitable scope creep issue.

If your PM isn't effectively managing 1+2+3 (and it's a very challenging job!) then projects will most likely stuff up.



Not-quite scope creep

As a client, I have had to deal with something that was probably called "scope creep" by our consultants. That said, what I experienced was this:

1. I (and my co-workers) provided tons of information up front;
2. The consulting company clearly did not review that information and agreed to a very complex task;
3. The consulting company hired a subcontractor;
4. When I communicated with both companies after development started, it became clear that the consultants didn't have any idea what they'd agreed to;
5. The subcontractor did their best to fulfill the request;
6. We got to the end of the money and didn't have any more;
7. The consultants pulled the plug.

In this case, who sucks it up? The consulting company, I hope, took more of the hit than the subcontractors, because it wasn't really their fault. And we ended up with a big expensive site that hadn't fully been quality controlled and no instructions or plan for maintenance. The learning curve was very steep, but ultimately we're okay, and we probably got at least our money's worth.

We were certainly to blame for getting in over our heads, but the consulting company should take some blame for not really paying attention to what they were told.

Anyway, cautionary tale, and (despite its lack of detail) I'm curious what others think about it.



Great Advice for All

Thanks for a great article. It's a great reminder of what's important for web developers, designers, SEO's, SEM's, and really all other small and growing web-based contractors out there. Take care of your people, take only well calculated risks, and manage your growth.




Thank you for being willing to put yourself out there and share this info. Your perspective and experience is incredibly helpful!



Thanks for this article. I

Thanks for this article. I think the part of how to manage payments and growth is difficult to manage if you don't have the experience or some advisors. At the Drupalcon there was some discussion of these topics and we were lucky enough to participate and hear from other Drupal Agencies mistakes and lessons learned. I can relate to the white whale mistake: the hours that we invested in it were too much for a project that in the end, it seems it would be more a pain.

Once again thanks for this article, I hope you write more about these topics.



You have made me smile

You have made me smile several times in this article. There are many blatant truths that are being ignored consistently by many web agencies.

I come to understand that if a company tries to manage their team in an emotionally sustainable manner that team will produce amazing results. On the other hand you put the same team under insane schedules, unrelated business pressures, treat them just as labor assets, … and it will end up with very different results.

Great article!