The Principal Developer
comments
Today I had a phone conversation with my ex-colleague Alex. Alex works as a software developer in a fast-growing international organization.
Me: “How are things going?”
Alex: “My company is searching for a principal developer.”
Me: “Did you apply for that position?”
Alex: “I did, but my application has been rejected. CTO believes that I am not qualified for that role. He is searching for a better candidate.”
Me: “Do you think that you are good enough?”
Alex: “Of course! I have been writing code and solving intricate technology problems for more than seven years. I write clean code, proactively fix the technical debt and cut through JIRA tasks like a ninja. I am faster and better than other teammates”.
Me: “I guess this is the exact reason why you don’t qualify.”
Alex wasn’t happy to hear that, so we quickly wrapped up our conversation. I hit the target.
I picked up a phone and dialed Andrey. Andrey is the CTO of the company.
Me: “Hey Andrey! Rumors say that you are looking for a principal developer. Why not just promote the most experienced developer from your team?”
Andrey: “Someone like Alex?”
Me: “Someone like Alex.”
Andrey: “Let me explain why it’s not possible. There are great coders and technical problem solvers in my team, but none of them have skills that I expect from a principal developer.”
Me: “Can you be more specific about your expectations?”
Andrey: “For a developer to get to the principal developer level, he must be a mentor. In contrast to a smartass, who tries to become “the best of the best”, a principal developer actively develops his team and helps the less experienced colleagues find ways to “level up”. He is an inspiring role model others want to follow. He leads by example and influences not only engineers but also product people, upper management and business stakeholders. A principal developer has a strong and positive cross-organization influence.”
Me (positively excited): “Do you expect a principal developer to become a mentor not only to other developers, but also to non-technical people?”
Andrey: “Absolutely right. Too often developers complain that “the business” knows nothing about technology and don’t know how to work with developers effectively. Does complaining solve the problem? No. Someone has to take full responsibility over the problem and fix it. Guess who is that?
That’s why a principal developer is a diplomatic communicator. He knows how to deal with different personalities, how to influence people across the organization, negotiate, manage up and down. He dares to raise uncomfortable questions, speak up when others are silent and align everyone around his vision.”
Me: “This implies a deep understanding of both IT and business.”
Andrey: “It’s part of the job, man. A principal developer is a T-shaped professional. In addition to deep expertise in one or more technical areas, he can collaborate across disciplines with experts in areas other than one’s own. The list may include, but is not limited to system operations, quality assurance, security, product development, human resources, marketing, finance.”
Me: “Sounds like a candidate must be 50% developer and 50% businessman.”
Andrey: “Exactly. Developers measure their productivity by the number of produced features. But that’s all bullshit.
The goal of any for-profit organization is money-making. Meanwhile, techies and their partners in organized Scrum crime are configuring Kubernetes clusters, playing table tennis and working on cool features without assessing impact on profits.
We need fewer coders and more money makers. We need professionals, who understand the whole product development pipeline from concept to cash and contribute to the areas that produce maximum profits.
It could be eliminating delivery process bottlenecks, reducing operational expenses or even recruiting. Occasionally, the maximum business impact is achievable with the help of a keyboard. But less often than most developers think.”
If your only tool is a hammer, then every problem looks like a nail.
The more money makers my company employs – the better. Behaviors a principal developer displays is the behaviors my company rewards and other developers mimic. That’s why a principal developer must be a trusted business partner in tech.
Me (smiling): “With your requirements, you have just filtered out 99% of developers on the market, including Alex.”
Andrey: “A principal developer is a professional who can make a significant impact on the organization. Unfortunately, neither Alex nor 99% developers on the market can do that.”
Our industry needs:
- Fewer
smartasses, more mentors - Fewer
coders, more T-shaped professionals - Fewer
silent complainers, more diplomatic communicators - Fewer
JIRA ticket closers, more business partners