Software & Accountability
In the construction of a software business and product an accountable party is paramount to its nimbleness, survival, and growth. Leaders of small startups are sometimes technical people themselves, the shipbuilder and the captain, and sometimes not: the technical cofounder. Cases in which the leaders are not implementors and there is no established technical cofounder (read: accountable party) I’ve seen organizational confusion, shaky alignment of execution with vision, and vision that lacks clarity.
The accountable party is the person focusing their attention on the vision and folding into it, solutions. The journey of a product and business is a stream of course corrections that tack on an execution path, or product, that fits with a market and solves a legitimate problem (sometimes the honing of the execution and the problem to solve go hand-in-hand).
Accountability is, I think, a fundamental quality for the success of careers, businesses, and teams and in this essay I want to relay my own experiences as a leader and technical cofounder that did not understand, in the beginning, what to be accountable for and why. I had no mentors, at least not until Techstars, and little help navigating the flood of information available to founders.
Contractor to co-founder
In 2009 I started a sole proprietorship supplying web development services to local businesses in San Diego; it was a change from being an employed programmer because I became responsible for marketing myself, finding clients, and managing projects: a set of responsibilities and skills distinct from those when employed.
Mid 2010 I began a contracting project for Erica Douglass to build a platform for her SEO services business. The timing, fortuitous, because I desired to build a software product business to evolve beyond the difficult to scale services business. As the platform saw increasing signups Erica and I both decided we wanted to become cofounders and turn it into a startup, Whoosh Traffic.
The first two years were interesting because the company was small and we survived on providing SEO services while building our SEO metrics and analytics product. I say interesting because this was uncharted territory for me! Responsible for a product, platform, and customers? Check. Ship quickly? Check. I was now handling general technical support and experiencing the occasional fallout from shortcut software I had written. It was stimulating and intense and there were also many late nights. I began to understand how important it was that I was a cofounder - when shit broke I was the only person on the team that could fix it. I began to see why giving responsibility is concomitant with autonomy, when you own it, you care for it: my first lesson in accountability.
I also began to get a sense for hygienic programming (a form of personal accountability): small efforts at the time of writing code to improve clarity, reduce complexity, decouple units of functionality, and discipline my “think before you code” habits. I’m still improving to this day but I often, back then, experienced the pain of not having practiced the discipline: things that broke for unintelligible reasons or edge cases that seemed mysterious because I didn’t write property tests. Code that was difficult to navigate and refactor because it was everything the Pragmatic Programmer is not (and other symptoms). As a result I was learning the hard way about personal programmer accountability while being completely responsible for the experience of our users and the continued execution of our roadmap (technical cofounder accountability).
I developed severe burnout in January of 2013 when we returned from a vacation - we experienced a spike of signups due to the shuttering of a competing product but I knew that it was ephemeral. Our feature set was similar enough to the competitor’s to sell customers on our product but it was different, in a qualitative way. The change in paradigm our software introduced and a change in pricing model was too frustrating for customers and our features weren’t a compelling enough difference to justify them staying. I knew what was going to happen, I could see it a month prior the crash: a lot signed up on our free trial and all but three left after thirty days. My cofounder and I had also never done this before, we both made mistakes that experience could have mitigated, allowing us to grow that business with softer contrast.
When customers call your baby ugly and you know it’s ugly, it’s hard to see the potential. Potential that is definitely there. We had revenue, some of our customers loved us, and we did have a useful product with solutions none of our competitors had! But I burned out and lost all desire to be accountable for bringing execution in line with the vision. The vision was haphazard and I was working on an SEO product I had no affection for, except for the engineering challenges. The business felt more focused on building a startup for the sake of building a startup than impelling it with clarity of vision.
Neglecting to assert a clear vision, which is the founder’s most important work, always leads to flaccidity and omitted efficacy. Through mutiny this is sometimes resolved; though sometimes, failure is the only way forward. Without clear vision there is no concrete hold for accountability but accountability is what continues giving life to the vision, otherwise it takes off like a baloon into the sky.
My cofounder was also feeling the burnout and after a lot of talking we decided to re-brand the company and pivot - this is where things began to get a bit sticky between us but that’s a story for another time. We re-branded the company from “Whoosh Traffic” to “MarketVibe” and began on a product we didn’t define well (both of us), while still being unclear about our vision we felt lost on who was responsible for what and thus lacked an accountable party. I later learned (through Techstars) that I needed to assert myself much more onto the business and not just the technology; I think we were both locked in static paradigms that were true two years prior but not so any longer and neither of us understood what or how to talk about the issues we were observing.
We ended up waffling all over the place about what we were building for quite a few months, one of the more dangerous spots to be in if the founders are doing it emotionally or impulsively, instead of with data. This led to our first cofounder hiccup (almost a breakup, but we made up) and then a string of exciting developments with investors and our acceptance into Techstars.
Neither of us knew what was coming once Techstars accepted our application, I will blog about my experience some other time but here I want to relay the rejuvinating experience I had with Techstars and a few of my personal lessons in accountability.
The first week (or second?) of Techstars we hit a pretty big cofounder hiccup, approximately two months after the first one. Emotional undercurrents, fear of communication (on my cofounder’s part), and the intensity of Techstars made evident the fractures in our relationship.
Everyone running the Techstars program, places the cofounders on equal footing. Suddenly I was on a platform that shook up our static paradigms which allowed me to realize and assert my desire to interact with mentors, practice pitching our product, refine ideas for our product, learn about financing and legal structure, and much more. There were two weeks of time in which Erica was out due to a surgery she needed to have that I became responsible for: all our mentor meetings (about four a day), classes, maintenance of the old Whoosh Traffic product, development of our new product, management of our other engineer (who was great and didn’t need managing), and general customer support. I handled it well and realized I enjoyed it too!
Realization dawned on me about the importance of clarity, vision and what it meant to be accountable; not just for my software but for my company and my thought-formulation of the product and messaging to other people about that vision and its execution. To be accountable meant understanding where I was on the map of product <-> market fit, being transparent about it, and then being solution focused while allowing the feedback loop of constructive criticism and problems refine my clarity and conviction.
Once this occurred and I was clearer about my vision, our cofounder relationship started deteriorating. I did allow her choice in direction and we were trending upward in that direction but the stage was already set for us both. We split when Techstars ended.
With no money in savings, I needed to find a job or contracting work fast, which leads me to one more story.
A startup with an absent father
I came across a small company during the ATX Startup Crawl with an interesting product, Curb. They were seeking someone to take responsibility for their software as neither of the founders were developers and the person they outsourced the work to is an excellent programmer but limited by necessity of being a contractor, in their accountability for the product and business.
We talked a lot and the opportunity looked good: fair equity offering, potential CTO title and cofoundership if each of us liked each other and, of course, responsibility.
Once I started it became clear to me where I fit in: there was little clarity about the product, no product development process (another awesome person that joined when I did helped in this area a lot), and no project management process. They used an excel spreadsheet for feature / bug communication and were paying more than $1k per-month on AWS and ObjectRocket for less than 20 users that never used the product!
Digging in to the software, I realized there was a lot of entropy. It needed someone to be accountable, to smooth out its rough edges and focus on solutions to the problems that plagued the implementation.
The details of the turnaround I will write up in a later article but the tenor of it is I rewrote the core software and ported most of the interface within three months, improving the stability, accessibility, cost of operation, and ease of maintenance and feature iteration. Most will say that legacy software shouldn’t be “rewritten” and I tend to agree; but, there are some cases where it is incumbent on the product to be nimble with a prerequisite of maintainable and accessible software. It was a calculated choice: the rewrite happened during the holidays and what needed to be rewritten was small enough in scope to be manageable. The gains outweighed the opportunity cost - if not negated at this point.
At the end of January I had a candid meeting with both founders and discussed my tangible and emotional contributions along with my critiques of the product, vision, organizational structure, business, and where I wanted to be in relationship to it. We all agreed to become cofounders and name me the CTO with clearer refinements to the vision.
Those three months were difficult but I knew the need for accountability in the implementation of the software and also in the execution of the vision; I went all in and have validated for myself the lessons I learned from building and running Whoosh Traffic. I confirmed for myself why I needed to be accountable and for what to be accountable and I understood where I must assert myself to ensure my responsibility was serving the vision and not mollification.
What have I learned?
I had a taste of responsibility with my first startup early on but my sense of accountability was haphazard and not deliberate, I think. In observing my own product and business (Whoosh Traffic) ride the rollercoaster and what my personal response to it at the time was, I believe my lack of awareness (and other factors relating to cofounder dynamics) was responsible for a myopic view of only the problems, the what was wrongs - opposite to expanding my ken of the possible solutions that would have revealed themselves to me. Other problems with salient symptoms confusion about vision and leadership.
The experience of going through Techstars provided me with a platform to contain the problem that was my own perspective and look at it from a position of worthiness and honesty - the syzygy of that experience with the catharsis of splitting from my cofounder thrust me onto the peak of realization that not only was I accountable for my software, how I perceived my software, our product, our business, how I operated within the business but also accountable for me. For my frame of value and mettle and fidelity. Fidelity not in the sense that I was untrue by meddling with other businesses or products but fidelity in the sense of focusing on the solution and not the trivialities -trivialities like the perfect design pattern or the perfect language or the perfect database or the perfect combination of product features. Perfectionism taints fidelity which slows down industry.
This is why accountability is critical and far more important than your technology stack or processes or suite of services. Something you should not outsource or neglect to define.