Advice for finding a technical co-founder

So, you’re a non-technical founder. You have a great business idea. You have some market validation.

You’re ready to find a technical co-founder who can help build out your startup. You’ll need some coding done, and you imagine there are a whole host of other technical things that need doing. You want a partner who can help you.

You start looking and realize a few things:

  1. Anyone you pick is going to have a huge role in the success or failure of your business.
  2. You don’t have many developers in your network.
  3. It is hard to find technical people willing to work for equity in your unproven startup.
  4. Any time you post looking for a technologist co-founder, agencies (many offshore) respond, happy to help for $$.

I have had the “how can I find a technical co-founder” conversation a few times in the last week so wanted to share my perspective. This is based on my observations and reading, as well as having been a founder (two times, one successful) and early stage employee or contractor multiple times.

Where are you trying to get

Knowing this is important, as it affects the rest of your search.

Are you trying to get to an MVP you can raise money on? A partner you can work with for a long time (if so, consider the 5 Cs)? An application you can sell to someone? A refinement of your current vision which may have technical uncertainties? Advice if what you are trying to build is possible? A technical network so you can hire quickly?

All of these are valid answers, but different ones shift where you look.

It could be because of who I am rather than indicative of the larger need, but most of the folks I’ve talked to really don’t need a CTO. They need a founding engineer. I wrote about the difference between the two; the latter may grow into the former.

What do you have

You also need to get clear on what you have. The people I talk with often have the following situation:

  • no money (raised or in savings)
  • no tech skills/network
  • an interesting idea
  • a no-code or partially coded solution proving out part of their vision
  • some level of market validation

If you aren’t in a similar spot, you can read the rest of this post with some skepticism. Immediately below I give advice on what to do if this doesn’t apply to you.

If you have money, it’s easy: hire someone.

If you have a network, reach out to that network. Most people are happy to help. It won’t guarantee you a partner, but it can lead you down the path.

If you don’t have an interesting idea, well, you’re in trouble. That’s one of the key things you can bring to the table to interest a tech co-founder.

If you haven’t proven out some aspect of your idea with the tools you have at hand, that’s worrisome. Why not?

What can you offer

Being realistic about what you have means you can be realistic about what you can offer.

Here’s a fact: right now, technically competent people can be hired by companies willing to pay them money pretty quickly.

The idea that you are so passionate about that you’ve quit your job or are working on it full time off hours (if not, that’s a serious red flag to any developer)? That idea is exciting and unique for you, but it is one of many ideas the developer has heard about from passionate would be founders. In addition to not being bought in to your vision, technical talent has the following other considerations:

  • there is significant opportunity cost to joining a startup for equity only. It depends on market and experience, but call it a net swing of -$150k/year ($100k in foregone salary and $50k of debt/savings drawdown for living expenses). Yes, you might raise money, but will you pay market salaries to a co-founder then?
  • the risk is front loaded. I know tech folks who joined a startup, worked their butts off to build something, only to discover that their partners were unable to market or sell what they’d built. Whoops! That was a waste.

So, how can you mitigate those risks?

Don’t stint with the equity. Double digits for sure. Make sure to leave some aside for dilution and/or an employee pool.

In fact, thinking intelligently about equity is a subset of something else you should offer: understanding the business. The Nolo books are great for the fundamentals of business, but you should also understand the domain. If you’ve thought deeply about the domain and the business, you will stand out from the “idea folks” who just have, well, ideas.

Be flexible on working arrangements. In one situation where I was the tech co-founder, I worked full time on the company for the first four months, then half time after that because I contracted to pay the bills. Bring finances up in your initial discussions. Be honest and upfront about living expenses and how everyone has different needs. This will filter out some folks, but that’s ok. Better to do that early.

Push forward on your own. You can get a long way with no-code tools and manual processes. This is a grind, but a tech founder will be impressed by this effort if you get results. If you don’t get results, that might be the market telling you something. You can also start an accountability email list for $0 to share your progress.

You may even decide you want to code. Depending on the complexity of your idea, it may be possible for you to build something using free resources. Or buy a book–you are going to invest years of your life, so buying an intro book on coding is cheap. I’d suggest the Rails Tutorial if you are building a webapp.

I, and other devs, judge non technical founders by their ability to get sh*t done. Show that you can.

Know who you are looking for

Based on where you are trying to get and what you have to offer, you should be able to narrow down who you are looking for. Think about the following factors:

  • risk tolerance, including emotional and financial
  • experience
  • domain expertise
  • personal chemistry (you are going to be spending a lot of time with this person, they’ll know your triumphs and low points like no one else)

Write this down. It’s the start of your job description. You should flesh it out with your vision, experience, and what you’ve accomplished so far.

You want a written job desc because you’ll want to share it with anyone who is interested in helping. That’s the first thing I ask for. Put the job desc at at a URL. It doesn’t need to be fancy, a public google doc is fine.

This lets people easily help by sharing the job with anyone or any group they might think a potential co-founder frequents.

Where to look

Share that job desc with your network. You never know who may know someone.

Tech folks congregate in groups. This is often in a slack. Google for “<your area> tech slack” and you should be able to find something. Join, but watch for a while before posting your job desc. There may be certain channels where it is appropriate. And you’ll get more response if you aren’t a “drive by” poster.

There are also meetups. Google for “<your area> tech meetup”. Again, these are communities, not bulletin boards. Be prepared to join and interact for a while before making any pitches. Could be months.

Angellist is a good site on which to create a company listing and post your jobs. They have an email that goes out to interested folks. That’s how I first made contact with one of my co-founders.

Another option is targeted outreach. Tech folks, as mentioned above, congregate in online communities. They often comment. You can search for comments related to your idea/business and see who is talking about it. They may have contact info in their profile.

For instance, I had someone reach out to me because I’d commented several times about agriculture, and that was the domain of their business. This is a bigger time investment, but can lead to interesting connections. Reddit and Hacker News are good places to start. Doing this helps you build your tech network, because even if the commenter isn’t a fit for a co-founder position, they may pass along the job desc to someone else who is. They may also be interested in remaining in touch; if the company grows or their circumstances change, there may be a possible fit in the future.

When you find the person

Great, you think you have found a co-founder.

Have their skills validated by other technical people. You don’t have the knowledge or perspective to evaluate the co-founder. You are excited about possibly working with someone who can help make your dreams a reality. Sometimes an incubator can provide these advisors, other times your network. (As an aside, you should be trying to build your tech network. When you talk to someone who is helpful, see if you can add them to your startup accountability list.)

When people share equity in a business, it’s like getting married without the sex. Date first. See if there are a couple of projects you can work on before jumping in. Offer to pay them something for these, even if it isn’t full market rate.

Set up vesting for founder equity. Everyone should be on the same page if you are starting a true partnership. This will save you heartache if someone has a change of perspective or goals two years into the startup.

In general, plan for the worst, hope for the best. Discuss exits, future roles (do they want to build a team or continue to be an IC), co-founder departures, and long term vision. Do this even though the business model and organization is imaginary at this point. Having these conversations while everyone is excited about the company will make the inevitable tough times just a little less tough.

Make sure you discuss who will be in control. If you are partnering with a childhood friend, maybe 50-50 ownership will work. I’ve definitely seen it blow up because there’s a tension between the “owner” role and the “CEO” role, so even then I’d be hesitant. But if this is someone you just met, you should stay in control with more than 50% of the shares. Make that clear from the get-go so there is no confusion. That said, you aren’t partnering with this person to micro-manage them. Be clear about the areas they’ll have autonomy in.

I know I had issues with my lack of control when I co-founded companies, but that’s all the more reason to have that discussion earlier rather than later.

When it comes down to it, the technologist is crucial for many companies, but the non technical founder is even more critical. It’s a bit like the product and company is a racecar. The technical founder builds the car, but the CEO drives it. Both are important, but you can often find other car builders once the car is running (to mangle my metaphor a bit).

Conclusion

It’s going to be a long haul to find the right person for your startup.

It might be easier to try to raise some money to pay those ravenous agencies (I’ve worked there, so I can call them that) or hire a freelancer.

But the right co-founder will be someone you can trust, someone who will experience the depths and heights of startup life.

Best of luck finding them!


Open source software business model concerns in the age of the public cloud

A few years ago at Gluecon I was sitting at the lunch table with some new acquaintances. The talk turned to business models and someone mentioned the chilling effect of the public cloud providers on open source businesses. Companies whose main product was open source software (OSS) originally had a straightforward business model: sell support and consulting. (I’m leaving aside sponsorships, donations, dual licensing and other smaller streams of income. I’m focusing on what I’ve seen work to build larger, stable companies. If you are solopreneur you have a different set of options.)

This shifted over time to withholding certain features (the “open core” model) and licensing them to customers who wanted them. Open core was better for companies because it is more scalable and profitable to sell software than it is to sell labor (which is what support and consulting essentially are). Customers won because a certain set of them needed features that were likely not core to the software, such as single sign on or auditing, but were critical for their use cases. These customers tended to be businesses with money to spend. Open core, however, has some problems.

The fundamental one is “what should be OSS and what should be licensed” becomes a pressing question. Building a product is tough enough in general, but now there’s an additional marketing, product and engineering complexity.

The SaaS Business Model Cometh

With the rise of SaaS a third monetization option appeared: offer their software as a service and run it on behalf of their customers. NodeBB, ElasticSearch  and others all do this. The customer wins because they have a lower TCO and benefit from continual updates and the company wins because SaaS combines the margins of open core with recurring revenue. This has even caused some companies to move away from open core. The community remains satisfied because if they want, they can self-host.

Enter the cloud companies. Cloud companies could and did take open source projects, packaged them up and offered them as a service for a low monthly fee.

As a customer, and I’ve been such a customer many times, using an offering from these providers has definite benefits:

  • The cloud operators know how to run software at scale.
  • They are already part of the accounting infrastructure. There’s no additional procurement process.
  • They don’t typically deprecate software (killedbygoogle notwithstanding), so as a customer you are less worried ongoing support and availability.

Adoption by a cloud provider has benefits for the open source project, too.

  • It’s proof the software has reached a large level of customer demand, otherwise the big clouds wouldn’t bother.
  • Improvements to the software or documentation may be donated back.
  • It increases the number of folks who use the software or know about it.

However, those benefits may not balance out the loss or threat of loss of revenue from SaaS hosting. This was the chilling effect mentioned around that lunch table. When I read or ask folks about this issue, I’ve heard three separate proposed solutions:

  • Be better
  • You should be so lucky
  • Close your source or re-license

Be Better

First, as the prime mover behind the product, a company should be able to be better than the cloud operators. Not necessarily better at running all software, but better at running theirs. After all, they built it. This does assume that the best people to operate a service are the ones who built it. This may or may not be true. I think it is definitely true at a small scale–they are going to know which knobs to tweak, and if they run into an issue they can immediately fix it in the code base. As software gets more and more popular, the ability to run it well diffuses, however.

The company behind any project also should certainly have a better sense of customer needs and the ability to map those to its internal roadmap. Of course, being an open source project means that the advantages are fleeting. If anything is turned into code and released, it made available to competitors.

An even bigger issue is that this relies on customers being willing to stick with the company on the bleeding edge. For rapidly growing or changing software that may make sense. Where major functionality is being built regularly, upgrades are an easy sell. But OSS isn’t adopted by the cloud provider until it has a large audience, which means they are likely very functional for a lot of use cases. This means that the company won’t get as many folks on the upgrade train, which makes the “be better” argument more problematic. If the cloud provider can offer a “good enough” experience, then their other advantages start to dominate.

You Should Be So Lucky

This is the argument that the chances of an application becoming popular enough to be adopted by a public cloud are so low that it’s not worth spending time thinking about. I asked Steve O’Grady about the OSS business model predicament at a webinar once and this was his answer.

There’s a lot of merit to this. The biggest obstacle to an open source company succeeding is not anyone taking the software and running it, it’s the software not being useful or known. Obscurity has killed many a company, far more than AWS adopting their software.

But when a company reaches a certain size, this advice is less of a solution and more naming a strategic threat. Yes, they are lucky to have their solution be popular. But what can they actually do about the threat to what may be a sizable portion of their revenue? This argument doesn’t help with that.

Close Your Source

Depending on how the company developed the software, they could relicense or close source. This may require some prep work. First, make sure the software is all owned by the company; have all contributors assign over their copyrights. This will make it more difficult for you to reap some of the benefits of open source: easy contributions from others.

The company can also choose to relicense only certain portions of the codebase, taking a step towards open core. In any case, prepare to consult an IP lawyer.

The company must also be ready for the blowback from the community. Which hurts more, losing something that was once free or paying for something from the get-go? For me, it’s the former. Many of the marketing, engineering and product benefits gained from being open source will be lost; this is the price to pay for obviating the cloud vendor SaaS threat.

The firm could also dual license the software or use something like the Business Source License, which strikes a different balance, but still has some attributes of an open source license.

Alternatives

None of these sound very fun. I think the answer is to back up and consider whether to make a project open source initially. Consider this very carefully initially to avoid pain.

The benefits of open source for a business’ core offering are:

  • Lower friction of adoption
  • Contributions from outside an organization (these must be fostered, they may be free in terms of money but not time)
  • Increased rigorousness for the eng team (coding in public can make code better)
  • Easier to recruit because devs like working on open source
  • More eyes on the code means shallower bugs
  • Marketing halo

Are these worth the risk? I can’t answer that authoratively. If they are, another option might be to prepare for SaaS revenue cannibalization; this may mean going open core, focusing on consulting or support, or possibly never even building a SaaS solution.

There’s more than one way to be open. A company can do open development, inviting customers in to the product process. Would being more open with the development process (using public GitHub issues, for example, instead of an internal issue tracker) allow a company to get some level of contribution from outside the org? This would also imposes that “spotlight level rigor” on the eng team. Could the company make the software “free as in beer”, rather than “free as in speech” to lower adoption costs?

A firm can also release software as open source without taking any feedback from the community (“throw it over the wall”), which may be a good choice if the software isn’t core. Big companies do this every day. Facebook gladly open sources their computer plans and React, but certainly wouldn’t open source the core Facebook application.

In conclusion, if you are planning to build a company on an open source project, think about the main revenue flows for that company and what you’ll do in the unlikely, but hopeful, event the project succeeds.


Book Review: Am I Being Too Subtle?

I recently finished “Am I Being Too Subtle”, which is a business book by Sam Zell. He is an American businessman and real estate tycoon.

I quite enjoyed the book. We learn a bit about his parents and upbringing, and then he plunges right into the deals. Some of the details are great (he was able to complete a transaction once because he found out the owner of the property had buried a favorite dog in the backyard, and added a clause to the contract allowing the pet to be exhumed). He addresses his successes (helping professionalize the REIT market, selling the equity group, the loyalty of his employees) and his failures (the bankruptcy of the Tribune company in 2008).

The single biggest lesson that I took away was that to succeed you need to be looking in places that others aren’t and that eventually what worked for you will stop working and you’ll need to change. There are other pieces of wisdom in the book, and it’s less than 250 pages. A great fun read if you enjoy learning about business and deals.


The Challenger Sale

I just finished reading The Challenger Sale, a book about consultative selling. I really appreciated its data driven approach. The book, written in 2011, outlines a new approach to selling that is fundamentally about bringing the seller’s business knowledge to bear to provide value to the seller. But not just value, value in a way that is both striking (something new the customer hasn’t thought of before) and that emphasizes the product the seller has to offer. An example they give is Grainger, who sells parts. Grainger did research and determined that a large amount of the dollar spend with them was for unplanned part purchases, which can be expensive in both purchase price and staff time. They worked with customers to take advantage of their sprawling inventory to better plan parts purchases.

They cover the different kinds of sales techniques that their research uncovered, as well as tactics to help people adopt “challenger” traits to become more successful. They also cover how to sell this methodology to front line sales managers.

Two things really stood out for me. The first is that every company needs to answer why their customers should purchase from them, as opposed to anyone else. This can be a hard conversation to have because once you strip away all the “innovation” and “customer centricity” sometimes you aren’t left with much. I know that when I was a contractor, I would have had a hard time with this–my best answer would probably have been “I’m trusted, available, knowledgable and local”, which kinda sounds like a copout.

The other great part of the book was at the very end when they talked about how these techniques could be used for the “selling” of internal services (IT, HR, market research, R&D). I found that really interesting in the context of larger corporations where some of the functions aren’t valued for strategic insight, but rather are order takers from the business. I have in fact myself been an order taker. It’s easy, but not as fun as being part of the strategic conversation.


What is an MVP and why do you care?

I was recently published over on the Go Code Colorado blog. I wrote about what a minimum viable product (aka MVP) is. When I talked to teams at last years competition, one recurring theme was how much people wanted to spend time building rather than talking to users.

I have been there! I know it is much more fun to build something than it is to try to find people of whom to ask questions.

But it’s much better for the long term viability of your project to build something people want poorly than something no one wants perfectly.

More over at the Go Code Colorado blog.


Announcing: Letters to a New Developer

Blank paper, pencil, lightbulb, eraserI’ve been working on a new project that I’m excited to share here. It’s called Letters to a New Developer. It’s a blog with over forty posts full of advice for people who are just starting out in the field of development.

So much of development is not about code. It’s about teams and processes and organizations and questions. I feel like the traditional education system (whether four year college or bootcamp) does a good job of teaching folks coding fundamentals (what you need to be a programmer) but there is so much more to being a successful developer than coding. In my experience, delivering code is a necessary but not sufficient activity for success in a software company.

That’s why I’ve spent the last five months writing up some of my experiences and learnings.

The posts are mostly mine, but some are from guest posters who bring a different perspective. I also excerpt posts I find on the Internet that I find helpful, so that I can stand on the shoulders of some of the giants who have come before.

Here are some of my favorite Letters To a New Developer posts: Always Be Journaling from Brooke Kuhlmann, Get Used to Failure, and Learning to Read Code is More Important Than Learning to Write It.

I hope you find this project as fun to read as I’ve found it to write.


Ideas for marketing a dev centric product

I have a friend who has a company that produces a developer tool that provides a one stop shop for application authentication. It’s a good one and they’ve found some traction.

They are trying to follow the redhat/mongodb playbook–create a tool so good at solving developer problems that developers adopt it. Eventually some portion of enterprises will wake up one morning and realize that their developers are using this. The CIO will freak out and be happy to pay money to my friend’s company for support.

The question is, how do you get developers to find out about the solution and how it will make their lives better?

I am not a marketing guru, but I am a developer and have been involved in selling of software in the past, so I had some suggestions.

  • Read The New Kingmakers, by Stephen O’Grady, in particular “Courting the Developer Population” and “What to Do?”. You can get a PDF here. O’Grady has thought a lot about this problem and his blog is worth reading as well.
  • Find or create a community, and contribute to it. Depending on your audinence, this may be a reddit subforum, an old school php bbedit forum, a facebook group or even an IETF working group. An existing group is more likely to give you results, where a new group will give you more control. Aim for results.
  • Present case studies or testimonials of success using the software. How did a real person solve a real problem with your software?
  • If you can find analysts and/or bloggers focused in your problem space, contact them and offer to walk them through the solution. (To me, this seems more of a long shot, but could be a big hit if you find the right person.) Developer focused podcasts could be an option too, as long as you are talking about technology and the problem space, not your product.
  • Writing interesting content on your blog. Share it widely. Again, this doesn’t have to be about your product, in fact it shouldn’t. Instead, take topics you’ve learned by building your product, or in the communities of which you are part, or the problems developers have solved with your product, and highlight those topics.
  • Write talks for conferences. For developers, I’d look at conferences like gluecon and oscon. Meetups are good too–easier to get into but much less scalable. You attend virtual meetups as well as physical ones.
  • Set up a google alert for competitors’ names and keywords and see if you can add value to any discussions happening there.

Above all, don’t be salesy. Focus on making the developer’s life easy.


Atoms and Bits

Atom

I found this post by Fred Wilson about atoms and bits to be a nice counterpoint to this post from a few years back by Chris Dixon. There are so many advantages that a software product has over a business that delivers physical goods, whether that is inventory, startup costs, or distribution. (Yes, if you build a mobile app, you have to pay the vig to Apple/Google, but you also can distribute at zero incremental cost to hundreds of millions of people.) From Fred’s post:

we should … understand that the timelines [for working on businesses that focus on atoms] will be longer and the road to adoption will be more challenging.

The fact is that atoms are just harder to work with than bits. However, that very difficulty can provide a moat around your business (“where there’s muck there’s brass”). If your business is bits, find another moat (branding, network effects, niche domination).


Startup COOs: What do they do?

I really enjoyed this post about what startupo COOs do. It was interesting because it wasn’t just opinion, there was also data. I particularly enjoyed the evolution of the author’s role over time, and the percentage of COOs that owned various responsibilities. To be fair, it was a small set of respondents in one geographic area, but still interesting.

However, the money quote was:

I actually have [simple way] of explaining what I do, and I would sum it up this way: taking things off my CEO’s plate, and figuring out how to thoughtfully scale the company.

Of course every company’s different, but I’ve seen the pattern of a visionary and an operator in a couple of companies, and it’s powerful.


(Links To) Advice For Someone Selling a SaaS Business

Sold signI ran into someone at a meetup recently who’d built a SaaS that had a pretty decent MRR. Enough to support one person. Which is a huge achievement!

He was wondering what options he had to either grow or exit the business. This is something I’ve been reading about for a number of years, so I had some advice. I thought I’d write it down so that others could benefit (or chime in). These are resources I’ve found insightful.

This is a great first hand account by patio11 of selling a software business (it wasn’t SaaS, rather a one time digital product sale, but I think there are a number of common themes). He mentions the broker he uses, the due diligence process, and what you can do now to set yourself up for success (have separate accounts, for one).

I can’t even talk about SaaS without telling folks to raise their prices. It’s a reflex now. Amy Hoy has two great posts on this: grandfathering and new features (with a lot of communication mixed in). I experienced this myself at a previous startup, where we almost doubled our monthly subscription price in 18 months.

Finally, here’s an interesting post from a venture capitalist about how private equity is a new exit option for SaaS companies. In that vein, I chatted briefly with one such PE firm, SureSwift Capital, about part time work a year or so ago. I don’t know how they are to work with (the position wasn’t a fit) but at the time they were focused on acquiring SaaS companies with good MRR and helping them grow.



© Moore Consulting, 2003-2021