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’t want to abandon the practice that frankly brings them fulfillment.
Enter the coding leader.
This 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.
By 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.
And 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.
Myth: Programmers can’t be good leaders
The coder’s 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.
The perennial danger for the engineer is in becoming obsessed with building things, losing sight of the business value of what they are doing. I think of this as the Bridge on the River Kwai blunder, where the character’s temporary technical task (the building of the bridge) comes to eclipse the much higher purpose (overcoming the imperial occupation).
But 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.
The 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—something akin to a work/life balance, where both have equal claim to attention.
The 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.
That includes, of course, the job of guiding the humans in the business.
Myth: Coders are bad with people
It’s such a hackneyed notion. It’s also somewhat true.
Machines 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.
Some 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.
For 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.
The beauty is that the coder has a vast advantage in leading other coders and tech personnel.
Coding leaders are “one of us”
Every programmer will recognize this scenario: The project manager saunters in and makes preposterous projections based on their Gantt chart. Or even more cringe-worthy, begins abusing buzzwords. To communicate the business needs to the builders in an effective way is a special art. To be an effective bridge between the two is even more precious.
There’s 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.
There 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.
While 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’s willingness and ability to jump into the thick of things.
That kind of respect and fondness translates to the software world, where the leader is seen as “one of us.”
Should the leader keep coding?
In writing about his own experience as both coder and manager, Mark Porter, CTO of MongoDB, says “There are many types of CTOs. A CTO at a small company who is leading the development of the company’s first product should absolutely code. A CTO who is focused on outbound activities for a major firm should not.”
This 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.
It’s 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.
In 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.
The 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.
When 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.
As to the question, shall I be a manager or a coder? Maybe the answer is: both.
