Engineering behaviours

UNDER REVIEW - Aligning engineering behaviors with new principles is in progress

• Engineering behaviours
  • Introduction
  • Humble
    • We make things for humans
    • Help others grow
    • We succeed and we fail together
    • Communicate as good neighbours
    • We listen before solving
    • We are not our code
    • My way is not the only good way
    • Shit is not someone else’s problem
  • Unstoppable
    • Stupid questions don’t exist
    • Tackle the root cause
    • Your ownership ends where Cabify ends
    • Keep the common space clean
  • Coherent
    • Discuss with data and evidence
  • Brave
    • Challenge the status quo
    • Detect the threats
    • Save time for others
    • Protect the engineering
  • Accountability
    • Take control
    • We operate what we build
    • Mind the costs
  • Focus
    • Keep it simple
  • Impact
    • Make it happen
  • Curiosity
    • Explore the world
    • Not everything is a nail

Introduction

Here at Cabify, we have a set of Principles and Competences that conform actionable guidelines for the type of behaviour we strive for ourselves and look for in our colleagues. However, sometimes it is difficult to associate each principle with specific behaviors in the engineering world we use to find at the end of the day.

This document is aimed to be an instrument to identify the behaviours we should, and should not, see in a Cabify engineer. This is useful to drive our role as reviewers of code challenges and interviewers in hiring processes, but also to know what the company expects from us and what we should expect from others.

The behaviours are classified by the principle they belong to. Each one must be described by a short title to make it easy to reference as we do with our Principles. Then the behavior must be expressed with two sentences, describing what we should expect and what we should not expect, respectively.

Everyone is invited to extend this set of engineering behaviours by making a Merge Request to this document. If you want to make a contribution, please consider the following tips:

• Don’t be too generic. We are describing behaviours, not principles. E.g., “be transparent” is too broad, “say what you think” is fine.
• Don’t be too specific. We are describing behaviours, not specific situations. E.g., “say what you think” is fine, “tell the truth in the standup meetings” is too narrow.
• Use a short but self-descriptive title.
• Describe the behavior with a dual statement: one for the actions we expect to see, one for the actions we expect not to see.
• Avoid having a should not expect statement that is a logic negation of the should expect one. E.g., for “(should expect you to) say what you think” use “(should not expect you to) keep your thoughts for yourself” rather than “(should not expect you to) not say what you think”.
• Read the rest of behaviors, get inspiration, learn and follow the same spirit.

Humble

We make things for humans

• We should expect our engineers to consider the human factor of engineering, assuming things they create to be used by humans with a wide range of needs, skills and limitations.
• We should not expect our engineers to behave as if they are alone in the world, taking decisions and building things considering only their own needs, skills and limitations.

Help others grow

• We should expect our engineers to teach others, share their knowledge and mentor their peers.
• We should not expect our engineers to keep their knowledge for themselves, ignoring the growth needs of their peers.

We succeed and we fail together

• We should expect our engineers to recognize the contributions of others when we succeed, no matter how small they are.
• We should not expect our engineers to blame others when we fail, no matter how much it is their fault.

Communicate as good neighbours

• We should expect our engineers to be good team neighbours and communicate to other teams anything that can cause a negative impact, regardless of who caused it and who is the owner of the failing things.
• We should not expect our engineers to ignore things that have negative impact just because they are not the owners, or they want to avoid blame or revealing their weaknesses if made public.

We listen before solving

• We should expect our engineers to listen to the problems and needs of the users before proposing a solution.
• We should not expect our engineers to design a solution first and then make the problems fit into it.

We are not our code

• We should expect our engineers to accept their code can be criticized, and accept reviews and feedback from their peers gratefully.
• We should not expect our engineers to build up an identity relation with their code, assuming that it is part of themselves and nobody can mess with it.

My way is not the only good way

• We should expect our engineers to evaluate each other’s solutions even when they are made in a different way.
• We should not expect our engineers to dilate on or block a conversation just because the solution chosen is not their own.

Shit is not someone else’s problem

• We should expect our engineers to tackle both unpleasant and exciting tasks equally.
• We should not expect our engineers to ignore those tasks that are boring and tedious, expecting others to do them.

Unstoppable

Stupid questions don’t exist

• We should expect our engineers to make as many questions as needed, no matter how stupid or trivial they sound.
• We should not expect our engineers to stay with the doubt just because they didn’t dare to ask or they didn’t want to reveal their weaknesses.

Tackle the root cause

• We should expect our engineers to pull the thread, looking to address the global root reasons that are potentially impacting the whole organization.
• We should not expect our engineers to address the local symptoms of the problem ignoring the global root causes that are impacting the whole organization.

Your ownership ends where Cabify ends

• We should expect our engineers to be inclined to contribute with solutions to someone else’s problem in the form of patches, fixes, issues, suggestions, or any other kind of help.
• We should not expect our engineers to refuse to address something that gets into their hands just because it is owned by another team.

Keep the common space clean

• We should expect our engineers to follow the boy scout rule, leaving the code better than they found it and documenting to facilitate the job of the people that will come after.
• We should not expect our engineers to be induced by the Broken Windows Theory, not only leaving the rubbish as it is but also generating more with the excuse of the codebase being a mess.

Coherent

Discuss with data and evidence

• We should expect our engineers to disagree by reasoning and refuting through data and evidence.
• We should not expect our engineers to disagree by opinionating and not refuting, ignoring others’ data and evidence.

Brave

Challenge the status quo

• We should expect our engineers to propose innovative and disruptive ideas, having critical thinking and challenging the notion that things have to be done as they always have.
• We should not expect our engineers to assume we are doing it right, using the right tools and following the right approach on every aspect of our engineering process.

Detect the threats

• We should expect our engineers to realize when they are bitten, detecting the problems, the risks and the inefficiencies that can cause a negative impact to our products, our operations and our processes.
• We should not expect our engineers to assume and embrace problems, risks and inefficiencies as something inherent to the engineering process so they get used to living with it.

Save time for others

• We should expect our engineers to write clean code, clean documentation, clean Git history, clean issues, etc, under the certainty that others will have to pass over there and you will save their time.
• We should not expect our engineers to ignore the time that others will have to waste to understand their code, their documentation, their Git history, their issues, etc.

Protect the engineering

• We should expect our engineers to keep the machine lubricated, ensuring it works in a reliable way and we can serve the business in a timely manner.
• We should not expect our engineers to succumb to external pressures that can put the reliability and the development speed at risk.

Accountability

Take control

• We should expect our engineers to understand how things work, turning black boxes into white boxes when needed and having the situation under their full control.
• We should not expect our engineers to use magical thinking, making uninformed assumptions, reaching hurried conclusions and resigning to extend their understanding of the problem or the solutions.

We operate what we build

• We should expect our engineers to take care of their code beyond merging a MR, operating their own code in the runtime environments we have.
• We should not expect our engineers to be only focused on coding tasks, disregarding the operational tasks and the negative impact they might cause to others.

Mind the costs

• We should expect our engineers to account for the cost of their actions and decisions, assuming that every line of source code, every service, every repository, every rule, every moving piece has a maintenance and operational cost for the company.
• We should not expect our engineers to add new code, new services, new repositories, new rules, new moving pieces blindly, ignoring that they will have to be maintained and operated demanding time and resources.

Focus

Keep it simple

• We should expect our engineers to concentrate on making things simple, escaping from unnecessary complexity, and removing any moving parts that do not have a positive net value or are aligned with our goals.
• We should not expect our engineers to abuse from overengineering, or waste their time and resources on solutions that bring little value to the business and have a negative net profit.

Impact

Make it happen

• We should expect our engineers to go for it, actively seeking for things to be done and pushing forward.
• We should not expect our engineers to stand around waiting for events to happen, or to receive instructions before every single move.

Curiosity

Explore the world

• We should expect our engineers to learn new things, extending their knowledge to new and potentially different forms of doing things in a better way.
• We should not expect our engineers to assume they already know all they need to perform at their best.

Not everything is a nail

• We should expect our engineers to choose the right tool for the right job, considering the strengths, weaknesses, opportunities and threats of available solutions and choosing wisely.
• We should not expect our engineers to be dogmatic and opinionated about technologies and tools, putting their personal preferences and tastes first and assuming that everything is a nail as they have a hammer in their hands.