Tag: Team Dynamics

For the public good…

I am continually fascinated by the notion of self-organising teams, how they motivate themselves and how you can create an environment that is conducive to self-motivation.

Unfortunately my experience is that self-management works for the minority and is highly rewarding and highly effective, but it does not work for all. Bystander Syndrome is prevalent and too often the plants do not get watered. Why don’t developers water the plants?

So, recently I ran an experiment and discussion on the general low involvement and engagement of extra-curricular activities. In particular events that are considered to be core to the effective working of the company but are not explicitly part of your core objectives.

The premise of the experiment is that we have become more focused on benefit to ourselves or benefit to our local teams, rather than the benefit to the wider organisation.

img_0447

For those out there ready to point out that an experiment requiring voluntary attendance already excludes those that are more focused on themselves – you got me!
I stacked the deck in favour of the more social minded of the organisation.

Some examples:

Our organisation is very much built around self-organisation and we are expected to manage our own time and priorities.  However, we have a number of activities that are ‘global’ in scope: some where the time spent is voluntary and expected to be worked above and around billable time.  Or facilitating other team’s retrospectives which is billable time but can conflict with your primary team priorities. Even our Guilds, which are groups of people based around a single focus or competency have an implied ongoing commitment to attend regularly.  Finally, “Lunch and Learns” or bookclubs where there is opportunity to share ideas and learn from colleagues, which is a core cultural goal of the organisation but is done as part of your personal development and on your own time.

All of these activities could be considered to be valuable to the organisation and in most cases to you personally (directly or indirectly), but all require an investment of time and effort. My observation is that in many cases the involvement is diminishing either proportionally or absolutely as we grow. Attendance at lunchtime events seems to be diminishing, involvement in volunteer groups like guilds is a challenge to the organisers and maintaining membership is probably the number one challenge.

The goal of the discussion was to identify ideas for how we maintain or stimulate these activities and how to involve a wider audience, preferably without putting a greater burden on a few (and often the same few people), and without directing people to attend, which is counter to our culture.

The Game….

We played a game loosely based on the ‘Public Good Game’ We set up two relatively large groups. All participants were given $10 each and the game is played in rounds.
Each round players can contribute as much or as little as they like to ‘a pot’ but the total contributions will be combined and then a pre-determined bonus would be added to it. One team got a 30% bonus the other team a 40% bonus.

Round 1

All players were asked to choose how much to contribute, in the 30% team the contributions were visible, in the 40% team the contributions were secret.

If you apply pure logic, the maximum gain is obtained by everyone contributing fully, that way everyone gains a lot.  But an individual can work out that by opting out and reducing their individual contribution they can benefit at the expense of others.

Subsequent rounds…

Over the course of a number of rounds as more and more people realise that others are not contributing fully, they will either call the others out for not contributing, OR they too opt out and eventually those that are still contributing receive back less than they contribute and at that point system fails as everyone eventually opts out.

End Game

What we found was that the transparent team reminded each other and kept the focus on the public benefit and maintained a better contribution level, the secret contributions team had two or three participants who were able to benefit considerably at the expense of others  by not contributing (leeching from the pot). There was sufficient reward to keep the others motivated although that was diminishing each round.  Overall it was the transparent team that benefitted more, but both teams missed out on a huge amount of potential benefit by a focus on personal gain.

Conclusion

In the recap there was a suggestion that it was unclear whether the goal of the game was for collective gain or individual gain – e.g. How did we measure the winner?

But the reality is that this is the same quandary that we face in our day to day life,  are we working for the benefit of ourselves or our team or our company?  All our choices for extra-curricular activities are an investment of our own time and effort and we are motivated either for personal gain (what is in it for me?) or collective gain (How would me attending benefit my team/company?)

Discussion

Many of the arguments we heard were around billing, and utilisation. There seems to be a reluctance to use personal time for ‘extra-curricular’ learning, which implies that there is a perceived lack of sufficient personal benefit from involvement in these activities.

In other cases such as facilitation and helping other teams people are balancing time spent with their local team against involvement in activities that benefit a wider group.  The question is… Which is more important?

The challenge for us then is how to change priorities such that activities that benefit the company as a whole are perceived as valuable (not necessarily more valuable but valuable enough to make that effort), or to highlight the benefits to us as individuals resulting from a greater involvement in company wide activities.

The conversation that followed created some great ideas, as well as highlighting some of the concerns.


The Dunbar number

Dunbar’s number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships.

Dunbar’s number on Wikipedia

Dunbar has a theory that as groups exceed a certain number approximately 150 people their sense of community diminishes and the group becomes less effective, less cohesive and it is more difficult to self-organise.

Many of the issues raised could be interpreted to have their root in the Dunbar number.  As we grow we don’t personally know the other people that are presenting at LnLs or the others that are attending the guild meetings. This lack of personal attachment results in a diminished sense of interest, ownership and responsibility, skipping is downplayed as it is only letting down people you don’t know, or an assumption that others will attend.

Ideas for increased engagement

  • Offer food
  • Educate people on calendar etiquette, e.g. show up if you accept
  • Increase advertising/promotion of events and activities
  • Write up a “What you missed” summary for those that didn’t attend
  • Leaders show support by attending,
  • Reward directly or indirectly those that present and/or attend
  • Make clear the purpose or learning goals of events
  • Introduce compulsory lunch breaks, or compulsory attendance
  • Highlight the understanding/visibility of what happens when you don’t step up
  • Identify Champions to help organise and promote these activities
  • Have fixed times/days for lunchtime activities to regulate number and ensure quality.
  • Invite only those from a sub-group (accept Dunbar’s Number and work with it).

Our goal with this experiment was to gain ideas and gain a better understanding of the problem and to share these concerns with a wider audience, we were not aiming for a solution to the problem just a start to the conversation.

Feedback?

Any more thoughts or ideas on this would be greatly appreciated

 

 

It is all in the follow through…


Accountability of others

Holding another person accountable can be a scary thing, even just saying that sounds a big deal.  And whilst it is a big deal, it doesn’t need to be scary.  Feedback is a skill, and it one that you get much better at the more you practice.

In theory feedback in the context of accountability should be the easiest kind.  Your work colleague or partner has made a commitment to you or to the team and in doing so they are implicitly inviting you to give them feedback if they stray from this commitment. Learning to give that feedback constructively and supportively comes with practice, and frequency. If you are giving feedback regularly it is easier to give and easier to receive, eventually it will become a normal and natural interaction on a team.

If they took an action item to do something by the end of the week a polite enquiry on their progress, may serve as a reminder that the task is important and that they have committed to it. There is no need for judgement or pressure and certainly no need to micro-manage. An offer to help or an enquiry if there are any impediments you should be aware of, or can assist with, should be sufficient to reassert the importance of the task and a reminder of the commitment made.

In most cases if someone has taken responsibility and committed to something, they will be happy to be held accountable, especially if you have established trust on the team and have decided as a group this is something important, a good team player understands that group decisions impact all of us and are in all our interests to get it done, so understand and expect you to have an interest in getting it done.

Holding yourself accountable

Holding yourself accountable is much harder, after all if we could see we were slipping we’d do something about it. Which is why it is so important to explicitly ask others to help you with this or to find techniques to help you stay focused on what is important.

accountability-breeds-responsibility1

Accountability techniques

There are a couple of very easy techniques for creating opportunities for holding each other accountable. If done right these should lead to more frequent feedback, if they become a constraint and feedback becomes limited to these opportunities then try something new.

A regular stand-up meeting

Get together with your team on a regular basis, a lot of teams find once a day is a good cadence, review priorities, objectives and actions, by sharing what you are working on and where you need help you are inviting input from others, if an action item is being neglected this is an opportunity to ask why or to remind others of the importance of it. Be careful this does not become reporting to someone, this is about sharing information and looking for opportunities to assist each other.

Make your work visible

Something like a Kanban board or a todo list is fantastic for sharing with your team mates what you are working on, you and they can immediately see if an action is not being given priority and can see why or what is.  If Kanban is used then priorities of work are clear and your policies are explicit, everyone is clear just by looking, what is going on.  The key to maximising the value of this is by ensuring it is used correctly, all tasks are on the board and you follow the rules, ambiguity can ruin this technique.

If combined with a stand-up it can enhance the effectiveness of both techniques.  Also whilst Kanban boards are great for team working, they also work well for an individual, many people find a personal Kanban board is a great way of keeping focused on what is important and avoids getting distracted by less important interruptions. and having it visible in a public space too will aid you holding yourself accountable to it.

Always review previous actions

At the start of a team meeting it is important to review the previous action items, and to not lose sight of any that remain outstanding. First the team should be focused on the most important issues, and actions should be the team’s collective view on how best to proceed. If as a team you don’t care enough to want to know how those actions turned out, you have to question your buy-in to those desicions or if your team is actually focused on the right priorities.

Was the purpose achieved?

Remember the reason for the Action item. I would also suggest that an action is the result of a discussion about resolving a problem, satisfying a need, or is progress towards a goal.
Taking some time not only to review whether the action was taken, but also to review whether it achieved it’s purpose would be valuable. It is quite common for an action to not have the expected results, and in that case the underlying issue still needs addressing.

Summary

Accountability should become routine, and we can all benefit from being held accountable. If it doesn’t become easier or routine then perhaps there are other underlying problems either with trust on the team or a lack of genuine commitment to decisions.

 

 

Related reading

This is the fourth post on the theme, the five dysfunctions of a team.

The others are available here:

Is it safe to dance?

Have you ever found yourself alone listening to music and you take a look around wondering if it is safe to dance?  Safe because your dancing is so bad it is unfit for other eyes, in fact it is so bad you are not sure you should look.  Perhaps your car is a little safer, it is a capsule of invulnerability, so when you are alone you can sing at the top of your voice and no one can see, or not until you stop at the lights and notice the person in the car next to you looking at you.

Feeling safe enough to be vulnerable is not easy even when you are alone, but it gets progressively harder when there are other people around. Now I’d never sing or dance in front of others, but the other day I found myself at lunch with four of my closest friends at work – if asked I would say I trusted the four of them a lot, I consider them really great friends, so I felt able to be a little bit vulnerable and I told a slightly inappropriate joke.This may not seem a big deal but I immediately became embarrassed I glowed red and went quiet for a while, I found vulnerability is tough even among such good friends.

Vulnerability is tough even among close friends

We all want to be liked and accepted, to be included in a group, and so it can be hard to be vulnerable, and yet the irony is that taking the step to show vulnerability may well be the step needed to make those friendships and your team stronger.

maxresdefault

Trust in a team

In a team environment it is so important that you can feel enough trust with ALL of your team mates that you can truly feel able to say things like:

  • I need help
  • I don’t understand
  • I disagree
  • I made a mistake
  • I find those tasks difficult
  • Show me how to do that again
  • I feel uncomfortable when you do that
  • I wanted to do the task you took
  • I am unhappy with this decision

But if I struggle to trust even my best friends, how can I possibly trust co-workers that I know much less, after all the same rules apply. I want to be liked and accepted, I definitely don’t want to look stupid or uncooperative, I don’t want to discourage others or waste time, I have a burning need to feel valued and part of the team. I need to show my worth to my boss, etc.

Is it safe to dance?

Essentially when you are part of a team you are asking yourself “is it safe to dance?”
If you keep that in mind it gets easier, what would make it safe to dance for you. For me it would take a lot!

I’d need others to dance first, probably all the others, but certainly the leaders, the people the others respect. I’d need to see that some were as bad as me, I’d need to see that no one was laughing at them (only laughing with them) and that everyone was encouraging and supportive, then and only then might I feel able to be vulnerable and join in, and frankly it would take a few repeats before I would truly feel comfortable.

We can dance if we want to, we can leave your friends behind
Cause your friends don’t dance and if they don’t dance
Well they’re no friends of mine…

dance

 

How does that relate to work?

You may think that dancing is not like working in a team and that the humiliation of dancing is far worse that simply doing your day job, but I think this is one of the reasons teams suffer from an absence of trust so often.  We dismiss both the importance and underestimate the difficulty of building trust in a team.

In a team environment you are sharing your ideas which are deeply personal, your knowledge and judgment which may be closely associated with your sense of self. Doing something wrong could affect your job, maybe even your career. Sure you may not look and feel like a buffoon but the stakes are much higher. And even if you get past the work related barriers you still have to contend with our inherent desire to be socially accepted, to be liked and valued.

So how do you build trust on a team?

Actually this is not that complicated it is not really any different to building friendships.

  • Spend time to get to know each other, take a few minutes during meetings to get to know each other, this is not waste, a few minutes spent building relationships could well be the most productive aspect of the meeting in the long term.
  • Chat over coffee and as you work – about personal stuff
  • Have lunch together as a team – this works best if the whole team is together.
  • Play games! One of the best ways to build relationships is to play a game something simple like a card game is great, it is inclusive and leveling, the most junior member of a team can challenge the most senior in the safe confines of the rules of a game this makes it much easier to discuss work ideas on a level playing field later.
  • Time, trust and relationships take time, do not underestimate it.

For all of these it works best if everyone is there to avoid creating pockets of trust which could undermine the team later.

trust-stones_480-300x200

The last one was time, and warrants an extra note. Building relationships is a slow process you can’t simply flick a switch, allow teams the time and space to grow the relationships will build and grow stronger and stronger, and once the team is stable changes can be made so long as a core remains to keep the identity and trust that has formed.

Trust takes time

dysfunctions

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility.  But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

You cannot uncover better ways to deliver software without first uncovering better ways to work as a team. And the basis for an effective team is Trust.

Building trust should be your top priority, spend the time, make the time, it is an investment in the future of the team. Without trust anything else you do will suffer.

Without trust anything else you do will suffer.

Take the time to build trust on your team, make it safe to dance.

 

 

When does coaching end and doing start?

“Coaching is unlocking people’s potential to maximize their own performance. It is helping them to learn rather than teaching them.” ― John Whitmore

Coaching is an interesting and confusing notion, as an Agile coach in my current role we must be explicitly invited by a team or an individual to coach, usually this is driven by an awareness of a specific problem or a general desire to improve in some area.  The goal of the coaching is to enable an individual or team to solve the problem or to provide structure and support to enable the learning.  The goal is not for the coach to solve the problem.

The goal is not for the coach to solve the problem, the goal is to coach you so that you can solve the problem.

I have reiterated that because it is so critical and so confusing. A team has asked for help with a problem and you are not going to solve it?   In fact you may actually let them fail and watch them flounder – how is that helping?

This essentially gets wrapped up in the whole “Give a man a fish” thought process, a coach wants to equip the team or individual with the skills to solve – not just this problem but the next problem and the one after that. A coach may very well know an answer to the problem described, but the agenda of a coach is to grow the team into being able to solve the problem, or at the very least to understand why a particular solution may be appropriate.  This can lead to confusion and frustration especially if the problem is causing pain or costing money. The team often want the problem solved far more than they want to learn.

A coach may ask questions that guide thought processes or sow seeds of ideas, they may point out smells or examples of behaviours that may be dysfunctional and warrant further thought, all this is intended to focus attention where it can have the most impact, but all without without explicitly solving the problem.  But when the team doesn’t understand this relationship it may appear that the coach is not helping, after all the coach may appear to only identify problems and doesn’t offer solutions.  This a common failing of coaches and of me in particular. There is a certain irony that one of the most common coaching guidance I give is around getting to understanding the why of a situation but I sometimes miss explaining this vital information when it relates to my coaching.   But when you coach multiple teams it is very easy to assume that everyone understand the coach relationship and this can lead to confusion and frustration.

file-21-09-2016-15-57-29

Coaching example

A very useful example is a situation where two people on a team are having interpersonal issues, Wendy continually leaves a mess at a pairing workstation and this drives Paul crazy, he gets frustrated and seeks out a coach and asks the coach to help. The coach will very likely ask if Paul has discussed this with Wendy and if not why not. Paul may ask the coach to speak on his behalf or to mediate, but again the coach may suggest that Paul should act alone. The coach may offer guidance on how to have difficult conversations (There is a great book on this subject: Crucial Conversations) but it is not the Coaches’ role to be mediator or to engage in conflict resolution.  If the matter is more serious they may refer the issue to HR just as any one else might but it is not the Coaches role to solve the problem or to get involved, merely to equip the person with the tools necessary to solve their own problem.

Levels of Coaching

If you consider the coaching on a one-to-one level it may be easier to see how the different levels of coaching are applied and when or why different techniques are applied.

If we take writing a first draft of a user story as an example.

  1. At one end of the spectrum the coach could ‘teach’ or talk about general story writing techniques and practices and give examples.  (Teaching) abstract ideas – blogging, courses, lectures, presentations etc
  2. Or it might be useful for the person being coached to work through a generic example with the aid of a coach (Training). Workshops or interactive activities such as games.
  3. Or it might be useful for the person being coached to work through a real example with the coach available to ask questions or the coach asking questions and offering encouraging ideas (Coaching/Consulting/Advice)
  4. In some cases the coach may sit with the person being coached as a partner sharing thoughts and ideas in a balanced way sharing the work (player coaching/mentoring)
  5. At the other end of the spectrum it may be that the coach actively participates in a pairing situation and shows the person being coached what is being done and explaining why.  – At this point the line between coaching and doing is a line in the sand and depending on the engagement level of the person being coached the level of learning and improvement may be negligible.
  6. And finally the coach does the work on behalf of the team/individual even though the team could do it for themselves. At this point there is no coaching value at all.

coaching

Of these five levels most Agile Coaches operate at levels 2 and especially 3, occasionally in 1 and 4, but 5 is unusual, certainly in my current role we explicitly say that we shouldn’t ‘do’ and if we stray we should be aware that we are no longer coaching.  In contrast a Scrum Master spends more time at 3 and 4 and often at 5  or even 6 – resolving impediments, producing metrics etc. But the overlap between the roles is subtle and there is no hard line. It is more a question of the intended outcome, rather than how it is achieved.

Reality

Of course the ideal and the reality can be quite different, I have been giving some product owner coaching recently and this is a double edged sword, the product owner aspect of software delivery is one of my favourites and I get enthusiastic. So I have been helping write story maps, and identifying personas and writing stories but every once in a while I’ll start doing, throwing out my ideas, making corrections without discussion and my biggest sin, taking over at the keyboard!  Thankfully usually one of us will spot it quickly and non-verbal cues will put me back in my coaching box.

My summary is really that not understanding the goal of the coaching leads to all sorts of problems, the teams facing a particular problem may feel they are not getting the assistance they need. It may be difficult to measure whether a coach is effective when they go out of their way not to ‘do’ something. The role is both very broad and very misunderstood.

But when the role is understood and when those being coached understand the relationship and the value of it, the situation changes drastically. It is a hugely rewarding role and the relationships can be fun and fruitful. When you accept that you are expected to solve your own problems (with guidance) it can be very empowering, a coach becomes someone that can help YOU expand YOUR understanding and ability, but credit belongs to you, not to the coach, they just point the way – you have to do the work.

Typical interview styles

The interview itself.

What I have observed is that interviewing is generally composed of one or more of a very small number of techniques:

  1.  Free-form, gut-feel unstructured or semi-structured chat and questions between candidate and hiring manager.

  2.  More formal pre-defined questions structured and consistently asked to all candidates.

  3.  Some variety of standardised test, essentially IQ based.

  4.  Questions posed by a technical expert with a desire to highlight his superiority rather than assess your capability.

  5.  A technical test or series of technical questions intended to be pragmatic and fair.

  6.  Aggressive panel questioning

  7.  Psychometric testing: verbal/numeric/diagrammatic reasoning or personality tests.

  8.  Presentation by interviewer on why the candidate should work for you.

There are studies and statistics that rank the effectiveness of the different techniques for selecting good candidates, I won’t pour them out here – I am not an expert and I’d just embarrass myself. But in my experience 1 is the most common, often combined with 4 or 5. But logic states that 4 is a waste of time and puts off candidates, and studies show that 1 and 5 are actually very, very poor indicators of ability and capability for the role and do not result in long-term success.

So what works? 

2, 3 and 7 are by far a better method of assessing candidates, followed by an independent panel-decision based on the documented evidence taken from the interviews – the interviewer should not be allowed to make the decision independently as they display bias (subconscious or otherwise).

But 2, 3 and 7 are hard, it requires yet more work on what is already a tough and time-consuming process, so very rarely gets done.

The reciprocal nature of an interview (8) is so often overlooked, if you want the best people and you want to get the best out of them, then not only do you need to decide if they are right for you, you need to convince them that your business/team is right for them. You should be putting as much effort in to impressing candidates as they put into impressing you. You are competing for them in a buoyant market.

recruitment2

Doing it right.

As an interviewer, my best experience has been for a company that did a combination of 2, 3, 7 and 5. We put a lot of effort into interviewing, but the majority of people still failed the combination of tests, especially the technical test. The test felt ‘easy’ to us and some candidates did well, but the results didn’t match the apparent skills of candidates, in hindsight I think it confused the process. The problem is that technical tests are not effective at assessing ability during an interview, there are simply so many other factors at play.

Relying on structured questions, IQ tests and psychometric tests may feel clinical and impersonal, but very likely the best way to find the right candidate. But ego plays a role and when hiring for a team, we are only human and so many hiring managers want to rely on their own instinct, even if evidence demonstrates this is unreliable, so it is hardly a surprise that many hiring managers favour their instinct over a structured process.

To be the best, hire the best… for you.

I have recently been reflecting on the impact of our choices when hiring new staff. Over the last few years hiring has been a major activity for me, and so I am particularly interested in what the impact of these hiring decisions has on the team and the organisation.

I have a number of experiences that I feel are relevant and two particular opinions I have recently heard that I would like to discuss.

The first was from a blog post: http://zachholman.com/posts/0x-engineers/   in this the author is critical of everyone chasing after the type ‘A’ engineer, it makes an interesting read and refers to a popular belief that the good software engineers are worth 10x as much as the ‘average’ engineer.  I don’t intend to get into the basis or accuracy of the claims, but I am satisfied that it is a generally well accepted opinion that there is a significant difference in ability, and value of output between those deemed average and the top end of the scale, I have heard figures ranging from 10x as valuable to 1000x as valuable from quite well respected authors.

But ultimately the author compares software engineers to restaurants and concludes that most of the time he would be content with an average restaurant as we can’t always all eat in the best restaurants.  This is the point where I try hard not to be dismissive. The analogy is suggesting that most of us are content with ‘Good’ food and don’t need ‘Great food’ but the reality is that we are not only comparing quality, we are comparing relative quantity AND quantity, if we use his 10x value estimate then what we are comparing is a 1/10th of a ‘Good’ meal to a whole ‘Great meal’  We’d need to eat (and pay for) 10 ‘Good’ meals to get the same quantity/quality (value) of food.

He does have some good points about a good team being better than a star player and I’ll come back to that but I for one am not content with a tenth of a meal.

By contrast I looked at Work Rules! by Laszlo Bock (SVP People Operations at Google)

Lessons from WORK RULES! include:

* Take away managers’ power over employees
* Only hire people who are smarter than you are, no matter how long it takes to find them
* Pay unfairly (it’s more fair!)
* Default to open: be transparent, and welcome feedback
* If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

Laszlo advocates hiring only the best, by hiring the best you get the best output, you certainly have to pay more but you don’t have to pay 10x the salary to get a 10x software engineer, it makes financial and practical sense, a small team of high achievers must be amazing and they clearly are for Google. But…

Here is where the real word kicks in.  Most of us don’t work for Google or Apple, we will not attract the best of the best, most organisations are unable to employ an entire team of 10x engineers, many of us are lucky to hire a few high achievers, when location, salary, benefits, and image are factored in, we can be selective and choose the best of what is available to us, but a good engineer is hard to find.

So I am saying that I don’t want a team where the primary qualification is a pulse, and I am highly unlikely to be able to hire (and retain) an organisation full of 10x engineers.  My world is the grey area somewhere between.

This brings me to what has been an inevitable consequence of the real world – a mixed team.  I didn’t like the restaurant analogy so I will go with cars.

cars

Lets say I have a team of five developers, as a very general rule a team will travel at the pace of the slowest member, and whilst you may be able to improve the speed of the slowest a little, the high performers are stuck at the slowest speed and may well be getting bored and frustrated.  It is no good one or two members zooming-off, knowledge doesn’t get shared resentment grows and very quickly you are at a standstill with a dysfunctional team. An effective team moves at one pace – the pace of the team, and as the original blogger wrote, a team that works well together can actually be far more effective than a single star player.

And this is where things get more messy, as either a Scrum Master or a Department Manager the goal is the long-term development of the team, I value all the team and I’d like to see everyone have the opportunity to develop and get better, a single star-player held back is bad, I don’t want to see that, but equally I am aware that an effective team can be amazing, and then again a dysfunctional team is a disaster. I want to grow and build a team that are greater than the sum of their parts not a group of individuals moving at the pace of the slowest.

So I find myself both agreeing and disagreeing with Laszlo, yes I want a group of the best engineers, but that isn’t going to happen, I don’t live in silicon valley and I don’t have that budget, and even if I did then I’d still prefer a great team of engineers. I believe that a team working well together can achieve far more and far better software than even ’10x’ individuals.

I aim to get that by hiring for the team. I will still aim to hire a team where they are smarter than me if I can but my primary goal is to find someone good that will enhance the existing team, that means I value the ability to communicate over their technical depth, I value their willingness to learn and to question over their certainty of their own knowledge, I value a desire to give customers what they want over a desire for a perfectly engineered solution. I suppose I am saying I value the team over individuals – even star players.

But I have a dark side too, anyone that is holding the team back needs to go, whether they are disruptive or not pulling their weight or simply because they don’t mix well with the others. I think we should be aggressive in hiring the best people for the team but equally aggressive in removing obstacles whatever form they take even if it means changing the make-up of the team.

I don’t want to close before addressing the other items on Laszlo’s list.  I want to voice my agreement over the other points,

* Take away managers’ power over employees

It really makes no sense to hire smart people and then tell them what to do, we hire smart people because they know more than us in their area of expertise – Let them use it!

* Only hire people who are smarter than you are, no matter how long it takes to find them

I agree with the caveat mentioned above, we don’t all have that luxury and for the most part it depends heavily on the next point.

* Pay unfairly (it’s more fair!)

Double what you are willing to pay and be selective. But don’t stop there! Retention is as important as recruitment, don’t lose someone good by being stingy, if you discover you have hired a star, give them a pay raise immediately, I can guarantee that when they go it will be for only 5%-10% more than you currently pay – don’t let that happen and offering to ‘match’ after they have one foot out of the door is far far too late. Let them know you value them now and make it hard for a competitor to lure them away.  Don’t worry if it upsets other people, if they know that reward is based on ability and performance they will respect it even if they don’t like it.

* Default to open: be transparent, and welcome feedback

I am a huge believer in transparency in development, so many projects fail because problems were hidden ignored or deferred or where customers were excluded until it was too late and too costly to change. Be honest and open and learn to see that finding a problem early is a good thing, even if you’d prefer not to hear it.

 * If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

This goes with the first point but let the team lead the way, they likely do know best, and make work a place they want to be, if a team of engineers is happy and enthusiastic you will see an amazing improvement. And trust them.

Trust the team

I shall add that as my own piece of advice for success with software development.  Trust the team, trust their judgement, trust their opinions, trust their concerns and trust that they will do the right thing. In my experience a good team will reward that trust ten-fold.

In my opinion if you cannot Trust your development team it is a failure of management as you have hired the wrong people.