Jameson Watts

Seth suggests in this post that new marketers need to be smarter than the current crop because online media requires “too much measurement, patience, creativity, technical knowledge, flexibility, speed and authenticity.”

I disagree. The best marketers have always been smart. In other words it’s not a lack of brain cells that hamstrings the current breed, it’s the rate of change. Mr. Godin was sort of right when he suggested that television’s reign has made certain formulas predominant; however, profit potential usually attracts the best and brightest not the “complete moron” alluded to in his post (note the recently discharged intelligence-magnet of Wall street).

Except possibly at the start, the vacuous stooges Seth is postulating don’t exist. TV advertising is competitive and its margins have been shrinking since the beginning; unless you are a regulated utility, it’s gonna happen. This means that more intelligence and more creativity are required to make the same profit. I think the current group of “traditional” marketers may actually be better prepared for the challenges brought on by the internet than Seth thinks.

It’s still research, it’s still segmentation, and it’s still the value proposition (authentic or not). Where I agree there may be a disruption is with flexibility, speed and patience. As consumers begin to participate in the creation and sustenance of a brand, they expect real-time interaction that evolves with an organic participant base and earns trust over time.

It may take time to build the technical infrastructure that responds and adapts in real-time and the courage to invest money in something that may take several years to cultivate.

Nice opinion piece by Joel Spolsky on the realities of software development and the personalities that permeate the industry. The main thrust of his argument is that software can always be improved and the ability to ship something that works (on time) is a “feature” in itself. “A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has…”, suggesting that many individuals and companies spend too much time working through how something is done rather than just doing it.

This philosophy seems especially relevant for agency work where a good portion of what we accomplish is temporary. Consider the example of programming a micro-site for a product launch. This is something agencies do on a regular basis and it is always time sensitive and usually temporary. However, the projects can also be fairly complicated to program (go check out some IZZE projects here or here), which lends itself to the sort of over-solving that Joel is speaking to. It’s impossible to know how long a piece of software will exist, but it’s imperative we at least consider the following criteria before deciding on an approach:

1. Does the client have budget for an elegant solution?
2. Do we have enough time to think through the architecture (and how likely is it to change before launch)?
3. What is the likely life of the software and will we be maintaining it in the future?
4. Is the client willing to pay for performance and architecture upgrades after launch?
5. Are there legal or regulatory constraints that require additional layers of security and accessibility?

There are many more considerations (including the composition of personalities on your development team), but this is where I like to start.

I know programmers who will argue till blue in the face for one approach vs. the other and each could prevail on the merits alone… but of course that’s not the point. The point is to succeed in the client’s and consumer’s eyes and the shortest point between now and that success is often the Duct Tape Programmer as Joel suggests.

Our recent launch of the IZZE Connect site (you should take a look here and read about it here) was a big step for a cult product into the sometimes scary realm of social media; however, the true challenge of the site wasn’t so much the technology… it was the brand. IZZE is loved for it’s design, it’s natural message (and product) and the honesty of it’s marketing. These tenets played a major role in how we approached a project fueled by social media.

First it was essential to actually “design” the site. Interacting with something IZZE branded isn’t just about the end result, its a statement about the choices you make as an individual and a reflection on how you feel about yourself. IZZE drinkers are happy, creative people and we wanted to provide an outlet where the most loyal could share that part of themselves with friends and family.

Of course the old rules of marketing still apply. Giving away “free” stuff and making it exclusive and scarce are all part of the puzzle; however, it’s really about engaging the consumer, making them an integral part of the brand and providing the tools to evangelize IZZE’s message.

For all you agency folks out there… what is your experience with the time division of Design vs. Development? Every project is different, but I’m interested in any guesses, average or real statistics from your experience. Is it 30/70?…  70/30?

I was inspired by Micah’s post on the Learn to Duck blog in its ability to distill job functions at an entrepreneurial software company into a series of questions. It got me wondering how I would do the same for an agency. Here’s how he defined the roles at Lijit:

• CEO – final decision maker; vision builder (”What do we want to be?”)
• Operations – operationally focused; makes the business run (”How can we make that a reality?”)
• Bus Dev – Lives outside reality, thinks about what is possible. (”What is possible?”)
• Product – Lives in feasibility; thinks about how to make things reality (”What is feasible?”)
• Engineering – Focused on making. They are the builders. (”Can we do it?”)

Here’s how I might break it down for a creative agency (some are the same or similar):

• CEO – “What do we want to be?”
• Operations – “How can we do it profitably?”
• Bus Dev – “What do we do better and who needs it?”
• Accounts – “How do we meet the client’s needs and exceed their expectations?”
• Creative Directors – “What is possible and should we do it?”
• Design / Interactive – “Can we do it and how?”

At our agency, a lot of these roles overlap. For instance, many at Vermilion brainstorm the possible; however, it’s often the creative director and myself (and sometimes the CEO) that analyze whether we should execute on any of the ideas. One major difference in my analysis is in the role of business development. I see it as much more of a marketing role since much of the creative thinking is often accomplished by the rest of the team.

About three months ago we were getting more RFPs than we could reasonably process, but in the last month that flow has substantially slowed. Oddly enough, the same phenomena occurs two other times of the year: once in November and again in April.

As you might imagine, this creates a certain degree of consternation within our business development team, albeit the seasoned personnel seem to intuit the pattern. Our best analysis is that those responsible for organizing design and interactive projects don’t want to process proposals during a period of the year in which their life is busy outside of work.

Right now, kids go off to college and back to school. In October, families are preparing for Thanksgiving and Christmas, and in April many are planning for graduations, weddings and the kid’s summer break. As a practical matter it seems agencies ought to adjust their forecasts to account for the inevitable sine wave of incoming work and try to schedule several projects during January, May and September.

Typical in my line of work is a scenario where we launch a large interactive project followed by months of ongoing upgrades, bugfixes and new features. We call these “maintenance” contracts, though no one really likes the word. A contract might include a bucket of 10-20 hours a month to be used as requests come in and the work doesn’t require an estimate or prior approval.

On paper, this is great… steady income, and plenty of efficiency given the lack of overhead. The issue, however, is that the client feels withdrawn from and neglected. Where as before, an entire team was at their beck and call–answering questions, squashing bugs, and tweaking features in real time–under the maintenance contract, things are necessarily more relaxed. In other words, if we were to afford the same level of service during a maintenance period as we do just prior to a big launch, the client wouldn’t get very much production since the majority of hours are spent on account management.

A few clients have recognized their own service needs and are willing to pay for it. For these the monthly budget is much higher, but for the small and medium-sized business, it was likely a stretch just to pay us for their interactive project. We haven’t quite pulled it off yet, but for these smaller clients I would suggest a couple strategies: a gradual constriction of maintenance hours over a period of months (give yourself plenty of hours the first month) and a robust conversation near the beginning of the project about what to expect after launch.

Read my post on Agile methods with non-agile clients on the Vermilion Blog.

“Inspired to some degree on our work for Agile company Rally Software and the Agile Manifesto my team recently proposed some changes to how we take on the week’s work…”

Read my post on The CMS Issue at the Vermilion Blog

“I was chatting recently with local legend Robert Reich about the CMS issue at agencies and the battles we’ve had over open source vs. proprietary systems…”

The general premise is that fixed costs (your FTEs) are more productive.

One of my main concerns is how to quickly secure development resources when the client demand becomes overwhelming–we’re in such a period right now and the pressure to find additional talent is palatable. However, the demand for quality programmers is high enough that freelancers are able to charge a premium for their services. The issue is whether to pay the high hourly cost or push deadlines.

My agency experiences cyclic workloads that ease about once a month (on average) meaning most work can be accomplished in house if the majority of time-sensitive work slips by a week. The alternative is that during an easing period your full time employees won’t be at capacity.   In other words, pushing deadlines is a smoothing function (much like a moving average) on the workload.

This sort of negotiation happens naturally as the days and weeks progress; however, the art seems to be in one’s ability to sense the business implications of missed deadlines beyond the simple math of variable vs. fixed costs.