In 2022 it’s quite rare to find someone who’s leading the same product for more than a couple years. It’s even more rare to have been around from product genesis to maturity. I’m rare I guess. I rode the wave of a single idea for over a decade. This turned into dozens of products, an ever expanding code base, a myriad of personas, multiple vertical markets and sub verticals, and thousands of enterprise customers.
I also hung onto this product through multiple acquisitions into much larger organizations. I became indispensable. I was the knowledge keeper. I knew where all the dragons lied. I new where all the compromises had been made. I knew the ‘why’ of everything.
It was suffocating.
It took far too long for it to click in my brain that I was stuck. There was no career path. Sure my title changed, pay went up, but my day-to-day never changed. I was so busy collaborating with dozens of people across all departments, that it felt like I was growing. I wasn’t.
There was a frequent situation that occurred that clarified my position. It wasn’t unique; it happened several times a day. In this case a member of our implementation team pinged me over chat, ‘What happens when I [perform these steps] in the application?’
The thing was, I knew, but I strongly felt as the enterprise implementation team, they should know the most about app functionality. They should be the most fearless with bending the application to suit their needs. I told my colleague that they should try those steps to find out.
‘I’m on with a customer now, I need to know. Please tell me!’
I had been so responsive, so all-knowing, for so long, the entire org was conditioned to go to me for answers instead of discovering on their own. And suggesting otherwise was met with hostility.
I was a crutch. I was a shortcut. I was a wiki.
In enterprise SaaS, things can be complicated. There’s potentially hundreds of product configurations and dozens of integrations, personas, and use cases. After realizing that I was a sentient wiki, I started to recognize that anytime a customer wanted to go beyond the core fundamentals of our products, I would get pulled into the implementation calls with a customer.
We had documentation, lots of it. We had involved all teams in the design process, the roadmap, the documentation. We did all the right things. But an enterprise customer is full of surprises and because I’d seen so much, I was rarely surprised and this was exactly why the products were configurable and extensible. It’s not that I didn’t want to engage with customers at this level, but I just didn’t want to get assignments in the implementation project. Inevitably, I would end up in a place where I was getting asked by implementation managers for the status of my implementation deliverables. I was becoming a shadow implementer.
There was a time, that I was doing deployments of our flagship product. This was back when we were a company of 15, and we had no deployment pipeline. It was literally copy/paste of directories across server farms and running SQL scripts. I knew a lot about the database and the application dependencies. But 5 years later, at a company with 600 people, a product leader like me had no business touching production servers and had absolutely no access. We had a whole DevOps department for that.
About monthly, I would get urgent pings from the DevOps team asking me to answer questions or respond to tickets that I would normally go to them for.
It was starting to feel like there was a 301 redirect on all product or infrastructure questions that went straight to me. This even seemed to survive after an entire department churned, like day 1 of onboarding for new employees included a training video called ‘Everything you need to know about Product X, Just Ask @SoFuckingAgile’.
My situation started to get dire. I had a hard time thinking strategically about product. I was too busy supporting the entire organization on all things related to the product. I was starting to get uneasy about building anything that required implementation effort or that was highly technical.
This included all integrations. In B2B enterprise SaaS you MUST integrate, so this was problematic.
I’m someone who likes to know. During product discovery and build phases, I like to understand the parts. But I had to stop understanding. I would coordinate the meetings to bring parties together to define the requirements, to understand the gaps and technical details, but I would not attend. I would not participate in testing or even demos of the new integration. I would not know anything about how it worked beyond the marketing slick.
This was huge. I could legit say ‘I don’t know’ to all questions, and redirect people to the correct resource. If that resource didn’t exist, it was escalated to someone other than me. Yes, our organization didn’t really empower people to take ownership of things and really become experts, but I was also enabling this by solving problems that I shouldn’t have.
Countless times someone would message me directly for product or industry info. Sometimes hours or weeks later, I would get the same question from someone else. I was constantly repeating myself and pointing people to the same documentation or resources.
One thing I instituted that helped was a specific Teams channel called Knowledge Transfer. Any questions that would normally have been DM’d to me could be posted there, publicly for all to see. In theory, others could step up to answer these. I could also forward DMs there to respond to publicly or refuse to answer in DM and require them to retype their question in the Knowledge Transfer channel. Rarely did others step up to answer, but it became more like a SoFuckingAgile office hours, which was still a big improvement.
Sales reps were needy. They always wanted me on sales calls like some sort of safety blanket. The thing was, their department leads had no idea this was happening. I created an email rule where any email to me from a sales rep would be auto-forwarded to sales managers and directors. Then they could decide if I was required on that call. This was extremely helpful.
Quarterly, I would also train other department managers on the most glaring knowledge gaps on their teams. I would help them build new content into their new hire onboarding programs. For example, if I got sales reps asking about prospects needing SOCK TWO (lol), the topic of SOC certifications and other data protection discussions would be added to the training list.
Even with some new measures in place, I was the bottleneck on everything in the product line. My entire work day was clicking Start Meeting buttons, not knowing what I was going to step into, and having the pressure of all those people who were there thinking I would be the one to drive them forward on some task. I’m not a micro-manager. I know a lot of people who wished that I was, but I really dislike getting involved in leading projects unrelated to getting products out the door — things like price increases, outsourcing professional services, branding etc. I would give big hints like ‘This is very similar to [insert identical project we just went through] and I think you should use that as a reference to move forward.’ It was draining and repetitive.
Being indispensable is possibly good for job security, but I had stopped learning. It had been years since I’d learned anything new from my work or the people around me. Sure I’d learned new ways to try and help people be more self sufficient, but the impact was minimal. I was stuck. One of the biggest problems with being indispensable and announcing that you feel stuck, is that the business will take steps to get you even more stuck, through more money, shinier titles and stock options.
This is more of a cautionary tale. I never really found out how to get unstuck and remain in the organization. Just know that it can sometimes feel nice to be an expert in something, but it’s a possible trap that can stall your professional growth if left unchecked for too long.