davidgasquez.com
📚 Personal bits of knowledge
🍿 Politics in organizations
+1
Politics.md
+1
Politics.md
···
54
- [Architecture is Politics](https://web.archive.org/web/20070607161518/blog.kapor.com/?p=29). Freedom, participation, creativity, and openness are better fostered by a [[Decentralized Protocols|decentralized]] but [[coordination|coordinated]] architecture.
55
- [[Plurality]] — the understanding that diversity of people, beliefs, opinions, mechanisms, approaches, implementations, etc within a given context generally results in better outcomes than in the absence of such diversity.
56
- For many social systems, truly large-scale, repeatable tests (to verify systems work as intended) are difficult if not impossible. Having simple systems is critical to legitimacy.
57
58
## [Voting Theory](https://www.lesswrong.com/posts/D6trAzh6DApKPhbv4/a-voting-theory-primer-for-rationalists)
59
···
54
- [Architecture is Politics](https://web.archive.org/web/20070607161518/blog.kapor.com/?p=29). Freedom, participation, creativity, and openness are better fostered by a [[Decentralized Protocols|decentralized]] but [[coordination|coordinated]] architecture.
55
- [[Plurality]] — the understanding that diversity of people, beliefs, opinions, mechanisms, approaches, implementations, etc within a given context generally results in better outcomes than in the absence of such diversity.
56
- For many social systems, truly large-scale, repeatable tests (to verify systems work as intended) are difficult if not impossible. Having simple systems is critical to legitimacy.
57
+
- Politics is just how humans coordinate in groups. It’s the invisible network of relationships, influence, and informal power that exists in every organization. [You can refuse to participate, but that doesn't make it go away](https://terriblesoftware.org/2025/10/01/stop-avoiding-politics/). It just means decisions get made without you. The alternative to good politics isn't no politics. It's bad politics winning by default.
58
59
## [Voting Theory](https://www.lesswrong.com/posts/D6trAzh6DApKPhbv4/a-voting-theory-primer-for-rationalists)
60
+9
Teamwork.md
+9
Teamwork.md
···
65
- On the other hand, beware of changing too many things. You don't feel the pain of things you're not doing!
66
- Scale organizational efforts across a portfolio of synergistic products.
67
- Don't replace prototypes with roadmaps. Encourage prototyping to learn and build confidence with different parts of your software stack.
68
- Ask people ["when do you think you'll get this done"](https://mobile.twitter.com/Carnage4Life/status/1438982223395393536), write it down and then follow up at that time. That makes teams more effective.
69
- Every document must have a specific goal written at the top of it.
70
- When building something:
···
137
- Make [small, achievable changes rather than large risky leaps](https://medium.com/@komorama/the-iterative-adjacent-possible-af3e7038357d). Each step should be within the "adjacent possible" - what can be realistically accomplished.
138
- Prefer combining proven components in new ways over building everything from scratch.
139
- [Communicate state, not just deltas](https://experimentalworks.net/posts/2024-01-16-communicate-state/). Communicating state rather than updates significantly increases the clarity of what you are trying to communicate. It makes it easier to follow and engage as it reduces the amount of context other people need to have to understand what you are trying to communicate.
140
141
## [How Small Teams Work](https://posthog.com/handbook/people/team-structure/why-small-teams#how-it-works)
142
···
65
- On the other hand, beware of changing too many things. You don't feel the pain of things you're not doing!
66
- Scale organizational efforts across a portfolio of synergistic products.
67
- Don't replace prototypes with roadmaps. Encourage prototyping to learn and build confidence with different parts of your software stack.
68
+
- Never be shy to give credit to others!
69
- Ask people ["when do you think you'll get this done"](https://mobile.twitter.com/Carnage4Life/status/1438982223395393536), write it down and then follow up at that time. That makes teams more effective.
70
- Every document must have a specific goal written at the top of it.
71
- When building something:
···
138
- Make [small, achievable changes rather than large risky leaps](https://medium.com/@komorama/the-iterative-adjacent-possible-af3e7038357d). Each step should be within the "adjacent possible" - what can be realistically accomplished.
139
- Prefer combining proven components in new ways over building everything from scratch.
140
- [Communicate state, not just deltas](https://experimentalworks.net/posts/2024-01-16-communicate-state/). Communicating state rather than updates significantly increases the clarity of what you are trying to communicate. It makes it easier to follow and engage as it reduces the amount of context other people need to have to understand what you are trying to communicate.
141
+
- You don't get to avoid "politics" in software, because building is collaborative, and all collaboration is political. No matter how correct or elegant your code is or how good your idea is, if you haven't built the relationships or put consideration into the broader social dynamic, you're much less likely to succeed. [The social stuff is usually the hardest part of any software developer's job, and, perhaps, especially so with distributed systems development](https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/).
142
+
- [Ideas don't speak. People do](https://terriblesoftware.org/2025/10/01/stop-avoiding-politics/). And the people who understand how to navigate organizational dynamics, build relationships, and yes, play politics? Their ideas get heard.
143
+
- [Here's what good politics looks like in practice](https://terriblesoftware.org/2025/10/01/stop-avoiding-politics/):
144
+
1. Building relationships before you need them.
145
+
2. Understanding the real incentives.
146
+
3. Managing up effectively.
147
+
4. Creating win-win situations.
148
+
5. Being visible. Share your wins, present at all-hands, write those design docs that everyone will reference later.
149
150
## [How Small Teams Work](https://posthog.com/handbook/people/team-structure/why-small-teams#how-it-works)
151