Someday I really want to write a book called “stuff no one will teach you”. The problem is that technically I want to teach you these things and suddenly the title becomes an oxymoron. This is the kind of thinking that keeps me up at night.
In the late nineties I worked as a presales engineer in an enterprise sales organization. It was a very different experience from building products and I learned a great deal in that role.
Decades later I find myself applying some of the lessons I have learned and passing on those learnings to people I work with.
Let’s talk about one of those lessons today!
A previous employer had a process for new software development where the lead engineer would write up a technical design document and present it for review in a meeting with engineering leadership.
These reviews were often savage and the outcomes were a mix of “go do it over” and anxiety.
I watched a few of these happen with the same curiosity and horror one might have driving by a road accident. I decided to see what I could do to help make this experience smoother since one of my engineering leads was about to go through the process.
I asked one of the senior engineering leadership why these meetings were so brutal. He smirked and told me that quite often these meetings were usually the first time that people presented ideas to him, and quite often they were missing some key considerations for a popular game at scale. The feedback given was sincere and in earnest—it was just horrifying to the person writing the document because they did not consider very important things that were necessary.
I was a little surprised. I decided to confirm my suspicions and speak to the engineering lead who was about to make his presentation.
Sure enough, he had not shared the document in advance for feedback.
These review meetings were not a place for someone to get feedback that required substantial redesign. They were supposed to be a place where maybe one or two small tweaks were needed to get the design as good as it can be before starting development.
Because this is the first time that some of the senior leadership were seeing the designs in question, quite often there was something significantly missing or an assumption that was fundamentally wrong.
I encouraged the engineering lead to set up a thirty minute meeting to go over the design in advance.
The leadership review afterwards went smoothly.
One of the things that engineering leaders need to learn on their voyage is that you should not be afraid of asking for help or guidance. I encouraged the engineering leaders I was managing to be sure to get advice and guidance before putting their software designs up for review.
Maybe the time I spent working on a sales team helped me to understand the value of getting your work cross-checked. We would always have presales meetings and do dry runs of our pitches and presentations. Even now, I spend time sending materials over to my peers, and similarly review their presentations before sending them off.
I have always found that I have been rewarded by doing some additional work to make sure that projects and presentations have had extra eyes on it.
Most organizations have a formal review process and it is always a good idea to make sure that people who make yes/no decisions on your projects have as much opportunity to achieve understanding as well as put any concerns on the table privately. If you can get some good feedback from them on things to add or adjust, that is also a benefit to the overall product, and I think people enjoy hearing you thanking them for the ideas when it is finally time to get the project approved.
Do not be afraid to put some extra work in before presenting a new project for approval at work. The more time you spend outside of that meeting making sure that all of the stakeholders have an understanding and a window to give you feedback and suggestions, the less time you will need in a large room filled with stakeholders making adjustments and addressing issues.
It makes your project look better and it respects the larger group’s time.
This does not just have to apply to project work. When I am sending emails around crucial conversations at work, I also reach out to people to get feedback.
You should give this a try at work. Collaborating with decision makers and making sure you have great shared understanding with them will only help you in the long run.
Thanks for reading along! I look forward to telling you more stories next week and seeing if there is something with which I can entice a profit-making click from you with my Amazon Affiliate account. Every two or three months they send me a reminder that I have made zero nickels and that the pending balance will carry forward. Clearly a case of “tell me I am a bad affiliate marketer without telling me I am a bad affiliate marketer”. I accept it as honest feedback even if it is attempting to gaslight me into selling more.