Crossroads of the career journey
It can be an event, a project, or an assignment. It’s that situation that leads to the point in time when we make a decision between two divergent paths. For me, it was a failed assignment as a software product manager. My job was to create a B2C internet site that integrated with a Siebel ERP. But the combination of business rules, technology capabilities of the web platform, and intricacies of an ERP integration were above my skillset at the time. I wasn’t mature enough to recognize it, and when management pointed it out to me I became defensive. The project stalled and was scrapped.
The unseen path
So my defining moment was a career failure. I was subsequently “reassigned”. The path was as much chosen for me as anything I did. I suppose I could have quit or asked for a different new assignment. But the idea of a change of scenery had an appeal. It was a new business unit with different technologies . A complete start-over.
I don’t know if the intent of management to locate me far away from central IT or if it was to give me a chance to work with a business unit that needed some IT assistance. It could have been either. I had been very successful in all my previous assignments. But a failure on a high profile project can be a “career limiting move”. Whatever the case, I went from a situation where I was trying to survive, to one where I could thrive.
Career booster shot
In my new assignment I reached out and aligned myself directly with business unit owners. The business unit wasn’t part of the core revenue making unit for the company and didn’t have much oversight from the central IT group. This alignment shaped my business preferences and thinking even to present time. It was decentralized. I had direct access to a developer and didn’t work through a central PMO or project board.
I’m not saying it was the wild west. There were rules. I had accountability. It’s just that most of it came directly from the business unit owners; my primary customers. Thinking back on it now, it was like an early model of agile development. I had lighter documentation. I had contact with the customer, the developer, and the tester. We programmed quickly and at regular cadences. We solved problems. We got stuff done.
Communication, relationships, and people
I developed new communication skills. I learned that the technology is not what matters to the business. What matters is solving a business problem with the technology. I learned that it’s the job of a technology professional to immerse in the business and understand it. I learned that it’s the people relationships that open doors to working collaboratively to find solutions.
The failure and subsequent change of scenery started molding me. It’s the reason I list career failures on my resume. They made me stronger. They helped me learn.
So for me, that defining career moment was humbling, disciplining, and guiding. It was worth it. I haven’t looked back.