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.”
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.
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:
Remember, if someone tells you that the chances of something happening are "next to nil" or "almost impossible" or even "highly unlikely," then the chances are still non-zero.
Next to nil isn't zero.
This axiom is clue that something is at risk and you should pay attention to it. It's not statistics that we should worry about it. It's our assumptions.
From: Lex Fridman's John Carmack Interview
It's not the writing of the program initially, it's the whole lifespan of the program.
No software project worth putting into production is ever truly static. Even a hypothetically bug-free application upon initial release has to change as it gets used in the real world. Users provide feedback so the UX has to change; the product owner or client of the application wants to tweak something; a new platform comes out for it to be deployed to; the app is so popular that it needs to be scaled up — any number of circumstances will force a change in software at some point during its lifetime.
Jira is a powerful and highly customizable software project management tool. Because of its popularity and long-time presence in the industry, there is a myriad of add-on and integrations to the platform, including Slack and GitHub.