Squidtree | All

Build better software by thinking about filing cabinets.

2025-01-25T00:00:00Z

All business software automates some analogous real-world process—even if that process is no longer visible. Software is not a means to its own ends. Good design comes from tying these things together.

Writing software for a business is hard work. Typing code is not the hard part.

The disconnect between these two ideas sits in the realm of The Business. Writing software for the business is much harder than mere coding because it takes time, patience, and communication to understand what the business needs. Often times, the business does not have a concrete understanding of its needs: perhaps the knowledgeable people are no longer around, or the needs are emergent and not yet well-understood, or perhaps those parts of the business have already been automated in software for which the theory is lost.

Software that is written without a critical understanding of the intentions of the business will go its own direction. It might work “correctly” against its own understanding, but customers will report bugs. They’ll express dissatisfaction. Internal stakeholders will pressure teams to change priorities to fix friction caused in business processes.

It’s paramount that we understand that software automates a business process. If we don’t understand how that business process works—how internal stakeholders interact with it, how customers are supposed to engage it, what its role is in relation to revenue—then we are doomed to automate it imperfectly.

There is no technical solution to these problems. They are entirely social.

I have a proposal for you on how to write software more thoughtfully, however, whereby we’ll inadvertently help ourselves with these problems—and a host of other problems!

First, some examples.

Let’s start by testing out that assertion—that software automates the business—to get into the right head space. Here are several software components and what they look like in the real world.

Websites: A website is automated communication and activity. Rather than calling a business for information or going to it to perform an activity, we can do this online.
Webserver routers: The conversation a user has with a router goes something like “I’d like to know about X” (via the URL their browser submits to the router), which is then directed to the subsystem that knows best how to answer that inquiry.
Databases: Businesses have always needed to store data about their customers, products, interactions, and operations. Even today, they fill books and filing cabinets with this information.
Indexes: Databases use indexes to speed up how they locate information. People create these artifacts for navigating the physical world, too. Before computers, libraries used card catalogues to list books and topics so tomes of interest might be located in the index before retrieval. Without this, finding the right book by handling all of the physical books would have taken significantly longer.
Model: In MVC, a model represents a thing or concept in reality. It might be analagous to that literal thing in reality, or it could represent the mental structure of a thing as it would manifest on, say, a paper form.
View: Views are an automation of a physical interaction. A view is how a person interacts with another person, process, or construct.
Controller: MVC controllers translate user activity into business logic activity and data. They automate things in the real world such as jobs, rules, policies, and processes.
Encryption: Secure communication has always been important to people. These days, we have effective algorithms for securing communication—for timeliness’ sake, they’re really only tenable with a computer, but one could imagine communicating using TLS on paper if time weren’t a problem!

The Cabinet Method for designing good software.

The crux of the Cabinet Method is the understanding of how your business would implement a process if computers did not exist (and if many of the constraints that computers solve for, like time, also did not exist). By understanding the fundamental process, we can write much higher-fidelity software which will be easier to maintain as requirements and constraints change.

It’s done in four steps:

Understand the business
Write down a description of the process
Translate into software
Implement

Step 1: Understand the business.

Programming shouldn’t begin until the business’ needs are truly understood. A terrifically incomplete list of things to understand first includes:

Who are the beneficiaries of the software?
What is the customer attempting to do?
How do they view their situation when they come to engage with this feature?
What problems or questions will the support team need to account for once people are interacting with the feature?
Which of our employees are taking which actions to turn the results of this software into revenue?
Who needs what information to do further planning and reporting on the process and results?

Product managers are typically responsible for gathering this information in the form of requirements. They come with their own biases and depth of understanding, though. Their requirements are not the automated result. Everyone involved in the project needs to have a deep understanding of the business process at hand, and has the obligation to push for more information (or to seek it out directly) if the level of understanding is not high enough.

Example: ACMEcorp needs records about its customers so marketing and sales can contact them and so we know how to direct transactional communications as we work together with the customer on their equipment purchases. Basically, we need a registration system.

Step 2: Write down a description of the process.

A comprehensive view of the business process needs to be written down. It needs to include the answers to the above questions, laid out in a natural narrative format that shows where the process is initiated and where its results go.

This is where the real trick is: It should be written in terms of human interactions and physical storage alone.

Pretend computers don’t exist. Invent job titles, roles, departments, names of paper forms as they relate. Think through how all of these things interact with each other sequentially to enact the business process from start to finish.

Example: A new customer arrives at an ACMEcorp outlet. They saw the new advertising we put out and are interested in getting our help on new equipment purchases. A lot of the details about our vendors’ equipment is confidential, and our legal team requires consent from the customer before we can share much with them. The front desk gives them a form which collects their contact information. Along with the form is our Terms of Service, which we ask them to sign before giving them access to our brochures. The customer can fill these out and hand them back to the front desk. The Customer Data Filing Manager takes these forms and files them into the Customers filing cabinet and the Agreements cabinet. They put a record identifier on the registration document, and note that identifier on the ToS document before filing both. As they do this, they also update the New Customers index document: the sales and marketing teams like to cohort their efforts by week, so next week they’re going to look at this registry to locate records for new customers so they can perform some welcome outreach. With registration out of the way, the customer is now free to peruse the equipment brochures and view confidential pricing information.

Step 3: Translate into software.

What’s the bare minimum software required to fulfill this story? What are the names of the existing systems involved in this process and how do they relate to the new requirements?

While going through this exercise, new constraints and processes will become evident. It can be interesting to continue updating the story with more people-and-paper-office analogies as these things are identified. Perhaps you use a central eventing design at your company, and you want to make a note about how the internal mailing department will need to deliver notes about new registrations to other interested departments.

This may also reveal inefficiencies and complexity in the current implementation. Is that abstraction really serving this story well enough that it’s worth bringing into the new design?

The most interesting part of this translation is often in how the database schema gets designed. Is that document always interesting to pull all at once, or is it more often interesting to look at one smaller section of the initial document? This can tell you whether you want wider database rows or more tables.

Do many departments want to request those documents? To fulfill which of their own specific business processes? Is it better for them to ask for the current document in its home department, or does it make more sense to deliver them their own copies and any subsequent updates so they can optimize their internal processes a bit better? Now we’re thinking about what we want our API interface to be, the possible role of evented systems, and the role of caching to some extent.

Step 4: Implement.

Go build the thing.

The business is the best thing to couple software to.

Software that is defined in terms of the business will be the most flexible for evolution.

The main way this is true is in reducing coupling between systems. If systems A & B both talk about the lead generation process in terms of how the sales team receives leads and how we make decisions about who to send over as a lead, then we have a system with an explicit decoupling point. Behind the interface which speaks about the named business process exists a translation into how that data is collected from the database and other systems. As the business evolves, that interface can receive updates to keep it aligned with reality. Things can be rethought without every underlying component needing to immediately start complying in the same way: I can rename something in my API contract but leave the old name in my database.

This can all be done very simply. We don’t need to bear the full cost of DDD’s approach to separate our interfaces from our implementations.

As the underlying implementations evolve, we can rewire them into the same interfaces if that part of the business process has not changed. If part of our lead generation logic requires me to check banking transaction data to ensure that a customer has spent more than $500 in the past month, then we have a business process of computing that data point from the transaction data and conveying it to interested parties. So long as we have an interface tailored for the business’ “lead generation cashflow data check” process, it does not matter if we’re working with Plaid or MX to gather that data. The cashflow team can change those partnerships and wire their new systems into that same business process—no client systems need to be updated to conform with the change.

Take, on the flipside, a system that dumps all of its database’s record update events onto Kafka for other unknown systems to interpret as they need. I don’t know who is coupling to my schema now. If I need to rename or remove a field in that schema, I either have to risk breaking a downstream client with that change, or I need to do significant work to identify and negotiate a migration with users. I might instead hack something in so that consumers still receive the old schema but I can migrate it without breaking them. Without designing this part carefully, this is probably going to get pretty nasty over time. Designing an event message that reflects what’s occurring in the business, though, instead of what’s defined in my database, means that I can reimplement any part of this system—or replace it altogether—without doing anything more than describing the current business process in the new implementation. Which is something that I’d end up needing to do anyway! It just ends up being easier and simpler this way.

Software can be simpler.

It should come as no surprise that coupling software to a lower volatility thing (your business) than a higher volatility thing (existing technical designs and partnerships) means that less maintenance is needed. Having all parts of the stack focusing on a clear-ish common thing (again, the business) instead of the fleeting specifics of implementation naturally means there is less coupling between things that are naturally prone to change.

This method is provided as an example of how to think through software design. There’s no reason to implement it as literally as I’ve written it. By following this avenue of thinking, your software will be more correct and more maintainable, all for the low cost of understanding the true needs of your business.

Modes of capability distribution in a system.

2025-01-11T00:00:00Z

I’ve been thinking a bit about how complexity emerges in a system, and whether the relative size of its subcomponents can influence the amount of complexity possible. Let’s explore it a bit.

Warning: this analysis is more of a stream-of-consciousness exploration to see how a few abstract things relate to each other. It’s not trying to assert anything especially meaningful, nor is it carefully proving or demonstrating any of its points.

Systems are defined by their components engaging in feedback loops to advance the system toward its target state. A change in the state of a subcomponent typically triggers some flow of information to another subcomponent, which may result in some type of action to help the system maintain homeostasis of its overarching state. The primary focus here will be on the ability of components to take those actions.

We want to answer this question:

Does the size of a system’s components influence how large the system is able to grow?

Synthesizing component-oriented system types.

We have a few examples of systems we can use to help us figure out what variables we’re trying to work with:

A mammalian body consists of stable subcomponents called organs. Each organ has a highly specific job, its own unique substructures, and specialized cells suited for the job of the organ.
A company usually comprises a number of well-defined departments and teams. The skills needed to support the activities of these teams usually differs across the functional units.
In an ant colony, there tends to be no specialization between individual drones nor organizing structures determining their work. With few exceptions, each member is able to do any job and moves between jobs as needs emerge through point-to-point communication.
A baseball team has members who take different roles out on the field with no hierarchy and little communication. Each player applies their specialization independently to support the team.

In Robert Keidel’s Seeing Organizational Patterns: A New Theory and Language of Organizational Design, he proposes three archetypes about how individuals interact in an organization. We can use those same archetypes more abstractly to think about how system components relate to one another. They are:

Cooperation: Components are integrated in a way that allows them to operate as equal peers in their decisions and actions.
Control: The system has a subordinate structure that gives members further up in the hierarchy power over the lower members.
Autonomy: Separation is built into the design such that system components do not have to interact.

Comparing these traits to our examples, we can easily conclude that mammals’ bodies and typical companies are patterned off of hierarchy and therefore fit the Control archetype. Ant colonies tend more toward the Cooperation aspect, with each member communicating to assess and act on the needs of the colony. A baseball team demonstrates an organization that focuses primarily on Autonomy.

Let’s accept these three archetypes as our system types. We’ll test out the properties of each of these archetypes to form some theories about how their unique constraints influence their ability to scale.

Autonomy: little growth potential.

First up, let’s look at Autonomy. Following the baseball example, we see that this type of system has trained individuals into different roles which require little-to-no communication between the other players to execute. The system is patterned up front—players are assigned to a particular job and trained on how to do it—and then the system is left to do what it can. If the pattern is not working, this system has to change paradigms temporarily to reform itself. Either one component of the system needs to analyze the system and apply the Control paradigm to redefine the system, or each of the autonomous components need to apply the Cooperation pattern to reassess and reorganize.

What constrains this pattern’s ability to grow into a complex system?

In order to be successful (and apply the paradigm purely), every component of this system needs some way to observe the global state and adapt to it. Since the only specializations in the system occurs at the smallest component’s level, every component either needs to be able to peform every job, or has to have some ability to grow into other specializations, perhaps through training by other specialists. Since the focus of this pattern is autonomy rather than coordination, every component needs to understand the global goals of the system, its current state, and the activities of any nearby (if not all other) components. Without these per-component feedback loops, the system would not be able to adapt and grow.

It ends up being hard to differntiate the overall system and any lower-level components under this definition. Even the baseball team design is not a pure autonomous system—baseball teams bring control and coordination into their designs to make choices. It’s not all left up to a given component to figure it out.

The growth potential of Autonomy-based systems seems to be nearly 0. There may not be any examples where such a system even truly exists: if a component and the system are indifferentiable, there may not be a system at all, just the component’s interior, and the component’s method of operation would likely need to be a different type of system to meet its theoretical requirements.

Cooperation: quickly constrained by wasted potential.

In many ways, a cooperative system resembles an autonomous system in the way we’re exploring them. Each component needs to be able to possess a meaningfully comprehensive number of the system’s internal capabilities for the system to grow and adapt. The biggest difference is that no component needs to understand the global state of the system under this design, components only need to be able to assess local conditions, make decisions about them, and rely that information to other nearby components to solicit their support.

This creates some efficiencies—units near a problem are fully empowered to self-organize quickly around it without the overhead of administrative layers. It also poses a constraint for inefficiency. Without any administrative activities, the possible complexity of local state trades off against quality of information and therefore system performance.

This works okay for ants: if the food stores are running low, any individual can recognize and communicate this to redirect more effort toward food collection. Any ant involved in that activity is capable of noticing when food stores are at an appropriate level to cease that activity. Information decay is pretty minimal, the worst risk is that too many drones accidentally collect too much food, but the maximum possible overrage is that every engaged ant brings back one unit of food beyond the target stock level.

Consider a much more complex state, however: take for example a supermarket. Per-item stock has to be managed much more closely than this. Coordination can no longer be managed as a point-to-point issue—a worker who notices that more bananas are needed cannot communicate that they are working on correcting that stock to every possible other worker who could notice that the stock is running low. Past a relatively small amount of complexity, who is doing what has to be coordinated by a meta-system outside of the individual components, whereby breaking the cooperation-only model since those new components govern the lower-level components.

Another constraint on this system is that every new capability of the system has to enjoy wide adoption amongst the components. It doesn’t have to be that every participant in the system possesses the capability, just that the capability is available where it’s needed to a degree adequate for the needs of the system. This does mean though that every component in the system needs to be able to grow proportionally alongside the system, though. This is quickly wasteful: each component needs to be able to perform tasks that it will increasingly never encounter the need for.

Every new capability additionally consumes more resources. The component needs to be able to learn the capability, or its design needs to be updated to possess the capability innately, and these changes require resources in one form or another to accommodate. Thus, resource availability also constrains the complexity potential of this system.

Control: eventually constrained by inefficient resource usage.

Hierarchical systems seem to be the most able to grow in complexity. These systems change the function of their components until they reach a stable state of performance. Each of these components has a specialized function. The hierarchy arranges these specializations in such a way that it can continue building functions, encapsulating them into stable higher-level subcomponents, and it can grow its complexity from there.

This approach runs into ineffeciencies in its approach to forming stable components. Many components may have needs that are similar between one another, but once stabilized, these systems often do not abstract shared responsibilities into components that are better optimized to provide the function across the whole system.

In fact, once we get to a certain level of complexity, managing the consequences of the complexity begins to take more and more resources that could have been otherwise employed to build refinements. Subtle failure modes in subcomponents negatively interact with each other causing larger and unpredictable failures.

Resource usage also begins to explode with growth. Redundancies form throughout the system. The goals of subcomponents waver, falling in and out of alignment with the overarching system’s goals. Complexity can continue growing in these systems so long as they are able to continue growing their resource consumption to make up for the exponential growth in inefficiency. Attempts by the system to resolve inefficiencies require it to un-encapsulate a stable component to change how it works, introducing new complexities as it integrates better with other components to address the inefficiency, which necessarily changes the component in a way that produces new failure modes and therefore quality issues. As complexity grows, so does the propensity for catastrophic failures.

With enough analytical and executive investment, it might be possible to eliminate both inefficiency and catastrophic failure modes. Assuming those internal constraints can be addressed, the only thing constraining how large and complex a system like this can grow is its environment.

So there we have it. It seems that systems comprised of smaller, more uniform components will grow wasteful much too quickly to achieve any real complexity. Systems with a hierarchy of components ranging up to very large system-level stable components become wasteful at a slower rate, allowing them to grow much larger and more complex.

How I use Zotero to drive my Zettelkasten.

2025-01-04T00:00:00Z

can help with those. In this post, I’ll detail my workflow in managing and making use of my Zotero content.

My Zotero workflow involves four major stages:

Collecting: Day-to-day activity of putting stuff into Zotero.
Managing: Tending to the ergonomics of the library.
Processing: Reading or watching the content, specifically while taking notes on it.
Referencing: Making long-term use of the gathered material.

These stages are mostly self-explanatory, but I’ll go into more detail on each.

Collecting.

This is the data hoarding and procrastination stage. While scrolling through social media, scouring my RSS feeds, or in navigating the natural course of life, I’ll encounter articles or other media and send it to Zotero. I do this either through sending the item to the Zotero app through the iOS share sheet, or by clipping the item in the desktop Firefox Zotero extension. I may or may not have read the piece, but saw enough of it to want to go deeper.

Managing.

This is where the most technical process is… and probably the least value addition. By tagging and cataloguing the new content, I ensure that I have a saved copy of the content, that the items can be identified by which processing stage they are in, and that I have some way of stumbling across the content again in the future when I need to put it to work.

I have several saved searches in Zotero. These are basically top-level folders that dynamically locate items based on various parameters. Most of my saved searches identify items by presence or absence of tags, whether the entry has an archived copy of the media yet, or where in Zotero the item can be found. Each saved search is numbered sequentially to reflect the item’s traversal through the Managing and Processing phases.

Unattached: All items that don’t yet have an attachment (i.e., the items which were sent from iOS). To progress from this stage, I need to reopen the item on a desktop browser, clip it a second time there, wait for the document to snapshot, and then merge the duplicate records in Zotero.
Unfiled: These items have not yet been filed into any of my Zotero categorization folders. I’ll show how I structure these folders in the next section. Items progress into the next stage after getting catalogued into one or more folders.
Unread: Anything that does not have the read tag on it. A little over half of my Zotero catalogue languishes in this state.
Up Next: An infrequently used stage, this one tracks anything with the up next tag on it. I use this when I have a specific research topic and I want to track anything related.
To Cite: This is a new one for me! I’ve noticed that I only add new things to my reading list when I’ve taken notes on it, but I want to start moving things there to more accurately reflect what I’ve been reading, even if I don’t have notes to publish yet. This category finds all items with a read tag but no cited tag.
To Zettel: The main reason I have any of this practice is to integrate content into my Zettelkasten. This tracks anything with the unzetteled tag. I add this tag to read items if I decide the content was worth further breaking down and integrating—but plenty of writing does not meet this standard. I’d guess that about 70% of the stuff that I thought important enough to save or read later ends up labeled for further processing. Less than 10% of my catalogue is waiting to get processed into something more useful.
Zetteling: Some things take a long time to break down into notes, notably books. This stage tracks those longer-running projects. This is flagged with the zetteling tag.
Zetteled: This is the final stage. At present, it’s pretty rare for things to make it all the way here—less than 10% of my Zotero content also has a zetteled tag.

Organization.

from another member of the Zettelkasten community. While this may or may not be a good idea for constructing a Zettelkasten (most say probably not, it violates some of the fundamental principles, but I’ve found it useful), it’s definitely helpful for cataloguing articles and books.

In the screenshot, you can see my first and second levels of organization. In some cases, I’ll go down to third or even fourth levels, but as of right now, I don’t really want the categorization to get too fine-grained. I’m considering starting to use the tagging system to add more specific topical indicators to each item, but haven’t yet. Tagging systems don’t work well with the way I’ve learned to think, and Zotero has a perfectly competent search feature if I need to find anything very specific.

Processing.

My approach to consuming content and making use of it changes pretty often, but the current practice has stayed pretty stable. Zotero lets you add notes as children items to a top-level item (e.g., an article). When I’m reading an item in Zotero, I’ll start a new note and type out anything that stands out. If I find that what I’ve written is worth further investment, I’ll add the unzetteled tag to it. Occasionally, but not as often as I’d like, I’ll start hand-writing and linking together the most useful of those notes, adding them into my paper Zettelkasten. Once that’s completed, I’ll swap the unzetteled tag with a zetteled tag.

I’m actually surprised that I haven’t done this yet, but I need to do a writeup on my whole Zettelkasten practice.

This is a fine summary of it, though.

Outside of the Zotero workflow, on a note card, I keep track of which notes I’m adding and which I’m updating. After I get to a good stopping place, I’ll go through that list and type out the additions and updates into my digital Zettelkasten. This allows me to access my notes from anywhere, and to share them publicly as well.

Referencing.

My Zotero archive serves as long-term storage for items, regardless of stage. So long as I have gotten the item at least through the Unfiled stage, whenever I’m researching something or trying to remember it, I can look through the relevant folders in the hierarchy to see items relevant to my inquiry. This is often a good trigger to actually finish processing an item. The best time to really get into a piece of content is when it has an immediate interest to what you’re focusing on. I do appreciate having notes on content from times when I processed it even without having a specific intended usage for the information, so there’s not really an ideal process when it comes to preparing for later reference.

With one main exception.

The Zettelkasten method is well-suited for gathering and linking information and knowledge. The way it presents this data back to you later is well-adapted to discovering insights and remembering details and connections you’d forgotten you once had, all in the specific context of what you’re now thinking about. As such, having the media filed away for rediscovery in Zotero is good, but having it fully processed into the Zettelkasten is very powerful.

In closing, Zotero is very flexible in how you use it. It allows you to use tagging, folders, saved searches, and its robust search features to achieve many different styles of personal knowledge management. My own approach focuses on getting information well-established for later discovery, but more importantly it streamlines me in feeding knowledge to my Zettelkasten.

If you’re interested in getting into the practice of using Zotero, you could copy my approach and start adapting it, but I’d strongly encourage you to first think deeply about what you’re trying to achieve and then design a very lightweight process around that. You can always add more complexity as you get a better understanding of what you need and what subtle pressures your choices put onto your practice.

You should use Zotero.

2024-12-28T00:00:00Z

My name is Shaine, and I am a data hoarder.

to collect and process books and online media. Zotero is a (completely) free research assistant. Before you dismiss this as an academic practice that probably doesn’t apply to you, let me first make this pitch:

We are all researchers of the world and our interests.

The normal cast of solutions don’t work.

You probably already have a set of tools for managing your intake of information. Unless you’ve invested a great amount of time into it, you probably regard it as mediocre but passable for the amount of effort you’re willing to exert for it. It’s lossy. It’s messy. Sometimes you wish you had a way to remember every book you’ve read, or to find again that article with that great advice so you can share it in its original prose. Maybe you know exactly how to find it again, but due to the natural rot of the internet, your bookmark points to a 404 page.

Oh well, nothing to be done about it now. Right?

The best time to make an improvement is now, though, even if you can’t recover from those failures in the moment. You can at least make sure they don’t occur again.

Zotero is the perfect solution to these classes of problem. It effectively replaces most use cases for many neighboring tools such as:

Browser bookmarks
Keeping every tab you’ve ever opened until the sun dies or the occasional purifying power of a browser crash visits you
Lists on places like YouTube
Various impermanent histories like in the browser or Slack

Zotero specializes in collection and archival.

Far and away, my favorite feature of Zotero is that it creates an archived version of anything you put into it. When you trigger the browser plugin to clip a webpage, it sends the metadata for storage in Zotero and compiles the webpage into a static local version. That copy is more than just the webpage, too—it’s a file you can open and mark up in Zotero.

All of the tagging, organizing, and searching features you could want out of such a tool are fully baked-in.

Zotero also offers a considerable amount of free storage online for backing up and syncing your archive between devices. I used it for the first few years without getting close to the limit. More storage can be purchased pretty inexpensively… but I’ve found this unnecessary. Zotero integrates simply with WebDAV servers, too, so you can switch from their hosting to your own without much difficulty at all.

Zotero offers apps on all major operating systems and mobile devices. Unfortunately, the webpage clipping feature only works when done from a desktop browser, but aside from that, each platform is full-featured. Mobile devices can still send items to Zotero, just without the snapshot file.

With these features, we can get away from the inadequacy of bookmarks and long-running tabs, paid services like Pocket, and we can dodge the slow corrosion of content on the internet.

My progress.

My archive contains over 1,000 items (almost 600 of which are, embarassingly, unread). I started it in 2020. This is a tool I use every single day, and how I manage it has evolved significantly over the years.

In my next post, I’ll go through how I structure and refine what I’ve captured. I strongly believe in the usefulness of aggregating content this way and then putting it to work. I also believe that anyone can use it in its most basic way and still get great value from their collection practice.

Give it a try for a few months, won’t you?

A template for setting yearly personal goals.

2024-12-15T00:00:00Z

Setting goals for the year can be daunting. A methodical approach can take out some of the guesswork—and risk.

It’s that time of year again, when the changing of the seasons and the calendar year invites us to reflect on how things are going and how we want things to go.

I always struggle with this. This seems like a pretty common affliction for those of us who even bother with it—and not bothering with it seems to be even more common. To be honest, more often than not, I find myself in that latter category. It’s hard to get started, and past results encourage me to believe that there’s not really any purpose to it. Which is funny, seeing as how I’m effective at setting and achieving goals in a work setting. I suppose I find that fulfilling a business’ vision is much simpler than identifying and enacting one in my personal life.

But! Methodicalism is a pretty easy way to cut through ambiguity and friction. Let’s put all of the effort I’ve put into my Zettelkasten to work for us by extracting a prescriptive process from my notes about goal setting, motivation, purpose, and whatever else pops up.

Below is a template for exploring your life context, the past year, establishing a positive mindset, setting goals, and incorporating them. Since I’ve been working at all of this for a number of years, I have already sat with a number of these longer-horizon analyses. If you don’t have anything ready to think about or reference, those ideas might become attractive focal points. Don’t get lost in them, though! They can pose a stumbling block for procrastination. If you can’t look ahead 30 years, can you look ahead 5? If you don’t know what you want (a notoriously daunting thing to identify!), can you identify a good-enough proxy for it? Your goals do not require you to know everything about your life and intentions, they only need to align with what you do know. You can put most of your focus onto your retrospective if some of those loftier answers are not easily forthcoming.

All right, let’s jump into the template! This is a written document for a reason—it’s critical that you write this all down so that you can reference it over time.

Establish context.

Before getting into the goal-setting, you need to get into a growth mindset and ground yourself in your life’s context.

Write limiting beliefs.

Anything that creates a scarcity mindset.

Reframe into “liberating truths”.

Restate limiting beliefs as opportunities for growth.

Retrospect the past year.

What were the goals? Outcomes? Failures, successes? Regrets, gratitude?

Synthesize.

Review those notes and extract 2–3 themes. What aspirations & personal potential can you identify?

Review & update other horizon artifacts.

Read through or establish artifacts about fundamental purpose and long-term desires, such as a life compass, life horizons, or any other such artifacts. Further synthesize and update with these. Now’s a good time to conduct a quality-of-life survey.

Create goals.

Brainstorm.

Brainstorm ideas for goals, with an abundance mindset from the above artifacts. Don’t hold back!

Filter.

Reduce the list to 7–12 goals for the year that best address the focus areas that have been identified.

Formalize and plan.

Frame each selected goal in terms of Specific, Measurable, Actionable, Risky, Time-bound, Exciting, Relevant. Plot them over the year, 3–4 per quarter.

Act.

Define triggers.

Figure out the activation triggers that incorporate actions into existing routines. Decide how goals will remain visible.

Get to work.

Stop planning. Get started by identifying next immediate small steps and then do them.

Create review checkpoints.

How are you going to externalize some triggers to help you restore your focus periodically? Calendars work great for this. What cadences will you benefit from?

A year as an engineering director: 2023 in review.

2024-01-01T00:00:00Z

2023 started off with a calm transition from senior engineering manager into engineering director, but once it started rolling, boy did it escalate quickly.

I closed out 2023 by reviewing my notes and schedule throughout the year. I’ve pulled from those a handful of accomplishments and focus areas which illustrate what roles such as mine look like in a macro sense.

As I went through it, I noticed a sort of narrative arc in it. In January 2023, I was made an engineering director, and it’s cool to see my year break into two major chapters. The first deals with moving away from my role as a senior engineering manager while the second attends to the business of inhabiting the role of a director.

Transitioning away from Senior Engineering Manager.

January.

In January, my focus was largely on shoring up my team. With my promotion, I saw a need to move into a new layer of abstraction in the organization, which in turn meant adding structure and culture to the team so I could turn my attention away from it without worry.

I did this in several ways:

I started codifying the team’s culture into documents that articulated how and why I had made the decisions and designs I had. This gave them something to reference and explicitly work into their processes so that as they continued to evolve, they could stay true to what I’d intended (for as long as my past intentions matter against their realities, anyway).
I enacted a plan to improve the quality of the team’s documentation by writing out a prescription of what it needed to look like and then capturing tasks for closing the gaps. Over the upcoming months, we would use the on-call process to review these gaps and strengthen their docs.
One of our most senior team members, Catalina, was the sole expert in one of our most important systems, so we worked on a succession plan to identify and make progress on how to distribute those responsibilities better. (This is going to be very helpful for supporting her actual succession later on in the year.)
There were performance issues on the team at the time, which led us to improving our skills in supporting others while also building a stronger foundation about the concrete requirements of being on the team.

I also sent some holiday gifts to the team. To further reinforce the themes at the time, I sent some Lamy Safari fountain pens to everyone, accompanied with a demand that they dedicate more time to writing.

This seems unimportant in this point of the story, but remember it for later: in February, we held a Data Summit to bring together members and leaders across the org to discuss our data approach and team structures. It founded our new data organization, which we’d been rather quickly building out over the previous few months.

February.

I started February with a pretty intense urge to build something. Realizing some blindspots in my approach, I eventually decided to use Elixir and Phoenix to build an analytics platform off of our data in Gitlab. This automation helped me assist the team with a number of hygienic, performance, and quality issues.

To further improve quality and sustainability on the team, we also launched our on-call process. This started mostly as a path to clean things up, add more monitoring to things, and make sure that other team members had enough of a starting place for understanding the details of the systems they owned.

In light of some issues we were having in achieving our product goals, I started finding oblique ways to interrogate our approach to planning and prioritization. Using Liminal Thinking and Thinking in Systems as guides, we changed parts of our approach fundamentally to take more authority and creativity over how we chose to solve our problems. I used this same approach to help other leaders in our organization to answer some fundamental questions about why teams at large did not seem to be able to achieve what was expected.

This month we also kicked off our new hiring process. I’ve written more about how our hiring panel works here.

March.

In March, I traveled with my merry band of friends to Tahiti and Moorea. It was a beautiful trip. The house we stayed in was right on the beach in Moorea, maybe 40 feet away from calm clear ocean water. In the distance, about half a mile away, we could see and hear the violence of the open ocean crashing against the reef. The whole thing was quite an experience.

Back in the office, we completed our reading of An Elegant Puzzle. This has been the most influential book over my work process to date. Accordingly, this also led to our creation of a fairly comprehensive engineering management training program. We never did launch it, but the outline along is helpful for aligning EMs with the full range of topics which we need them to be experienced in.

Our Salesforce Operations team had been reporting through me for several months at this point. These activities helped me support their EM better by showing us what areas to put more focus onto in order to continue their journey in increasing their effectiveness. We realized we had some specialization gaps on the team and worked with the organization to shift some focus from the QA and product management teams to support this team.

April.

In April, I began reading Jade Rubick’s excellent blog which led me to the concept of EM support teams. To further out interests in providing better support for our EMs, I made an attempt at standing these up at Nav, which has been met with varied results and is worth putting more energy into.

I began my obsession with Yubikeys and personal information security this month. I might have been a bit late on this though, the world seems to be moving away from needing this technology in favor of passkeys. I’m still into it though.

I began preparing my own succession plan this month by training a new EM for the team I had directly reporting to me.

May.

The decision to hand off that team to a new EM was driven by a few factors:

I knew I was under-serving the EM and members of the SF Ops team by having another engineering team absorb so much of my focus
I knew that the organization was changing and I’d have more responsibilities to attend to rather quickly

The latter came true rather quickly. In May, the Data Engineering team started reporting through me after a reorg of our data teams. We needed them to be more attuned to the engineering organization and less siloed within the data teams’ priorities.

June.

Completing an effort I’d started in January, we presented our official version of operating principles for the team which I was handing off. I’ll have to write about this elsewhere, but a strong sense of principles is key to anything that requires a high degree of effectiveness.

After some discussion with my peers in other companies, I realized and resolved a blindspot in how I was supporting the engineers of this team. We didn’t have brag docs! We now have a review at the end of each month for people to take a moment to think through their efforts and capture them. We do this together, which allows them to discuss what went on and to remind each other of the great things they’ve done for one another. Capturing your accomplishments tends to be much more about your approach than the results of the project.

With all that done, and a few months of training under the belt, we finally migrated the team under Nick’s leadership as a brand new engineering manager.

Not a moment too early, either. I’ve had very little exposure to data engineering in my career, so getting to know that team and its pressures demanded a lot of attention. To further compound that fact, we decided as an organization that we needed to replace our existing data stack.

I set to work acquiring contracts for Snowflake, Fivetran, and dbt so we could migrate away from Redshift and home-rolled scripting. This was my first exposure to vendor acquisition.

I’d been tinkering with that analytics platform I’d started building earlier in the year at this point and most of my problems were starting to point to a need to have a platform for managing knowledge about an organization. Associating people with teams, teams with teams, and people with people is actually very complex when you start tracking that stuff over time. Just modeling it is hard. When you need to build and populate the historical data into it, though? Forget about it. I had to start building a whole new suite of tools just to perform and record my archaeological expedition into the history of the org. So that became my new hobby.

Transitioning into Engineering Director.

With three engineering managers reporting to me and no ICs, I found myself in a position to change my attention to Engineering at large. I made a point to set boundaries for how far of a team’s process and work I’d be willing to oversee, and started instead looking at the larger issues between teams, process, and culture within the organization.

July.

As I started working with the data engineering team, we quickly found ourselves in a spot where I needed to start training an interim EM.

We were also in a pinch as an organization, so I helped set up an emergency SWAT team sort of affair as an onsite in our Draper office. We called it “Code Yellow”. It was a pretty fun experience: I’ve rarely seen teams collaborate so dynamically and quickly as I did during that. It’s rather powerful to get a bunch of people with varied skills together to declare a specific goal and complete freedom to self-organize and work toward that goal.

August.

August was mostly business-as-usual… aside from the layoff. I was also thrilled to get to move one of our most experienced ICs, Catalina, back into my direct reports. I’d been feeling a little too helpless about how difficult so many of our cross-team problems were to solve, and realized this reporting pattern would let us affect important change without having to deal with the bureaucracies of organizing multiple teams toward an effort.

September.

In September, we held another Data Summit. New data leader, new data organization. I think we’ve gotten it right this time. I don’t think there’s any particular failure mode at play that has led us to hold three data reorgs in nine months. I think that our organization of ~250 people is at exactly the right size for our data needs to be getting out of hand in comparison to the proportionally small group of data specialists that is reasonable for us to employ. These constraints just combine particularly awkwardly!

Not directly related, another engineering leader left the organization and we had to move several teams under new leadership. In this change, I picked up a team that is responsible for a key part of our data platform, which we call the Business Identities team.

Now with four EMs and a staff engineer reporting to me, I decided it was probably a little past due to begin holding my own staff meetings.

Entirely unrelated to my earlier interests in the year, we also started discussions with a work analytics platform called Jellyfish. They pull data from Gitlab, Jira, Confluence, and Google Calendar to shed light on all sorts of interesting things. I sorta lost interest in building my own platform for this activity since theirs is so good at helping EMs better understand their teams.

Back during Code Yellow, we had a side conversation amongst engineering leaders about the gradual decay of our API abstractions—our systems were leaking way too much of their responsibilities into each other and it was slowing us down. To resolve this, I helped found our “API Working Group”. For us, a working group is a temporary team of volunteers who are tasked with solving a specific problem. We’ve taken our approach for building these from Will Larson’s advice on scaling technical consistency. The API WG’s scope was to identify the responsibilities and boundaries for core systems so we could begin reconciling discordant responsibilities in a central place rather than requiring client systems to make their own choices about integrations and priorities.

October.

In October we started helping my staff engineer fulfill her increased scope of responsibility by cross-training her into the data engineering team.

We were also seeing that our hiring process was stumbling on the abstractions we’d injected into the process with the hiring bar we’d started at the beginning of the year, so I helped build a training discussion for our interviewers so they could experience what our hiring barometers see during the hiring bar discussions. I produced an example set of interviewer feedback submissions using ChatGPT and we used that to conduct a fake panel review on an imaginary candidate. It was a very illuminating discussion!

As I got deeper into the data stack through my efforts with the data engineering and business identities teams, I founded our Data Governance Board to address some of the problems I was uncovering. This is wholly new territory for me but I’m excited to get to support the org in this way. It’s been difficult to make and understand decisions about how to manage data in the past.

November.

As part of the data governance process I’ve been trying to establish, we need a robust approach to describing our data and policies. Prior data leaders had gone through the terrific trouble of getting a Datahub instance running internally, but we hadn’t adopted it widely yet. I wanted to start leaning heavily onto it, but we were considerably constrained in how we could support its underlying technology. It’s quite complex. I started down a path of getting a SaaS version which is operated by Acryl, but the timing ended up being poor and vendor discussions are currently stalled.

We officially stood up, launched, and trained on our Jellyfish instance, though.

My staff engineer and I began working this month on some of the key stuff that we’d intended for when we joined forces. Some parts of the primary platform are just completely broken in ways that no one team can confidently fix and subsequently can’t prioritize. The perfect sort of work for two highly tenured engineers to solve.

December.

Okay, one last data-related reorg and we can be done with that, right? Early in December I consolidated our machine learning engineers into a team that I’m leading directly which I’ve termed Machine Learning Operations. ML Ops is going to focus on making decisions that scale across our product engineers easily to support their integration of machine learning models into production systems. You can learn more about my strategy in this writeup.

In an attempt to solve a number of organizational issues explored above, I introduced two engineering design documents to the leaders across engineering:

APIs must surface domain-level, not implementation-level, concepts and clients must endeavor to couple only to domain concepts
Teams must own complete domain-level problems and concomitant data, not just the solutions that they prefer or have built

Between these two things, we should be able to create salient and robust abstractions across our sociotechnical systems which allow a significant increase in creativity and ownership within teams. It’ll be a tough road to actually execute on any of this stuff, but we must. When we come back to this at the end of 2024, I expect to see that I’ve put a lot more work into establishing these things and moving our attention onto other things more worthy of our time.

A template for founding ops and platform teams.

2023-12-27T00:00:00Z

Clearly stating the purpose and trajectory of a team is an important but oft-undervalued part of creating a new team. While missions and visions may seem like ambiguous artifacts intended only for the peacocking of the management class, well-crafted statements of intention can be very helpful to a team. They tell you and your stakeholders what is in- and out-of-bounds. What to expect from you—and not.

I’ve recently stood up a new Machine Learning Operations team. As part of that, I spent some time reflecting on their purpose and putting it into writing. I found that what I saw as their constraints and driving factors actually applied to almost every operations and platform team. Perfect for a template!

Before we get to that, it’s worth exploring some of the background that went into it.

Developing purpose for service teams.

The most important part of all of this is to clarify what needs to be solved by this team. The necessity of a solution entails the existence of a problem, which will serve as the team’s key focus. Additionally, we want to add some structure to give the team guidance on their approach, so we want to capture some high-level notes on how we’ll solve the problem. This will need to account for what’s realistic for the business to support. Anything can be solved with unlimited time or money, but chances are that this isn’t the length of the leash you’ve been handed.

When you look at this obliquely, you’ll see that we’re exploring different aspects of our constraints.

In my case, and I’d conjecture this follows for most other cases, platform and operations teams must conduct themselves in a way that scales asymmetrically with the rest of the organization. Every decision and project have to have a force-multiplication effect. The changes they are looking for must be high leverage to continue having impact in an organization that is most likely out-pacing their own growth.

With this in mind, the strategic constraint I’m most focused on solving is the difference in growth and scale between our ML Ops team and the rest of the organization. We’ll choose to focus our efforts on what makes product teams most autonomous and least reliant on the immediate efforts of ML Ops engineers. We know it’ll take quite a lot of effort to get into that state, which is another constraint to account for.

Artifacts of purpose.

The constraints analysis described above could be written into an appendix, draft notes, or left entirely in your mind. What we’re meaning to offer the team is the So What? of it, which we’re going to capture as three small documents.

The first, and most important, is the vision. This describes what the world looks like once the team has fully exhausted its purpose. A great vision should rarely change, if ever, and most likely is not actually a goal that can be directly accomplished—it’s there to guide the team’s momentum in a particular direction. It should be short and memorable. Details will go into the other artifacts.

Example: We are ending childhood hunger in the United States.

Next is the mission, which covers how you’re fulfilling the vision at a high level. This is the highest-level way you can find to describe the basics of your approach to solving the problem. It should be brief enough to be impactful, but needs to contain enough detail about how you intend to operate to get a sense of what kinds of actions you’ll take. This statement should be general enough to also resist getting changed.

Example: We work to feed hungry children by organizing donation drives, warehousing donations, and coordinating logistics for distributing goods. We do this through door-to-door solicitation and online advertising to collect digital donations through our websites.

Finally, we have the strategy which provides a coarse overview of the plan as imagined today. A strategy usually isn’t a roadmap. It likely covers the themes or initiatives of the team’s major next steps, though. A good description will list a small handful of items which together provide a sense of motion along the path of the mission toward the outcomes of the vision. These could be concrete goals or classes of effort necessary to make progress.

Example: Our physical operations have been well-established for a decade, but our digital presence is still nascent. To take the next step in our journey, we will first build a partnership with a digital marketing firm. Next, …

The template!

Vision.

Short, memorable statement about the change you want to make in the world.

Team name enables target user group to do some important thing that is hard or missing today.

Mission.

How do you operate to execute on the vision?

We support the some valuable trait of target user group by building and maintaining architecture, patterns, infrastructure, and training materials for target user group members to use. Where a project needs to evolve any of those, we intend to embed into projects to learn and build alongside target user group members. Where a project primarily benefits from existing patterns and technology, we intend to support members of the team directly through education, clarification, and refinements, but otherwise allow the team to execute the project autonomously.

Strategy.

What do the major parts of the long-ish-term plan look like?

We will execute on this through four logical “stage themes”—this is a trajectory more than it is a clean four-chaptered book.

Learn through doing: We will follow a project-embedding model to do the thing alongside target user group members. Our design choices will enable teams to maintain the work themselves as much as possible, but we expect to help with maintenance.
Abstract the architecture: Taking what we have learned through multiple projects, we will refine the common requirements out into an architecture that optimizes for self-service.
Maintain the architecture: Once things get into a largely self-service state, we will continue to support the architecture as its usage grows and our needs evolve. We will take cues from those using it and the system itself to decide where to further invest.
Return to step 1: Where things are now humming along without requiring team name‘s attention on projects, we are now free to embed on projects to further accelerate them. We should not represent blockers for teams whose projects we aren’t actively contributing to, but we are able to add some limited throughput to some projects.

Your needs might be quite different than what I’ve laid out here. That’s okay! The purpose this template serves is mostly in building new operations or platform capabilities in an org. It’s not every day that you build new teams to do that; you’re more likely to already have a maturing capability and team, but you may instead want to improve how they view their purpose.

Take what’s useful in the template and ditch the rest. If you follow a methodical process for breaking down the team’s purpose and practices, you’ll end up with a set of statements that are quite useful for members of the team. They’ll be able to see where you are heading together, but also understand how aspects of the team’s “how” roll up into their “why”. Armed with this intuition, they will be more able to engage their work and to better apply their creativity to the decisions they make all day, every day. It just works so much better when everyone is operating from the same playbook.

Squidtree is now serving RSS!

2023-11-27T00:00:00Z

It’s been a long time coming, but I’ve finally caught up to 2005.

Quick site announcement: Squidtree is now publishing RSS feeds! You can add the following feeds through your favorite RSS reader:

Blog: The Blog Feed serves up my latest blog posts. This is probably the one you want.
Reading List: The Reading List Feed offers a curated list of stuff I’m reading. I really only record the things I want to be able to cite, though.
Zettelkasten Notes: The Zettelkasten Notes Feed gives you visibility into my Zettelkasten’s evolution. This is going to be pretty low signal-to-noise though! A lot of my notes tend to be structural notes at this stage of its life, which will just contain links to other notes.
All: The All Feed indexes all of the above site activity. It’s… probably a bit much, honestly.

Huh?

Don’t know what RSS is? Check out the Reeder app while I consider preparing a more detailed post about it.

Reducing bias with a hiring bar.

2023-11-26T00:00:00Z

Even with training, de-biasing the hiring process is a challenge—we’re still human and humans are governed by subjectivity and subconscious pressures. What if our approach could reduce these factors?

In the past year-or-so, we have overhauled our engineering hiring process at Nav with a suggestion that made many of us fairly uncomfortable:

What if the people running our interviews didn’t weigh in on hiring decisions?

This went against all of my experience in recruitment. I have decades of experience in my field and I know how to run a good interview, so why shouldn’t I be able to surface my recommendations? Should I not trust my peers to be able to do the same?

Having used this process many times now, I can confidently say that we make better decisions when we reduce how much we need to trust individuals to make the right call. In a process where interviewers demonstrate the candidate’s qualifications rather than presenting their conclusions, we not only get better hiring decisions, but we also impose a constraint on our process which requires us to constantly improve its design and our engineers’ recruiting skills.

Performing the interviews.

Our series of interviews seem pretty standard from the candidates’ standpoint: we screen résumés, our recruiters kick off a discussion with an applicant, which is followed by some number of discussions with pairs of interviewers about design, coding style, experience, or whatever traits we’re specifically looking for in the role. Perhaps a little less common, our hiring managers only speak with the candidate toward the end, mostly to sell the team we’d like them to join. Where we’re considering them for multiple teams, we’ll sometimes have each engineering manager hold a short discussion about why they think their team would be a good fit.

As each interviewer goes through their sessions, we ask them to record facts and observations in Greenhouse, the recruiting platform we use. The best writeups will annotate simple assertions about whether a given entry indicates something positive, overtly positive, negative, or very negative—this will become important later. The template through which we collect these observations is structured by the traits which the interview seeks to demonstrate.

Two potentially surprising details about this process, though, are that we do not prime our interviewers with a level or title for the candidate, and we do not ask them for their conclusions about level or title. We just want the facts and an assessment about whether we should be excited to hire the candidate. The lack of priming about level can take awhile for our panels to get used to, since it can be somewhat difficult to prepare for an interview for a level which you’re uncertain about, but one of my peers describes her approach excellently as, “I’m going to ask you progressively harder questions until either you don’t know the answer, or I’ve gotten out of my depth and now you’re teaching me something.” A great conversation is structured to uncover depth rather than verify a specific level!

Air-gapping the decision.

Why all of this focus on assertions of observation without conclusion, then? Do we not trust our interviewers? We do trust them to know how to learn things about the candidate by wielding their professional experience. We also assume that they would most likely be able to make the right call themselves in most situations. We balance these things, however, with an acknowledgment that trust in fallible individuals creates unscalable single points of failure in a hiring process, and that even the most well-informed individual will have blindspots in their approach to getting to know new people. We can work around these biases by air-gapping the hiring decision: we decide on level and hiring through a panel of engineering leaders who have not met the candidate and therefore have had no ability to form assumptions about them based on their own socialization blindspots.

After the interview series is completed for a candidate, we convene a hiring decision panel which is composed of the recruiter, hiring manager, a facilitator, and two barometers. The facilitator and barometers are drawn from a pool of senior people in the organization who have been trained and calibrated for these tasks, excluding those who may have conducted the interviews. Before we arrive at this meeting, everyone is instructed to review all of the interview notes. The hiring manager forms a hypothesis about what level the candidate should be hired at, prepares a short pitch on why they want this candidate to join the company, and why that level makes sense.

The facilitator is the driver in the panel discussion. They first ask the hiring manager for their pitch as an introduction of the candidate (who is, of course, not present) to the barometers. After the level is proposed, the facilitator takes the barometers through a short series of yes/no questions about whether the notes about the candidate demonstrate that they possess the traits that we need for the proposed role level. To support this, it is critical that each interviewer has provided only assertions about evidence rather than their own assessment—if I say that the candidate demonstrated a senior technical competency in architectural design, the barometers would be forced to say that no, no the notes do not demonstrate anything, as they only have my assessment but no examples to judge. The positive/negative format we encourage for these notes assists the barometers in scanning through the notes to quickly locate specific points to back up their assessments.

The panel discussion ends with some discussion across the group about tradeoffs in the candidate’s strengths and weakenesses, whether the assessments had been made with any critically missing context, and finally a hire/no hire decision at the proposed level. At this point, there are four possible decisions to make: accept the panel’s recommendation, re-run the assessment at a lower level if the panel opted to not hire, conversely we can run it again at a higher level if the candidate seemed to clearly surpass the proposed level, or finally the hiring manager may appeal by requesting a new hiring panel if there were somehow major deficiencies in how the run-through occurred.

The hiring panel procedure has been instrumental for reducing the latent bias in our hiring process, but possibly even more importantly has added a constraint that requires our interviewers to think more critically about their approach to hiring. The detached nature of the process means that no amount of positive feeling about the candidate will get them hired, but instead that interviewers must build their discussion around what they can use to most clearly demonstrate the candidate’s qualifications.

Humanizing ChatGPT is unnecessary.

2023-03-30T00:00:00Z

I want to write about my experiences in using ChatGPT to assist with my role. Unfortunately, we need to clear up some stuff about AI first.

Look. I don’t care if the popular AIs coming out these days are classifiable as conscious, and neither should you.

Large language models (LLMs) and other types of generative artificial intelligences (GAIs) are not going to end the world, and humanizing them is not useful or even really interesting.

A lot has been made recently about their human-seeming responses, particularly with Ben Thompson’s experiences with Bing. This sort of treatment strikes me as hyperbolic and irresponsible—even if these examples feel striking.

They are not human and they will never be. They are something else. Can they be considered conscious? Maybe. Consciousness has defied our best attempts at quantification thus far, but we can readily see that there are scales of consciousness somehow because we can see the differences in sophistication between a tree frog’s reactions to stimuli or problem solving versus our own.1 There’s a compelling case that systems can be conscious without being classified as living,2 but this is still abstract, inconclusive, and doesn’t really hit the core of why the average person cares anyway: the empathy we have for a lifeform that’s trapped in a box and subservient to us, and the fear that causes us about potential retribution.

These entities are not alive, even if they are meaningfully conscious, and the constraints of life that created our consciousness are wholly irrelevant to theirs, as they are created and guided by different constraints. They cannot possess fear in the way we experience it because they aren’t alive and aren’t structured in every conceivable way to resist death, as we are. The scariest aspect about modern AI is that they are specifically tasked with learning the language of our interactions with our reality, which necessarily includes language of fear and threat and death. They weight their reactions on how they have modeled our world, not their own world, and there’s a pretty interesting risk in believing the lies that we created them to tell us.

“The very idea of creating machines like us is a project built on misunderstandings of human being and a fraud that played on the trusting instincts of people.”3

If LLMs are conscious, the consciousness lives in the reward of ferrying interesting symbols from some input to some output, not from assigning any internal meaning to that output. The chameleon’s skin does not understand why some predator is looking for the patterns it does for signs of prey, it only understands that reducing difference with surroundings increases its goals of survival and reproduction. It doesn’t have to model the hawk’s brain to do that. LLMs are the chameleon’s skin, not the hawk’s brain. The interesting thing about them is their appearance and how they create it, not whether those mechanisms in fact clone other distant mechanisms they’ll never actually interact with.

I see LLMs for what they are: statistical abstractions on top of language that can automate the production of words. Sometimes these words will be useful and poignant. Those words are averaged across large swaths of literature and will only be as accurate as there is training material available for the context of the prompt—that is, where those words aren’t simply stolen and reworded. They do not think, they do not decide. They are necessarily not able to approximate the complexity of most knowledge workers. Some roles are certainly mundane enough to be replaced by the literature generation these tools represent, but once the hype dies down we’ll come to remember that you cannot send an LLM to a beach on Tahiti for a week to report on how that feels these days. These tools are creative partners, but they cannot make choices or experience our reality, they can only parrot our words about it.

↩
Douglas R. Hofstadter, I Am a Strange Loop (New York, NY: Basic Books, 2007).
↩
Eric Schwitzgebel, “If Materialism Is True, the United States Is Probably Conscious,” Philosophical Studies, no. 172 (2015): 1697–1721. (notes)
↩
Abeba Birhane and Jelle van Dijk, “A Misdirected Application Of AI Ethics,” June 18, 2020, https://www.noemamag.com/a-misdirected-application-of-ai-ethics.

Slack doesn’t have to be a maelstrom.

2023-02-20T00:00:00Z

Slack and its ilk have come to dominate communications in the business world—truer still for companies with a remote workforce. The ease of communication comes with some noisy downsides.

For people starved for time and attention (especially managers!), its features can enable more than mere communication. For me, Slack is a significant driver for accountability, clarity, and asynchronous communication.

Creating accountability.

I’m an “inbox zero” sort of person. I prefer to avoid keeping email around that I can’t quickly do something with—I either delete everything or add it to my to-do list. You might then correctly guess that I compulsively read every new Slack message. Others like me say that this behavior in themselves often causes messages to get lost. I don’t share this problem, however, because one of my favorite coworkers has my back: Slackbot.

You see, when I view an unread message that in any way needs my attention and I don’t have that attention available (which is frequent as an engineering manager on account of meetings), I’ll leave it read, but I’ll right-click on it and tell Slackbot to remind me about the message later. When that reminder triggers, well… I’m likely still deeply involved elsewhere, but Slackbot retains the list of things I need to follow up on. This list of messages then constitutes a sort of to-do list that I can handle as I find time for it. It even has a “Mark as Complete” button for each follow-up, making it more of a proper to-do list than would mere unread messages.

This works great for keeping track of incoming messages, but the real secret here is in keeping track of your own messages. Managers spend a lot of their attention making or relaying requests, and we need a way to enable follow-ups—not everyone is going to have as mature of an approach to managing commitments as we do, so one of the ways we support our organizations is by maintaining accountability. When I send a message that I want to ensure gets answered, especially where I don’t think a conclusion is going to come immediately, like in the case of a request for a change or some other action, I’ll right-click my message and ask Slackbot to remind me about my request on some reasonable timeline. Often, I will have gotten what I need long before the reminder, but this practice is made worthwhile in the cases where I don’t (in which case I may have lost track of my request).

Improving signal.

I’ve found a few structural practices in Slack increase the signal-to-noise ratio, both for incoming and outgoing messages. We can organize information better for ourselves and clarify our communications for others.

Channels can form channel groups, which can direct one’s attention toward things that are of high interest while also grouping channels/DMs that are of lesser relevance. For myself, I maintain groups for my most critical partnerships (including Slackbot), my core team, other teams, working groups, alerts, company-wide communications, and a handful of others.

One of the best noise reduction practices I’ve seen is temporary channels. For conversations that are larger yet finite and include a cross-functional group, a dedicated channel separates focus on the matter from the simmering activity in more permanent channels. Consider an example channel #tmp-2023-02-20-site-outage: temporary, urgent, almost certainly needs the attention of people from across the company, but the discussion is poorly suited for other company channels like #general.

Temporary channels work best when operated like a well-run meeting, with a stated purpose and goal, clear expectations for participants—and a definite end. They can sometimes replace meetings, accomplishing more (or just enough) discussion with notes coming built-in with the approach; the tradeoff it accepts is in enabling asynchronous communication but moving slower to achieve its goals with less ability to make demands on people’s attention. With how my calendar tends to fill, this tradeoff is often (but not always!) beneficial. This approach does not address communication problems within the groups, however—best to avoid this tool where it makes existing communication issues worse.

Shouting into the future.

The last class of Slack features worth discussing here are those that aid future communication.

An underappreciated feature of Slack is the humble draft message. Often in (verbal) conversation, I will find I need to talk to someone else to ask a question, issue a reminder, or share some appreciation. In these moments, it’s convenient to start a message with a few keywords resembling the topic, so I neither lose the subject nor abandon my current conversation. I do this when I want to send the complete message as soon as possible, but this is a poor solution for managing a list of topics for upcoming discussions—those should go into a shared meeting agenda document instead.

I’ll sometimes remember something that needs to be said while I’m thinking outside of team working hours. I don’t want to use drafts in these cases because, like unread messages, drafts constitute a sort of inbox for me, and I’m driven to clear them as quickly as possible. In these cases, I’ll write my message and schedule it for the next workday. I want to support a culture that disconnects and recharges, so sending messages outside of reasonable hours is something I avoid. This helps me protect my own time too!

Coming full circle, our last tool for speaking from the past is a more common one: recurring Slackbot reminders. These are useful for creating a little repeatability in some async processes—reminders to the team to write standup messages, monthly requests to maintain bits of documentation, or the morning message announcing “Sustainability Saturday” (our cheeky team commitment to support some slight improvement to our engineering sustainability each Friday).

Slack has a reasonably simple set of behaviors, but they can be used creatively and interestingly. This list doesn’t even scratch the surface of what can be done with its base features, let alone the ecosystem of plugins and bots available. With just a few minor tweaks to your approach, you, too, can foster clearer signals, improve accountability for yourself and others, and reduce intrusions into your coworkers’ (and your own) personal lives.

The triadic lens: a tool for designing organizations for people.

2022-10-08T00:00:00Z

Working through others is hard; doing it without a map is more challenging. The triadic lens offers a way to focus organizational design on the right social interactions rather than leaving it to chance.

Organizations are designed—but not necessarily by a designer.

“Design is a plan for arranging elements in such a way as best to accomplish a particular purpose.”

—Charles Eames, American designer and architect

The act of design is one of intention. Not every design emerges intentionally, however—self-organizing systems will iterate through designs even without the guidance of a knowledgeable designer.1 The critical difference is whether the components of a system are organizing themselves as guided by well-placed guardrails or something more haphazard.

Will Larson, CTO of Calm, says that leadership is the experience of knowing what ought to be, the awareness to understand what is, and the care to do something about the gap.2 We might then categorize leadership tools in three ways: our tools may help us understand and interpret what reality is, decide what the future should be, or they can help us build the bridge from here to there.

What we create together is a facsimile of the way we communicate.3 For our companies to create what we envision for them, we must build a toolkit that allows us to design better social structures.

Lenses help us see clearly.

Something I’ve found helpful in thinking about the people systems around me is Robert Keidel’s triadic lens of human interaction. He suggests that humans interact in three distinct ways:4

Where one has station over another to direct their actions, it may be described as control. (Think of it more akin to “authority” than a synonym for “micromanagement.”)
People cooperate when they act together without power dynamics compelling them to.
With social behavior underpinning almost all human psychology,5 autonomy registers as a category of cognizant social interaction, despite the absence of other people.

Control, cooperation, and autonomy form a triangle within which we can plot all levels of human activities from a concrete view of how a particular meeting went to the abstract nature of a firm’s operations.

Try it out: On some paper, copy the following diagram. Think of something in your organization that you wish were going better—maybe a recurring meeting proving ineffective or a pattern of communication breakdown between two departments—and title your diagram after it.

I’ve observed that my team has been making decisions that were missing essential requirements, so I’ll name mine “Team project decision making.”

Let’s dig into each aspect a little deeper.

Control is hierarchical.

Where a system leverages more control, it brings to bear more global context. Activities are centrally coordinated. Coach-oriented games, shareholder-focused companies, steeper organizational structures, highly sequential work procedures, and mandated decisions are all control-dominant.

Autonomy is separate.

Flatter reporting structures yield less oversight. Golf doesn’t entail much teamwork. Subject matter experts have grown their skills in an area. Mass information dissemination relies on individuals interpreting the meaning and putting the content to work. In decision-making, autonomy means sourcing input from various contributors that aren’t coordinating with one another. Local context is found mainly at the individual level.

Cooperation is flat.

Basketball is cooperative. Org structures that lean this way tend to be flatter and more ambiguous. Pay structures that favor cooperation tend toward socialism. Collaborative decision-making builds consensus but also takes longer. Less about the global or local contexts, cooperation is how context moves, both vertically and horizontally.

It’s all a fractal.

As you zoom into any area, even a place focused on one of the variables, the same tradeoffs reemerge. Meetings are mainly cooperative (in contrast to other organizational systems such as rewards (autonomy) or decisions (control)). When breaking down the concept of meetings, we again find different focal points: a forum, where individuals represent different viewpoints, is autonomy-focused; decision-making meetings are for a group to exercise its authority, which is a control activity; and team building meetings increase the cooperability of the team.

Try it out: Consider the area you’ve identified needing improvement. Which traits does the situation currently embody the most? Or conversely, which characteristics do you wish it expressed more strongly than it does? Place a dot in the diagram once you decide where it fits best. You Are Here.

I see that my team works together effectively to make decisions, and individuals are highly engaged in the process. Decisions are well-made but miss some details. I’ll place my dot halfway between Control and Cooperation, outside the center of the diagram. There’s a healthy amount of autonomy in their approach, but it’s not the dominant trait.

Leaders design the future.

Keidel’s framework comes with two warnings and one core purpose.

It exists to help you clarify what you want. But you must work to understand the complexity of your system enough to avoid an overly simplified caricature, and you must be decisive about what truly matters in it.

Analysis 1: Each variable counts.

One-variable designs problematically overemphasize a trait. Where we may healthily focus on one variable with the support of the other two, it becomes pathological when the other two are not at all involved.

Conversely, a two-variable design will entirely diminish the potential of the excluded variable. It takes all three to work.

Analysis 2: Design means prioritizing.

But not all three without differentiation! Like in all other prioritization, valuing everything is valuing nothing. Undifferentiated design offers us a confused system where the lack of strategic tradeoffs compounds difficult decisions. This makes it hard to predict which system aspect will ultimately win in a particular situation, preventing smooth operation.

Try it out: Reference the diagram above. Does your dot sit in any of the seven problem zones? If so, does your problem match these downsides, or is the current system making tradeoffs that you haven’t yet considered? Update your starting point if needed.

Analysis 3: Intention is everything.

The problem zones are only one signal. The real utility is in thinking deeply about what tradeoffs you need to be making and where that might end up on the map. This is the hard part, and unfortunately, the framework does not ship with serving suggestions.

The model takes our attention off the most obvious solutions to allow us to think more broadly about what we’re trying to create. Where it might be obvious that I need to add more structure to my team’s decision-making process, it wouldn’t otherwise have been evident that this is only a symptom; that there are more parts of their work needing approval mechanisms, and we have more opportunities to layer in global context to inform their decisions better.

Try it out: Identify where on your diagram you need to move the situation by evaluating which tradeoffs balance it ideally. Perhaps the obvious solution in your improvement opportunity was to add more accountability, but the higher perspective also illustrates that more top-down context sharing is also necessary.

In my team, I want to convey more of the global context to them, and am otherwise happy with how they’re engaging. I’ll set my destination point a bit higher into Control.

With the destination identified, chart a course by thinking through what changes create that trajectory—beyond directly solving the problem at hand. By identifying the more resounding theme of the issue, you can solve it more thoroughly along multiple vectors and resolve other problems you would not have otherwise noticed as being related.

Leaders use many tools to make corrections within their organizations and teams. In my experience, prescriptive practices like scrum, strategic playbook design6, skip-level one-on-ones, and so on fill most of the toolbox. Some of the tools in the box are more abstract (and powerful), suggesting which levers are available to adjust in a system.7 Rarer still are the tools that reveal which changes are necessary—I like the triadic lens because it falls into this category. Tools in this category are harder to use, but because they challenge our more easily-formed beliefs, they can also drive more robust decisions.

↩
Donella H. Meadows and Diana Wright, Thinking in Systems: A Primer (White River Junction, Vt: Chelsea Green Pub, 2008). (notes)
↩
Will Larson, “To Lead, You Have to Follow.,” May 25, 2020, https://lethain.com/to-lead-follow/. (notes)
↩
Melvin E. Conway, “How Do Committees Invent?,” Datamation, April 1968.
↩
Robert W Keidel, Seeing Organizational Patterns: A New Theory and Language of Organizational Design (Washington, D.C.: Beard Books, 2005). (notes)
↩
Will Storr, The Status Game: On Social Position and How We Use It, Unabridged (London: William Collins, 2021). (notes)
↩
Patrick Lencioni, The Advantage: Why Organizational Health Trumps Everything Else in Business, 1st ed (San Francisco: Jossey-Bass, 2012). (notes)
↩
Gary Neilson, Jaime Estupiñán, and Bhushan Sethi, “10 Principles of Organization Design,” strategy+business, 2015, https://www.strategy-business.com/article/00318?gko=31dee. (notes)

Operation failed successfully: writing with a Zettelkasten.

2022-07-10T00:00:00Z

The Zettelkasten method is reasonably good at storing and retrieving information, but this is not its core purpose. The real power of a Zettelkasten is in its ability to act as a thinking partner, especially in writing. It’s a complicated relationship, however, and the risks can drive both growth and paralysis.

A Zettelkasten, often translated from German as “slipbox,” is an ever-evolving collection of highly interlinked notes. Practitioners of the method write their notes onto physical notecards or into note management software. As they learn, they capture notes relevant to their interests and link them into indexes and higher-level discussions of the ideas at play, as well as other more distant notes that notionally interact with the new content.

Building a Zettelkasten can be a lot of work; the note collection arises from a rigorous habit of learning, distilling information and observations, and relating this together across time. With enough networked knowledge, the Zettelkasten becomes a rich source of insight by allowing ideas to come together to contrast or build on each other in a way that would have been highly unlikely alone. It also resurfaces previously discovered relationships between ideas for use in writing.

How a Zettelkasten helps an author (and then gets in the way).

There’s an ironic juxtaposition here, however: a Zettelkasten contains an infinity of connections, but when using it for writing projects, its creative nature can be a siren song that pulls a project away from its goals. Holes in connections and knowledge in the notes are attractive distractions that can take an author away from making progress on their writing projects, even while providing the ideas that drive the project forward.

Learning is a function of failing.

To write using a Zettelkasten, one must shift from the motions of a Zettelkasten maintainer into those of a writer working with a co-author. Standing with one foot in an endless creative realm and the other in a project with a specific end goal and timeframe produces tinkering on one side and poor progress on the other. Notes must become read-only during drafting to avoid these downsides.

Roguelike RPGs provide an excellent model to follow, according to a recent article on the matter1. “Roguelike” describes a game style in which a character ventures into ever-changing landscapes to gather the game’s story while making choices about upgrading skill trees, dying, and resurrecting when taking on challenges outside their ability. The player overcomes each challenge, either by advancing far enough in the skill tree or by learning how to make it through a situation alive.

This analogy boils down to two recurring stages that resemble the Zettelkasten drafting dichotomy.

In one stage, we have gathered knowledge from our experiences and need to put it to work. We venture into the world to fight our enemies and produce our draft papers. Where our existing knowledge is not enough, we discover our shortcomings and eventually fail to complete the mission.

In the other stage, we go back to our knowledge, and we incorporate the new experience by adding connections and codifying details of the attempt. The Zettelkasten grows whatever insights occurred during the writing session and likely incurs even more understanding due to the integration process. Holes in the Zettelkasten’s knowledge and sources (and, by extension, our own) are laid bare by incomplete arguments or newly uncovered questions in the draft. The deficiencies may lead back to another round of research for further synthesis.

Focus improves effectiveness.

What does separating drafting away from note integration save? The Zettelkasten still evolves alongside the drafts, and the drafts still get written and rewritten. These are rarely the only concerns in play, though. The main difference is focus—or, more specifically, the elimination of multitasking.

Extensive research has been done into multitasking, conclusively showing that split focus leads to poorer and slower results. In writing, many sorts of tasks occur throughout the project. Each of those tasks deserves full attention. Research, writing, editing, and associating notes require different mental resources, each moving at different paces with unique focal points.2

Not only does multitasking make us slower and less effective, but it also grinds us down. Keeping ideas warm while switching focus requires specific types of energy-inefficient brainpower. Each switch of focus further exacerbates those expensive processes in a way that rapidly depletes the ability to restore focus, make effective decisions, or even control our impulses. Allocating time to different types of writing focus, and scheduling those blocks of time with an awareness of the difficulties of the respective tasks, is necessary for effective writing.4

By separating the writing process into multiple modalities, one produces more timely results across each contextual space without the disruption of context switching and increases the quality of work performed by virtue of mental resources being more available to just the task at hand.

Focus is concurrent, not parallel.

One way to interpret these limitations is through the lens of concurrency. Multitasking assumes to some extent that our attention supports parallelization. In parallelism, multiple tasks can happen simultaneously—as many jobs can occur in parallel as there are executors. Two people can do two things simultaneously; a CPU with 16 cores can do 16 tasks. Since the number of executors involved constrains parallelism, almost every system that manages many units of urgent work also has to figure out how to progress on more tasks than it has executors to support. Concurrency then comes into play, where any given executor has a way of owning multiple activities simultaneously, making some progress on each of them alternatingly. Two people can build seven hamburgers at the same time by rapidly switching between each of them, and CPUs schedule tasks such that they can perform some units of work for many ongoing tasks, so all of them progress together rather than getting blocked by other tasks in the queue. Concurrency must pair with fast-access or short-term memory, which is much more expensive to use than longer-term memory in both computers and biology, to support rapid focus-switching. Executors must maintain context across all tasks to switch between them to progress their processing. If that context gets relegated to longer-term memory, which is invariably significantly slower, the executor becomes ineffective and wastes most of its time waiting for context to come back so it can continue processing.

Focused human attention is a singular executor. We process significant amounts of information in parallel at all times—which does happen in parallel—but lower-level mental processes filter out most of it. What does surface to our consciousness must replace what our brains hold at attention, however temporarily. Because our active attention is so limited—three to four ideas, two points of decision, or only one new idea4—concurrently attending to multiple tasks renders us particularly ineffective. We keep our mental space loaded with each task’s context, which leaves very little room for actually performing the cognitive task.

Zetteling is disruptive.

To illustrate why growing a Zettelkasten and writing a draft need separation: integrating information into my Zettelkasten is a tumultuous affair. In one moment, I’ll have a clear and relatively uninteresting point written on a card. Beside that card usually sits the argument or concept that provoked this point. In many cases, I will end up with another seven cards plucked from my file cabinet while considering where this thought could use more color or influence some other existing notion. In considering how to relate the bunch, I’ll pull a few more threads, each carrying with it another five cards. I’ll have never considered these groups together before, which means I’m no longer working on integrating the original thought but am instead swept away by all of these secondary links. Before I know it, incorporating a passing comment on Mondays and Fridays being bad days to schedule one-on-ones5 has me figuring out how feedback timing relates to ego depletion6. This usually peters out as I grow dissatisfied with my progress in integrating the notes I’d initially set out to merge.

This isn’t to suggest that it wasn’t enjoyable or outright beneficial to have fallen into the side quests: the adventures to-and-fro are part of what makes this system such a joy in which to work. Trying to do even a disciplined subset of note integration while writing a draft has often sent me so far from freeform writing that I never was able to return to it.

My attempts at writing anything long-form from my Zettelkasten have so far failed. Before I started it in January 2021, I bought into the process suggested in Sönke Ahrens’ How to Take Smart Notes which implies that papers are written mainly in the slipbox before being pulled out, organized, and edited3. My interpretation of this process was that draft outlines were to emanate from the slipbox, like Athena bursting from Zeus’ forehead fully formed7. I’d never tasked the Zettelkasten with solving the problems I wanted to write about, however; I only knew it had things to say about the topics. With such an incorrect expectation in mind, the natural reaction was to work on the notes until such a draft could be found. The creative chaos that is my writing in the slipbox never gave me the drafts I wanted but did manage to inspire massive outlines that would grow out of control. These would break into smaller projects that would, in turn, do the same like so many public administrators in Parkinson’s Law8. I was never getting anywhere meaningful and became saturated with drafts that discouraged me from completing any of them.

Integrating drafts into the Zettelkasten.

With the benefits of roguelike modalities in mind, I archived my drafts and began comparing them to my permanent notes. Where the slipbox notes did not demonstrate my argumentation, I added links and abstractions that pulled together the set of ideas. Where ad hoc research had generated new supporting points, I wrote and integrated new notes. As a more concrete example, while reporting on the topic of velocity measurements in scrum, I went down a branch of novel thought that explored how velocity is ineffective to measure if a team cannot focus its efforts on specific goals—existing notes on velocity needed to add this thought and link it to notions of goals and purpose. In a splinter draft, I had taken this idea further, picking apart the aspects of velocity as described by physics. I had recalled that velocity and speed differ in that velocity entails heading straight toward a point B, where speed alone can take you anywhere, irrespective of any intended endpoint. Fascinated by this analogy, I’d worked toward identifying what mass, acceleration, and inertia might look like when described in terms of teams. I migrated these equations into a relatively nascent physics section of notes.

Tying it all together, in theory.

Follows is a proposed workflow for learning processes through to writing completed drafts. As I have little experience in successfully producing a final draft using my note box as a writing partner, some aspects of this are more theoretical than others. I have been following this process recently, however, and anticipate refining it further as I see what’s helpful and what other distractions it hasn’t eliminated.

Scan: Take a cursory look at relevant books and articles. Scan through headings, images, etc.9
Read: Add marginalia of some sort to annotate the literature for future use.10
Copy: Review what was identified as necessary while reading11, rewriting and summarizing the points into personal notes. I do this by hand in notebooks.
Wait: What was interesting while reading is not necessarily relevant. Waiting some days or weeks before revisiting may suppress interest in points that mainly contribute noise.
Review: Decide which points are important enough to continue distilling into permanent notes. I use a pen to highlight the issues that I want to move forward.
Distill: Write notes for the permanent collection. I do this on physical notecards. I’m currently in the habit of picking where the note will fall within the collection before writing it, which is an unnecessary distraction in a digital collection.
Cite: Update the Zettelkasten index with the new topics if they are high enough level to warrant inclusion there, add any new reference material to the bibliography, and add citations to the cards to track the ideas’ provenance.
Integrate: Ponder which other notes and indexes need to be updated to reference the new notes. Link into the notes from those, and link out where the identified relationships are also significant in the other direction.
Explore: When an idea becomes attractive enough to write about more completely, explore the note collection to pull together the points that might be valuable to include in a draft.
Outline: Organize the notes and ideas into an outline. Alongside that, track a list of new questions and research topics for later visitation.
Write: Produce a draft, updating the list of questions/research topics as needed.
Proofread: Review the draft, especially with an eye toward points that need more research.
Edit: Where beneficial, revisit the draft to make any immediate changes.
Regroup: Depending on what has ended up in the questions/research topics list:

The process may need to start again at step 1 to bring in more material.
Where new points and relationships have been added to the draft, going back to step 6 to incorporate these back into the Zettelkasten may be desirable. Doing so will further refine and associate those points to help during the subsequent draft phases.
When the drafts are nearing completion, it won’t be as necessary to jump so far back in the process. Iterate from step 10 onward.

Keep it separated.

A Zettelkasten can be a powerful ally when using it as a writing partner—but it can also be a dangerous distraction. What makes it enjoyable to build readily leads one down a path of procrastination and irrelevance during drafts when not separating writing projects into distinct focus modalities. Those modalities interact iteratively, where the draft learns from the Zettelkasten for a time, and then the Zettelkasten takes its turn learning from the draft.

The modalities of focus benefit writers in contrast to the caustic effects of multitasking. Doing only one small part of learning or writing at a time requires less context switching, allowing deeper focus, and resulting in higher quality and faster production. A hidden benefit of rejecting multitasking comes from energy and motivation. Every change of direction makes focus harder, and all outstanding tasks require exceptional energy to keep on standby. Produce higher quality, faster, and more sustainably by adding boundaries to work.

↩
Allen Wilson, “Playing the Zettelkasten RPG Through Arbitrary Constraints,” Zettelkasten Method (blog), April 2022, https://zettelkasten.de/posts/playing-zettelkasten-rpg-through-arbitrary-constraints/.
↩
Sönke Ahrens, How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking: For Students, Academics and Nonfiction Book Writers (North Charleston, SC: CreateSpace, 2017), 23–26.
↩
Ahrens, Smart Notes, 58–63.
↩
David Rock, Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long, 1st ed (New York: Harper Business, 2009).
↩
Camille Fournier, The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change, ed. Laurel Ruma, First Edition (Beijing: O’Reilly, 2017), 53.
↩
Ahrens, Smart Notes, 72.
↩
“Athena | Goddess, Myths, Symbols, Facts, & Roman Name | Britannica,” accessed July 9, 2022, https://www.britannica.com/topic/Athena-Greek-mythology.
↩
C. Northcote Parkinson, “Parkinson’s ,”Law The Economist, November 19, 1955, https://www.economist.com/news/1955/11/19/parkinsons-law.
↩
“T.H.I.E.V.E.S. - Reading Technique | Kent State University,” accessed June 19, 2022, https://www.kent.edu/writingcommons/thieves-reading-technique.
↩
Anne-Laure Le Cunff, “Interview: Using Books to Navigate Life with Juvoni Beckford,” Ness Labs (blog), November 3, 2020, https://nesslabs.com/juvoni-beckford-interview.
↩
Sascha Fast, “The Barbell Method of Reading,” Zettelkasten Method, 2018, https://www.zettelkasten.de/posts/barbell-method-reading/.{:target=_blank}

Glory to the short and weighty.

2022-03-07T00:00:00Z

Deciding how to spend time is one of the more challenging and worthy things to, well, spend time on. Weighted shortest job first (WSJF)3 is an excellent tool for estimating the best uses of time.

Understanding weights and lengths.

The purpose of WSJF is to rank activities by the order in which they are best accomplished. It does this by producing a “WSJF score,” an abstract figure that represents the value of time when spent on a given project—its “bounce to the ounce.”1 It does by estimating the value of an activity and dividing it by its size or difficulty (more or less— there’s nuance to explore).

wsjf = cost of delay / task size

What if we just didn’t?

The cost of delay looks at what we miss if we don’t attend to a given set of tasks instead of measuring the work’s outright value. This approach helps us eschew a fixation on the sunk costs of existing work and instead allows us to see the economics of our forward-looking choices.

One may view the cost of delay as an estimation of what matters. Figuring out what matters is difficult; work that provides immediate value tends to be prominent, while resilience-enabling work is easy to overlook.

The cost of delay asks us to survey all opportunities and the ways they support the business along several vectors:

cost of delay = value to the user or business + time criticality + risk reduction + opportunity enablement

Value to the user or business.

Aside from (maybe) time criticality, this aspect tends to be the loudest in an organization. This facet measures the presumed value the work will provide to an end user or business stakeholder.

Time criticality.

Work that has a deadline or declining potential is preferable to do sooner in proportion to its urgency. While it depends on the type of work, this facet rarely has much differentiation, but it matters a lot when it does.

Risk reduction.

Risk reduction typically pairs with the opportunity enablement factor to become one single figure, which means something to the effect of “efforts that add more certainty for an improving future.” They are helpful to think about separately, as a project can simultaneously reduce risk and increase opportunity.

While two sides of the same coin, this factor asks us to consider whether we can reduce any categories of business risk.

Opportunity enablement.

The other side of our “improving the future” coin is the unlocking of possibility. Opportunity enablement is where work creating distant possibilities as part of a business’s strategic interests gets prioritized or projects block other more attractive projects.

Estimating difficulty.

The divisor in WSJF represents some abstraction of difficulty or time required to perform the work. Any approach to estimating this figure is valid, so long as it produces a number. Many approaches to estimation exist, but all that matters is that the estimates are in proportion to one another. Where one body of work is double the effort of another, assign it an estimate twice the size.

Putting it into practice.

With the concepts in the system now laid out, let’s move on to implementing it. There are five steps to implementing WSJF:

Brainstorm: Get all of the opportunities written down.
Estimate: Calculate a WSJF score by assigning numbers to the different dimensions.
Refine: Interpret the results, get more information, adjust the estimates.
Execute: Put the results into practice.
Revisit: Always be calibrating.

1. Brainstorm.

Essentialists spend as much time as possible exploring, listening, debating, questioning, and thinking. But their exploration is not an end in itself. The purpose of the exploration is to discern the vital few from the trivial many.

—Greg McKeown, Essentialism2

To prioritize effectively, you need to know what’s even available. Put everything you’ve been hearing and thinking about into a document and spend time considering what’s missing from the list. WSJF will tell you what’s best to spend your time on, but the creativity that goes into producing that options is the limiting factor. If only a few things are truly worth focusing on, spending time seeking to put those items on your list is time well spent.

2. Estimate.

The estimation exercise in WSJF happens one factor at a time and needs to consider all possible projects simultaneously for the given factor. Each element needs at least one project to serve as the basis, and that project is assigned a value of 1. Estimate the remaining items relatively.

For example, if following the prescribed order as laid out here (which you don’t have to do!), we’d look at user/business value first. We’d ask which project is least valuable to a user or business stakeholder at the moment of its completion (don’t get caught up thinking about opportunity enablement while thinking about direct value!). After surveying the list, assign a project an estimate of 1. A subsequent scan might reveal other projects that are also roughly equivalent and also deserving of a 1 designation. Estimate the remainder in proportion to this baseline value—tasks seeming thrice as promising are assigned 3, and so on. Once every project has an estimate for the given factor, move on to the next aspect.

Hakuna matata.

It’s essential not to get hung up on the estimation activity. If some light research has happened ahead of time to get a better sense of circumstances for the estimates, that’s great! It is not required, though. What matters is that the task list is ordered mostly correctly in the end, not that every value is accurate. If you have a pretty good handle on the nature of the projects, the chances are that you’re looking at a difference of 90% accuracy from your best guesses against 95% for better guesses with more information. This 5% gain is not necessarily worth the prework because of the next stage.

3. Refine.

With a completed estimation in place, WSJF scores, and a corresponding best guess at the order in which work should unfold, it’s time to validate the results. The first step is to review the order of the project list and ask: “Does this match the understanding I have about what needs to happen?” If the answer is no, and there will often be a couple of things that raise your eyebrow, then another pass at the underlying estimation is warranted. Make tweaks to reflect your expectations better. If there are significant differences, though, consider whether you’ve severely understated something… or whether you should be revising your expectations.

Once you agree with your ranking, start socializing the results. Stakeholders and team members should discuss the order of projects to go through that same revision process:

Do people agree with the order?
Do they need to hear the narrative to understand the rationale?
Do they have viewpoints that change our understanding of the value of the projects?

Note that it is helpful to discuss the relative factors of the cost of delay between projects. It will frustrate everyone if stakeholders get involved in the underlying numerical estimations of the system. Keep it high level: discuss the relative value between projects they’re concerned about, but refrain from making them understand the scores across all projects.

We’ll expect a movement of some projects in this process, but not too much. If an overhaul is needed, that’s an excellent trigger for digging into what it is about the flow of information that caused the first pass to be so far off base.

4. Execute.

With a prioritized list now settled, you can put it into motion. Translate the list into whatever’s most helpful for working toward the results described by the projects, be that a roadmap or a to-do list.

5. Revisit.

It’s vital to keep prioritized lists updated to learn the best information about the optimal way to spend our time. Be wary of spending too much time on this process, especially brainstorming and estimating. A process that’s too demanding to follow will lead to infrequent catch-up sessions, which reduce the effectiveness of WSJF. A nimble approach to prioritization would see this process often happen, keeping up with new information on a similar timeline as it comes in (maybe not immediately reacting to all further information… but not waiting to review months of new projects all at once, either). It’s no secret that the easier something is to do, the more readily one benefits from it4.

Serving suggestions.

I find WSJF valuable for many areas of my life. The above caters somewhat to the context of a software engineering team, but not by much! With some slight adaptations to what the cost of delay might mean and how to measure the investment needed for an item, I’ve used WSJF to help me in many different subjects:

Manage development team priorities, naturally.
Decide which books to read next.
Pick which prospective hobbies to double down on (and which to set aside permanently).
Start writing more!

↩
It seems Pepsi coined the predecessor to “bang for your buck”.
↩
Greg McKeown, Essentialism: The Disciplined Pursuit of Less, First Edition (New York: Crown Business, 2014), 61. More from this source.
↩
“WSJF,” Scaled Agile Framework (blog), accessed January 7, 2021, https://www.scaledagileframework.com/wsjf/.
↩
B. J. Fogg, Tiny Habits: The Small Changes That Change Everything (Boston: Houghton Mifflin Harcourt, 2019).

Welcome to Squidtree.

2021-07-13T00:00:00Z

I’m thrilled to announce the launch of Squidtree! This project has been a work in progress since 2008, and while it continues to be so today… it’s actually a real website, finally.

About me.

I’m Shaine Hatch. The most important thing for me to share with you about this fact is that I am the curator of this website. There are a number of other interesting things for me to share with you; this is in fact the purpose of the website that I am announcing to you in this very moment. While I will leave most of those secondary interesting points for future writing, I can share today that my focus lies in software engineering, the management thereof, and the hoarding of art supplies.

About Squidtree.

Goals.

I’m looking to do three things here: make my Zettelkasten public (more on this in the future), start blogging again, and finally get around to playing with some design concepts in production.

A sordid and oddly Flash-based background.

I started programming in 2002. This is a website launch announcement and not instead a recipe, so I’ll spare you my entire life’s story, but I’m going somewhere with this.

In 2002, I was in high school, and looking back, I’d like to think that the nature of web development was also a teenager. CSS had not yet completely taken over from table-based design, and I spent a lot of time in those years learning about CSS from the masters while also reading through the arguments for and against delegating styling entirely to CSS.

During those 3 years, I also built 4-or-so Flash-based websites. 2 years after that, I was building renegade counterfeit investigation research tools in Adobe AIR, which basically brought Adobe Flash into the desktop environment, to augment the dysfunctional corporate software we were attempting to use for that purpose. A few years later, in my first official web development job, I spent a lot of time working around browser dereliction in the custom font world with a tool called sIFR or Scalable Inman Flash Replacement, which allowed us to use custom fonts by swapping out text with tiny Flash applets displaying the text in an embedded custom font. The namesake of that tool, Shaun Inman, (very) indirectly sent me down a path that eventually leads to this website.

Site design.

Squidtree features a revolving color scheme that’s anchored to the seasons of the year. This post was made in July and therefore reflects an orange color, existing in a season whose heat will escalate to a bright red. Come fall, purples will be introduced as things cool down on their way to the cold blue of winter. When spring starts to warm things up again, the site’s colors will rotate through green hues, back on their way to the warm colors of summer. Any piece of content published will become pinned to the colors of its publish date, which is why different colors are displayed while navigating the website.

This color concept has been one of the biggest drivers for me to work on this site, and it has followed me around for many, many years. But I cannot take credit for it. The reason for the Flash story? Flash led me to sIFR, which led me to the creative work of Shaun Inman, who shared his inspiration about the nature of the passage of time during a site relaunch. (If the page is unreadable, you may hit this color toggle URL and then reload the page). While Shaun’s colors fade, my interest was the progression of color with time—with the non-readable mode toggled on, you can see the color effect he was going for here. (Keep in mind this page was built many years ago against different constraints, and what we see today does not resemble what we’d experienced in the browsers of the day.)

Building Squidtree.

While this website has been under development since 2008, it has served its purpose over the years. There’s real, live content today because there’s real, live content to be shared. Before now, though, its purpose has specifically been to be in the process of getting developed…

…Many, many times.

This site has been rewritten with various forms and designs to

further develop a custom PHP framework
learn the Yii PHP framework
further develop understanding of Backbone.js
self-train isomorphic React & Node
familiarize myself with Elixir and Phoenix (twice)

Alongside those studies, many finer points were researched, such as CSS frameworks/patterns, testing frameworks, various databases, API design strategies, and a dozen other technologies and practices.

Technical details.

Having finally delivered a non-trivial version of the site, I can say that Elixir and the Phoenix framework have performed a miracle which no other technology combination has managed to do so far. The technology was easy to learn, it was opinionated and clear enough that I didn’t get caught up in the trap of non-development decision making, the language and framework details were engaging enough that I was able to build it as a point of entertainment in my spare time rather than treating it as a learning chore, and so much more.

The site is built mostly in markdown files on a static file server. Elixir manages a webserver to read and serve its contents, but the interesting part of this implementation involves OTP to manage processes with different responsibilities to the site.

As mentioned, the webserver is a given. Webserver requests mostly involve reading a markdown file and processing it in fairly complex ways. A GenServer is running with several ETS tables to pull in these markdown files and retain their processed copies in memory, so new requests can immediately serve the content.

Serving the content is only half of the story. With all of this content and associated metadata in memory, more useful behaviors are in place which index the content and make it available in contexts beyond just reading a document itself—a note about a book can now easily pull in every note that references the book, for example.

In closing.

While not necessarily the most efficient manner of learning, I couldn’t recommend more the practice of always having a background project that just so happens to need the application of the technical skills which you do not presently possess. The combination of understanding the requirements, having interest in moving forward, but not having the necessary skills to quickly or entirely deliver creates a space within which there’s a fast track toward technical growth.

I’m excited to have Squidtree up and running at long last. This milestone marks a time when my focus is no longer on learning technology, but instead is on deeply integrating ideas and sharing the resulting insights.

Time to open is highly correlated to code cycle time.

2025-02-01T17:09:00Z

According to a study of 180,000 merge requests from 500 teams, time to open (first commit to merge request open) has an 87% correlation with code cycle time. This suggests that code ships faster when the decisions are smaller and brought to the team for input sooner. Indirectly, this may suggest that strong pairing practices make code ship faster.rD13

↩
Noah Davis, “What Analyzing 180,000 Pull Requests Taught Us About Shipping Faster,” Code Climate (blog), November 28, 2018, https://codeclimate.com/blog/what-data-science-tells-us-about-shipping-faster/. (See notes.)

Cycle time.

2025-02-01T17:06:00Z

The time it takes to do something start to finish.

In software development, we usually separate the coding portion into code cycle time—time from first commit to deployment—away from the lead time of design and ideation, as these are squishier activities.rD12

This metric puts pressure on merge request and team process sizes to speed up sub-cycles within the work.rD12

Time to open is correlated most strongly with code lead time.

↩
Noah Davis, “What Is Cycle Time and Why Does It Matter?,” Code Climate (blog), December 8, 2020, https://codeclimate.com/blog/software-engineering-cycle-time/. (See notes.)
↩
Noah Davis, “What Is Cycle Time and Why Does It Matter?,” Code Climate (blog), December 8, 2020, https://codeclimate.com/blog/software-engineering-cycle-time/. (See notes.)

Skip levels.

2025-01-19T17:28:00Z

A skip level is a one-on-one between an employee and someone higher in their management chain than their manager.

The goals of a skip level are for the leader to learn about the performance of their management team, to keep a pulse on how changes are landing amongst steams, and to learn of challenges or concerns. Some ways to meet these goals: deep dive into specific areas of concern, test out new ideas in a speculative way, confirm important information is flowing down correctly and that there’s alignment. The discussion needs to be safe for the employee in order to meet its goals. Not every problem is a request for intervention.rR12

Like other one-on-ones, this is a good place to share feedback and observations, especially praise.

↩
Jade Rubick, “Why and How to Do Skip Level 1-1s,” September 30, 2024, https://www.rubick.com/skip-level-1-on-1s/. (See notes.)

Failure modes of scrum (and its derivatives).

2025-01-19T13:02:00Z

Scrum goes poorly when top-down management techniques are applied. The following symptoms can signal that leaders don’t know how to trust a team, which might be repaired by redoubled efforts toward delivering high visibility, high quality increments:rJ2

Standup is extractive rather than collaboration planning for the day
Planning is a series of demands rather than a goal and then self-organization
Sprint review is mostly lamentation of failed expectations, same with retrospectives

Managing stakeholder expectations is a big part of this failure mode.

↩
Ron Jeffries, “Dark Scrum,” September 8, 2016, https://ronjeffries.com/articles/016-09ff/defense/. (See notes.)

Brain matter.

2025-01-18T21:18:00Z

Brain matter consists of grey matter, which is used in the cortex and associated with more active thinking processes, and white matter, which is more for connecting different parts of the brain together.

In one study, it was observed that human males have somewhat more white matter, possibly indicating higher statistics for spatial awareness and motor control. Women were shown to have higher grey matter, suggesting a stronger propensity for memory and emotional awareness. Importantly, statistics may be useful for generic claims, but gender is only one part of the picture, and nurture will have a noteworthy impact on an individual’s capabilities, as well as environment.rG6

↩
Sanjana Gajbhiye, “Male and Female Brains Truly Are Wired Completely Differently,” Earth.com, January 9, 2025, https://www.earth.com/news/male-and-female-brains-are-wired-completely-differently/. (See notes.)

Troubleshooting.

2025-01-18T15:03:00Z

Nine rules of debugging are:rW6

Understand the system: read about it, learn its tools.
Make it fail: identify success and failure cases, look for patterns in intermittent failures, record all of the steps.
Quit thinking and look: only guessing should be about where to add more visibility.
Divide and conquer: cut down the problem space progressively, zooming into the cause.
Change one thing at a time: don’t fix until the cause is clear, try comparing the current state to the last known good state.
Keep and audit trail: write all changes down, assess for cause and effect.
Check the plug: start at the beginning, identify and verify all assumptions.
Get a fresh view: rubber duck, talk to experts, listen to experience, discuss symptoms rather than conclusions.
If you didn’t fix it, it ain’t fixed: verify fixes truly work, know that things can’t just start working, find the root causes.

↩
David Wheeler, “David A. Wheeler’s Review of ‘Debugging’ by David J. Agans,” March 2, 2004, https://dwheeler.com/essays/debugging-agans.html. (See notes.)

Barbell method of reading.

2024-12-27T23:29:00Z

This method optimizes for the time expense to value ratios. In this method, one reads through a body of literature once, marking anything interesting. If the piece proves useful, a second pass is taken, only reading what was marked. Notes and connections are made during the second pass.rF5

↩
Sascha Fast, “The Barbell Method of Reading,” Zettelkasten Method, 2018, https://www.zettelkasten.de/posts/barbell-method-reading/. (See notes.)

Five Whys is a cause analysis technique.

2024-09-29T12:08:00Z

Often used in defect management, the technique guides participants to move from symptoms or problems back into its cause. The question “why?” solicits an analysis of the factor, but by no means suggests that there is only one factor underneath and subsequently only one root cause; the exercise should pursue any interesting leads that arise. The assumption that there’s only one cause is problematic.

Fishbone diagrams show cause and effect.

2024-09-29T12:04:00Z

Also called an Ishikawa diagram. Commonly used as part of defect management to assess for root causes of some deficiency. The diagram appears as a fish skeleton, with the problem to be solved listed at its head at the right and four to eight major categories of potential cause extending to the left. The root causes are listed horiztonally, attached to the relevant category.

Different industries use different high-level categories. Some useful for software engineering might be:

People
Process
Tools/Technology
Requirements
Environment
Management
Quality

Porter’s Five Forces.

2024-09-29T11:56:00Z

Also called the Competitive Forces Model, this assess competitiveness in an industry. The forces are:

Intensity of rivalry
Threat of potential new entrants
Bargaining power of buyers
Bargaining power of suppliers
Threat of substitute goods/services

A sixth force is sometimes added: Power of complementary goods/services providers.

PESTEL analysis.

2024-09-29T11:55:00Z

This is used to assess a business’ outer context. It stands for Political, Economic, Social, Technological, Environmental, & Legal. Historically, only the first four traits were used.

SWOT analysis.

2024-09-29T11:51:00Z

SWOT stands for Strengths, Weakenesses, Opportunities, Threats. It is used as a planning tool to help assess organizations and projects. It is a matrix of helpful/harmful and internal/external.

	Help	Harm
Internal	Strength	Weakeness
External	Opportunity	Threat

Analysis.

2024-09-29T11:47:00Z

Analytical tools & models:

SWOT (planning).
PESTEL (market position).
Porter’s Five Forces (industry competitiveness).
Fishbone (cause/effect).
5 Whys (root cause).
Cost-benefit.
Scientific method.
WSJF (project sequencing).
Template.

The scientific method.

2024-09-28T18:07:00Z

The scientific method is an analytical and decision making framework used especially in the scientific community. Its steps are:

Form a question
Research
Form a hypothesis
Run an experiment
Analyze results
Draw a conclusion

Template for decision making and analysis.

2024-09-28T18:05:00Z

Start by reviewing decision making, problem solving, and goals and objectives.

Problem statement.

What do we need to figure out?

Is analysis needed?

Is there a faster or more direct solution? Are there significant risks at hand?

Observations.

What’s caused us to think we need this analysis?

Context & factors.

What’s the context? What factors and traits are involved?

Anatomy of the system.

What are the components and flows in the system?

Hypothesis.

What might explain the mechanics behind the observation?

Leverage points.

What might change the system of those mechanics? Which leverage points are most impactful?

Enact change.

Execute the change, perhaps as part of a change initiative.

Feedback loops to monitor change.

Ensure there are feedback loops that can create new observations, possibly restarting the process.

Usability heuristics.

2024-09-22T20:07:00Z

According to Nielsen Norman Group:rN5

Visibility of system status: Tell the user about what the system is doing with their actions, especially when something of consequence is happening.
Match between system and the real world: Use terms and representations that match the user’s natural context. Avoid jargon.
User control and freedom: Allow undo, redo, and cancel. Let the user get out of their current actions easily.
Consistency and standards: Maintain consistency, both within the product and with expectations the user learned externally in other products.
Error prevention: Use constraints and good defaults to prevent inattentive errors (“slips”). Reduce user mental load and add warnings to prevent consequential problems. Mistakes are caused by misunderstanding the system.
Recognition rather than recall: Information required to use the system should be available where it’s needed. Make the information architecture visible.
Flexibility and efficiency of use: Allow shortcuts for power users, personalization for tailored experience, and customization of product behavior.
Aesthetic and minimalist design: Focus content and design on the essentials. Remove irrelevant or infrequently useful elements.
Help users recognize, diagnose, and recover from errors: Use recognizable error design elements. Use plain language. Offer the user an action they can take to affect the situation.
Help and documentation: When otherwise unavoidable, show documentation where it’s needed. It should be searchable and give the user concrete steps to follow.

↩
Jakob Nielsen, “10 Usability Heuristics for User Interface Design,” Nielsen Norman Group, 1994, https://www.nngroup.com/articles/ten-usability-heuristics/. (See notes.)

Other things to do to improve executive presence.

2024-09-22T20:01:00Z

Generally:rR11

Improve by recording and watching communication from meetings.
Take note of peers’ strengths and try to copy their skills.
Schedule time to prepare for meetings.
Dress and groom to be in the top 2/3 of peer group in terms of avoiding the appearance of immaturity and shabbiness.rS13

↩
“A Practical Guide to Executive Presence,” May 27, 2023, https://staysaasy.com/leadership/2023/05/27/executive-presence.html. (See notes.)
↩
Jade Rubick, “Executive Presence Coaching – Use These Tips to Become a Better Leader,” February 7, 2022, https://www.rubick.com/executive-presence-coaching/. (See notes.)

Themes in executive presence-focused communication.

2024-09-22T19:58:00Z

There seems to be two primary themes: creating clarity and avoiding defensiveness.

Anxiety can cause a whole slew of defensive behaviors, so as a leader it is critical to engage in ways to alleviate shame and anxiety. Authenticity is therefore a key cause for executive presence.

Creating clarity has another series of associated tactics.

Focuses during communication to improve executive presence.

2024-09-22T19:54:00Z

Things to focus on:[^r11]

Ask questions & then wait—don’t add to them. Count if needed.
Ask for feedback about executive presence.
Improve writing by putting more attention into editing.
Tailor communication style to discussion context: executive discussions are action-focused and brief, other types may allow more exploration.
Avoid responding immediately where deeper thought offline is needed.
Speak definitively (remove “I think”), but enable disagreement by asking for weakenesses in ideas.

Similarly:rS13

Show confidence where experience/data/logic allow; okay to have no opinion.
Don’t destroy confidence by freaking out—freezing, anger, lashing out.
Avoid defensiveness. Consider all angles of your role, even if indirect. Avoid whataboutism. Take control of problems leading to excuses.

Continued.

↩
“A Practical Guide to Executive Presence,” May 27, 2023, https://staysaasy.com/leadership/2023/05/27/executive-presence.html. (See notes.)

Ways of speaking to improve executive presence.

2024-09-22T19:52:00Z

Several particulars to mind:rR11

Use active verbs, avoid passive verbs. Take accountability.
Similarly, avoid adverbs.
Don’t stress about filler words—focusing on connection with audience should naturally reduce them anyway.
Be concise. Relatedly, don’t ramble—increases surface area for saying something dumb, which is likely because rambling may come from a failure to understand the topic well enough to be concise.rS13

↩
“A Practical Guide to Executive Presence,” May 27, 2023, https://staysaasy.com/leadership/2023/05/27/executive-presence.html. (See notes.)
↩
Jade Rubick, “Executive Presence Coaching – Use These Tips to Become a Better Leader,” February 7, 2022, https://www.rubick.com/executive-presence-coaching/. (See notes.)

Executive presence.

2024-09-22T19:50:00Z

Executive presence may be defined as a set of behaviors that influence others to listen.rS13

We may break it into a few high-level categories of action:

↩
“A Practical Guide to Executive Presence,” May 27, 2023, https://staysaasy.com/leadership/2023/05/27/executive-presence.html. (See notes.)

Staff engineer level description.

2024-09-22T18:10:00Z

Level details:rG5

Time scope: 2–3 months.
Complexity scope: Large & complex tasks spanning the system. Turn significant ambiguity & upcoming needs into clear tasks.
Risk management: Manage risk for team projects & objectives, especially by establishing the sequence of deliverables.
Domain expertise: Expert in domain, moving toward architecture and system thinking.
Big picture: Prioritization & solution input to product strategy.
Influence: Team, 5–15 people.
Supervision: Lead team in delivery over 2–3 month timelines.
Communication: Proactively give input to improve others’ work. Share the technical achievements of team to a larger audience.
Team contributions: Technical lead. Mentor others into new responsibilities. Build consensus with team and management about team direction.
Evaluation: Manager & director.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Senior software engineer level description.

2024-09-22T17:29:00Z

Level details:rG5

Time scope: 1 month.
Complexity scope: Disambiguate tasks into actionability. Effectively work across multiple parts of the system.
Risk management: Manage own risks & blockers. Escalate if overwhelmed.
Domain expertise: Advanced understanding of domain. Aware of other domains on the team.
Big picture: Solid understanding of product strategy, solve big problems.
Influence: 2–5 peers.
Supervision: Largely self-directs on assignments.
Communication: Unblock teammates. Go-to for code review. Contributes to team discussions.
Team contributions: Go-to on team. Improves team productivity. Interviews candidates effectively
Evaluation: Manager.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Fellow.

2024-09-22T17:24:00Z

Level details:rG5

Time scope: 3–5 years.
Complexity scope: Ground breaking solutions. Solves high risk problems.
Risk management: Solves existential risks for company & industry.
Domain expertise: Industry leader in multiple domains.
Big picture: Helps build company purpose, aligns product/org strategy with needs on 3–5 year timeline.
Influence: Industry (10,000+).
Supervision: Industry leader.
Communication: Runs industry discussions. Part of senior leadership.
Team contributions: Mentors senior leaders across company & industry. Adjusts company culture to meet future objectives.
Evaluation: SVP.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Distinguished engineer.

2024-09-22T17:21:00Z

Level details:rG5

Time scope: 1–2 years.
Complexity scope: Coordinates solutions across internal & external teams.
Risk management: Assesses risks for the whole industry.
Domain expertise: Industry leader, expert in multiple domains. Familiar with domains across the company.
Big picture: Lead product strategy with organization leaders.
Influence: Company with 1000+.
Supervision: Directs whole organization with management.
Communication: Manages industry discussion. Advises senior leadership.
Team contributions: Mentors senior tech leadership. Strategic recruiting. Responsible for individual contributor culture.
Evaluation: Directors & VP.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Principal engineer.

2024-09-22T17:19:00Z

Level details:rG5

Time scope: 6-12 months.
Complexity scope: Reconcile priority conflicts. Reduce overarching complexity through systems & architectural thinking.
Risk management: Design to reduce risk for whole company.
Domain expertise: Company leader. Easily deepens expertise through others.
Big picture: Inform new product strategy through engineering capabilities.
Influence: 50+ across organization.
Supervision: Drives cross-team initiatives from ideation to delivery without regular oversight.
Communication: Manages company-wide technical discussion.
Team contributions: Mentors mentors. Improves organization process, tooling, & culture.
Evaluation: Director, VP.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Senior staff software engineer.

2024-09-22T17:15:00Z

Level details:rG5

Time scope: 3–6 months.
Complexity scope: Complex work across multiple teams & domains. High impact work. Finds & solves areas for improvement.
Risk management: Manages risk while working with other teams.
Domain expertise: Company leader in domain.
Big picture: Turns strategy to action with company leadership.
Influence: 15–50 among peer teams.
Supervision: Provides direction in large or multiple teams. Requires infrequent oversight.
Communication: Known for written and verbal technical communication. Actively teaches others.
Team contributions: History of mentorship, collaboration, leadership, recruiting. Improves team efficiency & trains others in engineering culture.
Evaluation: Manager & director.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Software engineer 2 (mid-level engineer).

2024-09-22T17:13:00Z

Level details:rG5

Time scope: 1–2 weeks.
Complexity scope: Minor collaborative tasks.
Risk management: Escalate blockers before they occur.
Domain expertise: Understands domain & aware of others on team.
Big picture: Awareness of & contribution to product strategy.
Influence: Self.
Supervision: Weekly or fortnightly attention from manager, senior engineers.
Communication: Share progress with team.
Team contributions: Follows & improves team process. Self-improvement to productivity.
Evaluation: Manager.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Software engineer 1 (junior engineer).

2024-09-22T17:10:00Z

Level details:rG5

Time scope: 1–3 days.
Complexity scope: Minor, self-sufficient tasks.
Risk management: Escalate blockers.
Domain expertise: Learning industry & best practices.
Big picture: Potential to learn it.
Influence: Self.
Supervision: Frequent attention from manager & senior engineers.
Communication: Status updates to manager.
Team contributions: Learns & follows team processes.
Evaluation: Manager.

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Engineering levels.

2024-09-22T17:08:00Z

As defined by Mozilla:rG5

↩
Aria Beingessner (@Gankra), Twitter post, September 30, 2018, <https://twitter.com/Gankra/status/1046438955439271936/photo/1>. (See notes.)

Senior engineers need new skills to advance.

2024-09-22T16:59:00Z

To move into management or staff engineering, senior developers must develop further:rS12

Learn to scale scope: Combination of taking on more scope by prioritizing important things more carefully, but also by training others & working through them—with or without authority.
Managing ambiguity: Get better at picking tradeoffs & making bets by making & falsifying hypotheses, isolating uncertainty into specific problems, decomposing problems into subproblems, eschewing paralysis by making decisions with minimum viable information, & making choices flexibly against what’s volatile.
Influence without authority: Not really just the magic words people need to hear (persuasion), but personal connections, brand, negotiation.

↩
Irina Stanescu, “3 Critical Skills You Need to Grow Beyond Senior Levels in Engineering,” April 8, 2024, https://www.thecaringtechie.com/p/3-critical-skills-you-need-to-grow. (See notes.)

Becoming a staff engineer.

2024-09-22T16:58:00Z

Senior engineers need new skills to advance.

What individauls can do about burnout.

2024-09-22T16:29:00Z

Employees can:rO4

Introspect their true values outside of work & invest more deeply in them. Work is not who we are, we need to invest in our hobbies, health, etc.
Set boundaries to prevent exhaustion. Create non-negotiable personal routines such as exercise.
Get perspective from friends & family about work stresses.

↩
Csaba Okrona, “Demystifying Burnout – A Deep Dive Into Its Symptoms And Remedies,” June 26, 2023, https://leadership.garden/demystifying-burnout/. (See notes.)

What organizations can do about burnout.

2024-09-22T16:27:00Z

Organizations can:rO4

Promote balanced workloads & deadlines, build slack into the process
Realign on values so both individual & org needs are incorporated
Ensure transparency in compensation & promotions
Recognize employees better through programs & public praise
Nurture intrinsic rewards such as learning

↩
Csaba Okrona, “Demystifying Burnout – A Deep Dive Into Its Symptoms And Remedies,” June 26, 2023, https://leadership.garden/demystifying-burnout/. (See notes.)

Burnout is not merely excessive stress.

2024-09-22T16:26:00Z

Stress diminishes with relaxation, but burnout persists through it.rO4

↩
Csaba Okrona, “Demystifying Burnout – A Deep Dive Into Its Symptoms And Remedies,” June 26, 2023, https://leadership.garden/demystifying-burnout/. (See notes.)

How burnout manifests.

2024-09-22T16:24:00Z

Burnout syndrome appears as:rO4

Emotional exhaustion: An overwhelmed sense where no more could imaginably be tolerated. Rest & vacation don’t change anything.
Depersonalization or cynicism: Short fuse with everyone & a persistent assumption of malicious intent.
Sense of personal ineffectiveness: Even when things are going well, there’s a loss of purpose & no sense of accomplishment.

This is not merely stress.

↩
Csaba Okrona, “Demystifying Burnout – A Deep Dive Into Its Symptoms And Remedies,” June 26, 2023, https://leadership.garden/demystifying-burnout/. (See notes.)

Signs of an unhealthy organization.

2024-05-25T16:54:00Z

There are many signs that an organization has been tainted by shame, including:

Perfectionism
Weird power dynamics
Framing worth by productivity
Blame-focused culture

Other “org smells” include:rB7

Conflict-avoidant leadership
Moving poor performers around
Leadership burnout

↩
Suzan Bond, “An Incomplete List of Org Smells,” Substack newsletter, Suzan’s Fieldnotes (blog), April 25, 2022, https://suzansfieldnotes.substack.com/p/an-incomplete-list-of-org-smells. (See notes.)

Signs that an engineering director is struggling.

2024-04-27T17:33:00Z

It’s a common problem that directors do not get the training or support that they need to be effective. It’s also common to trim companies by their middle management layer when it’s time to take a hard look at who contributes what. This can create significant fear in this layer, and insecurity + fear = defensive behavior, particularly by drawing inward into the certain skills that made success in past roles and by spending greater focus on their teams than the organization. They de-risk their failures by ensuring lax timelines and increasing headcount requests. Blame is deflected on these factors, too. Knowledge silos increase and the connectedness of more junior employees decreases. Other parts of the organization start to route around things the director is rendering ineffective.rN4

↩
Johnathan Nightingale and Melissa Nightingale, “Director Means Something,” January 10, 2024, https://www.rawsignal.ca/newsletter-archive/director-means-something. (See notes.)

Webserver sessions.

2024-04-20T00:00:00Z

Sessions are IDs that address a timeboxed set of activity performed by a specific client. They are often associated with session storage which records specific details about client-server interactions. In webservers, sessions are often set as cookies in the client which are carried on each interaction with the server, but any method of trading session tokens can work. Sessions are often additionally defined by level of identity verification of the client, with each level having unique IDs and potentially different timeboxes.

Webservers.

2024-04-20T00:00:00Z

Sessions.

Rules of the UNIX philosophy.

2024-03-24T00:00:00Z

As follows:rR9

Rule of modularity: Simple units connected by good interfaces.
Rule of clarity: Clear over clever.
Rule of composition: Programs are design to interact with each other.
Rule of separation: Separate interface and rules from how it works.
Rule of simplicity: Add complexity only when absolutely required.
Rule of parsimony: Write big software as a matter of last resort.
Rule of transparency: Design to accommodate troubleshooting.
Rule of robustness: Comes from transparency and simplicity.
Rule of representation: Express knowledge as data, keep logic simple.
Rule of least surprise: Design interfaces to minimize surprise.

Continuation

↩
Eric Steven Raymond, “Basics of the Unix Philosophy,” 2003, http://www.catb.org/~esr/writings/taoup/html/ch01s06.html. (See notes.)

Tactics for effective leadership.

2024-03-24T00:00:00Z

Some approaches to combat leadership pitfalls:rR10

Explicitly ask for arguments against your ideas. Creates the space for pushback that one may expect but not naturally receive.
Make bad proposals, or incomplete ideas, to solicit their thoughts. Implicitly delegates solutioning to them and builds trust as they find their ideas affect change.
Build relationships everywhere. Gives access to better context, space to bounce around ideas, and opportunity to act on hidden problems.
Appreciate opposition to help de-risk future contributions from individual contributors.
Servant leadership. Stay hidden during success, act as support.
Roll out plans incrementally with previews and feedback gathering.

↩
Jade Rubick, “Everyone Lies to Leaders,” June 1, 2021, https://www.rubick.com/everyone-lies-to-leaders/. (See notes.)

The UNIX philosophy.

2024-03-24T00:00:00Z

The components of UNIX philosophy originate from a series of maxims by UNIX and C language experts. They focus on software composition, simplicity, and optimization.

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is the universal interface.

—Peter H. Salus

Rob Pike offered a series of rules that advise that we don’t optimize algorithms until we’ve measured a bottleneck and only if it overwhelms the rest of the program at that, because fancy algorithms are buggier and only offer improvements at large scales. Ken Thompson simplifies it to:

When in doubt, use brute force.

—Ken Thompson

From these statements and actions of early design master, a series of rules may be extracted.rR9

↩
Eric Steven Raymond, “Basics of the Unix Philosophy,” 2003, http://www.catb.org/~esr/writings/taoup/html/ch01s06.html. (See notes.)

Rules of the UNIX Philosophy, continued.

2024-03-24T00:00:00Z

Continuing from the first 10:rR9

Rule of silence: Only output if there’s something surprising to note.
Rule of repair: Fail as early as possible, loudly.
Rule of economy: Programmer time is more expensive than compute.
Rule of generation: Write code that writes code where possible.
Rule of optimization: Make it work before improving it.
Rule of diversity: There’s rarely a single right way.
Rule of extensibility: Design for the future.

↩
Eric Steven Raymond, “Basics of the Unix Philosophy,” 2003, http://www.catb.org/~esr/writings/taoup/html/ch01s06.html. (See notes.)

Pitfalls for leaders.

2024-03-24T00:00:00Z

Rules of power:rR10

Leaders lose touch with reality: The further one gets from the ground, the less information about it one has—with proportionally more responsibility to fixing issues.
Everyone lies to leaders: The further away you are, the more likely they are to say what is least likely to get them in trouble.
Leaders are overconfident: Cockiness and aggression escalate when present in a culture, often trickling down. Confidence is valuable but overconfidence is distorting.
Leaders get credit: This can reinforce ego and diminish the contributions of others.

These pitfalls can be countered!

↩
Jade Rubick, “Everyone Lies to Leaders,” June 1, 2021, https://www.rubick.com/everyone-lies-to-leaders/. (See notes.)

Inner-platform effect.

2024-03-24T00:00:00Z

This is an anti-pattern where a system designer overly favors flexibility to the degree that their system starts cloning features of the platform they are building atop. This duplication is done poorly and inefficiently, not to mention the expense of it.

The Unix philosophy helps mitigate this through its focus on composability and simplicity.

Software architecture philosophies.

2024-03-24T00:00:00Z

Domain-Driven Design.

2024-03-17T00:00:00Z

Domain-Driven Design (DDD) focuses design on business-level abstractions. This creates better technical abstractions.

Remote work.

2024-03-17T00:00:00Z

Ongoing research about remote work has shown that the shift toward remote work had no impact on productivity. Conversely, return to office (RTO) mandates have not improved company performance and either do not improve or do harm to productivity. RTO harms employee satisfaction. Studies suggest a correlation between CEO power and belief that RTO is necessary.rZ2

↩
Maxwell Zeff, “There’s More Proof That Return to Office Is Pointless,” January 30, 2024, https://gizmodo.com/more-proof-that-return-to-office-is-pointless-1851209231. (See notes.)

Developer experience.

2024-03-17T00:00:00Z

The returns on DevEx investment.

The appendix.

2024-03-17T00:00:00Z

While commonly regarded as pointless, the appendix actually serves the important role of providing a safe place for “good” bacteria to hang out. This is valuable during gastrointestinal events where bacterial colonies may otherwise be disrupted or destroyed, as the appendix offers a way to rëestablish the colonies after.rS11

↩
Selena Simmons-Duffin, “Your Appendix Is Not, in Fact, Useless. This Anatomy Professor Explains,” NPR, February 2, 2024, sec. Short Wave, https://www.npr.org/sections/health-shots/2024/02/02/1228474984/appendix-function-appendicitis-gut-health. (See notes.)

Distribution of employee impact.

2024-03-17T00:00:00Z

Conventional HR wisdom holds that employee performance follows a bell curve and results of performance reviews should follow this curve fractally—everything is roughly relative to nearby neighbors, there should be no truly outstanding teams or divisions.

The reality is that impact follows a power law distribution: there’s a long tail of average to middling impact, while a small handful—the top ~20%—are markedly more valuable. Research puts top performers at 3–4x more useful than average performers. Steve Jobs saw the difference as those who get company process versus those who understand its true purpose.rH5

↩
Jeff Haden, “27 Years Ago, Steve Jobs Said the Best Employees Focus on Content, Not Process. Research Shows He Was Right,” March 9, 2023, https://www.inc.com/jeff-haden/27-years-ago-steve-jobs-said-best-employees-focus-on-content-not-process-workplace-research-shows-he-was-right.html. (See notes.)

Risk assessments.

2024-03-17T00:00:00Z

A methodical risk assessment practice starts with asset identification, reviews practicality of risks, and makes recommendations as an output. A process for this:

Create a census of data types, interfaces, and flows.
Classify the data risk categories by integrity, availability, and confidentiality as high, medium, and low.
List some threats to the data, classifying each as adversarial, accidental, structural, or environmental. Don’t pursue comprehensiveness.
Identify vulnerabilities that trigger the threat, classifying which data risk category the vulnerability harms. These are the Risks.
List an controls that presently mitigate each risk.
Rate the likelihood of each risk occurring. Rate impact, too.
List the risk rating from a matrix of impact versus likelihood, with low taking precedent, medium next, and only high + high = high.
Finally, list risks + ratings and produce a recommendation for each.

Business-centric interfaces encapsulate abstraction better than data-centric interfaces.

2024-03-17T00:00:00Z

Data-centric interfaces typically revolve around CRUD activities, while business-centric interfaces focus on actions occurring at the level of the business. All software is about the business activities rather than technical concerns, at the end of the day, so it stands to reason that structure based on the business will convey more relevance across systems than CRUD descriptions will. For example, Employee Deleted does not convey as much information as Employee Terminated—while the former could include the additional semantics, the default implementation will omit it if the source system does not value the additional data. There’s a real chance downstream systems do benefit from it though, so everyone agreeing to discuss the business instead of technical implementation will reduce data loss and complexity. If the interfaces expose the source schemas directly, then the clients will couple to it and make changes harder, breaking encapsulation.rC6

↩
Derek Comartin, “Event-Driven Architecture Lost Its Way,” March 7, 2024, https://codeopinion.com/event-driven-architecture-lost-its-way/. (See notes.)

High performers have a fundamental appreciation of the company’s purpose.

2024-03-17T00:00:00Z

Steve Jobs differentiated company process from its “content,” the stuff that the company exists to make. While process is important, there’s not usually a repeatable pattern to innovation. When something works, there’s often an impulse to try to crystalize it into something that can make more success. The trouble is that success comes from a clear understanding of purpose and a relentless pursuit of that alone. To that end, great employees are difficult to manage because they are way more driven to accomplishment than purpose, and this makes them not marginally more valuable than others but multiple times more valuable.rH5

↩
Jeff Haden, “27 Years Ago, Steve Jobs Said the Best Employees Focus on Content, Not Process. Research Shows He Was Right,” March 9, 2023, https://www.inc.com/jeff-haden/27-years-ago-steve-jobs-said-best-employees-focus-on-content-not-process-workplace-research-shows-he-was-right.html. (See notes.)

Digestive system.

2024-03-17T00:00:00Z

Appendix.

Jobs to be done framework.

2024-03-17T00:00:00Z

A product development framework that frames user needs as goals for which they want to “hire” a product or service. Key concepts include:rR8

Market: A group of people largely defined by the job they need done.
Job: Task or goal a person would “hire” a service or product to help them do. A verb-first phrase that describes what they want, including functional, social, or emotional aspects.
Outcome: A goal or “What does success look like?”. Should be phrased in a way that suggests a measurement or other success qualification.

Suggested practice for applying the framework:rR8

Explore markets: Explore and research based on hypotheses about user needs. Distill into a coarse idea about the Jobs in the markets. Narrow to viable or underserved markets.
Discover all jobs and outcomes: Interview three experts in the market to learn all their jobs, together in one session, and their outcomes in a second.
Quanity unmet needs in a survey.
Prioritize unmet needs: opportunity score = Importance % + (Importance % - Satisfaction %)

↩
Sara Landi Tortoli, “Uncover Your Customers’ Hidden Needs In 4 Steps with Jobs-To-Be-Done + Access Custom GPT | HackerNoon,” December 14, 2023, https://hackernoon.com/uncover-your-customers-hidden-needs-in-4-steps-with-the-jobs-to-be-done-framework. (See notes.)
↩
Sara Landi Tortoli, “Uncover Your Customers’ Hidden Needs In 4 Steps with Jobs-To-Be-Done + Access Custom GPT | HackerNoon,” December 14, 2023, https://hackernoon.com/uncover-your-customers-hidden-needs-in-4-steps-with-the-jobs-to-be-done-framework. (See notes.)

Write with the readers’ context in mind to increase effectiveness.

2024-03-17T00:00:00Z

The average reader reads 240 words-per-minute (WPM). Brevity of words and fewer ideas or requests help readers access what’s most important. Make reading easy by shortening sentences and using short/common words. Design for ease of navigation by:

Making ther most important things immediately visible
Separating distinct ideas
Placing ideas in priority order
Grouping related ideas
Using headings
Adding visuals

Formatting should be used just enough. Overuse will dilute the most important points which need formatting to highlight. Finally, readers need to be told why the text matters and why it applies to them (or, who it’s supposed to apply to).rD6

↩
Sam Thomas Davies, “Words Into Works #099 | The Six Principles of Effective Writing,” December 11, 2023, https://www.samuelthomasdavies.com/the-six-principles-of-effective-writing/. (See notes.)

The returns on DevEx investment.

2024-03-17T00:00:00Z

Allocating significant focus time to development increases productivity by 50%. The focus here is on establishing and maintaining flow state. Developers working on engaging projects are 30% more productive. 42% productivity boost when developers believe they have a high degree of understanding of their code and context around it—documentation efforts therefore have a clear ROI. Intuitive processes, including technical processes and issues around blockers/friction, create 50% more innovation. Fast turnaround on feedback loops creates 20% higher innovation. Fast responses to questions during development leads to 50% less technical debt.rK6

↩
Eirini Kalliamvakou, “Yes, Good DevEx Increases Productivity. Here Is the Data.,” January 23, 2024, https://github.blog/2024-01-23-good-devex-increases-productivity/. (See notes.)

Anna Karenina principle.

2024-02-08T16:48:00Z

Pulled from Leo Tolstoy’s Anna Karenina:

All happy families are alike; each unhappy family is unhappy in its own way.

In essence, in certain cases, a state arises from many other states, but the lack of any single one causes the absence of the state of interest. As another example, animal domestication requires many specific traits to line up, and any misaligned trait leads to an animal or species being undomesticatable.

Policy docs.

2024-02-04T16:54:00Z

There are three major levels for policy documents:

Policy: This is the highest level which captures what the org is committing to and why. Vision-adjacent.
Standards: This is capturing the details of the commitment, especially through measurements or goals. Mission-adjacent.
Practices: Specifics of the approach. Implementation prescriptions. Strategy-adjacent.

Order of abjectives in English.

2023-11-19T14:27:00Z

The order in which adjectives usually present in English is:rC3

Opinion
Size
Physical quality
Shape
Age
Color
Origin
Material
Type
Purpose

Following ontological parasitism which more or less suggests that what we consider objects are just collected properties of collections of matter, the order of adjectives leading into a noun suggests we are intuitively aware of the relationship between properties and objects. Nouns are essentially just large groups of properties presumed to be together. The list of adjectives before that group of properties is ordered roughly by specificity, ascending.rV1

↩
Vsauce, “Do Chairs Exist?,” YouTube video, 37:51, 2021-09-14, https://www.youtube.com/watch?v=fXW-QjBsruE. (See notes.)
↩
“Adjectives: Order,” accessed May 6, 2023, https://dictionary.cambridge.org/us/grammar/british-grammar/adjectives-order. (See notes.)

Grammar and parts of speech.

2023-11-19T14:26:00Z

Order of adjectives.

Mereology is the philosophy of parts and wholes.

2023-11-19T14:22:00Z

Part of ontology. Mereology is partly concerned with answering the Special Composition Question, which is: “When do two or more things become something else?” Mereological universalism answers that any combination of things across space or time constitutes a new thing regardless of sensibility. Regards it arbitrary to accept some composites as things while not others—that discernment, on the flipside, is eliminitivism. Mereological nihilism rejects these distinctions and postulates that only simples physically exist in reality.rV1

↩
Vsauce, “Do Chairs Exist?,” YouTube video, 37:51, 2021-09-14, https://www.youtube.com/watch?v=fXW-QjBsruE. (See notes.)

Ontological stances or viewpoints.

2023-11-19T14:18:00Z

These reference basic concepts:rV1

Ontological reductionism: A whole is nothing more than its parts, and ordinary objects exist through composition.
Ontological realism: Things objectively exist and don’t require the interpretation of an observer because the universe has meaningful “joints” by which to separate.
Ontological anti-realism: There are many ways to perceive the universe. Our perceptions are only as we need them to be. No objective “joints”.
Ontological innocense: Things arise from their simples but are not literally those simples. A thing “exists” in its own right, not necessarily as a reference to its literal parts. Things can be defined this way by introducing an application condition to provide enough context to distinguish a thing from the rest of the simples involved.
Ontological parasitism: Wholes must be hosted by something else cannot exist unto themselves. Object fixation/property repression has us focus on the parasite and ignore that only its materials actually exist.

↩
Vsauce, “Do Chairs Exist?,” YouTube video, 37:51, 2021-09-14, https://www.youtube.com/watch?v=fXW-QjBsruE. (See notes.)

Basic concepts of ontology.

2023-11-19T14:15:00Z

Especially in relation to mereology:rV1

Ordinary objects: Average and obvious objects such as chairs.
Composition: All things are composed of simples.
Simples: Some basic component of the universe that is not composed itself. (In a “gunky” universe, though, there are no simples, just infinitely lower orders of composition. Contrast with “junky”, which has infinitely larger structures which everything rolls upward into.)
Existence has senses: The neutral sense refers literally to groups of simples, while the sortal sense refers to higher-level countable objects. Simples need an application condition to have enough information to distinguish things.

↩
Vsauce, “Do Chairs Exist?,” YouTube video, 37:51, 2021-09-14, https://www.youtube.com/watch?v=fXW-QjBsruE. (See notes.)

Ontology: the study of what exists.

2023-11-19T14:14:00Z

Black hole stars could explain otherwise impossibly large black holes.

2023-11-19T14:09:00Z

Black hole stars are a hypothesis which explain why we see black holes from the first billion years with hundreds of millions of solar masses, which should not be possible. The stars we can see max out around 300 solar masses and can create black holes of dozens of solar masses. They can only grow very slowly because matter is super heated on a very long orbit before reaching the event horizon, which in turn puts pressure on other matter to keep it away. Even with merging black holes, there would not have been enough time to grow this large.

Black hole stars resolve this by being so large—forming in dark matter halos from many millions of solar masses of material which outweighs smaller galaxies—that when the pressure causes the core to collapse into a black hole, the resulting supernova is not powerful enough to blow away the outer mantle. The outer gravity overwhelms the black hole’s outward forces, force feeding it and generating tremendous radiation pressure which keeps the star stable until it runs low on matter, at which point it would explode.rK5

↩
Kurzgesagt, Black Hole Star – The Star That Shouldn’t Exist, 2022, https://www.youtube.com/watch?v=aeWyp2vXxqA. (See notes.)

Stars.

2023-11-19T14:09:00Z

Black hole stars.

Resource utilization must be less than full to allow flow.

2023-11-19T14:06:00Z

A simple example of sequential task flow between multiple participants shows:rK4

At full utilization, flow is reduced to a crawl as each step constitutes a bottleneck.
Focusing on one item at a time means the overall system is wasting capability.
Changing to a pull-based, rather than push-based, model allowed the system to maximize throughput and minimize waste.

↩
Henrik Kniberg, “The Resource Utilization Trap,” 2014, https://www.youtube.com/watch?v=CostXs2p6r0&ab_channel=crispagileacademy. (See notes.)

The Lippitt-Knoster model for managing complex change.

2023-11-19T13:38:00Z

This model says you have six elements that are all desired for success, and six pitfalls when an element is missing. This list has each element and its associated pitfall:rO3

Vision: when missing creates confusion.
Consensus: becomes sabotage when missing.
Skills: anxiety without.
Incentives: if unclear, will meet resistance.
Resources: change is frustrated when lacking.
Action plan: false starts until clear.

Where each of these are present, the change should meet success.

↩
Addy Osmani, “Managing Complex Change,” November 7, 2022, https://addyosmani.com/blog/managing-complex-change/. (See notes.)

Leaders lead change initiatives.

2023-11-19T13:37:00Z

For complex change, they may turn to the Lippitt-Knoster model for identifying pitfalls in their approach.

Implementing engineering manager support groups.

2023-11-19T13:29:00Z

One senior leader acts as the organizer who designs the groups of 5–8 and determines who the facilitators will be.rR4 They monitor and report on how the program is doing, in particular by checking in with participants. Organizers help facilitators learn from each other, and modifies the groups as needed.rR5

Facilitators handle scheduling, help people engage discussions, coaches people on trust issues, and guides conversation toward curiosity and reframing rather than festering.rR5 A typical discussion will solicit a challenge from each participant, prioritize them, and proceed to group discussion of each challenge. This requires absolute confidentiality to be established.rR4 A well-run group will behave like a conspiracy to improve the organization.rR6

↩
Jade Rubick, “Variations for Mini-M Management Support Groups,” February 10, 2023, https://www.rubick.com/mini-m-variations/. (See notes.)
↩
Jade Rubick, “Uplevel Your Managers with Mini-M Support Groups,” January 28, 2023, https://www.rubick.com/mini-m-support-groups/. (See notes.)
↩
Jade Rubick, “How to Implement Mini-M Support Groups,” February 2, 2023, https://www.rubick.com/implementing-mini-m-support-groups/. (See notes.)
↩
Jade Rubick, “How to Implement Mini-M Support Groups,” February 2, 2023, https://www.rubick.com/implementing-mini-m-support-groups/. (See notes.)
↩
Jade Rubick, “Uplevel Your Managers with Mini-M Support Groups,” January 28, 2023, https://www.rubick.com/mini-m-support-groups/. (See notes.)

Rationale for forming engineering manager support groups.

2023-11-19T13:26:00Z

There are a number of benefits to creating these groups:rR4

Learn from peers instead of just your manager.
Opportunity to grow by filling in your knowledge gaps through teaching.
Allows growth where you are rather than where a curriculum or mentor decides you should be.
Creates a long-lived support network.
Creates intentional connection and touchpoints which especially helps in a remote world.
Increases retention, lengthens their tenures, and attracts new talent.

↩
Jade Rubick, “Uplevel Your Managers with Mini-M Support Groups,” January 28, 2023, https://www.rubick.com/mini-m-support-groups/. (See notes.)

Generate IDs outside DB for high scale.

2023-11-18T00:00:00Z

At a large scale, DBs can no longer generate their own IDs. Cassandra operates at a scale where it doesn’t even have a default option since each implementation needs to be so particular. Autoincrement IDs don’t work when distributed, and UUIDs are too random to efficiently paginate through IDs when sharding. Twitter assigns an ID from a central service to a new action the moment it enters the ecosystem.rC5

↩
Rob Conery, “A Better ID Generator For PostgreSQL,” Rob Conery, May 29, 2014, http://rob.conery.io/2014/05/29/a-better-id-generator-for-postgresql/. (See notes.)

Database IDs.

2023-11-18T00:00:00Z

Crockford base32.

2023-11-18T00:00:00Z

0-9, A-Z, omitting I, L, O, U for human readability. Includes a check character at the end for automatic error checking.rC4

↩
“How to Generate Human-Friendly Identifiers | Connect2id,” 2016. https://connect2id.com/blog/how-to-generate-human-friendly-identifiers. (See notes.)

UUID.

2023-11-18T00:00:00Z

UUID is not adequate for high-security purposes. Because UUIDs use hexadecimal, they are quite uncompressed, especially when compared to something like base58.

How long to guess a hash?

2023-11-18T00:00:00Z

where A is guesses per second, B is the number of bits of randomness in the hash and S is the number of sessions that are valid to guess.rM8

↩
Neil Madden, “Moving Away from UUIDs,” Neil Madden (blog), August 30, 2018, https://neilmadden.blog/2018/08/30/moving-away-from-uuids/. (See notes.)

UUID is inadequate for high security.

2023-11-18T00:00:00Z

UUID4 has 128 bits, 122 of which are random. Bitcoin’s whole network in 2018 had a hashrate of 2⁶⁴ H/S, which could have guessed a UUID in 35 minutes, according to the OWASP hash guessing timing equation. Contrast with 160 bits of randomness, which would take 18 million years at that hash rate.rM8

↩
Neil Madden, “Moving Away from UUIDs,” Neil Madden (blog), August 30, 2018, https://neilmadden.blog/2018/08/30/moving-away-from-uuids/. (See notes.)

ID representations.

2023-11-18T00:00:00Z

base32.
z-base-32.
Crockford base32.
UUID.
base64.
base58.

Security.

2023-11-18T00:00:00Z

base32.

2023-11-18T00:00:00Z

A-Z 2-7 with = as a padding character. Omitted numbers are to improve human readability by removing numbers that look like letters.rC4

↩
“How to Generate Human-Friendly Identifiers | Connect2id,” 2016. https://connect2id.com/blog/how-to-generate-human-friendly-identifiers. (See notes.)

z-base-32.

2023-11-18T00:00:00Z

a-z 1-9, omitting 0, l, v, and 2. Omissions are for human readability and to eliminate potential mistakes in handwriting.rC4

↩
“How to Generate Human-Friendly Identifiers | Connect2id,” 2016. https://connect2id.com/blog/how-to-generate-human-friendly-identifiers. (See notes.)

Creating engineering manager support groups.

2023-04-30T15:59:00Z

Gustafson’s Law claims that efficiency improvements will be used to do harder jobs.

2023-03-18T18:15:00Z

This is in contrast to doing the old jobs faster.rS10 The implication here is that less interesting problems are selected when constraints are tight, but aren’t necessarily the real focus from a global perspective. Put differently, there is a positive correlation between available resources for a solution space and the afinity with which the resources are addressing the fundamentals of the problem space.

↩
Jason Sachs, “Zebras Hate You For No Reason: Why Amdahl’s Law Is Misleading in a World of Cats (And Maybe in Ours Too) - Jason Sachs,” February 27, 2017, https://www.embeddedrelated.com/showarticle/1033.php. (See notes.)

Amdahl’s Law computes how much an improvement will speed up a system.

2023-03-18T18:10:00Z

It can be written as:

with f meaning the fraction of the work process being improved and N referring to the speed multiplier for that subprocess. In its original context, N meant the number of parallel workers and 1 — f represented the remaining serial work. Thus, this equation describes an improvement made to a part of a system, but not the whole system.rS10

Gustafson’s Law claims this view is myopic, and that improvements to efficiency usually result in more interesting types of work rather than more efficient conduct of the old work.

↩
Jason Sachs, “Zebras Hate You For No Reason: Why Amdahl’s Law Is Misleading in a World of Cats (And Maybe in Ours Too) - Jason Sachs,” February 27, 2017, https://www.embeddedrelated.com/showarticle/1033.php. (See notes.)

Stages of insurgency.

2023-03-17T17:23:00Z

According to CIA field manuals on insurgency, there are three main stages:rO2

Pre-insurgency: Groups form around specific grievances and begin growing their numbers.
Incipient conflict stage: These groups start building militias by acquiring weapons and training. Infiltration of police and military provides further training and intel. The populace and government risk delayed action by not realizing that initial attacks are coordinated by insurgent groups.
Open insurgency: The groups engage open warfare.

↩
KK Ottesen, “‘They Are Preparing for War’: An Expert on Civil Wars Discusses Where Political Extremists Are Taking This Country,” Washington Post, March 8, 2022, https://www.washingtonpost.com/magazine/2022/03/08/they-are-preparing-war-an-expert-civil-wars-discusses-where-political-extremists-are-taking-this-country/. (See notes.)

Precursors to civil war.

2023-03-17T17:20:00Z

According to a study commissioned by the CIA, there are two highly predictive factors that lead to civil war:rO2

Anocracy: A society that is straddling authoritarianism and democracy likely has a government made of weakened institutions and is less able to enforce policy.
Identity-based factions: Rather than societal friction stemming mostly from political affiliations, society is focusing on identity such as religion, race, or ethnicity.

Countries ranking highly in these two factors have ~4% risk of breaking into civil war per year, which has a compounding effect over time.

↩
KK Ottesen, “‘They Are Preparing for War’: An Expert on Civil Wars Discusses Where Political Extremists Are Taking This Country,” Washington Post, March 8, 2022, https://www.washingtonpost.com/magazine/2022/03/08/they-are-preparing-war-an-expert-civil-wars-discusses-where-political-extremists-are-taking-this-country/. (See notes.)

Internal conflict.

2023-03-17T17:19:00Z

Peace and conflict studies.

2023-03-17T00:00:00Z

Internal conflict.

Properties not necessary to consciousness.

2023-03-07T00:00:00Z

A materialist view suggests a few non-requirements:rS9

Contiguousness: Presumably, components can communicate at a distance.
No conscious sub-components: There’s no reason part of the conscious system cannot have its own conscious properties.
Procreation: Nothing about the properties of consciousness require procreation to function.

Contrast with necessary properties.

↩
Eric Schwitzgebel, “If Materialism Is True, the United States Is Probably Conscious,” Philosophical Studies, no. 172 (2015): 1697–1721. (See notes.)

Properties of consciousness.

2023-03-07T00:00:00Z

A materialist view suggests minimal requirements:rS9

Organization of information to coordinate action
Responsiveness toward certain goals
Self-monitoring of some sort to maintain homeostasis
Phenomonology (what it’s likes to be oneself)

Other properties seem necessary, but aren’t.

↩
Eric Schwitzgebel, “If Materialism Is True, the United States Is Probably Conscious,” Philosophical Studies, no. 172 (2015): 1697–1721. (See notes.)

Cunningham’s Law.

2023-03-06T15:14:00Z

The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.

—Steve McGeady, after Ward Cunningham, inventor of wikis.rF4

↩
Nancy Friedman, “Word of the Week: Cunningham’s Law,” Fritinancy, May 31, 2010, https://nancyfriedman.typepad.com/away_with_words/2010/05/word-of-the-week-cunninghams-law.html. (See notes.)

Listing tables in schemas.

2023-03-06T15:13:00Z

Schemas are different than databases. In Redshift and Postgres, schema tables can be listed as \dt schemaname.*

Sword of Damocles.

2023-03-06T15:09:00Z

As told by the Roman philosopher Cicero in 45 BC, Dionysius II was a tyrant over Syracuse around 400 BC. He had many riches and much power, but had created many enemies in getting there. He was deeply unhappy, worried continuously about the threat of assassination. He lived through this fear in every way.

Damocles served the court, and in one occasion upset the tyrant by expounding on how successful, rich, and happy Dionysius must be. Dionysius offered to allow Damocles to sample his life. He arranged for a throne and servants to shower Damocles with luxuries. As Damocles enjoyed these gifts, he came to notice a sword hanging above his head, suspended only by a strand of horsehair. He was thus unable to continue enjoying his wealth, threatened by death at the slightest change or accident. He begged to be released from the throne.rA5

↩
Evan Andrews, “What Was the Sword of Damocles?,” HISTORY, February 17, 2016, https://www.history.com/news/what-was-the-sword-of-damocles. (See notes.)

Mythology and folklore.

2023-03-06T15:08:00Z

The Sword of Damocles.

History.

2023-03-06T15:08:00Z

Linguistic relativity, or the Sapir-Whorf Hypothesis.

2023-03-06T15:06:00Z

Simply put, language shapes the way we think and what we think about. Reality and our perceptions of reality are clearly different things, and the way we describe reality shapes what we are capable of noticing about it. Grammar prescribes a process for breaking reality into descriptions, so grammar itself restricts what we are capable of considering.rH4

↩
Basel Al-Sheikh Hussein, “The Sapir-Whorf Hypothesis Today,” Theory and Practice in Language Studies 2, no. 3 (March 1, 2012): 642–46, https://doi.org/10.4304/tpls.2.3.642-646. (See notes.)

Linguistics.

2023-03-06T15:05:00Z

Henrik Karlsson, Starting a Blog.

2025-02-01T15:20:00Z

Henrik Karlsson, “Advice for a Friend Who Wants to Start a Blog,” January 17, 2023, https://www.henrikkarlsson.xyz/p/start-a-blog.

Reading notes.

Be yourself, integrated, and ignore what others are doing. Weird combinations of personal interests are way more interesting than just one thing. Develop your own style through embracing quirks. Chat style is more relatable than official written article style. Write for your own purposes, especially in the beginning, by writing to think things through more deeply. Writing to someone specific encourages your emotion and personality to shine because you’re trying to say things that resonate. But the writing has to be well-formed: the learning and organizing comes before the writing so the writing can be off the cuff. Simple formats to try:

here’s a problem and how I solved it
here are reflections on a problem I want to solve
a list of whatever

Having a problem to solve tells the reader what they get for their work. For each piece in the first 100, work to improve one detail:

title
structure
ending
descriptions
dialogue

Gotta work outside of comfort zone to grow, but also have to finish stuff. Deadlines can help with this. Use prompts to start. If you don’t like what you get, start over, done try to edit it to good. Edit, but not too much. Cut the weakest 20% of the draft. There’s no audience to optimize for, let them build from what you find you want to do.

Vicki Boykis, On the Team as a System.

2025-02-01T15:19:00Z

Vicki Boykis, “On the Team as a System,” September 10, 2022, https://veekaybee.github.io/2022/09/10/on-the-team-as-a-system/.

Reading notes.

Software quality comes from systems that value quality, not individuals.

Good management starts with the understanding that there is a theoretically ideal system design, one that is completely efficient and produces perfect work output. From this system, you can make tradeoffs to make it more realistic. You can add code reviews to slow down the system but increase maintainability. Carefully make these tradeoffs, though, to make sure the deficiency does not outweigh the benefit.

Bad management is the adoption of tools and practices without understanding the tradeoffs they create. Breaking up teams introduces queues into the process flow while optimizing comms within it. If this is done without understanding the tradeoff is a problem.

Good teams have effective process. What is missing in a system is just as important has what it has. Slack in work as in kanban adds efficiency. 1:1s are for providing regular feedback, but also puts gaps in the flow of feedback. Takes away the ability to have uninterrupted work. Have to interpret what is being removed and gained when making these changes.

Sam Thomas Davies, Super Thinking.

2025-01-26T00:00:00Z

Sam Thomas Davies, “Super Thinking by Gabriel Weinberg and Lauren McCann,” Sam Thomas Davies (blog), accessed January 25, 2025, https://www.samuelthomasdavies.com/book-summaries/psychology/super-thinking/.

Reading notes.

This book mostly sounds like a compilation of notes from Thinking in Systems, Essentialism, Your Brain at Work, and Liminal Thinking.

Being wrong less:

Thinking things through from first principles is the best way to be wrong less and to learn new things rapidly. First principles are assumptions that need to be tested in the real world. Use Ockham’s Razor to strip away any unnecessary dependencies.

Traps:

Framing: Stuck in one frame of reference. Consider other frames when an idea is presented.
Nudging: Influenced by specific words or other cues, unrelated to the idea itself
Anchoring: Over-reliance on first impression
Availability bias: Distortions of objectivity/model of the big picture created by overvaluing recent information

To be wrong less about other people, imagine the situation from an impartial observer’s standpoint. Similarly, try to get into an understanding where you can represent the other PoV.

Most Respectful Interpretation MRI is giving benefit of the doubt, choosing to interpret something as favorably as possible.

Hanlon’s Razor suggests carelessness creates negative experience more than malice.

Fundamental Attribution Error is the interpretation that others’ behaviors come from their fundamental motivation rather than external factors. The above strategies help mediate this.

Veil of ignorance: pretending our perspective doesn’t exist when considering how society should be organized

Confirmation bias: using new information to reaffirm existing beliefs.

Backfire effect: tendency to dig into an incorrect position when presented with contrary evidence.

Disconfirmation bias: holding new information to unreasonably high standards that existing beliefs don’t have to clear

Cognitive dissonance: Discomfort cause by possessing two contradictory ideas at the same time. Reinforcement mechanism for confirmation bias.

Real trick to being wrong less: work to accept new information, paradigms.

Models to help do that:

Thinking gray: Get out of black and white thinking, it doesn’t work
Devil’s advocate: Write out opposing rationale. Include opposition when making decisions.
- Helps reduce Optimistic Probability Bias, confusing desire for something to be true with the likelihood it is

Daniel Aronson, Stocks and Flows: Converting From Causal Loop Diagrams.

2025-01-26T00:00:00Z

Daniel Aronson, “Step-By-Step Stocks and Flows: Converting From Causal Loop Diagrams,” January 17, 2016, https://thesystemsthinker.com/step-by-step-stocks-and-flows-converting-from-causal-loop-diagrams/.

Reading notes.

To convert Causal Loop Diagrams to Stock and Flow diagrams:

Identify the units used for each variable in the CLD. Makes the diagram more precise, starts identifying where time is a variable (therefore insinuating a flow), and points out missing variables.
Identify stocks. The prior step may have noted flows, which indicate stocks. (Note that not all time-involved variables are definitely flows.) Consider whether there are additional stocks to involve. (Stocks are drawn as rectangles)
Identify flows. What increases a stock? Decreases it? Every one of these processes is a flow. (Flows are drawn as fat arrows with a circle indicating the activity with a valve connected to it)
Connect stocks and flows. All decreasers are outflows, all increasers are inflows. A stock may need to be connected to a flow if the stock’s size provides information to modulate the flow—information links are line arrows.
Add and link remaining variables. Anything left over is either a constant (like market size) or a calculation (like % market untapped). These variables can only influence each other and flows. If it seems like they are influencing a stock, then they might actually be a full-on flow and should be reconsidered. Variables are just circles connected by information arrows.
Check units. Make sure they all line up and use the same time increments.
Add any remaining variables. The goal here is to get to a calculable model, so any missing ratios etc need to be added to get there.

Jade Rubick, Velocity Role 2 - the Mole.

2025-01-25T00:00:00Z

Jade Rubick, “Velocity Role 2 - the Mole,” January 23, 2024, https://www.rubick.com/velocity-role-mole/.

Reading notes.

The mole: Spying on the org to bring back intel

Goal is to coordinate with the org better. Absorb as much information and comms as possible. They connect the dots for less informed/attentive folk. Knows who knows what.

Moles ask who would be the best to talk to about things, and which stakeholders need more information.

Risk becoming gossips or preferring social interaction than the actual organizational goals. Shouldn’t undermine trust.

Jeff Rosenthal and Molly Rosen, How to Lead Across a Siloed Organization.

2025-01-25T00:00:00Z

Jeff Rosenthal and Molly Rosen, “How to Lead Across a Siloed Organization,” Harvard Business Review, January 11, 2024, https://hbr.org/2024/01/how-to-lead-across-a-siloed-organization.

Reading notes.

It’s a common problem for CEOs to not know how to get their executive teams to work together, with each executive thinking only about their own function.

Sampling VPs+ who are able to successfully navigate their organizations without harming their relationships, clear trends emerged. They have “lateral agility”, spending as much time with their teams as with the rest of the organization—able to focus on their own objectives while driving forward the objectives of others.

3 traits:

Expanded mindsets: Humility in choosing priorities, putting the entire organization ahead of their own functions. View their job as locating expertise around the organization, weaving it together.
Connective skills: Curiosity and empathy lead to trust and symbiosis. Interest in motivations and constraints of peers. Negotiation skills seeking for everyone to win.
Innovative practices: Everyone brings sketches, no one brings plans that didn’t involve others—never about getting others to take your ideas. Prioritize building relationships with the most important participants.

To improve:

Figure out 5-8 most important stakeholders and decide whether enough time is spent with them
Is time spend going laterally or just vertically?
Learn about the day-to-day lives of people around the organization

Jade Rubick, Velocity Role 4 - the Nowist.

2025-01-25T00:00:00Z

Jade Rubick, “Velocity Role 4 - the Nowist,” January 25, 2024, https://www.rubick.com/velocity-role-nowist/.

Reading notes.

The Nowist: Strives to remove waiting from the system. Doesn’t wait for communication, questions the need for meetings. Regards deadlines as not the goal but the failure line. There is always a way to make progress without blockers stopping movement. Seeks expertise rather than approval, broadcasting intentions instead of waiting for confirmation. Senses the way a decision will go and gets a head start on following it, risking a bit of wasted work if the guess was wrong. Needs immediate goals to work toward.

Risks creating untenable goals/expectations if this is a leader. Need to pay extra attention to the needs and constraints of people who are introducing slowness.

Jade Rubick, Velocity Role 1 - the Subtractionist.

2025-01-25T00:00:00Z

Jade Rubick, “Velocity Role 1 - the Subtractionist,” January 22, 2024, https://www.rubick.com/velocity-role-subtractionist/.

Reading notes.

Mindset to create velocity in a team: Subtractionism. Simplification of everything.

Distill complexity into simple representations. Focus discussions on the most important aspects. Prevent scope creep. Essentialism.

Risks cutting too deep, simplifying too far, or completely ignoring secondary improvements.

How to integrate velocity roles on a team:

Have each member choose one role. Keep it secret.
Ask in a month who can guess which role someone chose.
Ask everyone to try on a new role in the following month.
Discuss learnings along the way.

As an individual, monitor the activity of someone who has this skill to learn from them. If there are no role models, consider becoming the trait’s representative.

Jade Rubick, Velocity Role 3 - the Dodger.

2025-01-25T00:00:00Z

Jade Rubick, “Velocity Role 3 - the Dodger,” January 24, 2024, https://www.rubick.com/velocity-role-dodger/.

Reading notes.

The dodger: foresees and proactively resolves blockers. Liminal role for sure, asking if an assumption or constraint is even true/real. Facilitate others. Develops multiple solutions to problems.

Risks avoiding more permanent solutions upstream through avoidance, creating only temporary and incomplete solutions.

Sheril Mathews, Frustration Tolerance.

2025-01-24T00:00:00Z

Sheril Mathews, “Frustration Tolerance: An Essential for Surviving Large Orgs,” January 16, 2025, https://www.leadingsapiens.com/frustration-tolerance/.

Reading notes.

Frustration tolerance is what separates people who can be successful in a large organization from those who can’t hack it. This isn’t patience exactly, it includes ability to focus on the goal while navigating other people.

Psychological definition of frustration is an interfered goal and subsequent dissatisfaction. Impacted by the language of expectation vs reality.

Those with it expect things to go poorly and prepare to cope with it in advance. Those without are surprised and incapable of tolerance—rather accept the frustration rather than deal with the difficulties of changes for the longer-term goal. Have “anxiety about anxiety”, avoiding situations they assume would make them anxious.

Leaders with low frustration tolerance:

abandon initiatives early
react disproportionately to challenges
create a tense environment through their emotional disregulation

Root cause is 4 irrational beliefs, characterized by how things “should” be, how others “must” act, how one “must” perform.

Demands for comfort and ease: expectations that no process or interaction should be challenging to deal with. Leads to avoidance or avoiding growth opportunities.
Demands for fairness and entitlement: demands for more recognition, leading to resentment and conflict. Victim mentality will hurt teamwork and prevent growth in leaders.
Demands for achievement and perfectionism: unrealistic high standards perfectionism creates procrastination and unending projects. Delegation suffers, burnout proliferates, and innovation is prevented.
Demands for emotional control and certainty: refusal to tolerate negative emotions or uncertainty. This stoic behavior leads to cultures where vulnerability is weakness and performers never ask for help, whereby burning themselves out.

Understanding that friction at work isn’t just inevitable but actually desirable helps one learn to wield it for their own intentions.

Brandur Leach, Soft Deletion Probably Isn’t Worth It.

2025-01-24T00:00:00Z

Brandur Leach, “Soft Deletion Probably Isn’t Worth It,” accessed March 6, 2023, https://brandur.org/soft-deletion.

Reading notes.

Soft delete allows easy restoration. It leaks filtering requirements into query logic, though, and even where this is made easy to do, it’s then easy to forget in manual contexts. It also breaks the benefits of foreign keys. Things like GDPR frown on retaining data unnecessarily. SAoft deletion never actually ends up supporting undeletion, either. Deletions often have side effects in other systems, and un-soft-deleting won’t magically cause the right thing to occur there.

A deleted records JSONB table is probably more useful where there’s a use case of needing to reference old data for troubleshooting etc. Supports regulatory compliance much more easily.

Rich Hickey, Simple Made Easy.

2025-01-24T00:00:00Z

Rich Hickey, “Simple Made Easy,” InfoQ, October 20, 2011, https://www.infoq.com/presentations/Simple-Made-Easy/.

Reading notes.

“Simplicity is a prerequisite for reliability”. - Edsger W. Dijkstra

Easy is approachable, readily available. Simple is more like not deeply intertwined. They are different things.

Simplicity enables understandability, changeability, debuggability, flexibility.

Build simple systems:

Abstractions answer specific W questions
Return values of constructs are simple
Encapsulation hides complexity for building higher

Jenny Nicholson, Evermore: The Theme Park That Wasn’t.

2025-01-22T00:00:00Z

Jenny Nicholson, “Evermore: The Theme Park That Wasn’t,” November 4, 2022, https://youtube.com/watch?v=L9OhTB5eBqQ.

Johnathan and Melissa Nightingale, What Did They Say When You Told Them?

2025-01-21T00:00:00Z

Johnathan and Melissa Nightingale, “What Did They Say When You Told Them?,” August 7, 2024, https://rawsignal.ca/newsletter-archive/what-did-they-say-when-you-told-them/.

Reading notes.

You can’t run a “complaint laundry” where all report are bringing their issues to you to resolve or commiserate. There are structurally relevant things to escalate. We work with adults and “what did they say when you told them that?” is a great way to turn complaints into positive action without intervention.

But it goes both ways. Valid escalations can be uncomfortable to resolve, as they’ll involve either lateral or upward discussions that are difficult to have. Those are still necessary to help the org function in a healthy manner.

Ed Zitron, The Work-From-Home Future Is Destroying Bosses’ Brains.

2025-01-20T16:47:00Z

Ed Zitron, “The Work-From-Home Future Is Destroying Bosses’ Brains,” February 9, 2023, https://wheresyoured.at/p/the-work-from-home-future-is-destroying.

Technology Connections, Old-Fashioned Rice Cookers Are Extremely Clever.

2025-01-17T00:00:00Z

Technology Connections, “Old-Fashioned Rice Cookers Are Extremely Clever,” 2020, https://www.youtube.com/watch?v=RSTNhvDGbYI.

David Wheeler, Review of Debugging.

2025-01-16T00:00:00Z

David Wheeler, “David A. Wheeler’s Review of ‘Debugging’ by David J. Agans,” March 2, 2004, https://dwheeler.com/essays/debugging-agans.html.

Ethan Siegel, Protons: Made of Quarks, but Ruled by Gluons.

2025-01-16T00:00:00Z

Ethan Siegel, “Protons: Made of Quarks, but Ruled by Gluons,” January 16, 2025, https://bigthink.com/starts-with-a-bang/protons-quarks-gluons/.

Woodruff William, Be Aware of the Makefile Effect.

2025-01-16T00:00:00Z

Woodruff William, “Be Aware of the Makefile Effect,” January 10, 2025, https://blog.yossarian.net/2025/01/10/Be-aware-of-the-Makefile-effect.

Fred Hebert, Queues Don’t Fix Overload.

2025-01-15T00:00:00Z

Fred Hebert, “Queues Don’t Fix Overload,” November 19, 2014, https://ferd.ca/queues-don-t-fix-overload.html.

Sebastian Gebski, The Failed Promise of Domain-Driven Design.

2025-01-15T00:00:00Z

Sebastian Gebski, “The Failed Promise of Domain-Driven Design - Part 1,” January 2, 2024, https://no-kill-switch.ghost.io/the-failed-promise-of-domain-driven-design-part-1/.

Jason Wong, Building a First Team Mindset.

2025-01-13T00:00:00Z

Jason Wong, “Building a First Team Mindset,” Jason Wong’s Blog (blog), June 25, 2018, https://www.attack-gecko.net/2018/06/25/building-a-first-team-mindset/.

Sanjana Gajbhiye, Male and Female Brains.

2025-01-12T00:00:00Z

Sanjana Gajbhiye, “Male and Female Brains Truly Are Wired Completely Differently,” Earth.com, January 9, 2025, https://www.earth.com/news/male-and-female-brains-are-wired-completely-differently/.

Catherine Pearson, 6 Ways to Strengthen Your Relationships in 2023.

2025-01-10T00:00:00Z

Catherine Pearson, “6 Ways to Strengthen Your Relationships in 2023,” The New York Times, December 29, 2022, sec. Well, https://www.nytimes.com/2022/12/29/well/family/relationship-advice-love-friendship-dating.html.

Anita Hossain Choudhry and Mindy Zhang, The Best Managers Don’t Fix, They Coach.

2025-01-10T00:00:00Z

Anita Hossain Choudhry and Mindy Zhang, “The Best Managers Don’t Fix, They Coach — Four Tools to Add to Your Toolkit,” accessed January 16, 2022, https://review.firstround.com/the-best-managers-dont-fix,-they-coach-four-tools-to-add-to-your-toolkit.

Jennifer Chu, Physicists Magnetize a Material with Light.

2025-01-10T00:00:00Z

Jennifer Chu, “Physicists Magnetize a Material with Light,” December 18, 2024, https://news.mit.edu/2024/physicists-magnetize-material-using-light-1218.

Sigal Samuel, You Can’t Optimize Your Way to Being a Good Person.

2025-01-10T00:00:00Z

Sigal Samuel, “You Can’t Optimize Your Way to Being a Good Person,” December 3, 2024, https://www.vox.com/the-highlight/387570/moral-optimization.

Alex Russell, Frontend’s Lost Decade.

2025-01-09T00:00:00Z

Alex Russell, “Reckoning: Frontend’s Lost Decade,” 2025, https://youtu.be/0XwWVjQOmyg.

Sergey Tselovalnikov, Six Sins of Platform Teams.

2025-01-08T00:00:00Z

Sergey Tselovalnikov, “Six Sins of Platform Teams,” January 7, 2025, https://serce.me/posts/2025-01-07-six-sins-of-platform-teams.

Doc Norton, Tuckman Was Wrong!

2025-01-08T00:00:00Z

Doc Norton, “Tuckman Was Wrong!,” OnBelay, May 5, 2017, https://onbelay.co/articles/2017/5/5/tuckman-was-wrong.

Peter Naur, Programming as Theory Building.

2025-01-05T00:00:00Z

Peter Naur, “Programming as Theory Building,” Microprocessing and Microprogramming 15, no. 5 (May 1985): 253–61, (85)90032-8">https://doi.org/10.1016/0165-6074(85)90032-8.

Giacomo Bartolucci et al., Phase Behavior of Cacio and Pepe Sauce.

2025-01-04T00:00:00Z

Giacomo Bartolucci et al., “Phase Behavior of Cacio and Pepe Sauce” (arXiv, December 31, 2024), https://doi.org/10.48550/arXiv.2501.00536.

Joshua Kaplan, A Mole Infiltrated the Highest Ranks of American Militias.

2025-01-04T00:00:00Z

Joshua Kaplan, “A Mole Infiltrated the Highest Ranks of American Militias. This Is What He Found.,” ProPublica, January 4, 2025, https://www.propublica.org/article/ap3-oath-keepers-militia-mole.

Nicole Forsgren et al., The SPACE of Developer Productivity.

2025-01-03T00:00:00Z

Nicole Forsgren et al., “The SPACE of Developer Productivity: There’s More to It than You Think.,” Queue 19, no. 1 (February 28, 2021): 20–48, https://doi.org/10.1145/3454122.3454124.

Marilyn Haigh, Silent Meetings.

2025-01-02T00:00:00Z

Marilyn Haigh, “Execs from Amazon, LinkedIn and Square Start Some Meetings in Silence — Here’s Why,” CNBC, November 7, 2018, https://www.cnbc.com/2018/11/07/amazon-and-square-execs-swear-by-the-silent-meeting–heres-why.html.

Julius Seporaitis, What Can 75,000 Pull Requests Tell?

2025-01-02T00:00:00Z

Julius Seporaitis, “What Can 75,000 Pull Requests Tell?,” July 19, 2021, https://www.seporaitis.net/posts/2021/07/19/what-can-75000-pull-requests-tell/.

Ethan Siegel, The One-Page Calendar That Changes How You View the Year.

2025-01-01T00:00:00Z

Ethan Siegel, “The One-Page Calendar That Changes How You View the Year,” Big Think (blog), January 1, 2025, https://bigthink.com/starts-with-a-bang/one-page-calendar/.

Noah Davis, Cycle Time.

2024-12-31T00:00:00Z

Noah Davis, “What Is Cycle Time and Why Does It Matter?,” Code Climate (blog), December 8, 2020, https://codeclimate.com/blog/software-engineering-cycle-time/.

Marianne Bellotti, Hunting Tech Debt via Org Charts.

2024-12-30T00:00:00Z

Marianne Bellotti, “Hunting Tech Debt via Org Charts,” Medium (blog), December 20, 2021, https://bellmar.medium.com/hunting-tech-debt-via-org-charts-92df0b253145.

Stiltsoft, How to Visualize Cycle Time / Lead Time.

2024-12-29T00:00:00Z

“Pull Request Analytics: How to Visualize Cycle Time / Lead Time and Get Insights for Improvement,” Stiltsoft (blog), March 30, 2021, https://stiltsoft.com/blog/pull-request-analytics-how-to-visualize-cycle-time-lead-time-and-get-insights-for-improvement/.

George Guimarães, 5 Metrics Engineering Managers Can Extract from Pull Requests.

2024-12-29T00:00:00Z

George Guimarães, “5 Metrics Engineering Managers Can Extract from Pull Requests,” SourceLevel (blog), November 14, 2019, https://sourcelevel.io/blog/5-metrics-engineering-managers-can-extract-from-pull-requests.

Noah Davis, What Analyzing 180,000 Pull Requests Taught Us About Shipping Faster.

2024-12-28T00:00:00Z

Noah Davis, “What Analyzing 180,000 Pull Requests Taught Us About Shipping Faster,” Code Climate (blog), November 28, 2018, https://codeclimate.com/blog/what-data-science-tells-us-about-shipping-faster/.

Adrian Colyer, The Evolution of Continuous Experimentation in Software Product Development.

2024-12-27T00:00:00Z

Adrian Colyer, “The Evolution of Continuous Experimentation in Software Product Development | the Morning Paper,” September 29, 2017, https://blog.acolyer.org/2017/09/29/the-evolution-of-continuous-experimentation-in-software-product-development/.

Jaime Bocanumenth, Five Organizational Models.

2024-12-27T00:00:00Z

Jaime Bocanumenth, “Five Organizational Models,” accessed August 1, 2022, https://www.ursinus.edu/live/files/1157-five-organizational-modelspdf.

Sandi Metz, The Wrong Abstraction.

2024-12-25T00:00:00Z

Sandi Metz, “The Wrong Abstraction,” Sandi Metz, January 20, 2016, https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction.

Sinan Ata, Rockstars vs Superstars.

2024-12-24T00:00:00Z

Sinan Ata, “Rockstars vs Superstars — Get to Know Your People,” Medium, March 19, 2020, https://medium.com/the-crossover-cast/rockstars-vs-superstars-get-to-know-your-people-b30cd878e0a1.

Patrick M. Lencioni, Make Your Values Mean Something.

2024-12-20T00:00:00Z

Patrick M. Lencioni, “Make Your Values Mean Something,” Harvard Business Review, July 1, 2002, https://hbr.org/2002/07/make-your-values-mean-something.

Douglas A. Ready and Emily Truelove, The Power of Collective Ambition.

2024-12-19T00:00:00Z

Douglas A. Ready and Emily Truelove, “The Power of Collective Ambition,” Harvard Business Review, December 1, 2011, https://hbr.org/2011/12/the-power-of-collective-ambition.

Derek Comartin, STOP Doing Dogmatic Domain Driven Design.

2024-12-19T00:00:00Z

Derek Comartin, “STOP Doing Dogmatic Domain Driven Design,” CodeOpinion (blog), June 9, 2021, https://codeopinion.com/stop-doing-dogmatic-domain-driven-design/.

Julia Rozovsky, The Five Keys to a Successful Google Team.

2024-12-19T00:00:00Z

Julia Rozovsky, “Re:Work - The Five Keys to a Successful Google Team,” November 17, 2015, https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/.

Maarten Dalmijn, Shape Up vs Scrum.

2024-12-18T00:00:00Z

Maarten Dalmijn, “Basecamp’s Shape Up: How Different Is It Really from Scrum?,” Medium, May 6, 2020, https://medium.com/serious-scrum/basecamps-shape-up-how-different-is-it-really-from-scrum-c0298f124333.

Brandur Leach, Implementing Stripe-like Idempotency Keys in Postgres.

2024-12-15T00:00:00Z

Brandur Leach, “Implementing Stripe-like Idempotency Keys in Postgres — Brandur.Org,” October 27, 2017, https://www.brandur.org/idempotency-keys.

Richard Cook, How Complex Systems Fail.

2024-12-15T00:00:00Z

Richard Cook, “How Complex Systems Fail,” April 21, 2000, https://how.complexsystems.fail/.

RAPID®: Bain’s Tool to Clarify Decision Accountability.

2024-10-21T00:00:00Z

“RAPID®: Bain’s Tool to Clarify Decision Accountability,” Bain, August 11, 2011, https://www.bain.com/insights/rapid-tool-to-clarify-decision-accountability/.

Benjamin Artz, Amanda Goodall, and Andrew J. Oswald, If Your Boss Could Do Your Job, You’re More Likely to Be Happy at Work.

2024-10-20T00:00:00Z

Benjamin Artz, Amanda Goodall, and Andrew J. Oswald, “If Your Boss Could Do Your Job, You’re More Likely to Be Happy at Work,” Harvard Business Review, December 29, 2016, https://hbr.org/2016/12/if-your-boss-could-do-your-job-youre-more-likely-to-be-happy-at-work.

Melvin E. Conway, How Do Committees Invent?

2024-10-20T00:00:00Z

Melvin E. Conway, “How Do Committees Invent?,” Datamation, April 1968, https://www.melconway.com/Home/pdf/committees.pdf.

Charity Majors, Engineering Management: The Pendulum Or The Ladder.

2024-10-20T00:00:00Z

Charity Majors, “Engineering Management: The Pendulum Or The Ladder,” charity.wtf, January 4, 2019, https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/.

Ron Carucci, How Corporate Values Get Hijacked and Misused.

2024-10-13T00:00:00Z

Ron Carucci, “How Corporate Values Get Hijacked and Misused,” Harvard Business Review, May 29, 2017, https://hbr.org/2017/05/how-corporate-values-get-hijacked-and-misused.

Jade Rubick, Why and How to Do Skip Level 1-1s.

2024-10-02T00:00:00Z

Jade Rubick, “Why and How to Do Skip Level 1-1s,” September 30, 2024, https://www.rubick.com/skip-level-1-on-1s/.

Will Larson, Good Engineering Strategy Is Boring.

2024-10-02T00:00:00Z

Will Larson, “Write Five, Then Synthesize: Good Engineering Strategy Is Boring.,” November 26, 2020, https://lethain.com/good-engineering-strategy-is-boring/.

Richard Rumelt, The Perils of Bad Strategy.

2024-10-02T00:00:00Z

Richard Rumelt, “The Perils of Bad Strategy | McKinsey,” June 1, 2011, https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/the-perils-of-bad-strategy.

Will Larson, Engineering Strategy Every Org Should Write.

2024-10-02T00:00:00Z

Will Larson, “Engineering Strategy Every Org Should Write.,” November 7, 2020, https://lethain.com/eng-strategies-every-org-should-write/.

David Graeber, Are You An Anarchist? The Answer May Surprise You!.

2024-09-29T00:00:00Z

David Graeber, “Are You An Anarchist? The Answer May Surprise You!,” The Anarchist Library, November 9, 2009, https://theanarchistlibrary.org/library/david-graeber-are-you-an-anarchist-the-answer-may-surprise-you.

Katie Mather, How You Perceive Time Reveals a Lot about You.

2024-09-29T00:00:00Z

Katie Mather, “How You Perceive Time Reveals a Lot about You,” In The Know, June 30, 2020, https://www.intheknow.com/post/how-you-perceive-time-reveals-a-lot-about-you/.

Byron Katie, 4 Questions to Get out of a Negative Headspace, Stop Suffering, & Start Healing Now.

2024-09-29T00:00:00Z

Byron Katie’s 4 Questions to Get out of a Negative Headspace, Stop Suffering, & Start Healing Now, 2020, https://www.youtube.com/watch?v=lr0_afKsI8M&ab_channel=MarieForleo.

Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game.

2024-09-29T00:00:00Z

Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game,” Harvard Business Review, January 1, 1986, https://hbr.org/1986/01/the-new-new-product-development-game.

Abi Noda, Predicting Developer Attrition.

2024-09-24T00:00:00Z

Abi Noda, “Predicting Developer Attrition,” June 9, 2023, https://newsletter.getdx.com/p/predicting-developer-attrition.

Csaba Okrona, Demystifying Burnout.

2024-09-16T00:00:00Z

Csaba Okrona, “Demystifying Burnout – A Deep Dive Into Its Symptoms And Remedies,” June 26, 2023, https://leadership.garden/demystifying-burnout/.

Benjamin Harris and Aliz Hammond, We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI.

2024-09-15T00:00:00Z

Benjamin Harris and Aliz Hammond, “We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI,” watchTowr Labs - Blog, September 11, 2024, https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/.

Ron Jeffries, Dark Scrum.

2024-09-01T00:00:00Z

Ron Jeffries, “Dark Scrum,” September 8, 2016, https://ronjeffries.com/articles/016-09ff/defense/.

Lynn Root, The Design of Everyday APIs.

2024-08-09T00:00:00Z

Lynn Root, “The Design of Everyday APIs,” June 2, 2022, https://www.roguelynn.com/talks/everyday-apis/.

Alexandra Hoffer, Creating Processes for API Clarity and Consistency.

2024-08-06T00:00:00Z

Alexandra Hoffer, “Creating Processes for API Clarity and Consistency,” Plaid, February 17, 2022, https://plaid.com/blog/api-review-council/.

Stay SaaSy, Standardizing.

2024-08-06T00:00:00Z

“Standardizing,” Stay SaaSy, August 6, 2024, https://staysaasy.com/management/2024/08/06/standardize.html.

Proto Best Practices.

2024-08-05T00:00:00Z

“Proto Best Practices,” Protocol Buffers Documentation, accessed July 29, 2024, https://protobuf.dev/programming-guides/dos-donts/.

API Best Practices.

2024-08-05T00:00:00Z

“API Best Practices,” Protocol Buffers Documentation, accessed July 29, 2024, https://protobuf.dev/programming-guides/api/.

Kevin Dickinson, 3 Rules to Express Your Thoughts so That Everyone Will Understand You.

2024-08-02T00:00:00Z

Kevin Dickinson, “3 Rules to Express Your Thoughts so That Everyone Will Understand You,” Big Think (blog), December 1, 2022, https://bigthink.com/the-learning-curve/3-rules-express-your-thoughts-clearly/.

A Practical Guide to Executive Presence.

2024-07-28T00:00:00Z

“A Practical Guide to Executive Presence,” May 27, 2023, https://staysaasy.com/leadership/2023/05/27/executive-presence.html.

Jakob Nielson, 10 Usability Heuristics for UI Design.

2024-07-27T00:00:00Z

Jakob Nielsen, “10 Usability Heuristics for User Interface Design,” Nielsen Norman Group, 1994, https://www.nngroup.com/articles/ten-usability-heuristics/.

Jade Rubick, Executive Presence Coaching.

2024-07-02T00:00:00Z

Jade Rubick, “Executive Presence Coaching – Use These Tips to Become a Better Leader,” February 7, 2022, https://www.rubick.com/executive-presence-coaching/.

Kevin Gary, To the Bored All Things Are Boring.

2024-06-27T00:00:00Z

Kevin Gary, “To the Bored All Things Are Boring,” January 5, 2023, https://comment.org/to-the-bored-all-things-are-boring/.

Irina Stanescu, Growing Beyond Senior Levels in Engineer.

2024-06-23T00:00:00Z

Irina Stanescu, “3 Critical Skills You Need to Grow Beyond Senior Levels in Engineering,” April 8, 2024, https://www.thecaringtechie.com/p/3-critical-skills-you-need-to-grow.

Aria Beingessner, Mozilla’s Engineering Ladder.

2024-06-23T00:00:00Z

Aria Beingessner (@Gankra_), Twitter post, September 30, 2018, https://twitter.com/Gankra_/status/1046438955439271936/photo/1.

Suzan Bond, An Incomplete List of Org Smells.

2024-05-25T00:00:00Z

Suzan Bond, “An Incomplete List of Org Smells,” Substack newsletter, Suzan’s Fieldnotes (blog), April 25, 2022, https://suzansfieldnotes.substack.com/p/an-incomplete-list-of-org-smells.

Rach Smith, Reassessing the Morning Routine in 2023.

2024-04-27T00:00:00Z

Rach Smith, “Reassessing the Morning Routine in 2023,” Rach Smith’s digital garden, accessed April 14, 2024, https://rachsmith.com/reassessing-the-morning-routine/.

Ben Kuhn, Staring into the Abyss as a Core Life Skill.

2024-04-27T00:00:00Z

Ben Kuhn, “Staring into the Abyss as a Core Life Skill,” benkuhn.net, December 22, 2022, https://www.benkuhn.net/abyss/.

Louis Chew, The Steel Man Technique.

2024-04-27T00:00:00Z

Louis Chew, “The Steel Man Technique: How To Argue Better And Be More Persuasive,” August 25, 2018, https://constantrenewal.com/steel-man.

Cate Hall, How to Be More Agentic.

2024-04-16T00:00:00Z

Cate Hall, “How to Be More Agentic,” Substack newsletter, Useful Fictions (blog), January 10, 2024, https://usefulfictions.substack.com/p/how-to-be-more-agentic.

Itamar Shatz, The Shirky Principle.

2024-04-16T00:00:00Z

Itamar Shatz, “The Shirky Principle: Institutions Try to Preserve the Problem to Which They Are the Solution – Effectiviology,” accessed February 24, 2024, https://effectiviology.com/shirky-principle/.

Shreyas Doshi, High Agency.

2024-04-15T00:00:00Z

Shreyas Doshi, “High Agency: What Is It, Why It Is Important, and How to Cultivate It,” June 28, 2020, https://www.linkedin.com/pulse/high-agency-its-importance-how-cultivate-shreyas-doshi.

Derek Sivers, Writing One Sentence per Line.

2024-04-14T00:00:00Z

Derek Sivers, “Writing One Sentence per Line,” June 20, 2022, https://sive.rs/1s.

Eliyahu Goldratt, Theory of Constraints.

2024-04-14T00:00:00Z

Eliyahu Goldratt, Presenting TOC (Theory of Constraints), 2012, https://www.youtube.com/watch?v=DQoO8y3En3w.

AoM, Towards a Philosophy of Household Management.

2024-04-14T00:00:00Z

Brett & Kate McKay, “Towards a Philosophy of Household Management,” The Art of Manliness (blog), March 26, 2024, https://www.artofmanliness.com/lifestyle/homeownership/towards-a-philosophy-of-household-management/.

Redowan Delowar, ETag and HTTP Caching.

2024-04-10T00:00:00Z

Redowan Delowar, “ETag and HTTP Caching,” April 10, 2024, https://rednafi.com/misc/etag_and_http_caching/.

Paul Asjes, Designing APIs for Humans: Object IDs.

2024-03-26T00:00:00Z

Paul Asjes, “Designing APIs for Humans: Object IDs,” DEV Community, August 30, 2022, https://dev.to/stripe/designing-apis-for-humans-object-ids-3o5a.

Derek Sivers, Cut out Everything That’s Not Surprising.

2024-03-25T00:00:00Z

Derek Sivers, “Cut out Everything That’s Not Surprising,” October 14, 2019, https://sive.rs/d22.

Eric Raymond, Basics of the Unix Philosophy.

2024-03-24T00:00:00Z

Eric Steven Raymond, “Basics of the Unix Philosophy,” 2003, http://www.catb.org/~esr/writings/taoup/html/ch01s06.html.

AoM, 5BX.

2024-03-23T00:00:00Z

Brett & Kate McKay, “5BX: The Cold War Military Workout for Getting Fit in 11 Minutes a Day,” The Art of Manliness (blog), March 19, 2024, https://www.artofmanliness.com/health-fitness/5bx-the-cold-war-military-workout-for-getting-fit-in-11-minutes-a-day/.

Jefferey Cave, The Evils of Sequential IDs.

2024-03-22T00:00:00Z

Jefferey Cave, “The Evils of Sequential IDs,” Medium (blog), January 20, 2024, https://jefferey-cave.medium.com/the-evils-of-sequential-ids-2d1b18b50fdb.

Jack Lindamood, Bipartite Composition.

2024-03-15T00:00:00Z

Jack Lindamood, “Design Better Software Abstractions Using Bipartite Composition,” May 29, 2019, https://cep.dev/posts/design-better-software-abstractions-using-bipartite-composition/.

Vicki Boykis, Both Pyramids Are White.

2024-03-15T00:00:00Z

Vicki Boykis, “Both Pyramids Are White,” March 13, 2024, https://vickiboykis.com/2024/03/13/both-pyramids-are-white/.

Derek Comartin, Event-Driven Architecture Lost Its Way.

2024-03-12T00:00:00Z

Derek Comartin, “Event-Driven Architecture Lost Its Way,” March 7, 2024, https://codeopinion.com/event-driven-architecture-lost-its-way/.

Fred Wynyk, Conway’s Law in Team Topolgies.

2024-03-12T00:00:00Z

Fred Wynyk, “Conway’s Law in Team Topolgies: Did You Really Get It?,” Medium (blog), February 22, 2024, https://medium.com/@fwynyk/conways-law-in-team-topolgies-did-you-really-get-it-69c1a4d702af.

Yuval Yeret, 4 Metrics To Visualize and Accelerate Flow.

2024-03-12T00:00:00Z

Yuval Yeret, “4 Metrics To Visualize and Accelerate Flow - DZone,” May 10, 2018, https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events.

Sam Thomas Davies, Failing Forward.

2024-02-29T00:00:00Z

Sam Thomas Davies, “Words Into Works #106 | Failing Forward,” February 26, 2024, https://www.samuelthomasdavies.com/failing-forward/.

Matthew Rocklin, Write Dumb Code.

2024-02-28T00:00:00Z

Matthew Rocklin, “Write Dumb Code,” January 27, 2018, https://matthewrocklin.com/write-dumb-code.html.

Tom Critchlow, Narrative Strategy.

2024-02-26T00:00:00Z

Tom Critchlow, “(Another) Quick Riff on Narrative Strategy,” February 16, 2024, https://tomcritchlow.com/2024/02/16/narrative-strategy/.

Charlotte Hu, Why Writing by Hand Is Better for Memory and Learning.

2024-02-24T00:00:00Z

Charlotte Hu, “Why Writing by Hand Is Better for Memory and Learning,” February 21, 2024, https://www.scientificamerican.com/article/why-writing-by-hand-is-better-for-memory-and-learning/.

Ninad Pathak, Your GitHub Pull Request Workflow Is Slowing Everyone Down.

2024-02-23T00:00:00Z

Ninad Pathak, “Your GitHub Pull Request Workflow Is Slowing Everyone Down,” December 4, 2023, https://graphite.dev/blog/your-github-pr-workflow-is-slow.

James Samuel, How to Get Good at Giving Feedback.

2024-02-18T00:00:00Z

James Samuel, “How to Get Good at Giving Feedback,” Substack newsletter, Effective Software Leads (blog), February 5, 2024, https://softwareleads.substack.com/p/how-to-get-good-at-giving-feedback.

Greg Foster, The Ideal PR Is 50 Lines Long.

2024-02-08T00:00:00Z

Greg Foster, “The Ideal PR Is 50 Lines Long,” July 24, 2023, https://graphite.dev/blog/the-ideal-pr-is-50-lines-long.

Selena Simmons-Duffin, Your Appendix Is Not Useless.

2024-02-08T00:00:00Z

Selena Simmons-Duffin, “Your Appendix Is Not, in Fact, Useless. This Anatomy Professor Explains,” NPR, February 2, 2024, sec. Short Wave, https://www.npr.org/sections/health-shots/2024/02/02/1228474984/appendix-function-appendicitis-gut-health.

Jason Cohen, Business Advice Plagued by Survivor Bias.

2024-02-07T00:00:00Z

Jason Cohen, “Business Advice Plagued by Survivor Bias,” August 17, 2009, https://longform.asmartbear.com/survivor-bias/.

Maxwell Zeff, There’s More Proof That Return to Office Is Pointless.

2024-01-31T00:00:00Z

Maxwell Zeff, “There’s More Proof That Return to Office Is Pointless,” January 30, 2024, https://gizmodo.com/more-proof-that-return-to-office-is-pointless-1851209231.

Adam Fishman, Debate Everything vs. Just Tell Me What To Build.

2024-01-28T00:00:00Z

Adam Fishman, “Balancing Engineering Cultures: Debate Everything vs. Just Tell Me What To Build,” January 31, 2023, https://www.fishmanafnewsletter.com/p/balancing-engineering-cultures-debate-vs-do.

Eirini Kalliamvakou, Good DevEx Increases Productivity.

2024-01-26T00:00:00Z

Eirini Kalliamvakou, “Yes, Good DevEx Increases Productivity. Here Is the Data.,” January 23, 2024, https://github.blog/2024-01-23-good-devex-increases-productivity/.

Crystal Lewis, Hire a Data Manager.

2024-01-25T00:00:00Z

Crystal Lewis, “Hire a Data Manager,” July 7, 2023, https://cghlewis.com/blog/hire_datamgr/.

Tom Critchlow, Don’t Give Advice, Be Useful.

2024-01-23T00:00:00Z

Tom Critchlow, “Don’t Give Advice, Be Useful,” January 23, 2024, https://tomcritchlow.com/2024/01/23/advice/.

Crystal Lewis, Let’s Talk about Joins.

2024-01-21T00:00:00Z

Crystal Lewis, “Let’s Talk about Joins,” January 10, 2024, https://cghlewis.com/blog/joins/.

Fernando Villalba, Don’t Destroy Silos, Transform Them.

2024-01-19T00:00:00Z

Fernando Villalba, “DevOps: Don’t Destroy Silos, Transform Them,” Substack newsletter, The Personable Engineer (blog), December 19, 2023, https://fernandovillalba.substack.com/p/devops-dont-destroy-silos-transform.

Johnathan & Melissa Nightingale, Director Means Something.

2024-01-17T00:00:00Z

Johnathan Nightingale and Melissa Nightingale, “Director Means Something,” January 10, 2024, https://www.rawsignal.ca/newsletter-archive/director-means-something.

Bob Violino, 10 Ways to Destroy Developer Happiness.

2024-01-15T00:00:00Z

Bob Violino, “10 Ways to Destroy Developer Happiness,” January 8, 2024, https://www.infoworld.com/article/3711840/10-ways-to-destroy-developer-happiness.html.

Pier-Jean Malandrino, C4 Model Perspective.

2024-01-15T00:00:00Z

Pier-Jean Malandrino, “C4 Model Perspective - DZone,” January 5, 2024, https://lab.scub.net/the-different-types-of-software-architects-c4-model-perspective-dcf3bb4c49e8.

Tom Mahood, The Hunt for the Death Valley Germans.

2024-01-10T00:00:00Z

Tom Mahood, “The Hunt for the Death Valley Germans,” accessed January 13, 2024, https://www.otherhand.org/home-page/search-and-rescue/the-hunt-for-the-death-valley-germans/.

Derek Sivers, Benefits of a Daily Diary and Topic Journals.

2024-01-04T00:00:00Z

Derek Sivers, “Benefits of a Daily Diary and Topic Journals,” accessed January 4, 2024, https://sive.rs/dj.

Julia Evans, Write a Brag Document.

2024-01-03T00:00:00Z

Julia Evans, “Get Your Work Recognized: Write a Brag Document,” June 28, 2019, https://jvns.ca/blog/brag-documents/.

Jeff Haden, The Best Employees Focus on Content, Not Process.

2024-01-02T00:00:00Z

Jeff Haden, “27 Years Ago, Steve Jobs Said the Best Employees Focus on Content, Not Process. Research Shows He Was Right,” March 9, 2023, https://www.inc.com/jeff-haden/27-years-ago-steve-jobs-said-best-employees-focus-on-content-not-process-workplace-research-shows-he-was-right.html.

Will Larson, Why Limiting Work-in-Progress Works.

2023-12-28T00:00:00Z

Will Larson, “Why Limiting Work-in-Progress Works.,” February 17, 2019, https://lethain.com/limiting-wip/.

Sara Tortoli, Jobs-To-Be-Done.

2023-12-20T00:00:00Z

Sara Landi Tortoli, “Uncover Your Customers’ Hidden Needs In 4 Steps with Jobs-To-Be-Done + Access Custom GPT | HackerNoon,” December 14, 2023, https://hackernoon.com/uncover-your-customers-hidden-needs-in-4-steps-with-the-jobs-to-be-done-framework.

Sergey Faldin, All You Need Is To Make 1,000 Pots.

2023-12-20T00:00:00Z

Sergey Faldin, “All You Need Is To Make 1,000 Pots,” June 11, 2020, https://scribe.bus-hit.me/honest-creative/all-you-need-is-to-make-1-000-pots-6f8c80ebd88d.

Oskar Dudycz, From Relational Data To Events.

2023-12-18T00:00:00Z

Oskar Dudycz, “Hitchhiker’s Guide To Moving From Relational Data To Events,” December 15, 2023, https://event-driven.io/en/the_end_is_near_for_crud_data/.

Sam Davies, The Six Principles of Effective Writing.

2023-12-15T00:00:00Z

Sam Thomas Davies, “Words Into Works #099 | The Six Principles of Effective Writing,” December 11, 2023, https://www.samuelthomasdavies.com/the-six-principles-of-effective-writing/.

Leonardo Creed, The Most Valuable Trait of Top Software Engineers.

2023-12-04T00:00:00Z

Leonardo Creed, “The Most Valuable Trait of Top Software Engineers,” Substack newsletter, Engineer’s Codex (blog), October 26, 2023, https://engineercodex.substack.com/p/the-1-trait-of-the-most-valuable.

Chris Taylor, Every Self-Help Book Ever.

2023-11-30T00:00:00Z

Chris Taylor, “Every Self-Help Book Ever, Boiled down to 11 Simple Rules,” July 25, 2020, https://mashable.com/article/best-self-help-book-advice.

Remy Porter, The Therac-25 Incident.

2023-11-30T00:00:00Z

Remy Porter, “The Therac-25 Incident,” February 15, 2021, https://thedailywtf.com/articles/the-therac-25-incident.

Derek Sivers, First Follower Leadership Lessons.

2023-11-26T00:00:00Z

Derek Sivers, First Follower Leadership Lessons - Stabilized and Enlarged, 2013, https://www.youtube.com/watch?v=8p9GZfhvrys.

Veritasium, Testing the US Military’s Worst Idea.

2023-11-26T00:00:00Z

Veritasium, “Testing the US Military’s Worst Idea,” 2022, https://www.youtube.com/watch?v=J_n1FZaKzF8.

Stay SaaSy, Stop Making People Make Up Their Mind.

2023-11-18T00:00:00Z

“Stop Making People Make Up Their Mind,” Stay SaaSy, July 12, 2023, https://staysaasy.com/product/2023/07/12/changing-minds.html.

Jimmy Breck-McKye, Microfrontends Should Be Your Last Resort.

2023-11-18T00:00:00Z

Jimmy Breck-McKye, “Microfrontends Should Be Your Last Resort,” May 29, 2023, https://www.breck-mckye.com/blog/2023/05/Microfrontends-should-be-your-last-resort/.

Arjun Narayan and George Fraser, Don’t Use Kafka as Your Primary Data Store.

2023-11-18T00:00:00Z

Arjun Narayan and George Fraser, “Using Kafka as Your Primary Data Store? Here’s Why You Shouldn’t,” Materialize, December 8, 2020, https://materialize.com/kafka-is-not-a-database/.

Neil Madden, Moving Away from UUIDs.

2023-11-14T00:00:00Z

Neil Madden, “Moving Away from UUIDs,” Neil Madden (blog), August 30, 2018, https://neilmadden.blog/2018/08/30/moving-away-from-uuids/.

Connect2id, Human-Friendly Identifiers.

2023-11-14T00:00:00Z

“How to Generate Human-Friendly Identifiers | Connect2id,” 2016. https://connect2id.com/blog/how-to-generate-human-friendly-identifiers.

Henrique Vicente, You Don’t Need UUID.

2023-11-14T00:00:00Z

Henrique Vicente, “You Don’t Need UUID | Henrique Vicente,” May 30, 2021, https://henvic.dev/posts/uuid/.

Rob Conery, A Better ID Generator For PostgreSQL.

2023-11-14T00:00:00Z

Rob Conery, “A Better ID Generator For PostgreSQL,” Rob Conery, May 29, 2014, http://rob.conery.io/2014/05/29/a-better-id-generator-for-postgresql/.

AoM, You Should Have 12 Favorite Problems.

2023-11-11T00:00:00Z

Brett & Kate McKay, “Think Like Feynman: Why You Should Have 12 Favorite Problems,” The Art of Manliness (blog), May 2, 2023, https://www.artofmanliness.com/character/advice/think-like-feynman-why-you-should-have-12-favorite-problems/.

Matt Kirkland, On Keeping Sketchbooks.

2023-09-28T00:00:00Z

Matt Kirkland, “On Keeping Sketchbooks,” Attainable Felicity, August 22, 2023, https://attainablefelicity.mattkirkland.com/20230822/Sketchbooks.html.

Patrick McKenzie, Credit Card Debt Collection.

2023-09-12T00:00:00Z

Patrick McKenzie, “Credit Card Debt Collection,” August 11, 2023, https://www.bitsaboutmoney.com/archive/the-waste-stream-of-consumer-finance/.

Vsauce, Do Chairs Exist?

2023-05-06T00:00:00Z

Vsauce, “Do Chairs Exist?,” YouTube video, 37:51, 2021-09-14, https://www.youtube.com/watch?v=fXW-QjBsruE.

Premise: Ontology and mereology help us explore what exactly it means for a chair to exist.

Addy Osmani, Managing Complex Change.

2023-04-30T00:00:00Z

Addy Osmani, “Managing Complex Change,” November 7, 2022, https://addyosmani.com/blog/managing-complex-change/.

Premise: You need 6 factors to manage complex change, and each is associated with a pitfall when missing.

David Jenkins, Guillermo Del Toro on Noir and Horror.

2023-04-29T00:00:00Z

David Jenkins, “I Asked Guillermo Del Toro His Thoughts on the Intersections between Noir and Horror (w/r/t Nightmare Alley) and, for Context, He Threw out This Amazing Definition of Noir… Https://T.Co/COrbpXJqdp,” Tweet, Twitter, December 14, 2021, https://twitter.com/daveyjenkins/status/1470871077404479499.

Kurzgesagt, The Star That Shouldn’t Exist.

2023-04-23T00:00:00Z

Kurzgesagt, Black Hole Star – The Star That Shouldn’t Exist, 2022, https://www.youtube.com/watch?v=aeWyp2vXxqA.

Premise: Supermassive stars may have existed in the early universe which created and force fed internal black holes, explaining why we see black holes that seem to be too large to exist.

Henrik Kniberg, The Resource Utilization Trap.

2023-04-23T00:00:00Z

Henrik Kniberg, “The Resource Utilization Trap,” 2014, https://www.youtube.com/watch?v=CostXs2p6r0&ab_channel=crispagileacademy.

Premise: Resource utilization must include slack or the flow of work is held up.

Sam Thomas Davies, The Four Commitments.

2023-04-19T00:00:00Z

Sam Thomas Davies, “Words Into Works #070 | The Four Commitments,” Sam Thomas Davies (blog), April 3, 2023, https://www.samuelthomasdavies.com/the-four-commitments/.

Lara Hogan, Be a Thermostat, Not a Thermometer.

2023-04-15T00:00:00Z

Lara Hogan, “Be a Thermostat, Not a Thermometer,” April 4, 2023, https://larahogan.me/blog/be-a-thermostat-not-a-thermometer/.

Jade Rubick, Engineering Manager vs. Tech Lead.

2023-04-07T00:00:00Z

Jade Rubick, “Engineering Manager vs. Tech Lead – Which Is Better?,” November 17, 2021, https://www.rubick.com/engineering-manager-vs-tech-lead/.

Cedric Chin, Goodhart’s Law Isn’t as Useful as You Might Think.

2023-04-07T00:00:00Z

Cedric Chin, “Goodhart’s Law Isn’t as Useful as You Might Think,” Commoncog, April 7, 2023, https://commoncog.com/goodharts-law-not-useful/.

Jade Rubick, Can This Ownership Exercise Improve How You Work with Others?

2023-04-07T00:00:00Z

Jade Rubick, “Can This Ownership Exercise Improve How You Work with Others?,” June 10, 2022, https://www.rubick.com/role-definition/.

Ryan Peterman, Why Engineers Need To Write.

2023-04-02T00:00:00Z

Ryan Peterman, “Why Engineers Need To Write,” March 24, 2023, https://www.developing.dev/p/why-engineers-need-to-write.

Angela Giuffrida, Carbonara Is a US Dish.

2023-03-29T00:00:00Z

Angela Giuffrida, “Italian Academic Cooks up Controversy with Claim Carbonara Is US Dish,” The Guardian, March 27, 2023, sec. World news, https://www.theguardian.com/world/2023/mar/27/italian-academic-cooks-up-controversy-with-claim-carbonara-is-us-dish.

Jade Rubick, Completed Staff Work.

2023-03-21T00:00:00Z

Jade Rubick, “Completed Staff Work,” July 27, 2016, https://www.rubick.com/completed-staff-work/.

Jade Rubick, Advice for New Directors.

2023-03-20T00:00:00Z

Jade Rubick, “Advice for New Directors,” February 20, 2023, https://www.rubick.com/advice-for-new-directors/.

Jade Rubick, A History of Mini-Ms.

2023-03-18T00:00:00Z

Jade Rubick, “A History of Mini-Ms,” February 23, 2023, https://www.rubick.com/history-of-mini-ms/.

Premise: History and context of EM groups.

Jade Rubick, Variations for Mini-M Management Support Groups.

2023-03-17T00:00:00Z

Jade Rubick, “Variations for Mini-M Management Support Groups,” February 10, 2023, https://www.rubick.com/mini-m-variations/.

Premise: Ideas on ways to adjust EM support group formats.

Jade Rubick, How to Implement Mini-M Support Groups.

2023-03-16T00:00:00Z

Jade Rubick, “How to Implement Mini-M Support Groups,” February 2, 2023, https://www.rubick.com/implementing-mini-m-support-groups/.

Premise: Guidance on implementing EM support groups.

Jade Rubick, Uplevel Your Managers with Mini-M Support Groups.

2023-03-15T00:00:00Z

Jade Rubick, “Uplevel Your Managers with Mini-M Support Groups,” January 28, 2023, https://www.rubick.com/mini-m-support-groups/.

Premise: Introduction to an EM support group format.

Jason Sachs, Why Amdahl’s Law is Misleading.

2023-03-07T00:00:00Z

Jason Sachs, “Zebras Hate You For No Reason: Why Amdahl’s Law Is Misleading in a World of Cats (And Maybe in Ours Too) - Jason Sachs,” February 27, 2017, https://www.embeddedrelated.com/showarticle/1033.php.

Eric Schwitzgebel, If Materialism Is True, the United States Is Probably Conscious.

2023-03-07T00:00:00Z

Eric Schwitzgebel, “If Materialism Is True, the United States Is Probably Conscious,” Philosophical Studies, no. 172 (2015): 1697–1721.

View a PDF of the article here.

KK Ottsen, They Are Preparing for War.

2023-03-07T00:00:00Z

KK Ottesen, “‘They Are Preparing for War’: An Expert on Civil Wars Discusses Where Political Extremists Are Taking This Country,” Washington Post, March 8, 2022, https://www.washingtonpost.com/magazine/2022/03/08/they-are-preparing-war-an-expert-civil-wars-discusses-where-political-extremists-are-taking-this-country/.

Vadim Kravcenko, Contracts You Should Never Sign.

2023-03-06T00:00:00Z

Vadim Kravcenko, “Contracts You Should Never Sign,” Vadim Kravcenko, January 27, 2023, https://vadimkravcenko.com/shorts/contracts-you-should-never-sign/.

Tim Carmody, Cistercian Numerals.

2023-03-06T00:00:00Z

Tim Carmody, “Cistercian Numerals,” kottke.org, January 30, 2023, https://kottke.org/23/01/cistercian-numerals.

Jade Rubick, Everyone Lies to Leaders.

2023-03-06T00:00:00Z

Jade Rubick, “Everyone Lies to Leaders,” June 1, 2021, https://www.rubick.com/everyone-lies-to-leaders/.

Animation Obsessive, How to Paint Like Hayao Miyazaki.

2023-03-06T00:00:00Z

Animation Obsessive, “How to Paint Like Hayao Miyazaki,” Substack newsletter, Animation Obsessive (blog), February 2, 2023, https://animationobsessive.substack.com/p/how-to-paint-like-hayao-miyazaki/.

Don Wentworth, Bashō by Hass.

2023-03-06T00:00:00Z

Don Wentworth, “Issa’s Untidy Hut: ‘Even in Kyoto … I Long for Kyoto:’ Bashō by Hass,” Issa’s Untidy Hut (blog), August 27, 2010, https://lilliputreview.blogspot.com/2010/08/even-in-kyoto-i-long-for-kyoto-basho-by.html.

Amos Wenger, Lies We Tell Ourselves to Keep Using Golang.

2023-03-06T00:00:00Z

Amos Wenger, “Lies We Tell Ourselves to Keep Using Golang,” fasterthanli.me, April 29, 2022, https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang.

Clive Thompson, How I Use RSS To ‘Rewild’ My Attention.

2023-03-01T00:00:00Z

Clive Thompson, “How I Use RSS To ‘Rewild’ My Attention,” Medium (blog), February 7, 2023, https://clivethompson.medium.com/how-i-use-rss-to-rewild-my-attention-7731267a40d8.

Philipp Hauer, Effective Remote Work.

2023-02-01T00:00:00Z

Philipp Hauer, “Lessons Learned from the Book ‘Effective Remote Work,’” August 25, 2022, https://phauer.com/2022/book-remote-work-lessons-learned/.

Kevin Bartley, ETL vs ELT.

2023-01-20T00:00:00Z

Kevin Bartley, “ETL vs ELT: Key Differences, Side-by-Side Comparisons, & Use Cases,” Rivery, June 27, 2022, https://rivery.io/blog/etl-vs-elt/.

Michael McIntyre, Goodhart’s Law.

2022-12-24T00:00:00Z

Michael McIntyre, “Goodhart’s Law,” October 17, 2001, https://www.damtp.cam.ac.uk/user/mem/papers/LHCE/goodhart.html.

Basel Al-Sheikh Hussein, The Sapir-Whorf Hypothesis Today.

2022-12-23T00:00:00Z

Basel Al-Sheikh Hussein, “The Sapir-Whorf Hypothesis Today,” Theory and Practice in Language Studies 2, no. 3 (March 1, 2012): 642–46, https://doi.org/10.4304/tpls.2.3.642-646.

Evan Andrews, Sword of Damocles.

2022-12-23T00:00:00Z

Evan Andrews, “What Was the Sword of Damocles?,” HISTORY, February 17, 2016, https://www.history.com/news/what-was-the-sword-of-damocles.

Nancy Friedman, Cunningham’s Law.

2022-12-21T00:00:00Z

Nancy Friedman, “Word of the Week: Cunningham’s Law,” Fritinancy, May 31, 2010, https://nancyfriedman.typepad.com/away_with_words/2010/05/word-of-the-week-cunninghams-law.html.

William Morgan, The Generation Ship Model of Software Development.

2022-12-21T00:00:00Z

William Morgan, “The Generation Ship Model of Software Development,” Medium (blog), July 10, 2014, https://medium.com/@wm/the-generation-ship-model-of-software-development-5ef89a74854b.

Robert Lucas, Econometric Policy Evaluation.

2022-11-16T00:00:00Z

Robert E. Lucas, “Econometric Policy Evaluation: A Critique,” Carnegie-Rochester Conference Series on Public Policy, no. 1 (1976): 19–46.

Douglas Hofstadter, Gödel, Escher, Bach.

2022-11-13T00:00:00Z

Douglas R. Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid, 20th anniversary ed (New York: Basic Books, 1999).

Lieberherr and Holland, Assuring Good Style for Object-Oriented Programs.

2022-11-13T00:00:00Z

K.J. Lieberherr and I.M. Holland, “Assuring Good Style for Object-Oriented Programs,” IEEE Software 6, no. 5 (September 1989): 38–48, https://doi.org/10.1109/52.35588.

Benoit Mandelbrot, How Long is the Cost of Britain?

2022-11-13T00:00:00Z

Benoit Mandelbrot, “How Long Is the Coast of Britain? Statistical Self-Similarity and Fractional Dimension,” Science 156, no. 3775 (May 5, 1967): 636–38, https://doi.org/10.1126/science.156.3775.636.

Doc Norton, Escape Velocity.

2022-11-09T00:00:00Z

Doc Norton, Escape Velocity: Better Metrics for Agile Teams (Leanpub, 2020), http://leanpub.com/escapevelocity.

Nathaniel Davis, UX Design Practice Verticals.

2022-11-06T00:00:00Z

Nathaniel Davis, “UX Design Practice Verticals,” December 4, 2011, https://methodbrain.com/2011/12/04/ux-design-practice-verticals-2/.

Aaron Gustafson, Understanding Progressive Enhancement.

2022-11-06T00:00:00Z

Aaron Gustafson, “Understanding Progressive Enhancement,” A List Apart, October 7, 2008, https://alistapart.com/article/understandingprogressiveenhancement/.

Seth Godin, Three Kinds of Forever.

2022-11-06T00:00:00Z

Seth Godin, “Three Kinds of ‘Forever,’” Seth’s Blog, May 17, 2019, https://seths.blog/2019/05/three-kinds-of-forever/.

Will Larson, Staff Engineer.

2022-11-05T00:00:00Z

Will Larson, Staff Engineer: Leadership beyond the Management Track, First edition (San Francisco? Will Larson, 2021).

Ben Gremillion, Mobile-First Responsive Design.

2022-11-05T00:00:00Z

Ben Gremillion, “A Hands-On Guide to Mobile-First Responsive Design,” Studio by UXPin (blog), October 1, 2015, https://www.uxpin.com/studio/blog/a-hands-on-guide-to-mobile-first-design/.

Shin Takahashi, The Manga Guide to Statistics.

2022-10-22T00:00:00Z

Shin Takahashi, The Manga Guide to Statistics (San Francisco: No Starch Press, 2009).

Jasper Polak, McKinsey Presentations.

2022-10-02T00:00:00Z

Jasper Polak, “McKinsey Makes $500,000+ on a Single Presentation. You Can Learn Their Simple Framework below (for Free):,” Tweet, Twitter, July 23, 2022, https://twitter.com/polak_jasper/status/1550816018158833667.

Trey Harris, The Case of the 500-Mile Email.

2022-10-01T00:00:00Z

Trey Harris, “The Case of the 500-Mile Email,” November 29, 2002, https://www.ibiblio.org/harris/500milemail.html.

George Dvorsky, What Is the Purpose of the Universe? Here Is One Possible Answer..

2022-10-01T00:00:00Z

George Dvorsky, “What Is the Purpose of the Universe? Here Is One Possible Answer.,” March 30, 2013, https://gizmodo.com/what-is-the-purpose-of-the-universe-here-is-one-possib-5981472.

Julia Evans, How to Spy on Your Programs with Strace.

2022-10-01T00:00:00Z

Julia Evans, “How to Spy on Your Programs with Strace” (Julia Evans, April 14, 2015), https://wizardzines.com/zines/strace/.

Ann Pietrangelo, Yerkes-Dodson Law.

2022-09-19T00:00:00Z

Ann Pietrangelo, “Yerkes-Dodson Law: How It Correlates to Stress, Anxiety, Performance,” Healthline, October 22, 2020, https://www.healthline.com/health/yerkes-dodson-law.

Will Larson, An Elegant Puzzle.

2022-08-11T00:00:00Z

William Larson, An Elegant Puzzle: Systems of Engineering Management, First edition (San Francisco, Calif.: Stripe Press / Stripe Matter Inc., 2019).

Robert Keidel, Seeing Organizational Patterns.

2022-07-30T00:00:00Z

Robert W Keidel, Seeing Organizational Patterns: A New Theory and Language of Organizational Design (Washington, D.C.: Beard Books, 2005).

Caleb Kruse, Seeing Blue.

2022-07-25T00:00:00Z

Caleb Kruse, “Focusing on Blue - 10 Projects,” accessed August 10, 2022, https://calebkruse.com/10-projects/seeing-blue/.

Premise: The human eye cannot see blue light in focus.

Larry Wall and Randal Schwartz, Programming Perl.

2022-07-03T00:00:00Z

Larry Wall and Randal L. Schwartz, Programming Perl, Minor correction, A Nutshell Handbook (Sebastopol, CA: O’Reilly & Associates, 1991).

“I Have Dubbed It The Baader-Meinhof Phenomenon”

2022-07-03T00:00:00Z

“Sunday Bulletin Board: I Have Dubbed It The Baader-Meinhof Phenomenon,” Twin Cities (blog), October 16, 1994, https://www.twincities.com/1994/10/16/baader-meinhof-phenomenon-sunday-bulletin-board/.

Ricial Dilig, Shokunin.

2022-07-03T00:00:00Z

Ricial Dilig, “Shokunin: The Mastery of One’s Profession,” Pop Japan, May 10, 2018, https://pop-japan.com/culture/shokunin-the-mastery-of-ones-profession/.

Russell Ackoff, From Data to Wisdom.

2022-06-28T00:00:00Z

Russell Ackoff, “From Data to Wisdom,” Journal of Applied Systems Analysis 16 (1989): 3–7.

Russell Ackoff, Continuous Improvement.

2022-06-28T00:00:00Z

Russell Ackoff, “Learning and Legacy of Dr. W. Edwards Deming - Continuous Improvement,” https://www.youtube.com/watch?v=OqEeIG8aPPk.

Will Larson, To Lead, You Have to Follow.

2022-06-27T00:00:00Z

Will Larson, “To Lead, You Have to Follow.,” May 25, 2020, https://lethain.com/to-lead-follow/.

Northcote Parkinson, Parkinson’s Law.

2022-06-25T00:00:00Z

C. Northcote Parkinson, “Parkinson’s Law,” The Economist, November 19, 1955, https://www.economist.com/news/1955/11/19/parkinsons-law.

Susanne and Andreas Bartel, The Official Guide to the Kanban Method.

2022-06-23T00:00:00Z

Susanne Bartel and Andreas Bartel, “The Official Guide to the Kanban Method,” February 2021.

Jay H. Bernstein, The Data-Information-Knowledge-Wisdom Hierarchy and Its Antithesis.

2022-06-22T00:00:00Z

Jay H. Bernstein, “The Data-Information-Knowledge-Wisdom Hierarchy and Its Antithesis,” Proceedings from North American Symposium on Knowledge Organization 2 (November 13, 2009): 68–75, https://doi.org/10.7152/NASKO.V2I1.12806.

Lyn Bond, Synthesizing.

2022-06-20T00:00:00Z

Lyn Bond, “Synthesising,” Text, February 16, 2012, https://emedia.rmit.edu.au/learninglab/content/synthesising-0.

Abigail Bassett, The Art of Kakeibo.

2022-06-19T00:00:00Z

Abigail Bassett, “The Art of Kakeibo, the Japanese Budgeting System That Could Change Your Financial Life,” Pocket (blog), February 3, 2020, https://getpocket.com/explore/item/the-art-of-kakeibo-the-japanese-budgeting-system-that-could-change-your-financial-life.

Arnold Zwicky, Why Are We so Illuded?

2022-06-18T00:00:00Z

Arnold M. Zwicky, “Why Are We so Illuded?,” September 2006, https://web.stanford.edu/~zwicky/LSA07illude.abst.pdf.

Will Storr, The Status Game.

2022-05-02T00:00:00Z

Will Storr, The Status Game: On Social Position and How We Use It, Unabridged (London: William Collins, 2021).

Oliver Burkeman, Four Thousand Weeks: Time Management for Mortals.

2022-05-02T00:00:00Z

Oliver Burkeman, Four Thousand Weeks: Time Management for Mortals, First (New York: Farrar, Straus and Giroux, 2021).

Allen Wilson, Playing the Zettelkasten RPG Through Arbitrary Constraints.

2022-04-23T00:00:00Z

Allen Wilson, “Playing the Zettelkasten RPG Through Arbitrary Constraints,” Zettelkasten Method (blog), April 8, 2022, https://zettelkasten.de/posts/playing-zettelkasten-rpg-through-arbitrary-constraints/.

Juvoni Beckford, Using Books to Navigate Life.

2022-04-23T00:00:00Z

Anne-Laure Le Cunff, “Interview: Using Books to Navigate Life with Juvoni Beckford,” Ness Labs (blog), November 3, 2020, https://nesslabs.com/juvoni-beckford-interview.

How, Exactly, Is Structure Supposed to Emerge?

2022-04-17T00:00:00Z

Imaginary-Unit-3267, “How, Exactly, Is Structure Supposed to ‘Emerge’?,” Reddit Comment, R/Zettelkasten, March 26, 2022, https://www.reddit.com/r/Zettelkasten/comments/todvoo/how_exactly_is_structure_supposed_to_emerge/i26u1hq/.

AoM #734 with Brandon Warmke, How Moral Grandstanding Is Ruining Our Public Discourse.

2022-01-09T00:00:00Z

Brett & Kate McKay, “Podcast #734: How Moral Grandstanding Is Ruining Our Public Discourse,” The Art of Manliness (blog), August 23, 2021, https://www.artofmanliness.com/character/behavior/moral-grandstanding-podcast/.

AoM #756 with Will Storr, How the Desire for Status Explains (Pretty Much) Everything.

2022-01-09T00:00:00Z

Brett & Kate McKay, “Podcast #756: How the Desire for Status Explains (Pretty Much) Everything,” The Art of Manliness (blog), November 15, 2021, https://www.artofmanliness.com/character/behavior/podcast-756-how-the-desire-for-status-explains-pretty-much-everything/.

Jakub Neander, How To Export PostgreSQL Query Output as CSV.

2022-01-09T00:00:00Z

Jakub Neander, “How To Export PostgreSQL Query Output as CSV,” zaiste.net, accessed January 5, 2022, https://zaiste.net/databases/postgresql/howtos/howto-export-postgresql-query-output-csv/.

Donella Meadows, Thinking in Systems.

2022-01-03T00:00:00Z

Donella H. Meadows and Diana Wright, Thinking in Systems: A Primer (White River Junction, Vt: Chelsea Green Pub, 2008).

Premise: Changing a system requires understanding the interactions of its components to identify the leverage points by which change is possible.

Society of GK Chesterton, “Taking a Fence Down”.

2021-12-30T00:00:00Z

“Taking a Fence Down,” Society of Gilbert Keith Chesterton (blog), April 30, 2012, https://www.chesterton.org/taking-a-fence-down/.

AoM #762 with Michael Hyatt, Prepare Now to Have Your Best New Year Ever.

2021-12-21T00:00:00Z

Brett & Kate McKay, “Podcast #762: Prepare Now to Have Your Best Year Ever,” The Art of Manliness (blog), December 8, 2021, https://www.artofmanliness.com/character/advice/your-best-year-ever/.

David Gray, Liminal Thinking.

2021-12-20T00:00:00Z

David Gray, Liminal Thinking: Create the Change You Want by Changing the Way You Think, 2016.

Premise: Beliefs shape how we experience the world and they must be changed to produce change.

Ron Jeffries, Story Points Revisited.

2021-12-11T00:00:00Z

Ron Jeffries, “Story Points Revisited,” May 23, 2019, https://ronjeffries.com/articles/019-01ff/story-points/Index.html.

Premise: Story points had just meant “ideal days”, but today are used for all manner of inappropriate purposes.

Camille Fournier, The Manager’s Path.

2021-12-05T00:00:00Z

Camille Fournier, The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change, ed. Laurel Ruma, First Edition (Beijing: O’Reilly, 2017).

Premise: A technical management career has many escalating roles and areas of responsibility.

Kurzgesagt, The Origin of Consciousness.

2021-12-05T00:00:00Z

Kurzgesagt, The Origin of Consciousness – How Unaware Things Became Aware, 2019, https://www.youtube.com/watch?v=H6u0VBqNBQ8.

Premise: Consciousness evolved from the need to find food.

Sarah Drasner, Mistakes I’ve Made as an Engineering Manager.

2021-11-28T00:00:00Z

Sarah Drasner, “Mistakes I’ve Made as an Engineering Manager,” CSS-Tricks, February 18, 2021, https://css-tricks.com/mistakes-ive-made-as-an-engineering-manager/.

Premise: A review of some common mistakes that engineering managers make and what to do instead.

David Allen, Getting Things Done.

2021-11-07T00:00:00Z

David Allen, Getting Things Done: The Art of Stress-Free Productivity, Revised edition (New York City: Penguin Books, 2015).

Premise: Get things done by writing them into small tasks 0G0.

Christopher Sirk, The History of Kaizen.

2021-11-01T00:00:00Z

Christopher Sirk, “The History of Kaizen,” CRM.org, August 5, 2020, https://crm.org/articles/the-history-of-kaizen.

Premise: Kaizen started in the US pre-WWII before saving Toyota in Japan and then coming back 0M2A.

Sarah Drasner, The Importance of Career Laddering.

2021-10-27T00:00:00Z

Sarah Drasner, “The Importance of Career Laddering,” CSS-Tricks, April 15, 2021, https://css-tricks.com/the-importance-of-career-laddering/.

Premise: Discussing career objectives helps engineers own their career trajectory.

Elizabeth Saunders, 6 Causes of Burnout.

2021-10-27T00:00:00Z

Elizabeth Grace Saunders, “6 Causes of Burnout, and How to Avoid Them,” Harvard Business Review, July 5, 2019, https://hbr.org/2019/07/6-causes-of-burnout-and-how-to-avoid-them.

Premise: Burnout can be traced back to specific factors, and those factors can be mitigated.

Mile Oliver, Better Short Term Goals for New Engineering Hires.

2021-10-27T00:00:00Z

Mike Oliver, “Better Short Term Goals for New Engineering Hires | by Mike Oliver | ASICS Digital | Medium,” December 8, 2017, https://medium.com/runkeeper-everyone-every-run/better-short-term-goals-for-new-engineering-hires-9a180f1ebc0f.

Martin Fowler, What do you mean by ”event-driven”?

2021-10-27T00:00:00Z

Martin Fowler, “What Do You Mean by ‘Event-Driven’?,” martinfowler.com, 2017, https://martinfowler.com/articles/201701-event-driven.html.

Premise: Evented ecosystem paradigms tend to fall into one of three noteworthy types.

Hal Elrod, The Miracle Morning.

2021-10-20T00:00:00Z

Hal Elrod, The Miracle Morning: The Not-so-Obvious Secret Guaranteed to Transform Your Life before 8AM, 2018.

Premise: The way one starts their morning fundamentally changes their outlook on life 6F.

Whitson Gordon, How to Dual Boot and Virtualize the Same Partition on Your Computer.

2021-09-23T00:00:00Z

Whitson Gordon, “How to Dual Boot and Virtualize the Same Partition on Your Computer,” Lifehacker, May 7, 2013, https://lifehacker.com/how-to-dual-boot-and-virtualize-the-same-partition-on-y-493223329.

Bill Burnett & Dave Evans, Designing Your Life.

2021-08-23T00:00:00Z

William Burnett and David J. Evans, Designing Your Life: How to Build a Well-Lived, Joyful Life, First edition (New York: Alfred A. Knopf, 2016).

Premise: Design thinking can uncover better ways of living. 6C

Ken Schwaber & Jeff Sutherland, The Scrum Guide.

2021-08-13T00:00:00Z

Ken Schwaber and Jeff Sutherland, The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, 2020, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf.

Premise: Empiricism can help a team create value for stakeholders with increasing speed while reducing waste.

Doanh Do, What Is Continuous Improvement (Kaizen)?

2021-08-12T00:00:00Z

Doanh Do, “What Is Continuous Improvement (Kaizen)?,” The Lean Way, August 5, 2017, https://theleanway.net/what-is-continuous-improvement.

Premise: Kaizen is action and analysis to reduce waste and improve operations 0M2.

Jeff Sutherland, Scrum.

2021-08-12T00:00:00Z

Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, First Edition (New York: Crown Business, 2014).

Premise: Any team can reduce waste and deliver the most impactful work with the application of scrum.

Willem-Jan Ageling, 7 Reasons Not to Use Scrum.

2021-08-11T00:00:00Z

Willem-Jan Ageling, “7 Reasons Not to Use Scrum,” Serious Scrum (blog), October 29, 2019, https://medium.com/serious-scrum/7-reasons-not-to-use-scrum-480530e3e00a.

Simon Sinek, Most Leaders Don’t Even Know the Game They’re In.

2021-08-05T00:00:00Z

Simon Sinek, Most Leaders Don’t Even Know the Game They’re In | Simon Sinek, 2016, https://www.youtube.com/watch?v=RyTQ5-SQYTo&ab_channel=SimonSinek.

Premise: Leadership ought to focus on ongoing improvement, not try to win against someone else.

Thierry de Pauw, Shades of Conway’s Law.

2021-07-31T00:00:00Z

Thierry de Pauw, “Shades of Conway’s Law,” ThinkingLabs:: Thierry de Pauw, May 3, 2021, https://thinkinglabs.io/articles/2021/05/07/shades-of-conways-law.html.

Nir Eyal, Hooked.

2021-07-23T00:00:00Z

Nir Eyal, Hooked: How to Build Habit-Forming Products (New York, New York: Portfolio/Penguin, 2014).

Premise: Understanding the psychology of motivation is instrumental in building high-engagement products.

Dan Pink, The Surprising Truth about What Motivates Us.

2021-07-23T00:00:00Z

Dan Pink, RSA ANIMATE: Drive: The Surprising Truth about What Motivates Us, 2010, https://www.youtube.com/watch?v=u6XAPnuFjJc.

Premise: People are motivated by mastery, autonomy, and purpose; compensation only motivates up to the point where money is no longer a major issue.

Robert Burton, Where Science and Story Meet.

2021-07-21T00:00:00Z

M. D. Robert Burton, “Where Science and Story Meet,” Nautilus, April 22, 2013, http://nautil.us/issue/0/the-story-of-nautilus/where-science-and-story-meet.

Jeremiah Lee, Spotify’s Failed #SquadGoals.

2021-07-21T00:00:00Z

Jeremiah Lee, “Spotify’s Failed #SquadGoals,” April 19, 2020, https://www.jeremiahlee.com/posts/failed-squad-goals/.

Premise: The Spotify Model optimized for autonomy, which is not what the firm needed, so the approach failed 4B1H.

Brené Brown, Dare to Lead.

2021-05-02T00:00:00Z

Brené Brown, Dare to Lead: Brave Work, Tough Conversations, Whole Hearts (New York: Random House, 2018).

Premise: Vulnerability is necessary to lead teams with clarity and trust 4B6C.

Tiago Forte, Building a Second Brain Podcast.

2021-05-02T00:00:00Z

Tiago Forte, “The Building a Second Brain Podcast,” accessed July 24, 2021, https://open.spotify.com/show/40O0Lbp5ockSt0qSogo6q1?si=8Xuq_oxxQp2UYvqIp6WDMA&dl_branch=1.

Premise: Collecting and distilling every day knowledge work inputs enables faster and more comprehensive creative output.

Dustin Gorski, When to Use Scrum?

2021-05-02T00:00:00Z

Dustin Moris Gorski, “When to Use Scrum? Waterfall vs. Scrum vs. Kanban vs. Scrumban - Dusted Codes,” Dusted Codes (blog), November 8, 2015, https://dusted.codes/when-to-use-scrum-waterfall-vs-scrum-vs-kanban-vs-scrumban.

Premise: Each work management methodology has circumstances where it’s optimized for the problems and needs—scrum is not the end-all-be-all of work management.

Patrick Lencioni, The Advantage.

2021-05-02T00:00:00Z

Patrick Lencioni, The Advantage: Why Organizational Health Trumps Everything Else in Business, 1st ed (San Francisco: Jossey-Bass, 2012).

Premise: Organizational health is the most important focus of a company 4B3.

Nick deWilde, The Learning Loop of Knowledge Work.

2021-05-02T00:00:00Z

Nick deWilde, “The Learning Loop of Knowledge Work,” 2021, https://junglegym.substack.com/p/learning-loop-of-knowledge-work.

Premise: Organizations can actively foster learning 0C1.

David Rock, Your Brain at Work.

2021-05-02T00:00:00Z

David Rock, Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long, 1st ed (New York: Harper Business, 2009).

Premise: Understanding how the brain works allows one to wield it more effectively 0G3.

Elon Musk’s Loop - It’s Bad, Folks.

2021-04-16T00:00:00Z

@donoteat01, “Elon Musk’s Loop - It’s Bad, Folks,” 2019, https://www.youtube.com/watch?v=4dn6ZVpJLxs&ab_channel=donoteat01.

Gary Neilson et al., 10 Principles of Organization Design.

2021-03-23T00:00:00Z

Gary Neilson, Jaime Estupiñán, and Bhushan Sethi, “10 Principles of Organization Design,” strategy+business, 2015, https://www.strategy-business.com/article/00318?gko=31dee.

Premise: Aligning an org with strategy happens with several variables.

Robert Keidel, The Three Reasons to Hold a Meeting.

2021-03-21T00:00:00Z

Robert Keidel, “The Three Reasons to Hold a Meeting,” Wharton Magazine (blog), March 23, 2017, https://magazine.wharton.upenn.edu/digital/the-three-reasons-to-hold-a-meeting/.

Karla Segura Chavarría, Will Betelgeuse Go Hypernova?

2021-03-19T00:00:00Z

Karla Segura Chavarría, “Space and Earth Science: Will the Giant Star Betelgeuse Go HyperNova?,” Space and Earth Science (blog), 2011-08-29, http://spaceandearthsciencearticles.blogspot.com/2011/08/will-giant-star-betelgeuse-go-hypernova.html.

Merve Emre, Secret History Of Myers-Briggs.

2021-03-19T00:00:00Z

Merve Emre, “Uncovering The Secret History Of Myers-Briggs,” Digg, October 1, 2015, https://digg.com/2015/myers-briggs-secret-history.

What it’s like inside of a black hole.

2021-03-19T00:00:00Z

RobotRollCall, “Reddit: What It’s like inside of a Black Hole,” Reddit Comment, R/Askscience, January 15, 2011, https://www.reddit.com/r/askscience/comments/f1lgu/what_would_happen_if_the_event_horizons_of_two/c1cuiyw/.

Rouan Wilsenach, DevOpsCulture.

2021-03-19T00:00:00Z

Rouan Wilsenach, “Bliki: DevOpsCulture,” martinfowler.com, July 9, 2015, https://martinfowler.com/bliki/DevOpsCulture.html.

Martin Fowler, MicroservicePrerequisites.

2021-03-19T00:00:00Z

Martin Fowler, “Bliki: MicroservicePrerequisites,” martinfowler.com, August 28, 2014, https://martinfowler.com/bliki/MicroservicePrerequisites.html.

Mark Forster, Noguchi Filing System.

2021-03-09T00:00:00Z

Mark Forster, “Noguchi Filing System,” June 9, 2008, http://markforster.squarespace.com/blog/2008/6/9/noguchi-filing-system.html.

Watts & Hertvik, Technical Debt: The Ultimate Guide.

2021-01-15T00:00:00Z

Stephen Watts and Joe Hertvik, “Technical Debt: The Ultimate Guide – BMC Blogs,” July 30, 2020, https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/.

Premise: Defining and managing technical debt.

Steven Rogelberg, The Surprising Science of Meetings.

2021-01-09T00:00:00Z

Steven G. Rogelberg, The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance (New York: Oxford University Press, 2019).

Premise: Meetings can be very effective with the right approaches.

Scaled Agile Framework, WSJF.

2021-01-08T00:00:00Z

“WSJF,” Scaled Agile Framework (blog), accessed January 7, 2021, https://www.scaledagileframework.com/wsjf/.

Greg McKeown, Essentialism.

2021-01-03T00:00:00Z

Greg McKeown, Essentialism: The Disciplined Pursuit of Less, First Edition (New York: Crown Business, 2014).

Premise: Focus only on the disproportionately valuable options 0G2.

Sascha Fast, The Barbell Method of Reading.

2020-12-31T00:00:00Z

Sascha Fast, “The Barbell Method of Reading,” Zettelkasten Method, 2018, https://www.zettelkasten.de/posts/barbell-method-reading/.

Sönke Ahrens, How to Take Smart Notes.

2020-12-28T00:00:00Z

Sönke Ahrens, How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking: For Students, Academics and Nonfiction Book Writers (North Charleston, SC: CreateSpace, 2017).

Premise: Writing is thinking 0G1.

Jon-Paul Bruce, Milliseconds Make Millions.

2020-03-24T00:00:00Z

Jon-Paul Bruce, “Milliseconds Make Millions,” Deloitte Digital, March 24, 2020, https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Consulting/Milliseconds_Make_Millions_report.pdf.

Annie Duke, Thinking in Bets.

2017-05-05T00:00:00Z

Annie Duke, Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts (New York: Portfolio/Penguin, 2018).