As the CTO for an early-stage startup, I had put together a version-1 of the Principles and Best Practices for our engineering team. Most of these are borne out of my past work experiences at a variety of companies, including two of the FANGs. There are many great things I’ve learnt from these companies. But there are also many frustrations that I’ve encountered – frustrations that we endeavored to remedy at our startup.

We recognize that not everyone will like the core principles and best practices described below. And almost everyone will find something that they disagree with. This is to be expected – it is rare for any two people to agree on everything, especially when much of it goes against the prevailing way of doing things. It is also worth noting that not everyone is a good fit for the culture and processes being suggested here. Some people operate best in a more traditional corporate culture. But for the people we did hire who were a good fit, it worked really well.

Principles

Put the team’s goals first

We aim to operate like a professional sports team. Our primary goal at the workplace is to succeed at the highest level possible, and build the world’s most efficient, lean and agile product team. The following principles and best practices are all designed to achieve this goal. Avoid any and all other distractions that take focus away from this goal.

Hire and promote candidates who can best help the team

We strive to recruit the most talented candidates for all positions, regardless of personal connections, personality, or circumstances.

Discriminating in favor of or against someone, on the basis of race, religion, caste, gender, sexuality, national origin, or any such factor, is not acceptable.

We recognize that most people are subconsciously biased in favor of or against certain demographics. We expect everyone to make great efforts to regulate their biases, and to judge all candidates on their individual merits.

Promote team cohesion while at work

Everyone should carry themselves professionally in the workplace, and make their colleagues feel included and welcomed. Avoid behaviors that will make any demographic group feel uncomfortable, disrespected, or disregarded.

As responsible citizens, we all have a duty to engage in the political process. I’m sure you have beliefs and opinions that you feel very strongly about. We certainly have controversial opinions of our own. But do not subject your colleagues to them. When at work, avoid discussing topics that are not immediately relevant to your job responsibilities if they might cause heated debates or upset any of your coworkers.

While at work, focus intently on doing great work, furthering the company’s mission, and growing your career. We encourage you to passionately follow through on your other beliefs, in your time outside the office.

Single Decision Maker

We do not believe in decision-making by consensus or committee. It leads to diffusion of responsibility, and a lack of ownership or accountability. Everyone’s opinions and suggestions are valued and welcome – but decisions are ultimately made by a single explicit decision-maker who assumes all ownership for that decision. By default, the single-decision-maker will be the person who is most actively working on that task. If the decision is overruled by someone else more senior, that person then assumes all ownership for that decision.

We expect all leaders to actively seek out and seriously consider everyone’s feedback and suggestions, in order to make the best possible decision. A decision that they will bear full responsibility for. 

Once a decision has been made, we expect everyone to commit to it. Reasonable people can and will disagree. We do not expect you to cheerlead every decision made by others. But we do expect you to commit to it and not undermine it.

If you feel particularly strongly and would like to fight against a decision, you are encouraged to talk to the decision maker 1:1, or escalate it to senior leadership. If all else fails and this is a deal breaker for you, we understand and will not hold it against you for leaving. But staying with the company and undermining a decision that has been made, undermining the person who made the decision, publicly lobbying against it, or fomenting dissent, is not acceptable.

Ownership

People with an “employee” mindset passively do what they are told. And they use the full extent of the budget and time they are given. This is not the mindset we want at our company.

We want everyone, especially managers, to have an ownership mindset. As owners, we want everyone to:

1. Think critically for themselves, push back and provide feedback, when they are asked to do something that is suboptimal
2. Make wise investments that will pay off over time
3. Avoid unwise investments that cost more than they deliver
4. Treat the company’s revenue and expenses as you would your own. Be laser focused on minimizing costs, maximizing productivity, and delivering an outstanding customer experience

Look for inspiration from small business owners, not corporate employees.

No Jerks

Treat all colleagues with civility, regardless of seniority. Disagreeing and critiquing ideas is strongly encouraged, but never engage in ad-hominem attacks. Always keep your emotions under check, and never yell or speak demeaningly to others.

If someone makes a mistake or makes a decision you disagree with, objectively point out the flaws and weaknesses in the decision they made. Do not use colorful adjectives to insult them or their work. 

Gordon Ramsay and Simon Cowell are most certainly not the kind of people we want in our company, regardless of how talented they are.

Best Practices

Design/Code Reviews

Be a Force-Multiplier, not a Ninja

As builders, the things we build take on a life of their own. A bad design decision will have negative impacts on numerous others for years and years. For this reason, the single highest leverage an engineer can have is improving on designs and code before things go into production.

More practically, this is something that senior developers are best able to do. In many companies, there is an expectation that senior developers focus primarily on building shiny complex projects. When required, this is certainly great. But do not neglect your responsibilities to the wider team. As a general rule, the best ROI a senior developer can have is helping others improve on their designs and pull-requests. For this reason, every design and pull-request should be reviewed by at least one senior developer.

Design Docs

It takes time and effort to implement functionality in a specific manner. Avoid wasteful rewrites by first communicating what you intend to do, and quickly course-correcting if your reviewers suggest a different approach.

For complex projects that span multiple components or pull-requests, first write a design doc before starting work on the implementation. Include as approvers one or two domain experts for every component being impacted, and ensure that you get their explicit approval. 

If you’re the reviewer of a design doc, treat it similarly to a pull-request – review it quickly and asynchronously. You don’t need an entire team of people sitting in a room together, listening to someone’s rehearsed presentation, just to do a design review.

Note that I’m using the term “doc” very loosely above. It isn’t supposed to be pretty, wordy, well formatted, or follow a predefined template with a hundred boilerplate questions. It is supposed to be concise and to-the-point.

When reviewing the doc, focus entirely on the proposed design and its pros/cons. Avoid going off on other tangents. Do not get distracted by the doc’s formatting or wording. Only ask for more information or revisions if it will meaningfully impact your recommendations. The goal of this doc is to accelerate development velocity, not slow it down.

Draft Pull-Requests

For each pull-request, first create a draft pull-request, demonstrating the proposed implementation at a high level. Use TODOs and placeholders to indicate which classes/methods you will be touching. Send it off for review and then immediately start working on the actual code and tests.

This mitigates the amount of wasted effort, if your reviewer then suggests a completely different way of implementing things. Once your reviewer approves the draft, link to it in your pull-request, to make sure everyone knows what was already discussed and agreed on.

Code Reviews

All code should be reviewed prior to merging, unless you’re dealing with high-severity production bugs.

Strive to have at least one reviewer who is more senior than you, even if that person has less domain knowledge. This person will break all deadlocks, if you and your reviewer can’t agree on the best outcome.

The other best practices around unblocking others are especially relevant here. Strive to start reviewing design docs and pull-requests within 2 work-hours of receiving them. Do not keep people waiting.

When reviewing code, it is easy to focus on the things you’d like to see changed. Remind yourself to also compliment things that are done well.

Some people recommend not leaving too many comments at once. We recommend the opposite. Do not string people along across multiple iterations. Give their pull-request a comprehensive review, and post all comments upfront. This allows the other person to address all of your concerns in one shot, with minimal time spent waiting for further comments. Strive to merge a pull-request in exactly 2 iterations – the initial iteration, and a final iteration that addresses all of the reviewer’s concerns and suggestions. Having 4 iterations or more is an organizational smell if it happens regularly.

Tech as a Means not an End

It is tempting to embark upon glamorous “tech improvement” projects that sound very flashy, but deliver minimal value to our users. For example, rewriting your code in Rust. At many companies, overengineered projects and “improvements” are commonplace because it’s an easy way for engineers to showcase their technical capabilities, “demonstrate impact”, and do cool engineering work that looks good on their resume.

Resist this temptation. Tech is a means to an end, not an end in itself. Focus your time and energy on the things that matter to our end users. Embark upon big tech projects only if they translate into improvements for the end-user. An investment that costs more than it delivers, is a bad investment. Be very wary of bad investments.

To enforce this, team performance will only ever be evaluated on the basis of end-user impacting improvements. Not tech projects that promise amorphous improvements in the distant future. 

If you’ve made tech improvements that cut latency by 30% for the user’s API calls, that is great. 

If you’ve paid off tech debt which then allowed your team to deliver twice as many user-impacting features, that is also great.

But if your team has spent half its time working on “tech improvements”, and ended up delivering fewer improvements that users actually care about, that is bad.

Depth Before Breadth

In many companies, we often see every engineer attempting to develop a superficial understanding of every single initiative embarked by the team. They often do this by spending multiple hours every day attending meetings and reading docs on topics that they aren’t working on.

Needles to say, this takes time away from delivering concrete deliverables that our customers care about. More pernicious, in the long run, the team becomes filled with people who are proficient but not experts in any topic. Without experts to give authoritative answers on how things work, technical discussions often devolve into guesses, hunches and even misinformation.

For this reason, we encourage remaining focused and developing a depth of expertise in one area that you’re actively working on. And once you’ve truly mastered that area, picking the next area to develop expertise in.

This approach requires effective collaboration with others, since you will sometimes find yourself being blocked by domains you don’t have proficiency in. This is why we have other best practices around responding promptly and unblocking others. Collaboration among experts will lead to better outcomes than amateurs working alone. 

At a team level, bus-factor resilience is still essential. It is up to each manager to ensure that there are at least 2 designated experts for each component owned by the team.

Focus

Great work requires great focus. To foster better focus, we will be following these policies:

Meetings should be avoided where possible

Meetings attendance and participation are often used as proxies for engagement and capability, during performance evaluations. Resist this urge. It leads to people feeling pressured to show up to meetings, put in face-time, and “give their 2 cents” – all of which is a waste of time for the company. Don’t evaluate people on the basis of sounding smart in meetings

Before scheduling a meeting, first attempt to discuss the matter over slack, email, calling them or walking over to their desk, and having an informal conversation. Only schedule a meeting if all of the above fails.

Limit the number of participants in a meeting. Only invite key stakeholders who will be actively participating in most of the discussion. As a general guideline, the quality of a meeting is inversely proportional to the number of people at the meeting.

If you wish to solicit feedback from a wider audience, collect status updates, or keep everyone informed, use a different medium. Send an email, a slack announcement, write up a doc, or even record a video of the meeting and send it to as many people as you want. But don’t clutter their calendars with meetings where they aren’t key stakeholders. Social pressure dictates that if you mark a meeting as optional, engineers will attend anyway, even if it’s not a good use of their time.

People often use meetings to implicitly socialize and build team camaraderie. Lunches are a better way to do this. They are more social, more fun, and less disruptive to work. Anytime you eat lunch with someone you work with, bill it to the company. We encourage all teams to have a team-lunch at least once per week, where they can have a chat about how things are going, company/manager updates, and problems the team is running into. We also encourage everyone to vary up their “lunch buddies” so as to get to know everyone in their team.

Meetings should be clustered when needed

Always keep in mind maker-schedules vs manager-schedules. To the extent that a meeting is required, schedule it back-to-back with another meeting. Avoid spreading them out – no one will be able to focus meaningfully in small pockets of free time.

Avoid distractions

No one is expected to respond immediately to messages or emails. Even if it’s coming from their manager or director. To enable better focus and combat people’s tendencies to expect an immediate response, we encourage everyone to disable slack and email notifications – your manager certainly can’t blame you for following company guidelines.

Unblock others

Focusing and avoiding distractions is great, but so too is unblocking others. Particularly with our no-meetings and depth-before-breadth policies, it is doubly important that people respond to others promptly while working asynchronously.

People generally take a mini-break or context-switch every 1-2 hours. When this happens, check your email and slack. Respond to all questions, review all proposals, and unblock anyone who is currently waiting on you. Resume your own work only when you have responded to everyone who needs your input. Treat your colleagues’ time with just as much value as you would treat your own time.

In particular, avoid requesting or waiting for a group meeting, just to sign off on a proposal. As discussed above, our goal is to avoid meetings where possible. If you need further context, either start a slack channel or email thread. If that doesn’t work, call them, walk over to their desk, or meet 1:1 with the relevant person you’d like to talk to. Don’t postpone the decision for multiple days, just so everyone can sit in the same room at the same time.

If someone is sending you too many requests, tell them directly, or talk to your manager. If you’re receiving too many requests, talk to your manager to figure out the best way to rebalance your workload and requests. Don’t just keep people waiting. Unblocking others is the best way for the company as a whole to move more quickly and be more agile.

Feedback

Feedback is essential to helping people get recognition for their contributions, as well as identify their areas of improvement. It is also essential to the organization in promoting the right people, and stamping out antisocial behaviors.

Feedback works best when it is continuous, immediate, and paired with specific examples. To achieve this, each person will have a publicly shared feedback-form which people can fill out at any time, any number of times. Whenever you notice someone doing something well, or something that can be improved, take a second to fill out the form.

These forms are designed to be extremely concise, and it should only take 15 seconds to fill them out. Responses should be short and simple. For example, “Had to wait an entire day to get my code reviewed and unblocked.” Or “Reviewed my pull-request within an hour, with very useful suggestions.” We encourage everyone to provide at least one piece of feedback every day, including a balance of both compliments and suggestions for improvement.

The above form responses will be viewable only by the person’s manager, and others in their management chain. These responses should then be summarized and discussed during 1:1s, but anonymity should always be preserved.

Planning and Project Management

We are big believers in Agile:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

But we are not big believers in any specific agile implementation or ceremony. Scrum in particular will be avoided, because of the time-intensive “sprint planning” processes, and the arbitrary and error-prone time-boxing of tasks.

For the above reasons, we encourage using something more similar to Kanban. Ie:

• Keep an unprioritized backlog of tasks. Anyone can add tasks to this set
• Managers will use email/slack/offline conversations to place these unprioritized tasks into an ordered list of tasks to work on
  • Assign specific individuals to tasks if needed
  • Assign “complexity scores” to each task, if tracking velocity is an actionable metric for the team
• When someone is looking for a task to work on, pick a task closest to the top of the ordered list – one that they can work productively on or have been assigned to

For reasons discussed regarding meetings, Standups are better done via slack. As soon as they begin their workday, each person can post their previous-day-recap, plans-for-the-current-day, and problems/blockers. Have a dedicated channel for this purpose, which also serves as a documented summary of the work each person has been doing

Don’t feel compelled to adopt all the other bells-and-whistles of Kanban or any other sprint ceremony, unless you’re sure they are adding value to your team.

Focus on What Matters

Unlike other startups, we value work-life balance and do not expect grueling schedules that are commonplace elsewhere. At the same time, our goal is to raise the bar for engineering excellence, and build the world’s most fast-paced engineering team. To enable both of the above, we expect everyone to use their limited time at the office efficiently.

Do not waste your work-time on things that don’t have a clear positive impact on the company. For example:

• Attending meetings where you aren’t a key stakeholder
• Assigning action-items to others that are effort-intensive and only marginally useful
• Attending info-sessions that aren’t related to your day-to-day job
• Debating politics on internal mailing lists and slack groups
• Partying or extended socializing
• Personal hobbies and interests

The few exceptions to the above are lunches and after-work events. We highly encourage everyone to use their lunch hour to socialize, learn about Haskell, go for long walks, debate tabs versus spaces, and do anything else you feel like doing. You’re certainly also welcome to organize optional after-work events like happy hours, board game nights, and other social activities.

We encourage everyone to have a fulfilling life outside of work, where you can engage in any and all activities you’re interested in. And if you find yourself needing a break while at work, go ahead and take a break. Go for a walk, do some meditation, anything that helps you to recharge. But don’t waste your time and other people’s time on things that are mentally taxing and “feel like work” but aren’t actually delivering value to our customers.

Career Growth

Job Titles and Promotions

We do not believe in extrinsic and arbitrary markers of career growth, such as job titles, stack-ranked performance ratings, and the “promo process” used by most FANG companies. In particular, the promo process is exceedingly dangerous in:

1. Introducing unnecessary complexity, as a way of showing off technical ability
2. Instigating unnecessary bureaucracy, by people focusing on documenting their accomplishments as opposed to getting stuff done
3. Producing unnecessary product churn, by people wanting to demonstrate personal impact
4. Neglecting vital improvements that are individually small and not fancy enough to stand out in a promo packet

To quote the former lead of Google Sheets:

we had a lot of small bugs and usability issues, often in areas where we weren’t at parity with Excel.  Users wanted us to implement … pretty standard spreadsheet fare, and very reasonable requests. … However it was a constant struggle to prioritize these types of issues vs. “bigger impact” projects. Our engineers cared about the product and wanted to polish it. But they also wanted to be promoted. And so we would deprioritize product polish for projects that looked better to a promotion committee

Rather than the above extrinsic and bureaucratic promo process, we believe in organic career growth. Growth that gradually occurs via:

1. Growing your skills – both people skills, general engineering skills, and domain-specific skills
2. Growing your area of influence, as you gain the trust needed to lead projects of larger scope and greater importance
3. Growing your compensation, as a result of the value you provide to your team and the company

For legal reasons, we might offer you a specific job title based on your years of experience and compensation. But internally, this is something we do not pay any attention to. You might join the company as a recent college graduate, with limited experience and skills, working mostly on smaller individual projects. Ten years later, you might find yourself having accumulated a tremendous amount of skills, leading a team of people working on a vital company initiative, and earning three times as much as you previously did. This would all happen gradually and seamlessly, without having to go through any promotion process, or overnight changes.

Performance-Based Compensation

Ownership is one of our company’s core principles, and this will be reflected in our compensation plan. Each person will receive a base salary that will cover their life needs. Beyond this, we believe in performance based compensation. Specifically, we believe that everyone should be compensated according to:

1. The success of your immediate team. The more successful your team is, the more upside there will be for the entire team
2. The amount of value you provide to your immediate team. The success of your team determines the size of the pie – the amount of value you provide to your team, will determine how much of that pie will accrue to you

As a young startup, the above is something that naturally happens. If our startup succeeds, our equity will become tremendously valuable. And the more value you provide to the company, the larger equity grant you will receive.

As our company grows in size, the above relationship starts to break down. At most FANG companies, people’s compensation becomes very disconnected from the success of their team. And their compensation becomes highly tied to the success of a massive corporation that they have minimal impact on – or arbitrary stack-rankings within a team. This leads to highly dysfunctional outcomes. To prevent this, once our startup grows beyond a single engineering team, we will find new mechanisms to restore this alignment.

Retention

If you have any concerns with your project, job responsibilities, day-to-day work, or compensation, talk to us at any time – we welcome the conversation.

We understand that there are other companies that take punitive actions against employees who are considering leaving. That is most certainly not something we would do. If you inform us of another job offer that you are seriously considering, we will never hold it against you. We hope you will keep an open mind and talk to us first before accepting.