Quote – Jonathan Rosenberg of Google

There are two components to our definition of open: open technology and open information. Open technology includes open source, meaning we release and actively support code that helps grow the Internet, and open standards, meaning we adhere to accepted standards and, if none exist, work to create standards that improve the entire Internet (and not just benefit Google). Open information means that when we have information about users we use it to provide something that is valuable to them, we are transparent about what information we have about them, and we give them ultimate control over their information. These are the things we should be doing. In many cases we aren’t there, but I hope that with this note we can start working to close the gap between reality and aspiration.

Jonathan Rosenberg, Senior Vice President, Product Management, Google – “The meaning of open

Quote – Gary Vaynerchuk

By 2001, we were doing about 20 million. Not bad. Not bad at all. Life was good and business was booming. Most guys my age would have thought they had it made.

Then, on my thirtieth birthday, November 14, 2005, I was driving along the New Jersey Turnpike on my way to work thinking about my day, and I realized that as perfect as life seemed, I wasn’t entirely happy. I knew deep in my soul that there was no way I was ever going to buy the Jets if I stayed on the retail path. It was time to go big.

Gary Vaynerchuk – Crush It! (free on Dailylit.com)

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
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
4. be a buffer
5. Build the business: go sell something, find customers, make $
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
8. never use a bug as the basis to add an enhancement
9. PUBLICIZE
  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.