Meeting frameworks to use between architects, developers and clients

For us as developers I guess the toughest job is to get perspective of human being who is not technical and explain your technical knowledge to somebody who does not understand it completely. It might be our point to grow. I asked few of my past clients to give me honest feedbacks about my work and work of other people. I decided to share some tips by summarizing feedbacks and share what I have learnt to myself.

Here is my personal list of things we should do before the meetings:

1. Get ready and ask questions before you start (the best is to put questions in the meeting agenda). Don't be afraid to ask questions to fill in the gaps. This shows you are thinking critically. Instead of waiting for a problem, proactively identify potential issues. For example:

   • "What happens when...?" "What happens if an account has more than five open opportunities? Should we show a 'View All' link, or just the top five?"

   • "How should this be handled...?" "How should we handle situations where there are no open opportunities? Should the component be hidden, or display a message?"

   • "Is this feature a 'must-have' or a 'nice-to-have'?" This helps prioritize and focus your efforts on the most critical elements first.

2. Repeat and Paraphrase to Ensure Understanding: After a manager or a client explains a requirement, don't just say "okay." Instead, repeat what you've heard in your own words. For example: "Just to make sure I've got this right, the goal is to create a new component on the Account record page that displays the last five open opportunities, sorted by close date, with a link to each opportunity. Is that correct?" This forces immediate alignment.

3. Document your agreements. Make notes or use automated tools to do it as Fireflies. I prefer the second option.

4. Create a plan of action before you write any code: Before diving into development, send a brief message outlining your approach. This could be a quick email or a message on a collaboration tool like Slack. For example:

"Hi [Manager's Name], I've reviewed the requirements for the new Account component. My plan is:Build an Apex controller to query the last 5 open opportunities.Create a Lightning Web Component (LWC) to display the data in a table format.Add the LWC to the Account record page.I'll be sure to handle the 'no opportunities' scenario by hiding the component.Let me know if that sounds good to you before I start coding."

This gives them a chance to correct you or add details before you invest time in the wrong solution.

5. Share progress regularly. Small, regular updates build trust and allow for quick course corrections before a problem grows too large.

   
   

Share your thoughts I am happy to hear opinions from developers and managers :)