I have been hearing a lot lately about the focus on "Delivery," and it has always struck me as somewhat reductionist and linear in its thinking.
I mean, I get it. Somewhere, a group of (non/ex) builders said, fallaciously, that everything can be built and delivered as a trackable lifecycle. There I go now, being a reductionist, but the difference between building and selling is in play here.
My conflict concerns ownership of the software product and production of technical debt. This is informed by my personal experiences, so keep that in mind. Software work comes in multiple flavors, which primarily impacts the technical debt. For a long time, I have said.
"a software engineer's job isn't to build software but to manage, even anticipate, change."
The pragmatic programmers can leave now and go yell at someone else's clouds.
For those who remain, there is no reason we can't do both. Think of the box that we will ship now and the box that we will ship next week as distinct but part of a system. I often don't see that happen because, in my experience, the roadmap is less than six weeks long for many companies.
Let's talk about behaviors that are successful, though, and not mire them in Big Business Bullshit Bingo terminology. For a product to be successful and be deliverable it must:
- Have at least a 3-month roadmap with stretch goals
- Understand and have mapped the dynamics of the "socio-technical" system it will be delivered in [Teams, Vendors, Business Processes]
- Presented to teams as something more significant than a 2-week unit
- Must leave space for non-deliverables [System Design and Maintenance]
- Must be assigned champions, not just responsible for the team but for driving the completion of the work and owning when it will inevitably go a little pear-shaped.
That last one is the next thing we need to train and hire for: ownership. In the days of my grandfather, we would call it "pride in our work." I am going to do a thing, and I am going to be proud of it. If this seems abstract at all, I advise you to read "The Four Agreements" by Don Miguel Ruiz. It's a quick read, I promise!
We build ownership in a few ways, but the easiest is continuity of effort. We work on a problem until it is either SOLVED or GOOD ENUF. The vagueness of the latter is important. Consider this a real-life example of P versus NP.
"can every problem whose solution can be quickly verified can also be quickly solved"
The answer is Nope :)
"Good enuf" means we have at least awareness of the tradeoffs we made and have left some record of the decisions that led us there. So:
- Be proud of your work
- Be prepared to say no to work that doesn't have a clear roadmap
- Be prepared to ask for different if you don't want to be an SME
To be clear ownership is not being a Subject Matter Expert. Sometimes toxic, some of us don't want to be pigeon holed and that scares some from ownership. In a healthy work system three has to be a balance were what you do often will be things you have done in the past but it shouldn't be the only thing you do.
There is another tifle though, uninspired work, in this case I often see developers doing a little as possible to move on to something more interesting. Once again I go back to my grandfather who didn't believe in small work. There's a waste of time, and those don't count, it is our responsibility to contextualize the value of our activities and seek clearity when value is low. But, a job still needs to be completed, and doing your best work means doing the work until its Done. I see the opposite in places with uninspired work, the team kinda wanders off from boring work and take so long it gets re-backlogged. The choise of learning something new to solve a problem and letting it kinda become more expensive than its worth occurs.
This being the rarest trait I find in most workers, not just software, is doing the job right, completing the work, and having standards. Sounds rude yea, well sometimes the truth hurts, and thats a learning process. I am not judging you, but if you feel some pangs, well...