+1

Automation.md

reviewed

··· 9 9 2. Create automation equivalents. Add command-line snippets to replace steps. 10 10 3. Create automation. Create a script that runs everything. 11 11 - Drive standards through automation and building internal tools/scripts rather than through extensive [[documentation]]. 12 12 + - Standards can help to reduce this friction but take time. Before jumping into standards processes, [consider other ways to encourage consistency](https://blog.ldodds.com/2023/09/18/consistency-before-standards/). 12 13 - Makefiles are a great way to document and consolidate different projects of a team. Each project should have a `make` that runs it, and perhaps a `make deploy` to deploy it. Language and tool independent!

+1

Data/Analytics Engineering.md

reviewed

··· 22 22 - Ground truth isn't a single place. Start by joining on common unique keys and counting things, then figure out what's different and why. 23 23 - [[Teamwork|Collaborate with your team]] and break down complex models into reusable pieces. 24 24 - Working with data is like exploring the horizon. It changes as soon as you look it from a higher place (more data). 25 25 + - Find out what decisions your stakeholders need to make, repeatedly, and help with those. 25 26 - Attach a date to your team output resources ([[Dashboards]], analysis, ...) so they exist as artifacts that were true at a certain point on time. 26 27 - Reduce the areas where business logic can be injected, create "time to live" policies on last mile transforms, build a culture of standardizing + celebrating access to cross-functional codebases. 27 28 - People default to writing business logic in the tool they are most comfortable with. The best way for data teams to prevent sprawling business logic is to limit last mile transforms in other tools and invite others into their tools. [The logic will be written, and if the data team gate-keeps, it will be written outside of their visibility](https://ian-macomber.medium.com/data-systems-tend-towards-production-be5a86f65561)! If a data team can educate and encourage contributions to their codebase, they invite code to be written where it most belongs.

+5

Data/Dashboards.md

reviewed

··· 6 6 7 7 - [Before you dive into how to build a dashboard, the first thing you should ask yourself is whether this is the right tool for your situation.](https://shopify.engineering/make-dashboards-using-product-thinking-approach) Understand your problem and your audience; design a dashboard that does one thing really well, for a clear set of users. 8 8 - Answer three specific questions: [How, What, How](https://youtu.be/g2-dkJkZjiI)? 9 9 + - The data will move 1 of three directions; up, down or stay the same. Ahead of time, what will the stakeholder do in each case? Are all three answers the same? 9 10 - Strive to create dashboards that are either standalone or include links to provide the relevant context. Without meaning, data is just digits. 10 11 - [Add all the possible context into the dashboard](https://www.youtube.com/watch?v=Kub2bXrKmOE): 11 12 - Instructions. ··· 25 26 - Add an [explicit expiration date so it doesn't mold](https://mikkeldengsoe.substack.com/p/moldy-data). 26 27 - [Have meetings where you check and discuss the metrics on the dashboard](https://counting.substack.com/p/the-utility-of-an-unwatched-dashboard). This creates a powerful forcing function to look at the thing. 27 28 - Follow up and iterate on your work by marketing, improving and maintaining it into the future. 29 29 + - Provide deep links in the dashboard to the underlying data or specific segmentations/filters. 30 30 + - Design matters a lot — if it looks bad, people won't look at it. 28 31 29 32 The value is that now discussions are happening about the data. 30 33 ··· 63 66 - That the data is correct. 64 67 - That the transformation logic is correct. 65 68 - That the data is complete. 69 69 + - The dashboard is always just a snapshot of "what" is happening, but knowing the underlying base level data is always needed to understand "why" it’s happening. 70 70 + - Usually, answers don't lead to Eureka moments, they lead to follow up questions and follow up questions.

+1 -1

Data/Open Source Data Projects.md

reviewed

··· 52 52 53 53 --- 54 54 55 55 - 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) 55 55 + More at the [`awesome-oss-alternatives` repository](https://github.com/RunaCapital/awesome-oss-alternatives), [twitter](https://twitter.com/johnrushx/status/1706424446205022294), [`tools-for-makers` repository](https://github.com/MarsX-dev/tools-for-makers#open-source-alternatives-to-xxx), and my [Open Source Stack GitHub Curated List](https://github.com/stars/davidgasquez/lists/open-source-stack)

+1

Emergence.md

reviewed

··· 11 11 - [[Evolution]] 12 12 - More than one goal that can be achieved in more than one way. 13 13 - Alphabet: An alphabet is a kit of parts, together with rules for combining them (e.g Lego). The simpler the building blocks, the better. 14 14 + - A holon is something that is simultaneously a whole in and of itself, as well as a part of a larger whole (e.g: humans). 14 15 - An easy initial learning curve but infinite potential (e.g. Minecraft). 15 16 - Involves multiple agents. It has [[network effects]].

+1

Organizations.md

reviewed

··· 62 62 - A company is a superorganism. 63 63 - [Teams usually don't stop to think what (and why) things are working or not working](https://cutlefish.substack.com/p/tbm-952-when-nothingeverything-actually). Make time for that. 64 64 - By [swinging the pendulum](https://twitter.com/BrandonMChu/status/1502312472644100105) and changing focus periodically, you accept more extreme (and clear) outcomes in the short term, but in the long term arrived at the middle ground you aim for. 65 65 + - [Big organizations develop strategic inefficiency to carry on doing what they're doing](https://youtu.be/v1eWIshUzr8?t=1147). 65 66 66 67 ## Resources 67 68

+1

Teamwork.md

reviewed

··· 25 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 - [A team's ability to operate autonomously relies on alignment, which is strengthened by context](https://macroapp.io/blog/the-context-warehouse). 28 28 + - You can also have no durable cross-functional teams. Teams assemble around a project and disperse once the project is done. 28 29 - 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, ... 29 30 - The right way to promote people is to give them [meaningful and clear goals](https://youtu.be/oIMvMb5wVO4) for the organization and promote them if they hit the goals. 30 31 - Lack of ownership is the root of all evil.

+2

Web3.md

reviewed

··· 63 63 - [Probably Nothing Labs](https://www.probablynothinglabs.xyz/) 64 64 - [Space And Time](https://www.spaceandtime.io/) 65 65 - [Credmark](https://credmark.com/) ([GitHub](https://github.com/credmark)) 66 66 + - [3xpl](https://3xpl.com/) 66 67 67 68 #### Tools 68 69 ··· 79 80 - [Cosmos ETL](https://github.com/bizzyvinci/cosmos-etl) 80 81 - [Luabase](https://github.com/luabase) 81 82 - [Digital Assets Examples](https://github.com/aws-samples/digital-assets-examples) 83 83 + - [Subsquid](https://subsquid.io/) 82 84 83 85 ### Bounty Based Collaboration 84 86