[javadocmd]

I would argue that company-specific historical knowledge is not the value you (et al) are bringing. The value is the soft-skills of effective leadership that distinguish Principal from Senior (to use the article's parlance). Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills. And, of course, in finding a company and an interview panel that understands their value.

Anyone worth their salt should realize that the long-term value of technical leadership far eclipses the short-term value of knowing what happened that one time we tried switching from Technology A to Technology B. (And unless you've completely purged your engineering department, such institutional knowledge is there to be queried.)

[scarface74]

Managerial principles also state that your value to a company is also partially based on the relationships and good will you’ve built that enable you to be more affective when you need something from another team or department and even the relationships you’ve built with vendors and customers.

[fromMars]

I am believer in promoting from within for the most part.

At the companies I have worked at, hiring people directly into principal roles hasn't worked well. Invariably, they struggle to fulfill that role because they don't have enough knowledge about the inner workings, code base, etc.

It usually takes them at least a year before they contribute at their level.

[maxxxxx]

“Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills”

Any ideas for doing this other having a lot of public visibility? I may have answered the question already but there may be other ways .

[tibbetts]

Learn to talk about your accomplishments like an entrepreneur or executive would: impact with quantified customer and company value. Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.”

Another thing I don’t see enough in this thread is emphasizing software you managed to avoid writing. That’s the real secret of being a 10x engineer: telling your organization when building something expensive is not necessary, either because you don’t really need it, can use something simpler, or can adopt something that already exists.

[matwood]

> Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.”

This is important for any level job. Java to Go by itself is really only interesting for a low level position. 8MM revenue growth is a person that will almost always get another look. In general, using exact numbers that can be backed up is better because they tell the why.

Using the Java to Go example. Sure, the work was done but why was it a good idea? What did the company receive out of the change? How did the interviewee think about and mitigate the risks?

[roel_v]

How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'? It could just as well have grown by that much even if there had been no switch. When I see formulaic nonsense like that in a CV, it better be meticulously sourced and they better be prepared to defend such a number in a potential interview, because usually I'll bin them with the other bullshit artists straight away.

[matwood]

> How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'?

In addition to what pm90 already said, if you can't quantify the value to the business on some level, then why are you doing the work?

My comment also said to back up the numbers. If I said I wrote a little utility and it saved the company 8B/year I better be able to explain how.

Also, the numbers do not have to necessarily go directly to revenue. Less bugs, faster feature development, less server resources, lower costs, better estimates, etc... are all quantifiable on some level. Is this an exact science? No, but this is what any engineer above junior (even they should be asking why are they doing something), should be asking themselves about every single engineering task. Because something is new and shiny is generally not a good answer, yet these types of migrations still happen in companies and waste large amounts of money.

[pm90]

One of the best things I've see engineers do to get their team the resources it needs is to spend time on modelling the value that they generate for the org. Speaking candidly... this could be any number at all, but most teams try to make it quantify the value generated in some meaningful way at least (even if that may not be admissible from a purely accounting/GAAP perspective).

e.g. it could simply be how much client data is processed by your system everyday, how many clients use it, what is the ultimate value the pipeline generates (even if that may be the cumulative value generated by the entire software pipeline)

[tdumitrescu]

Oh man, I see so many resumes littered with these kinds of statements. I totally gloss over them as they generally read like BS, and are formulaic enough that they just represent another "how to sell yourself" job-hunting checkbox point. Lots of devs would love to have some way to quantify our impact in monetary terms but the reality is that "process/tooling change X -> $Y ARR" is basically always hand-wavy made up math.

[tibbetts]

Sure, but most business decision making is based on hand wavy made up math. Like, how do you decide to build a feature or switch programming systems? Does it not relate to customers or revenue?

Also, yes, don’t have the numbers be BS or fail to include other useful narrative in your resume. But I so often see none of this, and leaving it all out is a sign someone hasn’t had to justify their decisions at that level.

[riku_iki]

It is task of decision making person to filter out hard facts from BS. If he does good job - company is more successful.

[riku_iki]

It is a good question for interview to discuss how those numbers have been derived.

[javadocmd]

In addition to tibbett's point (expressing technical accomplishments in terms of their value to the business), do some honest introspection on your value to your peers. I'm really just elaborating on Ms. Botros' article here, but for example you want to ask yourself these kinds of questions:

Do you improve the skills of the people around you? Do you identify and help resolve barriers faced by your peers? (This doesn't always mean fixing things yourself!) Do you improve the environment and culture where you work? Can you work collaboratively to establish a vision for change? How do you gain the buy-in of your peers when it comes time to implement change?

Internalizing these answers will prepare you to steer the conversation onto the skills that you know are important for the role.

[micksabox]

Building RefactorKit.com to help with this too:

> Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills.