A slightly silly history of leading programmers – Part 3

Welcome to the intermission of our story.

(Part 1 of this story is here

Part 2 is here.)

Besides a bio-break, let’s pause and remember why we’re here.

I’m here to help improve our technical management and leadership skills.

You are here for many different reasons, and there are many of you now (over 5,300!). It would be foolish of me to think all of you are here for the same reason.

Even more foolish to think that you each are in the same place, need to hear the same advice, or learn the same lesson.

Each of you is an individual, just like me.

It would be easy to think of myself as the “leader” of this group, but in truth, I’m just the guy with the microphone.

And today, the guy with the microphone isn’t sure where the story should go next.

I know, leaders aren’t supposed to admit when they’re stumped. But I am, so why not admit it.

Why we started on this journey

See, I can imagine the story turning in many different directions from here, and each turn leads to a different lesson.

So let me return to my original reason for writing this story, which I haven’t shared with you yet.

It started when I asked myself, “Marcus, I wonder why managing programmers is so hard, and why managing is so hard for programmers?”

One answer I came up with was that the science and practice of management was unprepared for the impact and complexity of computers.

And maybe the computers, and particularly the computer-people, threw a wrench into traditional management approaches.

I sorta like that idea – that we broke the system. Maybe that’s the rebellious side of me.

We messed with it until we broke it

It also might give us a hint about why managing programmers is hard, and why managing is hard for programmers.

Maybe managing programmers is so hard because… they hate being managed. They might not mind being led, as long as they believe in the leader.

And, just maybe, managing is so hard for programmers because… well, the same reason: they hate being managed. They find traditional management ideas brutal, brutish, and bossy.

We might imagine that the computer-people marched into the old, venerable cathedral labeled “Management”, placed dynamite against the footings and blew up the building.  Quite a revolutionary idea, right?

And then, standing proudly around the rubble, we looked around and asked, “Okay… now, what goes its place?”

A collective shrug occured, and we went back to coding. ¯\_(ツ)_/¯ 

I must admit that the majority of my work has been piling more dynamite against the old establishment, blowing those ideas to bits.

Which is fine… but I’ve done little to build something in its place.

This story, and the choice of where to take it, revealed this pattern to me. Amazing what lessons life offeres from the most unexpected places.

This touches on another reason programmers (and designers, devOps, UX people, product owners, and ‘makers’ in general) have a hard time with management: if we’ve destroyed traditional management, what’s left in it’s place?

Through writing this, which truly is a dialogue with myself, I see now that I want to build new ideas up rather than simply tearing old ones down.

I don’t quite know where the story will go, but that’s the direction I’m going headed.

A sneak peek

I’ll give you a sneak peek: I think the answer is ‘leadership’, and a particular idea called “Relational Leadership” has worked best for me.

Thanks for joining me on this journey, and sitting through the intermission.

Got thoughts on this?  Write me back. 🙂

Best,
Marcus

[SPONSOR] GitPrime helps you have more meaningful, impactful conversations with your engineers, facilitated by real engineering data. Win-win!