Leadership Without Management: Scaling Organizations by Scaling Engineers

• was going to be titled “Software Engineering Middle Management: Toxin or Cancer?”
• Brooks’s Law: “Adding people to a late software project only makes it later”
• Software Engineers are not equal
  • Steve McConnell’s “10x effect”
  • a 10x engineer not only is more effective as an individual, having 1/10 as many engineers lowers your drag (communication, etc.) significantly
• ok, so we want the best engineers, and only the best engineers. how do we find them? how do we motivate them? how do we not demotivate them?
• Motivators
  • my background
    • if you describe oracle without ending in nazi allegory, you have left some understanding of oracle on the table
    • if you were attempting to explain the nazis to someone who had never heard of world war 2 but was an oracle customer, you would actually explain the nazis in oracle allegory. “imagine that larry ellison controlled a country” “oh jesus, i mean, my god, the license audit!” “yeah, yeah, the license audit. we called it blitzkrieg it was really ugly”
  • mission - the ‘why’ of the endeavour - this is how we serve humanity
  • the team
  • the technological problem
• not a motivator: compensation
  • compensation is no higher and no lower than the next thing
  • Joyent has beat out Google and Facebook in spite of their offers sometimes including stock grants (not options!)
  • the amazing thing about Google is, you would never know who you’re working with. “but don’t worry, it’s google, we’re all brilliant”, it’s like “yeah, yeah, yeah, you’re all brilliant, but some of you are assholes, and i’d just like to know, y’know, who i’m working with”
  • if you focus exclusively on compensation, and you don’t emphasize those other things, you’ll get the wrong kind of people; the second they get a better, dumber offer, they’ll leave
• Demotivators
  • These tend to be systematic
  • Bryan’s own history
    • when i was offered a VP Engineering job at Joyent
    • every VP I have ever known, at sun, without exception was a jackass or become a jackass when they became a VP
    • I’m gonna do an experiment. I’m just not gonna do what I know I shouldn’t do. And then I’m gonna hope – like I’m a sculptor – that what I’m left with is plausible.
  • Formalized annual review
    • Feedback is essential
    • Too formal
    • It’s the wrong cadence
      • If I wanna burn the place down I should do it like immediately after my last review so you’ll forget it. By the time the fire finally simmers down, you actually forget that I did that, and we can talk about the things I did in the last 45 days.
    • It always pissed me off
    • There’s this obligation, I have to give you “something to work on”, aka “something to ding you with”
    • You get dinged on your personality (too shy/not shy enough), and other things you can’t change
    • Negative feedback doesn’t work. If you don’t believe me, have some kids.
    • Writing your own review
    • Literally, I had a manager who would only introduce grammatical errors into the review that I had written
    • “Bryan is a first-grade debugger” “I made a huge mistake of telling my mom about this, and she nearly died laughing”
    • annual performance review is named in Peter Deming’s “Seven Deadly Diseases of Management”
  • Hierarchical Titles
    • The ‘dual ladder’ is a plus, means that tech people can advance without going into management.
    • The n+1 shithead problem
      • I don’t care how enlightened of a thinker you are. When someone at the next grade up acts like a jackass, it just deflates you. You say, “like, wait a minute. If Johnny Jackass is n+1, why am I not n+1. And I always counsel people that instead of fixating on that one jackass at that grade above you, focus on the best possible person at that grade
    • It means when someone else gets promoted, you’re actually angry about it: “why not me”
    • every time I was promoted, my attitude was “guys, it’s about time”
    • Hierarchical titles are not uplifting, they are corrosive
  • Ranking
    • Force an absolute ordering of top (20%) to be rewarded, middle (70%) to be ignored, and the bottom (10%) to be terminated
    • Amazon “top grading”, Microsoft “stack ranking”, GE “rank-and-yank”, Intel “ranking-and-rating”, Motorola “individual dignity entitlement”
    • By fiat, no set may have more than a fixed number of top performers (irrespective of real performance)
    • It’s also a self-fulfilling prophecy, top performers will leave
    • At Sun, when you had this top rank, you had to get promoted. So if you’d just gotten a promotion you were ineligible for the top rank, and you’d oscillate between high ranks and low ranks.
    • Quotas quickly arise via organizational jockeying
      • some jackass director out there will say “all my guys are top performers”, even if they’re off on some inbred island that everyone knows is a jail sentence. so you have to kind of divvy them up and quota them around, and then you have organizational jockeying
    • Then you ultimately have the mother of all perverse incentives: you are actually incentivized to not work with good people, indeed to seek out the opposite “hey, you seem like driftwood, wanna come into my organization”
    • then you’ve got the junior engineer that’s like “man i can’t believe bob is still here. bob has been dead for two years. he’s mummified in there” it’s like “yeah yeah, i know it seems ridiculous” “it is ridiculous” “no no, it seems ridiculous. but it’s not, here’s why. bob always gets the lowest rating. so trust me, you want bob. bob is the reason i’m able to promote you. so next time you see bob, you give bob a pat on teh mummy over there”
  • the Purple Robes Club
    • noticed by the presence of titles like: {distinguished, principal} * {architect, fellow}
    • people got in (or got excluded) for all the wrong reasons
    • architectural review = good; architectural review boards = bad
    • sets up a class of putatively technical people who ratify decisions but whose job is by now mostly to go to meetings (but in fact, nobody’s job should be to go to meetings)
    • one of the things to do is to game the architectural review board
      • throw up little walnut sized issues that everyone can wrap their brain around
      • make sure to feed both sides of the argument until the clock runs out
  • Non-technical management
    • can’t resist channelling Frederick Winslow Taylor (measured time to complete a repeatable, rote task, and divided 8 hour days by that amount, to set expectations)
    • If you’re doing software engineering right, you’re never solving the same problem twice
    • It’s hard for non-engineers to fathom that there are unknown unknowns.
    • Of Functionality, Quality, and Schedule, you can pick only two
      • by the way, if you pick Functionality and Schedule, I’m outta here, and so is every other high-quality engineer, because I don’t want to deliver shit
      • It’s sort of like CAP in that way (where Partition tolerance is non-negotiable)
      • You can only pick Schedule when the unknown unknowns are off the table
    • Non-technical management is a recipe for date-driven death marches
  • Ex-technical management
    • retain the confidence of an engineer, but lose the humility that is forced upon an engineer who must get a complicated system to actually work
    • It’s essential that those in formalized leadership positions continue to directly contribute technically – if only to maintain empathy.
  • Inability to Focus
    • Top engineers will try to tackle all of a world’s problems
    • Steve Jobs’s 1997 WWDC Keynote listing a bunch of projects they were going to kill in order to focus
  • Autocracy
    • Present engineers with problems, not solutions
  • Shilly-shallying
    • Right-thinking engineers will usually fail to reach consensus for one of two reasons
      • personal style (tabs vs spaces) “we’ve gone to a states rights model, where every repo must be self-consistent, and there must be a style tool that checks it”
      • insufficient data, in which case either agree to get more data or make a choice that forecloses on the fewest options
• Software engineering leadership
  • The best engineers are also natural leaders
• Finding superlative engineers
  • engineers you have worked with who you know to be good
  • talented, promising university graduates
  • individuals in open-source projects that your team leads
    • this is your farm system, this is your minor leagues
    • you see how they think, how they communicate, and their code
    • this is a way for the talent to find you