Heroes and Juniors: Increasing Engineering Team Velocity
medium.com
medium.com
" Knowledge transfer isn’t something that just happens, it’s a skill. And like all skills you only get good at it by doing it over and over again. Consider this: in 2013 Sun Microsystems published the conclusions of a seven year study about the impact of mentorship that found that the people doing the mentoring experienced similar benefits to the junior colleagues being mentored. 25% of mentees saw a positive change in their salary growth, and so did 28% of mentors. Retention rate for the juniors rose from 49% to 72% and for the seniors it rose from 49% to 69%. When senior level people are able to grow junior colleagues, they are able to take on new responsibilities, build new skills, find new challenges without leaving the organization and ultimately everyone is better off. So why aren’t you hiring junior engineers?"
The truth is, a lot of organizations either cannot see these decisions as long term investments (rather than liabilities), or have enough trouble hiring senior engineers in the first place that they're horrified of hiring junior engineers who will flounder without the right amount of mentorship.
This is somewhat of an aside to what the article mainly talks about, but I don't really know that all of this has to do with the engineers vs the companies.
Today's scrappy and small companies are still trying to find fit fast, and still have to be tactical. They can't avoid a pile of tech debt because they don't yet know what they need to build. Building a really fancy solution to a problem and then having that problem change out from under you is just another kind of tech debt.
So even without a focus on "rock stars", how can you avoid tech debt when you're in an exploratory phase?
Seems a bit of an instance of a common way for slightly-less-young-companies to shoot themselves in the foot. If your tech debt is just due to those other people who screwed up when building the initial systems, then of course it's a good idea to rewrite the world!
The tech debt becomes welfare if its whole purpose is to be a temporary benefit until eventually getting off of it. Abandon the old one and don't pay back the debt. But don't let zombie pets follow you to the next one... Legacy can be incredibly difficult to kill.
I don't know exactly how it relates to the broader "tech debt" discussion, but one thing that can make a big difference is to design systems in such a way that there are obvious strain indicators.
To quote Firefly, ways the system can "let you know she's hurting before she keels.".
How exactly you do that depends on what you're building, but I think it's a worthwhile thing to keep in mind.
Can't think of any specific example off the top of my head, but I've noticed that lots of places talk about needing people to be "on call" all the time. We are a very small shop with some fairly high profile clients, and "everything's on fire" situations happen maybe once every year or two. And are then mitigated by fixing the code in such a way that there are diagnostics to let us know if we're ending up in dangerous territory again. Before everything goes Kaboom.
The "everything's on fire" metaphor also has a larger context. Sure, when people are getting woken up in the middle of the night because the site is down, shit's on fire. But also "we're constantly missing our deadlines" is shit's on fire, "our customers are not satisfied" is shit's on fire, "our overhead is way too high for what we're delivering" is shit's on fire. If you're out on the water and building a new boat because yours is on fire, it's a little late.
First time I've seen someone so accurately nail this effect of hiring junior engineers. I think this one is counter-intuitive to management, it's commonly believed that hiring more engineers leads to more manpower which leads to more work getting done and junior engineers are the ones that can be easily hired very quickly. I'm sure it's great for the careers of everyone involved, but it's awful for company productivity in the medium term.
I worked in numerous other industries and my friends have as well and there's not near as much analysis of science lab workers or truck drivers or restaraunt workers or nurses or social workers.
It feels strange.
some concerns are specific of our industry, like efficiency from high level languages. some are more cross cutting, like communication efficacy. some are more universal, like optimal working hours per week.
if you pick some common metric like that last one you'll see all fields share a great deal of the same issue and same research
There's decades of tech industry research and experience, and centuries of worker productivity data and management research.
However, there's a relentless drive in tech management to figure out how to squeeze more and more productivity out of the workers, all the while keeping them happy and maintaining quality products.
No other industry has that. Nurses would absolutely revolt if you told them that you were putting them in an Agile system in Jira and all of their productivity was going to be tracked down to the hour and once a month they had to hit crunch time and work an 80 hour week to meet deadlines and they had to meet everyday and justify their existence at a standup.
Nurses also have clearly defined goals, career stepping stones, licenses, specialties, etc.
Tech has none of that. The ideal hire is a ROCKSTAR developer that knows everything and doesn't need any wasted time on training, and would love to work their life away.
And management keeps trying to figure out how to make devs more and more like this.
"Behavior arising from class discontent, such as union activity, is derided as destructive and damaging. An appeal is made for “intelligent labor leaders to advocate efficiency in production to make possible the lowering of costs and prices” (Spriegel, 1947: 590). Even as early as 1928, an author argues that industry has moved past conflict and entered a period of “cooperative policies” (Anderson, 1928: 15), where harmony between workers and employers can reign."
> The ideal hire is a ROCKSTAR developer that knows everything and doesn't need any wasted time on training, and would love to work their life away.
"Frequently, the word “worker” is preceded by adjectives of various types, modifying the qualities and attributes of the person to whom they refer and thus judging that person to be “good” or “bad.” Spriegel (1947: 326) identifies “first class workers” in contrast to “substandard workers.” Anderson (1928: 320) talks about “indifferent workers and slackers” and “unintelligent workers” compared to “ambitious workers” (Anderson, 1928: 434). Folts (1938: 311) has “slow,” “medium,” and “superior workmen.” Balder - ston and colleagues (1937: 245) discuss the importance of “mentally alert” workers. "
https://www.researchgate.net/publication/271722189_2013_Cons...
To answer the latter half of your question, it is strange to not see that much analysis of science lab workers, truck drivers, restaurant workers, nurses or social workers, but I imagine that without the profit incentive there, the demand for research dries up. I wouldn't say that's a good thing, and it does indeed feel strange.
I can guarantee that nurses are analyzed to hell and back; everything in healthcare is analyzed to hell and back. After all, every pill is billed, every machine is billed, etc.
Social workers are also very very analyzed on their day to day work, so much so that there are passed laws compelling reports of suspected activities to the police.
Only in tech is there a relentless drive to figure out how to get more and more productivity out of us, and who to hire that will produce the most at the lowest cost, instead of a fair sane career path.