[HN Gopher] A Framework for Engineering Managers
___________________________________________________________________
A Framework for Engineering Managers
Author : aviramha
Score : 272 points
Date : 2022-07-28 07:15 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rishav_sharan wrote:
| This is great. Is there something similar for Product Managers as
| well?
| ivalm wrote:
| Isn't this TPM in this framework?
| rgavuliak wrote:
| The black labels on charts don't go well with the black GH
| background
| Sodman wrote:
| Thanks for this, I didn't even see the labels and was re-
| reading the text trying to see if they had specified which
| chart directions represented which measurements!
|
| Unfortunately GH doesn't have a way to alternate images in a
| readme based on light mode vs dark mode afaik.
| blowski wrote:
| Interesting read. I'm not sure I agree that an EM defining
| processes is operating at a more mature level than one merely
| challenging them. I try to challenge processes but coach the team
| to find the right processes themselves. I define processes myself
| only as a last resort.
| andsoitis wrote:
| > one merely challenging them
|
| I'm always more interested to hear from someone who _also_ has
| suggestions for improvement or change.
| aviramha wrote:
| The way I see it - _you_ defined that the way to create further
| definitions is by collaboration, so it 's still a way of
| defining process. I assume it's not just a "democratic" process
| to create a process ;) btw, totally agree on the point though!
| buro9 wrote:
| This attempts to recreate https://sfia-online.org/en , but it is
| way harder than one imagines and then is in danger of being too
| prescriptive and inapplicable.
|
| It's better to go the other way and work out the principals
| behind progression... that the further in their career the more
| ownership, agency, and scope they have. Most things can be guided
| by merely understanding the principals of it.
|
| This very old doc (from Sun Microsystems engineers IIRC) remains
| excellent
| https://web.archive.org/web/20090420152505/http://mark.kampe...
|
| It speaks to the spirit, the principals, behind progression...
| and that makes it extremely applicable to lots of fields,
| personal paths, and environments.
| vladsanchez wrote:
| Your point of "Ownership, agency, and scope" resonated with me
| but it hasn't been my case. I have almost 30yrs experience and
| still struggle to earn agency and ownership on subject-matter
| topics/projects. Not sure what's my problem but my point is
| that none of these frameworks are prescriptive, only
| descriptive. Thanks for sharing your ideas.
| chrisweekly wrote:
| principals -> principles
|
| (very different words)
| buro9 wrote:
| Yeah. Mobile phone keyboard are the bane of communication
| fjdbeb76 wrote:
| xEnOnn wrote:
| It's a pretty comprehensive framework and I think it's great. It
| would have been better if it also has a table of salary range for
| each level in different regions so that companies aren't
| misinterpreting these job levels or, at worse, misuse the guide
| to manipulate their employees.
|
| There are companies which make their employees senior or tech
| lead but pay $50k and use the same framework as expectation. It
| cannot be based entirely only on job titles because they are
| "free" to issue. You can easily mint new titles out of thin air.
| To back these job levels or titles with real value, their
| corresponding pays need to be relatable.
|
| If we could print money without backing it with something scarce
| like gold, guess what will happen? Haven't we seen some companies
| where there are so many senior, lead or even principal engineers
| but yet they getting paid lower than a mid engineer at another
| company? Job level/title inflation.
|
| On the other hand, at companies that don't inflate their job
| levels, they could still be underpaying their "seniors" and
| "leads" with junior or mid level pay while expecting them to
| operate along with the guide.
| roguas wrote:
| > If we could print money without backing it with something
| scarce like gold, guess what will happen?
|
| We do. We adjust monetary supply for markets to be stable -
| money has been not backed by anything tangible for quite a
| while. Like with any proposed framework(also applies to
| monetary stuff) you find out how it affects outcomes and you
| adjust usage.
| xEnOnn wrote:
| Yes, I'm aware that we do. I'm just trying to give an analogy
| of what I'm trying to convey.
|
| In the case of job levels, employees really shouldn't be
| shortchanged into believing the job titles given to them. The
| remuneration is a better indicator when in doubt.
| nutate wrote:
| wouldn't folks just join the military if this was their dream?
| mosselman wrote:
| This is great, thanks.
| lamename wrote:
| Reminds me of Patreon's IC leveling doc
| https://levels.patreon.com/?
|
| Note: '?' required for link to work
| newfonewhodis wrote:
| > Note: '?' required for link to work
|
| Wow that is an extremely dumb feature (bug)?
| lifeisstillgood wrote:
| I think there is a cut off point where influence is entirely down
| to hierarchical position.
|
| Yeah there are some people who cross cut and have personal
| influence (every org has celebrities) but in the main a person
| who has 1000 people reporting to him has more influence than
| someone with 2 people.
|
| How they got to that position will have very little to do with
| the skills sets mentioned here.
|
| It's kid of like the French aristocracy before the guillotine was
| invented writing a book on how to rise through the ranks to
| become an influence at court.
|
| It's missing most of the important stuff
|
| PS - I am getting overly cynical but I do favour democracy in
| organisations
| zerkten wrote:
| I wonder if the author plays Football Manager[1]. The attributes
| screens use this same visualization.
|
| [1] https://www.passion4fm.com/img/football-manager-player-
| attri...
| mariogintili wrote:
| I feel like these structures are often used to prevent people
| from getting a raise by raising the bar too far
| Hermitian909 wrote:
| This is really well done, but I feel like it (and other such
| frameworks I've seen) all start to fall apart at high levels of
| seniority.
|
| What makes someone D7 in this framework? The real answer is not
| in the charts, it's that they're very business critical. Maybe
| they're some ultra-niche specialist or just the only one who's
| been at the company since the beginning and knows where the
| bodies are buried.
|
| Things change in very interesting ways once the power dynamics
| between employer/employee shifts so the company asking the
| employee what it will take to make them stay.
| aviramha wrote:
| My take on management (and really on life) is that every
| theory/framework is a setting stone and not instructions. The
| framework helps you think better, but reality is always more
| complex than what is described and covered in the framework.
| Best managers IMO are aware of many different strategies,
| frameworks etc and adapt it to suit _their_ organization needs
| (based on the culture, people, goals, etc).
| ChrisMarshallNY wrote:
| Nice.
|
| Like all of these types of things, I believe that an _heuristic_
| approach is best, and this would work well for that.
|
| I could see a training curriculum being developed from it.
|
| However, it's also likely that an HR policy document would be
| developed, with compensation and review targets. That could have
| ... _interesting_ ... ramifications.
|
| BTW: the image does not do so well in GitHub's new dark mode.
| jb3689 wrote:
| Interesting idea. Tech lead at our company is mostly a TPM role
| mixed with the TL responsibilities listed here. In fact every
| senior engineer is expected to act in the TL capacity at our
| company. No commentary as to whether that is good or bad just
| relating that is how our (fairly large, well-known) org works
| webspaceadam wrote:
| On the first glance i really like that approach, but i have the
| feeling that something is missing. They address the issue, that
| different people can be on different stages in different axes,
| but there is no real explanation of how to handle the
| differences. Someone can come in with little knowledge about the
| technology, hence not using it before but is very well suited to
| "lead" discussions about architecture or processes.
| pliuchkin wrote:
| Thanks, very useful. I'm just finding it hard do adapt and find a
| place for the role of a Software/System Architect (which is very
| common in my industry) in the framework since it conflicts a bit
| with the other roles, mainly, Tech Lead. I`m thinking of
| Software/System Architect to be a TL7.
| mouzogu wrote:
| thanks for this, very useful. at least a basic framework to work
| with and adapt to my needs.
| mepiethree wrote:
| I really like this, the Dropbox career framework, and the Monzo
| career framework. I synthesized all three recently into one that
| I keep for our company, and the work pays such dividends. We do
| quarterly performance reviews and not only does having a
| consistent standard make these fair, but it reduced my time to
| write them from 1 hour per report to about 30 min.
|
| https://dropbox.github.io/dbx-career-framework/
| https://github.com/monzo/progression-framework
|
| And my nascent adaptation.. https://kevala-
| progression.herokuapp.com/
| harryf wrote:
| It's a nice idea to things like this _in theory_. Medium has
| something similar they called Snowflake -
| https://github.com/Medium/snowflake ... but note the
| disclaimer...
|
| > Heads up: Medium isn't using this tool anymore, but you're
| welcome to!
|
| The problem with things like this is the typical engineering
| mindset, when shown a graphical or numerical analysis of their
| performance will zoom into analyse every detail and in the end
| it's just backed by the managers impressions and judgement.
|
| For similar reasons I have a strong opinion that engineers
| shouldn't be paid performance related bonuses, because no matter
| what happens, it's just going to upset them - the best case -
| maximum bonus - just equates to a "meh". Better to pay a good
| base salary upfront ...
|
| Anyway use tools like this with caution IMO.
| maest wrote:
| > the best case - maximum bonus - just equates to a "meh"
|
| Can you elaborate on this? I find it surprising since bonus
| pays are very commonly used in many industries (and, in fact,
| relied on very heavily in e.g. finance)
| blowski wrote:
| I remember going through performnace-related bonuses. If
| somebody tried super-hard and got a "level 5", they got a
| PS5K bonus. Somebody ticking along without being outstanding
| got PS3K. Most people realised the extra PS2K wasn't worth
| the extra effort required to get it.
| pjbeam wrote:
| The bonuses where I am now are a % of the employee's base
| salary. A mid-level "meets" engineer can expect something
| like $20-25k during an average year for the company. Up to
| twice that for a strong year.
| yakak wrote:
| A raise of even a small amount makes a big difference over
| time because raises continue and even compound a little.
| Consequently, a cheap company will try to make the near
| certain portion of a bonus feel like part of your
| negotiated salary and extract effort with bonuses as
| ephemeral raises.
| quickthrower2 wrote:
| It doesn't compound at all. If the going rate is $200k
| and I switch jobs my previous salary doesn't matter, and
| therefore compounding doesn't matter.
| dzolvd wrote:
| in what industry does your previous salary not matter?
| (Not a snarky ask btw.) I have never entertained an offer
| blow my current salary, so personally find them highly
| correlated (sw eng).
| pc86 wrote:
| Nobody is talking about previous salary, the $3k/$5k
| thing was about yearly performance bonuses.
| jasongi wrote:
| Previous salary can't affect future salary unless you let
| the previous salary be known.
| vikingerik wrote:
| Raises that are a percentage will compound over multiple
| iterations, that's what he meant.
| pc86 wrote:
| We're not talking about raises, we're talking about one-
| time performance bonuses.
| yakak wrote:
| We are talking about performance bonuses, a trick to
| avoid permanent raises.
| romanovcode wrote:
| It's different in finance because a finance guy can go to his
| boss with hard proof and say "I made your company 10 million
| last year" and ask for 500k bonus.
|
| But developers do not have hard proof and they will be
| getting 10k bonus instead.
| HPsquared wrote:
| See also, sales.
| kqr wrote:
| Performance bonuses the way they are commonly done doesn't
| work in finance and sales either -- they're just so in-
| grained in the culture that it's impossible to hire a finance
| or sales person without offering bonuses the common way.
|
| The problem is that individual performance is a much smaller
| factor of outcome than commonly believed. Organisational
| structure, luck, social standing in the organisation, etc
| play a much bigger role. So in the end, performance bonuses
| usually reward random variation more than individual prowess
| (as much as the recipients would like to think otherwise.)
|
| This one-armed bandit type compensation, when disguised as a
| performance bonus, creates confusion, weird incentives,
| limits creativity and experimentation, and breeds bad blood.
| sokoloff wrote:
| > Better to pay a good base salary upfront ...
|
| Bonuses that are variable with company performance are a common
| way to manage the reality for many businesses of "some years we
| have more money than others". It seems better to pay bonuses
| that vary than to set high base salaries and lay people off in
| cyclical lean years.
| kqr wrote:
| That can work, if the scheme is (a) fair, and (b)
| transparent. I.e. something like "this is the formula we
| apply to the quarterly report to get everyone's bonuses".
|
| Anything else just ends up being a lottery that helps no-one.
| twblalock wrote:
| > Anything else just ends up being a lottery that helps no-
| one.
|
| I've seen several occasions when corporate bureaucracy has
| prevented or delayed raises and promotions because of
| policy or budget wrangling, but not bonuses or stock
| grants. Bonuses are a tool for managers to reward and
| retain their high performers when those other options are
| not available during that fiscal year.
| rufius wrote:
| I think your point is a good one. Though I'd say, that's why
| it's good to describe these as frameworks. They set the rough
| bounds of expectations, but much like API frameworks, the
| business logic is specific to your company and its culture.
|
| Anyway - agreed that you cannot just blindly follow one of
| these. Also, this level of complexity in leveling is something
| that is best left to bigger organizations. It's almost limiting
| to impose it on smaller orgs.
| charlie0 wrote:
| I agree, pay them more. Nowadays, the best "bonus" is switching
| jobs.
| dasil003 wrote:
| > _The problem with things like this is the typical engineering
| mindset, when shown a graphical or numerical analysis of their
| performance will zoom into analyse every detail and in the end
| it 's just backed by the managers impressions and judgement._
|
| The point of leveling frameworks is not to magically make
| everything objective and quantifiable--though I agree that is
| what many smart young people want and expect (after a decade+
| in our Victorian education system)--it's to channel and provide
| a rubric that many different engineering leaders' (both EMs and
| ICs) impressions can be compared and contrasted in a structured
| and relatively fair way. The last thing you want to do is
| remove expert judgement from the equation, but in a medium to
| large org it shouldn't be one person.
| twinklegarg7 wrote:
___________________________________________________________________
(page generated 2022-07-28 17:00 UTC)