- Schneider Electric ousts CEO over strategic differences
- Pakistani Hackers Targeted High-Profile Indian Entities
- The 2-in-1 laptop I recommend most is not a Dell or Lenovo (and it's $200 off)
- Los CIO buscan perfeccionar la gobernanza de la IA a pesar de las dudas
- Chinese Air Fryers May Be Spying on Consumers, Which? Warns
6 tips for successfully leading software developers
Developers are notoriously grumpy and unamenable to disruption. They tend to want to continue working until they arrive at a place of completion and satisfaction.
That’s all well and good unless they’ve lost sight of the bigger picture.
What’s an IT leader to do?
The following perspectives will help you better understand what motivates and mystifies developers and can guide your thinking on how to be the leader your team needs.
Cultivate business awareness
One of the critical tasks for all leaders is to provide an overhead strategic vision to the people who work on the lower-level tasks. This is especially important—and challenging—when working with developers because their work is so demanding of careful, focused attention.
Developers are required to master an enormous amount of complexity that can squeeze out the larger context, resulting in a kind of myopia. The work itself is enough to occupy even the most ambitious and active mind, so it becomes especially important for leaders to provide the two-way channel between the daily coding and the larger direction.
This is a delicate task.
Asking for progress reports or offering direction or, worst of all, changing course, are all typically most unwelcome. In some cases, these are actually very disruptive, but in others, they are exactly what is needed.
The right way to engage developers in strategic dialog is in a balance. Here is where meta-engagement is important. Asking developers about how the meeting load is, and how well they feel engaged in the larger goals is a good way to tune the balance. It also helps to get them thinking about the bigger issues.
Cultivating developers who have both technological excellence and business awareness is a hugely precious thing to the leader, the business and the developer.
Convey meaning
Although strategy and business value are valuable to communicate to developers, there is an even higher thing which we’ll call purpose or meaning. The strategy is engaged to support the mission. The mission is the raison d’etre for the company itself.
Does the company have a potent mission statement? Is the essence of the mission well distributed into the ranks? The rightness or goodness of the enterprise should be infused into everyone’s activity.
Developers are especially tricky, as they are typically rather resistant to what they often cynically see as indoctrination. Nevertheless, the sense of legitimacy is just as necessary for long-term developer contentment as anyone else.
The key to delivering meaning to developers is to understand the next point about creativity—and integrating it. The inherent worth that developers derive from coding can be integrated with the larger business purpose. Uniting meaning and creativity is a major source of a drive for excellence for developers.
Foster creativity
Developers’ will to create is strong, but it can be hard to perceive as creativity is often obscured by the technological nature of development. Developers communicate with a strange patois of acronyms that hide the artistic spirit behind it. Learning to perceive and nurture that spirit is a special kind of leadership that developers will appreciate.
Just the awareness of the creative life of developers is important. Not only will it help to understand where they are coming from, but it will lead to policies and decisions that support that creativity and out of that will come real bottom-line benefit. The space and time to innovate will lead to better software that handles the vicissitudes of business. You need the human creativity of your developers captured in the half-machine/half-thought medium of code to be agile.
Perhaps the most important feature for the leader to bear in mind here is in realizing the attachment that developers have to their work. Affection might be a better word than attachment. Building a thing that feels beautiful and worthy in itself has its own momentum. Interrupting this momentum should be undertaken with a soft touch, rather than as if switching tabs in the browser. If possible, a gradual readjustment is best.
Developers work with machines, but they are not themselves machines. At the same time, improving developers’ understanding of the larger context as discussed above is greatly helpful in bringing out an understanding of the necessity for redirection, tuning, and planning. This understanding helps to ameliorate the frustration and feeling of senseless churn.
Allow space for failure
Despite their mastery of complexity, developers are prone to feeling like they are not really up to the job at hand—the strange phenomenon known as imposter syndrome.
This kind of insecurity is more common and sensible with green developers, but you would be surprised at the accomplished programmers who still acknowledge running into it. Even coders coming from great success can find themselves burdened with uncertainty about their ability to handle the next thing confronting them.
Every leader’s style is different, of course. So is every developer’s. Instead of a hard and fast rule like avoiding harsh criticism or promoting recognition, it’s good to simply bear in mind the kind of difficulty developers wrangle with in their daily work. The path of execution is rarely a straight line for a developer. They frequently must call upon an inspirational force to get there, and this can be frightening when deadlines loom.
Even if you think there is no way that a person is uncertain about their ability to execute, it’s helpful to remember that at some point they were. They are confident because they have come through it and developed mechanisms for dealing with it.
In addition to awareness on the part of leaders, a good approach to helping is to encourage communication between developers as described in this Tweet. In short, encourage senior developers to share their experience with juniors, especially with a willingness to acknowledge mistakes.
The ability to air mistakes in a safe environment is therefore an important thing for leaders to cultivate. Provide the ability to fail forward, with a sense that guardrails are in place, and developers will thrive. Failure is an important part of all enterprise and innovation, and especially so for developers.
Encourage taking breaks
Here is a practical insight: When you have developers who are facing blocks, they have a tendency to beat their heads against the wall of impasse. Usually, the block is a creative one that can’t be solved with faster shoveling and hammering.
Know when to encourage a break. It’s counterintuitive, but so many times the breakthrough a programmer is looking for is not to be found in working harder but in getting some distance from the problem.
Developers themselves frequently miss this point. In fact, they will actively resist it when they are in the grips of a tough challenge. They believe that continuing to grind away at the thing is the path to a breakthrough.
Even though time and time again they will struggle against a seemingly intractable difficulty, believing that further effort will yield result, only to take a begrudging pause in the effort and then suddenly envision how the whole issue can be resolved. Like a stroke of lightning, everything crystallized and seemed so obvious.
Sometimes what seemed like a systemic shortcoming—a flaw in the design perhaps—turns out to be a face-palm like a botched variable capitalization.
By being outside the trenches, you can help keep in mind what the developers themselves forget: the non-linear nature of their work. Success is a union of effort and creativity. Sometimes the goal can’t be reached by further direct effort and must await more insight. Be a leader who can help remember this and your developers will thank you.
Provide balance
Developers suffer from discontentment, stress, and burnout at a high rate. Whatever you can do to mitigate this is welcome. Developers do it to themselves and also are subject to external pressures. Both of these forces can be addressed by leaders.
Internally, developers suffer from a kind of obsessive tendency about programming. In some ways this seems beneficial for the enterprise: Keep the devs caffeinated and coding. But predictably, that is a recipe for burnout.
If you can be the voice of balance in developers’ work lives, you will benefit both them and the business. The best way to do this is to be a softening shield when bridging between them and the pressures of the business. Often, it’s not more pressure but a sense of support and guidance that is most in need.
