And it's not just the ideas that come from outside but ideas of doing something different, like having a cup of coffee with colleagues at least once a week. I'm often even commented down on naming variables in pull requests, only sometimes to something I agree is a better name but I stop fighting so that we don't get stuck. We get rejections of our ideas all the time.
When you learn all your ideas are rejected, you move on to only dealing with ideas on a personal level and obeying ideas of powers to be. You take what others are offering, and within the box of them not seeing you do things, you do what you can do right inside that little box.
I'm someone who counts. I count how many times my ideas get brushed down. I count how many times I brush down other people's ideas, and who are the people who reject other's ideas the most. I have been rejected a lot, yet I still keep trying because when I need to give up, I need to give up on the industry.
Here are some ideas of how I deal with that rejection that we get in the teams:
- repetion. Ask once, ask again. Kids have no shame in this, but adults get punished fairly soon. So if you repeat the same ask, be careful on how much annoyance you will add. A weekly repetition is probably better than repeating it many times in a row. But also, people end up liking things they've heard of many times better than those they hear 1st time.
- finding right time. Ask when they are more likely to say yes. Did you know that asking to get out of jail as a convict, you are more likely to get out if the time of your case happens just after lunch? Asking after completing a major milestone is likely to give different results than asking while you are in the middle of that worst crunch.
- prioritize what you ask for. You'd like to see 10 changes, so select one. It could be the one that means you the most. It could be the one they are most likely to accept.
- finding right words. It's not what you say, it's how you say it. Sometimes it is true, sometimes it's an excuse. Try to find a way of explaining it that makes the one listening to your proposal understand it. It could be logic. It could be financial benefits. It could be an appeal to your personal happiness ('yay, that worked for me on ensemble (mob) programming').
- finding right messenger. Sometimes you will never be heard, so send someone else. I did this to get no estimates started a few jobs ago and too many times I could quote since. I like to say: "best ideas win if we care about work over credit" and feel sad how much of my credit I need to move away before reclaiming it through promoting results.
- finding right medium. Some people react better to verbal while others react better to written requests. Some people forget all things verbal and are only safe being asked in writing. Use one first, another later.
- convincing a subgroup. If you have a few people suggesting something, some folks here groups better than individuals. You may need to get buy in from people who are not making the decision to get through to those making the decision.
- make it sound temporary. Call it an experiment. Agree on a time you will do it, and when you give up, even when you are really thinking you should keep doing it. This worked great to get to having an agile team with no product owner and results that were improved significantly.
- confronting the rejection pattern. Tell people you've observed that your suggestions are rejected. Keep track of what ideas they did reject, and suggest a rule that they must experiment with at least one every six months, or one out of ten you produce. This one is DANGER!
- visualizing of whose ideas we went with. Draw on a whiteboard a tally of names and label that as ideas proposed/implemented. See if seeing the pattern helps people realize they could work with it.
- showing it works without the others. Just do it yourself. A lot of tech ideas only get traction if you show up with a prototype that works. You could also find others in community instead of your organization, and work like you wanted on your free time on learning projects.
- build a track record. Get some of your ideas through. Show you can try small and are willing to step away if they fail. Building that confidence may help them hear you better.
- create a patience raindance. Create a little routine that helps you through all this rejection so that you still can try again. My patience raindance routine is tweeting. It's a mysterious call for powers to be on granting me patience to try again until I succeed in getting to a happy place.
- amplify ideas of others. Don't be the person who shoots other people's ideas down. Try to approach them with the "let's try it out" attitude even when you hate it. You'd like them to do it for you, do it for them.
Finally, dealing with rejection is a skill, and your need of developing that skill depends on your status in the organization and team. It is likely you will deal with this more if you are a tester and if you are a woman and even more if you are not white. Cope with rejection, but never ever give up. Only through the No you can get to a Yes. Protect yourself on the way there with versatile strategies of knowing when to give up and how to get to a yes.
This blog post is brought to you by a twitter pile on of helpful agilist who seem to think getting rid of or changing contents of a daily meeting is something you just change in a team. They may come from a position of privilege where when they point out a change people just do it, but I find myself more often not in that situation and thus employing all the ways I have to be tenacious and get there anyway. I've been there too, and I recognize the difference.
