"As a founder your role is NOT to build the thing"

Submit
@LefterisJP
@LefterisJP

A lesson many tech-focused/dev founders tend to learn the hard way is this: As a founder your role is not to build the thing. Your role is to clearly explain your vision about the thing: - to your team that builds the thing - to the world so that they like and use the thing

twitter.com

As a founder your role is not to build the thing

avatar
I scrolled by this yesterday, and since I look up to Lefteris and am a pretty hands-on founder, this immediately made me really uncomfortable. So, I scrolled past, trying to avoid the lesson here. But harnessing that feeling, I would like to understand how well I'm performing on this task at Kiwi (feel free to tell me, even if it's negative).

For example, I don't usually go on podcasts, I don't write GitHub issues, and even the roadmap and other blog posts are pretty light on the product vision.

I can understand that this sometimes creates somewhat of a mess as it is rather implicit what I want, and I often communicate it by example.

However, I do feel like this is the best way for me to communicate what I want.
Yes, I could write a really long blog post outlining the details of what I want the Kiwi News Protocol to be eventually.
However, I think this extreme approach of building in the open, sharing strategic details with everyone, making all the code accessible, and publicly backtracking on false decisions is also somehow "not building the thing as the founder" but "explaining your vision."

I take my inspiration from Peter Hintjen's "Social Architecture," in which he details how living systems are architected and that if you have to invoke entropy to make your system alive, and paying people is such an action, then the system is actually not really alive.

So, if I had to rate myself by the proposed criteria, I think we (and I) are doing OK, but I have to acknowledge that building Kiwi in this way requires an immense amount of patience and persistence. For interest structures to emerge naturally through mere participation (as opposed to, e.g., financial incentives) is just a very hands-on and slow process—with hopefully very strong roots and bonds later on, though!!!
avatar
In addition, Mark Zuckerberg said in a podcast recently that he doesn't believe in delegation as a founder, and he motivated this mostly by saying that this is just something he gained confidence in. I think that's really inspiring: https://youtu.be/xQqsvRHjas4?si=KX5dd7v2HFE06KFd&t=2139 (link has a timestamp)

If I had to guess, I'd say Elon is probably quite similar in that he's very hands-on and knows about all the internal processes, etc.
avatar
I think this "explaining vision to your team" part depends on the project.

If you build something like Ethereum, you have to paint your vision (via, e.g., whitepaper) to get more people on board because you can't achieve it alone.

Also, if you already have a dev team, it'd be good if they understood the vision behind the project. That way, they can take the big picture into account when building features, which would also make them more excited.

In our case, you do the overwhelming majority of the dev work, so that might be less important as the product vision is in your head. On the other hand, I'm wondering if a clearly written Kiwi vision wouldn't make the Open Source devs more interested in contributing to Kiwi. IIRC, Hintjen recommended something similar.

Also, writing things down helps one really think them through. So, I'd bet that the act of putting the vision into words might improve it significantly.

As for "communicating with the world"...

Many devs I met have a big blind spot here, but I think we are doing fine (though the written down product vision would help IMO). One advantage of Kiwi is that it's pretty self-explanatory compared to things like EigenLayer or other infra-level projects, so it's easier to "communicate the vision via the product".