The author argues that abstract architectural discussions about microservices are often unproductive. Instead of focusing on theoretical benefits and drawbacks, conversations should center on concrete business problems and how microservices might address them. Architects tend to get bogged down in ideal scenarios and complex diagrams, losing sight of the practicalities of implementation and the potential negative impact on team productivity. The author advocates for a more pragmatic, iterative approach, starting with a monolith and gradually decomposing it into microservices only when justified by specific business needs, like scaling particular functionalities or enabling independent deployments. This shift in focus from theoretical architecture to measurable business value ensures that microservices serve the organization, not the other way around.
This 2015 blog post outlines the key differences between Managers, Directors, and VPs, focusing on how their responsibilities and impact evolve with seniority. Managers are responsible for doing – directly contributing to the work and managing individual contributors. Directors shift to getting things done through others, managing managers and owning larger projects or initiatives. VPs are responsible for setting direction and influencing the organization strategically, managing multiple directors and owning entire functional areas. The post emphasizes that upward movement isn't simply about more responsibility, but a fundamental shift in focus from tactical execution to strategic leadership.
HN users generally found the linked article's definitions of manager, director, and VP roles accurate and helpful, especially for those transitioning into management. Several commenters emphasized the importance of influence and leverage as key differentiators between the levels. One commenter highlighted the "multiplier effect" of higher-level roles, where impact isn't solely from individual contribution but from enabling others. Some discussion revolved around the varying definitions of these titles across companies, with some noting that "director" can be a particularly nebulous term. Others pointed out the emotional labor involved in management and the necessity of advocating for your team. A few commenters also shared their own experiences and anecdotes that supported the article's claims.
Jo Freeman's "The Tyranny of Structurelessness" argues that informal power structures inevitably arise in groups claiming to be structureless. While intending to promote equality and avoid hierarchy, the absence of formal procedures and explicit roles actually empowers a hidden "elite" who influence decisions through informal networks and pre-existing social capital. This informal power is difficult to challenge because it's unacknowledged and therefore lacks accountability. The essay advocates for consciously creating explicit structures and processes within groups to ensure genuine participation and distribute power more equitably, making decision-making transparent and enabling members to hold leaders accountable.
HN commenters discuss Jo Freeman's "The Tyranny of Structurelessness," largely agreeing with its core premise. Several highlight the inherent power dynamics that emerge in supposedly structureless groups, often favoring those with pre-existing social capital or manipulative tendencies. Some offer examples of this phenomenon in open-source projects and online communities. The "tyranny of the urgent" is mentioned as a related concept, where immediate tasks overshadow long-term planning and strategic decision-making. A few commenters question the binary presented in the essay, suggesting more nuanced approaches to structure and leadership, like rotating roles or distributed authority. The essay's age and continued relevance are also noted, with some arguing that its insights are even more applicable in the decentralized digital age.
The original poster is exploring alternative company structures, specifically cooperatives (co-ops), for a SaaS business and seeking others' experiences with this model. They're interested in understanding the practicalities, benefits, and drawbacks of running a SaaS as a co-op, particularly concerning attracting investment, distributing profits, and maintaining developer motivation. They wonder if the inherent democratic nature of co-ops might hinder rapid decision-making, a crucial aspect of the competitive SaaS landscape. Essentially, they're questioning whether the co-op model is compatible with the demands of building and scaling a successful SaaS company.
Several commenters on the Hacker News thread discuss their experiences with or thoughts on alternative company models for SaaS, particularly co-ops. Some express skepticism about the scalability of co-ops for SaaS due to the capital-intensive nature of the business and the potential difficulty in attracting and retaining top talent without competitive salaries and equity. Others share examples of successful co-ops, highlighting the benefits of shared ownership, democratic decision-making, and profit-sharing. A few commenters suggest hybrid models, combining aspects of co-ops with traditional structures to balance the need for both stability and shared benefits. Some also point out the importance of clearly defining roles and responsibilities within a co-op to avoid common pitfalls. Finally, several comments emphasize the crucial role of shared values and a strong commitment to the co-op model for long-term success.
James Shore envisions the ideal product engineering organization as a collaborative, learning-focused environment prioritizing customer value. Small, cross-functional teams with full ownership over their products would operate with minimal process, empowered to make independent decisions. A culture of continuous learning and improvement, fueled by frequent experimentation and reflection, would drive innovation. Technical excellence wouldn't be a goal in itself, but a necessary means to rapidly and reliably deliver value. This organization would excel at adaptable planning, embracing change and prioritizing outcomes over rigid roadmaps. Ultimately, it would be a fulfilling and joyful place to work, attracting and retaining top talent.
HN commenters largely agree with James Shore's vision of a strong product engineering organization, emphasizing small, empowered teams, a focus on learning and improvement, and minimal process overhead. Several express skepticism about achieving this ideal in larger organizations due to ingrained hierarchies and the perceived need for control. Some suggest that Shore's model might be better suited for smaller companies or specific teams within larger ones. The most compelling comments highlight the tension between autonomy and standardization, particularly regarding tools and technologies, and the importance of trust and psychological safety for truly effective teamwork. A few commenters also point out the critical role of product vision and leadership in guiding these empowered teams, lest they become fragmented and inefficient.
Summary of Comments ( 37 )
https://news.ycombinator.com/item?id=43515563
Hacker News commenters generally agreed with the author's premise that architects often over-engineer microservice architectures. Several pointed out that the drive towards microservices often comes from vendors pushing their products and technologies, rather than actual business needs. Some argued that "architect" has become a diluted title, often held by those lacking practical experience. A compelling argument raised was that good architecture should be invisible, enabling developers, rather than dictating complex structures. Others shared anecdotes of overly complex microservice implementations that created more problems than they solved, emphasizing the importance of starting simple and evolving as needed. A few commenters, however, defended the role of architects, suggesting that the article painted with too broad a brush and that experienced architects can add significant value.
The Hacker News post titled "Why I'm No Longer Talking to Architects About Microservices" (linking to an article on the same topic) generated a moderate amount of discussion, with several commenters sharing their perspectives on the role of architects in microservice adoption and the challenges of implementing them effectively.
Several commenters echoed the sentiment of the original article, expressing frustration with architects who promote microservices as a silver bullet without a deep understanding of the complexities involved. One commenter noted how some architects focus excessively on theoretical purity and complex diagrams, losing sight of the practical considerations and trade-offs required in real-world projects. They highlighted the importance of understanding the problem domain and choosing the right architecture for the specific needs, rather than blindly following trends.
Another commenter pointed out the potential disconnect between architects who design systems and the developers who actually build and maintain them. They emphasized the need for architects to be more hands-on and involved in the implementation process, gaining practical experience with the technologies they advocate. This, they argued, would lead to more realistic and effective architectural decisions.
The discussion also touched upon the importance of communication and collaboration between architects and developers. One comment suggested that the issue isn't necessarily architects themselves, but rather a lack of clear communication and shared understanding. They advocated for a more collaborative approach, where architects and developers work together to define the architecture and ensure its successful implementation.
A different perspective was offered by a commenter who argued that architects do have a valuable role to play in microservice adoption, particularly in large organizations. They suggested that architects can help establish guidelines, patterns, and best practices for implementing microservices consistently across different teams. However, they acknowledged the risk of architects becoming detached from the realities of development, reinforcing the need for practical experience and ongoing communication.
Some commenters also discussed the potential downsides of microservices, such as increased complexity, operational overhead, and the need for robust monitoring and logging. They cautioned against adopting microservices prematurely or without a clear understanding of the benefits and trade-offs.
While there was a general agreement on the challenges associated with microservice adoption and the importance of pragmatic architectural decisions, the comments also highlighted the diverse perspectives on the role of architects in this process. The discussion emphasized the need for collaboration, communication, and a deep understanding of both the technical and organizational context when implementing microservices.