> Don't be too attached to your proposal. If someone makes a valid suggestion, then take it. Your goal is to find a good solution, not to prove that your solution is good.
Step 0. In most of the software engineering in our world, whether it's feedback, PR reviews, proposals, or technical docs, is leaving the ego at the door. These are our systems, and we're responsible for building them to the best of our knowledge.
Also, good tips on making proposals that people will actually read by using clear titles and sharing them early.
I couldn't help but relate to a situation I'm living in right now.
We are making changes in our team dynamics, from agile ceremonies to technical procedures of operational excellence.
Trying to put it all at once because "it's a best practice" would only create resistance.
I was super delighted with my manager making every week one little change. All of them fell into a larger vision, but in an approachable way that left nobody behind.
These tips apply to any change we try to introduce in any group of people. Thanks for sharing them, Raviraj!
Nice article Raviraj. Really like your visual too (70% people skills/30% technical detail). So true! One thing I'd recommend adding under your "Dos" heading: Bring a benefit to the table for each of your stakeholders. If you can show them how there is change, but that change is going to make their lives better... it can help with buy-in. 😄
This exactly was the case in my first company I worked at. A lot of proposals, especially those with a bit of a novel/different approach or technology, would be shut down by few loud opinionated voices. This would be very helpful at that time in my career!
I like the points you raised about being approachable. And, at the same time being proactive and not accepting being shadowed or ghosted. Those are keys to successfully raising a heard voice!
Very important topic especially for entry level engineers. I have worked in a hard team that kept me in the shadow as a junior all the time.
> Don't be too attached to your proposal. If someone makes a valid suggestion, then take it. Your goal is to find a good solution, not to prove that your solution is good.
Step 0. In most of the software engineering in our world, whether it's feedback, PR reviews, proposals, or technical docs, is leaving the ego at the door. These are our systems, and we're responsible for building them to the best of our knowledge.
Also, good tips on making proposals that people will actually read by using clear titles and sharing them early.
Great stuff, Raviraj!
Thank you Akos! It is hard to leave that ego out of the door but it is the essential first step!
I couldn't help but relate to a situation I'm living in right now.
We are making changes in our team dynamics, from agile ceremonies to technical procedures of operational excellence.
Trying to put it all at once because "it's a best practice" would only create resistance.
I was super delighted with my manager making every week one little change. All of them fell into a larger vision, but in an approachable way that left nobody behind.
These tips apply to any change we try to introduce in any group of people. Thanks for sharing them, Raviraj!
Yea Fran. These apply to most cases where we need to build alignment. Glad you loved it!
Nice article Raviraj. Really like your visual too (70% people skills/30% technical detail). So true! One thing I'd recommend adding under your "Dos" heading: Bring a benefit to the table for each of your stakeholders. If you can show them how there is change, but that change is going to make their lives better... it can help with buy-in. 😄
That’s a good callout, thanks
This exactly was the case in my first company I worked at. A lot of proposals, especially those with a bit of a novel/different approach or technology, would be shut down by few loud opinionated voices. This would be very helpful at that time in my career!
I like the points you raised about being approachable. And, at the same time being proactive and not accepting being shadowed or ghosted. Those are keys to successfully raising a heard voice!
Very important topic especially for entry level engineers. I have worked in a hard team that kept me in the shadow as a junior all the time.
Great read!