Add seed stage hiring strategy

@jamesefhawkins @mariusandra @Tannergoods @EDsCODE

Happy with all comments including "start over" or "completely disagree" or anything else. It's important we get this right.

Hey, some thoughts regarding the new roles. I could be totally wrong though, so take them with a grain of barley.

1) What are the expectations of the investors in spending the money? Is there an implied "burn as much as possible to get as far as possible with the shortest time" mentality? Or are we free to evolve as slowly as we please? In the current economic uncertainty, I'd advocate for a more cautious approach, while obviously not being stupidly slow.

2) I guess there's work for a full time devops engineer, yet the role is still rather vague for me. I get the parts about supporting self-hosted customers and writing guides/scripts for cloud providers, but I'm having a harder time understanding the "scale and optimise Postgres database and queries" part. (I don't disagree, yet would like to write/think this through...)

I think writing good queries should be part of the job of every general/backend engineer, not something a "devops engineer" comes and cleans up after. I'm saying that since after a certain point, there's not much further you can optimise postgres with the types of queries we're making... and it's not hard to get to that point. An engineer who could guide devs in this could be valuable obviously.

For our own hosted deployment, we can get very far with the cloud tools available (Heroku, GKE, etc). Scaling the app dynos/pods is rather straightforward. The only real question is how to scale the postgres DB if we continue using that as a database. Here I think it makes sense to switch to something like Citus, which supports sharding by team_id out of the box and delivers great scalability already thanks to that (and other stuff). We would be in good company.

Right now we could just install their heroku addon and let the cloud elves take care of the rest.

Having someone specialised in this will make absolute sense as the company grows. I'm just not convinced that this is the first hire we need. It could be more valuable to have another strong generalist or two who can help push out features faster, build a massive integration test suite and help make PostHog a stronger product overall.

Somehow I think it's more valuable now to hire a strong backend/django engineer with an interest in devops than to hire a full on "scalability" engineer (yaml ninja) while we haven't reached the theoretical scalability limits yet. Hiring too fast here might backfire.

3) We should definitely have a designer who would clean up everything related to the current visual image of PostHog. Yet I'm also not sure if this is a full time gig. Having a freelancer make a new logo plus a bunch of templates for the website and app UI would get us very far without requiring a full time person on the payroll. They could spend some time updating our ant design layout and let us roll with the results. A great place to find such freelancers is Dribble. A lot of people there are available for work... and this is a good way to get someone to come onboard eventually if there's a lot more work in the future.

Right now though I don't think that a designer should design every page/modal/popup/box. We can get really far if we just have the right looking elements and some guidelines in place.

4) I love those "working managers" and "managers of one" posts. At this scale and with the current ambitions, we don't have the resources to either have full time managers nor have people who need a lot of hand holding. Everyone should thus perform on all their cylinders.

That said, for the "working managers" Tim and James, I do expect a lot of random stuff to take up a large part of your day going forward. Everyone will be demanding things from you left and right, so you will definitely not be working full time just on the product.

5) In the engineering side, we are currently three and all fullstack, but taking out half a Tim due to increasing demands on his time and removing myself partially as I seem to be working a lot on the periphery, we just have ~1-2 people actually fully working on the product and building the great developer experience we're talking about.

Thus I think that before any other devops/designer role, we should find a way to bump this core developer count up by at least one or two.

Those were my 0.02 EUR

Some great points in the above. Marius, to answer your q: We haven't committed a timeline yet or what we'd set the burn rate at, so we can optimize here ourselves.

If we were B2B SAAS I'd be saying we should aim for a big Series A within 12-18 months. That means investors can see a steep rate of growth, which badges you as an exciting company that they'll miss out on. This round would be sales focussed.

Given we are open core, from all the investor discussions I've had, I think the best possible series A story would be something like "we have 100K users at 10k companies, and we're profitable. Here's how we'll go from this level of revenue to something much larger".

If we can do that in 12 months, great. However, I'd guess 24 months is what we should aim for so we don't get too commercial too quickly. We can spend the first 6 working out how to grow adoption grabbing whatever money happens to come in the door along with it, then the latter 75% of the time getting monetization right.

To summarise, I'd see it as:

Spend 6 months getting as much adoption as humanly possible.
- Two ways: more stuff inbound + going from 1 user to many
Spend 18 months increasing our revenue, then do a Series A.
On the roadmap, we should get phases 1 and 2 complete. Then we should do phase 3 = paid features.
Before Phase 3 is done, we just charge for hosting.

RE: Marius

Just to add - even if we hire as per plan we will have 3 years of runway (even if we make $0 in revenue) which is a long time. I don't think it makes sense to slow down hiring to increase that even further
I agree with this. It would be good to find someone who's comfortable enough to write all the cloud provisioning stuff, but could also contribute to new features. I'll update the job spec for that. I also agree with James it probably is worth making that person our next hire.
I'm a little torn. I can see the rationale for being conservative and doing some contract work. However I do think a non-zero amount of our appeal to developers will be "it looks slick". That surfaces in things like how our docs are written, how our issues are written, design of the website, design of the readme(!) and also design of the product. The product also needs to be super slick to use, and I think having someone who's main job it is to ensure that could force us to do this properly.

Perhaps the solution is to find someone on a contract base soon to do logos/templates etc, and then see if we want to take that person full time.

Agree I won't be a full time dev but my personal goal should be to get as close as possible.
Coming back to point 2, I think it's worth our next hire being a devops-y person that can also do features so we have more firepower, and you can focus more on core stuff rather than periphery.

Actions:

[x] Change devops job spec to be closer to generalist, and move them up in the plan
[x] Add note that we are going to start looking for a design contractor soon.

RE @timgl

Agreed that we shouldn't artificially slow down hiring.

3.1. Regarding docs vs design - do you think there could be one person who would make sure the docs are well written and also assure that the interface well designed? I'm not sure how much of an overlap of skills there is here... nor how much do these responsibilities overlap with the work of @Tannergoods .

3.2. I see that hiring a designer is now planned for Q4 of 2020, so approximately half a year from now. I think we should already start wow-ing people with a slick product. Hence the recommendation to find a freelancer now who could help us where it hurts the most... and perhaps he/she could be the eventually hired full time. In any case, I think we shouldn't wait until Q4. Also, to be clear, I'm not against hiring someone full time. I think we need someone to do this role.

It's an ambitious goal to be coding close to 100% of the time. If you work 200% of the time, you can pull it off easily :D.

Speaking from my (somewhat limited) experience, as the team grows, you'll have many other things that will take up a lot of your time and it'll be harder to cling on to coding. Having a team of "managers of one" will definitely help shift the balance, but not fully.

In the book High Output Management the former CEO of Intel says something like this (I'm paraphrasing): the value of a manager is the sum of the value of all the people he manages. That means that instead of optimising to code as much as possible yourself, you should optimise for everyone in your team having the least amount of distractions, so they can always be "in the flow" and produce the best work possible.

This means your time will be filled in with a lot of things just so that others won't have to do them. Things that you're already doing: responding to issues, talking with customers, being the first to fix bug reports, hiring people, motivating the team, taking part of higher strategic discussions, planing sprints, doing a lot of QA, being "customer support" for people on your teams, investor meetings, being the proxy between designers/product/developers, being the only one who knows all about the product and where the dragons hide, evangelising etc. This is not an exhaustive list, but already things here will add up quickly as the team grows and the product gains popularity. It'll be hard to find time for coding as much as you'd like to.

Also, here's a pretty good article about building software teams in a startup. Might be worth going through. The entire "increment" magazine is really valuable actually. I recommend subscribing to their newsletter to get notified of new releases.

@mariusandra 3.1 I didn't mean well written docs (I think that's still primarily responsibility of devs) just that the docs look/feel awesome 3.2 Yep it does mention it now - James is going to start looking for a designer contractor now and then that might translate into a full time role

I agree I won't be 100%, have clarified that in the doc now. In reality there will be a lot of demands on my time (as you mention) and those are all equally important. However both to lead effectively and be able to make good strategic decisions I need to get my hands dirty a lot. I suspect by the time we have tiered management that will drop down.

PostHog / handbook

Add seed stage hiring strategy #39