this repo has no description
:art:
+75
-68
+1
Company Handbooks.md
+1
Company Handbooks.md
+1
Curiosity.md
+1
Curiosity.md
···
11
11
- [If you think you're going to regret not doing something, you should probably do it](https://blog.samaltman.com/the-days-are-long-but-the-decades-are-short). Most people regret far more things they didn't do than things they did do.
12
12
- [Find your way around the inertia of helpless mentality](https://www.youtube.com/watch?v=YMPzDiraNnA). You probably have control of more things that you think! Knowing this fact changes the way you see your circle of control.
13
13
- [Practice hunting for bugs](https://radimentary.wordpress.com/2018/01/29/hammertime-day-1-bug-hunt/?utm_source=pocket_mylist)! A bug is anything in life that needs improvement. Even if something is going well, if you can imagine it going better, there's a bug.
14
+
- Knowing we really want is hard and takes effort. Explore yourself and your [[Values]].
+1
-1
Data/Open Source Data Projects.md
+1
-1
Data/Open Source Data Projects.md
···
51
51
52
52
---
53
53
54
-
More at the [`awesome-oss-alternatives` repository]() and my [Open Source Stack GitHub Curated List](https://github.com/stars/davidgasquez/lists/open-source-stack)
54
+
More at the [`awesome-oss-alternatives` repository](https://github.com/RunaCapital/awesome-oss-alternatives) and my [Open Source Stack GitHub Curated List](https://github.com/stars/davidgasquez/lists/open-source-stack)
+4
-3
Evolution.md
+4
-3
Evolution.md
···
1
1
# Evolution
2
2
3
3
- Evolution is a behavior that emerges in any system that has:
4
-
1. Mutation
5
-
2. Heredity
6
-
3. Selection
4
+
1. Mutation
5
+
2. Heredity
6
+
3. Selection
7
7
- Evolutionary systems often generate unexpected solutions. [Nature selects for good enough](http://gordonbrander.com/pattern/evolution/). It affects almost everything (life, [[ideas]], communities, [[systems]], ...).
8
+
- Nature ended up: resilient to disturbances, decentralized, redundant, diverse, and self-healing.
8
9
- Every [[Culture]] is the gradual accumulation of useful environmental adaptations combined with random memetic drift.
9
10
- [[Systems]] that evolve organically are usually, [but not always](https://slatestarcodex.com/2017/03/16/book-review-seeing-like-a-state/), well-adapted to their purpose. Cultures, ancient traditions, and long-lasting institutions contain irreplaceable wisdom that's hard to pin down if you're designing them from scratch.
+3
-3
Focus.md
+3
-3
Focus.md
···
3
3
[Focus (absorption, concentration) is the ability to narrow the attention so as to apply it in a more detailed and penetrating way for sustained periods of time on some chosen part of your present experience](https://www.lesswrong.com/s/xqgwpmwDYsn8osoje/p/35eEHAXis3jMqETod).
4
4
5
5
- Whatever your primary motivations are in life, you won't get anywhere by waiting for something to happen. Plan!
6
-
- Humans do not think [[Thinking |strategically]] by default.
6
+
- Humans do not think [[Thinking |strategically]] by default.
7
7
- Environmental changes can make it easier to attend effectively to the right things.
8
-
- Removing clutter and other distractions can make attention less difficult, for which the virtues of orderliness and simplicity can help.
9
-
- Disable notifications and badges so that you don't mindlessly open distracting apps.
8
+
- Removing clutter and other distractions can make attention less difficult, for which the virtues of orderliness and simplicity can help.
9
+
- Disable notifications and badges so that you don't mindlessly open distracting apps.
10
10
- [[Mental Health#Meditation |Mindfulness meditation]], e.g. breath-counting, seems to be a go-to technique for developing focus.
11
11
- Periodic exposure to nature and out-of-doors in an relaxing, undemanding way can restore attention capability.
12
12
- [Attention is a scarce resource](https://youtu.be/ZWI4_Oe-Qbs). Everything in the world is fighting to get yours.
+65
-61
Teamwork.md
+65
-61
Teamwork.md
···
2
2
3
3
- Explicitly define the [[values]] and desired [[culture]] of your team.
4
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]].
5
-
- When coming up with a long-term vision is important to stay abstract.
6
-
- Stick to defining components and keep concepts generic (cache, database, algorithm, ...). Show how the components interact.
7
-
- Define boundaries and limitations of each component.
5
+
- When coming up with a long-term vision is important to stay abstract.
6
+
- Stick to defining components and keep concepts generic (cache, database, 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
-
- Tested, automated process for new development environments.
11
-
- Automated preview environments.
12
-
- Automated code formatting.
13
-
- Templates for new projects and components.
14
-
- Mechanisms for creating test data.
15
-
- Invest in [thoughtful logging](https://www.16elt.com/2023/01/06/logging-practices-I-follow/a).
10
+
- Tested, automated process for new development environments.
11
+
- Automated preview environments.
12
+
- Automated code formatting.
13
+
- Templates for new projects and components.
14
+
- Mechanisms for creating test data.
15
+
- Invest in [thoughtful logging](https://www.16elt.com/2023/01/06/logging-practices-I-follow/a).
16
16
- Create a [[Company Handbooks |handbook]] to store your [[Company Knowledge Management |company knowledge]]. Document:
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
-
- 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.
23
-
- [[Meetings]] agendas and conclusions.
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
-
- Defaults. Each thing should have a place by default, docs, issues, ...
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
+
- 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.
23
+
- [[Meetings]] agendas and conclusions.
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
+
- Defaults. Each thing should have a place by default, docs, issues, ...
26
26
- Aim to be a completely autonomous team. Everyone should feel empower to make decisions. Those who are responsible for something must have the means and context to effect it. You build it, you run it! **The company strategy guides the team, it doesn't tell it what to do.**
27
27
- Run [Automated Check-ins](https://basecamp.com/features/checkins) to share things explicitly. What are people working on, what are they planning to work on next, ...
28
28
- The right way to promote people is to give them meaningful goals for the organization and promote them if they hit the goals.
29
29
- Lack of ownership is the root of all evil.
30
-
- Having skin in the game improves the decision making process.
31
-
- [Have direct responsible individuals for everything. Everyone's problem is no one's problem](https://nintil.com/programming). Having a name accountable instead of a vague "the team" or "the process" makes it easy to make changes.
30
+
- Having skin in the game improves the decision making process.
31
+
- [Have direct responsible individuals for everything. Everyone's problem is no one's problem](https://nintil.com/programming). Having a name accountable instead of a vague "the team" or "the process" makes it easy to make changes.
32
32
- Write postmortems after large changes. This will create [[Feedback Loops]] to guide learning about what happened and how it can be avoided next time. It'll also help calibrate for the previous decisions.
33
33
- Do [lightweight self reviews](https://andrewhuth.substack.com/p/writing-good-performance-self-reviews) . Worst case scenario, they help you update your resume.
34
34
- Make time to pay technical debt. [[Systems]] evolve organically over time and might get stuck on a local maximum. Alternative abstractions/designs might be better to continue progressing! There are two kinds of tech debt:
35
-
- Things you haven't built yet.
36
-
- Things you shouldn't have built that way.
35
+
- Things you haven't built yet.
36
+
- Things you shouldn't have built that way.
37
37
- Accidental complexity is a sum of all the shortcuts you have taken. Complexity attracts more complexity and compounds in a non-linear way. Every shortcut you take is an invitation to more shortcuts elsewhere.
38
38
- When the context changes a lot, you can use [the blue tape technique](https://randsinrepose.com/archives/the-blue-tape-list/) to notice what is wrong with it:
39
-
1. Notice everything that feels off.
40
-
2. Make a list of everything that feels off, no matter how big or small.
41
-
3. Wait a bit, like a month, but address everything.
42
-
- This translates to ideas to review, tools to try, docs you want to write up, ...
39
+
40
+
1. Notice everything that feels off.
41
+
2. Make a list of everything that feels off, no matter how big or small.
42
+
3. Wait a bit, like a month, but address everything.
43
+
44
+
- This translates to ideas to review, tools to try, docs you want to write up, ...
43
45
- Culture should incentive people to fix things outside their area. Encourage submitting Pull Requests that might be rejected.
44
46
- Teams [need slack to absorb and adapt when unexpected things come up](https://www.neelnanda.io/blog/38-slack) and to prioritize the development of force multipliers (tooling and automation).
45
-
- Lack of [[slack]] compounds. It gets harder and harder to get out as more things get added to backlogs and more patches get added on the systems you build (slowing you down in the end).
46
-
- A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done.
47
-
- [Balance putting code where they are most comfortable while optimizing for speed vs putting the code where it belongs when considering a longer term perspective on the overall system.](https://twitter.com/jmwind/status/1477399261700526080).
47
+
- Lack of [[slack]] compounds. It gets harder and harder to get out as more things get added to backlogs and more patches get added on the systems you build (slowing you down in the end).
48
+
- A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done.
49
+
- [Balance putting code where they are most comfortable while optimizing for speed vs putting the code where it belongs when considering a longer term perspective on the overall system.](https://twitter.com/jmwind/status/1477399261700526080).
48
50
- **Focus on business outcomes, not on technologies.**
49
51
- When you start from a shared understanding – that you’re all doing your best you can – you can foster a compassionate working environment.
50
-
- Everyone on your team should assume that everyone else on the team is doing their best work, given their circumstances.
51
-
- Trust people. Add [[Processes]] where you need to replace some level of trust.
52
+
- Everyone on your team should assume that everyone else on the team is doing their best work, given their circumstances.
53
+
- Trust people. Add [[Processes]] where you need to replace some level of trust.
52
54
- Times change, trends change, cultures change. Make it explicit.
53
55
- Spend time at work thinking strategically. E.g: Think about the approach you will take to address the company's needs over the medium to long term.
54
56
- **How to drive change in a team**: find people who agree on the problem, start small, experiment, scale, repeat. Making big change is hard. Keeping things simple is hard.
55
-
- On the other hand, beware of changing too many things. You don't feel the pain of things you're not doing!
57
+
- On the other hand, beware of changing too many things. You don't feel the pain of things you're not doing!
56
58
- Scale organizational efforts across a portfolio of synergistic products.
57
59
- Don't replace prototypes with roadmaps. Encourage prototyping to learn and build confidence with different parts of your software stack.
58
60
- 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.
59
61
- Every document must have a specific goal written at the top of it.
60
62
- When building something:
61
-
1. Question everything.
62
-
2. Remove more than you add.
63
-
3. Optimize what works.
64
-
4. Shorten iteration cycles. **[Boyd's Law of Iteration](https://blog.codinghorror.com/boyds-law-of-iteration/): speed of iteration beats quality of iteration**.
65
-
5. [[Automation |Automate]] and keep standards.
63
+
64
+
1. Question everything.
65
+
2. Remove more than you add.
66
+
3. Optimize what works.
67
+
4. Shorten iteration cycles. **[Boyd's Law of Iteration](https://blog.codinghorror.com/boyds-law-of-iteration/): speed of iteration beats quality of iteration**.
68
+
5. [[Automation |Automate]] and keep standards.
69
+
66
70
- Keep great global [[coordination]] and incentive local experimentation.
67
-
- Being able to run small and compounding experiments (on the product or company [[processes]] and systems) is important. **Work smaller**.
68
-
- [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.
69
-
- 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*.
71
+
- Being able to run small and compounding experiments (on the product or company [[processes]] and systems) is important. **Work smaller**.
72
+
- [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.
73
+
- 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_.
70
74
- [Brainstorm for questions first (explore). Then find the answers (exploit).](https://getpocket.com/explore/item/better-brainstorming)
71
75
- Strive for constructive conflict. Get people to [[Asking Questions |ask questions]]. Engage in passionate, unfiltered debate about what you need to do to succeed.
72
76
- Encourage to fail. Failing is good if the team [[Learning |learns]] from it!
···
76
80
- Use long-form [[Writing]], rather than [[Meetings]], speaking, and chatting. Speaking only helps who's in the room, [[Writing]] helps everyone.
77
81
- Finish projects before starting more.
78
82
- Prioritize things that will compound [on shipping faster](https://youtu.be/p2XVU7jLGQw).
79
-
- Make time to build abstractions and tools that increase your team's pace of shipping. Focus on Developer Experience.
80
-
- Break big ideas into small digestible pieces.
81
-
- Weeks of programming can save you hours of [[planning]]. Plan and write [[Design Docs]]!
82
-
- Reduce blockers. Every [small inconvenience](https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-trivial-inconveniences) slows much more than it might seem. [Blockers are death. Above all else, your job is to unblock anything that prevents you from moving as fast as you can toward your top priority.](https://www.lesswrong.com/posts/6LzKRP88mhL9NKNrS/how-my-team-at-lightcone-sometimes-gets-stuff-done)
83
-
- Deploy often. Don't wait for perfection. Ship and iterate. Fix time and change the scope.
84
-
- When everything is important then nothing is important.
83
+
- Make time to build abstractions and tools that increase your team's pace of shipping. Focus on Developer Experience.
84
+
- Break big ideas into small digestible pieces.
85
+
- Weeks of programming can save you hours of [[planning]]. Plan and write [[Design Docs]]!
86
+
- Reduce blockers. Every [small inconvenience](https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-trivial-inconveniences) slows much more than it might seem. [Blockers are death. Above all else, your job is to unblock anything that prevents you from moving as fast as you can toward your top priority.](https://www.lesswrong.com/posts/6LzKRP88mhL9NKNrS/how-my-team-at-lightcone-sometimes-gets-stuff-done)
87
+
- Deploy often. Don't wait for perfection. Ship and iterate. Fix time and change the scope.
88
+
- When everything is important then nothing is important.
85
89
- Constantly prioritize. Communicating with the team to make sure everyone understands the what and the why of the priorities, especially in times of change, and is aligned with clarity to move forward.
86
90
- Assign as few possible to a project. Should have an owner and a stakeholder.
87
91
- [Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance](https://jacobian.org/2022/sep/9/quality-is-systemic/).
88
-
- This implies system with tests, easy development environments, CI/CD, documentation, culture, ...
92
+
- This implies system with tests, easy development environments, CI/CD, documentation, culture, ...
89
93
- Optimizing for short term speed is dangerous if you don't allow some slack to pick up things that will make you faster in the long run.
90
-
- If you want to optimize for speed, you need an experimentation platform to track the impact of changes. Teams need to learn how to [disagree and commit](https://en.wikipedia.org/wiki/Disagree_and_commit).
94
+
- If you want to optimize for speed, you need an experimentation platform to track the impact of changes. Teams need to learn how to [disagree and commit](https://en.wikipedia.org/wiki/Disagree_and_commit).
91
95
- Look for a way to decouple things as much as possible and don't aim for perfection. Aim for eventual convergence.
92
96
- Beware of [potential things that might harm your team](https://twitter.com/bernhardsson/status/1594722618585874432).
93
97
- When proposing a change, add context to why is important and how it'll impact people.
94
98
- [Standards make it easy for new team members to onboard and enhance efficiency in the long run (removes micro-decisions)](https://seattledataguy.substack.com/p/setting-standards-for-your-data-team).
95
99
- [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/):
96
-
- The team needs to follow processes that have either been externally imposed, or internally imposed but no-one remembers exactly why.
97
-
- The sheer scale and/or complexity of how things work. There is truly no-one who understands the emergent behavior of the [[Systems |system]].
98
-
- E.g: Slow _boiling frog_ situations where existing tools have become ineffective but no one noticed.
100
+
- The team needs to follow processes that have either been externally imposed, or internally imposed but no-one remembers exactly why.
101
+
- The sheer scale and/or complexity of how things work. There is truly no-one who understands the emergent behavior of the [[Systems |system]].
102
+
- E.g: Slow _boiling frog_ situations where existing tools have become ineffective but no one noticed.
99
103
- [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!
100
104
- 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.
101
105
- 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.
102
106
- As a manager, give problems to solve, not solutions. Make sure the team knows what they're working toward and that it has the resources needed to complete the work.
103
107
- Most software or processes should be opinionated. In increases [[Coordination |collaboration]]. Flexible processes lets everyone invent their own workflows, which eventually creates chaos as teams scale.
104
108
- As teams scale, traditional approaches to decision making force a tradeoff between transparency and efficiency.
105
-
- The easiest way to ensure everyone can understand the how and why of a decision is to adopt systems that, through their daily operation, ensure such context is automatically and readily available to those who might want it (and explicitly not only those who presently need it).
109
+
- The easiest way to ensure everyone can understand the how and why of a decision is to adopt systems that, through their daily operation, ensure such context is automatically and readily available to those who might want it (and explicitly not only those who presently need it).
106
110
- [Run 1:1s (one-on-ones)](https://erik.wiffin.com/posts/how-to-get-the-most-out-of-your-11s/). A recurring meeting with no set agenda between a manager and one of their reports. Don’t make it a status update (these should be async). Chat about anything bothering you, career growth or type work that is interesting for you. End it with actionable next steps.
107
111
- Say no a lot, up front. [Distractions are anything that doesn’t help you keep your existing features running, or deliver your top priority faster](https://alexturek.com/2022-03-07-How-to-do-less/). Finishing work is more important than starting it.
108
112
- As a new team member:
109
-
- Ask questions without judging. Never ever be _negative_ about the stuff they created. It was done for a reason.
110
-
- Beware of [Normalization of Deviance](https://danluu.com/wat/).
113
+
- Ask questions without judging. Never ever be _negative_ about the stuff they created. It was done for a reason.
114
+
- Beware of [Normalization of Deviance](https://danluu.com/wat/).
111
115
- When meeting/emailing interesting people ask if they know anyone else you can meet with. [Try to expand your network with successful folks in the area/space!](https://twitter.com/AdamRy_n/status/1297920306900865024)
112
116
- Keep a [private work log](https://youtu.be/HiF83i1OLOM?list=PLYXaKIsOZBsu3h2SSKEovRn7rGy7wkUAV). It'll make easier for everyone to advocate what you did.
113
117
···
127
131
- There's a real danger in thinking that what made you successful in the past will make you successful now.
128
132
- Read all the things.
129
133
- The team you'll be working on will probably have some kind of [normalized deviance](https://danluu.com/wat/). Try to [understand why everything is as it is](https://fs.blog/chestertons-fence/) before doing any recommendations. Don't come in with "the answers".
130
-
- [Chesterton’s fence](https://www.meyerperin.com/posts/2022-04-02-chestertons-fence.html) is an important concept to keep in mind when starting a new job or a new scope of work. The [context of why a certain architectural choice was made](https://vickiboykis.com/2021/11/07/the-programmers-brain-in-the-lands-of-exploration-and-production/) is just as important as understanding its current pain points.
134
+
- [Chesterton’s fence](https://www.meyerperin.com/posts/2022-04-02-chestertons-fence.html) is an important concept to keep in mind when starting a new job or a new scope of work. The [context of why a certain architectural choice was made](https://vickiboykis.com/2021/11/07/the-programmers-brain-in-the-lands-of-exploration-and-production/) is just as important as understanding its current pain points.
131
135
- Record first impressions / friction log as you go. [Beginner's mind has real value](https://eugeneyan.com/writing/onboarding/)!
132
136
- Build great relationships so you can be supported in decisions to get some early wins.
133
-
- One of the most valuable things you can do during onboarding is update/write documentation.
137
+
- One of the most valuable things you can do during onboarding is update/write documentation and [create/update checklist of all the processes](https://lifeitself.org/tao/onboarding#create-an-onboarding-issue). This will help you and your team in the long run.
134
138
- [Make bite-sized impact, fast](https://stormdata.substack.com/p/reflecting-on-my-impact-during-my).
135
139
136
140
## Links
137
141
138
142
- [Ways of Working](https://github.com/joelparkerhenderson/ways-of-working) - Guidelines that improve teamwork and communication.
139
143
- Team Management.
140
-
- [IPFS](https://github.com/ipfs/team-mgmt).
141
-
- [Kubernetes Governanve](https://github.com/kubernetes/community/blob/master/governance.md).
142
-
- [Linear Method](https://linear.app/method/introduction).
144
+
- [IPFS](https://github.com/ipfs/team-mgmt).
145
+
- [Kubernetes Governanve](https://github.com/kubernetes/community/blob/master/governance.md).
146
+
- [Linear Method](https://linear.app/method/introduction).
143
147
- Guides to Communications:
144
-
- [Gitlab Communications](https://about.gitlab.com/handbook/communication/).
145
-
- [Basecamp Communications](https://basecamp.com/guides/how-we-communicate).
148
+
- [Gitlab Communications](https://about.gitlab.com/handbook/communication/).
149
+
- [Basecamp Communications](https://basecamp.com/guides/how-we-communicate).
146
150
- [Engineering Fundamentals Checklist](https://microsoft.github.io/code-with-engineering-playbook/ENG-FUNDAMENTALS-CHECKLIST/).
147
151
- [Know Your Team](https://knowyourteam.com/blog/). Thoughts on how to become a better leader, and avoid being a bad boss.