Have you ever wondered what we do as software development teams or what is our long-term purpose? Having such a perspective on why we do things as a team is extremely powerful but sometimes difficult to define. Recently I tried to look at this topic from a bird’s-eye view and found something that could sound pretty universal! Today I would like to share that with you and inspire you in finding your own purpose.
Software Engineer
As a software developer, I used to master the engineering area of my work. It’s where the code lives, where I could optimize the development processes, maximize the error-free ratios, design the best solutions to problems, etc…
However, I started asking myself why there is a need for all that. While I believe there is a strong need for Software Developers to obtain mastery in engineering there must be something more behind the ‘why’.
Engineering addresses Product needs
As long as it’s not academic considerations but a real business - technology was called to build a product. Firstly, let’s quickly brainstorm what the product means. It’s a collection of random thoughts that came to my mind not anything carved in stone:
So when joining these two, there comes a relation of what product needs from the engineering. Here is the inspiration for what it could be:
I chose only a few, but I am convinced that having a flexible technology that is designed for change while also being quickly developed and deployed with stability is a sort of universal need of the software product.
What does engineering need from a product to give it the best support? Developers need to know what should be developed and why. Knowing the purpose of changes and the potential priority is important to properly design software. Solutions for critical paths would be designed in a different way than the experimental new feature. Also, engineering needs a piece of trust to take actionable ownership of technology problems.
The missing ‘department’
Both product and engineering have needs from one another, but none of them could be tackled without people. Here are some more random thoughts on how we could describe that:
So people are needed for both Product and Engineering. I called that need engagement. This is where extraordinary results come into play. Without deep engagement, belief, pride in product and engineering, there is only mediocrity possible.
And last but not least are the needs of people from product and engineering. The needs are pretty similar for those areas:
Both product and development should just give people fun (check out why in my other post where I describe what makes people engaged and self-driven). People should feel like they could be the ambassadors of both the product and technology. The purpose is to give people self-esteem and growth. This could be achieved only when people can do their best (freedom) and know the direction of where they are going (vision).
The model
So it appears that every part of our everyday work is connected with two other parts. Here is the complete system example:
My idea is that software development teams’ universal purpose is to find a way to keep all the needs satisfied.
Where all needs are satisfied equally, then there is a steady state. The product, people, and engineering are all effectively supported.
Practices
What happens if one relationship is not functioning well? This is when things become complicated.
As to systems theory, there are two possibilities when a system loses its stability. One option is to lose the stability forever, stop working, or even explode… And that’s a tragedy you want to avoid. This might happen for instance to highly disengaged products, some technology terrifically inappropriately used, etc…
However, the other option is to get back on the stability track somehow. And that “somehow” is the most interesting for teams. This is where the practices of a team emerge. Let me give you some examples:
- A product part couldn’t be delivered fast enough, so the team decided to deliver smaller functional parts
- Waiting for the code review took too long time so the team introduced a daily routine of code reviewing
- There happened some releases that introduced major bugs in main functions so the team introduced weekly regression tests
- … and so on
It’s the team practices that help to keep the balance in a constant movement. When the team is forming and has no experience it’s more fragile so one stability disorder could lead to burnout. However, when the team has implemented many emergent practices it’s much more difficult to move out of the balance. Some of them even become their good or best practices that are repeated and improved over and over. Here’s an example of what I mean by team practices across all relationships:
Find the balance!
So, the purpose of why I am sharing that model with you is that I think that “finding a balance between Product, Engineering, and People” could be a long-term purpose for software development teams. It’s not about making only the product or the technology successful, all three areas above are equally important.
So what I encourage you to do is take it as an empty template with just Product, Engineering, and Team on the paper. Then the team may define what a product is for them, what the engineering is, and how they describe the people’s roles. Also, define your needs as a team, and try to fill the model with your thoughts in every possible need direction. Discovering connections represented as green arrows might be the game changer! Write down the practices that you have worked out - those are the team’s DNA that shouldn’t be lost.
Do you see any imbalance? Is there any “branch” that is not well supported by the others? Maybe the diagram would be a cool inspiration to start working out issues the team has ignored so far.
After all, it’s not about filling the diagram, it’s about finding the identity of your team. Write down every challenge, problem, and practice together. Knowing what and why you do as a team is a great foundation for constructing a team purpose based on ‘keeping the balance’. By having a such purpose, you can focus on constant improvement in all the important areas.