Highly-effective Teams
At JUXT we work with many teams and businesses at different stages on the software journey. Sometimes small startups, with a vision but not a single line of code yet written, sometimes global businesses with thousands of employees and a vast and complex existing software estate. We’re often tasked with reviewing existing systems and processes. It means we see the results of both successful and failed software strategies across many different businesses and sectors and it gives us a unique view on how things succeed (or fail) most often.
There’s no playbook for guaranteed success, but over time we’ve seen the characteristics that are common to highly-effective and productive teams. Let’s call out some of those key traits and build a good starting recipe for a highly-effective team.
1. Ruthless prioritisation
Teams should always ensure they are working on the most critical task. Backlogs should be prioritised with a clear rationale that’s well understood. Every effort should be made to identify the critical core of each feature, defined by benefit to customers, and non-critical elements should be prioritised appropriately.
There is far less demand for accurate estimation (a perennial source of frustration and conflict) when the team can be certain they are always working on the most valuable task.
2. Small is beautiful
Smaller teams benefit from lower communication overhead, clearer focus, higher alignment, and greater accountability. We see empirically that the most effective teams we build are small. The characteristics of small teams are key to creating surprising productivity.
3. Constant communication
Teams should communicate, in high-bandwidth ways, very regularly. We encourage communication of all kinds, on all topics, daily, and rarely restrict communication on any topic to designated meetings. Communication does not always come naturally, so we endeavour to create supportive environments in which people feel encouraged to share.
4. Working as equal partners
The motivation of engineers, and their sense of commitment, depends on treating all members of a product-making team as equal partners. This means avoiding structures or processes that imply that managers, or those driving product strategy, are the ones that want to ship the product and engineers have less commitment to the goal.
5. Iteration and feedback
Delivering product features requires turning expectations into reality, and it’s essential that these expectations can be validated as early and as incrementally as possible. Teams should coordinate every day to see and test some material improvement to the systems they build, and product owners/managers should work with teams every day to provide feedback. This means engineers must look for opportunities to ship early and often. Since priorities can and do change, it’s essential that systems are built iteratively so that, at any given moment, the inventory of unrealised value is small.
6. Recognise effort, and results
Teams should celebrate successful results, but where engineers are required to do exploratory work, exploring an unfruitful avenue must be recognised as progress on the path to success. Where engineers work diligently towards team goals, this must always be recognised and never devalued.
Processes that include artificial deadlines, and seek to invalidate work done towards the goal if the deadline is missed, should be shunned. Cultures or processes that do not recognise earnest work undermine motivation.
7. Autonomy for engineers
All individuals within an engineering team should be encouraged to bring their own experience, ingenuity, and judgement, to the tasks they complete. Ways of working, where possible, should be left to the individual. This naturally also means that teams must avoid defining roles too rigidly. Engineers should be free to choose practices that are appropriate to the task at hand and we should be wary of the one-size-fits-all mindset.
This doesn’t mean chaos, and highly effective engineering organisations will create a strong common culture that often results in a lot of alignment on technical choices (and approaches) across individuals and teams.
The Model Team
The JUXT model team consists of 2-4 engineers, and a dedicated domain expert (on-site customer / business analyst / product owner / product manager). All team members have a good understanding of agile product-making practices.
The team meets every day to discuss priorities for the day. When they meet, they talk about new things they have to show, new things they have learned, things they do not understand or need to clarify, and things that have changed. During the day, they check-in with each other frequently and when questions arise they are quickly asked, discussed, and answered.
All members of the team are ‘delivery-focused’. The team has a bias towards action and progress, and seeks to avoid procrastination. Ambiguity and indecision are often resolved by just trying something, to see the result and get tangible feedback.
The team radiates information about progress, such that no-one is in any doubt about what’s in-flight and what’s complete, what’s deployed and what can be used. Planning processes are minimal, but there is trust that the team’s full and conscientious effort is directed towards work of the highest priority. Teams break work down into small units, if at all possible, and high-level plans are built using macro observations and aggregated metrics.
Doing more, with less
There’s some truth to the idea that talented individuals will succeed with any process, but we see common patterns in highly-effective teams. As software businesses are challenged to do more with less, it’s more important than ever to identify what makes a team effective and how to maximise results.
