13 posts tagged with "project management"

Make Your Voice Heard​

I was recently on a call where someone spoke up to challenge how we defined and used a single word in our burgeoning project.

One single word.

I just applied for any engineering management position. They asked in the application submission process, "Tell us about your biggest achievement or personal success in customer support".

Personally, I think it's nice to have a space just for that sort of question, pre-interview, that doesn't take up space in the resume or in the cover letter, so I appreciate the question. This is what I said:

I was looking over the DORA metrics, trying to think of a mnemonic for the four options that would roll of the tongue a little more easily than "Lead Time," "Deployment Frequency," "Failure Rate," and "Time to Recover." I mean, "DORA" itself isn't even helpful, since it stands for DevOps Research and Assessment, which is the name of the project, not a acronym for the metrics.

There’s no silver-bullet metric (or set of metrics) at the individual level that doesn’t either require extensive context or can’t be gamed by the developers, or worse, might be misused by the upper-echelon, looking for excuses to “clean house.”

This concept comes up in conversation more often than I care to admit: "Project Management Office (PMO) is just another layer of bureaucracy". This is an overly simplistic point of view, so let's think about it in terms of the human body.

I wrote this originally a few years ago for teams whose members were new to each other; these suggestions acted as a guide to understanding my perspectives. I know that everyone has different points of view on how to run a project. By making myself the locus of attention, the idea was that the team could debate with me about the details and we could come to a consensus that worked for everyone.

Preamble aside, let's read on!

I’ve written this document because, over the past few years, I have encountered one too many situations with developers not living up to their own expectations.

As a developer myself with a couple of decades of experience under my belt, I’ve seen a lot of examples of how code can go wrong and how painful it can be to fix them when the PM comes along with a new feature request or important bug fix. As a project manager I’ve had to deal with the consequences of those poor coding decisions, spending an inordinate amount of time and social and political capital trying to smooth things over when a client gets upset because we went over time and budget.

I’ve been away from my computer for quite a bit recently, hard at work in the Texas heat (don’t worry, I keep well hydrated and take lots of breaks) fixing a limestone patio. It’s a lot of moving dirt around, lifting and placing large stones, and planning.

Planning. We can never evade it, can we? Whether building a new house, fixing an old patio, or creating the latest revolutionary digital product, planning is always there.

OKRs: Objectives and Key Results.

Oof, how they bother me sometimes. Nothing wrong with them per se, except they sometimes obfuscate what should happen behind just another TLA (Three Letter Acronym), an idea created from the heart of Intel (who I used to work for), as notorious for their overuse of acronyms as the US military is.

I’m wrapping up a not-quite two month software project right now and we’re in the midst of finalizing with stakeholders, doing retrospectives, and digesting all that has happened. During the project I kept copious notes and I can make a few definitive comments: