Varun Srinivasan
@v
How to ship fast as a small company looking for product-market fit 1. Avoid side quests. If you aren't coding, selling or talking to users, it's a side quest. 2. Eliminate process. Don't cargo cult your team into sprint planning, offsites or recurring 1:1s. Gather once a day, talk about what to ship and ship it. 3. Hire people who love to ship fast all the time. Most people cannot do this correctly or do not enjoy doing it. 4. Don't hire people who can't ship. It's temping to get an ea, bd rep or community manager to offload work. This usually just creates more work for you. 5. Have a simple and fast tech stack. A new hire should be able to write a feature in a day and deploy it to users in 30 minutes.
34 replies
86 recasts
634 reactions
jj 🛟
@jj
The hardest challenge having run 150+ eng teams is scaling this. At some point the problem isn’t are your engineers good, you cross a dunbars number and people are essentially strangers. You are basically throwing stranger together and asking them to work well. When that happens that’s when you start needing process because people don’t know how to talk to each other. Keeping process lightweight so that people remember it and will do it will be important. Culture is just really hard to scale unless you hire slowly over time and have really good retention. Then constantly removing process will be another battle because processes, policies and other BS starts creeping in and getting a life of its own. Engineers just love complexity or they think it’ll let them stand out. The best engineers I’ve worked with will be able to explain and execute highly complex systems but make it self evident and make it seem super simple.
1 reply
0 recast
6 reactions
lightcap
@lightcap.eth
Scaling an eng team is psuedo-productivity. Almost always driven by outside perception of what it means grow a successful startup—typically VCs. IMO so few teams should be that big. I've yet to see teams bigger than 8-10 really ship. Even massive company wide individual teams should be no bigger than 8-10. The friction and institutional inertia that builds with any more outweighs any benefit of "scaling" an eng team.
2 replies
0 recast
3 reactions
jj 🛟
@jj
Unfortunately success will pull you into scaling a team. I do think it’s getting better that you can delay it or do more with less with more automation and AI, but your people will burn out if you don’t hire more people.
1 reply
0 recast
0 reaction
lightcap
@lightcap.eth
That's not necessarily true. In fact I think in most cases there'd be more success if that wasn't the common conception. Was instagram successful? What do you define as success?
1 reply
0 recast
0 reaction
jj 🛟
@jj
I mean when you find PMF that sucks you and your team’s lives - when your users and customers demand things, when things break everyday because you’re shipping and complexity increases I’m really saying that after a few straight years of that, they will burn out and you do need better work life balance
2 replies
0 recast
0 reaction
lightcap
@lightcap.eth
I've been down that road too. But adding more engineers only helps to a point, MMH and all. Plus, quality of engineers matters far more than number. Having to onboard a bunch of jr devs like so many corps love to do to keep costs down and "develop" talent is a net loss in productivity in most cases.
1 reply
0 recast
1 reaction
jj 🛟
@jj
Yea I’ve don’t that too, and learned from jr engineers. Some have become rockstars others have floundered. Agreed quality matters - but also requires culture and chemistry matters to bring out the best in people. Had plenty of “paper all stars” never thrive. Maybe you have more experience than me around this
1 reply
0 recast
0 reaction
