What are engineering principles
Collaboration is a key element in any organization. Collaboration allows the different parts to accelerate each other, and it makes for a better outcome in the end. Software engineerings spend a lot of their time collaborating within their teams, but how do we ensure the collaboration is smooth, the objectives the same, and the standard aligned with each other?
There might be multiple ways of doing this, but one I’ve found works well is with team engineering principles.
First, let me explain engineering principles and then get into the team-specific parts.
Engineering principles are a way to align an engineering department by setting some common values and guiding lights for engineers to follow when making decisions. Examples of engineering principles from some big cooperations can be found here:
These are good to do on a company level, and one important thing is to formulate the principles in such a way that:
- They don’t communicate a rule (You must you X-technology vs. Aim for low coupled architecture)
- They strive for excellence (Quality comes first)
- They are easy to remember(e.g. YAGNI - you ain’t gonna need it)
It’s hard to write great principles, so it may need to go through a couple of iterations, remember to make it an ongoing process.
If done right, engineering principles can help your engineering organization move in the same direction and increase co-operability between teams.
The company-wide engineering principles often sets the high-level direction. It works well for aligning teams with each other, but it’s equally important to align teams internally. This is where team engineering principles find their value.
Team engineering principles
Team engineering principles should always respect the company-wide principles, but can expand on them or make them more concrete towards the specific team. It allows the team to set the bar higher than the company-wide principles, or re-phrase it into a context that makes sense for the team.
Team engineering priciples can also help the team understand communication patterns between different team functions (Dev, UX, QE) or how workflows should be within the context of the specific team.
Some examples of team engineering principles could be:
- We share successes and mistakes as a team.
- We make decisions together, but trust individuals.
- Automate processes.
- Document decisions.
Again the same rules for creating great principles apply, and they will have to be re-evaluated whenever the team changes (a person joins, or a person leaves), and continuously.
How do you get started?
This step is really easy. From my point of view, it was a simple process. I requested that we got some team engineering principles, but made it very clear that these are not my engineering principles as a manager, but the team’s engineering principles. I gave some pointers on what I believed would be good principles as examples, and then let the team run the discussion and create the principles themselves. It creates some very interesting discussions, especially between different functions within the team, as they tend the view the world from different perspectives, as a manager you can either choose to observe or leave it completely to the team.
What’s next?
When you’ve created your team’s engineering principles, make sure to bring them up in refinements. This is something everyone in the team should know, and if anyone spots anything which goes against the principles, then flag it, and discuss why that is. Maybe the decision will change, maybe the principle will.
When enough teams do these team engineering principles, you might begin to see patterns across different teams, consider making these into some of the company-wide engineering principles. It’s a very bottom-up approach.
Conclusion
I think principles are important, it helps create better discussions, and makes the team express and expand their views. It aligns workflows and processes and helps prevent conflicts inside the team.
This is just another tool in the toolbox, but one I’ll keep doing with my teams, as I feel a high value coming from this.