How can you influence successful software engineering teams to think, behave, and reason about decisions? One tool I like to use is developing a set of principles, which encourages autonomy among teams.
— noun · “a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning”
For teams to be successful, rather than trying to correct/control individual decisions, leaders can take the approach of aligning their teams on a set of principles and trusting them to behave and make decisions which will achieve that success.
Telling people a list of your own principles is not as effective as working with them to come up with a shared set of principles (e.g. by running a workshop,) which I did recently with my engineering leaders.
As many have shifted to remote working due to the pandemic, I’ve found collaborative online white-boarding platforms like Miro.com to be an invaluable tool for running inclusive workshops.
To inspire creative brainstorming, we started by reviewing prior art, including internal company artefacts such as company values, and external work such as this collection of engineering principles: https://github.com/posquit0/awesome-engineering-team-principles
We then jumped into a blank canvas where everyone captures their ideas for a list of principles on stickies. When the group was ready, we began clustering — grouping related stickies together. Once we identified a unique set of principles, we captured the essence of all stickies into a sentence, and gave our principle a word/title which we thought best represents it. The stickies can also be used to help provide bullet points which cover more details of the why and how — useful for example when explaining to folks while running through a slide deck.
In order to have an engaging workshop and avoid endlessly chasing perfection, we constantly asked ourselves: is this good enough for now, and safe enough to try?
Our 7 principles
TEAM: Efficiently work together as equals
- Strive for alignment and shared understanding across all roles and levels.
- Break silos and hierarchies and work as one team, but balance “too many cooks” with clear boundaries and autonomy.
- Build trust and safety through honest relationships.
LEARNING: Foster a safe environment which seeks and promotes continuous growth
- Team growth & individual growth go hand in hand.
- Continually learn from experiments, mentors, doing, teaching, and asking questions.
- Promote psychological safety through curiosity, humility, and respect.
IMPACT: Always have clarity of your purpose/mission, who your customer is, and the problem you’re solving for them.
- Build empathy for your customers.
- Guide decisions by what’s best for customers.
- High impact solutions come from solving well-prioritised, clearly-defined problems.
- Ship it! Production is the only environment where value can be delivered to customers.
MEASUREMENT: Be deliberate about the data you can use to drive impactful change
- It’s easier to demonstrate impact when you have a baseline measure.
- Consider the risks of what/how you’re measuring — the scope, data quality and integrity, potential bias, and cultural impact.
- Leverage data for decision making, prioritisation, and focus.
LEADERSHIP: Empower others to be successful at making an impact
- Leadership is an attribute not a role.
- Speak up and encourage others to do the same.
- Be a concise but effective communicator.
- Help drive clarity and avoid complexity.
IMPROVEMENT: Everyone should drive continuous improvement
- Leave things more secure, reliable, performant, and operationally efficient than you found them.
- Automate toil — which is manual, repetitive, automatable, tactical, devoid of enduring value, and/or scales linearly as a service grows.
- Own your teams’ value stream end-to-end (build it, ship it, run it).
SCIENTIFIC: Use an evolving, methodical approach
- Practice hypothesis-driven development.
- Be cognisant of your Product Maturity and Software Development Lifecycle (SDLC) for decision making.
- Be adaptable so that processes and priorities remains relevant.
Importantly, leaders should seek feedback and input from teams and evolve these principles over time. In fact, the workshop approach used here can be applied at any level of an organisation — I believe it’s ok for teams to develop their own set of principles, provided they do not conflict with the broader values and principles of their organisation.
The alignment around principles matters more than the resulting words on the page — because it brings consistency to peoples’ understanding of those words. At the end of the day, the success of any organisation comes from its people, and I’ve found this to be a helpful tool in leading software engineering teams.