Thread by @radhika_agar

As a part of our Velocity program at @BlumeVentures, we invited @ponnappa at @gojektech for a session on 'Building a Tech Org'

Thread below on our learnings on hiring, internal processes, & recommended reads👇

#BlumeVelocity

@DeepikaDakuda @RaoMaterial @sajithpai

0/n

1) Pre-PMF rule: Always be < 2 weeks away from a ground up rewrite.

Pre-PMF, most of what you build won't work & once you hit PMF you can't pause the work —> so, you carry over junk from earlier.

Don't accumulate debt in your project management!

1/n

2) Post-PMF rule: Don't depend on anything that is not in production!

Teams tend to make projects depend on each other to avoid duplication and maximize efficiency — but it's better to duplicate something than to depend on what is not yet in production.

2/n

3) Tech for non-tech founders: Make the effort to understand the tech canvas - the same way you understand the effect of inflation on your fundraise w/o an Economics degree!

You don't need to learn to code but you need to know the constraints of your tech and how it moves.

3/n

4) Hiring: Titles are designed for recruiters, not for executors.

An "Android engineer" isn't someone who knows Android *really well*, it's someone who *only* knows Android. You want the former, not the latter.

Optimize for execution, not for ease of hiring!

4/n

5) Hiring:

- Don't do artistic interviews (i.e. create on the spot questions). Instead, use standardized questions
- Use 2 interviewers —> prevent biases
- Successful hire = someone still on the job & doing well 6 months in

Recommended read: gitlab.com/india-startups…

5/n

6) Network driven hiring: Build a network with people you want to hire

@ponnappa says his hiring pipeline is yrs long. @Twitter / @Clubhouse / @newsycombinator are great funnels. Build relationships early on so you know how they think. Good hires can be a year long process!

6/n

7) Generalists vs specialists: At <50 engineers, don't need specialists. By 500 engineers you have specialized teams. Somewhere in the middle you hire specialists.

Don't need QAs. Your best engineers should be flagging the issues themselves.

Read: gitlab.com/india-startups…

7/n

8) Retention:

- Have a high bar & fire people who don't meet it. A bad engineer causes more stress for good engineers. Maintaining a bar creates a better work life for others.
- Don't prevent people from leaving. Do 1:1s so you always know in advance when they're leaving.

8/n

9) Common terms: Create a glossary of terms that lives across the entire company - everyone refers to the same glossary.

Every team uses different terms to refer to things➡️build a shared understanding of labels. Critical to dealing with invisible complex systems.

9/n

10) Cadences: Control all execution through cadences. It's the founder's job to create this heartbeat.

- End of each cadence: something needs to be in production
- Longer cadence➡️less clarity
- Have a documented list of all cadences running
- Cadence should be < 1 week

10/n

11) Involvement of leadership in the coding: Up to 100 tech people - everyone should be hands on.

- Manager / Tech Lead (Level 1) - Be fully hands on
- Manager of manager / VP (Level 2) - Be partially hands on
- SVP (Level 3) - Should ideally be involved with the code

11/n

12) Writing: Need to make your engineers comfortable with writing & communication - it's the barrier to good documentation

@ponnappa runs daily drills in bootcamps:
- Write a 2-3 para piece on what was done & publish it publicly
- Pick a random topic & just talk on it

12/n

13) Finally, @ponnappa's recommended reads on tech org building:

- Hackers and Painters by Paul Graham
- Mythical Man-Month by Fred Brooks
- No Silver Bullet by Fred Brooks
- The Gervais Principle by Venkatesh Rao

Full list: gojek.io/blog/the-gojek…

FIN.