As software professionals, we are exposed to all kinds of problems and complexity. We try to implement business ideas that most of the time are just a shadow of what really matters for the end users. In worst case scenarios we have unrealistic deadlines set by stakeholders that don’t understand very well what we are doing and how software engineering at scale works.
Some of you might have heard the term VUCA (Volatility, Uncertainty, Complexity and Ambiguity). This is were software professionals live every day. For every development we embrace, at some point one or more of those adjectives will make part of our work and I believe you guys have one or two things to say about it.
In VUCA environments, its really easy to make mistakes, and even easier to start pointing fingers. But this does not make the software better and the company better. It will go the other way, will start to corrupt the morale like an infectious disease. It will make people have fear to do their job. Will kill innovation. Your software will become stagnant and dull. Good developers will eventually leave.
The good news is that we have the power to change this. If we start to base our interactions on trust and cooperation, we start creating a environment to face VUCA and build solutions for the real problems at the right time. And the developers, the actual builders of the software, are the base level for any culture change. If everyone is on the same page, either the management fire you all or change with you. And if you have excuses, then you have 2 options: leave right away, or make part of the change.
Many times some people mistake trust with incompetence. I am not saying we should indulge with incompetence, no, on the contrary: high-performance teams are made with strongly motivated individuals that act cooperatively as a single self-healing unit. Scientific research strongly suggests that cooperation wins over competition.
I follow some rules part of my experience that I observe to act positively within the teams:
- To hold on blaming, and instead rely on coaching;
- Open yourself to learn from others;
- Active Listening. Don’t just listen to answer, but instead try to really focus on what others are trying to say. Some say human communication fails by default, so this rule is extra important;
- Don’t stop self education. What made sense years ago won’t make sense now. Technology is changing every day;
- Peer Reviews. Sit side by side, talk about code and learn with each other;
- Driven by the domain. Be guided by the real use cases of the software and well-defined boundaries. This way you narrow the technical options and discussions;
- Responsibility. Assume ownership by the solutions you build and do your best;
In the end, software development at scale is like writing a book with dozens of authors, all making an effort to make a coherent story. Its a highly collaborative environment where everyone should be aiming at the same goal.