Ask HN: First technical hires, what worked and what didn't?

[avyfain]

I'm a first time founder. The smallest company I've worked full-time at was ~70 people when I started, though I did intern at startups with <10 people early in my software engineering career. I'm looking for anecdotal advice about how to make things work at the earliest stages, particularly on the technical front.

Would love to hear from founding engineers, early technical hires, and technical founders. What decisions had the most impact on your experience? How did you choose what problems to tackle first? How did you pick tools? What expectations did non-technical team members set? What would you do differently? In short, what worked and what didn't?

(And yes, I'm hiring founding engineers in SF. More info in profile if you're curious.)

[rangooski]

First good decision we made at our old startup was use what was old and real talent was easily available instead of choosing a new tech stack.

Second was proven self suffiency on capital via revenue rather than funding.

Third was people, you hire people who chime with you and let them do it. I guess that is what matters on the long run when things go downhill.

Edit: typo

[ra0x3]

I'll bite :)

- Stick to the basics to start: Mattermost/Slack for messaging, Github for issues/work, standard tooling (I imagine you might be B2B SaaS? So maybe Node or Python). There's a small chance you're building something that's actually "new" - so just stick with what is tried and true.

- Have an onboarding doc! Even if you don't stick with it, or even if it doesn't make a lot of sense. When do people get paid? Who to go to for HR-like questions? Is there a virtual happy hour on Fridays? How should one communicate on Github/Slack? How do I get my project setup with all proper dependencies, etc. This saves a ton of "Oops, we never actually clarified this" down the road. - This doc is where you help clarify company culture (#NoSmartAssholes) and stuff like this. - This is also where you can set expectations on the role, and what's expected.

- Have work ready to go. It will only take a decent programmer a few hours to get setup (obviously depending on the project, but you mentioned you're small so it's probably just a repo you can clone). Use those Labels on Github issues liberally. Have a slate of "Good first issues" ready to go that can introduce the new hire to all/most areas of the codebase gently :).

- Lastly, vibe is maybe a little more important than technicals at first? Of course there's work to be done, and it needs to be done correctly, but on a really small team being able to have an actual discussion about "What did you do this weekend?" is maybe a bit more important than "Proper tests were not added for this new feature".

TLDR: Use the same comms platforms as everyone else, have a decent onboarding doc, have some work already triaged and ready to go, focus on good vibes and the technical stuff will come :)

[paulcole → ra0x3]

> This doc is where you help clarify company culture (#NoSmartAssholes) and stuff like this.

The less you try to do this the better. Keep it as simple as possible. Because your culture isn’t what you put in a Google Doc, it’s how people actually behave.

We try to impress upon people early that our culture is in their hands because no matter how much we say #NoSmartAssholes (or whatever) if they are a smart asshole, that is part of our culture now.

The onboarding doc is a great idea though. I always liken it to customer service. Businesses put all this time and money to attract new customers and business owners hate it when a new customer is treated poorly and doesn’t have a great first experience. But then they put all this time and money into hiring new employees and more often than not just give them a computer and hope things get figured out.