Strong People Culture, but Product Engineering Needs a Reset
Pros
1. The HR team maintains a good balance between protecting the company and taking care of its employees. 2. The company has a good reward system in place to recognize the contributions of both short-term and long-term employees. 3. The company has strong female representation at all levels, with less macho culture than many organizations in the industry.
Cons
1. The feudal system: The idea of leadership here often seems to revolve around purchasing enterprise software, creating layers of bureaucracy around it, and overseeing that bureaucracy while gradually removing decision-making authority from ground-level engineering teams. At the same time, accountability becomes diluted. This culture can promote incompetence. For example, individuals with limited product engineering experience may be placed in leadership positions despite lacking a deep understanding of software products, agile development, product roadmaps, technology stacks, programming languages, or production feature development. As a result, leadership can become focused on bureaucracy rather than technical execution, reducing management to process enforcement, status signaling, and organizational politics. Customers typically buy software because they are unable to build it themselves due to internal constraints, bureaucracy, or working conditions. Ironically, the company has increasingly mirrored some of those same conditions by prioritizing bureaucracy over product engineering expertise. This has weakened its ability to build and evolve competitive software products. 2. The DevOps effect: The DevOps mindset often emphasizes purchasing and operating third-party software and services rather than building core capabilities internally. While this approach has value, excessive reliance on external vendors can weaken product innovation. In many product-focused organizations, technical leaders like CTO remain hands-on in programming and actively contribute to product architecture and engineering. Here, there is often a tendency to take product challenges to vendors in search of solutions rather than developing them internally. As a result, innovation frequently follows market trends rather than leading them. A company that once introduced significant technological innovations can gradually become dependent on third-party products and services, sometimes replacing its own offerings with vendor solutions. Product engineering leadership should ideally have substantial experience building software products. When engineering problems are approached primarily through an operations mindset, there is a risk of selecting solutions first and then searching for problems that fit them. 3. The data-driven approach: A successful data-driven culture requires both the intellectual rigor and organizational willingness to honestly interpret and act on data rather than selectively using it to support predetermined conclusions. Without that foundation, organizations risk interpreting, presenting, or shaping metrics in ways that reinforce existing leadership narratives and preferences instead of driving meaningful improvement. Sustainable product growth comes from developing expertise over time, learning from failures, and preserving institutional knowledge. Data can support that process, but repeatedly highlighting metrics without addressing underlying engineering challenges often leads to more bureaucracy rather than meaningful improvement. In such environments, product development can stagnate instead of growing. The leadership also has a tendency to categorize criticism as negative, positive, or constructive. However, constructive criticism depends on the intent and integrity of the person providing it. It should not be dismissed simply because it challenges existing assumptions or established ways of working.
