The Principal Developer | Hacker News Reader

The Principal Developer

sizovs.net

72 pointseduardsi34 comments

So, in short they want a developer that has skills that no developer is allowed to train.

If you want business oriented developers, you need to change your company's culture.

I have once been asked to work towards becoming one. I was asking for a salary augmentation after I had just doubled my workload during the previous year. I had upgraded to doing both front-end and back-end. My CTO told me that no matter how good at coding I would become, that's not what generates money and unless my value increased my salary wouldn't move.

He wanted me to become a better mentor, to be better at juggling budgets and at dealing with clients.

He also tracked my time to the minute and I wasn't allowed to do anything but code. Taking an hour to think about a problem before tackling it was frowned upon.

They will never promote any developer into that position, their company culture is the opposite of that.

I ended up leaving and found a nice company that actually rewards productivity and allows people to breath between tasks.

At first, I disagreed, but then I completely agree after thinking about that problem more. The proper mindset comes from the Top. If managers can't guide/lead their devs then they just can't expect business-oriented development. I guess most often what they want is less coding more features anyway. But if developers are supposed to help with business then they should understand the business and not be viewed as programmers but as the developers - for instance, programmers would probably code new feature from 0 but developers could use external SaaS to verify the need for that feature in the first place. I agree that developers need free room and a lot of help from management to make business development a reality.

On the other hand, I do think that not every developer is meant for that kind of work, there are lots of developers that think only about coding...

I've seen people who worked their own business, freelancers, etc., come in such a shop and end up out of date code monkeys after 2 years.

> that's not what generates money and unless my value increased my salary wouldn't move. He wanted me to become a better mentor, to be better at juggling budgets and at dealing with clients.

How does being a better mentor "generate money"? If your workload "doubled", that means you were doing the work of 2 people, no? (or similar). it doesn't generate money, but that saves money they might otherwise have spent.

Unless "dealing with clients" means "getting them to spend more money", "dealing with clients" doesn't generate more money (and... depending on how its done, can be a financial loss).

On "taking an hour... before tackling..." - that hour is tackling the problem, no? Just with a "code after it's been thought about some" approach, but it's tackling it all the same.

> So, in short they want a developer that has skills that no developer is allowed to train.

> If you want business oriented developers, you need to change your company's culture.

Woah, so true. I'm inclined to say that unless tech leadership (CTO, engineering directors, etc.) specifically work setup training and mentoring programs to help engineers move up the ranks, then any sort of technical career track is just useful fiction for recruiting and nothing more.

Likewise, if you want people to take initiative outside of the scope of their current responsibilities, you must provide them slack to do so.

During my orientation, I was able to visit the call center and put on a headset to listen in on a few client calls. It was quite interesting. That was years ago and I haven't had direct contact with any customer since, even though my work affects them directly.

This is the second HN blog post I have read today where the author views a (former) colleague as an enemy to be defeated ( https://news.ycombinator.com/item?id=19190472 was the other one). Given that they are having a casual phone call it can be assumed they are some kind of friends. Yet the author's self worth seems to be at least partially based in winning a game of being more correct.

Even if someone is wrong about something, why take joy in their failures or in beating them at something? Wouldn't it be better to take joy in their successes? It's not the point of the article, but it is jarring to me.

I agree, it comes off as really petty and does the author no favors.

All of these articles are meaningless.

You simply cannot define what makes a "senior/principle/lead" engineer. It depends on what the company needs.

If you're building a highly-technical thing (e.g. an OS) then your needs may be entirely different than building something low-tech and customer facing.

Any attempt to say that skill X matters more than Y for promotion (skill/IQ/social-skills/niceness/politics) is necessarily a drastic oversimplification.

Also, the idea that promotions are based on a skills is an absurd pretense. It's as much a function of creating a pretty org-chart as anything. To point - In open-source you may see a project of 3 principles and nobody else. You'd never see this in a company because the org chart doesn't look like a pretty tree.

Exactly. At the end of the day, the person solving issues and being good at marketing himself will be the next principal//staff//whatever dev.

"Whole-systems engineering, when you get good at it, goes beyond being entirely or even mostly about technical optimizations. Every artifact we make is situated in a context of human action that widens out to the economics of its use, the sociology of its users, and the entirety of what Austrian economists call “praxeology”, the science of purposeful human behavior in its widest scope." - Eric s. Raymond

I would agree that building a highly-technical piece of infrastructure will require a different skill set than building an enterprise-y "forms and reports" style application.

But if you're going to give someone the latitude to decide what kinds of problems they are going to solve (an not merely the latitude on how to solve it) you are going to want some communication skills and some awareness of how those problems relate to the overall goals of the business.

Now I tend to think that even in these higher level positions, technical skill still matters a lot. Architecture Astronauts are a plague and can create unnecessarily complex problems that the senior grunts have to deal with.

However, the importance of "soft skills" does grow as one move's up the ranks.

For me, the biggest take-away was that the CTO had failed to cultivate talented employees for promotion.

If this CTO has those objectives, why doesn’t he make them transparent? It should be clear for everybody what is expected in the next progression and part of the organizational performance management process

It depends upon the need for the role. In my experience principal engineers do one of three things.

1. Develop new technology that can be sold to customers with a wide understanding of the company's business model (engineer + salesperson) This would be different than an application engineer, because the application engineer uses the company's current tech to solve issues.

2. Fix problems in a multi-disciplinary technical pipeline (engineer + manager).

3. Develop new technologies that save engineering or business time on large scale. This could be creating a new process, or a new toolchain for a problem specific domain. It could also be optimizing or re-architecting a very large code base. (engineer ^ 2)

So yeah while moving Jira's from left to right is a good skill to have. The first two require more soft skills, sure, but the last one is really writing more jiras, and communicating to other engineers how to solve a problem. So even it is not free of soft skills.

In my org, principal dev is expressly for the most talented devs who don't aspire to leadership roles. We have explicit leadership roles that require certain personality traits more than technical chops.

Like being able to deal with a thousand people dropping tasks on their desk and expecting them to get done.

No, we don't work that way. Devs are assigned to projects and projects have prioritized backlogs. There's always a next task and everything else gets in line.

I think this is a good point, but it really feeds into one of the ongoing set of conversations that are happening on HN. One thing we keep coming back to is what an engineer gets promoted into. We repeatedly come to the conclusion that management (often) isn't the right career path and that technical seniority is important. But when you look at the really senior levels for engineers those management skills start to re-emerge. It's how you relate the engineering to the business and how you influence others. In this way you're actually taking on a management skillset, without necessarily taking on the direct responsibility.

Too often engineers want it all -they want the responsibility of a new grad coder with the title of an architect.

If you start looking at senior engineering roles in line with the cousins in management or sales you realise you need a much more broad background to reach those top levels.

I think the problem is that career path has multiple directions, as does seniority. Principal developer is just a label slapped on technical people that have management chops, as described in the article.

If “the most successful career path” is defined by financial compensation, it should be no surprise that those techies that also master the broader art of business and management add more value to the organization and are thus compensated accordingly.

Would they be able to replace that very senior distributed systems engineer? Maybe, but more likely it’s a different type of value added to the organization.

I think another reason developers are reluctant to join management is there is this gap between developers and upper management. In upper management you're making enough money and have risen high enough you'll land on your feet. But before you make it there, you're stuck in middle management.

In a lot of ways it's better to be a sr. dev or tech lead than middle management. The starting salary at any company is higher, you're more sought after, and you are usually keeping a valuable skill up to date. Where as project managers usually add value through their knowledge of the organization and application which is less transferable. My LinkedIn is peppered with lots of smart and capable project managers who didn't quite make it to upper management(usually because they weren't sharks) so they switched out of software or are stuck at jobs they don't like.

> We need fewer coders and more money makers.

This only works in a relatively small niche, like consulting bodyshop where billable hour is the only metric.

A coder that works on some internal software, database, in infosec, design is not making any money. A game developer who created a beautiful realistic-looking reflection, a web designer that eliminated possibility of XSS attack, an embedded engineer that spent extra week designing FADEC in such a way that race conditions cannot freeze it, how much money did they make?

This will be a very unpopular opinion here but as someone who has managed a few different engineering departments and now a CTO I agree with the premise of the post.

A single business/mentor oriented senior+ engineer is an unbelievably effective force multiplier. One engineer can then take 2-3 very jr engineers and drive a small cost effective team. Such a team needs little product support given its lead is product oriented, and the technical architecture is unified as more junior engineers follow the leads standards to grow and learn from them.

On top of that in 2-3 years those jr engineers often become exceptionally effective business/tech focused engineers themselves.

Disclaimer: For this to work you need to either be a very small company and/or have a culture that doesnt use the product team/department as a wall between business and tech.

Let's assume this is true... The CTO wants someone that will mentor but is unwilling to mentor his team. :-). Seriously, set expectations for your team and see if they rise to it. Folks don't read minds. CTO is probably screaming about how slow the release is and developer is cranking out feature after feature and now is flipping it around that developer is not talking to the business. If the developer was spending time, talking to the business and mentoring and doing little coding, perhaps CTO will claim that developer rarely ships and is not qualified. Frankly, folks that care about promoting from within do so and does that don't, will always look for outside talent.

One wonders what the CTO does then.

Or fewer CTOs who think they deserve the 1% working for them

CTO is going to be looking for a while given these demanded qualifications. Maybe he should have tried some mentoring himself.

Of course, none of this actually happened. It's just a made up story from some nobody tech influencer. There's a kernel of truth, which is that focus on larger business of objectives are important to keep in mind if you want to have a big impact. But there's a lot of BS wrapped around that kernel in this article.

I don’t think any CTO really does. Seems more realistic to aim for 2 developers in the top 30%.

Hmm personally sure I think developers should have ability or sense of making money. Generally speaking, it would make more sense to rather encourage developers _not_ be too obsessed with tools. Sure I like programming, computer network etc, but in my 30 I'd love to make more things that are accessible and useful to the world, not necessarily changing the world.

In Slack or chat today is kind of boring, developers are too obsessed with tools to the level that I wonder these people had done anything useful. No one mentions what kind of apps they build.

Developers or engineers should make more.

All of the behaviours this alleged CTO supposedly wants from his "principal developer" are things that are punished if displayed by developers.

Speaking up about things that are wrong in other departments or decisions made by your "superiors"? You're not a team player.

Spending time helping other developers instead of crushing Jira tickets? We need to talk about your performance.

Going outside of your team to coordinate things with the rest of the business? You're cutting the product owner's grass (or interfering with management of some other team).

Here is a related blog post from last week that defines the "Principal engineer" / "Staff engineer" role: https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-e...

Discussion here: https://news.ycombinator.com/item?id=19128489

If you want influence at your company, transform into a product owner. If you want to stay a coder, I think in most companies you can't expect to have any real say. I think most companies would love to have more technical product owners that can't be bullshitted by the dev team. Fake it till you make it!

Even if you know, management has to listen to you (not just mouth the words), which is a much bigger challenge.

Talking to a former colleague that way just makes you seem like a very unpleasant person.

The article is confused about the position it's writing about. That's either a director, vp of engineering, or even the CTO itself and at that point, no longer a developer or individual contributor.

Comments here are pretty negative, I'm curious how this made it to the front page. It was submitted by the author. Question is, who upvoted it?

Reply on news.ycombinator.com