In the ever-evolving world of software and product development, finding the right balance between creativity and governance is crucial for a company's success. "The Curious Case of Transcendent Tech" is a fictional story inspired by real-world experiences. It explores the challenges a new developer, Sarah, faces as she navigates the complexities of a software company that prioritizes pure creativity over structured processes. Through her journey, we delve into the implications of decentralization, the absence of coding standards, and the impact of open-source code integration on a company's finances and operations.
Sarah, a senior developer with a successful Silicon Valley exit under her belt, stepped into the office of Transcendent Tech, a moderately sized software company nestled in the heart of Silicon Valley. With ten agile teams working on three different solutions, she was eager to dive into her new role, helping the company expand, with the expectation of another exit in the future. However, what she found on her first day was far from what she expected.
"Welcome to the chaos," muttered a fellow developer as she made her way to her desk. She brushed it off as a joke, but it didn't take long for Sarah to realize it was an understatement.
Her manager handed her a laptop and a stack of documents that seemed more like a patchwork quilt than a cohesive guide. As she delved into the codebase, she was stunned to discover that there were no shared coding standards. It appeared each team was operating in its own bubble, with different languages, frameworks, and even cloud platforms. AWS, Azure, and Google Cloud were used simultaneously, with no rhyme or reason.
Sarah’s confusion grew when she met Satish, the technical leader. With his perpetually bewildered expression, Satish seemed more interested in fostering what he called "pure creativity" than establishing any form of governance.
During their first meeting, he declared, "Standards stifle innovation. "We want each team to explore its own paths."
"But isn't there value in some consistency?" Sarah asked hesitantly. "It could help with collaboration and reduce costs."
Satish shrugged. "Creativity is our most valuable asset. Governance is just a fancy word for red tape."
Then there was Ming, the product manager, who believed her sole purpose was to solve the most urgent customer problems as they arose. When Sarah inquired about a product roadmap, Ming looked at her like she had asked for a crystal ball.
"I don't do roadmaps," Ming said firmly. "You see, I read a book about being inspired to solve problems and how roadmaps limit our ability to pivot as often as needed as we respond to our customers' needs."
"But how do we plan our development cycles?" Sarah asked. “How do our B2B customers know when they can expect some of the bigger challenges they’re facing will be solved so that they can prepare for the solution, like when we’re planning to change our APIs?”
"We don't," Ming replied with a smile. "We solve problems as they come. Customers have to integrate into our APIs when we release. Sure, they complain about the lack of forward planning, but giving any forecasts on future releases isn’t very customer-friendly. And besides, the developers are never that accurate, so why bother trying to get better at forecasting? Respond in the moment. It's the only way to stay truly agile."
The final puzzle piece was Avi, a young and enthusiastic developer. Avi was a lone wolf, often hunched over his laptop, working on his own projects. One day, he decided to integrate an open-source library into their latest solution.
Avi’s integration was seamless and significantly improved the product's functionality. However, it came with a catch: the open-source license required their entire codebase for that solution to be open-sourced.
When Sarah found out, she was incredulous. "Did you not check the license?" she asked Avi.
Avi shrugged. "No. Why would I do that? Open source means that we can just use cheaper stuff that’s free."
When Sarah pointed out that there was still time to remove the license, Avi reminded her that at Transcendent Tech, all decisions were decentralized – there was no need for heavy-handed, old-school development.
Avi's decision had immense ramifications. Suddenly, the entire solution’s codebase had to be open-sourced.
When Sarah raised this to Satish, he merely responded: “Open source licenses promote creativity – we can see how other people have solved problems, and our developers can improve the code for others.”
Sarah wasn’t sure how much capacity Transcendent Tech developers should devote to improving open-source software, so she tried a different angle and asked Ming: “Can you help me understand how open source will benefit Transcendent Tech financially? Will it help us accelerate our growth, allow us to increase our prices, or lower our costs?”, Ming responded, “Look, Sarah, I’m a former Product Owner who worked hard to be promoted to a Product Manager. I was never trained in creating a financial model or pricing or packaging. My job is to create value. I let the sales team set the prices, which seems to work fine because we’re growing.”
Sarah wasn’t so sure. Her last company looked carefully at the financial implications of their decisions, often allocating capacity to improving existing features instead of just solving the next problem from the loudest customer.
And this latest move from Avi just seemed to unleash chaos. Teams scrambled to rewrite proprietary code sections, while others saw it as an opportunity to showcase their individuality. The lack of standards and shared practices became glaringly problematic as each team’s unique approach clashed with the others. Making important decisions without a financial model to back them up seemed, at best, shortsighted and, at worst, a recipe for disaster.
As the dust settled, Sarah sat down with Satish and Ming to discuss the future. "We've seen what happens without any governance," she began. "Creativity is essential, but without some form of oversight, we’re just creating chaos. Furthermore, making decisions without understanding how we will create a sustainably profitable business means that we may not even be a company in the future."
Perhaps the latest round of customer complaints or the recent request from the CEO for more clarity on the revenue forecasts motivated Satish to think about this a bit more deeply. "Perhaps there’s a middle ground. Some level of standards without stifling creativity."
Ming nodded slowly. "And maybe a roadmap doesn't have to be a strict plan but a flexible guide, and perhaps I should invest the time to learn pricing, packaging, and licensing.”
While clearly fictional, this story is based on my experiences over two decades as a consultant.
I invite you to consider the following questions. How have your answers to these questions evolved throughout your career? Are they serving you well?
Finding the right balance between these and other questions is an ongoing challenge. I hope this article can help you find yours. And yeah, we’re here to help. Schedule a meeting with one of our pricing, packaging, and licensing experts, or check out upcoming training opportunities.