this repo has no description
:art:
+18
-14
+1
Coordination.md
+1
Coordination.md
···
3
3
- Human coordination in groups ([[Teamwork]], [[Cooperatives]], [[Decentralized Autonomous Organizations]]) to achieve aims is the secret sauce of human civilization. If it could be engineered, a lot of problems would have been solved.
4
4
- Coordination problems are a [constraint to production of all kinds of economic value](https://www.lesswrong.com/posts/P6fSj3t4oApQQTB7E/coordination-as-a-scarce-resource).
5
5
- All problems are coordination problems. Moloch is at the end of all!
6
+
- The Second Law of Consulting: No matter how it looks at first, it's always a people problem.
6
7
- [Coordination](https://vitalik.ca/general/2020/09/11/coordination.html), the ability for large [[Teamwork|groups of actors to work together]] for their common interest, is one of the most powerful forces in the universe. It can be improved in many ways:
7
8
- Faster spread of information.
8
9
- Better norms that identify what behaviors are classified as cheating along with more effective punishments.
+3
-3
Data/Data Culture.md
+3
-3
Data/Data Culture.md
···
16
16
- [Data teams should be a part of the business conversations from the beginning](https://cultivating-algos.stitchfix.com/). Get the data team involved early, have open discussions with them about the existing work, and how to prioritize new work against the existing backlog. Don’t accept new work without addressing the existing bottlenecks, and don’t accept new work without requirements. **Organizational [[politics]] matter way more than any data methods or technical knowledge**.
17
17
- Including data people in meetings causes happy accidents!
18
18
- The layout of the organization impacts time of the information to propagate and adds losses.
19
-
- The modern data team needs to have *real organizational power*—it needs to be able to say "no” and mean it. If your data team does not truly have the power to say no to stakeholders, it will get sent on all kinds of wild goose chases, be unproductive, experience employee churn, etc.
19
+
- The modern data team needs to have *real organizational power* — it needs to be able to say "no” and mean it. If your data team does not truly have the power to say no to stakeholders, it will get sent on all kinds of wild goose chases, be unproductive, experience employee churn, etc.
20
20
- Data should report to the CEO. Ideally at least with some weekly metrics split into (a) notable trends, (b) watching close, and (c) business as usual.
21
21
- If data is the most precious asset in a company, does it make sense to have only one team responsible for it?
22
22
- [People talk about data as the new oil but for most companies it’s a lot closer uranium](https://news.ycombinator.com/item?id=27781286). Hard to find people who can to handle or process it correctly, nontrivial security/liabilities if PII is involved, expensive to store and a generally underwhelming return on effort relative to the anticipated utility.
23
-
- [The pain in data teams come from needing to influence PMs/peers with having little control of them. Data teams need to become really great internal marketers/persuaders](https://anchor.fm/census/episodes/The-evolution-of-the-data-industry--data-jobs-w-Avo-CEO-and-Co-founder-Stefania-Olafsdottir-e16hu1l). That said, it shouldn't be the data team job to convince the organization to be data driven. That's not an effective way of spending resources.
23
+
- [The pain in data teams come from needing to influence PMs/peers with having little control of them. Data teams need to become really great internal marketers/persuaders](https://anchor.fm/census/episodes/The-evolution-of-the-data-industry--data-jobs-w-Avo-CEO-and-Co-founder-Stefania-Olafsdottir-e16hu1l). That said, it shouldn't be the data team job to convince the organization to be data driven. That's not an effective way of spending resources.
24
24
- People problems are orders of magnitude more difficult to solve than data problems.
25
25
- **Integrate data where the decision is made**. E.g: Google showing restaurant scores when you're looking something for dinner.
26
26
- Reduce the time to insights. If the data is already in the tool you're using, then there's zero time to insights. Provide a set of tools with the same data and let people choose depending on the goal.
···
63
63
- Is Data Accessible and Discoverable?
64
64
- Is Data Secure?
65
65
- [Good things come from a knowledge of what a system is doing and when it is doing it](https://buz.dev/blog/the-contract-powered-data-platform).
66
-
- Measure [[Data Quality]] to help set high standards for your data team.
66
+
- Measure [[data quality]] to help set high standards for your data team.
67
67
- Only after measurement can you optimize cost.
68
68
- Only after timing can you make things faster.
69
69
- [Aim for a culture of celebrating measurable progress and learnings, versus celebrating shipping](https://erikbern.com/2021/07/07/the-data-team-a-short-story.html).
+1
Learning.md
+1
Learning.md
···
3
3
- Learning is a process of [[Conceptual Compression]].
4
4
- Understand the base and build from it. First Principles Method. Seek the big picture understanding - focus on concepts not details.
5
5
- Read about topics you care, observe the world around you and keep a beginner's mind (*shoshin*).
6
+
- Find a mentor if you can and ask them questions.
6
7
- Don't be afraid to[[Asking Questions|ask a question]] that may sound stupid because 99% of the time everyone else is thinking of the same question and is too embarrassed to ask it.
7
8
- You can apply [The Feynman Technique](https://www.farnamstreetblog.com/2012/04/learn-anything-faster-with-the-feynman-technique/):
8
9
1. Identify the subject.
+1
Personal Handbooks.md
+1
Personal Handbooks.md
+1
-1
Programming.md
+1
-1
Programming.md
···
18
18
- **Do one thing and do it well**.
19
19
- By focusing on a single task, a program or function can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and a lack of flexibility. [Good software makes hard things easy](https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d).
20
20
- Design composable primitives.
21
-
- **Make it work, make it right, make it fast**.
21
+
- [**Make it work, make it right, make it fast**](https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast).
22
22
- Build a prototype as soon as possible to get a sense of the entire process.
23
23
- Once you have a working prototype, apply guidelines and previous learnings. Then, focus on performance.
24
24
- There is nothing so useless as doing efficiently that which should not be done at all.
+1
Quotes.md
+1
Quotes.md
···
64
64
- It's _chapuzas_ all the way down. Me on my dreams.
65
65
- [You will observe with concern how long a useful truth may be known, and exist, before it is generally received and practiced on](https://www.youtube.com/watch?v=IV3dnLzthDA). Benjamin Franklin.
66
66
- People are tribal. The more settled things are, the bigger the tribes can be. The churn comes, and the tribes get small again. Amos Burton.
67
+
- What got you here won't get you there. Marshall Goldsmith.
67
68
68
69
## External Lists
69
70
+10
-10
Teamwork.md
+10
-10
Teamwork.md
···
1
1
# Teamwork
2
2
3
-
- Explicitly define the [[values]] and desired [[culture]] of your team.
4
-
- Share a vision to make [loosely coupled, tightly aligned teams](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/). Then, define the strategy with [[Writing Team Key Results|great key results]].
3
+
- Explicitly define the [[values]], vision, and desired [[culture]] of your team.
4
+
- Define the vision to promote [loosely coupled, tightly aligned teams](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/). Then, define the strategy with [[Writing Team Key Results|great key results]].
5
5
- When coming up with a long-term vision is important to stay abstract.
6
-
- Stick to defining components and keep concepts generic (cache, [[Databases]], algorithm, ...). Show how the components interact.
7
-
- Define boundaries and limitations of each component.
6
+
- Stick to defining components and keep concepts generic (cache, [[databases]], algorithm, ...). Show how the components interact.
7
+
- Define boundaries and limitations of each component.
8
8
- Work in the open and [[Documentation|document]] everything. Transparency increases understanding and reduces synchronization challenges. **[Emulate Open Source projects](https://tomayko.com/blog/2012/adopt-an-open-source-process-constraints) and [[Remote Jobs|remote companies]]**.
9
9
- To make everyone more productive and happy: **Make feedback loops fast**. [Some best practices](https://simonwillison.net/2022/Oct/1/software-engineering-practices/):
10
10
- Tested, automated process for new development environments.
···
16
16
- Create a [[Company Handbooks|handbook]] to store your [[Company Knowledge Management|company knowledge]]. Document:
17
17
- [[Processes]]. Status updates, [[Design Docs]], [on-boarding docs/scripts](https://about.gitlab.com/blog/2020/02/10/lessons-learned-as-data-team-manager/), [[Checklist]], ...
18
18
- Decisions. Context and rationale can be documented in a durable location.
19
-
- Each team should [keep a changelog](https://keepachangelog.com/en/1.0.0/). [The company too](https://medium.com/linear-app/startups-write-changelogs-c6a1d2ff4820). ^473cb4
20
-
- Aim to [confirm and log decisions](https://understandlegacycode.com/blog/earn-maintainers-esteem-with-adrs/) to move them forward. [Everything must have an URL](https://ben.balter.com/2015/11/12/why-urls/).
21
-
- Show your work. Capture who made what decision and when, along with a detailed, but _concise_ description of why and how that decision was made.
22
-
- Consistent changelogs also communicate new features, the value they get from your product, and your commitment to improving it.
19
+
- Each team should [keep a changelog](https://keepachangelog.com/en/1.0.0/). [The company too](https://medium.com/linear-app/startups-write-changelogs-c6a1d2ff4820). ^473cb4
20
+
- Aim to [confirm and log decisions](https://understandlegacycode.com/blog/earn-maintainers-esteem-with-adrs/) to move them forward. [Everything must have an URL](https://ben.balter.com/2015/11/12/why-urls/).
21
+
- Show your work. Capture who made what decision and when, along with a detailed, but _concise_ description of why and how that decision was made.
22
+
- Consistent changelogs also communicate new features, the value they get from your product, and your commitment to improving it.
23
23
- [[Meetings]] agendas and conclusions.
24
24
- Responsibilities. Things that aren't your fault can still be your responsibility. If something is everyone's job, it's no one's job.
25
25
- Defaults. Each thing should have a place by default, docs, issues, ...
···
67
67
5. [[Automation|Automate]] and keep standards.
68
68
- Keep great global [[coordination]] and incentive local experimentation.
69
69
- Being able to run small and compounding experiments (on the product or company [[processes]] and systems) is important. **Work smaller**.
70
-
- [Some experiments won't work](https://www.lesswrong.com/posts/97LgacucCxmyjYiNT/the-archipelago-model-of-community-standards). But oftentimes it _feels_ like it wont work when in fact you just haven't stuck with it long enough for it to bear fruit. This is hard enough for _solo_ experiments. For group experiments, where not just one but _many_ people must all try a thing at once and _get good at it_, all it takes is a little defection to spiral into a mass exodus.
70
+
- [Some experiments won't work](https://www.lesswrong.com/posts/97LgacucCxmyjYiNT/the-archipelago-model-of-community-standards). But oftentimes it _feels_ like it wont work when in fact you just haven't stuck with it long enough for it to bear fruit. This is hard enough for _solo_ experiments. For group experiments, where not just one but _many_ people must all try a thing at once and _get good at it_, all it takes is a little defection to spiral into a mass exodus.
71
71
- The group with the most power determine the system that reflect and reinforce their own way of thinking. Aim for inclusion. _Diversity is being invited to the party. Inclusion is being asked to dance and help organizing the party_.
72
72
- [Brainstorm for questions first (explore). Then find the answers (exploit).](https://getpocket.com/explore/item/better-brainstorming)
73
73
- Strive for constructive conflict. Get people to[[Asking Questions|ask questions]]. Engage in passionate, unfiltered debate about what you need to do to succeed.
···
97
97
- [Learned helplessness](https://en.wikipedia.org/wiki/Learned_helplessness) can happen in a team. Two of the main reasons of this [normalization of deviance](https://danluu.com/wat/):
98
98
- The team needs to follow processes that have either been externally imposed, or internally imposed but no-one remembers exactly why.
99
99
- The sheer scale and/or complexity of how things work. There is truly no-one who understands the emergent behavior of the [[Systems|system]].
100
-
- E.g: Slow _boiling frog_ situations where existing tools have become ineffective but no one noticed.
100
+
- E.g: Slow _boiling frog_ situations where existing tools have become ineffective but no one noticed.
101
101
- [Act as if you might leave on short notice](https://jmmv.dev/2021/04/always-be-quitting.html). Document your knowledge, long-term plans, meetings, train people around you, empower other people, delegate and keep learning!
102
102
- You have to put in more effort to make something appear effortless. Effortless, elegant performances are often the result of a large volume of effortful. Praise this instead of complex solutions.
103
103
- Invisible work will happen. If you're doing it, make an effort to share and get credit for it. Build a narrative (story) for your work. Arm your manager and fight recency bias keeping track of all the things you've done.