Skip to content

Instantly share code, notes, and snippets.

@jcreamer898

jcreamer898/README.md

Last active February 5, 2018 17:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jcreamer898/6f9b87eb5bd55d286903c3d1d102f4fb to your computer and use it in GitHub Desktop.
Save jcreamer898/6f9b87eb5bd55d286903c3d1d102f4fb to your computer and use it in GitHub Desktop.
Download ZIP
Raw
alex_robson_epic_tweets.md

I remain disheartened that we engineers continue to fancy ourselves capable of doing every role in an organization with only our passing awareness and effort - as if only engineering required lifetime dedication and on going study and focus.

What bitter hell have we wrought for ourselves? This is nuts. Of course our organizations collapse, our projects fail, and our people suffer depression, burn out, professional stagnation and “I left/am leaving tech” is a thing.

It stems to some degree from this attitude that the engineering is the hard part, everything else is easy, and we’ll just kinda do it in the dull moments and wear those extra hats. Please imagine the Batman slapping Robin meme

No, we can’t just decide we’ll “figure out” other disciplines that have, in many cases, predated ours, in our spare moments when we’re not tearing our hair out over the latest security zero day, broken dependency, slipped deliverable, retired third party API.

Engineering that aligns to the organizations objectives, that provides value, that is cohesive, well tested, up-to-date, documented, and free of security or major defect is rare and requires constant focus and discipline. No org gets there while eng juggles other things.

When you say, “I need to be a technical manager and remain involved in the details”, I hear, “I don’t trust my team and don’t know how to or will not spend time to mentor and coach them until I can trust them.”

It’s understandable that this is the case. I’ve been there. There are lots of reasons for it. A lot of orgs do not support the idea of mentoring and developing the people you manage. There’s not time alotted to this at all.

Instead the culture of “ship things like your livelihoods depend on it (b/c they do lol)” has been instilled in us - most software shops do not measure efficacy of features shipped, just the rate they’re shipped at. (One is hard the other is easy)

As they say, measure for the the behaviors you want - so we’ve built cultures where the idea of sloshing code into prod is more important than continuously improving culture, teams, processes and people. I know because it’s rare to find effective measures for any of these things.

This is why we have the reinforced and canonized concept of managers who must have solid technical chops - because we’re essentially “doing it wrong”. We should be open to learning and changing our org structure to improve vs. doubling down on broken structures.

And I get it, I’ve heard about teams with technical managers who ship. Fine, you’re shipping stuff, but you’re not doing everything you could be and it’s a disservice to your team, org and customers all so you can maintain control or stay technical (because you want to).

If you’re doing this, just realize:

  1. your team isn’t going to tell you you’re underserving them. The power dynamic is such that they can’t and shouldn’t have to. You’re kind being a bad manager just by putting them in this position, so “hi”, I’m telling you for them ...

  2. your org/boss isn’t going to tell you you’re doing a poor job even if morale is low or turnover is high because they’re not measuring/equipped to measure. Orgs tend to insulate themselves from “leadership is poor” signals in a myriad of ways - just know this is endemic.

  3. you can mask org problems by shipping “neat stuff” (even if customers give 0 Fs) because for a while, engineers will like solving fun problems and shipping code. You’ve only extended their burn-out/churn tail a little ~ maybe you’ll feel better about it all 🤷

  4. maybe be honest with yourself and everyone else - being a technical manager has less to do with the best org/team outcome and more to do with your comfort level and desire to control implementation (vs guide, teach & mentor) and get to code (code is fun!)

If you want to be a technical leader - there are or should be tracks for that in your org that are not responsible for managing and limit your control and responsibility to technology and implementation only. Seek that out rather than insisting on tech expertise in managers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment