Many of the leaders in the software industry come up from the ranks of working developers. They often want to expand into management as their mastery of technology gives them the confidence, but they don\u2019t want to abandon the practice that frankly brings them fulfillment. \n\nEnter the coding leader.\n\nThis new kind of leader is responsible for both strategy and being hands-on with the tech and walks in the worlds of business and technology with equal aptitude.\n\nBy staying up to date with the practice of coding, these leaders maintain insight into the workings of the projects, stay on top of industry developments, and can perceive where changes can best benefit the organization. \n\nAnd this trend may help to address one of the most niggling problems in the software industry: the feeling among developers that they are saddled with poor managers.\n\nMyth: Programmers can\u2019t be good leaders\n\nThe coder\u2019s daily work is often detailed, line-by-line stuff to be sure, and it can tend towards thinking about the trees more than the forest. \n\nThe perennial danger for the engineer is in becoming obsessed with building things, losing sight of the business value of what they are doing.\u00a0 I think of this as the Bridge on the River Kwai blunder, where the character\u2019s temporary technical task (the building of the bridge) comes to eclipse the much higher purpose (overcoming the imperial occupation).\u00a0\n\nBut as developers grow in their role, their vision encompasses more of the systems and processes at play, with understanding of the individual elements. As a skilled developer becomes really experienced, especially when their knowledge of the specific system under development becomes expansive, they are able to dip into high-value areas, assist with making changes, and maintain the high-level view. Adding to this an appreciation for the business side of things makes for a potent combination of talents.\n\nThe mindset change that is required of coders here is to allow for a true balancing of priorities. While working developers may tend to see anything but actual coding as simply an interruption, successful coding leaders can hold the importance of both business and technical needs in mind\u2014something akin to a work\/life balance, where both have equal claim to attention.\n\nThe coding leader knows how to keep a broad perspective that incorporates both the trees and the forest, how to shift between them, and, especially, how to allow the two to inform each other so insight flows between them.\n\nThat includes, of course, the job of guiding the humans in the business.\n\nMyth: Coders are bad with people\n\nIt\u2019s such a hackneyed notion. It\u2019s also somewhat true. \n\nMachines are logical and amenable to being coerced into doing exactly what you want by telling them in just the right way. People are not. There is something different in kind about leading people. As the programmer evolves from doing stuff, to leading other people doing stuff, to leading people leading people doing stuff, this distinction is magnified.\n\nSome folks just have a knack for people, how to elicit from them their needs, fears, and desires; how to perceive where the personality conflicts arise; how to see where they can grow; and how to effectively engage with these forces to help them and the business succeed.\n\nFor the rest of us, these are learned, sometimes hard-learned, skills. Coders are no different. By acknowledging the importance of human interaction, the coding leader undertakes to gain insight and skill, just as they did when writing a for-loop or functional component was intimidating and foreign. The inner workings of the corporation are just as astounding as the internet.\n\nThe beauty is that the coder has a vast advantage in leading other coders and tech personnel.\n\nCoding leaders are \u201cone of us\u201d\n\nEvery programmer will recognize this scenario: The project manager saunters in and makes preposterous projections based on their Gantt chart.\u00a0\u00a0 Or even more cringe-worthy, begins abusing buzzwords.\u00a0 To communicate the business needs to the builders in an effective way is a special art.\u00a0 To be an effective bridge between the two is even more precious.\n\nThere\u2019s no substitute for the actual experience of wrangling silicon into compliance. This translates not just into a deeper empathy for the technological work being done, but for the special joys bestowed upon and tolls exacted from people by the profession. \n\nThere is a great deal of value to be found in keeping alive the knowing what it's like to be in the trenches. The ability to put oneself into the shoes of the working coder is certainly a big piece of the puzzle in improving the perceived and actual performance of tech management.\n\nWhile researching and thinking about this issue of coding vs. managing, I happened to bring a car to the mechanic. The shop was a big operation, but I watched the owner walk out to a car and crawl under it to help diagnose a problem. There is a certain respect that comes from the engineers with a leader\u2019s willingness and ability to jump into the thick of things. \n\nThat kind of respect and fondness translates to the software world, where the leader is seen as \u201cone of us.\u201d\n\nShould the leader keep coding?\n\nIn writing about his own experience as both coder and manager, Mark Porter, CTO of MongoDB, says \u201cThere are many types of CTOs. A CTO at a small company who is leading the development of the company\u2019s first product should absolutely code. A CTO who is focused on outbound activities for a major firm should not.\u201d\n\nThis is a realistic acknowledgement that of course there are roles that demand the person filling it let go of hands-on coding, but there is also a place in the world for people who love coding, who want to continue being involved with it, and also grow into leadership. \n\nIt\u2019s not difficult to find even prominent leaders with deep hands-on technical knowledge these days. Werner Vogels of AWS and Brendan Eich of Brave, for example, give every indication of knowing and caring about the kinds of specifics that hands-on developers are concerned with. \n\nIn the realm of technology tools this kind of expertise is even more valuable. Not only is the coding leader better able to relate with the in-house developers, but with the customers, as well.\n\nThe coding leader demonstrates that a programmer is like a classical musician, rather than a football player or a fighter pilot. A classical musician may grow into a conductor who sustains their instrumental prowess to improve their work.\n\nWhen considering the weighty question of career paths, the notion that one must choose an either\/or path forward of practicing coder or IT leader is becoming less concrete. It can perhaps be seen as a spectrum, instead of a disjunction. At one end is the pure business leader, at the other, the pure engineer. Most CIOs, CTOs, or other tech leaders will blend some of both aspects, with the coding leader falling more into the middle of the spectrum.\n\nAs to the question, shall I be a manager or a coder? Maybe the answer is: both.