Many of the leaders in the software industry come from the ranks of working developers. They often want to branch out into management as their mastery of technology gives them confidence, but they don’t want to give up the practice that frankly brings them satisfaction.
Enter the coding leader.
This new kind of leader is responsible for both strategy and being hands-on with technology and walks the worlds of business and technology with equal aptitude.
By staying current with the practice of coding, these leaders maintain insight into how projects are working, stay abreast of industry developments, and can sense where changes can best benefit the organization.
And this trend may help address one of the most vexing 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 no doubt, and can tend to think more of the trees than the forest.
The perennial danger for the engineer is to become obsessed with building things, losing sight of the commercial value of what he is doing. I think of this as the Bridge on the River Kwai bug, where the character’s temporary technical task (building the bridge) comes to overshadow the much higher purpose (overcoming Imperial occupation).
But as developers grow in their role, their vision encompasses more of the systems and processes at play, with an understanding of individual elements. As a skilled developer gains a lot of experience, especially when their knowledge of the specific system under development becomes expansive, they can dive into high-value areas, help make changes, and keep a high-level view. Add to this an appreciation for the business side of things and makes for a potent combination of talents.
The mindset shift required of coders here is to allow for a true balance of priorities. While working developers may tend to view anything but actual coding as a simple interruption, successful coding leaders may keep in mind the importance of business and technical needs, akin to a work-life balance. , where both have the same right to care.
The coding lead knows how to maintain a broad perspective that incorporates both the trees and the forest, how to toggle between them, and especially how to allow the two to inform each other so information flows between them.
That includes, of course, the job of guiding humans in the business.
Myth: Programmers are mean to people
It’s such a hackneyed notion. It is also somewhat true.
Machines are logical and willing to be coerced into doing exactly what you want by telling them the right way. People are not. There is something different about leading people. As the programmer evolves from doing things, to leading other people who do things, to leading people who lead people who do things, this distinction is magnified.
Some people just have a gift for people, how to get their needs, fears and desires out of them; how to perceive where 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 skills, sometimes hard to learn. Encoders are no different. Recognizing the importance of human interaction, the coding lead commits to gaining insight and skill, just as they did when writing a for loop or functional component was intimidating and alien. The inner workings of the corporation are as amazing as the Internet.
The beauty is that the coder has a huge advantage in leading other coders and technical staff.
Coding leaders are “one of us”
All programmers will recognize this scenario: the project manager walks in and makes absurd projections based on your Gantt chart. Or even more embarrassing, he starts abusing buzzwords. Communicating business needs to builders effectively is a special art. Being an effective bridge between the two is even more valuable.
There is no substitute for the real experience of making silicon compliant. This translates not only into a deeper empathy for the technological work being done, but also for the special joys the profession bestows and the burdens the profession places on people.
There is a great deal of value to be found in keeping alive the knowledge of what it is like to be in the trenches. The ability to put yourself in the shoes of the working programmer is undoubtedly a great piece of the puzzle to improve the perceived and real performance of technology management.
While researching and thinking about this issue of coding vs. management, I took a car to the mechanic. The store was a huge operation, but I saw the owner walk up to a car and get under it to help diagnose a problem. There is a certain respect that comes from engineers with a leader’s willingness and ability to get into the thick of things.
That kind of respect and caring translates to the world of software, where the leader is seen as “one of us.”
Should the leader keep coding?
Writing about his own experience as a coder and administrator, Mark Porter, CTO of MongoDB, says, “There are many types of CTOs. A CTO in a small company leading the development of the company’s first product absolutely must program. A CTO who is focused on the exit activities of a major company should not do it.”
This is a realistic acknowledgment that, of course, there are roles that require the person filling them to put aside practical coding, but there is also a place in the world for people who love coding, who want to stay involved in it. and also grow in leadership.
It’s not hard to find even top leaders with deep practical technical knowledge these days. AWS’s Werner Vogels and Brave’s Brendan Eich, for example, give every indication of knowing and caring about the kinds of details that concern practical developers.
In the realm of technology tools, this kind of experience is even more valuable. The coding lead is not only able to better engage with internal developers, but also with customers.
The coding leader demonstrates that a programmer is like a classical musician, rather than a football player or fighter pilot. A classical musician can become a conductor who maintains his instrumental prowess to improve his work.
When considering the weight of career paths, the notion that one must choose a path forward as a practicing programmer or IT leader is becoming less concrete. Perhaps it can be seen as a spectrum, rather than a disjunction. At one extreme is the pure business leader, at the other the pure engineer. Most CIOs, CTOs, or other technology leaders will combine some of both, with the coding leader falling more in the middle of the spectrum.
As for the question, will I be a manager or a coder? Perhaps the answer is: both.