Bringing In Help

I remember when I was first getting into the field of software development. Ready to soak up all the knowledge from my new colleagues and the challenges I was facing down. I was going to learn it all leaving nothing left on the table. I worked my hardest to continue an aggressive pace of learning. After several months, I was tired of learning. I was at a local maximum, it was time for a break. It took me a little bit of time to recover from this aggressive pace. That experience taught me there is a limit to the amount a single contributor can do in a given time. It was time to learn when to bring in help, to move items across the line.

How does this look in practice?

Quite recently, I was working on a project that presented data to the end user for them to select from. I knew going into this task that I did not have all the answers needed to complete the work, as the presentation of this information is nuanced. I did what could to get the data on the page, presenting it in a way that I understood would be best received by the end users. The presentation was not polished at all, it was just data on a page. I knew that I could spend more time on this implementation, but it would potentially be throw-away work. Or it was not 💯 necessary to communicate the idea. Instead, I decided to bring in an expert.

Starting the conversation with, this is not complete, I want to make sure I am on the right track, and I value your opinion. We did a screen share to show off what was completed. In less than 5 minutes of conversation, we came to a point where there were only slight adjustments that were needed. Then some polishing of the data is presented. As I made the adjustments my expert stayed along for the ride. Seeing each update on the screen share as they were made. At each step, the expert provided valuable feedback on the improvements. 20 minutes later the task was complete and on its way to a development environment with a high degree of confidence, the solution provided would indeed solve the user's problem.

Notes from experience

• Be humble, no one person can know everything
• Be vulnerable, tell your team you do not fully understand the request
• Ask in advance, if you know you may need help around lunch-time communicate it early so others can plan their day accordingly
• Be open, feedback is a gift whether it be positive or negative feedback

Great things in business are never done by one person; they’re done by a team of people.

-- Steve Jobs