#teambuilding
7 posts

Your system is not a sports team

Don’t be obsessed with a system that you have built or worked on for many months/years. Don’t focus only on improving the system you are working on.
Read more

Your system is not a sports team

  • If you are aligned to a mission, rather than being aligned to a specific system, you will work better for the success of the company.
  • Don’t be obsessed with a system that you have built or worked on for many months/years.
  • Don’t focus only on improving the system you are working on. Look at the larger goal your company is working towards and find the best utilization of your time.
  • Get your team aligned on the problem at hand and not around the tools & technologies to use to solve the problems.
  • Empower all engineers to focus on the impact of their decisions on the overall company by avoiding silos.

Full post here, 4 mins read

SLOs are the API for your engineering team

SLOs help you invest in your team's ability better to meet the agreed-upon goals. SLOs ensure consistent & predictable delivery.
Read more

SLOs are the API for your engineering team

  • SLOs (service level objectives) help you invest in your team's ability better to meet the agreed-upon goals.
  • SLOs help you push back when demands exceed your capacity to deliver.
  • SLOs ensure consistent & predictable delivery.
  • SLOs enable better decisions based on real data without wasting time on debating.

Full post here, 9 mins read

What Google taught me about scaling engineering teams

Create reusable training material & use it to onboard new engineers. Agree on a set of standard coding conventions as early as possible.
Read more

What Google taught me about scaling engineering teams

  • Focus on building shared tools & abstractions across engineering teams. Dedicate people to it.
  • Create reusable training material & use it to onboard new engineers.
  • Agree on a set of standard coding conventions as early as possible.
  • Take code reviews seriously and use them to increase code quality.
  • Having lots of right data will solve many problems.
  • Automate testing to scale your code. Rigorously focus on tests during code reviews too.

Full post here, 5 mins read

Hyperproductive development

Stop using any words that suggest anything is simple or obvious in all team communication. Write tests so people afraid of unintentional breakages can freely experiment with their ideas & contribute to the system.
Read more

Hyperproductive development

”Complex systems are easier to build than to figure out after they’re working.” - Valentino Braitenberg
  • This Law of Downhill Invention, Uphill Analysis starts becoming visible as development teams and projects start scaling.
  • The person who creates the system knows the ins & outs of it. They start assuming & expecting same level of knowledge of the system from everyone on the team.
  • First thing to ensure productive development environment is to accept the overhead that comes with larger teams. It is a tradeoff for scale.
  • Stop using any words that suggest anything is simple or obvious in all team communication.
  • Write tests so people afraid of unintentional breakages can freely experiment with their ideas & contribute to the system.
  • Try pair programming. It is one of the best ways of knowledge transfer about systems.
  • Make an exhaustive README document for developers on the team. Start this on day 1 when you start building any system.

Full post here, 5 mins read

How should you structure your engineering team?

Answer: No one size fits all. Structure your team in accordance to what works best in your company's context. Here are 5 things to think about before and during the process of making changes to your engineering team structure: Know what you want to solve with the change - a
Read more

How should you structure your engineering team?

Answer: No one size fits all. Structure your team in accordance to what works best in your company's context.

Here are 5 things to think about before and during the process of making changes to your engineering team structure:

  • Know what you want to solve with the change - a collaboration, communication, clarity or direction problem
  • Consider the impact of the change on other teams & the organization
  • Don’t make change a big deal
  • Decide who decides on what
  • Over-communicate all aspects & consequences of change

Full post here, 8 mins read