Category: Engineering

How does a group develop integrity – wholeness, cohesion, unity?  How does it become a team? Last time I talked about trust and shared values in accountability, performance, and communication.  Let’s keep drilling in.

There needs to be clarity on roles and responsibilities.  There is dynamism here … rigidly defined roles with rigidly specified responsibilities fail in a world where different people bring different strengths (and weaknesses) to the table.

Roles will – or should – generally define what the person with that role is expected to produce during different stages of the SDLC (software development life cycle).  The role imparts the responsibility to the person with the role.  Before a person is assigned (or accepts) a role, the person should know what responsibilities they are shouldering.

Senior engineering responsibilities include mentoring junior engineers … one problem with an ad hoc development team is that there is no sense of permanence … not that anything is really permanent these days … but there is no sense of continuity … no sense that things will continue on after our involvement has ended.

There also needs to be clarity on authority.  Team and project management generally rely on authority rather than persuasion to get things done.  A self-directed team will exercise that authority over its own activities … but that team needs to be above average before it is truly capable of self-direction.

Finally, what should be done about “social loafers” or “toxic team members?”  I want to spend some time on communication so “toxicity” is going to have to have its own blog post …

So … communication

A gelled team communicates.  That is probably a no-brainer, but you may be surprised at how little (or how badly) most people communicate.

Communication has 4 aspects:

1. Transmission (w/ medium) – generally, in technology, speaking/writing … much more generally, it includes art, music, etc.  But we are engineers, not musicians … on the job, anyway.

2. Reception (w/ medium) – perceptually that is hearing/seeing, with luck (and some training) it is listening and reading with comprehension.

3. Cognition – the often neglected art of thinking before speaking and writing or while (and after) listening and reading.  You know you haven’t finished listening until you have reflected on what you heard … absent that reflection you never finish listening to what you heard.

4. Attention – focuses the mind.  You see (or hear) what you focus on … not vice versa

If your attention is focused on thinking about what you are going to say rather than receiving what is being said to you then you are hearing but you are not listening.

People are immersed – drowning – in an ocean of “communication” these days.

We get a tsunami of content – both audio and visual – from our environment.  But it is mostly noise with some few signals sprinkled in.

Signal to noise ratio measures the relative strength of the meaningful (signals) compared to the meaningless (noise).  The internet has a horrible signal-to-noise ratio. 

So … the real question becomes … what is your personal signal-to-noise ratio? 

Mindful communication encourages us to ask whether what we are about to share is “true, necessary, and kind” … we should add “does it improve on the silence?” If we could get some silence, that is.

There is a reason that all-star teams “draw hard vacuum.” A team is not a collection of individuals.  If it devolves into that then you can stand back and watch it disintegrate … notice that word … dis – integrate … to lose cohesion or unity.  The loss of integrity. How does a group develop integrity – wholeness, cohesion, unity?  How does it become a team? 

Credit where due … I have drawn some of this from the website “thebalancecareers.com” where you can find some interesting blogs on business management and leadership;

To be a team a group needs to have (or develop)

Trust – mutual trust of the team members … if it isn’t mutual then it is a problem.  Different people have different levels of trustworthiness and … what I call “trustwillingness” – a person’s baseline predisposition to trust others.

There must be at least enough mutual trust so that people aren’t walking around with their backs to the wall all day.

An interesting article from June, 2009 by Roderick Kramer in the Harvard Business Review on their website – “Rethinking Trust” … he argues for “tempered trust”

“Salting your world with lots of small trusting acts sends a signal to others who are themselves interested in building good relationships … [, and decades of research by social psychologist Svenn Lindskold and others have proved that it leads to more positive interactions.] It works because it’s incremental (and thus manages the risks intelligently) and contingent (that is, tied to reciprocity). By taking turns with gradually increasing risks, you build a strong and tempered trust with the other person.”

When you think about it … tight-knit teams are all built that way … the individuals learn to rely on each other increasingly over time.  Over. Time.  This doesn’t happen overnight.

Besides the fact that it is just a group of individuals, this is one reason why all-star teams suck … there is no time to build a resilient level of trust.

Beside trust, the team has to have shared values … everybody needs to buy in, more or less, to common expectations of

Accountability; commitment discipline – we can advertise that our team has “extreme accountability” (it is in our corporate value statement), but if the team members don’t buy-in … it is just a despair.com poster waiting to happen.

Shared accountability for team success (failure) – the whole team wins/loses together.

Performance and communication – Clear expectations about the level of performance and how and how often the team will communicate. 

There also needs to be agreement – a consensus – on things like

How the team will make difficult decisions – difficult, as in, somebody is not going to get his way.  That somebody needs to already have signed up to accept the decision if/when it goes against him.  You know you have a gelled team when the wrong decision is made and the person who had the right idea (and has been proved right) feels badly.

How the team will deal with differences of opinion – civilized people (and some developers) know how to agree to disagree without it becoming personal.  Flintlocks at 20 paces is probably not a good way to moderate differences of opinion.  In an engineering environment, the proof is in the pudding (which means, I think, that there is whiskey in the cake).  It’s engineering, not personal.

How the team members will support each other.  Nobody left behind, right?  Read up on the Navy SEALs to get a sense of what it takes to form an elite team. 

With respect to training and team formation, the SEALs have an 80% washout rate … you cannot afford that, but if you are trying to build a top-notch team then you have to have the wherewithal to absorb a certain amount of tech churn as you let under-performers. 

Chances are good that you do not have that kind of wherewithal … in which case you are building a team from average performers that you generally won’t want to lose … unless they are way below average.

What does a productive, gelled development team look like?  What does any productive, gelled team look like? You may as well give up the idea of working on a high-performing team.  Unless you are willing to do what it takes to elevate your team’s performance.  And that might not be enough.

Even if you are willing to do what it takes, does everybody on the team?

A development team is not that different from any other kind of team.

Let’s face it, if a team is going to have a chance at becoming a high-performing team, it needs to have an overall commitment to excellence. 

On a sufficiently dysfunctional team, one person trying to lead by example or one voice exhorting the team to work smarter, harder, faster, better will be met with derision. 

If it is a manager calling for improvement it will be met with passive resistance (at best).

People have compared development teams to orchestras … or, better, jazz bands.  And some developers do like to think of themselves as … artistes …

but what is different about a development team, though, is that it is supposed to be building a working solution – it is more engineering than art – and that creates an environment that is more like an academic department than an orchestra …. or jazz band … or athletic team …

… and academic departments are never dysfunctional …

Depending on the type of project, the actual development team may be created ad hoc or pulled together from existing staff.  Or some combination of both of those.  Unless you are unusually fortunate, we assume the following:

Your team will be, on average, … average.  That means that – assuming we have a normally distributed population – 68% of the population will be within +/- 1 standard deviation of the mean.  The average.  It also means that 84% of the population will be +1 standard deviation or worse.

I am willing to be convinced that our population of developers is skewed … towards excellence, of course.  But the argument holds that you will not draw your entire team from the lofty reaches of engineering excellence.

The job is to take a generally average group of performers and build them into an above-average team.  It takes an above average leader to do that.

Many of the arguments for self-directed teams presuppose that the team is above average.  An average or below average team will fail at self-direction.

There are more than a few average (and below) performers out there who believe that they are well above average … or that they are owed self-direction. 

If you have the time, patience is a virtue.  The team should be allowed to start work as it sees fit – within bounds.  The team’s metrics will save you.  One of four results can be expected:

Metrics are not produced.  If the team cannot even reliably collect data and produce process metrics then it is clearly below average and incapable of self-direction.

Metrics show below average performance.  Is there a trend showing improvement?  If so then encourage the team and sustain their ascent.  If not then intervention is needed.

Metrics show average performance.  Is that good enough?  Again, is the team showing improvement?  Keep an eye on things and if performance slips, intervene.

Metrics show above average performance … pop a cork and celebrate … everybody wins.

Next time we will talk about building a development team.  What kind of group characteristics and dynamics need to be developed.