Unicorns and Rainbows

I'm was in Sydney again this week, so this will be a somewhat unstructured and lightweight blog post. Feels like there have been a lot of those lately, which irritates me for some reason, but there isn't really anything I can do about it.

At least I'm keeping to a publishing schedule.

Anyway, on with the filler content.

A long long time ago, I tried to set up a regular schedule for learning, which was mostly just reading things. I even set up a Trello board of all of the things I was going to read.

I like reading, it's one of the best ways for me to absorb new information and inspire new thoughts, but it didn't really shake out the way I wanted it to. I haven't really done much with that board since I created it, and I definitely haven't carved out the learning time I initially envisioned.

Recently, I've been giving it another crack and I've been getting back into the habit of reading a little bit each morning. Since the start of the year, I've read three books, which isn't too bad, especially considering we're only four months in.

It's a hell of a lot better than the one a year prior to that.

The last book I finished was The Unicorn Project, and sort of sequel/side-story to The Phoenix Project.

Both of them are good books and I highly recommend them.

They are written in the style of a story, which makes them incredibly easy to read. Sometimes they can be a bit heavy-handed with the points they try to make about effective software delivery, but if you can push through that, there are some really valuable messages within.

I don't really like doing book reviews, so if you're interested in notes, you're more than welcome to read the comments on the Trello ticket that I used to collect my thoughts. They are pretty terse and a little incomplete, but I'm not here to provide a summary.

If this was enough to pique your interest, just read the book. It's not that hard.

Still here?

Alright, I'll ruminate on the content of the book a bit, but it's definitely not going to be a summary or anything.

I don't know if I've ever been in an organisation quite as bad as the one described in those two books, but there are definitely elements within that I recognise from first-hand experience.

Disconnection between roles (i.e. development, QA, operations, sales, marketing, etc) is definitely one that hits hard for me, because I once tried to form a truly cross-functional team at my old job with the goal of draining the pool of our legacy product and flushing all of those customers over to our Cloud replacement.

I failed pretty miserably at the time, and I suspect I would try a different tact if I tried again. For one, I wouldn't go through managers who have a vested interest in protecting their fiefdoms, I'd hit either above or below them, at executives or individuals instead.

On reflection though, I do worry that maybe I'm turning into one of those stupid and short-sighted managers that the book loves to slander. My team is a small cog in a great and wonderous machine, and we've struggled enough that I think I'd be pretty protective if someone came along wanting to steal some of my awesome people to form a truly cross-functional unit for some purpose.

In fact, I think I have been pretty protective in exactly that situation, so I need to watch myself more closely in the future.

See, this is why I love reading stuff. It makes me think and reflect and take a few moments away from trying to do things all the time.

I really should make more time for it.

But it's tiring as well, and there are always things that need doing, so when I get a free moment, I feel like I should be doing things or I'm going to fall behind.

I've trained myself to be like that, which saddens me.

But, it's never too late to change. You can always teach an old Todd new tricks.

Maybe.

We'll see.