Anton Kazakov: Healthy Performance & Career Management for Engineers

In this talk, Anton Kazakov discusses effective performance management specifically tailored for engineers. As an engineering director at Canonical, he highlights the importance of having a robust performance management system that supports individual career progression, setting clear expectations, and providing regular feedback. Kazakov delves into the creation of career progression frameworks that outline the skills and expectations at different levels, ensuring that employees understand their growth paths. He emphasizes the necessity of continuous monitoring and improving team performance through authentic feedback and regular appraisals. Additionally, the speaker addresses the complex task of managing underperformance and facilitating career development, encouraging a supportive and constructive environment that helps engineers thrive.

[Music] welcome back folks next up I've got uh what I will simply describe as a Smooth Operator they came in they bragged as like oh I've timed myself perfectly a 40 minute talk I'll leave enough time for questions and that's why it's important to me that you guys remember to use the Q&A section at the end of this to take advantage of that big brain of his

because next up I've got Anton kazakov coming in to talk about performance and career management Frameworks for engineers Anon FL hey hey everyone thank you Darren for introducing me especially for introducing me as a Smooth Operator that's flattering um Okay cool so um I'm Anton uh and I'm very happy to be here thank you for having me everyone and uh I'm going to talk in the next

40 minutes about the healthy Performance Management for engineers um first a little bit about me I work as an engineering director at the company called canonical um we the publisher of buntu by the way we have recently had a long-term support release called Noble number so all the bu users out there if you want to uh install a brand new long-term support relas go ahead um all

of those who are using older systems you'll be able to upgrade a little later yeah um as an engineering leader I also mentor and Coach other engineering leaders gladly um currently I can only do that pro bono for various reasons so yeah if you have a topic and you want my advice on on it for any reason just knock on my LinkedIn or or send me an

email I'd be glad to help you I'm also a father and fan of Mountain skiing and hiking and enough about me uh oh yes one important bit canonical is hiring a lot of open positions just go ahead to canon.com careers and uh maybe you find something for yourself um yeah that's definitely enough about me let's talk about people Performance Management and first I want to ask you

a question what do you feel when I say people Performance Management there's probably a lot that you feel so you can definitely leave comments uh that what you feel in the chat however maybe some of you feel some discomfort people Performance Management uh it's like uh like someone is laying a cold Palm on your shoulder right and like ah Performance Management or maybe some of you cringed

a little bit because that's such a corporate term so HR and so on right nothing good comes out of it and also for the same reason maybe some of you feel anxiety hearing this and let me tell you I've been there I can relate to that and I uh I felt all of that hearing people Performance Management and I just want to say that it doesn't have

to be that way every individual working at a company every employee deserves a good performance management system for themselves so let's talk about what a good performance management system uh could look like and because most of us at least work in engineering organizations um let's talk about a slightly ta tailored to Engineers uh a system slightly tailored to engineers and first what do you think the goals

of Performance Management are some people will tell you that it's maybe satisfy the board of directors and the HR well whereas it can totally be um indirectly a goal but hopefully that's not directly um some people say ah it's definitely to fire button performers every now and again and that's a awful goal for performance management system and both of these are wrong I would argue that the

right goals for people Performance Management System would be setting performance expectations for individuals monitoring and improving their performance over time providing sufficient and convincing evidence for taking well-informed decisions and underperformance situations career progression uh need situations and importantly also it is to provide a solid foundation for people's career progression and what's also very interesting both within and outside of the company so a good Performance Management systematic

company can actually map out you will see that map out one's entire career uh for the foreseeable future and that is going to be independent from the company uh they they work at currently so let's take care of each and every one of these four goals uh one by one starting with setting performance expectations right that's basically um like threefold I would say first of all it's

about task level expectations you know all those J tasks that we uh know and like um just with enough description enough clear requirements um SM goals uh which is which stands for as many of you probably know specific measurable achievable relevant and Ty out um yeah that task level it's easy Ro level expectations though are a little more complex and interesting because it's not day-to-day um they

don't they don't necessarily you know jump to mind when you think about setting uh expectations um at least not in in the full detail that they are required in uh this is about setting expectations from a person's skilled knowledge ability and impact what they actually do in their role based on their role and this is when career progression Frameworks and team specific role requirements come to rescue

and spoiler alert we're going to spend a whole bunch of time just in a bit talking about career progression Frameworks because that's the the a central tool for a good performance however before that let's also mention that there's another layer of expectations and it is expected role level dynamics of meeting the expectations uh of particular roles so say someone gets promoted to a senior engineer um when

do you expect them to fulfill all of the expectations of the role or the majority same goes for a new hire so this also needs to be defined now as promised let's talk about career Frameworks first of all what are they this is roughly what they look like um this is a diagram made by a company called Red Gate and uh published on their um website progression.

r- gates.com and it consists of a bunch of bubbles arranged paths career progression Puffs um as you can see there are broadly four Puffs concretely five uh we're going to talk about why uh there are five and not four uh where when there are four expertise areas areas of expertise that they're covering so you can see that they're covering the engineering part of the org uh the

coaching part of the org whatever um Redgate defines it as um so this is this is a distinct area of expertise that they also have a progression framework path for then they uh also Define uh the path for product designers and product managers and behind each and every bubble on this diagram there's a rather comprehensive description of all of the expectations from the rule that the bubble

represents so a care progression framework building one is actually quite a large undertaking which is necessary but still large so why put ourselves through that well because career progression Frameworks are very helpful with three very important things they help map the current skills of an individual to the expectations from a rule let's say their current R and identify gaps why is it useful because isn't that the

core of performance evaluation you have criteria and these criteria are public to the person so they know what is expected and they can um steer their work and development um towards the goals that uh are identified there are going to be gaps they're going to be defined by the same expectations so this not going to be surprising uh to the people who know these expectations that these

gaps have been identified now even if there are no gaps uh between their performance and the current role that they're in there definitely are going to be gaps between their performance and the next role which also is very helpful to devise an efficient career progression path for them and then finally career progression Frameworks these kind of diagrams and so on they motivate people while are setting a

North star goal for them because they show that progression to high levels is possible it's kind of demystified there there is an answer to the question I'm a junior software engineer or a junior product manager how do I become a senior product manager uh at this company there's a a quick and easy way to answer this sort of question so what should a good career progression framework

have to be helpful with all of that well a bunch of things first and foremost all levels of all areas of expertise in your organization let's say in tech department should be covered by this from the very entry level like Junior Engineers or some people Define software engineer one do CTO because it is important to know the expectations from the CTO and how they are different from

um other levels at the company and so on and also make sure to cover all areas of expertise that there are software Engineers that can split into backend Engineers front-end Engineers devops Engineers product managers would be a SE a separate path if you have support Engineers maybe support engineers and what have now each all the progression paths where it makes sense should have individual contributor and manager

tracks why because it's awful to ask someone who doesn't want to be a people manager to become one because that's the only way they can grow at your company they will probably opt for not growing uh further at your company uh in many cases so there must be an individual contributor track that doesn't involve people uh management because not all people want to do it not all

people can do it as well that's a pretty certain set of skills so an individual contributor um path there would be something like you know a sing engineer getting promoted into staff engineer position where they think of cross theme architecture cross um you know system architecture to your company uh where they pull off large um technical you know programs projects and so on and so forth so

that sort of growth Advanced Career progression Frameworks even cover three tracks which is a manager people people manager a technical leader this sort of stuff engineer that I've just described and also kind of a high level Hands-On Builder operating across teams and like actually building cross system um things that are incredibly complex but needed to be built fast and so on so forth now for each and

every bubble on your diagram similar to the diagram um that Redgate created um there must be a detailed description of the expectations in terms of the skills the knowledge the ability that's required in terms of the impact that needs to be seen so this is how the skills the knowledge and the ability are practiced are um put you know to work and also sometimes there are certifications

that are required now there is also um an extra thing that is often overlooked um and this is about ways to recognize specific contribution um often known as addon rules for instance an architect sometimes a company doesn't have a distinct architect role because this role is being um fulfilled on a part-time basis so to say within each and every individual team by a couple of Senor Engineers

for instance there needs to be a way to set expectations from it and recognize the main the main thing the most important thing is to recognize that people do this work on top of the things that are defined in perhaps defined in their main role uh same goes for mentors speakers Security Experts um security needs to be built into the system of thinking there's going to be

a panel discussion on this by the way tomorrow so feel free to join um I'm going to participate there with a bunch of other very um thoughtful folks so it's be interesting so yes these addon rules also need to be defined let's take a look at at some examples for instance this is how um a company called Dev experts defines their um defines the hard scills for

their JavaScript Engineers for instance on the middle level E4 as as uh they call it they expect an engineer to know uh about asynchron Primitives of JavaScript for instance so ASN weight promises and so on and so forth and a bunch of other things for their s they uh put a requirement of knowing about memory management garbage collection also about some Advanced uh function uh functional programming

con Concepts um this is how Redgate defines um their soft skill requirements for if I remember correctly a single engineer so emotional intell intelligence what does it mean exactly his was three bullet points recognizing the feeling of others and adapting your approaches accordingly um being able to draw out opinions of others to help make decisions and so on then this is how the the experts Define impact

expectations from if I remember correctly also a senior engineer so uh they break down tasks for the rest of the team they are actively engaged in hiring as primary interviewers and so and so forth so yeah this is this is the least I would say level of detail you want to Define it on sometimes you want to even go more detailed and more comprehensive so as I

mentioned building a career progression framework is a rather large undertaking uh luckily there are tools nowadays so there's this progression. FYI website uh with a large collection of progression Frameworks published by established industry members there's uh this website engineering ladders.com with a rather comprehensive framework for engineering ladders uh not so elaborate and there's a ra rather simplistic uh framework which is um perhaps a good starting point

or is useful for smaller organizations uh which is out um open sourced by uh Sarah drazner the author of the book Engineering Management for the rest of us which I can totally recommend that way um however because it's still complex even with the tools let's talk about tips and goes that um are useful while building and rolling out a career progression framework at organization first and foremost

iterate as little as possible unlike many things especially in software engineering and feature devel product development nowadays where the approach is is good uh when it's agile right you iterate you uh introduce changes and so on and so forth career Frameworks are pretty much waterfall because um changing a career framework kind of live when it's already rolled out is very painful it is moving go posts for

uh your team members uh changing expectations that they've spent quite a bit of time and effort adjusting to that's going to be painful and is not going to be appreciated so it's it is a very good idea to get your career progression framework right or at least mostly right on the first attempt to do that besides being very thoughtful and uh um spending time on it um

it helps involving your senior team team members to get their perspective so that at least it is not very surprising and also you can uh asking your senior team members you can probably um anticipate well like what expectations uh from more junior team members uh would be right or wrong and so on and this process of course needs to be moderated uh the bigger your team is

the harder the universal consensus is to reach some times it's it's like impossible so you need to moderate it cleverly now let's say you've built it there's going to be a transition period from not having the framework to framework in full power um and navigating this transition needs to be done very carefully because uh no matter what framework you build and what you include there there's going

to be a bunch of discrepancies between the set of expectations defined in your framework and the status quo the real life let's say there's a well-regarded senior engineer that you have um who has been receiving good performance reviews for a while and they think of them as a very good s engineer and then suddenly uh you discover that their manager have has um really overlooked a bunch

of areas that you would like every Senor engineer to actually cover and suddenly this senior engineer needs to cover them uh out of the blue they're going to be frustrated that is for sure so you need to give them time and necessary support to adjust and stay flexible right so don't just say okay uh this is the career progression framework the very next performance review is going

to be done based on that so probably not the very next one however remaining flexible in the moment and throughout the transition uh doesn't mean that you can remain flexible about the end goal no end goal should be very clear you should be firm about it the end goal is that this framework is the core bit that is uh informing performance evaluations now once you've built a

framework and rolled it out don't change the system at least not often because moving gold posts are not very appreciated by people and it's very stressful for them when it's change so what you can do is extending it like introducing new roles new addon roles uh more Fidelity like a new role between two existing roles where the gap between them was too large and that sort of

stuff and finally as mentioned before already don't forget team specific expectations from roles because when you define a career progression framework people start prioritizing their work and their activities uh related to the expectations defined in this framework over everything else because this is what they're going to be evaluated against right so make sure that there are team specific expectation expectations defined or clarifications of uh the framework

defined on the team level um but very clearly it can be something like in a particular team a sing engineer is supposed to do level three support of customers they're supposed to do also on call for instance which for the folks on the same level in the other teams aren't supposed to be doing so that needs to be defined on that team otherwise it can even be

that the senior Eng says oh okay the career progression framework doesn't uh tell me that I need to do level three support and that's that's the part of my work that I dislike the most so I'm going to stop doing this and uh yeah so for that not to happen do Define it as a set of Team specific expectations all right enough about career progression Frameworks I

could um talk about them for the rest of the day um I love them so much and um enjoy building them as well but yeah we need to move on to the next goal of a good and healthy performance management system for engineers or for individuals in general that is definitely a shared one and that is monitoring and improving performance of individuals and what this is about

is basically feedback I'm going to have to be very brief about this although feedback is on its own like a topic for a separate presentation that I'll probably um hold at some other day on some other day uh yeah this is about three major aspects of feedback or types of feedback if you will first of all day-to-day feedback it needs to be done right so in an

authentic way so you mean what you say uh giving feedback um regularly timely so you don't wait to give feedback about some event that happened evidence-based of course so it's not based on your assumptions but it's based on facts balanced don't over rotate on you know negative feedback make sure that there's enough not enough but an appropriate amount of positive feedback given as much as as um

the individ deserves and also in appropriate context uh this is about you know not giving negative feedback to an individual in front of the entire team and so now there needs to be a 360 spectrum of feedback of uh directions of feedback channels of feedback meaning you want to avoid silence uh even if it's not just you which is the worst if it not just just you

giving feedback to the individual and the the immediate team their peers also give feedback uh it may not be enough because there are other teams that they inter interact with um they are they also have you know team members managers and so on so um there needs to be feedback channeled from the outside of your team and these channels need to be inclusive not only in the

uh that you cover all relevant teams but also in the sense that you cover all uh types of personalities and cultures right so for instance if the channel of giving feedback to your team is confronting uh your team member with with the feedback uh you will find that not everyone is comfortable doing this so yeah so maybe you want to have a um an asyn asynchronous and

not you know a face tof face channel of giving feedback and also you need to enourage in like these channels you need to encourage balanced feedback so it shouldn't be like okay uh if you have a problem with someone from my team please complete this form guess what you'll get only information about problems with your team members and you then won't uh necessarily get uh the props

from other teams that they wanted to deliver to a specific person so uh the channels need feedback and finally another uh topic for for a full presentation that I have to rush through it's regular appraisals done well so you want to avoid recency bias um which means that you know they're done every 3 to 12 months but we can only reasonably remember the last month in detail

so we we need to do something to avoid uh only mentioning the results of the last month because this needs to cover the entire assessment period usually that um is done VI taking notes throughout um you want to avoid uh mood congruent memory bias which is because of how again our how our brains work uh let's say if you are angry and you're writing someone's performance review

you'll tend to write a more negative one than necessary uh than would be fair uh likewise if you're very happy you'll probably write a more positive performance review uh than would be appropriate so whilst whilst it's probably less bad than writing a two negative one you you just want to write the appropriate one right avoid bias also there should be no surprises but if you're doing day-to-day

feedback uh right then the person whom you are um writing an appraisal for will have heard all the points that you have to say there from you already and you want to do a full snapshot of the person's performance against Ral expectations um meaning you just go through the uh expectations described in the career progression framework and one by one address address them sorry uh and finally

of course um if you want to give some improvement suggestions you want to do that based on the seniority of the person you're giving them to in the particular area so if they're senior there you probably can just set the goal and uh expect them to figure out the path if they're less senior there or even like quite Junior uh you probably will want to um def

at least kind of outline the path for them that's it about monitoring and improving performance of individuals you monitor it with the 360 spectrum of feedback uh with the channels that you provide and with regular appraisals and improve it via feedback that you're delivering again regular appraisals and day-to-day feedback now let's talk about uh providing sufficient and convincing evidence for underperformance and promotion related decisions this basically

boils down to managing underperformance and managing great performance so managing underperformance very simplistically is a feedback fed uh process so first you do evidence-based evaluation based on the list of criteria that is defined in your career progression framework you provide an evid evidence-based feedback to the person and then you support them and monitor the progress support supporting them may mean uh even adjusting the processes of your

team if it's not them it's the process that's wrong uh and other stuff you can support them in learning things that they need to learn thrive then you do another identify the remaining gaps provide feedback about them and go into another uh cycle of supporting and monitoring and then EV at some point at the nth iteration you may find that um your evidence-based evaluation shows that the

progress so far is kind of dissatisfying and you may need to make a decision now because a decision in such context usually means to people like a a very very concrete decision very specific decision I want to call it out specifically that a decision here is does not equal termination this is actually hopefully not a termination of a person so you don't want to let them go

big just because you're dis dissatisfied with their progress there options options and to talk about these options um basically options of what to do if uh feedback doesn't help an underperformer improve I want to ask you a question and here I'm going to need your opinion so you can probably go to the Pine tool chat and uh send me some messages uh right so how much do

you think it costs to replace an employee and while you're putting in your um opinions in the chat of the pine tool um let me talk about the inputs to this formula so it definitely depends on how senior the person is right it depends on how unique their skill set is it depends on the situation on the market currently are there many folks who are looking for

job are there a few is there much demand for this particular skill set um it depends on what tasks they are currently assigned to right because a lot of it is going to be opportunity cost while you're looking for someone else projects are not progressing or slower which kind of you know prolongs the the way towards uh completion there towards new features and uh the new income

right there is an opinion in the chat 10% annual salary okay that's that's a good guess okay right okay so I think for in the interest of time let me just reveal uh the answer based on the calculations I've done throughout the uh years and uh I based on the calculations of other folks that I've seen depending on the modeling and on the inputs and on everything

uh it's actually much more than 10% of anual C thank you uh without us uh for the guess it's usually in the range of 0.5 to three times the person's and interestingly enough it can go much higher depending on the inputs but it can't really go much lower than that because if you calculate the uh opportunity cost into this it just kind of spiral spirals uh out

of control really and you're like oh oh my God okay with the opportunity cost it's actually uh quite a lot of um quite a lot of cost so not only uh letting someone go because of underperformance uh is a often a mean thing to do because it's not it's not a clean cut right so they're not perh not terrible uh not doing terrible but uh they are

kind of you know a little bit mediocre and you can't do anything about it so it it may be a mean move uh but it's also a very expensive move so I suggest uh that you consider three warps to cater for actually something that Simon copsy talked on this track earlier today uh that it may be that the underperformance isn't inherently because of the person it is

because of some mismatch of the person and some aspects of the environment so three whates to consider here the first one Whatever team the person Works in isn't the right one for them they may need a more suitable set of similar tasks like tasks uh a different environment or even just a different boss which is a very hard pill to swallow for many of us as managers

because we think of of ourselves as of good bosses and here it turns out we may not be a good boss for them but um with such a cost it is really um important to consider that so maybe there's a different position and a different team that you want to look for another what if is what if the level the person uh is on was misassigned to

them and is to Big A TR for them currently um this is a bit of a can of worms because although these mistakes happen like a promotion that was given too early or you know a person hired as a senior engineer who's not that all that senior um depending on the labor law in the country uh we're talking about it may or may not be possible to

actually fix so it may be possible to uh effectively demote a person come to them say okay look so here's the mistake that happened uh here's the aftermath of it uh you do want to have a different set of expectations for you because otherwise we'd be talking about underperformance uh underperformance and we don't have a good path forward so let's maybe adjust it and sometimes it's going

to be possible and some areas like where I live in Germany for instance um you may be able to reduce the level but you may not be able to reduce their salary so yeah there there are things to consider you may want to go to your um HR team and talk about this uh but yeah if this is an option it may be an option to consider

with a mutual agreement of course uh with the agreement from from um the person um that was mis leveled and also another what if whatever the role they work in isn't fully suitable for them and that by that I mean actually they may need an adjacent role so not in in my personal uh experience I've had several folks getting transferred from let's say a software engineer to

a software engineer in test or from a QA position into a junior uh product manager position and they Thrive there they work better they were better fit and also sometimes you've been desperately looking for a product manager for this role and here you have a an underperforming QA uh who would be a good fit and that that kind of solves two problems at once so this is

another good what if to consider and only if nothing else works then you can think of parting ways now let's talk more um rewarding thing positive thing managing great performance it's often overlooked because people tend to over rotate on managing under performance uh whereas managing great performers is much more pleasant and also you know sometimes even more important and here it's simple productivity is key you already

do check perform their performance against the career progression framework regularly as part of regular appraisals right usually months now if you you see that they're doing great against the expectations of their current level check how they're doing against the expectations of the next one and if they're close bring it up with them tell them they're great and support them uh in reaching the next step if they're

up for it sometimes they may want to enjoy their comfort zone for while if you check and they are already doing well against an expectations of the next level then go and proactively suggest the promotion so there's arguably nothing quite like boss coming to and suggesting proactively suggesting that you should be promoted right so yeah it's that simple but also super important that simple provided you have

a career progression framework to work with right and now let's talk about the final goal uh of a healthy performance management system which is facilitating progression there's a bunch of things to consider there um we should run personal development coaching session with everyone regularly you can also refer to them as career coaching um usually it would be done after regular appraisals usually every six months you can

do every 12 months would be to my taste a bit too infrequent you can do every three months but that's too frequent usually there's nothing much happening within three months so yeah it makes sense uh to do it every six months in these sessions you create personal development plans for the next six months you track the progress you can even track the progress during one-on once with

the folks but at least in these sessions and you set smart goals so specific measurable achievable relevant and time bound um in this personal development plan to achieve um the next level of your career um and do make sure to specify the resources the person can use to achieve every goal you define there importantly make these personal plans about them the person Define their long-term career goal

not your long-term career goal you see for them um it may be becoming a CTO becoming a Founder building something specific maybe early early retirement even because uh people consider their job as a means to an end right um but importantly it must be their goal and their path towards it even if this is not necessarily your company what you will Define at your company is the

immediate Next Step so it's going to be with you coaching them through that towards their next um level on the career progression um framework and finally you need to agree on how they work towards the goals so some goals can be worked worked towards within working hours some goals need a lot of personal time invested like learning new programming language um you will need to provide resources

and support they need so give them time if you if you promis time uh give them the mentorship they require and so on but don't overdo if you do excessive handholding you are accountable for their progress whereas they should be accountable for their progress let's recap because we're almost at the end of session so what does a healthy Performance Management framework for engineers look like Define expectations

your career progression framework team specific role expectations clear task level requirements all of that do day-to-day feedback well it should be authentic regular should be done timely evidence based and balanced don't overate on any particular bit especially on criticism do regular appraisal as well no surprising feedback there evidence-based entire assessment time should be covered to fight recency bias and there should be a full check of Ro

criteria involved manage other performers well based on evidence supporting people in the growth that's required there if there's no result try changing the environment the team or the role uh only then consider termination manage great performance well be proactive anticipate the need for promotion and do personal development process properly regular care regular career coaching sorry personal development plans that are about them the person providing resources and

making the person accountable for their growth and with that just a quick mention that I'm a big fan of building career progression framework and if you want to build your own career progression framework let talk do reach out I will see what can be arranged to help you and with that thank you very much do you have any questions do we have time for questions Daren we

do you're on point see I I said you're a Smooth Operator you left two or three minutes and that's absolutely perfect folks use that Q&A tab I think we've actually already got a few coming in actually Anon so I'll hop us straight into them um great one coming in from vus they ask uh if the career progression framework should be very detailed and also should uh not

be changed frequently how do you keep it up to dat and still relevant in a landscape that is always evolving and usually quickly that is a great question thank you very much for it um indeed uh we're working software engineering it's a it's notoriously fast-paced and indeed this there must be a a set of very good reasons that can be universally agreed uh on like through through

throughout your org um to to change this so you basically need to be able to sell these changes to to the folks in your engineering organization you can expect some frustration to still be there but at least um it should be that people understand why you're doing this and uh let's say uh the company has switched from I don't know react to angular or vice versa uh

universally so the react relevant bits of the career progression framework don't make sense anymore so and that because everyone is working with angular everyone will just think of it of the change that's um done based on that as a necessary change so that definitely is possible this should just be a set of good reasons for this okay good response um we've got another question coming in from

Julian uh they were talking about your technical path it showed five levels they're wondering uh in what cases should you add more levels for example like Junior mid senior staff principal distinguished um right so the technical part that I showed first of all thank you for the question that's a very good one um the technical part that I showed uh was a technical path that a company

called dread gate uh thought would be good for them so the technical path for your company should be good for your company and if you see uh the Need For Stuff uh level maybe there stuff senior then principal so there can be more levels now but when to introduce this usually you want to do this when you see that uh you have um so to say kind

of a uh many uh levels of hierarchy in your orc so usually uh a staff engineer for instance would be expected to operate on a cross Team level uh a senior staff or a principal engineer would potentially be operating across Department level now if your engineering organization consists of one Department you probably don't need principal Engineers just yet or maybe you want to create this role for

two uh particular people whom you want to define the next steps for because you clearly see that they've outgrown the uh last role defined for them in in your career progression framework that would also be a case when you can think about okay yeah kind of like a got the folder drop it inside the folder type approach right you kind of compact it down as you go

makes sense simple is always good was it the classic saying is like um slow is fast fast as simple something like that I always forget the one it's like a military saying but Anon I just realize we're a little bit over time but it was absolute pleasure to talk to you folks if you do have more questions for Anon you've got his details right there be sure

to reach out but a pleasure to talk to you my friend I'm sure we'll be seeing you again very soon thank you very much thanks a lot everyone cheers