I used to think the best contribution I could make as a software developer was to know when to say “no”. What I should have done was to raise my concerns from my perspective about their requests or instructions, offer them some alternative options, and pointed out the key trade-offs.
I used to think the best contribution I could make as a software developer was to know when to say “no”.
- No to the product owner who wanted me to add fields in a part of the API where they don’t belong.
- No to sales who have already sold a feature in the new Europe division that they promised will be delivered in one month. It’s a bad idea. No.
- No to the Business Analyst who wanted us to just compare these two values with each other in a really cool chart. You can’t do that - you’re not comparing apples to apples - no.
What I should have done was to
- raise my concerns from my perspective about their requests or instructions,
- offer them some alternative options,
- and pointed out the key trade-offs.
That would not only have been more fun for them to hear, but also much more helpful.
Why would I say no?
This was probably mostly happening once I had a couple of years of experience as a software developer and a masters degree focusing on the industrial subjects. I’d attended the conferences. I’d watched the videos. I’d read the articles. I had seen some things in my time. And I was getting good feedback about my decisions. I rightly gained confidence.
I really had good reasons for my resistance!
- The API should be structured so that things are where you expect them. Just like a user interface. If you arrange things in confusing ways, API users are more likely to send bad data and someone has to end up fixing the mistakes. And chances are, sales will want you to fix clients’ mistakes to keep them sweet.
- If we rush a feature out just because sales sold it without talking to tech, things could get brittle and break more often. Or it gets messy and future changes become slower and/or more risky.
- We can’t just throw data into a visualisation and think it will be useful. It might not mean anything. It might even be misleading!
Who likes to hear “no”?
We all (ok, many of us) think our ideas are awesome. We came up with them. We applied our special sauce. Other people who think they’re not awesome just don’t understand yet!
In the cases above I was in fact saying no to people with the decision-making role on those projects. Who is this little worm who dares to tell them no? I was not making it easy for them to see my value.
But even teammates would find direct no’s frustrating. You’re making them do the work of asking why and looking for alternatives. Not kind.
Why are they even talking to me?
The reason they were even talking to me was because I was part of the team that should build the thing they want.
Perhaps it was a courtesy. They could have just stuck it into jira and waited for it to come out the other end of the software machine. That wouldn’t be fun.
Perhaps they respected my opinion. Or it was simply my role to give the tech perspective. I understand software development better than they do. I understand what’s really happening with the bits and the bytes. Instead I gave them another hurdle in their way to get things done.
Saying no doesn’t give the decision-maker the tools to make good decisions. They need to know what impact the different options will/might have. A technical person is at least a part if no totally responsible for turning tech details into variables like dev cost, downtime, and risk, which becomes a probable cost. This is what the decision-maker needs from the devs.
What are the options?
There really are so many ways around the problems that we often think are dead ends:
- The proposed API structure might actually make sense from the client’s perspective! Or it was just a proposal, and other suggestions are welcome.
- The new feature might not need all the depth you’re assuming. Are there bells and whistles you assumed? What is the minimum viable product? Is sales aware of the risks? Are they happy to ease up the SLA for this part of the product? Do they stick to their guns when on-call, overtime, and customer (dis-)satisfaction is estimated and made part of the cost-benefit tradeoff of this decision? Then it’s their decision to make, and their consequences to live with.
- What are the things that the data actually could tell you? Are users interested in that? The limitations and capabilities of a dataset aren’t particularly clear until you actually try to do something with it, so the options should really be explored interactively with a data person.
Why does this matter?
Saying “no” kills innovation. Instead of greasing the creative process by raising concerns, options and perhaps missed opportunities, “no” is a stumbling block. Perhaps the person with the idea has to gather themselves from the surprise or disappointment of hearing “no”. Then someone has to take the initiative to start ideation for problem solving again.
A challenge can be an opportunity to notice angles of a problem space that weren’t noticed before. And along with the new perspective on the problem, you might see new opportunities. It doesn’t have to be a negative thing. It was always the reality. You only just noticed it.
At OpenUp we seek to empower people and government, through data, technology and innovative-thinking, to become active agents in creating positive social change.
If we kill ideas before considering the alternatives and trade-offs, we will be missing out on a lot of opportunities.
If you like the way we think, please get in touch. We are currently specifically looking for senior software developers who propose options and tradeoffs while protecting the bits.
If you think we’re wrong, mail us anyway, and let us know!
Cover image adapted from “Man photo” created by cookie_studio - www.freepik.com
