Adam Keys is Thinking

Ben Kuhn, Categories of leadership on technical teams:

More importantly, though, we often want to somehow split these responsibilities between people. Team leadership covers a huge array of things—as you can see from how long this post is—and trying to find someone who can be great at all of them is often a unicorn hunt. Even if you do find someone good-enough at all of them, they usually spike in 1-2 areas, and it might be higher-leverage for them to fully focus on those.

If you find yourself in a wholly new team, this might help you find your way to traction. If you find yourself confused by the (rapidly) changing nature of work and need to zoom out on the team/role you find yourself leading, this will help!

Even if you’ve been in your job/team/organization for a while, to paraphrase David Byrne, “You may tell yourself, this is not the job I signed up for! / My god, have I have I done?”, in which case this mental model is also helpful. (And, good luck!)

Herein, a napkin sketch on producing creative work, ideas on finding the spark(s) that consistently lead us to assemble new things, and the hand-wavy stuff in-between.

Production is connecting the dots

Extensively, manically, collect ideas (i.e., dots). Collect ideas, put ‘em in order. This is the tricky-but-fun part!

Boom, that’s something new! Like this essay. Collect, connect, write, post, again and again.

Austin Kleon, It’s not inside you trying to get out, it’s outside you trying to get in:

I never feel like I have a book in me. I always feel like there’s a book around me. It’s like I’m a planet and there’s all this space junk orbiting me, and all the junk starts smashing together and forming book chapters. My job is to grab that stuff around me and shape it into something.

Production is making social connections

So you’ve got a routine of journals and notes and active reading and such. You’re turning those into blog posts and thinking with the network, right?

In particular, using networked writing (hypertext, social media) as an attractor for ideas and likeminded folks. Repeatedly engaging with those folks until a new, boring status quo/local maximum is reached. Iterate and seek ever higher peaks.

Tom Critchlow, Small b blogging:

Small b blogging is learning to write and think with the network. Small b blogging is writing content designed for small deliberate audiences and showing it to them. Small b blogging is deliberately chasing interesting ideas over pageviews and scale. An attempt at genuine connection vs the gloss and polish and mass market of most “content marketing”.

Henrik Karlsson, A blog post is a very long and complex search query to find fascinating people and make them route interesting stuff to your inbox:

The reason I’m spelling out this dynamic is twofold. First, you can get out of this mess if you want to. You do that by writing online (or publishing cool pieces of software, or videos, or whatever makes you tickle—as long as you work in public). Second, if you want to get out of the mess the key lies exactly in understanding that you are not the only person who has no one to talk to about the things you get obsessed by.

Production is a second-order outcome from consuming/reading

Consider two sorts of people: “Really Into Notes” or simply “An Enjoyer of Reading”. Either way, making things and ideas comes from connecting an idea from what you read, enthusiasm for making, and the discipline to turn that enthusiasm into action. How and what you turn that action into is left as an exercise or implementation detail up to the reader.

Andreas Fragner, Writing Summaries Is More Important Than Reading More Books, if you’re a third kind, “Extremely Okay With Marking Up Your Objects”:

One thing I’ve learned over time is to read fewer books but to take the time to write summaries for the good ones. The ROI of spending 2h writing a synopsis is much higher than spending those 2h powering through the next book on your list. Reading is not about page count or speed [1]. What matters is how it changes your thinking and what you take away from it. Optimize for comprehension, not volume."

Production is doing the thing you can’t not do, a vocation

Maybe it’s writing, but it’s cool if it’s not. Putting all these ideas together yields something new in the world, literal creativity. That calling, no matter the ambition or profitability or fruitfulness, is different for all of us. But we can all work the skills that support that creation.

Jared Henderson, AI won’t replace you, unless you let it:

Similarly, there are men and women for whom being an artist if their vocation. It is what they most suited to do. I believe that determining and pursuing your vocation – even if your vocation is not your job – is crucial for a good human life, because it puts work in its proper place. Work ceases to be toil when you are pursuing your vocation.

Tools for thought are nothing without producing ideas and publishing them.

There are things you can only learn by negative experience. In these cases, you just gotta go out there and suffer:

• Lose your first 50 games as soon as possible (Go proverb)
• Struggle through your first 50 interviews (hiring or seeking)
• Awkwardly run your first 50 meetings
• Flail at leading your first 50 projects
• Bomb your first 50 jokes

I won’t keep you waiting or give you false confidence with a snappy conclusion. Get out there and make some mistakes!

Robert Fripp via Austin Kleon, The Meaning of Discipline:

The musician has three instruments: the hands, the head, and the heart, and each has its own discipline.

So, the musician has three disciplines: the disciplines of the hands, the head and the heart.

Ultimately, these are one discipline: discipline.

Bear with me as I try to apply this lively metaphor of emotion and musical creativity to dry-and-boring engineering leadership¹.

The leader’s hands gesticulate, often for the aid of the speaker more than the listener. Sometimes, the hands conduct the thoughts to written words through the keyboard. Not too dissimilar from a musician’s hands through which, crucial for (most) musicians to make their sound, but equally a bit of flair.

The head thinks, and overthinks. Sees patterns and connects the dots. Listens to what people say and answers their questions directly and honestly. Is convinced it sees patterns in randomness, or that folks are hearing and understanding a message that they find confusing but don’t know how to address the issue.

The heart, for the leader, is there to mediate the head. There are other people on the other side of the decisions and decrees leaders make. A process or strategy is only good if it does right by those carrying it out.

Discipline is our capacity to make a commitment in time.

Discipline, in leadership, is to make a decision and then support the people executing that decision. All the while, seeking new information by which you might update, revise, or set the decision aside, if necessary.

To have sitzfleisch means the ability to sit still for the long periods of time required to be truly productive; it means the stamina to work through a difficult situation and see a project through to the end.

✋🏻 management by walking around

👉🏻 leadership by sitting down² and engaging with the people doing the work

Even better: leadership by sustaining long period of assimilating what the team and meetings are telling you into a slightly better way of working. And sometimes, memos and slides, etc to send out and socialize ideas for you.

Mike Hoye, Fifty Years of Diff:

My friend Greg Wilson has argued, and I absolutely believe, that you can divide the entire computational universe into who has diff and patch, and who doesn’t. It’s the seed crystal of all workable open collaboration, and people living without it don’t even have the language to recognize how bad they’ve got it.

Re:re:RE:DRAFT-draft-V7-FINAL-FINAL2.doc is just no way to live, and if you live in word processors, spreadsheets, slides, art, anything without diff and patch you’re definitely feeling this pain, even if you don’t have a term for it.

Yep. diff, along with its trusty companion patch is a developer superpower. (Even though patch came 10 years later, apparently, TIL.)

diff made source control possible, so I have to think it’s in the top 5 accelerants to software development of all time¹. Let alone using diff or patch under the hood in systems to move changes around.

Even the concept of diff is a big deal!

Part of the superpower of being a developer is the idea that you can analyze two pieces of data with a common lineage, extract the changes, and work with/reason about the changes as first-class data. Were it only that more non-developer tools had this capability!

Writing from notes is a bootstrapping problem. Anything you can do to get started, overcome static friction, and “defeat” the first blank canvas is the best thing you can do.

I started with journaling. Don’t worry about the quality or quantity — yet. Just write. Start with recollections of your day(s) and branch out from there.

There is a trough of despair, at some point. It may feel like you’re just writing into a void. Don’t reach for a “crushing your notes” course on YouTube. You’re writing now, it’s not unusual for it to take a moment (days, even weeks) to click.

Next, I started reading actively and taking highlights. Tools don’t matter here. The outcomes you’re looking for are 1) getting more out of the reading than if you didn’t mark the passages that grab you, 2) coming back to the good stuff later. It’s nice that highlighting, even on mouse-and-keyboard computers, gets your hands moving and involved in the reading process.

Once I crested about a hundred notes/journals/highlights/etc., the next level was resurfacing past notes and revisiting/rewriting/reworking. I use random resurfacing of notes¹, “on-this-day” resurfacing of journals², and spaced repetition of highlights via Readwise. These generate insight, nostalgia, and (sometimes) the spark to connect the dots of enough ideas that a new draft comes into existence. That’s a big win! Honestly, even writing up a new note connecting some older notes or highlights feels like the system is working _for _me.

On a great day, the combination of resurfacing mechanisms and a bit of luck leads “a perfect post”. That is, one that connects old insights to new ideas, a quote that backs up the new insight, and a recently generated idea that ties it all together delightfully³.

Now I had a compounding loop of making new stuff (journals) and revisiting old stuff (highlights). Time to look for connections between them, and notice how the quality of the more recent stuff is improving over the older stuff. The temptation, particularly in a world of influencer media on note-taking⁴, is to get a Big System to Lead You Right To The Big Connections in Your Thoughts. You don’t need that, you’ve got one sizzling away in your noggin, right now.

The revisiting and revising and rewriting is how you end up making the connections. The last generic tool I’ll recommend here is a good-old blog. For me, the insights and connections first came to me in short form, link posts and asides⁵ if you will. Over time, my insights grew into a ton of notes, journals, and some short-to-medium length⁶ writing on this blog.

In other words, what you require is not just a blog, but a blogging habit. Not just a journal, but a journaling habit. Not just the desire to connect the dots, see your ideas compound, and point proudly at a volume of work, but the habit to make all those things happen.

Possible next levels in my process, use the blog:

• as an iterative series of first drafts (see 15 rules for blogging) and
• as a way to figure out _what I think_by writing my way through it.
• worrying less about writing down what I already know⁷

Slash pages:

…are common pages you can add to your website, usually with a standard, root-level slug like /now, /about, or /uses. They tend to describe the individual behind the site and are distinguishing characteristics of the IndieWeb.

This sort of thing is what makes personal/humane-scale websites the greatest. So many adventures to choose from!

My favorites, already in place here:

• /about – “a page all about you”
• /blogroll – “a list of other sites that you read, are a follower of, or recommend”

And the ones I need to get off my butt and implement:

• /uses – “details of the things you use on a daily basis”
• /colophon – “a page that describes how the site is made, with what tools, supporting what technologies”
• /hello – “a single page listing the ways that you prefer to keep in touch”
• /now – “a page that tells you what this person is focused on at this point in their life”

Adjacent: Microfeatures I Love in Blogs and Personal Websites.

Steph Ango, Style is consistent constraint:

“Collect constraints you enjoy. Unusual constraints make things more fun. You can always change them later. This is your style, after all. It’s not a life commitment, it’s just the way you do things. For now.

Your constraints generate your style. 🧠

Yet again, the grass was not greener. I did learn a little more of simplicity-by-reduction. I asked myself, what Obsidian plugins or idioms am I using because someone else seemed to benefit a lot from it? Then I stopped using the ones that weren’t actually doing much for me. 💪🏻

I don’t need daily notes. That’s for the journal, which happens elsewhere. Daily notes might actually make my note-writing worse because I’m not above a perfunctory streak-preserving note.

It might even be the case that Muse is the right connecting-the-dots notes tool for me and Obsidian is more like a long-term development tool for preserving, archiving, and evolving ideas. 🧠

One of Obsidian’s advantages is the data is not opaque, its files in folders. I should use Finder more! It’s very good for dragging files around and considering organizational hierarchies. 🤷🏻‍♂️

I thought just buying Bear (it’s not expensive!) would cut the envy knot. It sorta did, so that was nice for about a day. Then, almost immediately afterward, I caught word that Obsidian’s previously-vague “mobile improvements roadmap” turned out to be “improved load-time” which is half of what I wanted. Timing is everything, folks! That said, native macOS/iOS apps are just excellent and I hope the Obsidian developers can close that gap.

As far as how to use Obsidian without getting nerd sniped: Tom MacWright and Matt Stein have the right idea. At least, not too nerd sniped. 🤦🏻‍♂️

Should internal narratives, and the philosophies they generate, be among the guarded proprietary info within a company¹? The stories the company tells the outside world are more about marketing and serving a purpose. Not those stories.

In particular, the stories the company tells itself to generate the culture and conditions for its success (or not). How it really happened, and what does that mean for where the company is now? They’re not exactly running to the press to tell the story².

Te scar tissue, what caused it, how that’s reflected in the process today? That’s guarded info, not eagerly shared in blog posts and conference talks. At least, not the entire truth.

Granted, many stories are used for building an image and marketing. To investors, competitors, potential hires, professional communities, etc. Or even to help teams internalize the purpose and goal of what they’re building today.

There’s a term for the people who’ve been around to witness these events and craft these stories — the old guard. They’re almost literally guarding the stories or narrative, but also guarding the way of working that made those stories a success.

These stories are often divorced from the reality of how the much bigger company now operates!

Narrative is powerful. Makes sense to guard it³. Both for alignment, but also for preserving myths that hold that purpose up. Myths that come from true stories. Myths that were constructed/embellished for marketing or aiming throughout the company’s existence.

Tall tales and fables by the campfire: now for corporations, too!

Thorsten Ball with a great reference to Comedians in Cars Getting Coffee. Be findable:

You’re in your apartment watching TV, and they knock on the door, like “Jerry, I’m Dave Addison from the Show Business Commission. We understand you got enormous talent and tremendous potential and you don’t know what to do with it, and there’s really no bridge or no other conduit which will carry you over to the next level, which is why we’re here. We’re the Show Business Commission. We’re here to sort of collect you up.”

No one is going to discover your work spontaneously. Making your work discoverable is part of the work. It’s not bragging or obnoxious. Unless you’re habitually obnoxious, in which case a little self-promotion is the least of your problems!

100 Tips for a Better Life:

95. Some types of sophistication won’t make you enjoy the object more, they’ll make you enjoy it less. For example, wine snobs don’t enjoy wine twice as much as you, they’re more keenly aware of how most wine isn’t good enough. Avoid sophistication that diminishes your enjoyment.

Teaching someone the depth to something like cars or pens or literature is a gift and a curse. On one hand, you’re showing them a new, deeper world that they might really enjoy and find fulfillment in. On the other, they might realize something like “a true classic Porsche 911” is out of reach or that the pen they like is kinda middle-ground or that their favorite sci-fi author is kinda schlocky.

Maybe the gift is “this is amazing, but it’s a bit of a forbidden-knowledge hazard to know you could have this thing.”

The classic knowledge hazard for me, is One car to do it all. If that video hadn’t re-awoken my excitement for Porsches I would have a much more boring car, a lot more time back in my life, and mid-five figures of money spent otherwise. But maybe I’d have missed out on a fun hobby. 🤷🏻‍♂️

Riffing on this idea:

“If you want to upset a person for a day, tell them their car sucks. If you want to upset them for life, show them how to appreciate the automotive experience in a way that they will plumb the depths of for the rest of their days.”

“If you want to upset a person for a day, tell them their taste in music sucks. If you want to upset them for life, show them the first step in the journey to seek out and appreciate the depths of really great music despite the knowledge that the most popular music is an entertainment business and will never reach the levels which you aspire to.”

Enjoy things, seek out the finer details of what makes them nice. Not too much. Mostly things that don’t cost more than your monthly mortgage/rent.

Previously:

The only way to finish writing, planning, coding, designing, etc. is to do the thing.

Rarely will new tools, larger scope, a different approach, another section, more tidy, or any other number of not doing the thing finish the job.

Finishing is the skill. Finishing is The Way.

Conjecture: the last 90% of a project is 90% of the effort because we rarely develop the skill of finishing.

It’s easy to think “this project was doomed from the start, let’s start a new project to right our mistakes”, and boom you’re starting instead of finishing.

Finishing may incur damage to pride, reputation, etc. OTOH building a reputation for finishing is a tremendous asset in teams and careers.

You probably haven’t heard of many people who didn’t finish their thing.

Schubert had to write nine symphonies so he could write “The Unfinished” Symphony and have it live on hundreds of years later. Is there a writer who is only known for one unfinished novel or screenplay?

Starting a new thing is more fun than finishing an existing thing. This is always the temptation! The interesting things in a project usually happen when you’re starting and when you’re getting feedback from people interacting with it. The finishing phase is often the “canyon of disillusionment” where all the mundane or tedious tasks end up.

Updating another earlier thought:

✋ We’re not here to work on things.

👉 We’re here to finish things.

Corollary: we’re not here to push JIRA issues/Trello cards/etc. around. We’re here to make something and share it with the world.

Don’t neglect those issues/card¹. Finishing is important, but communicating that progress counts for a lot too! There’s no sense in finishing if no one else knows.

Austin Kleon, A few notes on daily blogging:

With blogging, I’m not so sure it’s about quantity as much as it’s about frequency: for me, there’s something kind of magical about posting once a day. Good things happen. Something small every day leads to something big.

Maybe it’s not so much quantity that builds the quality, but frequency and consistency.

The traditional prescription for keeping software easy to work with and amenable to change is “refactoring”. As we’re fixing bugs, adding features, and making new possibilities, we investigate how to change the structure of code so that correcting, changing, or adding behavior is easier. In reverse order — we should make the change easy, then make the easy change to achieve the desired results¹.

I may not surprise you in suggesting that’s often not how things actually work out.

Some code, processes, or data are inherently complex or crystalized in path dependence. After our first urge to simplify is stymied, move on to the second possibility: live with and document the complexity, then keep moving². Everyone wins.

Documenting code is a great forcing function for simplifying it. When I look at code with the intent of writing down how to use or understand it, my perspective shifts, and I’m more aware of the missing affordances. A clarifying parameter name or perhaps a simpler calling sequence. So I make that change (aka refactoring) as part of the process of documenting the code. Everyone wins.

The same goes for processes and data. Writing down how to fix an unprocessed payment or restore data after an accidental deletion flips my perspective enough that I’m not seeing it in the weeds. I can see opportunities for automation, so I take them. Or I can see how to improve a data structure such that errors are obvious to humans or detectable by computers. I make that change, everyone wins.

It’s not always possible to find these little wins. Occasionally, we don’t win!

Some systems, especially the older and critical ones, resist change. The volume of data may be the resistance to change, the process may touch too many people to casually change, the risk of updating code may be too great. If you’ve worked on a billing system, I bet you’re hallucinating memories of it at the mere mention of data, process, people, and code resisting even the smallest change in course.

In that case, the next best way to improve the situation is to improve everyone’s knowledge of the system by writing it down. Document how it works. Even better, elaborate on how it’s supposed to work and how it actually works in some important but problematic circumstances.

Go from tricky code to refactoring. If you’re stymied by refactoring, switch to documenting it instead. Everyone wins.

Alan Jacobs, the attention cottage (Via Austin Kleon). I was not expecting to quote an attention metaphor involving the cardiovascular system and cottages, and yet:

To care only for things temporal is to lose the things eternal; but to attend rightly to things eternal is the royal road to constructive thought and action in the temporal realm. The great artists and thinkers cultivate a systolic/diastolic rhythm, tension and release, an increase and then decrease of pressure. In the latter phase they withdraw, by whatever means available to them, to their attentional cottage for refreshment and clarification — and then they can return to the pressures of the moment more effectively, and in ways non-destructive to them and to others.

But most of us, I think, get the rhythm wrong: we spend the great majority of our time in systolic mode — contracted, tensed — and only rarely enter the relaxed diastolic phase. Or, to change the metaphor: We think we should be living in the chaotic, cacophanous megalopolis and retreat to our cottage only in desperate circumstances. But the reverse is true: our attention cottage should be our home, our secure base, the place from which we set out on our adventures in contemporaneity and to which we always make our nostos.

I often think how much easier, how much more naturally healthy, life was even just a couple of decades ago, when the internet was in one room of the house, when the whole family had one computer connected to a modem that was connected to a landline, and movies arrived in the mailbox in red envelopes.

I love a cottage/workshop/garage metaphor. Doubly so when they recall a time when distraction had yet to pervade our homes and lives.

The past is gone, we’re not going back to Netflix DVD mailers. So how do we carry the idea of inhale/exhale and space forward? I’m trying a few things currently ¹:

Minimize apps with an adversarial agenda. Currently: YouTube is only on my iPad, but the intent is I mostly watch via AppleTV. Twitter, Ivory, and Instagram are only on my phone. Reading apps (Books, Kindle, Reader, Reeder) are on all my devices. In other words, the apps aligned with my goals (read more of what I choose, think bigger thoughts) are everywhere and the ones that want to direct my attention to advertisements (mostly) are only present where my attention is (probably) already scattered.

Hold devices to a purpose. The intent here is that I’m holding my iPad largely for reading, focus, and writing. My laptop is largely for writing, publishing, and collaboration. The Kindle is, obviously focused on reading alone, despite the predations of Amazon into all possible revenue streams elsewhere.

Treat the transition to focus with reverence, if not physical space. When I’m reading or writing, I try to keep my phone out-of-reach. If not in another room. My laptop sits in a (part of the) room where I’m only focused on writing, ideas, publishing, or keeping those things operating smoothly. Whether I’m in my home office or making do on a roadtrip, this is the attention cottage Jacobs mentions above.

It’s not quite as quaint as an actual cottage. But, it does an okay job balancing the pastoral with the modern.

It’s the only way to survive as an engineering leader.

1. Hand off tasks/work to the team
2. Give guidelines, execution tactics, or constraints to keep things on track
3. Set an expectation of what to deliver and when
4. Get out of the way

Delegate not only the main/critical path work, but also “the toys” and interesting/exciting work. Give away your toys.

Even more difficult: don’t tell someone how to do it. Give context (“why”) and constraints. A few style guides perhaps (i.e., codified influence!). But, work with the team to develop the style guide, raise the standard, and enforce the standard. Provide constraints that keep them on track and/or reduce the problem space.

Leadership is about executing through other people. To some extent, that means influencing your team to do the right work efficiently and effectively. That’s delegation in a nutshell.

“In the beginner’s mind, there are many possibilities. In the expert’s mind, there are few.”

— Shunryo Suzuki

The trick being, how can an expert help a beginner, given they know all the false paths. And how can the expert encourage the beginner to help them find new ideas, knowing all the paths they’ve followed in the past?

The distinguishing quality of beginner-ness is that every rock turned over has something surprising or interesting under it. It’s all rabbit holes to fall down or rakes to step on.

When there are no time constraints present, it’s fine to explore these ideas, some of which may not be fruitful. Or, to figure out exactly why the result was surprising and not intended.

When time is of the essence, being a beginner is sometimes pretty dang stressful. Doubly so when the path to productivity is littered with novelty.

Ergo, Make Failure A (Safe) Option.

I feel lucky that I was able to learn a lot about software development in high school and college. Mostly, self-directed; I used Linux during college, spent a lot of time compiling Enlightenment and tinkering with up-and-coming languages you may have heard of, namely Python and Ruby (and to some extent, Lisp and ML).

Beginners today are thrown straight into narrowly guided tutorials and online courses. Then they’re dropped into the wilds of innumerable Unix minutiae, source control, relational databases, multi-paradigm programming languages, styling in browsers, and agile methods. I realized I was firmly in the “expert developer” camp when I could spot all the rabbit holes and rakes-in-leaves three moves ahead. I deftly maneuvered in the dark, knowing by feel where the potential problems were and how to avoid them.

It’s difficult to impart that knowledge to beginners. It’s not principles, it’s compounded experience. Worse, beginners find themselves amidst a hustle culture of “ship a side project alongside your day job and somehow do that whilst traveling the world”. Or, become a “content creator”. Most importantly, I knew a side-hustle and creator¹ lifestyle were not for me.

I’m certain beginners can help me find new and interesting angles. But it’s difficult to thread the needle between listening for insight and skipping ahead to what I know will work. It’s tempting to say, “I see where you’re going, but there are hazards ahead and here’s all the ways your approach could stymy us.” For one, failing is a pretty dang effective way to learn! For another, “don’t do that, I’ll tell you why later” is a pretty lousy way to acquire knowledge.

One lesson I’ve learned from beginners is that probably we should design systems without reliance on understanding the full depth and breadth of the computing world. Folks don’t have the time or energy to get Very Good at ./configure; make; make install² like I did in college.

Beginners are pretty good at working incrementally. They have to, lest they get lost in all the stepping on rakes and learning of minute! Many experienced developers have forgotten how to build incrementally. They glimpse the glass castles in the sky and plow ahead to realizing them, only to find themselves stepping on different kinds of rakes hidden in the leaves.

Expert mistake number one: try to skip past all the beginner’s insights. That is, the beginner’s mind.

Teammates new to software development and new teammates on the team, accidentally or intentionally, can both reveal useful information about your team, process, and software. Information that is otherwise difficult to come by. There are things everyone is accustomed, and thus blind, to that a beginner can tell you straight away.

I have to remind myself that this is a critical moment. Don’t skip straight to “onboarding them onto the team’s culture” by explaining the history and the why-or-why-not. I should listen to the insight, evaluate the idea, and bias to act on it if I can.

A group of experts can make great things. But a group of experts with a beginner alongside can assimilate new ideas and make great and interesting things.

See also:

• Austin Kleon, Show Your Work
• James Clear, This Zen Concept Will Help You Stop Being a Slave to Old Beliefs 

I’m trying to change up my blogging style: write without telling people what to do. Show, don’t tell. It’s a stronger writing position to take. It’s the difference between writing social media “content” and writing from a place of earnestness/honesty.

• Advocate by telling a compelling story.
• Motivate by strength of logic alone.
• Change minds by revealing an obvious truth that was once obscured.
• No shortcuts.

The way I read him, Kurt Vonnegut (might) want it that way. Who knows, he can’t tell us now!