Engineering culture for an Internet company

Thu, Dec 11, 2014

Hope you will bear with me improvising the definition of engineering culture as the ideas, attitudes, organization and behavior of the members of an engineering-driven company.

Each one of the Internet companies we work in have an engineering culture, regardless of the awareness of their members (and managers). That's because a company is an ecosystem that operates under a series of individually-disconnected and collectively-connected principles that when placed together over time they become ideas, attitudes and behaviors conforming an Engineering culture: the reality on which the company operates and organizes itself.

The Engineering culture might contain either organizational stuff or technical choices. Some companies disclose these operational habits and culture and publicly share in awesome presentations their stories of success (and failure). These companies will try to hire only people that fits well in this strategy. Others simply aren't very aware of what is their underlying culture, but at the end of the day all companies have an engineering culture, a mix of what "the company" wants and the individual beliefs.

The following lines describe an abstract engineering culture I believe in, the one that fits better with my style.

It is very difficult (and would be very long) to write a recipe in detail but see this article more as a notepad with ideas than a detailed recipe. You cannot cook only by reading this.

Also understand that this is not the definition of the engineering culture I currently work in or had, but my point of view.

By sharing this I hope you give a thought about your own engineering culture and of course to see you contribute back with comments, opinions and any disagreements (so I can keep improving!)

This document can evolve and transform over time, as we all do in our career. What today is very clear tomorrow can be object of discussion and even considered a bad practice, as it happens with refactoring.

Let's go!

Reliable co-workers

And by reliable I don't mean the quality of the work they produce in the first place, but their personality: Self-responsibility, honesty, fairness, accountability as main drivers.

You know you are in a reliable team when:

• Autonomy, transparency, and trust in others are strongly rooted. Word is kept.
• Failure is used to learn, and blameless postmortems are a good way to improve.

• There is no finger pointing between members

• No politics are used, no fear.

• Wins and loses are always as a team

• Every one is individually responsible for creating as much value as possible.

• Good judgment is applied instead of being lead by imposed rules.

• Do it! is the slogan, no bullshit, no excuses.

Beautiful teams

• Teams don't go bigger than 8 people (Many theories related with team size exist, and also for social interaction as the 150 Dunbar Number)

• Do the meetings only with a few, share results in a document. Not everyone needs to attend a meeting when conclusions are shared clearly later.

• Autonomous multidisciplinary team. Should be able to resolve anything related with the product.

• Don't split one product between different teams, but split it by usage/consumption of it). Less coordination is required.

Every family needs safety

"Look ma', no hands!", is a bad pattern. No one should cross-fingers during the product iterations, you need predictability. Do not endanger your business and let things to their fate. There are several things you can do to minimize the number of things going wrong, some examples are:

• Invest on automated testing. Proper testing assures no harm will be made to the products in the next release and helps engineers to play safe and with certain guarantees.

• Foster constructive code reviews between colleagues. Not only many bugs will arise but junior members will learn a lot by reviewing seniors code, and of course they will make incredible contributions too.

• Live monitoring on the production site, not only systems and services but also metrics on key business indicators. Have user sign-ins decreased? Is advertising showing properly? Are there any deviations in the incoming cash?.... The engineers need to now nothing has been broken after their code is deployed, an dit has to be real time.

• Whatever is in the master branch (or the approach you use) has to be safe to be published, anytime. In case your workflow requires someone "pushing the button" to deploy then anyone should be able to.

• If your product is critical you might want a pre-production/integration/staging environment to take a moment of safety before going live, although IMHO it is always better to have continuous deployment and put small pieces in production without stopping and accumulating changes in these environments.

• Never, ever have code generation on-the-fly on deployment time. Do not put anything in production that can't be tested in an earlier scenario.

Incremental development

Grouping tons of features and releasing all of them at once is a bad idea. Anything can go wild and then you need to run like a headless chicken (that's a literal translation of a set phrase in spanish, but very graphical). You'll never know what piece of all the code you put online altered the metrics and fixing anything can be hard. Instead of releasing functionalities:

• Publishing small pieces of code, constantly and frequently will help you detect failure faster.
• If these pieces are part of a greater thing that cannot be seen by the end user yet, hide it. Use configuration flags or use inaccessible pages to toggle features. Even the code is not "seen" this might help you find out system instabilities and detect problems prematurely. Reverting is very easy when you have toggling flags.

• Use a continuous integration infrastructure

• The development to production cycle has to take only a few minutes. When the developer has finished a working piece of code should be eligible for going live in few minutes.

• Use continuous deployment whenever is possible

• Reverting code can be done moving formward instead of backwards. Just commit the reverted changes, this is something natural in any DVCS.

Open source mindset

Even if you don't want to share any of your code with the world, the open source community has very good habits you might adopt.

• Everyone is free to contribute in any piece of code and all the code is opened to invite anyone to participate.

• If someone wants to change code a pull request to the owner is made, just like in any open source project. Note that you need an owner (person or team) of everything you produce.

• Whatever you touch, you leave it better than it was.

• Anything not related with the core business should be eligible for going open source, for real.

• Inside the company you don't change "others" code. It's yours. Any piece of code in the company is YOUR code.

• So say "NO" if it will harm the code

• Don't write crappy code

• But at the same time balance technology with product delivery.

• Have a culture of one team

Managers are not above engineers

Becoming a manager is not a step up in your career but a change in the orientation of your work. Managers facilitate process and help people, engineers solve technical problems. Apply for management if you are more motivated towards helping people. Related to that:

• Pay scales between managers and engineers should be equal.

• Managers of engineers must have been engineers at some point to better understand the problems.

• Managers measure team happiness, just as another metric.

• A manager explains the problem, the teams will think on solutions. As a manager, do not tell the team what and how to do it, give your opinion for sure but don't lead the solution.

• Managers are to remind the mission and explain and define the strategy.

• Flexibility is important and engineers will help make the strategy better.
• Default the company to information sharing. Everything should be shared unless there's a strong reason not to.
• Implement team chat rooms, bots and integration

Grow and help others

Being focused on the day to day and the products won't make you grow and won't cultivate you without an addition.

• Foster the innovation. Make a hackathon every quarter, lasting 24h.

• Most people will welcome a family & friends day once in a while.

• Celebrate culture rockstars. People who fits in the engineering culture has to be recognized.

• Celebrate wins. You don't need to make a party, celebration comes in many forms including a simple High five!. Praise people.

• Internal training is very important. All members should give speeches and workshops so everyone learns something new. Exchange knowledge between different teams.

• Helping others is your first responsibility. Do not leave colleagues in the cold. When you are in trouble ask for help responsibly.

• Switch team members between teams if they are more interested and will bring more value.

• Help people in other teams that are interested in other areas of specialization and can contribute in the same are you are a specialist.

Afterwords

I tried to cover some topics relevant in the operation of an organization, but of course there are many things I didn't write and left out the document. I will be very happy to hear your thoughts.