History often shows that great civilizations—like Ancient Greece, the Ottoman Empire, or Rome—entered a decline once they began directing their energy away from their founding strengths and onto social concerns. It’s not that these new social pursuits were unworthy; it’s that they assumed their original competitive advantage would always remain intact. At a certain point, they neglected the very foundation that had made them powerful in the first place.
Eventually, once reliable access to food, water, and shelter were secured—and even a rudimentary health system was in place—other societal needs began to surface as “fundamental”. Interestingly (though I’m no historian), this shift toward social welfare marked the turning point for many great empires, from Ancient Greece to Rome. In each case, their attention moved away from the core strengths that had made them dominant, and ironically, this is when their decline began.
A Modern Software Parallel
A similar pattern can happen in software development departments or entire software organizations. When you start consistently delivering solid, high-quality products, the focus can shift from refining your core engineering practices to the “softer,” more socio-professional aspects of organizational life. In many ways, this is natural and healthy: organizations need to evolve, and paying attention to people’s well-being and growth is critical.
The problem arises when we forget that the business itself still hinges on the ability to deliver and innovate technically. Without good products, there is no revenue; without revenue, there is no department.
The Slide From Technical to Socio-professional Focus
Here’s what often triggers this shift:
1. Consistent Quality Delivery
Once you’ve proven you can deliver reliably, it’s easy for teams—and leadership—to take product excellence for granted.
2. Employee-Driven Initiatives
As the department grows, staff may push for more autonomy in decision-making, more delegation to teams, and a bigger focus on personal development, career paths, and organizational structure.
3. Buzzwords & Trends
You might hear phrases like “We need to optimize for team happiness above everything else,” or “Let’s reorganize ourselves by the book and see how it goes,” without carefully considering the impact on product architecture and sustainability.
Of course, none of these pursuits are “bad.” The risk is shifting too far away from technical stewardship, architecture alignment, and keeping pace with the industry—because software engineering evolves at breakneck speed. You don’t have to be an early adopter of every new trend, but staying in the late majority can cripple your competitiveness.
Why This Matters: A Historical Parallel
• Ancient Civilizations
Once their basic needs were met—food security, strong military, stable governance—they diverted focus to more complex societal issues. Important work, yes, but over time they neglected what had made them strong to begin with.
• Modern Software Departments
Once teams master consistent delivery, they may pivot attention to organizational design, psychological safety, and net promoter scores (NPS). These are vital topics, but if they come at the expense of keeping your technology stack fresh and your product architecture robust, you risk eventually falling behind.
It’s not an either/or proposition. You can address socio-professional concerns and maintain technical excellence, but you need to safeguard your core product’s integrity or risk losing the very foundation that supports all those new initiatives.
A Note on Transitioning from Projects to Products
Many organizations are still in the midst of a major shift—from project-based modes (finite scope, rigid funding) to continuous product development (stable delivery structure, ongoing budget). This mindset change and the accompanying organizational restructuring can take years in large companies. Meanwhile, your department will still be responsible for delivering a consistent flow of product enhancements to keep the business afloat. If you pivot too soon to socio-professional concerns—before the organization fully embraces this shift—you risk letting critical technical responsibilities languish.
Predictable Outcomes When the Shift Happens
1. Strongly Opinionated New Voices
As the department moves toward inclusive, cross-functional decision-making, new (and often loud) voices emerge in strategic meetings. Some may be driven by personal agendas, pushing organizational changes that inadvertently undermine product focus.
2. Delegation Without Direction
More delegation to teams can be powerful, but if those teams lack critical context, they could make decisions that stray from overall strategic goals. In the worst cases, you’ll face architectural fragmentation or duplicated efforts.
Beware of dogmatic statements like: “modern organizations delegate everything to teams”. In your leadership position you should be questioning all these statements. What worked for Spotify, AWS or Netflix might not work for your organization. While one company might favor time-to-feature higher than product-care costs (maybe driven by different teams using different technologies, design patterns or development practices, or any other property of polyglot systems) other companies might have strong reasons to favor a more manageable (often times measured in cost) product-care phase (e.g. companies writing software for heavily-regulated environments like medical devices). The autonomy of the teams in one or the other company will be totally different (and for good reasons). Just don’t feel bad if you cannot apply the recommendations as in the book. Check what are the needs of your products and organization and decide what is the best setup to be able to deliver it fulfilling all its quality attributes.
If you are going to blindly follow the directions given by a book, at least make sure you take the correct one.
3. Organizational Restructures & Trend-Chasing
It’s not uncommon to see entire departments “reorganize by the book,” copying a successful tech giant’s playbook without adapting it to the target architecture of their own products. Structures meant to reduce dependencies can inadvertently create new ones if not designed for your specific ecosystem.
Managing the “Strongly Opinionated” Stakeholder
A common side effect of this socioprofessional shift is the introduction of new players in decision-making—people with strong opinions and loud voices. They might challenge established practices or advocate for radical changes that have little to do with core product needs. Don’t panic; see this as an opportunity for stakeholder management:
1. Assess Their “Power of Disruption”
• Talk to Other Decision-Makers: Have informal coffee chats to gauge how influential or connected this new stakeholder is. Influence is not self-assigned; it’s granted by those around them. How to do that? Ask them questions related to the topics/proposal that the new stakeholder is bringing on the table. E.g. “what do you think about the proposal of switching to cross-functional teams?” or “How do you see the contributions of the new stakeholder?”
• Map Their Network: If the rest of the group isn’t strongly aligned with this individual, their disruptive power is lower than it appears.
2. Find Their Interests
• Have a Direct Conversation: Invite them for a coffee to uncover their motivations, desired outcomes, and definition of success. You can start from a more general question like: “What is your opinion on the strategic goals from the department/uynit?” to later move to more concrete questions like “what do you expect to gain by moving towards a cross-functional teams setup?”
Important: if you want to lead the conversation, make sure you are the one asking the questions. Show natural interest and carefully listen to the answers. Take notes so that you can use the answers to ask new questions until you unveil the essence that drives this person’s goals.
• Use the Stakeholder Map: Once you understand their power of disruption and their interests, place them in a stakeholder matrix. This helps you decide how much communication, persuasion, or compromise to invest.
By handling these new voices proactively, you can nurture positive contributions while keeping a firm grip on the technical direction of the department.
Managing Organizational Restructuring “By the Book”
Organizational restructuring is often sold as a silver bullet: “Just adopt the Spotify model!” or “We have to break into Amazon-like micro-organizations!” However, blindly following a popular framework can do more harm than good if it’s not aligned with your product’s target architecture and your business realities.
1. Define the Target Architecture First
• Understand Your Product’s Needs: What are your product’s quality attributes (performance, maintainability, security, etc.)? How do your current teams align—or clash—with achieving those attributes?
• Align Structure with Architecture: Once you know where your product needs to go, design your teams or squads to support that journey.
2. Incremental Overhaul vs. Big Bang
• Pilot First: Instead of flipping the entire organization overnight, trial a new structure in a single, non-critical area. Observe the outcomes—both technical and cultural—before rolling it out more broadly.
• Assess Impact: Track key metrics (e.g., deployment frequency, lead time, error rates) to ensure the restructure is actually moving you closer to your architectural goals.
3. Keep People at the Center
• Provide Context & Training: If you’re restructuring based on domain boundaries or technical stacks, make sure teams understand the why behind these changes.
• Listen and Adapt: Even the best-planned reorg can miss nuances. Be open to feedback and ready to pivot if you see that certain decisions are backfiring.
Following a well-known “book” might offer useful guidelines, but remember to tailor any organizational design to your product’s architecture and business constraints.
Balancing Act: Socio-professional vs. Technical Excellence
To reiterate, focusing on people, structure, and well-being is essential for a healthy culture. But maintaining your product’s quality, architecture, and alignment with industry evolution is critical for survival.
Key Strategies to Maintain Balance
• Regular Technical Refreshes: Periodically review your software stack, architecture, and processes to ensure you’re not falling behind.
• Guided Autonomy: Empower teams to innovate within established guardrails that align with strategic product goals.
• Continuous Stakeholder Engagement: Make sure socio-professional initiatives don’t overshadow the technical conversations that safeguard your product’s future.
Recommendation for Handling Delegation Without Direction
To prevent excessive or misguided delegation from harming your department’s core mission, you need to balance autonomy with strategic clarity:
1. Set Strategic Context
• Define the Why: Before delegating, clarify how tasks align with broader company goals and the product’s architectural vision. It is a very useful tool to always start a meeting or conversation with you team or team members by reminding/mentioning the strategic goals and/or directives of the organization. Remind your colleagues what are the driving forces for a certain task or decision.
Example: “As you might recall, sustainability in our products has been set as a divisional priority. From software perspective, we want to contribute to this goal by…”
• Explain the Impact: Link each team’s decisions to the overall product or organization goals—“It’s crucial to follow these guidelines for sustainability”—so they understand the bigger picture. It is again a very helpful practice to link their work to the fulfillment of the goals that you started the conversation with.
2. Offer Guardrails, Not Micromanagement
• Establish Clear Boundaries: Document architectural principles, preferred tech stacks, and design constraints. Whatever isn’t written will be forgotten.
• Check in Regularly: Periodic reviews help catch deviations early. Avoid the extremes of micromanagement or complete hands-off delegation.
Honestly, this is an area where I’ve personally failed a lot. I did the mistake of delegation without control. Definitely far from micromanaging, but almost as harmful (from a product perspective). Late discoveries of teams (or individuals) not following agreed decisions, practices, technologies or concepts can lead to one or multiple of the expected quality attributes of the system not being fulfilled.
Example: having some teams following a decision while others deviating might have a direct impact on the maintainability of the system.
My recommendation: perform regular ‘compliance’ meetings where you check with your team if concepts, decisions or technologies are been applied and followed. Create Technical debt items (in the corresponding tracking tool) for each finding and make sure your business and project management is aware about the technical debt items. Only then you will have one opportunity to get them fixed.
3. Foster Cross-Team Communication
• Shared Knowledge Base: Maintain a single source of truth for architectural decisions, best practices, and constraints.
• Encourage Peer Feedback: Let teams cross-pollinate ideas to identify misalignments before they escalate.
4. Empower with Training and Context
• Skill Up: Offer technical and strategic training so teams make informed decisions.
• Contextual Insights: Provide visibility into customer needs, budget constraints, and long-term roadmaps.
By giving teams the freedom to solve problems creatively—while offering enough strategic clarity to keep them aligned—you strike a balance between empowerment and direction.
Conclusion
Delivering high-quality products consistently is a fantastic milestone. You should celebrate it. But remember that this achievement can breed complacency—just as once-great civilizations foundered when they took their foundational strengths for granted.
Stay vigilant. Encourage socio-professional growth, but don’t let it crowd out the technical acumen that got you this far. Keep a watchful eye on how decisions are made, who’s influencing them, and whether your org structure still supports your target architecture. By doing so, you’ll navigate the natural shifts that come with success—without losing sight of why you started building great software in the first place.
Keep in mind: history has a habit of repeating itself.
What’s Next?
• Architectural Integrity vs. Organizational Restructuring: Finding the sweet spot where you can pivot your org chart without fracturing your product.
• Early Adopter or Late Majority?: How to identify which emerging technologies are worth exploring—and when it’s safe to let a trend pass by.
Remember: building a world-class product isn’t just about code and diagrams. It’s about understanding the human and organizational aspects without neglecting your technical foundation.
