Before working with Dojo Five, I had worked with teammates from different backgrounds, but never met or talked with customers. There’s more to it than status updates. Your customers may appreciate deep technical expertise, but they are happiest when they can trust and enjoy the process of working with you. A project management tool shows the tasks you’re working on and their status but often doesn’t cover the system-level design choices, requirements, or constraints. It takes extra effort and care to ensure they are communicated thoroughly and clearly when you don’t sit together in the same building every day. These three communication lessons are the direct result of what I’ve learned from helping customers create their devices.
Lesson #1: Document Decisions For All to See
Recently, I had some trouble communicating fixes and changes I made in the clients’ code. I had communicated changes through email and instant messaging with the technical reviewers. But that was not visible to the rest of the team. So to them, the changes seemed random or confusing. This problem was magnified when technical details and explanations were exchanged via e-mail, phone call, or instant messaging. Messages are easily lost and not easily shared with everyone that may need to understand the work that has been done.
The key is to use tools to communicate that will last throughout the project as well as after your service has concluded. One way to do this is through pull requests and service tickets. I have found that using link features provided by repository hosts like Github and team management services like Jira are very effective at communicating progress, successes, and failures. Using tickets and code reviews in pull requests to communicate provides more the full story for your client’s entire team to review. Everyone, present and future, will have full, searchable access to the living history of the work that can give context for why decisions were made that cannot be commented in the code.
Lesson #2: Understand Your Limits and Expectations
I recently had a task to reduce the RAM usage of my customer’s entire system. I was not as familiar with the codebase as they were, but they had asked me to clean it up. Going in, I did what any embedded engineer would do and looked through the map file to find any obvious sources of wasted RAM. I found nothing. I checked for any dynamic allocation of memory on the heap. I found some things, but not enough for me to be proud to call this task complete. I kept looking and looking for anything, and I was not sure what to do when I couldn’t find anything.
Ultimately, I gathered up a list of all the significant RAM usage, and reasons for why I could not touch these particular large allocations. I presented this to the customer, and they came back with feedback that confirmed most of my observations. I had been worried about not being able to meet expectations when the request may not have been possible. Despite my feeling of failure to cut their RAM usage as much as I thought they expected, it was important to communicate what I found and explain my observations about their system. I have also learned that it is beneficial to communicate my progress while working on a larger task. It gives the client an opportunity to correct me if I am wrong about a conclusion, or to confirm my thoughts, letting me be more confident in my performance on the task. In situations like that, it is important to be both honest and confident when communicating with the customer. Lacking either can give them a reason to call your work into question. In the RAM reduction task, I was honest that I wasn’t sure I could reduce it to the level they were looking for — but I was also able to confidently list out the reasons why certain pieces couldn’t be made smaller after looking at the code.
Lesson #3: Be Friendly
When working with other people, completing tasks is of utmost importance. But if you are not pleasant or easy to work with, the customer may be inclined to find someone else to get tasks completed with a friendlier experience. An example of going above and beyond for a customer could be pointing out something that doesn’t deal with a feature you’re implementing but could improve the end product. Being able to not only finish your work but find other ways to make the project better can be a huge value-add for the customer, something that builds a long-lasting relationship.
And if you are looking for even more on embedded ops, we host a weekly Lunch and Learn on a variety of topics from embedded on cellular, deep learning with robots, and more! Check out our current list of events and sign up for your seats – always no cost!
