Staffing for the Present Perfect Future Tense

I'm a big fan of "solving the business problem you have." My clients will have tired of hearing me say it someday, but it's true. That's not to say that planning and execution on a large scale are not possible. In fact, some of the greatest accomplishments in history stemmed from visions executed over very long periods of time. What I'm *really* saying is to not invent business problems for yourself. Anticipate, sure. Contingency, contingency. But what you do next should probably be quite simple.

So turn the camera to Fending Group. We have a pretty lean structure: CEO, CFO, and consultants (ninjas) of every variety. That kind of dynamic structure -- responding to requests as varied as applications, websites, light design work, full-blown iPad apps, screen scrapers, you name it -- is really fitting for a small company. It allows me to create a work environment for the ninjas that's kind of ideal: they take the project or they don't. If the resource I had in mind isn't interested in a project, there's another specialist in black that might soon be available.

Occasionally, I look at where our own contingencies have been invoked and failed, either directly (an unhappy customer for whatever period of time) or indirectly (opportunity cost while I chase down a detail). As I do so, I start to create new, more complex contingencies and increasingly come to the realization that there are much simpler solutions. In particular, there are specific functions that I'm trying to fill that need additional blocks (not clouds) on the org chart. With blackboard wall at hand, I began to draw out this Dream Org Chart that might best serve those contingencies and serve customers -- and Fending Group -- better.

Sales & Marketing Admin

This is the first position I realized I'd need to hire in, and will likely do so after the first of the year. I already have a lot of strong recommendations for this part-time position from within my network, and look forward to bringing that person into a pretty responsible position. This could really easily balloon to a full-time job with benefits, given that the "Sales" part of that role often involves setting up a lot of meetings and explaining what a Discovery Engagement is to a lot of first-time clients. (And why the RFP we were sent got a "no thank you" response... again.)

Mobile Applications Practice Manager

This is a new one for Fending Group. We've been actively working on iPad (iOS in general, actually) apps and are in development on two or three kind of large ones for two clients. This is a really sexy field. Consultants in this area are supremely hard to find, and it's really hard to keep them happy (and on time). The Drupal side of the house is just that -- an entirely different stable. My first love is Drupal, and that's where most of my attention will always be. So I've got these projects that came up that have both Drupal and iOS dimensions and, for whatever reason, I jumped at the chance. Maybe I'll read this someday and realize that this was the moment this company Jumped the Shark, but I don't think so. There are some pretty remarkable things to be explored, and not by invoking UIWebView. (For all you website-as-app people out there.) So I feel a need to have a staffed consultant in charge of managing those projects, though not necessarily managing clients.

Drupal Practice Manager

This is where I get into some murky waters. As I wrote these words on the blackboard and now here, I realized that I can count the number of Drupal-focused project managers that I trust on one hand. This is a real problem for me. But I need to be out of the weeds for the most part. Instead of being focused on new business and keeping the company on the right kinds of projects, I often get sucked into scope and expectations management. Because I'm effectively leading projects, I often can't make time to lead the company and do stuff like, you know... write blog posts.

Community Contribution Manager

This is where I stopped. Where did THIS come from? That's not a line item any self-respecting client will let slide into an estimate! Actually, this isn't the case. Not in the long-term. I was having a twitter conversation with @bmann a few weeks ago on this subject, when he very neatly articulated why firms need to build community contributions into their bids in his blog post, Elephants like community ROI too. For me, this will likely be funded by support contracts with a "platform maintenance" line. Very business-friendly, and I have Mr. Mann to thank for that term. So this is a long-term bet. I'm going to start adding that line to support contracts at the beginning of the year, first with new clients, then retrofit into existing business as appropriate. In the near term, it allows me to distribute that work among consultants -- on the clock -- who are fulfilling maintenance contracts by not only improving a particular application but also contributing that improvement back to the open source community at large. In the long term, this means there's somebody there to say, "Hey! You're writing a custom module instead of fixing the community contrib module. Fix it once!" As well as a non-project person to contribute patches, solve issue queue questions, provide documentation for API functions, etc, to help actively maintain open source communities like drupal.org, groups.drupal.org, and perl.org for the benefit of our clients and the world. That actually sounds like a pretty sweet gig. I think I'll apply.

So those are my loose ideas. From here I guess I would start hiring the ninjas full-time, in sufficient abundance to let them trade projects with one another if the need presents itself. It's not perfect, but it's better than cube life. And if there's one moment at which this company truly DID Jump the Shark, it's the day the cube delivery truck rolls up.

Thoughts? Come on -- you know you have an opinion. ;)