
The Principal Developer - eduardsi
https://sizovs.net/2019/02/15/the-principal-developer/?new=true
======
Raphmedia
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.

~~~
wrestlerman
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...

~~~
Raphmedia
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.

------
aristophenes
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](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.

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

------
alexandercrohde
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.

~~~
lliamander
"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.

------
yayr
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

~~~
tootie
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.

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

~~~
tootie
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.

------
Traster
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.

~~~
stingraycharles
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.

------
pps43
> 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?

------
mharroun
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.

------
segmondy
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.

------
dfilppi
One wonders what the CTO does then.

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

~~~
asdfasgasdgasdg
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.

------
Existenceblinks
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.

------
Sophistifunk
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).

------
ivan_ah
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...](https://blog.dbsmasher.com/2019/01/28/on-being-a-
principal-engineer.html)

Discussion here:
[https://news.ycombinator.com/item?id=19128489](https://news.ycombinator.com/item?id=19128489)

------
EdSharkey
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!

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

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

------
mnm1
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.

------
kgwxd
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?

