Skip to content
    May 28, 2024

    The Curious Case of Transcendent Tech


    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.



    A New Beginning

    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.


    The First Meeting

    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."


    Ming's Philosophy

    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."


    Avi's Bold Move

    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.


    The Unraveling

    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.


    A Glimmer of Insight

    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.”


    Questions for Reflection / Conclusion

    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?

    • Can true creativity thrive without governance, or does it require some structure to flourish? Alternatively, does governance automatically stifle creativity?
    • How can companies balance the need for innovation with the necessity of standards and cost-saving measures?
    •  Is decentralization of decision-making always beneficial, or are there times when central oversight is crucial?
    • How can product managers plan for the future without feeling shackled by it?
    • What are the risks and rewards of open-sourcing proprietary code?
    • Who should be in charge of pricing, packaging, and licensing? What training and skills do they need to be successful?

    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.

    Tag(s): Profit , Product

    Luke Hohmann

    Luke has been involved with Applied Frameworks since its founding in 2003. He later went on to start Conteneo, a collaboration software company which was acquired by Scaled Agile in 2019. While at Scaled Agile, Luke served as a SAFe® Framework Contributor and Principal Consultant, with significant contributions to the SAFe Agile Product Delivery (APD) and Lean Portfolio Management (LPM) competencies and the SAFe POPM, APM, and LPM courses. He is an author and cited as an inventor on more than a dozen patents. His books include Innovation Games: Creating Breakthrough Products through Collaborative Play (2006), Beyond Software Architecture (2003), Journey of the Software Professional (1996), and the upcoming Software Profit StreamsTM (2023) co-written with Applied Frameworks CEO Jason Tanner.