
Heroes and Juniors: Increasing Engineering Team Velocity - mbellotti
https://medium.com/@bellmar/heroes-and-juniors-increasing-engineering-team-velocity-97ce6a59103e
======
yowlingcat
Wow, fantastic read. The author seems to fully internalize and understand how
when done well, it's not just junior engineers that grow but the senior
engineers that mentor them and the organization as a whole:

" 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.

------
majormajor
> What were small, scrappy companies in 2010/2011 are now either dead or
> medium sized companies with mounds of poorly documented, idiosyncratic
> technical debt — the apparent cost of ninjas and rockstars.

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!

~~~
peterwwillis
> how can you avoid tech debt when you're in an exploratory phase?

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.

~~~
war1025
> "We have to upgrade right now because everything is on fire!",

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.

~~~
peterwwillis
With DevOps you monitor [at least] four metrics: lead time for changes,
deployment frequency, mean time to recover/restore service, and change failure
rate. These indicators show if you're improving, stagnating, or straining. You
can also track more specific service level indicators, the amount of toil to
project work, and tech debt versus feature backlogs.

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.

~~~
war1025
I think we're both saying basically the same thing. So I agree.

------
kenhwang
> You want to start hiring more juniors because juniors slow down the pace of
> new growth and you want things to slow down.

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.

------
nickthemagicman
Does any other industry have as much analysis on the workers themselves?

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.

~~~
SolaceQuantum
_" nurses or social workers."_

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.

~~~
nickthemagicman
But there's a pretty established management structure, the roles are clearly
defined, the output is clearly defined.

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.

------
languagehacker
Great read. Can't agree with it enough.

~~~
wpietri
Same. Nobody was born a senior engineer. I learned through building. We need
to give everybody at least the same chances we were given. And hopefully to do
better for them.

------
edoo
I distinctly remember the point in my career where I realized shortcuts aren't
shortcuts if they increase the overall effort required in a project. Quite
often the seemingly slower and more expensive way is the overall fastest and
cheapest.

