Index on Dylan Fitzgerald

Don't decide who you need until you've determined what you need

Thu, 04 May 2023 19:16:00 -0600

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.

A bit of blog metawork

Wed, 03 May 2023 19:17:00 -0600

The last couple weeks had too much going on for me to keep the daily post schedule regardless, but I think I can make things a little more frequent by reducing posting friction. To that effect, baby’s first elisp:

;; open blog source file
(find-file "~/org/sites/dfnet-blog.org")

;; save file
(save-buffer)

;; use magit to stage changes
(magit-status)
(magit-stage-file "~/org/sites/dfnet-blog.org")
;; actually do the commit by shelling out to git
(shell-command "git commit -m 'update blog'")

;; use ox-hugo WIM to export full tree to markdown...maybe
;; it seems to have issues with image prefixes?
;; (org-hugo-export-wim-to-md :all-subtrees nil)

;; change directory to ~/sites/dylanfitzgerald.net/
(cd "~/sites/dylanfitzgerald.net/")

;; build hugo site
(shell-command "hugo --gc --minify --enableGitInfo")

;; stage, commit, push
(magit-status)
(magit-stage-modified :all)
(shell-command "git commit -m 'update blog'")
(shell-command "git push")
(magit-status)

;; build docker image
(shell-command "docker build -t arubis/dfnet:latest . --push")

;; reload image into k8s
(shell-command "kubectl rollout restart deployment/dfnet-blog-www-app")

;; clean up? want logic to do this only if it wasn't open already
;; (kill-buffer "dfnet-blog.org")

It works? The real trick is to stop myself fiddling further before I whittle away the gains I’d get from this automation.

Overall, I’m going to start emphasizing less hands work and more head work here as I get more deliberate in my audience selection. I hope you’ll be there!

Shaping In The Real World

Wed, 03 May 2023 15:08:00 -0600

Heading through the Shaping In The Real World course. I’m looking forward to pulling out insights on how to do piecewise applications of this framework with clients.

Spring has come to Denver. I almost trust it–Mother’s Day is about when I expect not to get more snowfall. Thank goodness; that was a long winter.

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

Wed, 03 May 2023 15:03:00 -0600

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.

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

Sat, 29 Apr 2023 21:10:00 -0600

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.

So you've got a suggestion

Fri, 28 Apr 2023 19:25:00 -0600

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.”

Figure out the reward before you start the work

Thu, 27 Apr 2023 12:42:00 -0600

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.

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!

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.

The supply and demand of getting shit done

Wed, 19 Apr 2023 16:42:00 -0600

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.

Jumping into a new system

Tue, 18 Apr 2023 21:10:00 -0600

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.

The obligatory GPT acknowledgment

Mon, 17 Apr 2023 20:54:00 -0600

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:

[SYS]: You are a helpful assistant.

[ME]: How can I use the principles of solution-based brief therapy to help a business leadership client understand their own values and priorities?

[AI]: Great question! Here are some steps you could take to help your business leadership client understand their own values and priorities using solution-based brief therapy principles:

Identify the client’s goal: Begin by clarifying with the client what they hope to achieve from this session. What is their desired outcome?
Explore exceptions: Ask the client to identify times when they felt they were living in alignment with their values and priorities. This helps the client recognize that they are capable of living in alignment with their values.
Identify strengths: Help the client identify their personal strengths that have helped them achieve their past successes.
Identify the client’s values and priorities: Ask the client to identify what is most important to them in their work and personal life. You can ask questions like “What do you value the most?” or “What brings you the most joy and fulfillment?”
Help the client examine their actions: Encourage the client to examine how their values and priorities are reflected in their actions. Are their actions consistent with their values and priorities?
Reframe the problem: Reframe the problem from what’s wrong to what’s right. Ask the client what they would like to have more of in their work and personal lives.
Focus on the future: Ask the client to identify what their ideal future would look like, and work together to create a plan for achieving that future.

Through these steps, you will help your client understand their own values and priorities in aligning them with their work and personal life goals.

(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:

[ME]: Please create a new application in Ruby on Rails. The application allows a user to log in, select a donation amount from the set $5, $10, or $20, and then proceed to pay my account that amount using Stripe.

[AI]: Creating a complete Ruby on Rails application with Stripe integration is beyond the scope of this text-based platform. However, I can provide you with a high-level overview and some code snippets to help you create the application yourself.

…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?