support and creativity
I’m sure I’ve written about this in the past somewhere… buried in my posts. For the sake of emphasis, I suppose, I’ll write about it again.
Last night I sat down with Troy to talk about all the stuff you never get to talk about in meetings. Some of it was personal, some of it was business, some of it was my personal thoughts on his business. One of the big topics, which was an extension of a discussion that started in a production meeting a few weeks back, had to do with people wearing different hats in the organization.
I’m all for cross-functional team members when it comes to a very entrepreneurial boutique firm like MetaFoundry. We’re all really skilled and talented, and have interests in different fields, and are capable of doing great things in different areas. For example… I may be asked to do the db design on one project, and squeak out a few scripts on another, while participating in the discovery for a third. A designer might fiddle around with the CSS for a site to get it to do what they picture in their head.
One of the lines that I think is difficult to cross is the one that exists between the “supporters” and the “creators.” The creators are an eccentric bunch. At least the good ones are. They’re responsible for delivering great work to the people that request it. That can be any number of things from reports to software to pamphlets, etc. The supporter’s job is to make sure that all the creator has to do is create. No worrying about clients, scheduling, resources, lighting, etc… just create.
This can also be described as Joel Spolsky’s Development Abstraction Layer:
“With a software company, the first priority of management needs to be creating that abstraction for the programmers.
If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.”
It’s worth reading a couple times, but the point is pretty clear. In order for those creative (and therefore temperamental) creators to do what they do so well, they shouldn’t have to worry about stuff. Have you met many programmers that were good at project managing themselves?
What’s always the challenge is applying these idealistic concepts to a tiny, shoestring organization. I enjoy doing this: taking abstract concepts and figuring out how to make them work in real-world situations. It’s pretty much my job on a fundamental level. I’ve done it before with some other development concepts (I’ll be sure to talk about soon 
), and this support/creative balance is at the core of it.
The glue that keeps these two halves together is process. There are a few buzz terms in development that chastise the overuse of process, or extol the virtues of rigid processes. The one that I always try to keep in mind is “people over process.” In the end, a process is meant to *help* the people, and if it doesn’t, then it doesn’t serve a purpose. If you can’t come up with a simple, easily justifiable reason for how a process helps someone, then it’s likely that it’s unnecessary.
On the flip side of that coin, a lot of day-to-day pain and suffering of either a creator or a supporter can be eased by establishing a sound process. For example, the daily interaction between a project manager and a developer can involve a lot of back-and-forth of questions and answers. The project manager will want to know the details of how and when a certain bug was fixed, and the developer will ask “what was that list of fields they wanted added to that form?” Lots of back and forth gets tiresome to both people, as they’re constantly interrupted in their work. If they had a ticket tracking system to post questions and look up details, they wouldn’t have to interrupt each other for mundane questions. The process involved here is requiring them to *use* the system, and to use it well. In the end, it’s to both their benefit.
And the key word there is “both.”