FutureStack Tokyo 19 -ăăŒăăăŒèŹæŒïŒœăąăăŸăł ăŠă§ă ă”ăŒăăč ăžăŁăăłæ ȘćŒäŒç€Ÿ: New Relică掻çšăăAWSăžăźăąăăȘ...
means a pretty specific thing in the tech community right now
but can also be someone on your team
these roles interact, sometimes in indirect ways
and they decrease in visibility, with rockstars taking home most of the glory
interestingly, the amount of unappreciated work they do is disproportionate to their visibility
people are unhappy and not doing what they want
can try to make something like reliability a first class citizen, but people confuse that with not changing anything, so itâs a tough sell
can try rotating responsibilities across teams, but some teams will be better at some tasks than others, and this will evolve back into an imbalance
what to do?
1969
kemmer
do you know how big my engineering organization is? how specialized?
but there is rockstar, builder, and janitor work on every team
and everyone should have the chance to be a rockstar, builder, and janitor within their own teams
people arenât just focused on their slice of the system lifecycle
Code defensively so they donât get paged
build more flexible and adaptive systems that are easier to reconfigure
foster new skills on your team
how will people know if theyâre good at something if they donât get the chance to truly try it out?
engineers can spend one week on each role
1 week isnât enough to develop a new feature? agreed, so letâs expand
first week they are once and janitor - getting paged and putting in bandaids
next week theyâre a builder and hardening what paged themâŠempower them to never get paged for that thing again
2 weeks theyâre being a rockstar and building new things
this gives us this balance of roles
which looks similar to the preferred state from the survey
the more you focus on builder tasks and defensive rockstar tasks, the less time youâll need for janitorial ones
and if you need more than 1 week per engineer for janitor tasks, then you have technical debt
and you need to stop building new things and focus your entire team on cleaning things up
you can go a lot faster when youâre not on fire
addressing technical debt is key to productivity
Entire white paper dedicated to tech debt called âA simulation study of practical methods for technical debt management in agile software developmentâ
Formula adapted by Greger Wikstrand
decommissioned 1,139 applications in 2013 alone
systems in use has reduced from 7,000 to 4,200 in three years
generally ops teams are understaffed and under appreciated
they have been down in the guts of your company for years and have had little opportunity to improve it
they canât improve it when theyâve been firefighting this whole time
ops teams have a pretty good idea of what janitor and builder tasks look like, itâs time to let them be rockstars
so start the rotation here first
wait a minute - ops stuff is always breaking
surely they should be heads-down in janitorial work?
ops doesnât happen in a vacuum
they are support code that developers put there and it turns out itâs not as resilient and scalable as you would hope
what keeps you up at night?
whatâs about to fail?
what did you bandaid and forgot to tell the team?
what is smoldering? what is about to explode?
what did we push out the door at 80% done?
what could run faster?
what could fail quicker?
what needs to be scaled? what needs to be rearchitected?
what excites you in the ops space?
what tool or system would make our environment better?
what do you play around with at home?
what do you read about online?
wonât dedicating some ops people to rockstar work cause upstream pressure on dev teams?
devs need to feel the consequences of their actions
they need to see the backlog they create that ops has just been silently dealing with
and they need to be aware of the new process thatâs about to hit them
devs donât own their infrastructure?
thereâs plenty to do at home
I think most of us understand what rockstar tasks look like for dev
load testing, performance testing, integration testing, penetration testing
what interdependencies have we built? who relies on us?
how can we scale our people processes?
what has support been alerting us to?
what did we push out too fast?
what bug really needs to be addressed?
what part of our tooling has decayed?
what needs to be revisited?
what tests can we write?
how is our logging? our monitoring?
what could be rewritten? what could be EOLd?
aside from the roadmap, what do you want to see?
what automation or tooling could we add?
what new language or platform are you interested in?
if the idea of dev doing non-rockstar work bothers you, remember that they are already doing it
theyâre just not getting recognized