Adding a star developer or architect—from here on we'll just call them a "star"—to the team does more than improve your organization's productivity by the amount that star can do. A halo effect often occurs where the existing developers on your team begin to improve their effectiveness too. This halo effect can be either amplified so that nearly every person on the team becomes better, or it can be isolated so that few, if any, people are affected by it.
To get the most out of your star developers and other team members, you'll want to amplify the halo effect. In this document you'll learn how to identify the halo effect, understand it's potential, how to amplify its effect, and how to convert the halo effect into a permanent change even after the star developer has left.
Understanding the halo effect
A friend of mine and I were talking before her wedding which occurred a few years back. It was important to her that she be able to do ballroom dancing for her first dance with her new husband. She had been taking dance lessons and she related how when she danced with her instructor her dancing was much better than with her husband and she didn't understand it. When she asked her instructor about it he told her that she was able to dance better because his leading was better. That with strong leadership she was able to follow clearly. Her future husband was a good, but not professional dancer, and so his leading wasn't as strong or assured. Although their first dance turned out fine, she learned first hand about how a "star" can artificially increase the effectiveness of her dancing.
In software development it isn't the strong leading of steps that causes the effect. Instead, the halo effect happens in part because through casual conversations the star causes the other developers around them to think in ways more conducive to finding a solution. It isn't so much the person around whom the halo is formed is giving specific guidance, directing tasks, or doing the work. They are instead simply pointing others in a direction that they know will work better. This helps prevent other members of the team from wasting time trying techniques which won't work – or which will require substantial amounts of effort to be successful.
A star person who is cognizant of the halo effect is careful to cultivate it whenever possible. They make sure they make themselves available. They don't insist on specific approaches, they casually mention approaches which have worked for them in the past. They're curious about the problems that other members of the team are working on.
Imagine for a moment how much faster you could get across a large town if every stop light was green for you. How much better does your day go when things fall in place – rather than you having to struggle to get things done? The same basic thing happens with star people. They are capable of helping the team around them without the team even understanding that they are being helped.
The halo effect also occurs because other members of the team can ask questions and get quick or immediate answers. Debugging sessions are reduced because the good developer knows tricks to make the process easier. In dozens or hundreds of small ways the star developer impacts small decisions to create a cumulative effect.
In nearly every case, the halo effect operates due to casual, informal, and frequent interaction with the rest of the team. The effect is directly proportional to the amount of openness there is with the team, and with the amount of time they are allowed to interact with the team.
A word about being a star
I launched into this discussion without much of a definition of a star developer. This was necessary so that we could focus on the halo effect; however, by now you have likely identified someone who's a brilliant developer and who has never been able to create a halo effect around them. They are loud, aggressive, and inflexible.
One of the differences between a brilliant developer and a star developer is that the star developer is attuned to the halo effect and strives to support the development of that halo. They have a passion for helping people learn more and become better developers. They are not self-centered, consuming of all of the oxygen in the room. They listen and wonder, rather than pontificate and spout their own laws of the universe.
So, it is possible to be a good developer or architect and yet not be capable of generating a halo effect. It is far more likely that a star developer will have some halo effect around them, the primary question will be how much of a halo effect are they generating and where is that halo effect being realized?
An interesting sidebar is that the halo effect doesn't have to be caused by a star developer that you employ. The interactions with a star developer are more important than what the business relationship is. Mentored development contracts with consultants can help internal developers dramatically improve their skills.
Getting more for less
The law of conservation of energy says that energy is neither created nor destroyed. That might make one think that there's no way to "magically" create a more effective development team. While it's true that energy can't be created, it is also true that there are ways to get more energy out of your developers. Like a catalyst that speeds the conversion from one chemical structure to another, developers can be simulated to be more productive – and star developers can be supported in ways that make the halo effect more pronounced.
One of the best ways to support the halo effect is to create more informal communication times. This might mean bringing in pizza for the group, coordinating a lunch outing, encouraging the group to get together after work for drinks (non-alcoholic or alcoholic), and other opportunities to get the group together in a non-structured, non-work situation so they can talk about the challenges they are having and get to know one another better, so that its easier for causal conversations to happen.
Generally speaking the more cohesive the team, and open to growing, the quicker they accept new members the quicker you'll start to see the impact of the halo effect. Teams that are already open to new ideas and sharing will quickly integrate the star and take advantage of the halo effect with little or no prompting and minimal skill on the part of the star to encourage the halo.
Another approach is to help the star understand the halo effect and how it helps the organization. By explaining the impact the effect is having on the organization, and how the halo effect works they can be encouraged (or "incented") to cause these behaviors to happen more often. By encouraging the causal conversations you can increase the effectiveness of the halo effect. Most star developers keep tight reins on the amount of non-productive time that they have. The trick is trying to demonstrate the value of some of these informal interactions so that the star developer will want to have more of them.
Depending upon the team it may even be possible to explain the halo effect to the entire team, to help them understand how to better use the halo and how they might create their own halo. This technique is sometimes risky because every member of the team will think they are the star and they will all start helping each other out until nothing gets done.
Managing the ripples between two halos
Thus far we've been talking about the impact of one star developer, however, as the team grows it's likely that another star will develop or it will be necessary to bring in another star from outside the team. The dynamics of having two stars in close proximity can be devastating.
If they are allowed to create fiefdoms in the team they will eventually rip the team apart. Any small discrepancy between the views of the two stars will be radically translated into the team. Because of this it's critical that the stars on the team are allowed their own time to coordinate, to communicate, and to move their perspectives closer together – not further apart.
Coordinating two (or more stars) is very challenging and potentially volatile. Some relationships form normally without much indication that it has happened while others are born only through some heated discussion with real sparks flying. In the end, there is no formula to making two stars work together, nor is their any guarantee. All you can do is to enable the right opportunities for the stars to develop together.
Making the halo effect last
Nothing lasts forever. That's a fundamental law of the universe. Everything is in a state of flux, a state of change. Because of this, it's impractical to believe that you'll always have your star to lean on. If you accept that eventually they will be gone you can prepare the organization for their loss by solidifying the permanency of the halo effect.
One effective way of stabilizing the halo effect to make it more permanent is to disrupt the normal flow of the effect. Once the halo effect has clearly taken hold, interrupt its flow for small periods of time to create a contrast between having help and not having it.
It's odd that creating a lasting effect requires that the effect be removed at random intervals so that the loss is experienced. There is definitely some truth to the song lyrics that say you "don't know what you've got until it's gone." The periods of time don't need to be long. A week long off-site, out of contact type project from time-to-time can be enough. It does, by the way, need to be an out of-contact week.
When the star returns from being unavailable, it is important that an emphasis be placed on how the team could have (and perhaps should have) gotten the information on their own. This begins the process of "teaching them how to fish" instead of "giving them fish." It's critical for the long term resiliency of the halo for each member to internalize the benefits they are getting from the star developer.
Another approach to this internalization process is the same concept that drives those "What would Jesus do?" wrist bands that were so popular for a time. (Most frequently they would be WWJD rather than the whole saying.) They were designed to remind Christians to think as Christ would have thought and to do what Jesus would have done. Of course, no one today knows precisely what he would do when faced with our situation, however, we can think about the intent that was demonstrated and be concerned with the concerns he expressed an interest in. Similarly, but with much less grandeur, teams can be asked to do a role play of the star to offer up similar questions, concerns, and thoughts.
Something that is a staple for making the halo effect last is identifying behaviors that are changing – and support the change. If developers seem to do a bit more research but spend less time doing construction after the introduction of the star – don't try to squeeze the time spent on research. It may be that this behavior shift is one of the improvements you've seen. Less rework since the developers more firmly understand what they're doing before they start.
The final thing that you can do to make the halo effect last is to keep the star around as long as possible. While no star performer can be expected to remain with the organization forever, the longer they are around the more ingrained they can make healthy habits that will serve after they're gone. There's no set formula for how long the star must be present to create a sustainable effect. The probability does, however, improve with the longer the person is present.
Find your star
The halo effect can have a substantial impact on the effectiveness of your developers. It can be those dozens of small changes and benefits that propel the group forward and mean the difference in the productivity of your organization. However, creating the halo effect and facilitating it takes not only the star developer but also an awareness of what the halo effect is, and how to make it persistent. Find your star, encourage them to shine.