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. \n\nThat\u2019s all well and good unless they\u2019ve lost sight of the bigger picture.\n\nWhat\u2019s an IT leader to do?\n\nThe 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.\n\nCultivate business awareness\n\nOne 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\u2014and challenging\u2014when working with developers because their work is so demanding of careful, focused attention. \n\nDevelopers 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.\n\nThis is a delicate task. \n\nAsking 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. \n\nThe 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.\n\nCultivating developers who have both technological excellence and business awareness is a hugely precious thing to the leader, the business and the developer. \n\nConvey meaning\n\nAlthough strategy and business value are valuable to communicate to developers, there is an even higher thing which we\u2019ll call purpose or meaning. The strategy is engaged to support the mission. The mission is the raison d'etre for the company itself. \n\nDoes 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\u2019s activity.\n\nDevelopers 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. \n\nThe key to delivering meaning to developers is to understand the next point about creativity\u2014and 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.\n\nFoster creativity\n\nDevelopers\u2019 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.\n\nJust 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.\n\nPerhaps 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.\n\nDevelopers 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.\n\nAllow space for failure\n\nDespite their mastery of complexity, developers are prone to feeling like they are not really up to the job at hand\u2014the strange phenomenon known as imposter syndrome.\n\nThis 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.\n\nEvery leader's style is different, of course. So is every developer\u2019s. 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.\n\nEven 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. \n\nIn 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. \n\nThe 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.\n\nEncourage taking breaks\n\nHere 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\u2019t be solved with faster shoveling and hammering.\n\nKnow when to encourage a break. It\u2019s 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.\n\nDevelopers 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.\n\nEven 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. \n\nSometimes what seemed like a systemic shortcoming\u2014a flaw in the design perhaps\u2014turns out to be a face-palm like a botched variable capitalization.\n\nBy 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\u2019t 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.\n\nProvide balance\n\nDevelopers 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.\n\nInternally, 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. \n\nIf 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.