Food For Founders #54

F3 is a FREE weekly newsletter where we find the best concepts on the internet that will move the needle in your business.

Vulnerability time.

One area that I am by far the weakest is by anticipating human nature. It’s that thing that in our household, we refer to as a serious blindspot. I project my approach onto everything and everyone I encounter and have to reel back from there. It usually ends up with a lot of damaged relationships along the way, but it’s a work in progress.

This happened in how I designed KnowCap. I always felt if I had a team of experts around me to help fill in gaps where I wasn’t absolutely excellent in, I could build multiple very large companies. In a sense, KnowCap is what I would have loved to have 2-10 years ago (I know I’ve been starting companies for a decade now crazy!!!).

I knew that I would be on the ball every day. I would respond in 1 hour or less because I knew I had more to lose and the slower I responded, the slower my team of experts would work.

This is where my weak point reared its ugly head. I was projecting how I would use KnowCap into how we structured things. Processes woulnd’t be needed, every founder would come in and trust the experts, move as quickly as possible, learn as quickly as we could build. The KnowCap team would focus on what they do best and create a repeatable way of executing on that skill.

That is not what happened.

Speed exposes the cracks.

I’ve always heard that speed can expose a lot of issues and its up to the founder to determine the difference between a critical issue and an annoying one.

There were a couple of critical issues that happened with KnowCap. Internally, our team simply wasn’t talking. The fact they had skin in the game didn’t solve it. In my mind (again my weakest point) I assumed people would put forth their most effective and efficient efforts to build successful companies…they are working for equity after all.

This isn’t what happened. So we had to build lots of structure around timelines, project management, documentation, and handoff processes. It’s allowed us to interact with founders with a lot more certainty, but there’s a long way to go.

On the founder's side, it was a mess. We needed something or someone to get everyone in alignment. We tried creating a founder liaison role to help the miscommunications and slow-moving pace…the projects moved slower, the founders were frustrated, the KnowCap team members were bailing because of how failed the structure seemed. This didn’t help.

Managed Choas vs. Breaking the Model.

I’ve always heard that unless you feel like your business is breaking, you may not be growing fast enough. I don’t necessarily agree with this, however, with the feedback we were receiving from all sides…our model was breaking. We needed to get it back on track. Back towards managed chaos.

In reality, I abhor the feeling of herding cats (I’m not a people person remember??), but I knew that would be a step up from what we were currently going through. So we decided to hamper down. Recruit someone who knew processes backward and forwards as the former director of design at Moo.com.

We then recruited someone with an extensive business intelligence and analysis background across large retail institutions. And now interviewing for associate product managers who have a background in process building and project management.

We also implemented a rule. Every single founder would agree to our founder code of conduct. You guessed it…we designed it after the way we all had hoped founders would treat our investment model. Eager to move quickly. Quick decision making. Respect the experts.


Founder Code of Conduct.

We created something that I hadn’t seen in our realm of accelerators/VCs/startup studios/incubators. We wanted to make sure that we weren’t bringing in the wrong people. We also wanted to be confident that if we needed to kill an investment….we could without any guilt.

The founder code of conduct is akin to a manual for how founders should process how we invest in companies. Highly dependent on the founder’s ambition, vision, focus, and drive to succeed.

We knew we couldn’t bring on anyone who wasn’t going to take it seriously. We also knew that a kiss of death would be an entrepreneur that we have to train to be an entrepreneur. They need to already come in with this skill.

Here is the outline of our Founder Code of Conduct. We believe more and more organizations like ours will adopt a document like this to manage expectations and provide guidelines for founders who have never been in a program as unique as KnowCap’s.

Outline

  • KnowCap is an investor - we require the same treatment as an investor, we are not partners and founders are not clients

  • Timeliness is key - If a founder delays, it delays their progress. Speed is what we aim for and we can’t promise that the full-value will be received if we are slowed down.

  • Always be learning - founders need to learn as fast as we’re helping. If our design team says something they don’t know, they should spend the next few hours getting very familiar. We believe 10-20 hours per week of learning is a good number to aim for in order to get the best our of our programs.

  • Our expertise is our value add - founders who don’t trust our experts, will not receive the full value of our programs. If they don’t trust us (who have an incentive to help them become as successful as possible) they won’t trust new team members or new investors. Not a good fit for us.

  • Be coachable - founders who cannot recognize that they don’t know what they don’t know will not find our program very valuable. We will contradict them a lot and they will need to know where they are weak and where they are strong.

  • Be responsive - if a founder isn’t responding to emails in 12 hours or less, do they really want it? We have to be sure that when we introduce them to investors, customers, partners that they are committed to build a company worthy of those introductions. Focus and responsiveness have a lot to do with that.

  • Adherence to our tech stack - We’ve run into too many issues with this. In order to build at the speed, we are capable of, we needed to dictate the tech stack we use otherwise we would spend too much time with the founders convincing them of our way of building products. Otherwise, we look slow, timeliness is delayed by weeks/months, and founders aren’t focused on building out their company…they’re focused on the tech stack.

Conclusion.

We are always learning new things. That’s part of what makes this interesting, but also very hard. We are dealing with cities, corporations, founders, experts, and investors all at the same time. This requires speed and constant iteration based on what’s working and not working.

It’s also required me to admit I was wrong multiple times a day because at the rate we’re building, a lot of decisions made just a month ago are being invalidated with edge use cases and new information.

Iterating is a difficult process as it requires humility and confidence. Confidence to know that your vision may be right, humility because the way you were executing on it may have been incredibly stupid.

Keep iterating. Keep pushing. Keep changing the world.