(Codestarter stopped accepting kid coder applications and donor contributions on 08/14/2015.)
When a founder winds down his or her company, it’s common to write about what was learned or why the company failed. That second one (about failing) is coming along soon. Today, however, I want to share a bit about what I learned during the 26 months I worked on my startup.
These points are concrete tips, as opposed to self-reflections. I selected them because they are some of the answers to the questions I have most frequently been asked by other founders who are just beginning to build their companies. My company, Codestarter, was a nonprofit situated in the tech space. We crowdfunded $250 laptops for kids who wanted to learn to code, but couldn’t afford their own computers. While much of what I write is aimed specifically at founders of nonprofits--because I think they receive less focused advice than do for-profit startup founders--these ideas are certainly applicable to the for-profit world. In the end, nonprofit or for-profit, we're all just trying to build a project into a sustainable business.
1. Solve a real problem.
Sure, everyone advises this; many founders think they’re doing it; few really do.
I attended a presentation of foreign startups the other night. These startups are all backed by a newly formed company that provides loans in the developing world. I was struck that the founders in their presentations rarely presented the problems they were trying to solve. One fellow excitedly talked about his technology to weave motherboards into chic toddler clothing allowing the child to interact with an ipad, and I couldn’t understand why a toddler or its parents really needed such a thing.
When I started Omakase, the initial startup before Codestarter, I was positive that people in tech would give to charity if only I made it super easy and straightforward. I was sure that they were just too busy to do the research themselves, and if I picked charities for them, they would surely sign up for a subscription donation process. I even conducted extensive surveys and later user-testing that tested and confirmed my hypothesis. The thing is: no one really needed that product. People who want to give to charity do, and people who don’t want to don’t. Making it easier or faster doesn’t really solve a big problem, because people don’t really conceptualize giving to charity as a problem in the first place.
After the first year, I pivoted to Codestarter to solve the problem of supplying kids with laptops so they could participate in the burgeoning programs worldwide that teach coding. This was a real problem, and when we were able to hook into education networks, we were inundated with requests. Plus, it turned out that people in tech were far more supportive of donating to laptops for kid coders than they were subscribing to a charity-of-the-month club.
Before building an entire company, would-be-founders should consider what their project really accomplishes. Is it just something they want to see exist in the world? Is it some cool tech, and now they’re trying to build it into a business? Re-frame your view in terms of the really stressful problems that need to be solved. That’s how to find demand and customers. Then it becomes about how to supply a quality product as quickly as it’s called for. But that’s a whole different can of worms.
2. Everything is about partnerships and community.
I did not do a great job at this. I blame it on being an introvert.
Toward the very end of Codestarter, a board member said to me--You and your team should be out networking at events at least once or twice a week. I knew she was right. And it’s easy to find meetups and people who share your interest. She added--When people talk about nonprofits that help kids learn to code, yours should pop into their minds. Especially locally here in San Francisco. The only way that happens, she said, was if we made ourselves known.
Our team worked hard to establish several high profile partnerships; and I’m very proud of that work. But I realise now that there’s a more social aspect to partnerships than just emailing or talking over the phone one-on-one. You have to go out and be a part of the crowd and shake hands and be seen and attend events and ask questions and offer to give talks and sit on panels--you must be a social butterfly. I believe that the founder’s job is to do these things, even when you’d rather go home to see your kid, which was my case, or when you feel woefully shy and hate public speaking, also my case.
3. Volunteers can be a lifesaver, but they can also suck.
Volunteers can make or break your nonprofit. With extremely limited funds, many founders hope that they can make use of volunteers to accomplish their work. My experience is that volunteers are rarely reliable in the way that paid employees are. Obviously there are exceptions, and I know a number of nonprofits that work with armies of volunteers, but for a young organization just starting out, it’s hard to get enough volunteers into the top of the funnel to reach the ones who might be consistent.
Codestarter received dozens of inquires from people who wanted to volunteer, whether with design, or coding, or writing. Anything and everything. A few volunteers contributed amazing code, design work, and blog posts, and I’m so grateful for their help!
By far, our most important volunteers were our Codekit hackers--we couldn’t have survived without them! These folks volunteered dozens of hours weekly to help us set up and image the laptops we sent to kids in need. Because we were a lean team (4 people full-time), we depended on these amazing volunteers to help us get the laptop orders out the door. I’m forever in their debt.
Other volunteers have been less reliable, and I think this is the trap into which many nonprofits fall--dreaming of what they could accomplish with the aid of volunteers. Design was especially hard because it’s difficult to do successful design work remotely, I found. The best designers we worked with were in our office and could take part in the back-and-forth creativity process. We found that many developers (not all) couldn’t really delve into the code for our admin or website without a lot of instruction. There were also a lot of privacy issues to consider. Writers were the biggest let-down. So many people offered up ideas, and then they never made it through article completion. Again, I know other nonprofits that have made this work, but we were never able to manage writers properly. In hindsight, having someone whose paid job it was to manage the volunteers would have been ideal, had we had the resources to do so.
I've already said that partnerships are key. But what happens when your partners are volunteers? Many of the kids coding organizations we partnered with were run entirely by volunteers, who themselves had full time jobs and only a limited amount of time, energy, and focus to contribute to their charity work. Having worked as a volunteer for a number of nonprofits, I am empathetic to their situations, recognize their limited capacity and huge hearts, and am truly grateful for the work they do. In reality, most kids coding organizations wouldn’t even exist without volunteers. Still, it was hard for me to run my laptop donation business when I often didn’t know what happened to the donated laptops, because various partners were slow to, or didn’t help their kids register.
I had anticipated communications trouble from the outset, and so we required each Coding Partner Organization to sign a contract listing its responsibilities to Codestarter in order to be eligible to receive laptop donations. Responsibilities included prompt communications, helping their students to register the laptops promptly upon delivery, and sending us collateral and other materials to share with donors. Still, emails often went unreplied, laptops were left unregistered, and we rarely received photos or stories from kids.
Far and away, I found that communications were smoothest with representatives who were full time paid employees of the Partner Organization--such as teachers at schools. This is not to say there weren’t some standout Partners who were volunteers, but it does underscore the fact that volunteers are likely to be less reliable. I’ve spoken with founders and program managers for other nonprofits that rely heavily on partnerships, and I’ve been assured that my experience isn’t singular.
Overall, our top volunteers were the Codekit hackers. I believe they were so great because the activity was a clear, bounded, and fun way to get involved with our mission. Volunteers showed up to our office, chatted, ate snacks, hacked on laptops for a couple of hours, and then we treated everyone to drinks at the bar down the street. Other volunteer projects (writing, for example) were far less clearly outlined, and lacked any social component. For this reason, I urge other nonprofit leaders to consider creative ways to incorporate volunteers that foreground community and fun, instead of focusing merely on what the organization itself needs.
4. When to hire a professional, and when to figure it out yourself.
At the recommendation of an early board member, I hired a firm to put together my company’s initial legal and financial documents. And it turned into a nightmare. Documents weren’t filed properly because the firm was unclear about California rules. I spent countless hours googling California nonprofit law on my own, trying to double and triple check what the firm I’d paid a lot of money to handle did poorly and what my board thought was accurate, only to discover that there were some potential gross financial implications if things weren’t remedied. Which I fixed. In the nick of time. But boy was it stressful.
In retrospect, I would still hire someone to prepare all the documents for the 501(c)(3), because THERE ARE A LOT OF THEM. But I would take more responsibility to research all of the different legal and financial stages IN ADVANCE so that I could be leading the process from above instead of treading water frantically below.
Step two was when I hired an accounting firm to handle our finances, especially taxes and payroll. I did this at the recommendation of a friend who said that it was the best thing he ever did for his company early on, because it allowed him to focus on the product. Overall, I think this was a good decision, despite a few moments when documents didn’t get filed in a timely manner or I didn’t have the ability to access our company’s bank accounts easily on my own. When it came to the accounting, I operated more from the top, having learned a lesson from my experience with the legal bit. I ran meetings more confidently and came prepared with lots of questions and concerns, having researched everything in advance. This made for a far more successful relationship.
Finally, the whole healthcare thing. Totally could have figured it out on my own without going through a third party broker and administrator. That just made it more confusing and wasted my time having to research and select among all the different brokerages, only to then have to go ahead and research insurance providers anyway, and pay them on my own when they won’t accept payment through the healthcare broker. Such a mess. I definitely would just pick one provider in the future and move forward.
5. You need an office.
Or a room with a door. Or a really big closet with a door. The thing is, you need somewhere to keep all of the stuff that a company collects. As much as you insist on electronic documents, there will always be paper everything sent your way. And you’re going to need to access it repeatedly.
At Codestarter, before we had an office and when it was just my cofounder and I, we kept all the laptops at our house. Where we have two very hairy cats. Just imagine trying to hack together and then image dozens of laptops in your home, all splayed out everywhere. Think of the teeny tiny screws. And those cats. And our toddler. After 3 months, we found the world’s smallest office and moved the laptop process there.
We also built all of our parental consent forms to be electronically submittable. We quickly learned that many parents didn’t have access to the internet or computers (that was sort of our value proposition in the first place), so that we had to create a system of printable pdfs in various languages for Partner Organizations to print off, send home with students, collect, and snail mail back to us. Then I had to enter them into our system manually. Hence the need for an office so that you don’t lose things.
6. How to lead a team--not everyone’s the same.
In every leadership/management position I’ve had, I’ve always led from behind. By this I mean that I’ve worked to encourage others to take responsibility for themselves and their own projects instead of giving orders or outlining my own full-blown plans.
For example, when I taught undergraduate classes, I began by presenting an overarching concept, and then worked with the students together to brainstorm ideas, devise plans of action, consider outside conflicts, and create thoughtful, thorough projects. It’s far more effective to teach about gender representations in the media when you slap a bunch of magazines on the conference room table and invite students to tear apart Cosmo, Men’s Health, National Geographic, and Redbook in order to find and consider their own examples, as opposed to lecturing through some out-of-date example that the instructor chose years ago and never thought to change.
As the teacher, I always knew where we were headed. I steered everyone (sometimes with nudges) along the path, but I made sure that their ideas were our focus so that they felt responsible for the end product, whether it was a classroom discussion, individual term paper, or group project.
I’ve tried to translate those same skills into practice with teams at work. What I’ve learned, however, is that in the real world not all people respond the same way to responsibility. Some team members simply do not enjoy the brainstorming aspect at all. They really would prefer to be assigned a task and left autonomously to resolve it. As the founder, I struggled to recognize this. I often offered too much possibility to a team that was, at times, too new to understand how to transform the company vision into practice.
I also expected that I could make myself approachable and open to criticism by framing various team members as experts in their fields, such that they would feel confident to assert their ideas and needs. I wanted to enable team members to feel comfortable speaking up about their concerns or to provide feedback. I learned, however, that sometimes, people just need to be asked for feedback directly, and some people really prefer a far more formal work relationship than the casual one I worked to foster.
My advice to founders looking to hire their first few employees and build a small team is this: have a leadership framework in mind, but don't impose your own assumptions about how to foster good relationships. Instead, be quick and honest with each employee about how they work best and what they need to thrive.
7. Should you do an accelerator?
I get asked this all the time. Also, what was it really like?
My first company, Omakase, was the first nonprofit accepted into Techstars. Omakase launched 4 months before Techstars began, and all signs pointed to fast growth. At the time, we were 2 people, my CTO, and myself. I travelled to New York alone, because my CTO had a new baby at home. We worked incredibly well remotely together, so distance between us was never an issue. I knew that it was very rare for a single person to enter into an accelerator, but I didn’t care. I told everyone that I could handle whatever came my way; I was tough.
Within a week at Techstars, I was drowning. The program was designed to be experienced by larger teams. All work on product ceased because we spent every moment in meetings. This isn’t to say I didn’t learn a ton about running a business and building a product. I did. And I made remarkable connections with people and business contacts who helped me immensely. Techstars is an admirable organization, and any company should count themselves lucky to be a part of it.
I believe that accelerators can be the metaphorical rocket strapped to the back of a startup, but only if the startup is at the right stage. My startup was too young and too small. I was so eager to build something that pleased my potential advisors, that I transformed Omakase on a weekly basis. I can’t say how many entirely different elevator pitches I memorized--none of them well.
A company best positioned to make the most of what accelerators have to offer, I think, would be a company that has 1) fully built and user-tested its product, 2) achieved near-complete product/market fit, and 3) has 4+ team members so that 1 or 2 people can attend meetings and the others can continue to run the business.
As for being a nonprofit in a for-profit accelerator, there were good and bad aspects. Wholeheartedly I think that nonprofit companies would benefit enormously from the perspective of and tools used by for-profits. I created a far superior product, conceptualized my company from a higher level, and ran everything using KPIs as the result of being in Techstars. That said, I would encourage nonprofits to seek out accelerators that offer the unique support necessary to nonprofits, such as legal or financial advice or fundraising expertise.
These are the large nuggets of wisdom that I have to offer from my experience founding my own company. In my next post I’ll try to do the traditional moratorium of “why my company failed” and see if there are more emotional points to be discovered.
Ultimately, my cofounder and I are now feeling extremely positive about the whole experience and where it ended. We’ve been able to deliver more than 500 laptops to kids so that they can enroll in coding classes. We’ve helped our partner organizations reach 47% more kids than they were reaching before working with us. And we hope that our work has added positively to the discussion of how to diversify tech, what the barriers to entry are, and what the needs of the communities and children themselves are.