Blog Entries

DRAFT We Tried Shape Up

A recent client I worked with was in the midst of implementing Shape Up as a software development lifecycle framework internally; getting my hands dirty with the process was much of my motivation for joining. Unfortunately, the engagement didn’t span a full six-week cycle, but it gave me a taste of experiencing firsthand what was previously just exciting theory.

My impressions are mostly positive, but with a lot more informed depth.

jxpx777 12:55 PM Discussion in the call about how Shape Up might not be appropriate when teams have a significant presence of junior developers made me think about the Dreyfus model of skill acquisition and how some SDLC approaches might fall at a different place on this continuum. Scrum or similar might be more appropriate for teams with novices and advanced beginners whereas something like Shape Up would require folks further up with folks that are mostly competent or above. https://testdouble.slack.com/archives/C02V47ES494/p1656701712107889

Aaron Gough 1 month ago We have tried pushing back a little already in terms of adhering to Shape Up more closely, and haven’t gotten much traction. There are lots of issues that stand in the way of them actually getting closer to shape up: There are not enough product people to really have close ties between the build team and pitch owner, they get swamped with questions easily and have to disengage. Our pitch owner last cycle was managing 6 pitches! There are not enough designers to have one per build team, so design work including wireframes and figma mockups is done before the cycle SOC2 compliance requires that ALL code changes be tied to a ticket detailing the reasons why the code change is needed https://testdouble.slack.com/archives/C02V47ES494/p1654530766680889?thread_ts=1654524649.195849&cid=C02V47ES494

jeremy 30 days ago Agree with a lot that has been said. I don’t think it will hurt to nudge them toward “better” Shape Up practices, but it’s definitely not a one-size-fits-all thing. I think the cycle milestones idea can be helpful for example, but isn’t the one way to do it™. At the heart of it is product planning and development and encouraging small scoped, core business valuable work where teams can be autonomous to make the right decisions and not feel pressured by leadership to sacrifice quality or cooldown time to get more scopes shipped.

Also, I don’t think strict adherence will solve the problem anyway. Root issues point toward things like poor feedback loops between product and engineering, lack of cohesion among product and technical leaders, and likely lack of trust that build teams will make the best decisions. https://testdouble.slack.com/archives/C02V47ES494/p1654566957548609?thread_ts=1654524649.195849&cid=C02V47ES494

(me) Process takeaway on Shape Up in my limited experience so far: might not be sufficiently supportive for juniors, but if you give it to a senior-ish team with prebuilt mutual trust, they can fly https://testdouble.slack.com/archives/D02LBHT49DE/p1656810198470429

A client I worked with was in the midst of implementing Shape Up as a software development lifecycle framework; getting my hands dirty with the process was much of my motivation for joining. Unfortunately, the engagement didn’t span even a full six-week cycle, but it gave me a taste of experiencing firsthand what was previously just exciting theory.

For the unfamiliar, Shape Up is a set of tools for going from a problem definition through delivery, similar in its purpose to Scrum, but utterly different in its framing and implementation.

Process takeaway on Shape Up in my limited experience so far: might not be sufficiently supportive for juniors, but if you give it to a senior-ish team with prebuilt mutual trust, they can fly

TODO Consultant’s toolbox: solution-focused question sequences

• on a scale of 1 to 10, where 10 is exactly where you want to be and 0 is the worst you can imagine, where do things stand with you now?
• why isn’t it worse? what are you doing that keeps you at (level they’re at)?
• between now and (future mark), where do you want to go?
• how will you know when you get there? what will it feel like?
• what’s one single thing you can do between now and (X) that will move things in that direction?

DRAFT Resetting after a system failure

First in a mini-series on systems and personal failure and recovery.

Okay, so something fell over: your server, your process, your sense of self.

TODO What’s your threshold for making an exception?

DRAFT

I asked Kagi AI:

how can I use elixir nx and axon utilizing my amd radeon 7900 xt card? the host system runs linux.

Here we go:

To utilize your AMD Radeon 7900 XT card with Elixir Nx and Axon on a Linux system, follow these steps:

1. Install Elixir and Mix:

   • Ensure you have Elixir installed on your system. You can install it via your package manager or by following the instructions on the Elixir website.
   • Mix is Elixir’s build tool and comes bundled with Elixir.

2. Set Up a New Elixir Project:

   • Create a new Elixir project using Mix: ```sh mix new my_app cd my_app ```

3. Add Dependencies:

   • Edit the ```mix.exs``` file to include Nx and Axon as dependencies. Add the following lines to the ```deps``` function: ```elixir defp deps do [ {:nx, “~> 0.2.0”}, {:axon, “~> 0.1.0”} ] end ```

4. Install Dependencies:

   • Fetch and install the dependencies by running: ```sh mix deps.get ```

5. Configure AMD GPU Support:

   • Currently, Nx and Axon primarily support NVIDIA GPUs through CUDA. However, you can still use your AMD GPU for general computation tasks that do not specifically require CUDA. Ensure you have the necessary drivers and OpenCL support installed on your system.
   • Install the AMD GPU drivers and OpenCL support: ```sh sudo apt update sudo apt install amdgpu-pro sudo apt install opencl-amdgpu-pro ```

6. Write Your Code:

   • You can now start writing your machine learning code using Nx and Axon. Here’s a simple example to get you started: ```elixir defmodule MyApp do import Nx.Defn

     defn simple_nn(x) do x

     > Nx.dot(Nx.tensor([[0.5], [0.5]]))
     > Nx.add(1.0)

     end

     def run do input = Nx.tensor([[1.0, 2.0]]) IO.inspect(simple_nn(input)) end end

     MyApp.run() ```

7. Run Your Application:

   • Execute your Elixir application: ```sh mix run ```

By following these steps, you can make use of Elixir Nx and Axon on your Linux system with an AMD Radeon 7900 XT GPU. Note that while AMD GPUs are not directly supported for CUDA-based operations, they can still be used for general computations and OpenCL tasks【1】【2】.

[1] elixir-nx/axon: Nx-powered Neural Networks - GitHub [2] How to Create Neural Network in Elixir Using Nx and Axon | Curiosum

Well. That’s…_something_. But in the end, it’s a bit disappointing, no? Yeah, CUDA works without too much work; that’s no surprise. But other stuff exists, and is (semi)officially supported! Hell, I’ve got a packaged version of ollama running with ROCm on my local without even needing to modify things on my own; it just builds (usually) and works (till I fill the VRAM with inappropriately huge models).

Elixir Axon refers to ROCm under the hood when pointing to XLA and while there may be Some Dragons it sure looks like it should at least try to work!

I’ve got a nice AMD card kicking around (a 7900 XT) with 20GiB of VRAM and would love to do something with it, and ROCm has been supported on it for months. How far along can we get?

Start at the base: Elixir XLA

Elixir NX XLA wraps up precompiled XLA binaries in an Elixir-friendly library. From OpenXLA:

XLA (Accelerated Linear Algebra) is an open-source machine learning (ML) compiler for GPUs, CPUs, and ML accelerators.

The XLA compiler takes models from popular ML frameworks such as PyTorch, TensorFlow, and JAX, and optimizes them for high-performance execution across different hardware platforms including GPUs, CPUs, and ML accelerators. (https://github.com/openxla/xla)

And from Elixir NX XLA:

#### `XLA_TARGET`

The default value is usually `cpu`, which implies the final the binary supports targeting only the host CPU. If a matching CUDA version is detected, the target is set to CUDA accordingly.

Value	Target environment
—	—
cpu
tpu	libtpu
cuda12	CUDA 12.1+, cuDNN 8.9+ and < 9
cuda	CUDA x.y, cuDNN (building from source only)
rocm	ROCm (building from source only)

To use XLA with NVidia GPU you need CUDA and cuDNN compatible with your GPU drivers. See the installation instructions and the cuDNN support matrix for version compatibility. To use precompiled XLA binaries specify a target matching your CUDA version (like `cuda12`). You can find your CUDA version by running `nvcc –version` (note that `nvidia-smi` shows the highest supported CUDA version, not the installed one). When building from source it’s enough to specify `cuda` as the target.

Note that all the precompiled binaries assume glibc 2.31 or newer.

##### Notes for ROCm

For GPU support, we primarily rely on CUDA, because of the popularity and availability in the cloud. In case you use ROCm and it does not work, please open up an issue and we will be happy to help.

In addition to building in a local environment, you can build the ROCm binary using the Docker-based scripts in `builds/`. You may want to adjust the ROCm version in `rocm.Dockerfile` accordingly.

When you encounter errors at runtime, you may want to set `ROCM_PATH=/opt/rocm-5.7.0` and `LD_LIBRARY_PATH="/opt/rocm-5.7.0/lib"` (with your respective version). For further issues, feel free to open an issue.

Okay. So we’ll need to build Elixir NX XLA from source. Cloning the repo (I did so at =e704d594548bbe953b40929ae5d26ce158082ae6=`) and save those needed environment variables somewhere handy:

# File: /home/dylan/dev/elixir-nx-rocm/xla/.env.sh
export XLA_TARGET=rocm
export XLA_BUILD=true

As for dependencies,

You will need the following installed in your system for the compilation:

Git for fetching XLA source Bazel v6.5.0 for compiling XLA Python3 with NumPy installed for compiling XLA

I’m on Manjaro Linux on this host, which is basically Arch with an installer. Git’s always present; python3-numpy lives in extra, so this is just package management: yay numpy does the trick for me. The Elixir XLA docs nudge us to use asdf-vm to manage Bazel’s version, which is fine by me:

asdf plugin-add bazel
asdf install bazel 6.5.0
asdf global bazel 6.5.0

I’m not gonna get any deeper into system package management here.

Cleaning things up

XLA_BUILD Defaults to false. If true the binary is built locally, which may be intended if no precompiled binary is available for your target environment. Once set, you must run mix deps.clean xla –build explicitly to force XLA to recompile. Building has a number of dependencies, see Building from source below. (https://github.com/elixir-nx/xla/blob/main/README.md#xla_build)

The first roll of the dice: with deps installed & the right values in our environment, what’s that call to mix deps.clean xla --build do?

❯ mix deps.clean xla –build 2>&1 | tee mix-output

• Cleaning xla

warning: the dependency xla is not present in the build directory

Ha! Well, so long as we haven’t already tired a build, nothing to clean up. Alright, let’s make this thing.

❯ make | tee make-output.txt
mkdir -p /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a && \
  cp -r extension/patches /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a && \
        cd /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a && \
        git init && \
        git remote add origin https://github.com/openxla/xla.git && \
        git fetch --depth 1 origin fd58925adee147d38c25a085354e15427a12d00a && \
        git checkout FETCH_HEAD && \
        bash patches/apply.sh && \
        rm /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a/.bazelversion
Initialized empty Git repository in /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a/.git/
remote: Enumerating objects: 5349, done.
remote: Counting objects: 100% (5349/5349), done.
remote: Compressing objects: 100% (4839/4839), done.
remote: Total 5349 (delta 1168), reused 1419 (delta 464), pack-reused 0
Receiving objects: 100% (5349/5349), 11.61 MiB | 637.00 KiB/s, done.
Resolving deltas: 100% (1168/1168), done.
From https://github.com/openxla/xla
 * branch            fd58925adee147d38c25a085354e15427a12d00a -> FETCH_HEAD
Note: switching to 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at fd58925 Introduce MakeConstantWithShape in hlo_creation_util file.
+++ dirname patches/apply.sh
++ cd patches
++ pwd
+ dir=/home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a/patches
++ uname -m
+ arch=x86_64
+ [[ x86_64 == \a\a\r\c\h\6\4 ]]

That only took about 21 seconds, which seems…too short? Let’s try `mix deps.clean` again…nah, doesn’t do anything.

So, the presence of Makefile is a little misleading for this particular engineer. I tend to assume that its existence means we’re using make to wrap the functionality of whatever other tooling we’ve got in place, but in this case Makefile is here to manage the non-Elixir parts of the project & gets invoked by mix.

Let’s go through mix.

❯ mix deps.get
Resolving Hex dependencies...
Resolution completed in 0.011s
Unchanged:
  earmark_parser 1.4.33
  elixir_make 0.6.2
  ex_doc 0.30.3
  makeup 1.1.0
  makeup_elixir 0.16.1
  makeup_erlang 0.1.2
  nimble_parsec 1.3.1
* Getting elixir_make (Hex package)
* Getting ex_doc (Hex package)
* Getting earmark_parser (Hex package)
* Getting makeup_elixir (Hex package)
* Getting makeup_erlang (Hex package)
* Getting makeup (Hex package)
* Getting nimble_parsec (Hex package)

mix compile:

[0 / 1,370] [Prepa] BazelWorkspaceStatusAction stable-status.txt ... (12 actions, 3 running)
ERROR: /home/dylan/.cache/bazel/_bazel_dylan/800dbc0c7dee67ed9cf6e19793e3dfe7/external/com_google_protobuf/BUILD.bazel:27:11: Compiling src/google/protobuf/any_lite.cc [for tool] failed: (Exit 126): crosstool_wrapper_driver_is_not_gcc failed: error executing command (from target @com_google_protobuf//:protobuf_lite) external/local_config_rocm/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer ... (remaining 41 arguments skipped)
No version is set for command python
Consider adding one of the following versions in your config file at
python 3.11.1
python 3.8.1
python 3.8.8
ERROR: /home/dylan/.cache/bazel/_bazel_dylan/800dbc0c7dee67ed9cf6e19793e3dfe7/external/double_conversion/BUILD:9:11: Compiling double-conversion/strtod.cc failed: (Exit 126): crosstool_wrapper_driver_is_not_gcc failed: error executing command (from target @double_conversion//:double-conversion) external/local_config_rocm/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer ... (remaining 44 arguments skipped)
No version is set for command python
Consider adding one of the following versions in your config file at
python 3.11.1
python 3.8.1
python 3.8.8
Target //xla/extension:xla_extension failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 27.423s, Critical Path: 0.19s
INFO: 320 processes: 314 internal, 6 local.
FAILED: Build did NOT complete successfully
make: *** [Makefile:26: /home/dylan/.cache/xla/0.7.1/cache/build/xla_extension-x86_64-linux-gnu-rocm.tar.gz] Error 1
** (Mix) Could not compile with "make" (exit status: 2).
You need to have gcc and make installed. If you are using
Ubuntu or any other Debian-based system, install the packages
"build-essential". Also install "erlang-dev" package if not
included in your Erlang/OTP version. If you're on Fedora, run
"dnf group install 'Development Tools'".

Yeah! Errors! Now we’re getting somewhere. If this worked right out of the box, the lack of it being packaged already would just make me sad.

I installed NumPy system-wide with my package manager, but typically I’d manage it with asdf-vm, which Elixir Nx’s docs describe some workarounds for. Let’s start off by explicitly falling back to system python with asdf local python system; asdf reshim…which doesn’t seem to have an effect on the output. Right! Let’s follow Elixir NX’s docs on this and go for the direnv suggestion:

(snip)
  INFO: Found applicable config definition build:dynamic_kernels in file /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a/.bazelrc: --define=dynamic_loaded_kernels=true --copt=-DAUTOLOAD_DYNAMIC_KERNELS
  Loading:
  DEBUG: /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a/third_party/repo.bzl:132:14:
  Warning: skipping import of repository 'llvm-raw' because it already exists.
  DEBUG: /home/dylan/.cache/bazel/_bazel_dylan/800dbc0c7dee67ed9cf6e19793e3dfe7/external/tsl/third_party/repo.bzl:132:14:
  Warning: skipping import of repository 'nvtx_archive' because it already exists.
  DEBUG: /home/dylan/.cache/xla_extension/xla-fd58925adee147d38c25a085354e15427a12d00a/third_party/repo.bzl:132:14:
  Warning: skipping import of repository 'jsoncpp_git' because it already exists.
  Loading:
  Loading: 0 packages loaded
  Analyzing: target //xla/extension:xla_extension (1 packages loaded, 0 targets configured)
  Analyzing: target //xla/extension:xla_extension (167 packages loaded, 12392 targets configured)
  INFO: Analyzed target //xla/extension:xla_extension (172 packages loaded, 16026 targets configured).
  INFO: Found 1 target...
  [47 / 3,968] [Prepa] BazelWorkspaceStatusAction stable-status.txt
  ERROR: /home/dylan/.cache/bazel/_bazel_dylan/800dbc0c7dee67ed9cf6e19793e3dfe7/external/llvm-project/llvm/BUILD.bazel:218:11: Compiling llvm/lib/Demangle/RustDemangle.cpp [for tool] failed: (Exit 126): crosstool_wrapper_driver_is_not_gcc failed: error executing command (from target @llvm-project//llvm:Demangle) external/local_config_rocm/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer ... (remaining 77 arguments skipped)
  No version is set for command python
  Consider adding one of the following versions in your config file at
  python 3.11.1
  python 3.8.1
  python 3.8.8
  ERROR: /home/dylan/.cache/bazel/_bazel_dylan/800dbc0c7dee67ed9cf6e19793e3dfe7/external/com_google_protobuf/BUILD.bazel:27:11: Compiling src/google/protobuf/arenastring.cc [for tool] failed: (Exit 126): crosstool_wrapper_driver_is_not_gcc failed: error executing command (from target @com_google_protobuf//:protobuf_lite) external/local_config_rocm/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer ... (remaining 41 arguments skipped)
  No version is set for command python
  Consider adding one of the following versions in your config file at
  python 3.11.1
  python 3.8.1
  python 3.8.8
  ERROR: /home/dylan/.cache/bazel/_bazel_dylan/800dbc0c7dee67ed9cf6e19793e3dfe7/external/com_google_protobuf/BUILD.bazel:27:11: Compiling src/google/protobuf/arena.cc [for tool] failed: (Exit 126): crosstool_wrapper_driver_is_not_gcc failed: error executing command (from target @com_google_protobuf//:protobuf_lite) external/local_config_rocm/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer ... (remaining 41 arguments skipped)
  No version is set for command python
  Consider adding one of the following versions in your config file at
  python 3.11.1
  python 3.8.1
  python 3.8.8
  Target //xla/extension:xla_extension failed to build
  Use --verbose_failures to see the command lines of failed build steps.
  INFO: Elapsed time: 3.682s, Critical Path: 0.24s
  INFO: 33 processes: 33 internal.
  FAILED: Build did NOT complete successfully
  make: *** [Makefile:26: /home/dylan/.cache/xla/0.7.1/cache/build/xla_extension-x86_64-linux-gnu-rocm.tar.gz] Error 1
  ** (Mix) Could not compile with "make" (exit status: 2).
  You need to have gcc and make installed. If you are using
  Ubuntu or any other Debian-based system, install the packages
  "build-essential". Also install "erlang-dev" package if not
  included in your Erlang/OTP version. If you're on Fedora, run
  "dnf group install 'Development Tools'".

Hm. No real effect. Guess that’s not too surprising–I’d followed the explicit instructions to install direnv with asdf, but as a fairly heavy direnv user already, had previously had it installed at the system package level.

Instead of this route–Let’s try to clear out that GCC issue first; having two major base-language issues at once is potentially confounding. Elixir NX XLA says:

You may have issues with newer and older versions of GCC. XLA builds are known to work with GCC versions between 7.5 and 9.3. If your system uses a newer GCC version, you can install an older version and tell Bazel to use it with export CC=/path/to/gcc-{version} where version is the GCC version you installed. (https://github.com/elixir-nx/xla/tree/main?tab=readme-ov-file#gcc)

My GCC is gcc (GCC) 14.1.1 20240522 which is way outside that range. Looks like we’re diving into installing a parallel, older compile toolchain from AUR. Exciting!

❯ yay gcc8
3 aur/gcc8-fortran 8.5.0-2 (+9 0.05)
    Fortran front-end for GCC (8.x.x)
2 aur/gcc8-libs 8.5.0-2 (+9 0.05)
    Runtime libraries shipped by GCC (8.x.x)
1 aur/gcc8 8.5.0-2 (+9 0.05)
    The GNU Compiler Collection - C and C++ frontends (8.x.x)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 1 2

…and let it fly!

(GCC8 instead of 9 because the 9.x offered in AUR is 9.5 [> 9.3] and I definitely don’t want to fight this fight twice)

==> Sources are ready.
==> Making package: gcc8 8.5.0-2 (Wed 10 Jul 2024 07:43:46 AM MDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
/home/dylan/.cache/yay/gcc8/PKGBUILD: line 279: CHOST: unbound variable
/usr/bin/makepkg: line 131: logpipe: unbound variable
 -> error making: gcc8-exit status 1
 -> Failed to install the following packages. Manual intervention is required:
gcc8 - exit status 1
gcc8-libs - exit status 1

Ah, poop. As a simple debug step, I manually set export CHOST"\({CHOST:-\)(uname -m)-pc-linux-gnu}"= and retried to no effect. Do we want to debug an AUR PKGBUILD for a C compiler? …not really?

Let’s try gcc9.5 and see if XLA is cool with that.

…and go get a coffee, this build appears to be single-threaded and will take a while! Additionally, in parallel, I tried adding the direct path to my asdf-managed python3 to my $PATH instead of relying on direnv:

export PATH=$HOME/.asdf/installs/python/3.11.1/bin/:$PATH
# your actual path _will_ vary, can just do `export PATH=$(asdf which python):$PATH` in a pinch

IT BUILDS. My goodness, it builds.

mix compile

and it succeeds.

Onwards!

Pointing EXLA to our custom XLA

DONE Don’t decide who you need until you’ve determined what you need ShapeUpconsulting

When formulating a new project, idea, or team, it’s natural and typical to pull in the usual suspects. You know who they are without thinking about it too hard, though it’ll differ by person or project: you might pull in people by title (a Product Person, a Design Person, a Technical Person), or by familiarity and past work together, or you might just go with whoever’s available.

This is easy to justify. It’s not even necessarily even the wrong people. But it’s not the right way to build your team.

Instead, first consider what specifically you need from people to succeed here. Rather than “John and Anja always work well together, let’s get them on board”, or “we need Product and Engineering so grab the most senior available of each”, get into the facets of competencies you need:

• do you need pixel-perfect designs, and/or deeply empathetic understanding of how a user will navigate the flows of the system, and/or a strong researcher? One of these might be more important than the others.
• do you need to manage rituals? or be a central hub for communication? or have a strong sense of the business goals and how they relate to the project, allowing them to decide what’s not important and what’s essential?
• do you need someone that can reliably take an existing system and scale it to millions of users, or someone that can build a new system from scratch, or someone that has deep context and recent experience with the system you’re trying to augment or modify?

Once you’ve figured out what competencies are truly essential, you might end up picking the same people that you would have otherwise. It’s fine to have good instincts.

But often you’ll find something like: the right technical person to pull in is the intern that’s spent the last month linting and upgrading the system you want to modify; or the right product person isn’t the one that runs great rituals, but the one that came out of customer support just last year and knows how your users think; or the right designer is terrible at Figma but great at whiteboarding a user flow.

Nail down the characteristics you need, and then pick your people.

DONE Have you described how to build the thing, or just why it’s a great idea? ShapeUp

In preparation for a client project, you’ve identified a problem worth solving, and you’ve got a great idea for how to solve it. There’s a meeting set with the engineering team to start building things out, and you’re excited to get started. Let’s have a look at your artifacts: your slide deck, or pitch, or spreadsheet, or tickets, or whatever.

Do you describe why the thing is a great idea? Look for charts with an axis labeled “users” or “money” or some other metric that goes up and to right. Got it. If this is your first time meeting with the folks involved, or if the decision to actually build the thing hasn’t been made yet, this is totally reasonable! It’s great to get people excited. And it’s great to ensure people will back your idea with resources if you haven’t already got a commitment.

But it’s not enough to actually build the thing. And, if this is something that’s already been sold, you’re selling past the close. Don’t do that.

If you’re handing your builders a bulleted list of feature ideas, or a sales pitch, but not a description of how the thing is built from top to bottom, you’re asking them to do your job for you–not just to build the thing, but to do the footwork of figuring out what the thing is, and how the plumbing comes together, and unearthing any hidden assumptions you’ve made along the way that might blow up in their faces. They might be perfectly capable of doing that, but it’s not their job, and if they’re on a typical builder’s schedule, you’re going to blow up their metrics for cycles to come if you ask them to just get started.

Getting technical input into your artifacts is a great idea. The time to do that is before you tell people to go build your thing.

DONE Dream as who you want to be–but scope for who you are today

When considering a new project or strategy or relationship or business venture, it’s not just easy to get excited by the possibilities–it’s necessary. If you don’t have a vision for what you want to be, you’ll never get there. But it’s also easy–and often project-ending–to set yourself up for failure by expecting too much of yourself too soon.

Dreaming up a grand new SaaS company is a blast. Going through weeks or months of market research, product definition, and customer interviews is a slog. And that’s before you even start building the thing–and all the while you’re mostly trying to prove that the idea is a waste of time that you shouldn’t pursue, and hoping to fail in that pursuit.

Spinning up with a new client is exciting. Getting to know their business, their people, their codebase, their processes, their goals–it’s a lot of work. And since you’ve already made the sale, you’re already pressuring yourself to deliver value, and may feel like you’re failing to do the high-impact work that matters while flailing your way through the low-impact work that doesn’t.

It’s great to dream, and drum up your excitement for what’s possible. It’s even great to plan a pathway there. But when you’re taking the tactical-level steps, and especially the first ones, scope your way to success. The questions you need to ask your new teammates to do the most junior-level of work at a snail’s pace are the work. The research you need to do to validate your idea is the work. The first steps are the hardest, and the most important, and in the short term, the least rewarding. But you have to do them. Don’t beat yourself up while you do.

DONE So you’ve got a suggestion

In the midst of a discussion, it dawns on you: they’re doing it wrong! You’ve got a suggestion, and you’re going to share it. It’s great, they just need to…

Hoooooooold on. Do they need expert advice? Or do they just need to notice something they already know?

Sometimes, the answer really is that the expert advice is warranted. If something’s clearly off in a prescriptive process, or technically wrong in a way that’s broken, by all means–chip in.

But if it just feels like a meeting is lacking definition, consider raising it as a question instead of a suggestion. “What’s the goal of this meeting?” is a lot more likely to get a productive response than “We should have an agenda.”

DONE Figure out the reward before you start the work

When it comes to supporting a team, or helping an individual client, or running an organization, if-then rewards are almost always a terrible idea.

If-then extrinsic rewards suck all the creativity and inspiration out of the tasks they are applied to. They are a great way to get people to do things they don’t want to do, but a terrible way to get people to do things they do want to do.

From the outside, that is.

When you impose if-then rewards on yourself, though, things are a different matter. Building a new habit? While you’re building it, the automaticity what you’re doing isn’t really fully installed yet–you’re still in the process of building it. And while you’re building it, you may not be getting the reward of the habit itself; oftentimes those take weeks or months to become apparent. So, in addition to setting up smart cues, you need to set up smart rewards. And the smartest thing you can do is to figure out what the reward will be before you start the work.

There’s two parts to this. Which is the most obvious will depend on the person–I’ve run into folks that report either of these being so clear, and the other a surprise, but for both answers.

1. Well in advance of any work- or habit-planning whatsoever, build a pool of potential self-rewards.

   There’s generic suggestions around this stuff: have a piece of chocolate! run with your dog! read a book! but scrubbing through that list is a decisionmaking process, and adds to the friction of your process. What do you like? What do you find rewarding? It’s worth considering environments in which you use these rewards: if your life is centered in an inner city, you’re unlikely to take a 20-minute break to go mountaineering, but you could go through your old trip photos or spend time considering your next adventure. If you’re in a rural area, you might not have a lot of options for a quick trip to a museum, but you could spend time looking at art online or reading about the history of a favorite artist.

   Here’s some of my own:

• go for a walk
• scrub through recommendations on Steam
• take a bike ride
• just sit in the sun if the weather’s nice
• listen to a new album
• set a budget and do some online shopping
• take a nap (though don’t force yourself to stay awake if you can’t)
• journaling

Some of these will sound like great ideas for you. Some of them will sound like work. Don’t choose the latter as a reward for yourself!

1. When you’re planning the habit or work, pick a self-reward.

   This give you something specific to look forward to, and frontloads the decisionmaking before the task so you can just coast into a reward without delay once you’ve completed your habit. You can of course flex on this once you’ve done the thing! If you don’t want to do the thing you said you’d give yourself, don’t force it, and be kind to yourself. But having a plan in place will smooth things over.

Give it a shot! Figure out what sorts of things you love (this is fun anyway!) and then pick one to look forward to when you’re planning your next habit or task.

DONE Jumping into a new system

When working with unfamiliar systems, judging scope to complete a task when you don’t understand all the moving parts is especially challenging. The best approach is always to pull in someone more knowledgeable, whether that’s to pair with them or just to ask context-building questions–but what if that’s not available right now?

The best move is to just start, but with the specific intention of actually completing a small unit of work despite the unfamiliarity of the system. Trying to complete everything in your project almost certainly will find a brick wall or a misunderstanding along the way, while “just poking around” will, contradictorily, lead to greater confusion around the system in question.

Do the smallest thing. Check that it’s not horribly wrong. Take a walk.

DONE The supply and demand of getting shit done

In organizations of all sizes, work to be done has both a supply side and a demand side. I mean this not in the customer-wants-your-product sense, but that for a given project, task, or other unit of work, the labor of defining and refining what is to be done requires a different set of skills, mentality, and goals than the labor of actually performing the work.

A product manager is (oversimplifying) on the demand side of what projects will be tackled for a given strategic initiative, and on the supply side for breaking projects down into subtasks, dividing the work amongst teams, and providing feedback to the folks doing the delivery work on needed changes.

You can probably think of a dozen examples of this dynamic in your own organization, particularly if it’s a hierarchical one. More interesting to consider, though, is: how do you apply this to your own self, and your own work?

It’s useful to give yourself some definition around what kind of work you’re doing right now. Are you in supply-side mode, or demand-side mode? Are you defining the work, or doing the work? Are you thinking about the big picture, or the details? Are you thinking about the future, or the present?

The most important part of this is to be deliberate about what mindset you’re currently working in. Blending these is like any other kind of multitasking: doable in a pinch, but suboptimal for everything you’re working on.

DONE The obligatory GPT acknowledgment

There’s a couple different elements that I pull into the solar system of consulting: primarily, I love thinking about & working with clients to help them understand what they actually want, and how to better work together. This often turns into explorations around process (or lack thereof) and priorities, and how to frame decisions so they’re more likely to produce what clients actually want, not just labor and `git` commits.

So far, as best I can tell, GPT and friends aren’t especially helpful at this:

(GPT loves lists. Loves ’em.)

That’s not terrible, but it’s not actually helpful, either. The language is dry, and the information isn’t at all adapted to people’s needs. (Another attempt at generating from this prompt led with suggesting using “The Miracle Question”, which is rarely appropriate for clinical clients, and probably never in the business consulting context.)

All that is to say: there’s not much actually usable there. It could help with outlining. Someone with passing familiarity with SFBT could write something like that without referring to any outside documentation. We might see all this change in the near future–but right now, today, this isn’t an exciting use case.

I also happen to be familiar with a few programming languages. And, boy, is that a different use case:

…and then proceeds to generate code for your views, controllers, Stripe integration configuration and implementation, client-side JS, and so on.

You may not be able to use it right out of the box, but that’s a lot of documentation and API references that you don’t have to look up and toy with.

The generalization (from, granted, n=2 here) is that this tool isn’t super at replacing humans entirely, but it’s fabulous for accelerating work where you have a lot of boilerplate or external-to-your-cranium knowledge that needs referencing.

I’m excited to see how teams start to restructure and shift processes to respond to this different balance. Experimenting is a lot cheaper than it was a few months ago; will we see folks shifting implementation earlier than research and task definition?

DONE What you can, with what you have, where you are

It’s easy to get caught up in the loop of desiring predictability in oneself: delivering the same amount of effort and value and connection each day, or week, or whatever other unit of time most resonates.

That’s a set-up, and the set-up is to feel like you’re failing even when you’re not.

Some days you will fly and be brilliant. Some you will be able to deliver far more than others. There’s strategies and tactics to enable and accentuate these days, and to make them more frequent.

But there are also down days. You can’t not have them. And on those days, “bringing your best” or “delivering at 100%” looks like: whatever you’re capable of that day.

That’s it. “Your best” isn’t an absolute measure. It varies over time. And that’s everybody, and it’s normal, and it’s okay.

Don’t talk yourself into lowering your rates or compromising yourself because not every day is astonishing. If every day were special, none of them would be.

DONE Borrow the anthropologist’s lens

Adapted from the advice of a number of therapists I’ve worked with:

Borrowing the anthropologist’s lens can be pretty helpful in both understanding how systems of people interact.

The next time you anticipate being present at a potentially tense situation, or even just as good practice, try going in as though to study a strange and foreign people: there’s less getting directly emotionally invested in interactions/outcomes, more observing and “oh, fascinating, that’s how you try to get what you want in this system?”

DONE But if you do miss twice…

Don’t miss twice.

Be prepared to miss once by having a recovery plan: a way to get back on track when you have a bad day.

Don’t miss twice.

But if you do, it’s time to reflect.

Is this something that I value, and want to continue doing? If so, what about my prior system was insufficient to keep things going the way they were prior? Is there an obvious change to the system that can support resuming my habit or pattern? Do I need to use a different cue, or change the timing, or drop something else?

Most of what we think about when we think about habits and intents and scheduling is effecting our decisions around them, but it pays to listen to the outputs and to act accordingly.

DONE Everything is risk mitigation.

Every engagement, every time.

Doing expert delivery work? You’re helping the client mitigate the risk of being unable to ship the delivery on their own, and the risk of being the sole party to blame if things go wrong.

Consulting on team processes? If the team doesn’t improve, it’s not the manager’s fault; they’ve mitigated their risk by hiring a consultant.

Talking through the tradeoffs of a particular technical tool? You’re helping your client balance how much they trust the tooling with how much risk they have appetite for.

What risk have you mitigated today? It’ll map pretty closely to “what value did you provide”, but the perspective may be drastically different.

(Editor’s note: this blog will be off on Monday, returning Tuesday.)

DONE Strong agendas, lightly held

The gift and curse of the outside consultant is seeing opportunities for the client to do things differently. Better ways to collaborate; new strategies to support their stated goals; different delineations of responsibility and team structure; everyone working in this position will have favorites, go-to perspectives, and unique offerings. It’s natural to start developing an agenda of ways you want to help guide your clientele.

Every time you suggest one of these changes, you’re wagering some trust. If your client’s in a place to be receptive and try things on, they take your wager–and things from there get interesting. That’s the addicting part of the job.

Thing is, that’s not what always happens. If you’re making suggestions that your client’s not ready for, or you don’t have the rapport established to support, you’re putting up that wager of trust…and getting nothing for it. When you run into this, drop your agenda and get back to working the relationships. It may feel frustrating, but this is normal, cyclical, and fundamental.

It’s not starting from scratch. It’s starting with context, and it’s easier each time.

DONE Mission or ️Adventure?

(With credit due to the amazing Jason Allen)

You’re about to dig into your codebase to add a feature. Or: you’re about to go on a Target run with your partner. Or: you’re uncomfortable about the way a coworker behaved during a meeting, and you’ve scheduled some time with them to connect later. Or: you’re headed to the local art museum.

Are you going on a mission, or are you going on an adventure? That is: do you have a specific target thing you want to accomplish, and then get the hell out of there–or is this squishy, exploratory, creative, and free-form?

Both approaches are valid and have their benefits, but make sure you know which one you’re taking–and that everyone you’re doing this with is on the same page with you.

DONE Dancing around side-channels

Mid-conversation with a group at your client, it becomes blindingly, head-slappingly obvious to you that a major topic of discussion tangential to the current one needs to be addressed, and for as long as it goes undiscussed, it’s going to cause pain and confusion for you, for your client, and for your client’s customers. What do you do?

Blurt it out immediately? Not unless it’s literally the billing system falling over. You’ll end up busting up the current conversational context, making the current discussion less likely to actually finish and probably blowing any time block reserved for it. Don’t do that. But you know that.

So instead, you pop open Slack and send a direct message to someone likely to agree with you.

That’s…I mean, it’s better! It’s definitely less worse! But now you’re starting side-channel conversations without really giving that a lot of consideration. What’s your goal with this person? Are you trying to build rapport, or impress them? Are you trying on an idea with a limited audience to get a first take rather than throwing it in front of more people without knowing where the conversation will lead? Are you slighting someone else as part of this conversation? Wait, what was the main topic of conversation about again?

It’s a lot to think about…and you’re also trying to stay present in your current synchronous discussion, which doesn’t leave space for reflection.

Take a moment to jot a note (paper, Notes.app, whatever works best for you). Set aside 10-15 minutes after every meeting you take to process and, if still needed, act deliberately. And thank yourself for making your life a lot less complicated.

DONE The life-changing magic of keeping your mouth shut

An occupational hazard (and occasional benefit) of expertise consulting is forming a wide range of opinions broadly and at depth within your areas of expertise. Within any given conversation, meeting, proposal, architecture, codebase, and so on, you’re likely to have something to contribute: war stories, outside perspectives, things you’ve seen work well, tensions you can spot.

One really great option (which I’m as guilty as anyone of not exercising enough) is simply keeping your mouth shut.

Give it a minute. Your client is the expert on what they themselves want; given the space, sometimes they’ll arrive at the same conclusion you might’ve suggested. And the greatest value you can offer isn’t always the outsider’s spit-take; just as often, it’s the ability to soak up context and then re-share it later in a different shape than you’d found it.

(By all means, though, whatever you were thinking you wanted to share, write it down for yourself! Not only does it feel about as good as saying it aloud, but it may well have been a good idea, and this way you’ll remember it for later.)

DONE The Element of Surprise

The Queen is dead. The investigation had an outcome with grave consequences. The air is full of smoke from wildfire. The server process started running out of memory faster than new instances could boot, and your application started thrashing. You brought the people from an unhealthy family system into one place, and left feeling surprised and shocked by losing yourself in the mix.

Did this come out of nowhere—an unanticipated event at an unanticipated time happening at an unanticipated place to an unanticipated entity?

Or did you have an inkling? Did you know it would happen, but not when? Did you know something would happen then, but not what? Did the positioning of someone or someplace feel precarious, but the outcome and timing weren’t certain?

It’s rare that something takes us entirely by surprise. Often, the shock is tempered by a sense of disappointment, or resignation, or even some satisfaction or relief in no longer having to hold the tension.

What risks are in play for you right now that could turn into surprises? What things do you anticipate happening, but without a firm date or timeline? How can you make things easier for yourself when these possibilities are realized? And, when you feel blindsided by something, consider: could it have been prevented, or made unsurprising, given what you knew already—and if so, what in your thinking allowed the situation to surprise you anyway?

DONE Explicit ask vs implicit/inference culture

If you want something from your team or family, do you ask for it explicitly, or do you “make it clear that’s what you want”? (And is it actually clear, or is it a shared dance?)

Ditto in the other direction. How do you feel when someone makes a direct ask, either of you or in front of you? What about when someone makes strongly implicit they want something of you, but won’t make the ask? What feels comfortable, polite, or downright rude?

This isn’t just a rhetorical question—different people from different backgrounds, even within the same culture, will have dramatically differing answers, and the style opposite our own feels unnatural.

Note that both of these are learnable, but only one scales.

DONE This always happens.

When logistics for something are handled by someone impersonal and corporate, you run into the same issues repeatedly.

You’re starting a training session by asking students to download materials, but the corporate wireless network won’t let everybody connect.

You’re traveling across town to a specific location, but the municipal public transit options don’t interlink ideally, tripling the time it’d take to get there.

You’re shopping for a new car, but there’s not a dealership in your state that has the particular model you want, and you can’t just Amazon yourself a vehicle.

We’re all too busy to solve all of these ourselves; we have to defer to the existing systems that are meant to be generic enough to support most use cases, even if ours aren’t the best fit. But we can always solve one issue. (The materials could’ve been retrieved ahead of time; ride hailing apps will trade time for money; you could travel or put up cash or make a fuss or work with another dealer or start your own damn car company! with rockets! and shiba inus! in fact, screw the cars!) When you next run into some pet peeve of a repeated inconvenience that comes from a predictably anonymous system, consider: is it worth the extra effort to solve this for yourself?

DONE It’s conference season.

With conferences happening again mostly as we remember them from the pre-pandemic days, a lot of the same expected “conference ughs” are showing up. I don’t here mean the fatigue of extended exertion in a strange environment, or the potential need to realign with seeing people in person that you haven’t previously, but instead the more practical matters:

• the food
• the wifi problems
• projector-laptop interface woes
• microphones falling off, batteries dying mid-sentence, and the presenting speaker unaware of it

Every single conference runs into this stuff. We know it going in, and we live with it, because every single conference runs into this stuff.

None of these problems are showstoppers. They don’t kill the conference, and so it’s not obviously crucial to fix them. And maybe that’s the right outcome.

But if you’re going to speak, an easy way to differentiate yourself is just to remove one of these issues from your own talk. You can bring your own Wifi, at least for a few folks. You can know your material so cold that you can present without your deck, and turn that into a part of the show. You can bring snacks.

Building better, more compelling content than all your co-presenters is hard, but there’s easy ways to just show up better.

DONE Bring good questions. SFBTconsultingquestions

Your clients always will be the experts on knowing what it is they want. You can’t bring that element; only they can. But they may not be able to just explore and express those wants on their own. That’s why part of the job is to bring great questions. Here’s some:

• looking at your situation right now: why isn’t it worse? what are you doing that keeps you there, instead of degrading?
• between now and (as far out as the client can readily relate to), where do you want to go?
• how will you know when you get there? what will it feel like?
• what’s one single thing you can do between now and the next time we talk that will move things in that direction?

DONE What kind of autonomy does your team actually want?

When asked as a binary question, people will say they want autonomy–because we’re all the hero-protagonists of our own life stories. But it’s not really a binary concept, and unpacking what kind of autonomy your team wants can help you lead more effectively & give them the support they actually need.

Autonomy involves ownership over decisionmaking. So ask your team: what decisions do they want to outsource? And which ones do they truly, non-negotiably care about?

Having the ability to say “no” and veto a particular project is vastly different from choosing whose voice is even valid in a conversation. Somewhere on that continuum (and ever in motion) is the sweet spot where your team has control over what they care about, but isn’t spending cycles thinking through things that would be better off just dictated. (This, by the way, becomes the job of a single person, and if you don’t know who it is, it’s you.)

Have the conversations to narrow this down, then experiment, and ask for feedback. You’ll likely find that people will be happier not worrying about things they don’t prioritize so long as they have control over the things they truly value, and that as an effect you’ll realize a more satisfied team that has shorter, sharper meetings.

Note: I’ll be traveling with family and on break for the next few weeks; I may squeeze in a post or two, or possibly none at all. Regularly scheduled posts will resume August 29th.

DONE So, you’ve got a bug software

Someone (maybe you) found a bug in your software. Ugh! Now what?

Maybe you look at it and ask an engineer to pick it up when they can. Now it’s on your mind and theirs. Often, what happens is that the engineer drops what they were working on before and will have to start it again later, effectively from scratch.

Maybe you put it into your ticket system, so that it either takes the place of other planned work or languishes forever in your backlog, a little piece of permanent friction and clutter.

What if you just lived with it?

All software has bugs. What are the chances this one just isn’t a big deal, and that you can accept it and move on?

(Sometimes this is terrible, and you can’t live with it. Don’t ignore something that breaks your whole company! But these are rare, and you’re unlikely to question them.)

DONE Predictability as a precursor to trust

For your professional relationships to be fruitful, you’ll need to establish a baseline level of trust. These days, showing some vulnerability gets all the attention, and while that’s a helpful step, it’s not sufficient in isolation. For you and your counterparty to trust each other in a way that will help you to work productively together, you’ll need to be able to reasonably predict each other’s range of reactions most of the time.

This isn’t a marriage; you’re not looking to complete each other’s sentences. But you do both need to know whether you can raise a potentially contentious line of reasoning and get a productive response, and over time, learn what buttons to avoid in order to stay in a professional state of mind.

A great start to this is just to directly ask how they’d behave in another person’s shoes: “If you were leading this team, what changes would you make?” “If X had brought that issue to you like that, how would you have responded?” By using a circular question like this, you can take yourself out of the hypothetical situation to begin with, and then if appropriate, share your own response as well to help your counterparty to understand (and, slowly, to trust) you.

DONE How do you grade yourself?

When a client project or engagement comes to a close, what leaves you feeling like you did well? Months later, will you look back at this as one of your better times, or less so? How will you know?

Some possibilities:

• The amount of revenue produced for unit of your time or energy
• Whether the client is likely to want to work with you again (and if they’ve already brought it up)
• If you went in working at a skill edge, can you now market a new skillset more honestly?
• Did you actually solve the client’s problem?
• Did you help someone at a client organization make a good career move?

You can look around to other folks in careers and positions you don’t value and get a feel for how they grade themselves; often, it’ll help you to understand why those life choices don’t appeal to you. Some folks grade themselves on how many buildings they can plaster their name on, or how many people they can injure emotionally, or the quantity of possessions with expensive brand names on them they can acquire.

Knowing in advance which of these or other possibilities resonate with you & feel Important will help guide your decisions in the moment towards outcomes that you’ll value more–and to avoid the easy pitfall of just choosing societal defaults (which, stateside, is typically “work too much, try to get paid a lot”).

DONE What goes into an intro meeting with someone at your client?

As part of getting established, you’re getting 1:1’s with folks at your new client. What’s your agenda?

I suggest holding this lightly and abandoning it at will. But it’s handy to have a formula to fall back on:

Connection

What do you have in common, or that you can otherwise connect over? It’s all fair game; the topic matters much less than the vibe. What’s it feel like to interact with this person? Do they tend to lead, follow, spin out, shut down? What’s their posture look like? (Do you want to mirror it, or encourage a shift on their end?) Oftentimes you can feel in the first 20-30 seconds whether this is someone you can go deep with or if your interactions are more likely to be more superficial. All you can do is meet someone where they’re at–but to do that, first you need to see them where they are.

Tenure, history

Folks love telling stories about themselves. What’s a good story of a time they’ve had at this organization?

The One Thing

“If you could see one thing here change over the next couple of (weeks|months), what would it be?” If this is fertile ground, you can keep going: “If that change happened, what would be different? How would you know? What would it feel like?”

Desires, dreams, expectations

Especially with individual contributors, expressing interest in what they want with their career–regardless of whether that’s in alignment with their job description–can give you a lot of insight into how they operate, and much better ability to help and support their growth than if you were just doing typical support work for their stated position.

When you’re first building relationships at a new client, do you have other major points of interest and prompts that you prefer? Hit Reply and let me know–I read all responses!

Operator’s note: I’ll be traveling Aug 13-28; posts here will be sporadic during that time.

DONE Grab 1:1s with everyone you can on your first week

When first joining a new client, you have the “new consultant in town” excuse to grab meetings across your organization. This is super important if your insertion altitude isn’t at the C-level, so there’s folks above you in the hierarchy.

Use this ability with abandon. Drop invitations on the calendar of everyone working at your altitude, and then reach out to folks a step or two up the hierarchy–your contact’s boss, and their boss, too. If that gets you to the C-level, so much the better!

Tell them this: I’m excited to be working with (your contact) on (your project). As a consultant, I have repeatedly found that my status outside my client’s normal chain of command has been a useful tool for helping leaders get an insider’s perspective on how their teams are working together. Please let me know if this sort of insight would be supportive of our working relationship, and I’ll be sure to reach out to you with anything of interest.

If you’re feeling a little more outgoing, ask them for a small favor, too.

Sowing these seeds across your client’s leadership team early on can pay off enormously down the line when you need a little internal leverage, and it’s only easy right when you’re first joining. Take advantage of the situation while you can!

DONE Consulting and Delivery

If you’re working in a capacity where your client expects tangible deliverables made alongside their full-time staff, you’re going to have to spend some time producing, not just observing and summarizing.

At any given time, it’s worth checking in with yourself and your current tasks, and asking: am I working on the system, or within the system?

And what balance would best benefit the client? (And, frankly, what balance would most benefit you over time?)

DONE Nudges, not Hail Marys

The superpower and curse of the consultant’s outside point of view is the ability to see the yawning gap between the way things are and the way things ought to be. If only they would just do X and change Y everything would be great!

That sort of feedback is effectively unusable. Many people just won’t be open to the suggestion that things could be better, because the possible implication that something wasn’t being done right in the first place is too threatening. Harder to foresee, though, is that many teams’ and organizations’ cultures just can’t change that quickly. You might find that you’re working with people that are fully open and willing to try your ambitious and transformative plan–but when you actually try it, something doesn’t go quite right, issues compound, and eventually it all crumbles, leaving your client where they were before, plus some cultural scar tissue.

It’s fine (it’s great!) to have a big, ambitious end goal to reach for and orient by. Once you’ve got it, though, spend the time to ask your client: what’s one single thing you can do between now and next week (or month, or sprint, or whatever) that will nudge things in that direction?

Then help them do that, and check in with them there, and ask again.

Give them a nudge, and help them have accountability to themselves.

DONE Say “no” much earlier

Across every scale, from the individual up through multinational organizations, there will always be more ideas for things to do than time to do them.

Every time you say “no” to such a project or task, the further along the path you’ve taken it to completion, the more time and effort is effectively discarded. We find silver linings in lessons learned and context gained, but we don’t deliver what we’d initially intended to.

Knowing both these things, it makes sense to check in early on in the planning and shaping stages of work to find clear indicators that it’s something unlikely to be finished, accomplished, or otherwise done. The sooner you discover that a “no” will be the outcome, the more you can focus on your “yes”.

DONE Default Do or Default Don’t?

When a chunk of work is dropped into your team’s workstream–whether you call it a backlog, or a bucket, or what-have-you–is the default expectation that your team will do that work? Or is it that the team will consider that piece of work for inclusion?

The ends of the continuum in the software world: “waterfall”, in which everything is pre-planned before starting, is purely default-do. Shape Up is default-don’t: work pitches go to the betting table for evaluation, and only a few get picked up, with no systemic retention for the next time around. Big-A Agile and friends fall somewhere in-between, depending on how you’ve adapted them to your team.

The trouble with “default-do” is that every “yes” embeds an implicit collection of “no"s, so you’re making prioritization decisions implicitly. There may be a discussion around work sequencing that puts the more important (or, more likely, the more urgent) work ahead in the queue, but the default decision is still to do all the things. It also reduces the quality bar for work definition, shape and scope before being assigned to folks on delivery; the impetus is on the recipient to prove why something isn’t ready, rather than on the submitter to prove that something is ready.

“Default don’t” engenders conversation around whether each thing should be done at all right now, including whether the work is sufficiently shaped and defined–and if the answer is “no”, the impetus is on individual people (and not an automated system) to improve the work definition and re-raise it if they feel it’s appropriate in the future.

Where are your systems defaulting to an unexamined commitment to work by default?

DONE Consultant’s toolbox: seek out what’s working, not just what’s broken SFBT

As consultants, we typically seek out what’s going wrong: the faults, frictions, and broken bits that we can help improve in service of a client’s needs. This is a direct, unsubtle path: find the thing that isn’t right; make it better; send an invoice; ask for referrals. It’s a living.

It’s also missing all the good stuff, and in so doing, risks skipping the second-order thinking required to mitigate unforeseen consequences. What if the thing you change improves the immediate thing you’re observing, but breaks something more crucial?

When conversing and investigating with your client, be sure to ask: why is this the way it is? Where do you want it to be? And why isn’t it worse? –that is, what are you doing that’s keeping things as good as they are, when there’s clearly worse outcomes available?

Then, listen closely.

DONE You probably need less process.

What do you want out of your team processes?

This seems like a straightforward question: enable you to achieve your goals, or Create Excellence, or something similarly vague and tactically meaningless.

But what do you actually want out of your team processes? What specific effects do you want them to have? What guidance and constraints? Just as important: what don’t you want?

It’s tempting to throw process to the wind and just announce: We’ll Aim For The Goal And Hit It. There are some teams that can pull this off! They’re usually very small, very talented, and very self-motivated. If you think you have one, you should try it! But you should also be prepared for the likely outcome that you’ll be setting your team up for disappointment, and be ready to re-add some scaffolding.

Especially in response to team disappointment, chatter, chaos, and the like, it’s also tempting to define a process for everything. You pre-define deliverables, dates, each communication step, enforce squash merges on your Git host, have an SLA on Slack messages with a rotating on-call person to respond to them with a specific script, have recurring agenda-led meetings to discuss the agenda for other ceremony meetings, and so on. Your primary communication tool is JIRA. This inevitably creates so much overhead that you’re all stuck doing so much metawork that you don’t do any actual work, and delivery grinds to a halt.

The prescription: add enough process to define the bare minimum someone would have to do to not get fired for sheer incompetence. When you find the need to adjust, do so reflectively and responsively, not as a reaction to prevent a mistake from recurring. The solution to someone making a mistake in isolation is better team communication, not an otherwise meaningless ceremony that creates overhead in perpetuity.

Provide a floor to people’s work, not a ceiling.

DONE Transfer and accept responsibility—responsibly

With every project, sometimes more than once, a time will come to hand off responsibility for moving things forward, be it to another individual or another team.

How do you know when you’re ready?

“I don’t know what else to do” is a terrible answer. So is “it gets it out of my hands”; ditto “they have more information about it”. You want the answer here to be “the work is in the correct state to transfer responsibility to the next party”.

It helps to make the criteria for transferring responsibility and/or ownership as explicit as possible. This empowers people receiving inbound work to set firm boundaries against ill-defined tasks, and also empowers folks to say Yes, This Is Ready, And It’s Not Mine Anymore.

For example, before a software engineering team accepts a ticket as ready to have resources committed to it, they can require the three D’s of well-defined work:

• Definition: what “done” means, in sufficient detail that stakeholders are unlikely to succeed in pushing for scope growth later. (This also defines when the work gets handed off to the next party, if applicable.)
• Deadline, if any, and
• Dependencies this work has, or upon this work, to aid in sequencing.

Tickets lacking these criteria–or whatever you determine is crucial–can be safely pushed back upon without affecting any existing commitments.

Where are you seeing mushy definitions of work responsibility, and ill-defined work requests? Can you help delineate who should be focused on those tasks, so others don’t have their time and attention captured by work flailing?

DONE Do work with (some) jerks

There’s an almost meme-level usage of “don’t work with assholes/jerks” within the tech industry. While originally well-intentioned, this has unfortunately come to mean “don’t hire people who openly disagree with others”.

You need those people. You need more than one. Folks that are able to get combative, to set a boundary for themselves or for their team and stand fiercely by it, even in the face of opposition–that’s how you end up with a healthy team, with the ability to set their own priorities and deliver on them. “Nice” is great, but prioritizing for it in isolation can lead to a team being passive and easily steamrolled.

I find it’s helpful to break down “jerks” by their center of gravity. Jerks are fighters.

If they’re just fighting for themselves, or just to make a mess, they’re brutes.

If they’re fighting for what’s right–they’re strongly opinionated, but don’t base their sense of self on winning arguments–they’re paladins.

Do work with paladins. Don’t work with brutes.

DONE Responsibility, accountability, autonomy, and competence

They need to be roughly proportionate. The ideal presented by business and self-improvement books and blogs aplenty is to have all of these at high levels, but that’s far from the whole story. The big deal here is alignment.

Competence is the hardest to adjust, so align based upon it

If an individual or a team has a relatively low level of subject competence, giving them high levels of responsibility, accountability, and autonomy is setting them up for a public failure. That doesn’t help anybody. These more junior folks benefit from some guidance and hand-holding–not as a judgment or micromanagement, but simply to help them grow. (Hence concerns about moving to all-remote workplaces and supporting junior staff members, though ultimately that’s addressable; future blog post to follow.)

For individuals, subject matter competence is the peg the rest of these elements need to align with; for teams, you can change the personnel mix to nudge things if needed.

You can bias these elements a little higher or lower depending on your sense of folks’ drive and hunger, but let them know when you do so, or you risk having to repair after they fail.

Once you’ve got high competence, don’t skimp on an element.

• High accountability without responsibility means being judged for others’ actions without any control. It’s unfair.
• Responsibility without accountability is free reign without feedback. Folks won’t have the information they need to grow and improve.
• Autonomy without responsibility or accountability is unstructured without a mission. There are people that thrive in this, but if you’re not sure, they probably won’t.
• Responsibility without autonomy is stifling and prevents folks from owning their decisions.

And so on.

Keep it proportional.

Measure or estimate competence, then set responsibility, accountability, and autonomy to fit. Your juniors will appreciate the guidance, and you’ll make space for your more experienced staff to fly.

DONE Keep a personal “consulting backlog”

In the leadup to a new client engagement, you’ll typically have a flurry of connections and plans and defining deliverables and success, so you can show up knowing what you need to do and get right to work.

Then you actually show up, and meet the people involved, and the real learning begins. Team communication issues, processes that’ve fallen out of sync with people’s needs, pains and blind spots people have just learned to live with…bringing in an outside perspective, it can be overwhelming to absorb everything at once, and impossible to change it all in one go.

Don’t.

Treat the consulting issues the way you would incoming issues for software: write them down, triage them, and tackle one at a time. You won’t make any headway trying to reset a culture that isn’t even yours, but you can know where you want to go, take a small step in that direction, and re-evaluate. Your notes will still be there for you. Make sure they are, though–unwritten, you’ll certainly forget, and soon be one of the insiders that can’t even see them.

DONE There isn’t enough time.

Project A or fire drill B? Oh, and department C is really interested in you doing D, but that would cost the time you need to see your family for E, or maybe you could get up super early and…

It’s true: you cannot do everything. There are always tradeoffs, and differing pressures and demands on your time and attention.

Here’s the thing:

You actually do have complete, 100% agency over what you do with that. You could leave your family behind and disappear into a monastic lifestyle. You could quit your job and pour yourself into learning to knit silk lederhosen.

You don’t because you’re not willing to live with the consequences of those actions. And that can be totally reasonable! You probably shouldn’t leave your family–and you probably don’t want to, regardless of what you might do in their absence! (Definitely don’t because a blog post suggested knitting lederhosen from silk!)

When you’re feeling like you don’t have agency, remember how unbelievably vast the decision space of living in the universe is. Then weigh the consequences, and own your outcome.

Feeling like you’re stuck with your environment and situation breeds half-assedness and resentment. Acknowledging that you have choice lets you commit–or occasionally to make big changes.

You cannot do everything, but you can probably do any thing.

DONE Optimize “good feels” for what matters

What kind of “complete” feels most satisfying for the folks on your team?

It doesn’t even have to be about explicit metrics or rewards, though those will certainly have an effect–but if you were an individual contributor, would you feel best about clearing off your own plate, or about collaborating with one other person to get both of your stuff shipped, or about seeing an entire project or workstream brought to a successful close?

There’s a balance to be pursued here; both the individuated and communal approaches have their tradeoffs.

The upside of encouraging individual “task done” accomplishments to be rewarding is mostly about frequency: something cut down for one person is likely smaller than a collaborative workstream, and getting a rhythm of fast wins is addictive and encouraging. It’s a nice way to keep folks engaged & can reduce burnout. The potential dark side is trying to judge individuals’ efficacy by widgets created per unit time; if you’re not running an assembly line, this is probably counterproductive for you at best.

Aside from the smallest of organizations, though, the things you deliver that matter are the result of a series of specialists working together–not a single person checking off a single task. And if you (even unintentionally!) cause “finishing my work” to feel better than “finishing our work”, the temptation is for folks to ship something before it’s optimized for the next person that’ll have to work with it.

For example: in a product-led organization, do product engineers feel they’re accomplishing more if they create and populate general descriptions for eight new features, or if they work with folks that understand the customer needs and delivery limitations to deeply refine a single feature description before anyone even decides whether it’s worth working on?

The “pursuit of balance” here is continual–your team probably doesn’t have the ideal balance for this today, and even if they do, it’s likely to be in flux over time. So keep an eye out, and consider: what feels most rewarding? and what overall purpose does that best serve?

DONE Changing intervals

When one of your systems is failing under strain, do you change the system, the goals, or the surrounding environment?

There isn’t a universal answer, but you can start by considering which of those elements is the least likely to be changeable.

To the point: In keeping with a recent common theme of setting goals you can (mostly) hit and not setting yourself up for failure, I’m going to slightly reduce the frequency of publishing here to every weekday, plus weekends given the chance. My balance of childcare and life circumstances just doesn’t line up with carving out solitary time on Saturdays and Sundays at the moment. Of course, this is worth re-evaluating for fit in about a quarter.

Where are you feeling the strain? Can you live with it? Or does something need to change for now?

DONE Technical tools: Calendar management

When’s the last time you had someone book a calendar appointment on top of an existing commitment of yours? When’s the last time it was you doing it, because you were looking at one calendar & the conflicting block was on another?

Managing calendars, appointments, and availability across your home and work life when you’re working with multiple clients or organizations can be a frustrating, trying experience. I myself have tried the span of options from daily-handwritten templates copying events from a larger tracked calendar, using a given client digital calendar almost exclusively, manually copying events back and forth as iCal files, surrendering control entirely (don’t do this), merging everything that comes up into a Moleskine paper day planner, and probably others that failed to make an impression on me.

My current setup is the best balance I’ve found. It remains imperfect, and I’m more than happy to hear your suggestions–but in the meantime, I hope this can help you smooth things out for yourself & skip some of the long trial-and-error process I went through.

(some referral links follow)

Google Calendar for most stuff

I do not love Google Calendar, but virtually everything out there expects you to use it, particularly in the software business world. I have one FastMail account whose calendar I use, and I end up having to use their inbuilt Google Calendar Sync functionality to link into anything else.

Maybe Microsoft would work for you, depending on your use case? GCal is hard to avoid.

Reclaim.ai for calendar sync

Reclaim smartly does two-way event synchronization between your calendars. You can set it to include details or just mark things as “Busy”, “Personal”, “Work Commitment”, or similar, so your protologist’s appointment won’t show up on your client’s calendar.

There’s a bunch of extras for teams (which might be nice, haven’t tried them) and for auto-injecting tasks synced in from your favorite corporate ticket-tracking tool (Jira, Linear, others); I’ve found that just setting aside a block of time for uninterrupted work is the best approach for me, and the rest gets too fiddly.

Reclaim only works with Google Calendar. If you happen to be on another service, you may not be out of luck–some competitors have a much more basic “sync to one Google Calendar” feature, and you can use a dummy calendar as a proxy. I do this with a FastMail account without much issue. My understanding is that CalmCalendar gives more flexibility here, and I may have to check that out at some point–but for the moment, Reclaim is sufficient to not spent time investigating alternatives.

I frequently describe Reclaim as “just good enough that it keeps me from building a competitor”, and thank goodness it is, because calendar sync is a wide field of programmer rabbit holes.

Fantastical as Calendar.app replacement

If you’re on Windows, I don’t know what to recommend. If you’re on Linux, you probably already have a strong opinion here. But if you’re on a Mac and in the Apple ecosystem, you should throw away the default Calendar.app and swap to Fantastical immediately.

Unlike the other offerings here, I can recommend Fantastical without reservation (and without profit; that’s not a referral link). It’ll sync with darn near anything, plays nice with Reclaim (and reportedly CalmCalendar), feels like an actual Mac app, has great display options, deals with incoming appoint requests reliably, understands natural language for appointment creation, and (I especially love this) merges the display of identical entries on multiple calendars, so you can actually read them.

It’s also starting to step on the toes of Calendly and SavvyCal with its Openings feature to let people book appointments with you. I haven’t tried this yet, as I’m happy with SavvyCal and Openings doesn’t yet integrate with any sort of payment platform. Worth keeping an eye on, though, and this may be sufficient for your use case without adding and maintaining yet another paid tool.

SavvyCal for appointment booking and management

It’s like Calendly, but indie, non-corporate, with some serious UX magic (your clientele can overlay their own calendar while checking availability). It syncs with most popular calendars and integrates with Stripe for paid appointments. You can use it to automate finding a timeslot for a meeting with multiple people without all the back-and-forth of Slack and email and whatnot.

It does the things and it’s not the evil empire. If you haven’t used an appointment management service before, let me insist: even one use a month is worth the monthly fee to not have to think about coordination.

Invisible Calendar for a desk calendar

I live in my calendar and want it open all the time. I also love the gentle, non-invasiveness of e-ink screens. The Invisible Calendar sits attractively in my line of sight on my desk, close enough to a paper calendar, but without any of the manual copying back and forth from paper. Superb.

Things I (somewhat surprisingly) don’t use

I could nerd out on calendar tooling virtually forever, but it’s not what I get paid for. Consequently, I don’t pull my stuff into org-agenda, nor play with SavvyCal’s API access; I don’t bullet journal or sketch a paper daily agenda (though the latter has proven useful historically).

If something here jumps out at you, or if the whole system sounds reasonable, borrow bits and pieces or take the whole thing. Happy scheduling!

DONE Lifecycles of lifecycles; seasons of systems

When we discuss systems, there’s often an implicit understanding that systems are meant to be designed, then perfected, then ritualized. You get them to a good place and leave them be, so you can set that on relative autopilot and spend your decisionmaking energies elsewhere. Let the humans run the algorithm and be done with it.

Even so, many (most?) of the systems we work with every day that feel either broken, or like they were poorly designed in the first place.

What gives?

The inputs changed. Your team got more senior. The company got bigger. The folks building stuff are further from the folks selling stuff.

It’s a different season for your system. And it’d be helpful if we could acknowledge these seasons from the start, and to simply expect them to need to change with the company climate.

What’s this look like?

An example for the software folks: Scrum provides a ton of structure and scaffolding. It’s great for helping juniors and mid-level builders gel as a team and get the sensation (and ideally the reality) of delivering, and it gives management the sensation (and ideally the reality) of fast feedback and involvement. It’s also a lot of overhead: tons of meetings and ceremonies and tracking and process and discussion about the meetings and the ceremonies and the tracking and the processes.

I love using Scrum for helping teams repair themselves and getting back on track. I find it super heavy for teams that are intact and delivering.

When the team grows, it can grow past Scrum and be ready for something a little lighter, with more flexibility. Maybe it’s Kanban. Maybe it’s small-a agile. Maybe it’s Shape Up¹.

But then after some time, things change again. The build team has a lot of turnover and needs to gel again. Product loses some expertise and is having difficulty shaping work.

Bring it home

What’s shifted in the feel of your systems since the last season, the last quarter? Do some feel better, or newly uncomfortable, constraining or unsupportive? All of your systems will have to change with time. Knowing that ahead of time lets you prepare and accept, instead of being surprised when one fails entirely.

DONE Don’t burn out.

If you don’t schedule downtime, it will be scheduled for you, in the form of injury or burnout.

(Paraphrased) Visakan Veerasamy

There’s a good chance that you, dear reader, are making a living by exchanging time for money. This is ultimately not the ideal approach, but we’ve all got to start somewhere, and “time for money” is well-understood.

This being the case, you’re probably starting to think about how much each hour of your time is worth.

And how much it costs you to not be working.

Two-week vacation? It’s not just the flights and the food; you’re out 80-ish hours of billable time–and the higher your rate, the more that “costs”. If you’re engaged full-time with a client at $200/hour, you’re out $16k. Yikes!

The thing is: that’s bullshit.

Here’s why: you can’t just work full-time continuously forever. Your body will stop working. You will burn out. You will go numb. And you will stop being able to work, and have to spend (non-billable!) time recovering just to get back to baseline. And you’ll probably be unhappy the whole time.

Don’t burn out. Schedule your downtime. Take a vacation; you’ll have to spend the time one way or another, and better to choose it than have fate choose for you

DONE Consultant’s toolbox: include your confidence level with your estimates

Different professions, upbringings, and roles lead people to use and understand the same terms in different ways. When crossing these boundaries, you need to get everyone on the same page in terms of understanding (if not necessarily agreement).

For example, let’s talk estimates².

Same words, different meaning

“When will X be done?”, the product manager asks the engineer. “In about five days!”, says the engineer.

When do each of them believe X will be done?

The engineer typically thinks they’re saying that X will be done in about five days, give or take some, if there’s no surprises. That’s an “on average, if nothing blows up or takes priority”.

The product manager typically hears that X will almost certainly be done in five days or less.

Who’s right?

Both of them. Neither.

The actual meaning here got lost in translation. People are using terms and descriptors the same way most of their peers and colleagues do, not the way their actual audience expects.

Communicate more, imply less

Here’s the fix: ask for, and provide, both the estimate and what it actually means. “I think this will be done at day A with 50% confidence, and by day B with 90% confidence.”³

Oftentimes, that’s the job: helping people bridge the different implications in their communications.

DONE Meet your client where they’re are.

Do you recall the last time you got a question or demand from your client or customer that not only didn’t make sense, but it left a mark on you emotionally? Lingering frustration, a sense of disconnection or even insult…

An HN thread from earlier today is illustrative of these interactions. A builder or producer or engineer supplies a piece of data without questioning what it’s for or the context; the recipient hears something they didn’t want and reacts strongly; everyone comes away with no more information than they had before, but feeling worse. Nobody wins.

Of course, it’s possible that the real, actual information being communicated was really, actually that disappointing, enraging, and awful, and that a strong emotional reaction without further qualification was the only reasonable response.

But probably not.

More likely, this is folks feeling like they’re not seen & not understood–because they’re not being seen, and aren’t understood. The folks building a thing have a full grasp of all the nuance and effort and complexity that goes into building the thing, and are rightly sensing that their client doesn’t grasp that. The client has specific needs they’re trying to satisfy, and are rightly sensing that their service provider, employee, contractor, etc. is focused on the deliverable, not on seeing their problems.

Someone needs to break the impasse & ask the right questions, both to actually get the information about their counterparty’s needs and to demonstrate that they see them–to help their counterparty feel seen. Until that happens, there’ll be tension remaining, even after delivery.

If you ask me (and you’re on my site, after all), in a consulting relationship, this is the consultant’s profession and responsibility. The client is by definition the expert on their own needs. You’re the expert on bringing good questions to bear–this is more important than delivery! And that means swallowing your pride for a few uncomfortable minutes so you can really get curious about why your client feels they way they do.

Work with people you like and want to help. Meet them where they are, even if that’s not where you want them to be. Care enough that you want them to get to a better place of their own accord, knowing that you may have the honor of walking alongside them. That’s where your job starts.

DONE The sharpest feature

Is the sharpest feature the one with the most beautiful interface? Is it the one with the most impressive technical implementation, elegant under the hood and rapidly responsive to input? Or is it the one that solves the problem most directly, even if its appearance and underlying implementation are inelegant?

My local pizza shop has an app through which you can place orders for pizza, be it delivery or takeout. It’s clunky: scrolling is janky, the viewport is the aspect ratio of old iPhones before the removal of the physical Home button, the images are visibly pixelated. It works; you can order a pizza and the order goes through, with no provision to cancel & required confirmation info sent to your email, not the app. It merely works.

And when you first open this app, you’re presented with two buttons: Start New Order and Repeat Last Order. Repeat Last Order does exactly what it says, with a single confirmation screen: two taps and something hot and cheesy is destined for your door.

That latter button is literally brilliant. This neighborhood is full of young families and overwhelmed parents. Let me assure you: Repeat Last Order is the sharpest feature this pizza shop could possibly ask for–head and shoulders above the app looking modern or responding more quickly or including your current order status.

What sharp but thin feature could you add to your current work instead of the typical iterative stone-polishing?

DONE Consultant’s toolbox: language mirroring

Here’s a tool used by both professional negotiators and psychotherapists alike: conversational mirroring, or reflection.

When you’re working with a client, or need to interact with someone related to your client goals, take precise note of what terms and phrases they use to describe what they consider important. Actually write them down as you go, if your environment provides for that.

As the conversation progresses, when you describe what you’ve understood your client wants or needs, use their own words to describe it.

This runs counter to the mindset many of us have developed in school and the field over the years, to demonstrate understanding and connection by reformulating the conversation to show that you’ve integrated the concepts. That’s okay–the goal here is different. Here, we’re trying to build rapport with a client, and do so by showing that we can meet them where they are.

Language is powerful. Speak their language, not your own. If your client describes their problem as “incredibly frustrating”, don’t call it “challenging”. Call it “incredibly frustrating”.

Ironically, this can actually be a more powerful way to build your own understanding of the client’s needs than reformulation and summarization, because it forces you to listen more closely, rather than get sidetracked in abstracting the stated issues to larger concepts in mid-conversation.

(You can still do all that cognitive stuff–reformulating, abstracting, figuring out what strategies to apply and what levers to lean on! Just do them out of band. When your client is talking, actually listen to them. This is harder than it sounds.)

DONE How many answers per day?

A common framing among software engineers working on a codebase is the “feedback loop”–what’s the process of testing whether your change to the code causes the behavior you desire, and whether it breaks anything?

This basically maps over to: “how many questions can I ask my system in a day?”

There’s different ways to influence this speed: hardware, technique, investing time in improving the support around the feedback loop…

More interesting, though, is considering how this same framing fits for the rest of your life and career. Learning and habit formation depend on short feedback loops–it’s hard to lose weight because food tastes good now, but your noticing your body feeling lighter could take months.

For the things you care about, how many questions can you ask each day? And how can you raise that number?

DONE Before the next “yes”

Every “yes” is an implicit collection of “no"s.

Yes to another project is no to focus on what you’ve already got in flight, and no to that collaborative enterprise your friend had just suggested, and no to having some breathing room in your schedule.

Yes to going out to dinner is no to staying home to catch your breath, and also no to getting a last-minute flight to the coast in time for sunset, and no to taking an evening in the woods.

Yes is easy, though, because those “no"s aren’t explicit. That doesn’t make it necessarily the wrong answer, but it’s often done blindly.

The next time you’re about to Yes into a big new thing, no matter how exciting, take a moment and consider: what “No"s are packaged up with this Yes?

DONE Don’t miss twice.

One of the bigger takeaway tactics from Atomic Habits, among other purveyors of good habit-making and -keeping, is the “don’t miss twice” rule: everyone has a bad day occasionally, but make sure that when you miss your intended habit once, you won’t miss it again.

How do you do that?

Hopefully the hard day is a one-off. Then, it’s easy: your next day is “normal” and you just do the thing.

What if that’s not the case, though? What if you can foresee that won’t be the case?

How to not miss twice

• Know that hard days happen, sometimes sequentially.
• Have a plan to recover.
• Be willing to flex what “done” or “success” means, and have that be known in advance.

That last one is crucial for when you’ve got a couple tough days in a row. If you know in advance that you’ll find doing 10% of your normal acceptable, it’s a hell of a lot better than 0%, and you’re not just half-assing it in the moment–you’re following a plan.

Own the hard days, too.

DONE Things you can outsource, but shouldn’t

(If you haven’t already, check out the posts from yesterday and the day before; this post closes out the series.)

A little multi-order thinking around outsourcing, services, and the general theme of delegating things to others, usually for money.

If you’ve selected a task that you just don’t like doing, and it’s not core, and it’s not working on a relationship, and especially if it costs less money than your money-weighted work rate would for the amount of time it would take to do it yourself, of course it’s a no-brainer. Delegate the damn thing.

If it’s your core competency, don’t delegate it. If it’s building a relationship, you can’t delegate it.

Okay. Those are the poles. The middle’s more interesting.

Consider the tradeoffs in the middle ground

Your car broke down, and needs a replacement part, and the labor’s involved and expensive. What do you do?

Maybe you don’t like working on cars. Okay, easy.

What if you find working on cars it soothing, but in the time it would take you to do the car repair yourself, you could make more money than you’d pay for a mechanic to do it?

What if you value the sense of accomplishment that comes from doing the work yourself more than what you’d spend your time on otherwise?

What if the tradeoff is that you’d have to skip your kid’s birthday party to do the repair work?

What if…

Think it through

Most of us delegate and outsource far less than we should, and “just outsource it” isn’t a terrible default. There’s few decisions in life that we can’t revisit later at lower cost than it might seem upfront. But as you get in the habit of delegating and outsourcing bits and pieces, it’s worth periodically reviewing the nuance involved, and if there’s things you find you miss doing for yourself–and whether that’s worth the cost.

DONE Things you can’t outsource

There’s a lot of great ways you can buy your time back with services and outsourcing. But there’s things you really cannot replace. These are the things you outsource for, to get more time to do yourself.

Remember those 80’s and 90’s movies with dad always disappointing his kids by showing up just at the end of the competition that their kid had won? Mom not being fully present to actually get what her child was saying? (It was the 80’s/90’s and those families were strictly heteronormative, and they all had the same problems.) You’d watch an entire multi-hour sappy block to see an adult rediscover what they cared about.

Here’s some things you can’t effectively outsource:

• growing relationships
• making memories to cherish as you age
• your own enjoyment and recreation

This is a little fuzzy and touchy-feely, but worth highlighting: you’re building your income and optimizing your time so that you can have a good life. Don’t miss out on it in the process.

DONE Ways you can buy your time back

If you’ve been a professional for a number of years and started to find your groove, and especially if you’re independent, your main constraint is your time, not your money. You can make more money, if need be. You can’t make more time.

Where you can, you should buy it back.

Here’s some things you can try:

• household chores: periodic maid services, pickup/dropoff laundry service (most of the time saved is folding), dog walking, picking up after the dog, yard work, things you might DIY…
• errands: subscriptions to consumables on Amazon, a milkman if there’s one in your neighborhood, buying less stuff, grocery deliveries…
• business administration: hire a bookkeeper, turn frequent tasks into checklists and hire a virtual assistant, automate your email (automate anything, really)…

It’s easy to want to do everything yourself, but you’ll never have the time. If you have the privilege to choose, use it.

Don’t overdo it: if walking the dog is the one thing that gets you out of the house in the morning, do it yourself. Don’t pay someone to do something that’s good for you unless you’re doing to do something even better instead.

DONE Rituals big and small

Next Monday, many people across the United States will notice the date on their calendar, and change their thinking, their feelings, and their behavior compared to July 3rd. For some it will occasion joy; others concern, reflection, ambivalence, and so on. Very few won’t notice.

Why? And I’m not talking about old papers with dead men’s names on them.

The repeating of ritual throughout one’s lifetime, especially one imbued with generations of intent (often conflicting) and meaning, evolves with time. It doesn’t reveal itself all in one showing. It’s not always nice. It doesn’t matter every time. For some people, it may feel simple and roundly positive; others may never feel like a true fit.

Ritual writ large across society embeds much, each deserving of a dissertation, a dissection, a discussion. But the pattern can be examined in smaller form, in your family and in your workplace.

What rituals do you have in your team, and in your work? Where did they come from? What parts are deliberate decisions embedded consciously, and what parts do you do that may serve a purpose no longer clear?

Just because a part of your ritual doesn’t make sense on first blush doesn’t mean that it’s without value. But it’s worth examining how things got to be the way they are, and questioning the foundations. Otherwise our rituals calcify into something closer to religions, and we lose our ability to question them and change them for the better.

DONE Decisions affecting others and facing their costs

Oftentimes, the less visible costs to a given decision aren’t financial–at least not in the direct, immediate sense: the cheaper appliance requires more time and effort on your part to operate and maintain. Such examples are (fortunately) easy enough to learn over time, and generally easy to recover from–you adjust your purchase decision the next time around, no real harm done.

More insidious, harder to foresee, and far harder to recover from, are costs incurred against your trust and reputation. When your decision causes others to lose trust in you, and lowers your reputation in their eyes, oftentimes they won’t tell you–but they’ll tell other people, potential customers and clients, compounding the damage.

When you’re facing a decision–especially an unavoidable one–that will have a profound effect on others’ lives or livelihood, or surprise them in a way not obviously positive, it’s worth taking the time to put yourself in their shoes. How would you react if this change were imposed on you? Are there ways to reframe, communicate differently, or make small tweaks to the overall thrust that would preserve trust and show respect for the recipient?

Usually the answer is maximum transparency, with kindness where appropriate, but not at the cost of honesty. Aside from your discomfort, will this have a real cost?

DONE False economies

It’s usually the most visible costs that we make decisions based upon, not the whole picture.

We use the subscription instead of the one-off purchase price, and pay double for the same utility. We issue relatively cheap computers to developers with high rates, and pay them to wait. We don’t price climate impact into fossil fuel consumption, and we’ll all end up paying a higher price.

It’s easy, because we’re in a hurry, and in the habit of being in a hurry, and so the easiest thing to compare is what it costs right now. But that’s an awfully expensive habit over the long run.

DONE Build it or buy it?

So you’ve decided to build it yourself instead of buying it. It’s not your core offering, but it’ll be custom and fancy and you get infinite flexibility, where off-the-shelf offerings are much more generic. Plus it sounds fun!

What’s that going to cost you?

Well, you’ll need to actually build it, so that’ll take that much time or money, plus probably some overrun if your forecasts aren’t practiced or if you hire help that runs into problems. At some point, though, that’s done! The cost is sunk and you don’t have to think about this anymore.

Then you’ll need to integrate it with all your other stuff. Then you’ll need to maintain it, and also those integrations, and when the shape of something your not-as-newly-built thing connects to changes, you’ll need to change too. Plus there’s security vulnerabilities and maybe infrastructure, and possibly even your regulatory environment.

How much time of the year will that take? How many people, or hours of your own, will need to be dedicated to it? What could they do instead?

There’s a line of answers here that lead clearly to “yes, build it”, and if you’re getting there from here, by all means, fire up git init or your equivalent new box to build in. But maybe you should just buy it.

DONE What’s your buffer look like?

If you’re consulting, and particularly if you’re stateside, part of the arrangement is that you can lose a client with little to no warning. There’s a bunch of ways to prepare and to deal with that: among others, you can:

• have several or many clients,
• diversify into productized consulting,
• have a very short, easily-filled sales funnel,
• keep a cushion of cash handy that lets you keep going between clients.

Effectively, these are all different forms of keeping a buffer, be it of inbound work or otherwise.

Which of these works for you? If your biggest client disappeared today, what would you do tomorrow?

Having an answer will help you do better work today; once this is effectively a solved problem, you get a part of your brain back that you may not have realized was missing.

DONE Sums over time

The descriptors for things as being “zero-sum” or “non zero-sum” have been having a moment lately, be it in finance, policy, psychology, or your field of preference. It’s always interesting and often beneficial for a new framing to enter the discussion of the public sphere, but the treatment of this property of thing-ness as being binary–that is, every thing that involves sharing or multiple stakeholders is either zero-sum or it’s not–is missing the crucial nuance of context.

Let’s get tangible

For me, drinking coffee affects the timing of my awareness and sharpness, but not the total amount I have available over the course of a day. Perking myself up means I’ll crash later.

In the moment, and for the next hour, drinking coffee is pure benefit. Going from not very awake to highly alert with very little downside. Let’s go! Non-zero-sum system, let’s get some benefits!

Over a 24-hour period, it’s roughly zero-sum. Perky now, bottomed out and crawling later, in near-equal measure.

Over the course of months, it’s helpful to be able to time-shift sometimes and balance out others. How this maps out to summarized thinking is a matter of opinion.

What’s the big idea?

When using a mental model to simplify a situation, like whether to consider a situation as zero-sum or “grow the circle wider”, think about what framing you care about. Do you really care how this will shake out over 30 seconds when your goal is longer term?

DONE Writing as thinking, not memorializing

I’m not writing it down to remember it later. I’m writing it down to remember it now. - Field Notes branding

There’s a lot of chatter in certain circles about Writing As A Tool For Thought, and ensuring that everything that you’ve written is captured, catalogued, discoverable, archived, and so on. You’ll run into this with Zettelkasten, Building A Second Brain, Roam Research, and a number of competing tools and methodologies.

These are not without utility! Being able to do research, take notes on it, and rediscover it later is incredibly valuable. The issue is that these various tools and methodologies are presented as something you should put all of your written words into–and that creates friction to just grabbing a pen and notepad and chicken-scratching your way through a thought process.

Sometimes, it’s appropriate to use the equivalent of a really nice, heavyweight archival acid-free paper; it adds ceremony and perceived value to something you’ve already decided is worth keeping for the ages.

But don’t forget the power of a $0.50 legal pad, a smooth-writing pen, and total apathy for reading your own handwriting later. The mere action of writing is a valuable form of thought, especially when you’re digging into something bigger than you can hold in your working memory all at once, and you very well may never need to revisit most of what you’ve written in such a case.

DONE Dwelling in Possibility

Are you someone whose bookshelves are filled with books you’ve never read? Likely somewhat sorted by category, their titles beckon with possibility, for when you’ve read them someday.

How many of those books do you actually want to read? I ask this as distinct from how many you want to have read (which is likely all of them). Which would you put aside any other tasks–including reading something else!–for the time it’d take to read from cover to cover?

My guess would be not all that many. Some books are for actually reading; some for the possibilities they represent. No real harm there; they’re just books, even if nice ones.

The Abstract Bit

What other possibilities are you collecting in your life, things you dream of Having Done, but that you probably wouldn’t make the sacrifice and tradeoffs to actually do, as opposed to all the other things to which you could commit your time and energy?

There’s nothing wrong with daydreams, nor with big goals. It’s helpful to know which ones deserve your energy, though.

DONE Do you know when to cut your losses?

If you’re taking risks regularly and deliberately, or otherwise running yourself up against the resources you can bring to bear, it’s inevitable that you’ll sometimes fail. You’ll run out of resources, or of time, or motivation, or simply realize that whatever it is you’re doing on whatever timescale simply isn’t tenable.

How will you know?

Most folks’ default for this is to delay, to push through until either burnout or to semiconsciously reduce the effort in what looks like self-sabotage. A few of us cut things early, so as not to have to face failure. As a rule, though, this means making the decision to stop in the midst of feeling as though not all is going the right way, when you’re less well-resourced and rational, less able to make a quality decision.

What if you chose your criteria in advance? If you said, I will push to this point, but not further?

This sounds depressing, but a failure isn’t the end of the world, and avoiding all failure isn’t living. On your hardest day, at what point do you say: it’s okay, I’m not going to hit my goals today?

And once you’ve determined where the line is drawn, you can give your best right up to it. There’s a freedom in setting and knowing your own boundaries.

DONE Don’t estimate how long it will take. Instead, determine your appetite.

One of the greatest innovations from the Shape Up lifecycle is one that you can steal for your own life and work: stop doing time estimates on proposed work as the primary scheduling tool. Work, like art, is never truly done; you merely stop working on it–meaning that you’ll always face pressure to grow the scope of your proposed work beyond the original plan, regardless of how conservative it was.

Instead, Shape Up proposes that you determine your appetite: if a particular focus feels worthy of your time, how much time does it deserve? Then, based on that judgment, what can you accomplish in that time?

This flips the typical Agile-inflected judgment on its head. Rather than “we must do this project; how long will it take?”, the framing is “we’re willing to give this project six weeks; what will we do in that time?”.

There’s a magic to this. It answers tons of scope questions that would normally pressure towards growth, and it focuses the mind and the team on what matters without as much pressure to add cruft.

For your next upcoming goal, if you knew you had a hard stop to your work six weeks from now, what would you aim to do?

DONE Setting the pace; following the flow

Each of us have ebbs and flows throughout our days, our weeks, our years: a half-hour each day that’s sharper than the rest, a quarter when sales just feel easier, a day of the week that’s just always faded and hard to get stuff done.

What is it that makes that so for you?

Is it in your locus of control–something about your environment that you can change, to set yourself up for the situations you most benefit from? If you remove the television from your office, do you stop flipping on the TV news? How can you adapt your environment to better suit you?

Is it more a force of nature–something that’s going to happen regardless of your planned actions? Your taxes are due the same time each year; your young child wakes up crying and needs your attention for the next hour; the economy shifts and a third of your clients can’t pay you anymore. If you plan your own actions differently and have your financials in order, does it mean giving much up right now? And will you handle life more gracefully when it comes your way? How can you adapt yourself to better suit your environment?

DONE Don’t (just) destroy all meetings

Another Meeting. You can practically taste the collective resistance, and perhaps your own desire to eliminate that time commitment, too. “Couldn’t this be a report?”, suggests a colleague. “Or we can have a Slack bot to prompt folks to check in on this”, puts in another.

“Why don’t we just get rid of all the meetings?”

Why not, indeed? It’s easy to poll folks and get answers for why one meeting or another needs to persist: some need for data sharing, a guaranteed periodic touchpoint for everyone involved, the prescribed version of the software development lifecycle framework, visibility into the current status of work in progress across reporting lines. There’s likely also to be some unreported desires involved, too: social connection amongst coworkers, some time set aside as a break from delivery responsibilities.

Those desires and needs are all very real, and you risk them going unmet when you change or destroy a meeting.

By all means: be deliberate about respecting, protecting, and valuing your time and your team’s. Deleting a recurring meeting can be incredibly powerful & deeply satisfying. But before you do, spend the effort to uncover all the needs that occurrence was addressing, not just the stated purpose–or you’ll soon find that time blocked back out of your calendar with a vengeance.

DONE Getting to the point

Many of you in the tech space are likely familiar with “pointing meetings” or “planning poker” or “sprint planning”. Without getting in too deep, the general idea is to have the members of a team close to a piece of work to be done and collectively estimate or forecast how much effort is involved. Whether you should do this at all is a reasonable question, but for the sake of the argument, let’s say that you will, and that the goal of your meeting is to have some idea of what you should plan to do over the next couple of weeks to have a reasonable shot of completing it all.

How much of your team’s time is this worth?

How much of your team’s time is a single item on this list worth?

How much of your team’s time is a single item on this list worth when everyone’s pretty close in their guess of how much effort it will take?

Across teams, clients, and ecosystems, I’ve repeatedly run into this pattern:

• a unit of work, ticket, story, card, etc. is reasonably well-defined and not obviously going to explode
• everyone on the team votes for one of two adjacent point values: a mix of just 1’s and 2’s, for example, or of just 2’s and 3’s.
• the team spends the next ten minutes deciding which of those two options to go with.

Does that sound familiar?

Does that sound like the way your team wants to spend their time?

If this rhymes with your experience–a suggestion.

Tactically: if you’ve got a pointing meeting or voting meeting like this one, and the outcome isn’t enormously consequential, and all the votes are for adjacent point values like in the examples above, prompt your team for whether anything is clearly on fire about the work unit that requires extensive discussion. If it does, you’re not going to get a good forecast, and you should plan accordingly. If not, just choose the bigger point value and move on with your life. Done.

Thematically: where else in your processes and rituals are you having extended discussions around things that ultimately won’t have a large impact? They might not be zero, but your time and effort is better spent elsewhere. How can you cut down on that expenditure so you can focus on the things that matter?

DONE What you still don’t know about Bruno (even if we talk about him)

If you’ve got kids of a certain age, you’ve probably had the experience of passively (sometimes actively) having the same song, or show, or movie play in the background dozens of times. Young kids seem to really enjoy the familiar, and after the tenth or twentieth time through Encanto, with We Don’t Talk About Bruno echoing in your skull, surely there’s nothing in there you haven’t seen, heard, and subsequently half-maddeningly hummed to yourself while driving across town.

Right?

But on that thirtieth time through, there’s still something new to be seen. The expression on a Dolores’ face in the background while others speak of Mariano’s engagement, informed by your knowledge of the plot to come. The fourtieth time: the particular way voices interweave that one place in that one song. Something new on the fiftieth. A new appreciation; a deeper understanding.

And this is a cute kids movie. It’s good, but let’s not fool ourselves that there’s more depth here than anywhere else in our lives: you’re getting all that repetition because it’s easy to get given your current circumstances.

All that complexity is happening everywhere, right now, all across your life. It’s in the subtle variation of the texture of the air we breathe. It’s in the way a stranger notices (or doesn’t) the way you step onto a bus, or into a shop.

And we can’t take it all in. We can’t: we’d cease to function as laypeople. So we filter this all down and reduce to patterns and match on them. That’s how our ancestors caught prey and avoided becoming it themselves. It’s how we get through another sprint meeting, another periodic 1:1, and prepare for an interview: we prepare, we get good at the patterns, and we match on them. And, by and large, that’s served us pretty well.

But it’s worth taking a minute to consider: what are you missing, right here in this moment, that might be worth investing a little time in re-examining? …that might be worth getting a little bit more depth?

Here’s the thing: we’re spending eight-ish hours every day doing largely the same work. Over time we get really efficient at it by refining our pattern matching, and that’s largely desirable. But we’re working in our lives and working with other people living theirs, and there’s something magical about discovering the nuance and depth available even in the midst of this daily routine. So tomorrow, pick a time, and when you’re right in the middle of the moment, consider: what’s everything that’s happening right now, especially the subtle stuff in the background that would normally go unappreciated? You might surprise yourself.

DONE A bit of audience exploration

So, this is still early days around here. My hope is that getting in the rhythm of writing for this list daily will in and of itself drive clarity of thinking, and help best serve you, gentle reader, and your surrounding audience.

But that requires that I have some idea of who I’m writing for. With the understanding that this will shift and refine with time, who will find this artifact the most useful?

Who’s this all for?

You care, deeply, about how people work together. Business needs, personal and team productivity, and the eventual deliverable product all matter, but you’re really looking for ways to be truer to yourself, in your work and in how you interact with those around you.

Yes, we’ll work to make you and your team more productive. We’ll do it by getting back to ourselves: less cogitating, more enabling.

I’ll revisit this as we refine, but want the early version out there–so you can see where this started.

Okay. Let’s start.

DONE The life-changing magic of baseline and stretch goals

Goals are a funny thing. It’s helpful having a challenge, something to reach for, to give you a direction beyond mediocrity, but it’s discouraging and motivation-killing to fail repeatedly at something you’ve committed to. A lot of the challenge of setting goals has historically been self-awareness and pedagogical wisdom: you need both to consistently set goals that will calibrate a productive struggle, so that you’re neither bored nor doomed.

Trouble is, that’s a big ask–and a separate skill all in and of itself. But it doesn’t need to be!

Different goals for different purposes, all in the same time block

The aims here are to:

• get a rhythm of successes, and
• to have something to strive for.

Lumping those into the same goal is obvious, but unnecessary. For a given time block or work cycle, be it a Pomodoro, a year, a sprint, or between now and your next meeting, try splitting your single aim into Baseline and Stretch goals.

Baseline: an easily-achievable goal that allows you to declare Victory.

I find aiming for something that’ll take about a quarter of the time block I’m working with is a good fit.

> Did you set aside 25 minutes to read a chapter? Set your baseline for getting through the first two or three pages. Are you trying to go from zero to $100/month of recurring revenue on a personal project this quarter? Your baseline goal might be to get five subscriptions.

The crucial element of the baseline goal is that there’s a no-to-low chance of your missing it. Even if you’re not in love with getting “merely” that much done in a given time block, knowing that you’re setting a goal and hitting it is the whole point. It builds momentum and mitigates that sense of failing.

Stretch: a goal that you’ll be excited if you hit.

Here’s where you give yourself a challenge. As best you can, pick a goal for the same work block as that baseline goal that you’d be really pleased to hit–not necessarily surprised, but enough of a stretch that you won’t be disappointed if you miss it. Over time, I’ve found I like to aim for about a 70% hit rate for my own stretch goals; you may find a different proportion is the right balance for you.

The thing is, you don’t even need to worry about your stretch goal when you get to work. If you don’t hit it, you haven’t failed. But it’s awesome if you hit it!

How big a time block should you use for all this?

I mean, really, all of them. That said, a handy thing about using baseline and stretch goal framing for unit-sized work cycles (a Pomodoro, a segment of a focus block, whatever works for you) is that you can pretty quickly calibrate your goal framing for future cycles. Setting a baseline and stretch goal for the next 25 minutes four times in two hours gives you a lot of opportunity to reflect in the middle of your workstream, and can give you the sensation of tangible progress just as often.

Oh hey, this is actually pretty enabling!

Yeah, it is! As you grow more comfortable with goal-splitting like this on an individual basis, you’ll find it maddening to do anything else. I love taking this framework to teams that work with time-boxed frames, like sprints or spikes, and helping define what we can consider sufficient and what we can consider awesome as different things.

Give it a shot!

Next time you’re getting ready to sit down for a block of focused work, take a minute first to sketch a conservative baseline goal and a fist-pumpingly awesome stretch goal. When you’re done with your time block, reflect and see if hitting that baseline helped, and if having something further to reach for kept you from puttering out after hitting that first goal.

You might just find yourself addicted–and saved from the stress of having to perfectly calibrate goals on work you haven’t even started yet.

DONE Attention, agency, and the direction of time

How do you choose how to direct your attention?

Are you reacting, as opposed to responding? Something pops up and appears urgent, you forget what you were doing before, or will soon enough. You can easily end up on a flywheel of reactivity here, with a procession of ever-more-urgent demands on your attention causing the long-term things to get neglected, resulting in more emergent demands on your attention, quickly overwhelming your sense of agency over your time and attention and life.

Are you in autopilot mode, with your brain going into energy-saving activities? Vegging out, social media and its simplistic casino-like dopamine hacking, television you don’t even like…unconscious habits you don’t actually desire, but often don’t dislike enough to fight.

Are you deliberately relaxing? You’ve got to do this at some point. If you don’t schedule downtime, it will be scheduled for you. Is it addressing a weight or otherwise obliterating a distraction?

Is it future-oriented? Are you doing a thing that may not feel good or even not-bad immediately, but is in the service of a greater good—be it your own or something more macro?

In the middle of doing the thing, it’s worth asking yourself: is this about what just happened, or about what you want to have happen?

DONE The simple way or the right way?

You’ve got a reasonably well-defined problem ahead of you, and a couple ways to go about addressing it. Reductively, you can see there’s a simple, lightweight way to fix it right now, and a more complex way that takes into account some future possibilities.

You’re having a hard time deciding.

What has you questioning the path? Do you have a cognitive sense for what the “right path” is, but some internal resistance to going down that route? If so, I’d explore why the resistance–often your gut knows more than your mind.

That sounds very woo/hand-wavey, I’m aware. Specific examples might be “I can solve this with a somewhat complex ‘right’ approach, but have resistance because I’ve tried this before and it caused pain”, “I have a ‘right now’ simple fix, but recall having to rework something that felt like this before”, “I know the right way to do this, but am too tired to start on a Friday and don’t want it hanging over me”.

DONE How did you decide to do that thing?

The thing you’re doing right now. What is it? Why are you doing it?

Okay, how about now? And does that match with what you thought you’d be doing today?

So often, we describe the thing we intend to do, or the thing we’re doing, as Our Current Priority. And in some sense, that’s always true: we gave it our attention before something else. But the word Priority can be so much more powerful, so obvious, if only we’ll let it be so.

Let’s break this down a little: most of the time, the thing you’re doing is:

• a habit
• a preference
• an actual priority

If you had to think about doing it, and decide over something else, it’s probably a preference. If you’re doing it automatically, it’s probably a habit. Nothing wrong with that! Habits and routines are most of what gets anything done. If you dropped something you were in the middle of to do this thing, especially without having to think about it, it’s probably a priority. Emergencies are when a priority is threatened in the moment.

Once we give Priority the strength to mean what it should–the way you act when your child falls and starts crying, or your entire dashboard goes red–it’s easier to discern that much of the rest of our daily behavior is habits and preferences. And that’s where you can get empowered.

The likelihood of you deliberately changing your priorities is very low. That’s actually kind of the point. We want to change other stuff in service of our priorities.

So we can focus on the other stuff. If you want to change a habit, you need to plan ahead of time. (That’s a long topic, covered delightfully well in James Clear’s Atomic Habits or more concisely in Tiny Habits). If it’s a preference you’re acting on, though, I suggest you first check in on whose preference it is in the first place. Is it your stated preference? Your boss’s or client’s? Your spouse? Essentially, what are you trying to satisfy here?

By splitting off the many things that are mere preferences and habits, we give ourselves the space to actually think about the real priorities–the parts of our lives that we value the most–and to stop binning them in the same place as preferences and habits. Our priorities deserve better.

And then we can decide to act on them, even when they’re not emergencies–to make the space for what’s important, at the justifiable expense of what’s loud or has inertia.

DONE Working wounded

If you’ve been reading up on knowledge worker advice columns over the last decade or two, you’ll have run into what seems like a perfectly reasonable piece of advice: build up a store of brainless tasks that you can dig into when your motivation is lower. So, for example, plow through your email in that not-quite-siesta after lunch. Deal with your taxes when you’re fried. Store up your admin stuff for that rainy day when you’re just not up to the creative work.

The trouble is, this doesn’t address the whole problem. Yeah, when you’re tired and in the process of scrubbing your inbox, you can probably do one more. But what about those days when you scarcely slept, and even opening your Gmail account feels like a major lift? Or you’re still getting over the latest round of Covid, and your body feels like crap?

What about the walking wounded days?

Know when to fold ’em

Before the Tactics part of this little topic, let’s be real: there’s gonna be off days that need to be days off. If you literally cannot today, then don’t force it. If your work arrangement means you can be officially out, great; if you have to kinda idle in place, do it and recover. It’s worse for everyone involved (clients/customers included) if you burn yourself out further.

The metric was wrong

That said, how can you make some use of those hours and days where you’re not up to where you want to be, but aren’t flat on your back? I’ve found that the barrier to progress isn’t actually the “braininess” or complexity of tasks (though those are certainly harder). It’s getting started.

The focus on queueing up stuff that doesn’t require brainpower to finish doing was misguided. You need stuff that doesn’t require willpower to start doing.

Less “easy”, more “not awful”

What stuff do you find easy to fall into doing almost on autopilot, regardless of how zonked you may feel? It probably isn’t your bookkeeping (though you do you, friend!). Try these on for size:

• Read a page in a work-related book & take an action note for future reference
• Do two minutes of your favorite mindfulness exercise
• Clean your current workspace (which as a bonus will reduce distraction cues)
• Review your tasks for today and decide which ones not to do

What works for you will vary; you’re the expert on you. But consider what feels natural to start, not just what you’d entrust to a less-resourced version of yourself.

DONE How can I keep a good work-life balance when working from home?

When Covid slammed into our society last year, many of us found ourselves suddenly working someplace new—not just working remotely, but specifically working from home. A lot of the conversations around this could be pretty frustrating to hear: the reduction to “this is so much easier & I’m far more productive!” vs. “this is isolating and impossible to get anything done!” without allowing for circumstance. Working from home has a lot of potential upsides, yet comes with unique challenges: screaming kids and barking dogs in the middle of a Zoom call; getting distracted from work by the never-ending laundry (and then getting distracted from the laundry by never-ending work); the endless schlick!-ta-ta-ta of Slack notifications at all hours; that nagging feeling that, whatever you’re doing, you should be doing something else—all taken together, it’s easy to have the days blend together into a stressful, unrewarding mush.

Fortunately, there’s some techniques you can use to mitigate WFH’s downsides, so you can get back to finishing your work & living your life, and to enjoying the advantages of your situation. Today, let’s enable better boundaries between work and home by separating your work and not-work environments.

We humans are all creatures of habit, driven by cues in our environment. Did you have a favorite class as a kid? You’d step into the classroom and time would just slip away, before the class even started. Or perhaps you’ve had the experience of settling into the same reading nook for months or years on end and just falling into your book. What’s going on here is more than one good day in class, or a couple of good pages of a story: your mind learns to associate place with action over time, and so entering that place sets you up for the associated action. It’s why you can sit down in your car and find that you’ve turned the keys without having thought about it. With this self-knowledge, we can set ourselves up for a better life with a few easy steps.

First, set aside a space for work—and only for work. (It’s probably not your TV-facing couch.) The classic example is having a whole room as an office, but not only is that out of reach for many of us, it’s often misleading: a private office gets used for work, sure…and maybe some gaming, and cross-country family Zoom calls, a pet’s bedroom, a spare bedroom, kids’ playtime spillover, and so on. Offices are often full of distractions. The key here isn’t about your floorplan; it’s about how your brain interacts with your environment. If you’re in a small space or a studio, carve out a corner of a table that’s For Work Only. If you do have a whole room to dedicate to work, fantastic; just beware slipping into multiple uses, and if that’s unavoidable for you, consider if just part of the room can be truly only for work.

Then, grab a seat (or a stand) at your work spot, and observe. What’s in your field of vision? What do those things make you think of, or want to do? Is there mess? kids toys? the family calendar? your guitar? Yeah, move all that %$&@! The goal is to not have stuff in your environment that’ll cue you to do something other than the work you want to do—and vice-versa when you get to the fun stuff. This might mean turning your Space For Work towards a wall, which is fine (and pretty typical anyway). In-view Stuff that truly doesn’t cue you towards action and distraction, like flowers and decor, is usually fine, but if you’re not sure, find it a new home.

Okay, you’re ready! When you’re ready to work, plunk down in your new spot and get to it. When you’re not working, don’t use that work spot. Over time, you’ll find that you habituate to that particular environment telling your mind and body that it’s time for work. Getting started will be easier, and getting distracted less frequent. Likewise, you’ll find work-related thoughts and compulsions are less invasive in your non-work life: no more urges to check your work email when you catch sight of your laptop while cooking dinner.

And just like that, you’ve added better boundaries to your life. If you found this helpful & want more, add your email to my list below!

DONE “I had to do it. I couldn’t not do it.”

When Trent Reznor submitted The Downward Spiral to Interscope Records cofounder Jimmy Iovine, he offered an apology. “Sorry,” Reznor remembered saying in a 2016 interview with Beats 1 host Zane Lowe. “I had to do it.”

Apple Music liner notes to The Downward Spiral

It was June 4, 1979, the first time I went on stage. I didn’t know I could do it but I knew I couldn’t not do it. I quit everything in my life and this was the one thing I couldn’t quit.

George Lopez

We’ve all heard this from the heroes, the succeeding class, the Passionate People: that their work calls them, beckoning, that they literally cannot not do the work.

That…that must be nice.

I am a grown man, a husband and father with a few career changes, more than a few grey hairs, and a list of responsibilities that grows by the hour. I am in the extraordinarily privileged position of being able to choose my work: having the expertise in a pretty broad set of fields, running my own tiny consulting firm with all remote clients, working with reasonably fresh technology to build new things.

Let it be known that I am fully capable of not doing the work. The first week back at work after my wife was recovered-enough from Covid-19, I think I billed something like $400. And I played a lot of The Witcher III (which is fabulously fun).

I have a list of past and potential clients to follow up with, projects to kick off, essential skills to learn, marketing and outreach and everything involved in growing a small business. And I love it. It’s work that excites me. And–again–I am fully capable of not doing it.

Messrs. Reznor and Lopez and so many others have a drive that I simply cannot relate to. My own truth was much better worded by the late Anthony Bourdain:

I understand there’s a guy inside me who wants to lay in bed, smoke weed all day, and watch cartoons and old movies. My whole life is a series of stratagems to avoid, and outwit, that guy.

Anthony Bourdain

Let me be honest: being that guy for just a day sounds fucking amazing. The trouble, of course, is that it becomes a problem when it’s more than “just a day”.

My own strategems for self-care, -discipline, -productivity, what-have-you all fell on their face when I spent a few weeks on 24/7 (and I do mean 24 /7) childcare while scared shitless that my wife would die. And they don’t automatically come back. And then the second arrow strikes as I beat myself up for not getting done what I want accomplished.

So, where to from here? Still mid-pandemic, with mouths to feed and mental health to attend to. It’s starting here: with an unedited and rushed-out blog post to own that I’m running at half-capacity at best and that no one else will do shit about it. And it goes to what I know: to move anything, start by moving the body.

I have to run. Until my legs shake, until I’m scared my middle-aged knees will let go in mid-stride. I can’t not do it. Not because I can’t not do it, but because I know what lies down the path of not doing it–and that’s not living.

DONE Do it. Just publish it. …PUBLISH.

It’s okay, self: you’re (well) over thirty, with the grey hairs and growing child to show for it. Leave for another day the manifestos, the interconnected concepts, the fully-realized Word leaping fully formed from the forehead.

Resist even the urge to pause here in medias res to backfill thoughts and to grasp. See the grasping, and let it go.

Humble beginnings are just that: beginnings. Let this be mine.

TODO Responsibility and Guilt

Personal, relational, intergenerational, business, starting stuff

Childhood perspective: came out understanding these as almost synonymous and definitely inseparable. Had to tear this apart when facing my own shit and understanding that guilt for my challenges could be distributed but responsibility for managing them was mine, and that that responsibility did not directly mean that all the guilt was mine. Work: responsibility (neé control) needn’t imply auto-guilt-tripping; Cf. Hoy podcast

TODO On systems, insecurity, and fear: US post-911, the Catholic Church and child abuse; more?

TODO Near-term, near to my heart

To cover:

• Remote work
• Getting your first remote gig
• Getting into a technical role without a formal background
• Organisational systems
• Writing, process, product
• Adventuring

TODO Working title

What do you actually want in life? Interesting that this is so assumed and unaddressed. American Dream, right? Handy reference link: http://www.oprah.com/spirit/how-to-figure-out-what-you-want-in-life/all Also Eleanor Roosevelt quote

TODO On building habits when every day is different