How to Transform Your Squad Into Self Driven Ninjas
This is the first episode of Monkey Learnings! Monkey Learnings is a compilation of stories and learnings gathered from Engineers and Product Managers during the regular Monkey Club Meetups in Zurich. The goal is to share the collective knowledge of the club, to shine some light on engineering vs product perspective and give impulses for change.
Having worked in different companies, with different team constellations in different countries, one can observe certain patterns. No matter the product or organisation, each tech company is trying to increase motivation, productivity and/or innovation in their teams — using very different approaches.
In the Monkey Club Meetup on 5th February we discussed exactly that. How to transform your squad into self driven ninjas?
Before diving into the best or worst practises for transformation, let us first define what we mean by a “squad”.
A squad is a cross-functional team in an agile environment that is autonomously working towards its own goal. It usually consist of engineers, a product manager/owner and a UX/UI designer. Together they have the competence and ownership to deliver end to end features or even projects.
There are various aspects in everyday work life, may it be in a startup or big corporation that negatively affect the motivation of product managers, engineers and designers. The Monkey Club members have collected a rather long list:
- Feeling insecure about the job’s stability
- Lack of decision taking and responsibility
- Unclear purpose of the project or entire company
- Constant distractions
- Poorly thought-through solutions
- Unanswered desire for appreciation
- Overall negative vibes
- Retrospectives which don’t change anything
- No openness to debate
- Perceived lack of cooperation
- …and the list goes on
In our meetup we were discussing an amplitude of approaches and real-life examples of how motivation got positively affected — which we together structured in something very similar to the food pyramid. From a strong foundation of basic hygiene criteria to the essential conditions which make us work together, to the nice to have sweets on top. For this article we will focus on the two bottom layers.
Unfortuantely, there is no golden bullet that solves a squad’s motivation struggles all at once — but there are certain aspects which are essential to change in the right direction.
Foundation
Psychological Safety
Wikipedia defines it as "a shared belief that the team is safe for interpersonal risk taking". In psychologically safe teams, people feel accepted and respected. In our discussions at the club we saw this not only in the scope of a team but also on company level. May it be due to your company announcing strategic change of direction or a very moody boss — it is crucial that you give your team the confidence that their job isn’t on the line and that everyone can be him- or herself in their teams.
Purpose
Nothing worse than working on a project without understanding the reason for it in the first place.
A lack of purpose makes it hard to remember why one should get up in the morning. In contrast, a shared understanding of purpose encourages people to engage and contribute as they have bought into the idea in the first place. Of course the purpose can shift over time, however ensure that every team member is picked up when it happens. The purpose is your compass to get everybody aligned into looking in the same direction.
Interaction
Involvement & Ownership
The product manager thinks about a concept, engages the designer to mock it up, together they then introduce the entire concept to the engineers and shortly after, the implementation kicks off. Except it doesn’t. The engineers attack the fundamentals of the concept and the product manager defends the concept she has so long worked on — everybody is frustrated. Sounds familiar?
The former approach will struggle creating the desired sense of ownership and engagement. The whole topic is worth a medium article by itself but in a nutshell: As a product manager your job is to communicate the “What “and “Why”. Leave the “How” to your engineering team. Have few, but structured meetings early on, which give the squad the opportunity for input and important considerations. When the final concept with design is then presented and once more challenged, there will be much more buy-in and willingness from the squad members as they have already contributed to the final outcome.
Appreciation
Humans flourish and grow when they feel appreciated. It also makes us behave much more social and cooperative. With dense timelines and different perspectives on a desired project delivery, the sense of appreciation often gets lost.
Take the commonly mentioned example of a squad working on a project and suddenly a change of course and weeks of work are thrown into the trash bin. Here again, make sure your squad is involved in the ‘Why’. Is it really necessary to abandon the entire previous work because of this course change? — might there be a better way? Make the everyday turbulence of a startup a group effort and engage others in the solution. You will find that not only do problems seem less severe as they are carried by the entire squad but also solutions are easier to find and implement. We loved the best practice introduced by one of our members: “Bragging Sessions” — similar to a demo this is the moment for engineers, designers and product managers to present what they have accomplished. This creates the stage for celebrating accomplishments which otherwise might not be mentioned— it creates a vibe of pride and appreciation.
Feedback
As suggested in the Principles of the Agile Manifesto, most squads run regular retrospectives and feedback sessions to improve the way they work together…but forget to walk the talk.
Make sure you act on the outcomes of the retrospective to give your peers the feeling of appreciating their input. A simple method is to write down the “actions to be taken” during the retrospective and share it within the squad. Another way of acting on feedback are frequent releases which spin up a vivid feedback cycle between users and the squad. Don’t wait until you build the perfect product in the dark — release often and get feedback.
There are many more aspects to consider, however this article’s goal is to give you advice and insights about the core issues which you can start acting on today. Was this helpful? Share your squad experiences and ideas in the comment section below and let us know any feedback!
