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”.
What I should have done was to
That would not only have been more fun for them to hear, but also much more helpful.
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!
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.
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.
There really are so many ways around the problems that we often think are dead ends:
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
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”.
What I should have done was to
That would not only have been more fun for them to hear, but also much more helpful.
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!
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.
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.
There really are so many ways around the problems that we often think are dead ends:
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