Training for Technical Leadership
I found a discussion on the role of a “principal engineer” on Hacker news here. The article and HN comments are a unique insight into this role. This discovery had surfaced as I was researching the concept of RefactorKit, and it made me think - what role can RefactorKit have in training technical leadership? Here are some curated comments.
javadocmd (parent-comment)
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.)
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.
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.
riku_iki
It is a good question for interview to discuss how those numbers have been derived.
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.
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.
