I agree with Sam that most of the difference between working at a typical tech company and CEA is the size. Even most startup employees probably work at startups 10-100x the size of CEA. Unlike Sam I have worked in the tech industry, but I when I was hired at Kairos, I was employee #6, which I think is unusually early. Relative to Kairos, I think my experience at CEA has differed in the following ways:
I bring more of myself to work. CEA really wants to know what I really think the best thing to do is, and I get to be really open about what I think that is, and all the reasoning I have. I can speak my native EA-language here (nobody blinks an eye when I talk about expected value).
I’m more in charge of my own projects here. Kairos gave me a lot of autonomy, but CEA gives me even more.
The converse of that is that Kairos had more mentorship from people more experienced than me. I think Sam and I have gotten pretty good at this, but Kairos had one incredibly impressive software engineer in particular who I learned a lot from.
It depends on which tech company, but I know a lot of people working for companies that they think are fine, but not so great that their jobs are doing much good directly. This is definitely the best perk of the job, which now that I’m writing it sounds trite, but is my honest feeling.
I’ll first caveat by saying that I haven’t worked at either a typical startup or big tech company.
I think that there’s probably not a huge difference between CEA and a very early stage startup. I think that the most relevant dimension is just scale – currently we’re two devs working on a bunch of different projects, which means a high degree of autonomy and ownership over the code in a way that I expect is similar to a lot of small startups. We’re obviously a more mature org though, so we do have a lot of processes in place (CI, a dedicated Operations team etc) that you wouldn’t find at a really new startup. So, in some sense it’s the freedom and ownership of an early stage startup combined with the security and flexibility of an established org. It also means that there’s a lot of time spent on interacting with users (as opposed to just being siloed in your text editor), which I really like, partly because this is a great community and it’s really nice to talk to EAs who use your software, and partly because it helps you to get better at thinking about product development and making things that serve the needs of your constituency really well.
Another thing that’s a bit strange about CEA as a non-profit, and as an EA org, is that the approach to scaling is a bit different. In a for-profit startup, your aim is to grow as fast as humanly possible (at least, when you hit product-market fit). We’ve deliberately avoided that strategy (at least for now), in large part because it doesn’t seem prudent to scale something like the EA community as fast as possible, because scaling fast trades off pretty hard against the fidelity of your message and the existing culture of the community. This could obviously change in future, but historically it’s been part of our approach. This in turn means that the challenges are a lot about understanding how to build solid products that work for EAs, rather than how to run huge k8s deployments etc.
What have been the biggest surprises or differences working for CEA vs typical startup or commercial work?
I agree with Sam that most of the difference between working at a typical tech company and CEA is the size. Even most startup employees probably work at startups 10-100x the size of CEA. Unlike Sam I have worked in the tech industry, but I when I was hired at Kairos, I was employee #6, which I think is unusually early. Relative to Kairos, I think my experience at CEA has differed in the following ways:
I bring more of myself to work. CEA really wants to know what I really think the best thing to do is, and I get to be really open about what I think that is, and all the reasoning I have. I can speak my native EA-language here (nobody blinks an eye when I talk about expected value).
I’m more in charge of my own projects here. Kairos gave me a lot of autonomy, but CEA gives me even more.
The converse of that is that Kairos had more mentorship from people more experienced than me. I think Sam and I have gotten pretty good at this, but Kairos had one incredibly impressive software engineer in particular who I learned a lot from.
It depends on which tech company, but I know a lot of people working for companies that they think are fine, but not so great that their jobs are doing much good directly. This is definitely the best perk of the job, which now that I’m writing it sounds trite, but is my honest feeling.
I’ll first caveat by saying that I haven’t worked at either a typical startup or big tech company.
I think that there’s probably not a huge difference between CEA and a very early stage startup. I think that the most relevant dimension is just scale – currently we’re two devs working on a bunch of different projects, which means a high degree of autonomy and ownership over the code in a way that I expect is similar to a lot of small startups. We’re obviously a more mature org though, so we do have a lot of processes in place (CI, a dedicated Operations team etc) that you wouldn’t find at a really new startup. So, in some sense it’s the freedom and ownership of an early stage startup combined with the security and flexibility of an established org. It also means that there’s a lot of time spent on interacting with users (as opposed to just being siloed in your text editor), which I really like, partly because this is a great community and it’s really nice to talk to EAs who use your software, and partly because it helps you to get better at thinking about product development and making things that serve the needs of your constituency really well.
Another thing that’s a bit strange about CEA as a non-profit, and as an EA org, is that the approach to scaling is a bit different. In a for-profit startup, your aim is to grow as fast as humanly possible (at least, when you hit product-market fit). We’ve deliberately avoided that strategy (at least for now), in large part because it doesn’t seem prudent to scale something like the EA community as fast as possible, because scaling fast trades off pretty hard against the fidelity of your message and the existing culture of the community. This could obviously change in future, but historically it’s been part of our approach. This in turn means that the challenges are a lot about understanding how to build solid products that work for EAs, rather than how to run huge k8s deployments etc.