After the awesome 6 years as a SWE at Google it was time for me to fly out of the nest and back into a startup. During my last month I did a ton of Goodbye coffees - some of my friends wanted me to stay, some secretly envied my move to step out of the comfort zone. But all of them took the opportunity to impart nuggets of wisdom on a fellow engineer setting out on a perilous journey. I believe that I’m not alone and hope that my notes can be useful to you.
Let’s be friends on Twitter @svonava, we are hiring!
Now grab a cup of hot cocoa and let’s do this:
Culture & teamwork
- First: formalize the problems, second: formalize the solutions.
- Role of agile is to have a contract between business and engineering that allows to stabilize the direction for the sprint duration (2 weeks) and helps set expectations. It’s a common language of work definition and processing, that bridges two worlds which fail to communicate otherwise.
- Remote culture generates artifacts which is good (collective knowledge base, project trail etc), but be careful about the associated slowdown in the early state of each task/project. Need strong individuals who can draft a good proposal while asking the right key questions to avoid a lot of back-and-forth on a big doc.
- Do not get stuck in the ‘hybrid remote’ model where a part of your employees reached a critical mass in one location and the rest is dispersed - either fully remote (check the gitlab.com story) or ~all people in offices with critical mass.
- Use friction between team members of different backgrounds as a tool - it forces you to make tangible arguments. Then both sides need to recognize when their arguments are getting too contrived and serve only to justify a pre-existing decision and re-evaluate.
- Upon joining an early startup as a CTO or VP of Eng, work to build trust with the exec team to be able to provide effective ‘cover’ for the eng team. This is make-or-brake for scaling.
Technology
- Integrate through data (e.g. common data formats, protocol buffers etc) vs through functionality (e.g. calling somebody’s libraries).
- In young ecosystems like blockchain, abstract all players (think message queues) to be able to swap to the next hot thing or swap out when a project explodes.
- Be tech-agnostic and focus on building/owning the customer relationship.
- Invest into APIs, take shortcuts within the components (cohesion / coupling).
- In finance, if you can spend your eng time 50:50 (building new stuff, putting out fires) vs (investing into the system and infrastructure), you are doing well. Google is more like 30:70 which is even healthier. This means that by having a proper system setup and stable infrastructure, new stuff is much easier to build and there are fewer fires.
- Separate input from action - build system components that never drop an input (transaction) they log and serialize everything and then try to process it after that. If they fail, they need to be able to rewind to where they left off and continue. If they can’t continue, then your intern will have to enter it manually from logs - doesn’t matter - especially at the initial scale.
- Defer decisions by building generic enough foundation, make decisions that are easily reverted fast, make decisions that are hard to revert slower (but do make them).
- However don’t get slowed down by building too generic. Main role of the software at this stage is to facilitate product iteration/demos. Build a software foundation that allows rapid prototyping, instead of over-engineering for long term.
- Pick your battles, buy/integrate mature technology where possible, innovate/rebuild only key pieces.
- For marketplaces - start in a centralized way going to the market through an entity that already serves as a market-maker and then spread to both the supply and demand sides, relinquishing the control and getting buy-in gradually in exchange for it.
Let me know what you think on Twitter!