Being a Responsible Software Team
On my last post, a prior colleague of mine commented that she feels product people should also strive to be “responsible” (in the sense I was talking about). I totally agree and thank Cindy for pointing that out. I don’t think it’s a problem in itself that product people supply urgency to product timelines from their vast reserves of the stuff. The problem tends rather to be in how that urgency is spread around.
In the last day, I kid you not, I’ve spoken at length with two prior, senior product folks I’ve worked with very closely. Given I had recently wrote about product-developer interactions, I probably noticed more than I otherwise would have the little subconscious predispositions about the relationship between product and dev. But this post is not about these individuals whom I greatly respect, much less about picking on them in any way. As I said, it is their job to think and act from the perspective of what’s best for the product and business.
I also know how very difficult effectively managing products can be. In many ways (sorry, devs), it’s a lot harder than crafting code. It’s not harder work in the sense if putting more effort or expertise into it, but harder in the sense of the incessant uncertainty that is the nature of the job, and having that be joined to the responsibility of making long-term decisions that will impact many people — the day-to-day lives of team members, the livelihood of the company, its employees and their families, as well as the experience of customers. (This is essentially leadership responsibility and so applies to more or less any kind of leadership, but here I’m just talking about product leadership.)
Added on to that leadership burden is the almost-ubiquitous notion that devs have that, given the time to focus on it, they could absolutely do a better job than X product/business person. That notion is manifested in the almost-as-ubiquitous behaving as if that were indeed true, regardless of the devs taking said time, which is to say devs are always second guessing product/design decisions, usually based solely on their own personal experience or opinion. On top of that, product people have the pressure from the business owners for real, tangible results in the market. Needless to say, all this makes the job of managing products not a little crazymaking. (I’m not saying that this is why I went back into dev, but…)
So I say all that to express sympathy with the latent urgency and apparent rashness that underlies much of product management. At the same time, I agree with Cindy that an ongoing effort from product people to help set and manage realistic product development expectations would not be remiss. This, I think, is where mutual respect and trust must come into play.
Developers Are People, Too
Unfortunately, that devs are essentially lazy and are more or less like children who don’t want to work hard and deliver product on time is a not uncommon impression that product people give. Whether or not this is stated in so many words, that’s basically how it comes across. I’ve seen this attitude manifest on different levels with so many product/business people over the years; I’ve heard so many devs talk about experiencing it, and I’ve seen it alluded to in so much industry literature that I don’t think I’m going out on a limb to generalize about it.
Unfortunately, that devs are essentially lazy and are more or less like children who don’t want to work hard and deliver product on time is a not uncommon impression that product people give.
If I’m being generous, I think this attitude is the result primarily of the regular disappointment that product people suffer, be it from shipping delays or from the ultimate product not being what they’d imagined it would be when they set us all on the course to build it. I’m sure it doesn’t help, either, that so much of contemporary software development culture is very.. kid-like? I mean, we have ping pong; we have pool tables; we get free food and drinks, fun outings, and often bright/playfully designed spaces, etc. etc. The impression caused by those perks alone can make it seem like we really did never grow up, because we work in Never Never Land.
Regardless of the reasons, though, it’s just an unhealthy attitude. I mean, sure, you’re gonna have people who really are irresponsibly child-like, but I can probably count on one hand the number of devs I’ve worked with that might truly fall into that category. Now whether or not we seem that way is another question entirely. Our never-failing desire to have fun and to tinker incessantly on more or less unimportant things can feel that way, but it’s usually kept in check, sometimes with help.
What we’re talking about here is, again, mutual respect and trust, and its lack. This manifests most problematically when a developer provides an estimate (not that I’m any huge fan of estimation, mind you, but it is a necessary part of a decision-making process), and pretty much inevitably the product person’s response is something like, “really? that long? can’t you do it faster??” (Or some less friendly version of that.) It’s like, yeah, we just made this up. Why don’t you go ahead and tell us when it’ll be done.
And even more damaging is to get something like “but you told me it’d be done” when something is delayed, or to get that look or to hear that tone. No sane dev takes joy in missing their estimates; we have professional pride and don’t like to disappoint people. We already beat ourselves up enough, and we don’t really need the help. I’m not saying “oh woe is us, we can’t handle a few harsh looks” but rather that these kinds of interactions (and others like finger-pointing, gossiping, and backstabbing) reinforce a supremely unhealthy relationship between folks who really need to have a great relationship for success to occur.
On the other hand, presuming that we are trying to be Responsible Developers is a better way — and most of us are at least trying. Plus, there’s the old maxim to keep in mind that people often live down to your expectations. I mean that if you want devs to behave as responsible professionals, treat them that way, even if you don’t feel that way, even if you feel you have evidence to the contrary.
Yes, we are notoriously bad at estimating. Much money, effort, thought, and ink has been spilled on how to make this better, and so far we as an industry have yet to find a reliable, widely repeatable solution. The insolubility of this challenge for the industry should be an indicator that it’s not because devs are bad or unprofessional or lazy or goofing off that things go off the plans. Rather, it’s the nature of this business (and much ink has been spilled on that, too).
We Need to Work Together to Improve
Of course there are things we can do to improve the predictability of software development. There are process things (my personal preference as of now is Kanban and what I’ll loosely call Design-driven development, a.k.a., a UX process). There are dev workflow things (like continuous integration and deployment). There are dev practices (like test-driven development and its ilk, peer code reviews, joint design sessions and reviews, pair programming, etc.). But none of these, nor all of them together, is a guarantee of predictability. Because making software is fundamentally a design endeavor rather than an engineering endeavor, it will always involve some significant amount of irreducible unpredictability.
Because making software is fundamentally a design endeavor rather than an engineering endeavor, it will always involve some significant amount of irreducible unpredictability.
That said, I guarantee that the less we do of these (and as far as I can tell not doing most of these is still the de facto state of our industry), the less predictable software delivery will be and, indeed, the software delivered will generally be of a lower quality, both in terms of UX and in terms of reliability/maintainability. And needless to say, this reduces both the near-term and long-term success of any software endeavor.
Too often, though, we (product/business and dev) give in to the desire for tactical success rather than doing the work we need to do in order to achieve strategic success. This is primarily the result of the pressure to ship. And this situation is exacerbated when we don’t have mutual respect and trust. By that I mean when (thoughtful) estimates are persistently questioned, scoffed at, and pushed back against, when devs are persistently peppered with “are we there yet? why aren’t we there yet?”, and when we get the distinct impression or are even told that we must be just goofing off, not working hard, wasting time, etc., only the heroic dev can hold firm and “do the right thing” for the long-term. This is, after all, partly what led me to write my last post encouraging devs to do just that — stand strong and do the right/responsible thing even in the face of such pressure.
I mean, it is so bad that some devs have even convinced themselves that our the industry best practices are somehow harmful, and even those majority of us who buy into them will rarely dare to push for having a solid UX/UI prototype or to be given the time to ensure adequate test automation. Heaven forbid we suggest TDD or pair programming! Plus, half the time we’re working with some new technology that we really don’t know very well. And we dare not admit that we “wasted” some time actually trying to better learn our tools, much less to ask for time to do so.
Software developers ought to be given the time and the trust to do their jobs responsibly. We devs and product people need to find better ways to foster and share a reasonable sense of urgency without sacrificing the long-term good of the product or, indeed, the company. We need to start treating each other with more mutual respect and trust (and that goes both ways).
We need to find better ways to foster and share a reasonable sense of urgency without sacrificing the long-term good of the product or, indeed, the company.
Product/business people need to work harder on empowering devs to do their job responsibly. Devs need to work harder on respecting the direction and decisions of the product/business people. Product people need work harder to respect responsible dev estimates and to be patient, understanding, and collaboratively find solutions when they are off. Devs need to develop an ownership mentality and work responsibly throughout the project. Together, without blame and recrimination, without looking down our noses at each other, we can much more effectively and efficiently deliver business value and long-term success.
