Engineering behaviours

• Engineering behaviours
  • Introduction
  • Have a co-owner mentality
    • We operate what we build
    • Your ownership ends where Cabify ends
    • Keep the common space clean
    • Protect the engineering
    • Shit is not anyone else problem
  • Trust, communicate and develop
    • We make things for humans
    • Explore the world
    • Stupid questions don’t exist
    • Help others to grow
    • Discuss with data and evidences
    • We succeed and we fail together
    • Communicate as good neighbours
  • Embrace & Drive Change
    • Challenge the status quo
  • Analyze, Innovate & Simplify
    • Detect the threats
    • Take the control
    • Keep it simple
  • Contribute and commit
    • Do not expect to happen
  • Make an impact
    • We listen before solving
    • Not everything is a nail
    • Care the costs
    • Tackle the root cause
  • Have a Positive & Humble attitude
    • Save time for others
    • We are not our code
    • My way is not the only good way

Introduction

Here at Cabify, we have a set of Principles 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.

Have a co-owner mentality

We operate what we build

• We should expect our engineers to take care of their code beyond the MR is merged, 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.

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 to 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 to actually be a mess.

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.

Shit is not anyone else 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 the job.

Trust, communicate and develop

We make things for humans

• We should expect our engineers to consider the human factors of engineering, assuming things they make have to be used by humans with a variadic range of needs, skills and limitations.
• We should not expect our engineers to behave as they are alone in this world, making things and taking decisions considering only their own needs, skills and limitations.

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.

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.

Help others to grow

• We should expect our engineers to teach to others, sharing their knowledge and mentoring other peers.
• We should not expect our engineers to keep their knowledge for themselves, ignoring the needs of other peers to grow.

Discuss with data and evidences

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

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 big 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 cause a negative impact just because they are not the owners, or they might be blamed for causing it, or they might reveal their weaknesses by making it public.

Embrace & Drive Change

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 we always did.
• 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.

Analyze, Innovate & Simplify

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.

Take the 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.

Keep it simple

• We should expect our engineers to make things simple, escaping from unnecessary complexity and removing any moving parts that do not have a positive net value.
• We should not expect our engineers to abuse from overengineering, waste their time and resources in solutions that bring small value to the business and have a negative net profit.

Contribute and commit

Do not expect to 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 waiting for the events to happen, to receive instructions before every single move.

Make an impact

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.

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.

Care 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.

Tackle the root cause

• We should expect our engineers to pull the thread, looking for addressing 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.

Have a Positive & Humble attitude

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.

We are not our code

• We should expect our engineers to accept their code can be criticized, accepting 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 despite they are made in a different way than we use to do it.
• We should not expect our engineers to dilate on or block a conversation just because the solution chosen is not their own.