reading: team dysfunctions

my work-related reading started with programming books and reference materials. then, as i was becoming more aware of things around me, i started reading up on development process, requirements gathering, and all this other “softer” stuff.

when it comes to applying the knowledge, the latter was more tricky – perhaps because it was not just up to me when and where to implement it – other people had to be involved.

with non-technical books it is all too easy to kick back and follow along as if reading an adventure novel – this stuff is engaging, and one might dream of making bold decisions, only if one were in the position of power – all of it from the safety of one’s couch.

in my case i realized that i had to consciously make a mental effort to move from mere recognition and acknowledgment to tangible steps – what can i do tomorrow, in my particular environment? otherwise it will just sit in the back of my mind, and i will mumble behind peoples’ backs recognizing yet another opportunity missed.

this seth godin’s blog entry really helped to illuminate this problem for me – the ideas in a book are just a short bullet list, the rest is persuading the reader to act. so i will follow his advice and pick a book from my recent reading to see if i can get something tangible out of it:

five dysfunctions of a team – is a light read, just a few simple points presented first as a novel, then discussed one by one. but then after reading it, as it was fresh in my mind, i gradually noticed how nicely they applied to the environment around me.

true to its title (admittedly catchy), the book goes over five qualities that are necessary for creating an effective team; they build upon each other, so i’ll pick the first three, since they are the foundation for the rest:

Trust

in the team-building context trust is knowing that all the team members have team priorities first in their agenda. it is not being afraid of showing ones’ vulnerabilities, knowing that others won’t take advantage of that. it is knowing that your peers’ intentions are good, and there is no reason to be protective or careful around the group.

trust makes delegation possible – which allows the team to scale and be more effective, as work gets distributed around with everyone aware of individual strengths and weaknesses within the team. the opposite of that is everyone working in their little cubbyhole and reporting up.

finally, trust makes risk taking possible.

i think i consciously made an effort a few years ago to make sure i say, “i do not know” more – this simple acknowledgment goes a long way towards removing barriers within the team. it makes offering help and asking for help possible (which is good telltale sign in itself).

another conscious effort was to apologize more – it works towards defusing the tension and focusing on the problem. obviously, one has to be somewhat self-aware for that to work, and luckily i had a misfortune of witnessing some monstrous examples of personal communication deficiencies, so i have learned from others’ mistakes as well as my own.

team identity

in school we are encouraged to focus on individual goals, so it takes a conscious effort to change that habit for the good of the team, and team identity is one of the powerful aids. one has to consciously build it up – starting from the name of the team, clear statement of short-term and long-term goals, the vision that provides perspective when you are saddled with everyday tasks, acknowledging successes and being proud of them, sharing the problems and treating them as team’s responsibility. there are plenty of smaller things – everything from eating lunches together to casual chit-chat.

secrets and politics within the team kill trust, so my personal resolution is to be more open – have no reservations about telling others what i am working on and why. i noticed that i do hold back sometimes, not sure of others’ intent, and this is definitely a problem.

i also need to give more benefit of the doubt before arriving to conclusions regarding others’ motivations, i think sometimes i am too eager to assume ill intent, and this obviously inhibits trust.

feedback

this is the next step, it might come naturally as a result of working together, but it helps to acknowledge and strive for it consciously.

the good thing is that large companies invest heavily in HR review processes. the sad thing is that for the bad manager these twice a year reviews make the situation even worse, since they come across as stilted corny HR drone-induced formalities, so anything that resembles them (like actual good feedback) is squashed even further. as for the good manager, they do not need these, since they do it on regular basis anyway.

so my personal resolution is to give more feedback to my peers (which i think i am getting better at – noticing individual achievements, taking the time to stop by and comment on something casually, etc), but also giving feedback to my management, which i am not that good at.

i think i also need to get better at offering help – taking into account the personalities of others and trying to tailor my offer to that.

Conflict

productive conflict is essential. if it is avoided, important issues would not get resolved, which will be even worse in the long run. so one must recognize its importance and embrace it, at the same time remembering that it should not be personal.

needless to say, without trust productive conflict is impossible.

i think this is where i could use a lot of work. at some point i became all too aware of others’, so i tend to come across as non-confrontational more and more. i often tend to avoid conflict in the misguided attempt of maintaining everyone’s comfort.

another problem is “picking your fights” – there are always plenty of problems, and one cannot tend to them all. so you either spend your time on all of them and accomplish nothing, or give up and let it all slide.

here’s a common scenario i am guilty of – something is wrong, something is not working, i try a few times to fix it, but it is not my responsibility, although it hurts me as much as the others. so i grumble half-heartedly around the people responsible, but never challenge them openly.

a natural reaction is to ignore it, but that leads to the “broken windows” syndrome (see pragmatic programmer), which, once it gains momentum within the team, is hard to reverse.

it also reinforces the silos – this is my own perch, i tend to it, and others’ should not stick their heads in. ideally, a problem will be out in the open, the whole team would regard it as their problem.

so instead of creating a permanent state of team guilt, perhaps these issues could be put out in the open and prioritized, so that at least these mistakes won’t be made again.

i also primarily worked in the teams where i knew that we could always solve problems ourselves, there was no need to reach out to “higher authority.” it turns out that in large organizations it is sometimes necessary to ask for arbitrage from above to get stuff done. although it pains me to do this, since it fundamentally goes against what i think a leader should be doing, i have to acknowledge the reality and focus on the problem that needs to be solved.

Accountability

ideally i want and environment where my teammates hold each other responsible for the high standard of work they produce as a team. if someone goofs up, others should be able to step in and challenge them.

here’s an example. given a multitude of assorted projects with various infrastructure problems, one is tempted to create an architectural police of sorts that goes through the checklist – proper logs are written and rolled, monitoring in place, DR in place, etc. while this could be a valid first step in some situations, in a perfect world the team itself will know what these standards are (perhaps since they are wikified) and their personal pride and identity as a team makes them follow these standards and make sure other teammates follow them as well.

it comes natural in a healthy teams, but in dysfunctional teams its absence is painfully obvious: everyone does just the bare minimum to get by, and only certain people in complete isolation try to achieve their own high standards.

peer pressure is a powerful thing – poor performers feel the pressure to improve; it promotes respect, as opposed to resentment between team members with different standards.

of course it builds on the previous principles – it is impossible without trust to give feedback, it is impossible to challenge people with fear of conflict.

so my personal takeaway, going back to fear of conflict, is to challenge people and speak up; i should collect and promote best practices; i should be doing more presentations and knowledge sharing.

it is a gradual process, and with the absence of slack this grass-roots movement is very hard, so at some point there needs to be some management support.

it also helps to hold project retrospectives, because if we lack self-awareness and succumb to “broken windows”, we will make the same mistakes over and over again and take it as a norm. i am guilty of not pushing for retrospectives as much as i could. perhaps as a start i can informally round up a few teammates and go through a few exercises suggested by the “agile retrospectives” book.

why am i so adamant on this being a peer effort? leaders should not be the ones creating accountability, in fact it can be counterproductive – the team will delegate the responsibility to the leader and as a result either become even more passive, or worse, turn against it, seeing it as unnecessarily imposed upon them.

there is a lot more practical stuff in the book, and skimming through it again makes me realize that i’ve missed quite a few tips, but let’s see if i can get some of these practical things done first.