Rock Stars, Builders, and Janitors: You're Doing It Wrong, New Relic [FutureStack16]

Editor's Notes

• #3: 3 part question
• #9: means a pretty specific thing in the tech community right now but can also be someone on your team
• #18: these roles interact, sometimes in indirect ways and they decrease in visibility, with rockstars taking home most of the glory
• #19: interestingly, the amount of unappreciated work they do is disproportionate to their visibility
• #43: people are unhappy and not doing what they want
• #44: 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
• #45: 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
• #46: what to do?
• #48: 1969 kemmer
• #52: do you know how big my engineering organization is? how specialized?
• #55: 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
• #56: people aren’t just focused on their slice of the system lifecycle
• #57: Code defensively so they don’t get paged build more flexible and adaptive systems that are easier to reconfigure
• #58: 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?
• #59: engineers can spend one week on each role
• #60: 1 week isn’t enough to develop a new feature? agreed, so let’s expand
• #62: 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
• #63: this gives us this balance of roles which looks similar to the preferred state from the survey
• #64: 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
• #65: and you need to stop building new things and focus your entire team on cleaning things up
• #67: you can go a lot faster when you’re not on fire addressing technical debt is key to productivity
• #68: 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
• #69: decommissioned 1,139 applications in 2013 alone systems in use has reduced from 7,000 to 4,200 in three years
• #73: 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
• #74: 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
• #75: wait a minute - ops stuff is always breaking surely they should be heads-down in janitorial work?
• #76: 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
• #77: 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?
• #78: 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?
• #79: 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?
• #80: won’t dedicating some ops people to rockstar work cause upstream pressure on dev teams?
• #81: 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
• #82: devs don’t own their infrastructure?
• #83: there’s plenty to do at home
• #84: I think most of us understand what rockstar tasks look like for dev
• #85: load testing, performance testing, integration testing, penetration testing what interdependencies have we built? who relies on us? how can we scale our people processes?
• #86: what has support been alerting us to?
• #87: what did we push out too fast? what bug really needs to be addressed? what part of our tooling has decayed?
• #88: what needs to be revisited? what tests can we write? how is our logging? our monitoring? what could be rewritten? what could be EOLd?
• #89: 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?
• #90: if the idea of dev doing non-rockstar work bothers you, remember that they are already doing it they’re just not getting recognized
• #100: safe harbor