Part 1, focusing on skills, experience and domain knowledge.
What Qualities does your Team Need?
So, you have a business need – how to solve it?
You need a capable team – a team capable of delivering the needed software, which is maintainable and extendable. To succeed the team needs to have enough:
- software development skills
- experience in software development
- domain knowledge and
- teamwork skills
There is no way to quantify a threshold value for each of these qualities, but we can look into them from a qualitative point of view.
Skills and experience
Skills and experience – these two cannot be assessed separately as without experience from similar cases we cannot assess the skill-set needed. In some cases, we may only have a vague understanding of the possible skills needed if multiple unknowns are still unresolved when starting to tackle a completely novel problem – in these cases we must rely on intuition. Luckily, we often find that the available team has most of the skills needed and that the rest can be obtained along the course of the development or by utilizing external subject matter experts – assuming the team works well together.
A key finding here from a team building point of view is that…
We should look for team members that complement each other rather than just blindly trying to hoard the most senior and skilled individuals.
Clearly, a team without all the skills needed cannot succeed and there aren’t always enough time or resources to allow for extensive learning. In real life, a team without the needed skills is the one that gets cut off and replaced mid-development – a loss for the team and for the business.
Deficiency in experience is even harder to overcome because…
The core benefit of expertise is the ability to ‘get it done’.
Regardless of how skilled individuals you have in your team, if there is no comprehensive understanding of building a maintainable and working solution you may get stuck in a dead end, in an endless finalization phase, or ending up with an unmaintainable and unextendible solution.
The best way is of course to build new teams on top of existing ‘proto teams’ – core teams of 2-3 people that already have worked together successfully before. More about this approach in my ‘Siiliway’ video.
Is it possible to have too much of skills and expertise?
Not in theory but yes in practice, and it’s often the consequence of ‘hoarding the most senior and skilled individuals’. During the past 15 years of actively working in consulting I have witnessed a destructive pattern (which our team has managed to avoid by sticking to ‘solution deliveries’). For some weird reason, buyers of software development (encouraged by the salespersons of consultancies) concluded, that ‘Agile’ meant that they should run their own software development teams and use consultancies to provide the ultimate experts, but with no demands for output or complementing skills. The ‘Agile Process’ would ensure maximum output – the exactly needed software in the highest possible quality at high development speed.
The reason why so many traditional software consultancies struggle currently is that this paradigm led, in too many cases, to:
- underperforming teams
- teams with members with similar skill portfolios and little overlap
- high cost of features
- slow and unpredictable deliveries
- writing every solution from scratch – often with the latest (unstable) tech stack
(Thank God for team topologies for promoting platform teams which has started to fix the situation) - avoiding ready-made – especially proprietary – solutions
- purist approaches = every approach ending in ‘native’ for technologies with <5 years of history – cloud-native, AI-native etc.
- bad or lacking documentation
- engineering-first solutions vs. user-first solutions (overly exquisite architectures for simple solutions)
- etc.
It also encouraged an unhealthy competition where consultancies hoarded consultants with high wages and promises of getting to use the latest technologies – when at the same time the companies producing the software couldn’t compete, because they needed personnel to handle their legacy systems and could not afford a cornucopia of technologies to support.
Apart from wasting top talent on a ‘feature-factory’ assembly-line, a team of highly skilled and experienced experts will also bring along specific problems. As these experts know what’s best, they will come up with multiple different approaches, architectures etc. for each problem and will be capable of defending their approach efficiently against the others and being extremely reluctant to yield to an approach which they do not recognize as the best.
There are of course very specific and rare complex cases dealing with completely novel environments, a lot of constraints, and with very wicked problems to solve, where a team where every member is a seasoned expert is the best approach.
Domain knowledge
All solutions work in a context and understanding this context is crucial – otherwise you risk building a solution that is not supporting the natural way of working in a particular domain. All domains also have their specific business logic and set of constraints which the team needs to thoroughly understand.
An ‘outsider’ expert without the needed domain knowledge might view a solution as overly complex or unintuitive to use before diving into the domain and its ways of working. E.g. use of codes and abbreviations in an UI may seem unintuitive to a layman, but comfortable and unambiguous to a domain expert – consider e.g. factories, airplane, or even accounting. Similarly, legal constraints – like in the finance industry – or quality constraints – like in medical products – can have a massive impact. If you design software to run a surgical robot, the price of even small neglects can be measured in loss of life.
Acquiring the domain knowledge needed in typical cases is hardly ever a problem. You just need to factor in time for new team members coming from outside of the domain to interact with the users.
Practicing healthy respect, care and ample communication with your teammates when joining a team in a new domain helps you to avoid typical pitfalls.
As a software development team member, you do not need to be an expert in the domain. You should rather cultivate a healthy interest in the domain which will naturally guide you to learn more about the field. Once you understand the domain, the peculiarities of the business logic become easier to comprehend. Also, frequent interaction with your actual users is a good way to keep you grounded – just as in every kind of software development.
Of course, it’s healthy to expose ‘closed’ domain specific systems to general user experience and software development experts to get second opinions and radical ideas that could reshape the ways of working of a specific domain. However, it’s crucial that actual domain specific users verify the new approach before pushing the new approach into wider use. Also, when assessing the change, it’s important to try to differentiate resistance to change from unsuitable user experience and to calculate the possibly needed training to a new way of working to the costs of the change when compared to possible small gains in productivity.
Teamwork skills
I’ve seen teams of seasoned experts with all the necessary skills, experience and domain knowledge fail. Something that shouldn’t be possible, but because we are social animals. I’ve seen it happen multiple times and the reason is always related to interpersonal relations and (lack of) teamwork skills.
Teamwork skills and group dynamics are a thoroughly researched domain, yet for some reason teams seem to fight against these patterns repeatedly. Maybe because teamwork skills are not strongly enough represented in the education of software engineers, computer scientists etc. Maybe because of the strong division between the natural sciences and the humanities leading to the resentment of the humanities by many engineers and natural scientists. Behavioral sciences are seen as soft and vague because they lack explicit quantitative casual relationships between an action and the desired result.
We humans are complex animals and when forced*
*) Used to make a point. We are social animals and crave to interact with each other and feel physical pain if not able to engage with others.
… to work together and become extremely aware of the power play, the level of contribution given by other group members, the feedback received (or not received) from our teammates etc. One wrong move of word and the harmony is destroyed.
The cost of breaking the team’s efficient working culture is huge – I’ve witnessed several cases where a single incident has ruined it beyond repair.
In a worst-case scenario, you need to stop and completely rebuild the team with the loss of tacit and explicit knowledge and time.
When working together we need to focus on (Lindsjørn, 2016):
Communication, Coordination, Balance of member contribution, Mutual support, Effort, and Cohesion.
More about these teamwork skills in the next post.
References, Inspiration, and further reading
Hunt, A. & David Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master
Beyer, Jones, Petoff & Murphy (Editors) (2016). Site Reliability Engineering: How Google Runs Production Systems
Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow.
Lindsjørn, S. D. et al (2016). Teamwork quality and project success in software development: A survey of agile development teams. The Journal of Systems and Software 122 (2016), 274–286.
Our Great Team 