Imagine an engineering team that, although it keeps getting time and “space” to build proper solutions and ensuring good engineering practices they keep providing negative feedback on how things are built, with lots of problems on how the team should invest on full re-implementation of “the service” instead of just assuming that’s just ownership of the team and that they need to deal with it as a natural consequence of having “different people working on the same code base”!?
Sounds familiar? And what about a super important initiative that you have on your team’s roadmap!? Something very important to the company’s strategy and, although you’ve tried hard to motivate your team and gave enough reasons (and conditions) to keep them focused on the delivery and be successful, you keep seeing a recurrent negative attitude towards every impediment, even for the smaller ones, decreasing motivation within the team.
These may be some specific examples of behaviours, but these behaviours are definitely influenced by the company’s culture. That’s why Culture is a key topic when talking about companies and engineering teams, and their ability to succeed. Some say Culture is a retroactive narrative of successful companies, others would say that culture is the single most important characteristic of a successful company:
“Culture eats strategy for breakfast”, a phrase originated by Peter Drucker and made famous by Mark Fields, President at Ford
I say it’s the thing that most influences behaviours and behaviours define your team’s ability to succeed. You can have a great company culture and still not being successful, but I assure you that with a inadequate company culture you won’t succeed (in the long term).
So, although we might agree on it’s importance, being able to define it and apply it through all your teams is not that easy. First because culture is something that you live, not just something you right on paper and second because, like your company, it’s continuously evolving, specially with growing companies.
If we take a look into same known examples, we’ll find at least two very popular among tech companies, like:
- The famous Netflix Culture slideshare with over 17M views (new version here);
- And Spotify’s Engineering Culture (Part I and II).
And despite representing different cultures (and different approaches), both are recognised as successful with a very clear and rooted culture – that’s a result of their employee’s behaviours and their option to build and contribute to a strong culture. That’s why I believe that culture, being hard to define on paper is, at least, a must-have exercise for every team / company. Ultimately culture is a set of behaviours and skills valued by everyone in the company and promoted by its leadership.
So, how can I influence my engineering team’s culture?
A good way to influence a specific culture in your engineering teams is by promoting certain behaviours and skills, like using a Cultural Manifesto or a set of Engineering Principles, that you should value and promote in your team interactions. Here’s some examples that I’ve chosen:
- Mastery & Crafstmanship
- Code Reviews
- Ensuring standards / guidelines and the implementation follows the agreed solution
- Scaling Patterns
- Branching / Code Repos Best Practices
- API Design Principles
- Defensive Programming
- Frameworks / API re-usability
- Promote use of existing Frameworks
- Automated Testing
- Continuous Delivery
- Seek alternate perspectives
- Product and Tech perspectives
- Favor simple solutions over over-complex ones – avoid over-engineering!
- Build vs “Buy”
- Always promote an analysis and choose wisely before committing to do something from scratch
- Internal open-source
- Mindset to contribute to any code repo, ensuring proper coding review/analysis is done by the owners
- Refactor vs ReBuilding
- Clearly identify when we should just refactor a piece of our software or go through the path of rebuilding it, taking into consideration all aspects including business aspects
- Monitoring & Alerting
- Be pro-active, not reactive!
- Fault Tolerance
- Ensure our services and tools support fault tolerance
- Adding Capacity vs Optimizing for efficiency
- Own our Pipelines and Processes
- Identify root causes, and get beyond treating symptoms
- Maintain Healthy Code Bases (continuous work, not just some single shot tech debt project)
- Transparency (share information openly and proactively)
- Highly Aligned, Loosely Coupled
- Align with the Business priorities and Company’s vision, loosely coupled to give our contribution independently of other teams
- Conflict Resolution (listen well and seek to understand before reacting)
- Inspire team with your thirst for excellence
- Seek what is best for Farfetch, rather than what is best for yourself or your group
- Make your colleagues better (make time to help colleagues)
- Focus on results over process
- Ensure the process is a way to get results and that processes are changeable – continuous improvement
- Context not Control
- Push for decisions within the team, ensuring that they have all necessary context
- Data-driven decisions
- Support decisions with data – for example, retrospective actions based on data
Can you imagine the kind of culture you’ll have in your engineering teams if you applied these principles?
The hardest part is always ensuring those principals and behaviours keep being valued and promoted while your teams keep growing and that’s something that should definitely be part of your review/career development process.
This post represents my own opinion based on my experiences in several companies and does not relate in any way to my current employer.