What I do as a non-programmer

A few weeks ago Spencer Fry (Carbonmade) posted a nice article about what he does as a non-technical/non-programmer employee/executive at a web-based company. I had already been playing around with a post discussing the same (his is very good) but it inadvertently fell to the wayside while I was…well…doing those things I wrote on my list.

The life of non-programmer at a web-based shop is interesting to say the least. A lot of time is spent either mulling the things that absolutely are necessary to keep the business on an upward trajectory and battling with myself as to whether that thing is actually necessary. That is to say, battling over what to contribute and what not to contribute (I believe the latter is more important than the former in the long run). Additionally, it’s not a rare moment when I’m questioning whether or not I can stay as valuable to the company as our code-contributing staff (who are literally the architects of our future/potential success).

I started in 07 as 50% of our non-programming staff (but 1/3 of our startup). In the early days it was easy to pick up the slack. I was eager to contribute ideas and copy and brainstorming sessions where we laid all of our future successes out like a road map. As soon as I understood the business well enough though, I resigned to do my best to pull my own weight since I was unable to contribute to the code.

Here’s my short list of 9 (but maybe more…) aspects of my non-programming position. Which I might also title my “start up job description”.

1. Test – never a day goes by when I’m not on the system. I’m a power user. Be it Moodle, proprietary systems or just a home page. No link goes un-clicked, no combination of variables goes untested and no bug is left unearthed. When our programmers think the code is “perfect” it’s my job to point out where things break down or usability becomes confusing or some other practical/common process has been disrupted. I check from different browsers, different operating systems and with different end results in mind. Then I ticket and follow up and repeat. Testing, to me, is really synonymous to providing customer support and it’s either proactive or reactive (so might as well start testing now before you’re trying to test to find out a certain nuance that a user submits later).
2. Draw diagrams (but not imaginary screen shots – relational diagrams can help a lot more than “I want this button right here”).
3. find non-technical solutions to user problems. You might also call these “hacks”. If there’s a crazy bug or usability issue, I’ll ticket it. But I’ll also find a way around to ensure it’s not a blocker. Doesn’t load right in IE? Try FF. Doesn’t display in my profile. Unenroll and re-enroll. Blockers get highest priority, so when there’s a back log of those it’s my job to find (and disseminate) workarounds for the non-blocker (but critical) issues. This often means that I’m elbows deep in user interaction, guiding them through ways to fix the issue themselves or fixing this issues remotely to give them the smoothest user experience.
4. be a buffer: I mentioned earlier that programmers are extremely valuable; that’s why I focus on keeping them out of the focus. The programming staff I’ve worked with is efficient and creates excellent applications for our clients. But they shouldn’t be changing passwords or trouble shooting for specific user issues. This goes the same for the executive/programmer line of communication (if you happen to be at a bigger company). Distractions are costly. If there’s a road map that is worth following, it’s only a matter of time before a client need 0r CEO idea brings you off course. Creating a buffer can help your app “stay the course”.
5. Build the business: go sell something, find customers, make $, organize paperwork, manage finances (this stuff is the simplest when you’re getting started but it grows and grows in proportion to success).
6. Refrain from complexity: don’t spend time asking for additional features, just because you’re not busy doesn’t mean programming staff isn’t chipping away at the most recent revisions, enhancements, bug fixes.
7. write FAQs, site copy, user guide books, make tutorials. I would say that this is probably the 2nd most important role, besides customer support and satisfaction.
8. never use a bug as the basis to add an enhancement.
9. publicize/socialize: manage twitter, blog about the business, do the presentation circuit. Whatever you can do to spread the word about your business should be done and done well.