Principal Engineer

C

cguy

Executive Member
Joined
Jan 2, 2013
Messages
9,992
Reaction score
5,051
"A short while ago I was faced with a choice: continue to code but give up on career progress or give up coding and continue my career. I choose the later, but if I am honest my heart was always in creating things and #programming.

Today Absa Group has recognised that the future of our business is actually in keeping world class engineers in delivering value for the bank, so I am a literally over the moon to introduce the "Principal Engineer" role!!!" - Andrew Baker
Click to expand...

0


https://www.linkedin.com/posts/andr...developers-activity-6669561154920054784-looA/
 
can you do something on Call Centres, the way inside your company for customers with complaints, or detailed questions, in the sense of the person answering the phone has the knowledge and authority to make a decission on the spot, or if delayed you stay linked to that person to prevent the trend of going around in circles etc.
 
With the way it seems to be going now we need more Blacksmiths and gunsmiths. All the skill sets of the 21st Century helps bugger all in medieval times....
 
It's a good idea, but looking at the last slide it looks more like an IT Manager/Solution Architect that won't develop much (but will help others do so) than a very senior developer who takes on more leadership roles while retaining and using their core skill.
 
animal531 said:
It's a good idea, but looking at the last slide it looks more like an IT Manager/Solution Architect that won't develop much (but will help others do so) than a very senior developer who takes on more leadership roles while retaining and using their core skill.
Click to expand...

In my experience (the notion of a Principal developer has been around for 20+ years in the USA), it is still very much hands on, but the hands on work can typically range from 50-100% of the person’s time depending on a combination of current needs and preference.

As someone who hit that’s level some 15 or so years back, I probably spend 15% of my time in meetings these days and 25% of my time reviewing code and steering projects. 60% of my time is actually spent on coding/math.

Of course we do have to see what ends up happening in SA - whether it really gets treated as a more senior engineering role or as a technical first level manager. Then there is also the culture of “all managers are more senior than all engineers” to deal with before there can be any true engineering leadership.
 
cguy said:
In my experience (the notion of a Principal developer has been around for 20+ years in the USA), it is still very much hands on, but the hands on work can typically range from 50-100% of the person’s time depending on a combination of current needs and preference.

As someone who hit that’s level some 15 or so years back, I probably spend 15% of my time in meetings these days and 25% of my time reviewing code and steering projects. 60% of my time is actually spent on coding/math.

Of course we do have to see what ends up happening in SA - whether it really gets treated as a more senior engineering role or as a technical first level manager. Then there is also the culture of “all managers are more senior than all engineers” to deal with before there can be any true engineering leadership.
Click to expand...

I see. Those are some really decent percentages, hopefully the same kind of thing happens over here.
 
We did that, we've got specialist level which is mid manager level, than principal and some others I can't remember
 
SlinkyMike said:
You have a nice balance, like that actually sounds perfect. I have no idea how you limit meetings to 15%.
Click to expand...

One of the things that really makes a difference is a relatively flat hierarchy. We have so few dedicated managers, that almost nobody is paid to sit in meetings. :)
 
My company has Principle, Snr Principle etc. And they indeed do still do a lot of technical work.

The reality is when you have a company with really good engineers, even after about 5 years experience they will be able to execute on a sufficiently well fleshed out problem.

Moving up in a technical role, in my mind involves:
1) Bus factor, the more you can unlock others, the more valuable you are. Your main job should be working through others. As a engineer this means disambiguating complex problems into simple components. Some engineers thinks this means the principle engineer is coding that stuff. In reality it means creating a technical document that describes a solution and having it widely reviewed along with

2) Driving consensus, goes hand in hand with the above. Your technical documents shouldn't be about steam rolling over everything because you are the best. It has to stand on its own merit and that means being able to interact with others to bring consensus about technical solutions. This means balancing high quality software with business needs and convincing others by breaking it down so that they agree.

3) Developing others. This means giving people opportunity to do ever more complex work to develop themselves and thereby deliver with your assistance. This goes hand in hand with the above, they should be doing this albeit at a lower difficulty level. It creates a hierarchy (regardless of rank) that delivers software very effectively.

4) Thinking beyond what has been done before or what is obvious or trendy. You want someone who can see when you shouldn't just solve this complex problem but instead create a larger overarching solution that solves it for a lot of the business. This one is especially troublesome as many engineers struggle to really thinking big about solutions while still having reasonable milestones and deliverable solutions. Most engineers think replacing somethings is equivalent to this. It isn't.

5) Taking complex ambiguous idea from a customer and removing the ambiguation to make it into something the developers can build

Overall these are the top things that pop into my mind. In a lot of SA companies some of these are done by managers. And very badly I should say.

I was in a company where we had a manager acting in this role (architect/manager) and they thought it meant they had to code all the "hard" parts. Come up with the "architecture" of the whole system. Was bad at delegating. Didn't encourage criticism or seek other diverse views on their design, etc.

All signs of someone who got hired into a role that they don't have the skills to deliver on. If you have those skills, others will see when they help you develop the solution. You don't need to convince the company you are a one person developing machine

my 2c

For what it is worth on all of these I can score myself and know exactly where my gaps lie on them. This I think is important part of becoming better at moving up. It also allows me to clearly see in others where they are better at these things. For example the principle engineers, etc. in my company don't need to convince me why they are there, I can clearly see when I compare myself on these criteria why they are there.
 
Last edited:
Magnum said:
With the way it seems to be going now we need more Blacksmiths and gunsmiths. All the skill sets of the 21st Century helps bugger all in medieval times....
Click to expand...

Developers are...

We already forge and secure as best we can. Look anywhere but here, cause here is 20 years behind. Here the internet is a disgusting postbox. A hotline to cheap thrills.
 
John_Phoenix said:
Developers are...

We already forge and secure as best we can. Look anywhere but here, cause here is 20 years behind. Here the internet is a disgusting postbox. A hotline to cheap thrills.
Click to expand...
You would be surprised at how "behind" some companies in the US and UK are. A lot of generalisation here.
 
Takealot has principle engineers, that's where I first heard the term. Sounded like a project agnostic tech lead to be honest.
 
Hamster said:
Takealot has principle engineers, that's where I first heard the term. Sounded like a project agnostic tech lead to be honest.
Click to expand...

It seems to be a needed role, especially where a business product is split between product owners each with their own Dev team. It makes sense to have someone overseeing the entire spectrum, creating and sustaining cohesion.
 
Kosmik said:
It seems to be a needed role, especially where a business product is split between product owners each with their own Dev team. It makes sense to have someone overseeing the entire spectrum, creating and sustaining cohesion.
Click to expand...

That's what Kafka is for :mad:
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X