Many software industry leaders come from the ranks of working developers. They often want to develop in management because their mastery of technology gives them confidence, but they do not want to give up the practice which frankly fulfills them.
Enter the coding manager.
This new type of leader is responsible for both technology strategy and practice, and navigates the worlds of business and technology with equal aptitude.
By keeping up to date with the practice of coding, these leaders maintain insight into how projects are working, stay abreast of industry developments, and can perceive where changes can best benefit the organization.
And this trend can help solve one of the software industry’s most vexing problems: the feeling among developers that they’re dealing with bad managers.
Myth: Programmers can’t be good leaders
The coder’s day-to-day work is often detailed, line by line, of course, and he may tend to think more of the trees than the forest.
The constant 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 over the River Kwai gaffe, where the character’s temporary technical task (building the bridge) comes to overshadow the much higher goal (overcoming Imperial occupation).
But as developers grow in their role, their view encompasses more of the systems and processes at play, with an understanding of individual elements. As a skilled developer becomes truly experienced, particularly when their knowledge of the specific system being developed becomes extensive, they are able to dive into high value areas, help make changes and to maintain the high level view. Couple that with an appreciation for the business side of things, and you get a powerful combination of talents.
The mindset shift that is 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 mere interruption, successful coders may keep the importance of business and technical needs in mind, akin to balancing work/life, where both deserve equal attention.
The coder knows how to keep a broad perspective that incorporates both the trees and the forest, how to transition from one to the other, and most importantly, how to allow the two to inform each other so that information flows between them.
This includes, of course, the work of guiding humans through the business.
Myth: Coders are bad with people
It’s such a hackneyed notion. It is also somewhat true.
Machines are logical and susceptible to being 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 directing other people who do things, to directing people who direct people who do things, this distinction is amplified.
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 strengths to help them and the business succeed.
For the rest of us, these are learned skills, sometimes hard-won. Encoders are no different. Recognizing the importance of human interaction, the coder commits to acquiring knowledge and skills, just as they did when writing a for loop or functional component was daunting. and foreign. The inner workings of business are just as staggering as the internet.
The beauty is that the coder has a vast advantage in directing other coders and technical staff.
Coding leaders are “one of us”
Every programmer will recognize this scenario: the project manager comes in and makes absurd projections based on his Gantt chart. Or even more cringe-worthy, start abusing buzzwords. Effectively communicating business needs to builders is a special art. Being an effective bridge between the two is even more valuable.
Nothing replaces the actual experience of silicon compliance. This not only results in a deeper empathy for the technological work being done, but also for the particular joys granted and the tolls exacted from people by the profession.
There’s a lot of value to be found in keeping alive the knowledge of what it’s like to be in the trenches. The ability to put yourself in the shoes of the working coder is certainly a big piece of the puzzle for improving the perceived and actual performance of technology management.
While researching and thinking about this issue of coding versus management, I happened to take a car to the mechanic. The store was a big operation, but I saw the owner get out of a car and crawl under it to help diagnose a problem. There’s a certain respect that comes from engineers with a leader’s willingness and ability to get to the heart of the matter.
This kind of respect and affection translates into the software world, where the leader is considered “one of us”.
Should the leader continue to code?
Writing about his own experience as a coder and manager, Mark Porter, CTO of MongoDB, says, “There are many types of CTOs. A CTO of a small company who leads the development of the company’s first product absolutely has to code. A CTO who focuses on outbound activities for a large company shouldn’t. »
This is a realistic acknowledgment that there are of course roles that require the person filling them to give up practical coding, but there is also a place in the world for people who enjoy coding , who want to continue to participate, and also evolve towards leadership.
Nowadays, it is not difficult to find even eminent leaders with deep technical knowledge. AWS’s Werner Vogels and Brave’s Brendan Eich, for example, give all the hints to know and care about the kinds of specifics that practical developers care about.
In the field of technological tools, this type of expertise is even more valuable. Not only is the coder better able to communicate with internal developers, but also with customers.
The Coder 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 important issue of career paths, the notion of choosing a path to follow between practicing coder or IT manager becomes less concrete. It can perhaps be seen as a spectrum, instead of a disjunction. On the one hand, the pure entrepreneur, on the other, the pure engineer. Most CIOs, CTOs, or other technology leaders will mix some of the two aspects, with the coding leader falling more in the middle of the spectrum.
As for the question, should I be a manager or a coder? The answer may be: both.
Comments are closed.