"The best defence is a good offence!"
It's a very well-known quote but outside a war (or possibly sport) environment, it probably doesn't feel like a particularly relevant adage; especially in a business or management context. Generally, the idea is that taking a proactive approach to a problem will preoccupy the opposition enough that they are unable to react quickly, leading to a strategic advantage.
The software delivery process - especially for professional services vendors - is a complex system that often requires having as many contingencies and costs identified as possible. Anticipating complexity and unpredictability is what sets the software industry apart from so many of the metaphors used to describe it, e.g. automobile maintenance or housing and construction. This aspect of systems thinking means that failure is almost never apparent until you look back and see the decisions or constraints that led to that outcome.
When things go wrong - a key requirement was missed; a feature was poorly implemented; a deliverable exceeded the estimate originally provided - the natural inclination is to ask how it happened. This is where it is unfortunately still far too common to ask the sorts of questions that cause far more damage than a small cost overrun on a client's solution. A high-functioning team relies on the culture of safety we as managers and leaders encourage. I've addressed this directly previously in previous posts.
There are plenty of stories, tweets and blog posts along the lines of "this one trick" or "stop doing this one thing", but the facts of managing and supporting a team of knowledge workers is that there are actually quite a few crucial behaviours to be aware of. Any number of which can create negative reactions and dynamics within your team, no matter how well-intentioned they may have been at the start.
Take a really problematic example: "why". Asking 'why' is a particularly powerful question: it seeks to directly understand the circumstances and nuances that led to a particular point. The inherent danger in asking 'why' is the natural tendency to also include "you" somewhere in the phrasing. Directing a question to your people that includes "why did you" or "why didn't you" changes the intent of the question such that the question is immediately loaded: it's not just about facts; it's about interpretation and judgement. I'm asking about you. You are the one being asked to explain yourself. This is your fault.
Assume a person in your team has delivered a piece of work for a client. The client has sent an angry email to your manager because the work didn't meet all their expected requirements and it exceeded the estimate they were given by three extra hours. A manager's natural reaction would, in part, be to see what led to that outcome and understand how to avoid that in future.
Asking questions like the following are almost guaranteed to torpedo any goodwill and genuine willingness to work together by the team member and everyone else who observes the exchange:
- "Why didn't you check how much time you'd spent?"
- "Why did you deliver it without testing the functionality?"
- "Why didn't you add extra contingency into the estimate?"
- "Why wasn't the estimate / code reviewed?"
These might all be reasonable questions on the face of it and the information being sought is probably important, but "why" questions trigger defensive reactions and feelings that bypass data input and thinking. It assumes your people actually have an answer and puts them under pressure to answer immediately. If you are forcing your people to come up with a cogent justification they simply don't have, you won't get the right information and you'll likely engender defensive reactions for all your future interactions.
The rationale here is fairly easy to appreciate: "If I identify all the things they did wrong, we can put measures in place to prevent those things from happening again". In other words, if you mount a strong defence, the problem can be avoided in future. This might take a number of forms including additional rigour around your processes, having your people submit their work to you so that you can check it first, or having your team factor in significant extra costs to accommodate the inevitable shortcomings or risks your team are subjected to from elsewhere within the business.
While the rationale might seem entirely justified and appropriate, even more so if there appears to be a pattern of failure within the team, fostering an atmosphere that doesn't allow for error sends a very clear signal to your people and makes them more defensive. They'll play it safe and won't try things that might turn out negatively for them. Initiative within the team suffers and you can absolutely bet so does morale and hostility towards that type of management style.
This defensiveness is directly encouraged by trying to systemise the process.
When you impose rigid methodologies so that staff members are not allowed to make any of the key strategic decisions lest they make them incorrectly. The average level of technology may be modestly improved by any steps you take to inhibit error. The team sociology, however, can suffer grievously. - Lister, DeMarco : Peopleware
Good leadership is about creating an environment where your people can succeed. By its very definition, that environment is not strengthened by putting up barriers, safety nets and control gates. It's about adding freedom, trust and support, and that freedom very likely won't lead people in exactly the same direction you would have proceeded. To quote DeMarco and Lister again:
The right to be right (in your manager's eyes or in your government's eyes) is irrelevant; it's only the right to be wrong that makes you free.
Leadership is by nature a social contract. People have two broad expectations of management, one being character-based and the other competency-based. That is, we expect our managers to stand by us as advocates and allies, and we expect them to have a technical understanding of both the software we're building and the management skills accepted as being in line with good industry practice. Both of these areas are constantly evolving and a manager that neglects to improve or inform themselves in either (or worse, any) of those areas is letting themselves and their people down.
There is an approach that achieves the same result of minimising scope for error while still building a culture of trust, learning and accountability. Taking a more systems-based view and seeking out the procedural or environmental factors that led to a negative outcome is more valuable than placing the responsibility on the people involved.
So for the purposes of our example above where a series of "why did / didn't you..." questions are directed at the individual, the better approach is to look at how the system itself contributed to the problem and what can be done to refine those processes. Questions like "how can we make effort spent more easily and immediately visible", "what testing needed to be applied and what constraints were in place that might have impeded that" or "how can we involve more people in our work output so that reviews are thorough and accessible" collect the same - or better - information but with actual data that can then be acted upon.
Our people are just actors within a system. Assuming you've hired good people and trusted that they'd be a good fit for your team, responding to a situation in a way that protects them minimises the negative impact and maximises the potential to learn. With professional services vendors in mind in particular, software development companies have multiple teams and several complex interactions, often each concerned with their own motivations and sphere of influence. Identifying the points along those interrelationships that present risks and making the effort to understand the failure modes means that everyone can work more constructively towards refining the system and meeting the needs of the actors within it.
By turning the conversation around to look at who is accountable for ensuring the next person in the chain of responsibility is best-positioned to succeed, we move the narrative from one of blame apportionment and judgement to restorative action and support. The obligations of each person in a position to affect an outcome shift to being more equally shared rather than burdening the person left holding the baby when things go wrong.
To this end, our example manager can engage their developer in finding a solution to the client's situation and three hour overrun by working alongside and enabling rather than taking a position of power. If they approach the developer with "I'd like to help bring our effort more in line with our estimates. What do you believe would have helped achieve that in this case?", it allows both parties to build a stronger, more supportive system.
And perhaps that's the most important "why" of them all.