I turned forty in September. Including internships, I’ve been working professionally for over twenty years. The time has gone really fast.
I’ve done some reflecting recently on what I’ve learned over the last two decades. I hope that these three simple lessons will resonate with you.
Lesson 1 – Find Your Own Path
Early in my career, I was part of a team developing a software/hardware component that integrated with our client’s industrial product offering. Our end client was a Japanese manufacturer, and all of their team lived in Japan, so we were dealing with different timezones, languages, and business cultures.
As we got closer to a major release, our team and our client started to get nervous. We had integration issues with the industrial system that was being manufactured in Japan. Our process for deploying changes was for us to create a build, post it, and compose a message with our understanding of the fixes. Our client in Japan, who was ten hours ahead of us, would install the build the next morning, test the changes, and share their feedback. Small bugs that were difficult to detect without the production machine, which was in Japan, caused days to be lost out of the schedule. This created client frustration.
My company had a lot of experience working with Japanese clients; they felt the best way to collaborate and build a strong relationship was to frequently visit the client in Japan. Our main salesperson would always tell me that the Japanese need to see your fingers and toes to collaborate. I agreed that visiting was vital to building the relationship but refused to believe it was the only way to effectively collaborate. And flying to Japan at the eleventh hour before our scheduled release was time I didn’t want to waste.
Instead of following the standard play, I proactively connected with the end client and proposed that we connect via chat to more rapidly work out the product issues. This sounds like an obvious solution in 2020, but in 2006, that wasn’t the case.
The proposal to meet digitally required me to come into the office extremely early and our end client to stay at his facility into the evening. My client’s spoken English wasn’t great (although it was much better than my Japanese), so we used text-only chat, which gave him the confidence to slowly communicate his points. I worked hard to return the favor by keeping my English simple, concise, and unambiguous.
This synchronous communication allowed us to quickly identify the major integration issues. Since I still had an entire day of work after our early morning meeting, it also gave me time to produce a build candidate that addressed those issues. This success led me and our client to continue meeting synchronously on a weekly cadence to ensure that all of the integrations were completed successfully.
The experiment provided evidence to my organization that we didn’t need our client to see our fingers and toes to find success. It also taught me that I didn’t have to follow the established rules/guidance; I could and should define my own path for success. Having the confidence to run with my novel idea helped the project find success, and it led my company to adapt and evolve in a positive direction.
Lesson 2 – Manage Your Manager
I’m an engineer at heart. When I get work requests, I commonly outline all the things that need to happen, as well as the associated risks. This is important and valuable work.
Nevertheless, I’ve learned that, if things are fairly straightforward, it’s almost always better to use this as an internal checklist instead of sharing the complications with my manager.
One of my favorite managers shared this thought experiment with me early in my career. If you’re the manager, what do you hear when you listen to these two work requests:
- “This request involves A, B, C, and D. I believe B is kind of tricky and could cause some issues. This work will take about a week to complete.”
- “This request is straightforward. It’ll take me a week to complete. I’ll be sure to connect back if complications arise that impact the timeline.”
Both statements are outlining the same solution. However, the first statement activates the management side of a manager’s brain. Managers love to manage. Not knowing anything about the overall complexity of the task, the manager will likely start questioning the fact that you believe B is tricky. The thought process is: “Perhaps if we more tightly manage B, we can make the work be completed sooner.” Sometimes you want this level of engagement from your manager, and sometimes it’s simply not necessary.
The second statement gives the manager nothing to manage. You’ve expressed that it’s straightforward and that it’ll take a week. That communicates clearly that it isn’t happening in two days, even if we “apply management.” You’ve also communicated that you’ll proactively manage risk and involve them if the timeline is in jeopardy.
This is a simple example, but the concept of “managing the manager” has stuck with me. Managing your manager is not a condescending action. In many cases, it’s caring for your manager and simplifying your own work. As a manager, I love to help others succeed at their work. It’s also nice to not worry about every piece of work that I assign.
Lesson 3 – Act Like the Leader
At a previous company, we sold our products all over the world. It was common for us to translate applications into nine different languages. We had our own internal translation team that worked closely with engineering. I suspect that product engineering and translation all rolled up to the same VP at some level in the organization, but on the ground floor, we functioned as two distinct departments, and the accountability wasn’t clear.
Both groups were hard working and cared about the company’s success. However, our techniques and priorities occasionally didn’t align. Since the accountability wasn’t clear, neither group wanted to be overly assertive with the other group. This was a recipe for missed, unstated expectations and frustration. It was clear to me that there was a leadership void.
At one point, there was a product that needed to be shipped, but I had no real authority over the translation team. Instead of being passive in my conversations with the translation team, I decided to be more assertive. I worked hard to be sympathetic to their needs and desired process, but I focused our conversations on the end client and the successful launch of our product.
The translation team responded very well to this. They didn’t agree with everything, but they appreciated the leadership and direction. This experience taught me that you don’t need a title to lead and that people appreciate it when someone steps into a leadership void.
Closing Thoughts
These simple career lessons have helped shape how I engage at work. We’re never done learning during our careers. I’m looking forward to the lessons I’ll learn during my next twenty years.