2019 - Windsor, NSW
“Play the guitar so I can sing,” Mum says. “What’s that song…by Don Henley?”
“Heart of the Matter?” I reply.
“Yeah, that. Play that.”
“Do it or I tell the Marie biscuit story,” she says.
My sisters and I groan in unison. My sister’s boyfriend leans forward, asks the question we don’t want him to ask. “What’s the biscuit story?”
It’s an old favourite. There was a time when mum was young and she hadn’t eaten for days. A couple of neighbourhood kids teased her with a small pack of Marie biscuits. …
“A system of cells interlinked within cells interlinked within cells interlinked within one stem, dreadfully distinct…”
—Baseline test, Blade Runner 2049 (2017)
If you work within a fairly large software development organization (say, >150), your organisational structure might have different supergroups, each composed of multiple teams. It might look like this:
Each supergroup would have a different mission and priorities, which branch off to multiple individual teams, each with a different mission and priority, composed of individual developers with their own internal rubric of missions and priorities —
You get the idea.
If you’re particularly lucky (or unlucky), the group…
“So, what do you want?”
When I was an engineer, there were few conversations that I dreaded more than the career development chat.
This piece aims to provide a frame by which to tackle career conversations in a way that’s investigative, hopefully less shit, and factors in the myriad diverse ways that which people have an answer to the above question. If you’re a manager, I hope some bits of this are helpful and add to your toolbelt. If you’re reporting to someone, then I hope this provides a frame by which to have those conversations.
So, here we go…
No one knows you here.
You step inside the halls of your new job, all steel and marble and fiercely-lit screens and blinding lights, and it’s a far cry from the small, sooty startup spaces of where you came from. This is the city, goddammit. You’re not in the country anymore.
Onboarding is a blur of faces and names and teams and terms that you won’t remember in a week. Hell, it’ll take you months before things start to make sense. …
Outcomes first: In the span of six months, we stood up three practice leadership groups in MYOB. The groups were managed at first: in order to provide people with the tools to be able to assemble and produce decisions. A year later, they remain incredibly active and autonomous — providing the org with a couple of nice things:
This is a short, practical guide to CVs and LinkedIn profiles from the perspective of someone who has been on the other side of the hiring process for a while. Each company will be different: so a grain of salt may be required.
However, I can talk about what has worked for me, and I hope that it helps you too.
A tremendous lot of recruitment happens via LinkedIn — so if you’re looking for a job, it’s worth putting some work into making sure that you’re visible and pop up in aggregate searches. …
Maintaining software consistency is a bit of a gummy task: it’s indirectly tied to the dollar-value of work, and the by-effects of not looking after it are slow and sometimes not easy to see. In a lot of ways, the reasons why it is difficult is why tech debt in itself is difficult.
There’s a ton of ways to attack the problem —and there’s not much that’s canonical. What I hope to accomplish here is to provide a very narrow frame by which to tackle the issue: in that consistency is a byproduct of two functions:
A.) Mechanisms by which…
A good job is like a good game: you know what your goals are, all the tools you need at your disposal, and there’s a fair bit of challenge.
In the next few minutes, I’m going to unpack an assertion: that engineering management roles are way analogous to RPG classes. I hope it’s mildly useful.
Both groups are composed of differently-skilled individuals acting towards a common goal (or a quest, if you will)— each with their own role and motivators.
Success is usually a function of how well the party members execute on their roles, and how well…
Software organizations change a lot — they morph, they scale out, but they almost always never sit still. Structures change.
There’s a point in every restructure conversation where the word “culture” is bandied about: that if we retain our perceived working culture (“…as long as we collaborate…!”), things will be fine. There’s a key problem here: in that the approach seeks not to create culture, as much as it relies on it being an organizational bandaid.
Culture is not merely an input into a process. The working culture of an organization is largely informed by how it chooses to own…
Over the next couple of minutes, I’m going to talk about some of the ways that we teach DevOps to graduates — in a way that’s cheap, effective, and fair. But also, fun. And while this is focused on graduates, I hope that this also somehow applies to onboarding new team members (and maybe even your own goal setting exercises).
Bit of background: Like many other companies, my current company offers a graduate program that allows for “rotations” — to join teams for a finite amount of time. …
DevOps. Stories. Guitars. Motorcycles. Melbourne.