From my perspective, for-profit entrepreneurship seems better than nonprofit entrepreneurship in terms of making an EA impact. The main reason is that the profit incentive gives you much broader access to capital, so it unlocks ideas that will only be impactful given enough money to get started. And I think there are a lot of ideas like this -- it's not hard to look at e.g. YC's Requests for Startups and see obvious, huge-impact ideas that seem worth working on. (Linked from that page is another page about what YC looks for in a nonprofit, also a good read!)

I recommend that anyone wanting to start a company but not sure what to do, try looking at the Requests for Startups first and try to find something you have leverage on -- but keep it small, your initial idea needs to start really "niche", you won't be able to solve a giant world problem from the get-go. Then read Paul Graham's essays and Sam A's startup playbook. Hopefully this literature will give you a better sense for whether entrepreneurship is for you. As you work on growing your business, don't over-index on trying to make an EA impact early on -- just focus on growth, like you would for any for-profit business. EA impact will come over time as you grow, and spending too much time worrying about the impact while you're small is likely to be a distraction from growing as much as you can.

From my perspective, I wish more people would start software companies in Africa (presumably this is true for other places in the developing world). There's a pretty wide appeal for lower-end tech optimized for consumers and businesses in these markets: low cost; Android-based; focused on mobile money.

(I also think nonprofit entrepreneurship is great in lots of ways, and in general I want to see people in EA putting energy behind all forms of innovation!)

All the above notwithstanding, it seems like it makes sense for EA orgs like 80000 hours not to spend much energy pushing people into for-profit entrepreneurship: there's a model going around that the best entrepreneurs are driven enough that you don't need to tell them to be an entrepreneur -- it's in their blood or something :). I am not myself too  convinced this should be the blocker -- I go around telling all my friends to start companies -- but if that's the working assumption, then they are probably acting correctly.

I agree with most of what Lincoln said and would also plug Why and how to start a for-profit company serving emerging markets as material on this, if you haven't read it yet :)

Can you elaborate on the "various reasons" that people argue for-profit entrepreneurship is less promising than nonprofit entrepreneurship or provide any pointers on reading material? I haven't run across these arguments.

I really like these questions!

I'll answer your middle question first. When we were writing our first version in 2014, I logged probably 60+ most weeks. When living in Africa, I probably also logged around that many hours, since I had little else to do :). But now I start work around 8am and end around 5pm daily and usually take an hour for lunch, and don't work on weekends, so probably close to 40 hours. I am vaguely thinking about reducing my hours even more.

Transitioning to your first question:

The stage of a company really really matters, and it also matters what you consider to be "good" work-life balance. My cofounder is fond of saying, "there's no such thing as too busy, just poor prioritization." And I think that is ultimately how all work-life balance questions should be answered. First, decide on your priorities, then act accordingly :)

Classic startup advice always says that startups need to "move fast", speed is how you beat much more established competitors. But "move fast" is what it looks like from the outside when you have good prioritization -- when you're writing only the code that matters to get the marginal increment of growth rate, so you can learn what you need to learn in order to keep that growth on an exponential trajectory. It doesn't have to mean work yourself to the bone: on the contrary, I've found that when I spend many hours writing code, I have exhausted my capability to do the prioritization work which could save me many hours writing code :). So, I would say that great work-life balance in a startup starts and ends with great prioritization, not just at work but across your whole life. The 4 Hour Workweek is a well-loved treatise on the subject, as is Derek Sivers' Anything You Want. I put in 60+ hours in the early days because Wave was my life priority (and was able to get away with it because Drew was able to take most of the prioritization work out of my head and leave me with just code).

How do I take care of myself: I see friends and family, I take vacations, I have a coach/therapist person, I cook dinner and light candles and drink beer, I have tons of bright lighting in my office :)

I had a hard time answering this and I finally realized that I think it's because it sort of assumes performance is one-dimensional. My experience has been quite far from that: the same engineer who does a crap job on one task can, with a few tweaks to their project queue or work style, crush it at something else. In fact, making that happen is one of the most important parts of my (and all managers') jobs at Wave—we spend a lot of time trying to route people to roles where they can be the most successful.

Similarly, management is also not one-dimensional: different management roles need different skill sets which overlap with individual-contributor roles in different ways. Not to mention various high-impact roles at companies that don't involve formal management at all. So I think my tl;dr answer would be "you should try to figure out how your current highest performers on various axes can have more leveraged impact on your company, which is often some flavor of management, but it depends a lot on the people and roles involved."

For example, take engineering at Wave. Our teams are actually organized in such a way that most engineers are on a team led by (i.e. whose task queue is prioritized by) a product manager. Each engineer also has an engineering mentor who is responsible for giving them feedback, conducts 1:1s with them, contributes to their performance, etc.

Product managers don't have to be technical at all, and some of the best ones aren't, but some of the best engineers also move laterally into product management because the ways in which they are good engineers overlap a lot with that role. For engineering mentors, they usually need to be more technically skilled than their mentees, but they don't necessarily have to be the best engineers in the company; skill at teaching and resonance with the role of mentor is more important.

We also have a "platform" team which works on engineer-facing tooling and infrastructure. Currently, I'm leading this team, but in the end state I expect it to have a more traditional engineering manager. For this person, some dimensions of engineering competence will be quite important, others won't, and they'll need extra skills that are not nearly as important to individual contributors (prioritization, communication, organization...). I expect they would probably be one of our "best performers" by some metrics, but not by others.

The main outcome metric we try to optimize is currently number of monthly active users, because our business has strong network effects. We can't share exact stats for various reasons, but I am allowed to say that we crossed 1m users in June, and our growth rates are sufficiently high that our current user base is substantially larger than that. We're currently growing more quickly than most well-known fintech companies of similar sizes that I know of.

Unfortunately, it would not be prudent to share detailed stats publicly. However, we have over a million downloads of our Android app and are (or have been recently) #1 in the Play Store in Senegal. We still substantially trail Orange Money, our main mobile money competitor, in usage and volume though. We are still quite small in Cote d'Ivoire, though growing quickly there!

Great questions!

What are common failure cases/traps to avoid

I don't know about "most common" as I think it varies by company, but the worst one for me was allowing myself to get distracted by problems that were more rewarding in the short term, but less important or leveraged. I wrote a bit about this in Attention is your scarcest resource.

How much should I be directly coding vs "architecting" vs process management

Related to the above, you should never be coding anything that's even remotely urgent (because it'll distract you too much from non-coding problems). For the first while, you should probably try not to code at all because learning how not to suck as a manager will be more than full-time. Later, it's reasonable to work in "important but not urgent" stuff in your slack time, as long as you have the discipline not to get distracted by it.

Architecting vs process management depends on what your problems are, what kind of leader you want to be and what you can delegate to other people.

How do I approach hiring?

If you are hiring, hiring is your #1 priority and you should spend as much time and attention on it as is practical. Hiring better people has a magical way of solving many of your other problems.

Hiring can also be really demoralizing (because you are constantly rejecting people and/or being rejected), so it's hard to have the conviction to put more effort into it until you've seen firsthand how much of a difference it makes.

For me, the biggest hiring improvement was getting our final interview to a point where I was quite confident that anyone who passed it would be a good engineer at Wave. This took many iterations, but lowering the risk of a bad hire meant that (a) I wasn't distracted by stressing out about tricky hire/no-hire decisions, (b) we could indiscriminately put people through our hiring funnel and trust that the process would come to a reasonable verdict. After this change, our 10th-percentile hire has been about as good as our 50th-percentile hire previously, and we went from 4 engineers to 25 in a bit over a year.

I expect the exact same thing goes for investing in people once you've hired them, but I'm not as good at that yet so don't have concrete advice.

Just generally, what would you have imparted on past-you?

1. You suck at hiring, get better.
2. If you're worried that someone is sad about something (especially something you did), ask them!
3. Org structure matters a lot; friction, bad execution, etc. is often downstream of a bad division of responsibility between teams, teams having the wrong goals, etc. (Matters more once you are responsible for multiple teams)
4. Accept that you hate telling people what to do, and manage in such a way that you don't have to. (Perhaps specific to me.)
5. Hiring.

Yes, we've been doing remote work in some form since 2014.

Ben mentioned meeting cadence, but I would add to that, designing meetings to build relationships. With remote, voice communication is much more deliberate and only happens when people make it happen. And human relationships aren't really built over Slack, they are built via voice. So we're thinking a lot about how to make more of the right sort of relationships happen. Some examples of this would be:

• focusing 1:1s on relationship building with your lead (mostly by being careful to avoid the 1:1 being a "status update" meeting)
• having weekly team meetings which are small enough (<10, preferably closer to 6), with time designated for everyone to contribute and share something about themselves. we've done this by going around and asking each person to answer a question, e.g. "how are you doing really?" to "what fictional place would you most like to visit?"
• randomized 1:1 cross team chat events -- we use https://icebreaker.video/ (if this looks lame, don't write it off, it was surprisingly fun)

Beyond that, simpler stuff we do around communications transparency seems to help: nudge people strongly to put their message in a public Slack channel in almost all cases they intend to communicate with someone else. If you have a call to clarify something with someone, post the summary in slack. @-mention people when & only when you need them to read the thing you are writing. (If you have some tough feedback it's fine to keep it private, but even tough feedback can often be phrased in a way which is easy to share with others). We chose these defaults of communication transparency for the remote team because we wanted Slack to feel as much like a collaborative office as possible, in the sense that "stuff is happening, people are here and you can listen if you want to learn, and contribute if you have relevant knowledge." Many Slack teams default to "locking things behind DMs" in a way which makes that feeling a lot harder.

I'll let Lincoln add his as well, but here are a few things we do that I think are really helpful for this:

1. We've found our bimonthly in-person "offsites" to be extremely important. For new hires, I often see their happiness and productivity increase a lot after their first retreat because it becomes easier and more fun for them to work with their coworkers.
2. Having the right cadence of standing meetings (1-on-1s, team meetings, retrospectives, etc.) becomes much more important since issues are less likely to surface in "hallway" conversations.
3. We try to make it really easy for people to upgrade conversations to video calls, both by frequently encouraging them to do so, and by making sure that every new hire has a "get to know you" call with as many coworkers as possible in their first few weeks.

(Your mileage may vary with these, of course! In particular, one relevant difference between Wave and other remote organizations is that I think Wave leans more heavily on "synchronous" calls relative to "asynchronous" Slack/email messages. This is important for us since 80%+ of us speak English as a third-plus language—it's easier to clear up misunderstandings on a call!)

2. For personal work, it's annoying, but not a huge bottleneck—my internet in Jijiga (used in Dan's article) was much worse than anywhere else I've been in Africa. (Ethiopia has a monopoly, state-run telecom that provides among the worst service in the world.) You do have to put in some effort to managing usage (e.g. tracking things that burn network via Little Snitch, caching docs offline, minimizing Docker image size), but it's not terrible.

It is a sufficient bottleneck to reading some blogs that I wrote a simple proxy to strip bloat from web pages while I was in Senegal. But, those are mostly pathologically un-optimized blogs—e.g., their page weight was larger than the page-weight of the web-based IDE (Glitch) that I used to write the proxy.

3. Network latency has been a major bottleneck for our programming; for instance, we wrote a custom UDP-based transport layer protocol to speed up our app because TCP handshakes were too slow (I gave a talk on this if you're curious). We also adopted GraphQL relatively early in part because it helped us reduce request/response sizes and number of roundtrips.

On the UX design side, a major obstacle is that many of our users aren't particularly literate (let alone tech-literate). For instance, we often communicate with users via (in-app) voice recordings instead of the more traditional text announcements. More generally, it's is a strong forcing function to keep our app simple so that the UI can be easily memorized and reading is as optional as possible. It also pushes us towards having more in-person touch points with our users—for instance, agents often help new users download the app and learn how to use it, and pre-COVID we had large teams of distributors who would go to busy markets and sign people up for the app in-person.

1. Yes, I speak French, although not quite fluently. It's enough to interact with customers and agents in a pinch, but when I go out to do serious user research, I bring someone from our team who has better language skills. The language barrier is significant, and I would say somewhat hurts our ability to design the best possible products -- we've done a lot to overcome it though, and it's not one of our biggest bottlenecks at this point. Now our team is big enough that I don't even do that much user research on my own, and all the product managers I manage speak fluent or native French, so it's easier for them :)
   
   Before Senegal, we did a lot of our initial user research in Ethiopia, which had a greater proportion of English-speakers, and it was easier to get started there.

(I'll let Ben answer the internet-related ones)

On EA providing for-profit funding: hard to say. Considerations against:

• Wave looks like a very good investment by non-EA standards, so additional funding from EAs wouldn't have affected our fundraising very much (not sure how much this generalizes to other companies)
• At later stages, this is very capital-intensive, so probably wouldn't make sense except as a thing for eg Open Phil to do with its endowment
• Founding successful companies requires putting a lot of weight on inside-view considerations, a trait that's not particularly compatible with typical EA epistemology. (Notably, Wave gets the most of this trait from Drew, the CEO, who, while value-aligned with EA, finds it hard to engage with standard EA-style reasoning for this reason.)

Considerations in favor:

• Helps keep the company controlled by value-aligned people (not sure how important this is, I think the founders of Wave will end up retaining full control)
• If the companies are good, it doesn't actually cost anything except tying up capital for a while

Overall, I think it could make sense at early stages, where people matter more and metrics matter less (and capital goes further), but even at early stages there's probably much more of a talent constraint than a funding constraint.

The Wave business is currently unprofitable, although Sendwave is profitable and has been propping up the mobile money business. We have plenty of runway at this point, but we are likely years away from becoming profitable: mobile money is a very expensive business to start, mainly due to investing in the agent network.

In terms of what EA ecosystem should provide: the best thing would be better support for entrepreneurialism. Support from others probably comes in the form of social encouragement -- I think Founders Pledge is one notable EAish org working on this, as they don't just get people to pledge but are working on building a network of founders who can support each other in various ways.

I think the ecosystem needs a more coherent theory of corporations doing good with their mission -- in particular, there's a dominant cynical ideology on e.g. Hacker News, where people see that the purpose of a for-profit corporation is to "create shareholder value" and then they assume that the leadership must be sociopaths. In fact, the bulk of companies are trying to do something great for the world and a ton of them succeed at it. I don't know how to change this perception quickly, but maybe an army of social-media commenters would work :P

What about money? EAs giving founders a little money to quit their job and get started makes a lot of sense to me as well, but I recommend capping "free EA money" to for-profits around $50k or so: money is fungible, and you have good reasons to be in the competitive investment markets by that point -- those markets create useful feedback loops for both startups and investors that it doesn't make sense to diverge from.

Good questions.

Regarding general startup barriers:

Ultimately, there are very few barriers to getting started doing the things that you want to be doing anyway: for most countries, if you are from a developed country, you can fly there as a generic visitor and start talking to people. (once COVID is over anyway. note: I definitely do not recommend violating any visa laws.) My first trip to Ethiopia to investigate mobile money's potential was only a week long -- stayed in a hotel, made a few connections, talked to a bunch of people in a marketplace. A subsequent month-long trip was a bit more involved, but still required no special visa, just a longer stay in some kind of temporary housing.

Once you are pushing up against the limits to generic visitors (often 3 months or so), hopefully you've learned enough to know whether it will be worthwhile to invest further, at which time you probably need to hire a local lawyer to start investing in figuring out how to do whatever's next most important (maybe your visa; maybe creating a local company, etc).

I want to emphasize that startups are hard. Entrepreneurship of any kind is going to put barriers in front of you. The question is, do you want to let these random barriers block you? Cross-border paperwork is one example of such a barrier--but so is getting a bank account, getting licensed, negotiating an IP deal, or whatever junk you need to do to get started in almost any industry. Paul Graham writes about this in Schlep Blindness -- in some sense, value is created when you decide to plow forward and solve the problems in front of you, despite them looking annoying to solve.

So yes, I think these barriers are a blocker for many, but they don't have to be a blocker for you :)

Stepping back to our experience: we started in Ethiopia, which is not an easy place to do business by any metric. And we got very far before we had to stop (it's a place that is unusually hostile to foreign companies) -- far enough that we had learned significant lessons about how to start mobile money which we were able to port over to Senegal (which we chose partially due to "ease of doing business"). So while I wish we had not decided to spend so much time and energy there, I also don't 100% regret it. Plus, it was a lovely place to be and I have some wonderful friends from that era.

I think if a given place is the best place to get started, you should just go to that place and try not to over-index on "ease of doing business". However, if you have many similar-looking places to start, it will likely save you quite a bit of energy choosing a place where it's easier to do business!

Oh, and in terms of raising money, I think you should go to Silicon Valley for that (if you have a scalable enough business anyway) unless you have strong local connections.