• Lead Time : Length of time between when the code is committed and when it is deployed to production. Smaller is better.
• Mean Time to Recover : Length of time from incident start to incident end. Smaller is better.
• Change Failure Rate : Number of deployments to production that need hotfixes. Smaller is better.
• Deployment Frequency : Number of times new code (not hotfixes) is deployed to production. Larger is better.

Improving these metrics directly results in huge performance boosts for developer productivity.

• Business Projects : "Feature Work". This is the most visible type of work.
• Internal IT Projects : Release Automation, QA Automation, Developer Tooling and other internal enablers. Mostly un-tracked and invisible, but crucial to long-term success.
• Updates and Changes : Generally generated from above two categories of work. Introduces delay as breadth of existing surface area increases.
• Unplanned Work : Fire-fighting at all levels of the company. Ruins planned work, so root causes need to be aggressively remediated.

• Flow : Maximizing the rate of flow of work is the key to success. Limiting the work in progress is the fastest way to achieve Flow.
• Fast Feedback : Setup systems to get fast feedback at every stage of work, from concept through shipping to maintaining in production.
• Experimentation and Learning : Keep dedicated time for experiments, at every level of the company. A culture of innovation is necessary for achieving and maintaining Flow and Feedback.

We share written status updates within the team on a weekly basis (every Monday). I wrote this article to explain what these status updates should look like, and I think it's useful enough to publish publicly. Here goes:

What is the purpose of status updates?

• Let your manager know what you have achieved last week.
• Let your co-workers know what you have achieved this week.
• Reflect on your progress and pace yourself.

Properties of good status updates

• Short and meaningful. (5 min reading time)
• Communicate work in the previous week, highlight progress.
• Communicate plan for the next week, help make yourself efficient.
• Communicate open questions and blockers, highlight areas where we need to help you.

Writing the status update

Write the status update either as the last thing on Friday or as the first thing on Monday. Remember to review the status you had posted previously, so that you don't miss out on any updates. If you choose to write on Friday end-of-day, this can also be a great wind-down / logging-off ritual to wrap up the week and give yourself a sense of accomplishment.

Create sections for your updates

• Use the following sections:
  • What I accomplished this last week
  • What didn't go according to plan
  • What I plan to do next week
  • Questions / Blockers / Action Items
• This makes it easy to parse your update.

Name the project you are currently working on

• Yes, your manager is supposed to know what you are working on. But you often do unplanned, extra tasks too. You help on other projects, handle production issues, discover interesting tidbits, get insights from analyzing logs. Highlight all of these activities!.
• Help your manager by making it easy for them to compile project reports.
• This makes your update very readable.

Name the milestone of the project you are currently working on.

• Helps when the team needs to take a call about cutting or increasing scope on a project.
• Highlights and reinforces upcoming co-ordination points.

Your status update should definitively answer the following questions:

• What are you working on?
• For each project that you are working on, where are you? What is the next date that you are committing to?
• Are you on track for the current phase of the project or not? If not, what is the impact on the overall project?

Example status update

What I accomplished this last week:

• Completed final PRD review for Project X, no open questions at this point! :yay:. Project is on track!
• Pushed a fix to ABC Service to production and closed Jira Ticket Z. Graphs show amazing reduction in network bandwidth! :epicwin: link to graph or screenshot.
• Conducted the Enterprise initiative meeting, meeting notes are here: link to meeting notes.

What didn't go according to plan:

• Working on dev of Project Y. Project is not on track :sad_face:. We had communicated that dev will be complete by <2019-08-02 Fri> but I will need 3 more days. This pushes the new date to <2019-08-07 Wed> EOD.

What I plan to do next week:

• I will have the initial estimates for Project X by EOD <2019-08-08 Thu>.
• I will complete the Dev work on Project Y as mentioned above. <2019-08-07 Wed> EOD
• I will create a document about DEF Topic as we had discussed by EOD <2019-08-09 Fri>.

Questions / Blockers / Action Items:

• We need to sync up about ideas for implementing Project X before tomorrow EOD, but you don't have an empty meeting slot until day-after. What should we do?
• I will inform Frontend team-member that Project Y integration testing cannot start tomorrow, instead it will start on <2019-08-08 Thu>.

What do you get from writing a good update?

• A record of work for yourself. This is invaluable come performance review time. You only have to read through 26 updates and you have a thorough summary.
• Help your manager advocate for you during appraisals. You should care about your career more than anyone else.
• Help yourself. Writing the update should give you a clear idea of your own progress and what you need to work on.

Executive Summary

• Engineering quality is paramount. Focus on clean and clear code. Code is the primary medium of communication for any engineer. Write beautiful code and hold people to high standards.
• Adding head count has vast hidden costs and often brings down output. The reason for this is the exponential increase in communication required to align everyone to common goals.
• Similarly, pods cannot scale unless they can own small, independent components.
• Monoliths are normal and good when the company is small. Refactoring the monolithic model into different components allows us to scale pods and org.
• Carve monoliths only when it hits critical mass. Then, identify the pain and pull it out into it's own pod.
• "Relationship as a service" or "Please get this done for me over and above other stuff on your plate"
  • "Traffic congestion" (A team which is too busy) and structural failure can lead to the impression that the system is bureaucratic and political.
• Criteria when hiring Engineers
  • Computer science (Can computers understand your code?)
    • Ability to grasp large complex systems
    • Understanding of implications of design choices on that system.
  • Software Engineering (Can humans understand your code?)
    • How well do you communicate through your code? This is the metric that enables building good systems.
    • The hygiene you show in code is the hygiene you will enforce on others.
  • Good behavioral traits (Can you grow?)
    • Curious
    • Wants to learn
    • Can accept feedback
    • "Strong opinions, Weakly held."
    • "Pride without attachment."
• Find the full video here!
• The rest of this post is detailed notes on the video

The video

Introductions

• CEO: Nadiem Makarim
• CTO: Niranjan Paranjape
• Tech Recruitment Head: Sidu Ponnappa
• C42 Engineering: Sequoia SWAT Team for solving tech problems
  • They were the rare "other Clojure shop" in India in 2010.
• Common consulting milestone for them was "the Client just tried to poach me". When Gojek tried this with Niranjan, they sold the entire company to Gojek.
• Today, Gojek does $9 BILLION in transactions with 300 engineers.

How do you get so much done with so few engineers

• Adding headcount does not increase output.
• With every engineer you add, you actually slow down work (exponentially)
• A good finance person will challenge you on every item of spend because they understand that that's how they lose money.
• Similarly, a good engineering leader will challenge you on every addition of headcount. The hidden cost is enormous and impacts ability to deliver quickly and at quality.

Collaboration, Communication and Team Size

• Every person you add exponentially increases the combinatorics of communication you need in order to agree on what exactly it is that you are building.
• Code is communication between humans. Keep it clean and simple.
• Upto 4 people, productivity grows linearly with addition of people. Beyond that it starts plateauing and dipping.
  • The person who observed this started slicing and dicing teams so that at any point in time a subsystem was being worked on by no more than 4 people.
  • By Conway's Law, he was forcing system architecture to be set up in a certain way.
• We chose to map out our systems based on what a 5 person team could do.

What about "number of pods"? Will infinite teams of 5 scale infinitely?

• As an organization, we find similar diminishing returns with growing the number of pods.
• The company's ability to add pods is also limited by ability of the pods to understand the underlying system.
• If your pods are independent (have to collaborate only once in 2 to 4 weeks), then you are in a manageable situation.
• Multiple pods working on the same problem leads to pushing for local goals (evolving the system to maximize your objectives based on limited understanding)

Complexity of organisations

• "Don't slow me down" from CEO to engineering
  • Philosopher poet engineers
  • Engineering had to educate the CEO on the bad effects of not on-boarding new comers fast enough
• Adding Kafka to our stack allowed us to scale
  • Helped us decouple communication
  • Tap into our data, you don't need to ask me anymore.
• Refactoring the monolithic model into different components allowed us to put more people on the independent teams.

Monolith to SOA

• We first pulled out the allocation system
  • matching driver to customer
• Next we pulled out Go Pay
  • This allowed us to staff the team of Go Pay without them having to understand the entire monolith.
• Identify a problem, pull it out, establish a pod around it.
• CTO was pushing CEO:
  • Before we move into this new thing, we need to get rid of the monolith first.
  • The choice they made was never stall growth. This meant hanging on to the monolith for longer than they would have liked, and refactoring it in bits and pieces rather than in one single effort.
• When starting out, it makes complete sense to have a monolith.
• When you carve a system out of a monolith, eventually that will become a monolith.
  • Now you need to split it again.
  • Identify when the monolith reaches critical mass, and then refactor your team and code-base in lockstep.

Relationship as a service AKA How politics enters your system

• I need something from your system, so I'm going to lean on our relationship to unblock me and ignore your own priorities.
• "Hey I really need this done fast, because X".
• This will grow until you are completely busy trying to unblock other people and are unable to focus on any of your own priorities.
• Now you have a bureaucracy. The person with the back-channel to the blocked system gets to jump the queue. This inherently does not scale because people without the relationship back-channel get more and more frustrated.
• "Our organization is political." I don't have privileged access, therefore that other guy must be master politician.
• The actual underlying problem is traffic congestion.
  • If you are trying to do your best, you are going to use every resource at your disposal, including your relationships, to get work done
• Even in the most well-intentioned and non-egotistical organizations, structural failure leads to the perception of favouritism

Is there such a thing as a 10x engineer?

• As system complexity grows, for you to meaningfully contribute, you need to know the system!
• Criteria to select engineers
  • Computer science (can computers understand your code?)
    • Ability to grasp large complex systems
    • Understanding of implications of design choices on that system.
  • Software Engineering (can humans understand your code?)
    • How well do you communicate through your code?
    • Communication problems are the hard blockers on building good systems.
    • Well written code provides contextual logic and clarity.
  • Good behavioral traits:
    • curious
    • wants to learn
    • reads books
    • can accept feedback
    • ^ This is the kind of person who can grow.

Good practices in coding

• Every code-base comes with a glossary
• Terms have specific meaning, and naming is critical in the dividends it pays off in the future.
• Every engineer at every level has to take a written test
• We are not looking at whether you can solve the complex problem. We are judging how you express yourself. You are a programmer, and your code should speak well for you.
• Hygiene becomes more and more important as a programmer becomes more and more senior.
  • The hygiene you show in code is the hygiene you will enforce on others.
• High standards are important.

Differences between good engineers and 10x engineers

• 10x outcome (not output)
• As you grow your organization, individual outcome is less important. Team outcome is what you need to measure.
• Engineering is completely a team sport.
• You can have deeply capable and extremely competent individual contributors who like to work alone. As long as their code fits beautifully with other systems, they are multiplying everyone's capacity.

How do you spot red flags in a new hire?

• Every good engineer is highly opinionated. A good engineer has strong opinions weakly held.
  • You should be able to change your opinion on being presented facts.
• If you are unable to deal with criticism of your code, that's a smell.
  • We ask junior people to interview senior engineers. This shows the grace they have when dealing with others.
• We routinely wind up in situations where you have young people owning complex systems. Senior engineers need to be hired to now deal with these systems, and they will be on-boarded by juniors. They should be able to deal with this fact.
• CTO: "When I lay out a design, I expect people to give me rational criticism so that I can learn from them."
• If you had to hire someone with deep experience vs great behavioral foundations, what would you choose?
  • It Depends!
  • Sometimes, you need to bring deep experience to the table to build something out and learn from the guru.
  • Behavioral traits means that someone is teachable. Outside the Valley, this is extremely important because of the lack of access to experienced engineering.

Onboarding / Engineering bootcamp

• Structured decision making
• Basic coding hygiene
• Collaboration
  • How do you engage with someone else to meaningfully decide reasonably quickly what something in code should be.
• Heavy focus on coding during the bootcamp.
• We bring in coaches from every team and teach. (regardless of hire). This helps us build empathy, which is critical for future collaboration.
• Pride without attachment.
  • Pride allows you to focus on creating beautiful code.
  • Attachment means you will stand in the way of the evolution of your beautiful baby. You need to let it go and let others change it.
  • If you look back at code you wrote 6 months back and don't notice how bad you were, you aren't growing.
• Repeat the same problem every Monday throughout the whole bootcamp. Ask them to review every week and see if they find that feeling of progress.

Gojek culture

• Even the most high-performing team has to deal with intense time pressure.
• What makes or breaks teams under pressure?
  • Show them the impact that they are making.
  • You don't need to push engineers, you need to give them the rush! External force will not drive the maker as much as the impact of work will.
  • The value you create is not proportional to the time you put in, it's proportional to the state of your mind in that time you put in.
    • If you are burned out, or your team mate is burned out then there is going to be a huge negative spiral.
  • To harness creativity, you need balance and psychological safety. The hours that you put in, you need to be in a state of flow. This requires you to take short breaks after days of intense activity.
• You can have a 10x engineer amidst you, but you may never know it because you did not give them sufficient leeway to unleash their art.