Some assumptions:
In the context of the above assumptions, here are some families of interventions I've been entertaining, structured around the goals of infrastructure. While colored by the needs of technical contributors, many of these ideas can easily be generalized beyond that.
Smooth, seamless, predictable. That's how the process of starting to contribute should feel, both during initial onboarding, as well as when starting out a new work day, a new project, etc. The goal here is to squash any hints of aversion caused by initial setups.
Particular local configurations and versions of things should be codified in configuration files which are version controlled together with other version controlled artifacts associated with a given project. This might occasionally build on tools like devbox. This specifically avoids the need to fiddle with repeatedly configuring an environment instead of actually using it to contribute.
The minimal body of knowledge required to get to a point of being able to directly contribute, as well as being able to ramp up one's understanding of the context in a self-guided way, should be codified in quickstart-style docs. A relevant litmus test: If I were to re-engage with this project after a year-long sabbatical, would I be able to find my way back to being able to contribute or bootstrap my way to contributing?
Contributors should have the right permissions configured such that they can actually carry out their work. These should be configured upfront using standardized permission groups across platforms, rather than only applied reactively when people are running into misconfigured locked gates.
As a safeguard against constant “overclocking,” we should collectively weigh in on the amount of time a particular issue would require, and this before it gets an owner. By taking the average of a few simultaneous estimates and settling on personal workloads which do not exceed a contributor’s bandwidth until the next check-in, we can avoid overreaching, as well as celebrate the people who’ve been killing it.
Completely avoiding situations where people get blocked is at best extremely inefficient, and at worst unrealistic. Much more tractable is to oil the unblocking process indulgently. The goal here is to help people get back on track instead of getting bogged down in work which is not translating to impact, and so is less meaningful.
When trying to figure out what went wrong when encountering an issue, it's useful to have all the information aggregated in one place, like a #dev-alice Slack channel scoped for updates, logs, and alerts specific to your personal environment (see below). The aggregated view should provide meaningful excerpts (e.g., the last few lines of an error trace), rather than complete raw log dumps, but should nevertheless provide links to dive deeper (e.g., link to full logs of a VM on GCP). Autogenerated hot takes on errors could also provide nice cues. Besides facilitating the process of getting a "read" of a deployment, links and commands for jumping straight in and poking further should also be present (e.g., commands for SSH-ing into exactly the right container).
Complementing quickstart documentation, we need lower-level documentation to help people navigate and iterate on more specific parts of deployments. To limit overhead, we should set up readthedocs-style autogenerated documentation for every non-trivial codebase. Simple docstrings on functions, classes, and modules (in line with existing linter thresholds, actually) help pinpoint issues and understand interactions faster.
This is a bit of a departure from getting unblocked, and focuses on avoiding getting blocked in the first place. Specifically, by meetings and other sync activities. We should strive towards clustering syncs in batches at predictable times of the week and day, ideally as close to the start of the first workday in a week as possible, to help provide closure before the weekend and start fresh.
Asking questions may feel intimidating at times, you feel you run the risk of sounding stupid. But asking genuine questions is an unblocking superpower. This is an evolution of the #no-stupid-questions space. Trying to make it clear that there is no such thing as a stupid question and it's likely spotty documentation that's to blame can only get you so far in terms of lowering the psychological bar for asking questions. On an anonymized #ask, you can send messages routed through a bot which will simply post questions on your behalf — ergonomics for that ancient cognitive relic which tends to magnify social costs. Future agents might use the same pipeline to get steer from people with stronger context.
This one I stole from a MATS session on research management, though I'm misremembering the original name. The key idea here is, as a contributor, to have completely different people responsible for providing you support to carry out your work and for providing you feedback on your past work. The rationale behind this is to avoid the fear of coming across as ignorant when asking the person tasked with performance review questions. There's a dedicated contact, ideally generally familiar with your work at a high-level, to which you can turn when facing all kinds of issues, especially less legible ones.
This is more about the well-scoped than the whitespace. Sometimes we avoid trying promising things out due to the fear of breaking some important part of a production deployment. The instinct is understandable, but the setup that causes it is unfortunate. We try out different things, some work out and some fail. We shouldn't feel like babbling less things and more anxiously, things should instead be set up in such a way as to naturally prune the inevitable mistakes and only let the good stuff through, or at least aspire to that.
Besides the basic prod/dev environment segregation, each developer gets their own dedicated dev-alice style environment. Like the shared dev, personal environments are meant to be almost exact replicas of the true prod environment. However, their point is not to accumulate and validate recent changes from across the team, in contrast to the shared dev, but to provide a safe space for trying things out with complete peace of mind, and without any fear of overstepping. Personal environments are provisioned in much the same way as shared ones, though with only minimal sizes and counts of resources, and configured to shut down after a week of idleness.
You iterated on that new feature in your personal environment, and it works. It even passes local unit tests. The goal is for these contributions to find their way into shared environments. To further make this whole process accessible, end-to-end and chaos testing gates the shared environment instead of you having to break your flow and assume that persona yourself. End-to-end testing focuses on high-level integration of multiple components only, often following what feel like user journeys.
Your changes passed through end-to-end testing and made their way into shared environments. But what if some silent bugs you introduced by babbling out some code are laying dormant and waiting for an opportunity to make production crash! A standard alerting system is the last line of pruning away imperfections which made their way into shared environments. It's inherently more reactive, with louder updates on the Slack channels associated with shared environments, though mirroring the observability of personal environments.
We're a small team practicing talent distillation, and so while we should often be tactical and get into the weeds of things, we should perhaps more often make steps towards the strategic. This might mean anything from refactoring a code block using automated tools driven by contributor intent instead of doing it manually, to providing input on where the whole organization is heading. Plugging into the big picture can be deeply rewarding, while still leaving plenty of room for traditional individual contributor responsibilities.
The core of getting strategic is the practice of abstracting away from more tactical concerns. We can only fit so much in our working memory, and the journey from Assembly to Python completely changed what populates a developer's awareness during work, arguably in an enabling way. While AI tools are the latest addition to the lineage of tools for "automating away the grunt work to free you to focus on what truly mattersTM", there are countless little tools out there for allowing you to go higher-level when appropriate, ranging from CLI utilities to editor UX to concept handles.
The weekly reading group focused on AI safety strategy has multiple goals. Sure, the most obvious one is cultivating that sweet situational awareness of current developments in the field we're operating in. However, perhaps the more important one is using that shared understanding to together think through what this means for where we're heading as an organization. Extending the reading group into a strategy session conveniently guarantees that anyone who interests themselves to a bare minimum of situational awareness is welcome to inform high-level strategy. Join for the readings, stay for calling the shots.
Mirroring the anonymous #ask, the anonymous #say channel is more imperative than interrogative. Got input on organization-wide matters (including policies such as this one)? Bring it up right there safely.