more info ⬇


SW engineering, engineering management and the business of software

subscribe for more
stuff like this:

2020 01 01

2019 Year in Review

Inspired by:



Programming Languages


Popular Content by me:

Content I’m proud of:



Best Blog posts read

Best Books Read

Overall number of books read went way up in 2019: Over 120 if my math is correct across paper, kindle, iBooks. Most were light fiction (bedtime reading).

The best non-fiction I read:

Favorite Media:

My overall media consumption in 2019 went down I think. Nothing felt really satisfying to me like Infinity War did in 2018.



Todo in 2020

2020 01 09

What to do to become an Engineering Manager before you are an Engineering Manager

A lot of engineers want to be managers. I don’t think that eng management is right for everyone, but if you at least want the chance, here are somethings you can be doing to help you get that manager opporunity: (In no particular order)

It’s a harder transition that you think. Don’t lose faith in yourself. Take feedback well (even poorly delivered feedback). Ask for feedback proactively. Honestly assess yourself. Do what you can to increase your own self-awareness.

The realities of the workplace mean that the quality of your current manager has a lot to do with how fast you become a manager. You may be left the with unfortunately options of having to change your environment in order to achieve your goals.

In a nutshell: Be excellent at work and make you and everything around you better.

This post based of a series of tweets you can read here. You should follow me on twitter for more of my thoughts on engineering, management and hiring.

2020 01 14

My Nine Years of Go

I learned about the Go programming language when it was announced back in November 2009. It probably happend when it popped up on HN. There was a lot to like about it, even way back then. I’ve always had a list of things that I’d want in my hypothetical perfect programming languages and go ticked off more of them than any other language at the time. Spoiler alert: It still does.

I really sat down to learn the language in early/mid 2011. The language itself didn’t hit 1.0 until early 2012. I can’t find the original repo, but some of that code still powers this blog today.

A lot of the original design holds up well. Goroutines, fast compilation, static typing, interfaces, gofmt, defer, small core, broad standard library that included a webstack in particular. Some of the original quirks (no warnings, capitalization for public/private, disallow unused imports/vars, etc.) took no time at all to get over despite the internet opinions of the time. In fact, most of those look like great decisions in hindsight. As an app developer, I haven’t needed generics much. I love the error handling philosophy and wrote my own error wrapper. It’s part of why go codebases end up reliable.

Not only that but Go has been improving itself over time. It’s ecosystem and early killer apps will keep it around and popular for a long time going forward. I can like a language, but that doesn’t mean that language will gain any reasonable popularity. And popularity is important. You need a critical mass of users to have a reasonable ecosystem.

Go itself has influenced my options on things like GC. Back in 2009, I was a big fan of ObjC/Swift’s ARC and Rust-style lifetime management (even though Rust wasn’t around back then). These days, I prefer that something else thinks about memory management for me. The performance ramifications of GC are no longer relevant.

Go is one of my secret weapons. It still allows me to get from idea to production faster than anything else out there. The positive words I wrote about Go in 2013 still hold up.

The first blog post†† on this particular blog briefly touched on the nascent, early, promising language back in 2011 included these lines:

[Go] is a tremendous productivity multiplier. I wish my competitors to use other lesser means of craft.


That is still something I wish.


I need to update it for the go.mod era, but it still works great.

†† If you read that post, you’ll find the writing style… different. I’m both proud and ashamed of younger me.

2020 02 13

Questions to ask about Growth Opportunities while you interview

I was asked a good question this morning about evaluating growth opportunities in roles you are applying for. The easiest thing is to ask a few pertinent questions to all prospective hiring teams. In particular:

Who will be your manager? How many people have they promoted recently? How have people grown in the past year? This will help you understand a companies track record of growth. Hopefully you see both promotions and people’s roles evolving and developing over time.

How often does management turn over? Frankly speaking, a lot of your growth opportunity is you but a big chunk is how good your manager is at providing opportunities for you. If your manager shifts every 6 months (quitting, moving on, promoted up or sideways, terminated, etc.) it’s a big problem. Similarly if everyone doing the particular role keeps quitting, figure out why. That’s a fairly loud warning sign.

How many people in your function? Will you be the first person doing the role? 5th? 10th? 50th? The lower this number, the more responsibility you will have and the more diverse set of problems you can assume will come your way. This is generally a good thing for career growth as you get more exposure and experience in a short amount of itme. If you are the 50th person doing the role, you are likely to be isolated to a small niche responsibility for a while.

How fast is the company overall growing, both in people headcount and business (revenue or users)? How many more people for this role do you plan to hire over the next year or two? This represents the surface area growth opportunity. Being the first X in a 30 person company that gets to 150 headcount in 18 months represents tremendous career opportunity. converserly, If you are the 5th X and the company headcount is stagnent, you have a long wait for management opporuntities.

Unless you are close to retirement, growth should be one of your top priorities in your job search. Many companies do this poorly. Your best bet is smaller startups if you can tolerate the chaos and anarchy lack of structure. If you are the first or second person in a role in a startup, you tend to be asked to wear a lot hats and structurally, startups are essentially designed for and even defined by growth.

Thanks to Joyce Park for the tip on management turnover.

2020 04 02

Vue.js, vue-router's history mode and Caddy2

I’ve spent the bulk of March’s shelter-in-place order learning Vue.js (v2) and Tailwind.

I quickly came upon and greatly prefer vue-router’s history mode.

Brief summary, this allows urls in a Vue-base SPA (single page app) that look like:

instead of:

That initial hash tag in the path always felt un-web-like to me.

The downside of this is that you only have one index.html at the root (/) directory. If a user navigates from / to /login/, no big deal cause the router is doing it’s thing. If a user types in directly, a standard config webserver will try to fetch /login/index.html instead and throw up a 404.

As documented in the docs, there is a workaround:Rewrite directives. The docs list rewrite examples for a handful of webservers, including Caddy v1. Caddy 2, currently in late beta doesn’t have an example.

In an attempt to help the internet out, here’s a working Caddy2 Caddyfile example to get history mode to work:

localhost {
    try_files {path} /index.html

A real production Caddyfile will have other stuff in it of course: {
    root public_html
    encode zstd gzip
    try_files {path} /index.html

I’ve been very happy with Caddy. It’s first class support of https is amazing and it’s performance has only gotten better over time. I’ve been using it for all new projects and highly recommend it.

I’ve got lots of other thoughts (primarily positive) on Vue.js, Tailwind CSS and FE development in general, but I’m saving that for a future post.

2020 07 15

CRDTs in a Nutshell

Note: This post is a updated, expanded rewrite of an older post from 2012. I have removed references to older technology, but the concepts still stand.

Understanding CRDTs is fairly straightforward if you have some concepts clear ahead of time.

First, you have to be clear on two different types of possible contention with distributed data stores:

  1. Simultaneous Read and Write
  2. Simultaneous Write and Write

In case 1, If you are writing a value to a key, that value needs to be replicated to a few other nodes. This is where the read quorum (for fetches) and write quorum (for stores) come into play: While reading or writing, I must have X number of nodes agree on what the correct value is. You can set X to be all the nodes to get a strong certainty of getting the most recent value. If X is 1 then you might give up on getting the latest value in exchange for some improvement to latency. The typical, balanced – and often default solution – is to set X to be a simple majority of nodes.

In case 2, the write quorum has no practical use. If you have a 10-node cluster, and some client writes “flub” to nodeA and some other client writes “biggle” to nodeF, then we have something called write contention or siblings. How do you decide who wins? This is where sibling resolution comes into play. There are many, many strategies for this. The simplest involve last-write-wins (which is a good way to lose data if you have a counter). If you’ve ever seen a file in your Dropbox called SOME_TITLE (Matt Nunogawa's conflicted copy 2020-07-12) this is an example of siblig resolutions I like to call last-write-wins-but-save-a-copy-of-the-loser.

What happens in practice is that you cannot think about a distributed data store in terms of sets and gets. A better mental model is more like an operation log.

A counter works well in a distributed system if you are only adding. Each client simply tags his increment with some arbitrary but unique client ID. The operation is not get x, then set x+1, but rather counterID:ABC:clientID:gamma:count:+1. Since it’s add-only, if you have multiple counters incrementing at once, they will only modify their own clientID entry. If client alpha adds 1 to nodeA while client gamma adds 1, 1 and 1 to nodeF, you would see something like this:


or posisbly this:


To get the total count of the ABC counter, simply add up all the counts, taking the highest value per clientID. Both of the above examples resolve to 4. You could eventually whip up some garbage collection to clean up older entries if space is something you care about.

If client gamma partitions off the network? It’s just going to keep accumulating counts from is local clients. The short term totals are off but hopefully the system knows it is partitioned, but when it connects back, doesn’t matter what happend locally or on client alpha, the total counts should again be accurate assuming eventual consistency.

Add-only-counters are great but if you need counters that go up and down, you have to get a little clever. If you keep two counters, posABC and negABC and subtract, you effectively get a couter that can go in both directions.

And now we have Conflict-free Replicated Data Types:

CRDTs can be thought of as primitive, resolvable operation logs that can be composed into useful data types.

Now the implications are interesting, because if your distributed datastore can do key-value, and is eventually consistent, you can hypothetically develop CRDTs on top of it.

The above example is an over-simplification. In a real world operation, you would do lots and lots of finicky housekeeping around compression of the log as high-volume writes start to get expensive in terms of storage. But hopefully the concept is clearer.

CRDTS are exciting (in the way that only useful mathematical properties are). The add-only-counter and the add-only-set versions of these are relatively straight-forward. Some very smart people have created CRDTs for more complex data types like lists, maps and even directed graphs. Searching for CRDTs should bring you to the work of Marc Shapiro.

Very recently, Martin Kleppmann published a CRDT talk on recent advancements in this area as well.

But if you really want to learn about all the edge cases, finicky bits, etc. there’s no substitute for implementing a counter in a three node distributed datastore and hammering all three nodes with writes. Odd cookie that I am, I found it to be a great learning experience.

2020 09 19

Plain old HTML Tailwind CSS projects

Tailwind has quickly become my favorite CSS framework. One quirk of working with tailwind is that the core framework is massive. You need a proper npm or yarn setup and tree shaking via purgeCSS is necessary for any kind of production usage. You can see some numbers at the end of this post, but spoiler: 3 orders of magnitude reduction in CSS size is normal and necessary to get your CSS file to a reasonable size.

Tailwind is fantastic when paired with front end app frameworks such as Vue, React, etc. I don’t always need a front-end app framework however and simple html works fine for certain work.

It turns out that this is just a little fiddly and you can quite easily make “plain old html” projects work just fine with Tailwind.

Here’s how I do it:

Starting From Scratch

First, some basic setup:

mkdir -p site/static/css

site is where our plan old html will live. site/static is a great place for images, css and other files that don’t change.

Conceptually, site doesn’t even have to be even in the project directory, if you make the necessary adjustments to the appropriate config files.

npm init
npm install --save-dev tailwindcss
npm install --save-dev cssnano
npm install --save-dev @fullhuman/postcss-purgecss 
npm install postcss-cli --global

Next, you need a basic input.css file.

Create this at the root of your project directory (where you ran npm init).

touch site/static/css/input.css

It should contain the following three lines:

@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

Basic Config

You need a few config files. What’s a modern frontend project these days without a mountain of config?

I use two different postcss config files depending on whether I want to minify or not.

mkdir build debug
touch /build/postcss.config.js
touch /debug/postcss.config.js

/build/postcss.config.js should contain the following:

module.exports = {
  plugins: [
    // ...

/debug/postcss.config.js is the same, but remove the require('cssnano') line

touch tailwind.config.js

tailwind.config.js should contain the following:

module.exports = {
  purge: {
    enabled: true,
    content: ['site/**/*.html'],
  theme: {
    extend: {},
  variants: {},

Lastly, open up package.json and add the following scripts:

"scripts": {
    "debug": "postcss style.css --verbose --dir ../assets/static/css",
    "build": "postcss style.css --config minify --ext min.css --dir ../assets/static/css"

You can do either of the following to generate CSS:

npm run debug   # generate, purge, but don't minify
npm run build   # generate, purge, minify

Purging can sometimes be finicky and I don’t recommend you turn it off, even in during dev or debug mode.

At this point, any html files you add to the site directory should be scanned during the purgeCSS processing.

Your style.css file should contain only relevant tailwind CSS classes.

A quick size check, using a minimal hello world HTML file:

Plain Old HTML

I love POH for simple pages. It’s rarely worth the effort to setup an entire vue or react project for something like a landing page or placeholder work. For me, it’s almost always worth the effort to get tailwind in place.

2020 10 26

When to Hire Your First DevOps, SRE, Security or Data Engineering Specialists in a Startup

Engineering Specialists Aren’t Pokemon

When you are managing a very small team (single digit number of engineers), you essentially want generalists. They don’t have to be full stack, but they have to be able to stretch into adjacent areas. Typically this means you are hiring backend folks who can do a passable job at infrastructure or front-end. Sometimes it means front-end or mobile folks who can moonlight as backend until the team grows. It’s very natural for a small eng team to be mostly generalists and large teams to have mostly specialists.

But when does this change happen? As an engineering manager advisor and consultant, I answer that specific question a lot. The high-level answer is: “When stuff breaks.”

Let’s go role by role:

Infrastructure, DevOps and SRE

For the sake of this post, these are fairly similar roles.

Typically you need this investment around the 10-15 engineers mark, because that is when infrastructure management starts breaking. Too early and you are investing in tooling you don’t need and will likely throw away. Too late, and you’ve built up a lot of cruft, fragility and unreliability into your systems.

Infrastructure fragility is partly the systems you use and don’t use as well as the people and process around testing, deployment, monitoring and debugging (prod or otherwise)

Do you not have any production users? Do each of your devs work on completely separate systems that don’t interact? Are you still figuring out product market fit? You may not need infrastructure engineering at all.

Does it take over two weeks to get a simple change into prod? Does stuff work in dev and test, but not prod? Do you have significant downtime or lots of alerts, false or otherwise? Do changes to one repo, system or component break others? You’ve probably waited too long to hire infrastructure engineering.


This one depends. If you are in a highly regulated space (healthcare, finance, etc.) or are dealing with sensitive information of any kind (privacy, secrets, etc.) you should be investing early. Probably around team size five to ten engineers or so.

Are you mostly early with no or few users? Cat pics or other non-sensitive data? You can wait.

Investment in Security Engineering is a constant gamble. You should be constantly weighing the risk (chance of breech or data loss) against the consequences of those risk outcomes (blog post apology? sink the company?). Your risk profile is high if a small chance has potentially severe outcomes (such as sinking the company) or you have a large chance of incident due to tech, vertical (finance in particular), size of customer base, etc.

If your risk profile (roughly chance times outcome severity) is high, you should have already hired security engineering professionals.

Data Engineering

There’s no typical team size. This is more an issue of data and data processing workload. My rule of thumb here is to make sure to avoid premature optimization. Mostly companies don’t need fancy stream processing or Hadoop style cluster operations.

Basically, if your data and workload doesn’t fit on the beefiest RDS or other similar managed SQL database, not including best practices like read clones, caching layers, etc. you probably don’t need data or pipeline engineering specialists.

Things that make the cut? Petabytes of data. Hard real-time response requirements. Ultra complex, multi-join statements (sometimes). Millions of concurrent write events. stuff like that.

Things that don’t make the cut? Terabytes of data. Millions of users. (I promise. they won’t be concurrent for most all businesses.) Most Transactional Business logic.

I can’t count the number of startups that I have personally seen spin up Hadoop or Spark or Kafka workflows and then just throw them away because they never scaled, added too much complexity or the company pivoted far before they ever needed those systems.

“When stuff breaks.”

Again, the common theme is breakage or fragility that slows down engineering velocity.

You may be asking yourself, “Self, what if I don’t want stuff to break?”

Think of it as avoiding premature optimization. If the phrasing makes you or your boss uncomfortable, think of it as when stuff gets too fragile as to negatively affect velocity.

If you hire a specialists too early, you are potentially slowing your team down. they are putting tooling and process in place where it may be unnecessary and wasteful. Importantly, you are likely spending resources (money, headcount, meeting and training hours) in things that aren’t likely useful to an early stage company that hasn’t likely hit product-market fit. It’s far more likely your product requirements will change before your infrastructure investments pay off.

Similarly if you wait too long for any specific specialist, you are also slowing velocity. You will need CI/CD eventually. You will probably have a security incident of some kind at some point. Waiting too long means that your teams are struggling when a key hire could help alleviate some internal pain points.


There are always exceptions. Every combination of market, company, industry and team is unique. Is your company focused on mobile, data or security? Then by all means, hire those folks early.

Non-Engineering specialists?

Broadly speaking, the similar advice applies to non-engineers. When do you need a Finance manager or accountant? when the money bits get too complicated for the CEO or other co-founder who is probably doing it part time. When do you need your first marketer? When the marketing workload starts holding back key people from doing their jobs (typically co-founders or sales people) or you have evidence that the absence of competent marketing activity is negatively affecting growth.

Engineering Specialists aren’t Pokemon

Be thoughtful about when to hire. Don’t collect engineering specialists like they are Pokemon. Try to find the magical time where that key hire will add to rather than be a detriment to everyday engineering productivity. Ask your team or your peer network to think about both the pros and cons of a specialist hire. You probably won’t get it perfectly right, but you can improve your odds of not being detrimental.

2020 10 30

Plant Based Burger Review Update: Fall 2020

This is not a food blog. My one indulgence into the culinary milieu however is my ongoing search for great burger replacements. I originally wrote up a blurb on plant-based burgers a couple of years back.

For context, you can roughly devide plant burgers into two styles: Meat Imitation/Replacement and Veggie Patties. Back during my original blurb, there were really two viable chices in the meat-replacement category, Impossible Burger and Beyond Burger. Furthermore, in the grocer, only Beyond burger was available for making at home. Today, there are a lot more. All options below are available at grocers (at least in California, your region may differ).

Plant based burgers are still more expensive than the meat based originals. For example, Burger King sells the Impossible Whopper for seven and change, but the you can get two regular Whoppers for five. Hopefully this changes over time. It probably will remain this way for a while, given how the industry has spent so much on R&D on these products.

Fall 2020 Update: Plant-based Burger Rankings

  1. Impossible burger:
  2. Open Nature Plant Based Patties
  3. Beyond Burger
  4. Sweet Earth Awesome Burger
  5. Lightlife
  6. Morning Star’s Incogmeato
  7. Laura’s Plant Based burgers
  8. Trader Joe’s Protein Patties

Most of the remaining alternatives I’ve tried since the original 2018 post were either veggie patties or more like veggie patties than meat replacement.

Summing it all up

Impossible still rules the roost. Open Nature and Beyond represent a great second tier of choices.

There’s a large middle class of decent, but not great brands, including Lightlife, Incogmeato, and Laura’s.

If possible, stick to the top 3 or 4 on the list. There’s a bit of a drop off after that.

Still to try:

2020 11 03

WCWDIX: What can we do in 1 year, 1 month, 1 week, 1 day, 1 hour, 10 minutes.

One of the best tricks I’ve come across to make meaningful progress on any long term project is to start with an initial (typically long) time estimate, than play the “What Can We Do In X” game.

If you need a fancy mnemonic, use: WCWDIX (pronounced wick-widicks)

It works like this:

If you start with an initial, hypothetical estimate to build a product or feature of 5 months, ask yourself and your team: “What can we do in 1 month?”

One Month

This forces the thought process of Ruthless Prioritization. Typically, your must have features become should-haves and your should-haves become nice-to-haves. It’s important to be ruthless here. Strip the business down to the core, while still being usefull. Remember that the MVP of a car is not 4 tires on the ground (useless) but a skateboard or bike.

One Week

Follow that up with “What can we do in 1 week?”

This helps with the notion of what it takes to make a Useful Prototype. Hopefully this is mostly code/product that you can reuse over the longer journey. Importantly, you have prioritized faster and are cutting corners to get to a product point where you can put it in front of people. This builds technical debt, but it is almost always worth it because you are learning so much faster, earlier in the development process.

One day

By now, you know what comes next: “What can we do in a day?”

In a day, you can’t build much. But you can Fake Product. Sometimes this means wireframes in a mockup app. Sometimes this means wiring together no-code SAAS apps or even a spreadsheet and tools like Zapier to simulate the guts of your business logic. Fake Product is great for customer development or even early sales calls.

Another option is Market Discovery: spend a day doing market research. This is different from customer validation which typically happens after you have a product idea or prototype. Market discovery is more about finding a market that has pain points and the ability to pay to address those pain points, and ideally a market you can reach via known sales/marketing strategies. It’s important to do this process without any preconceived notions of product/solutions. Identify the pain first!

One Hour

“What can we do in an hour?”

Not much? Wrong! An hour is enough for Short Burst of Research. You can hold 2-3 customer development calls. You can setup up a landing page and blast LinkedIn, twitter and other social media sites to see if you can get any bites. You can do some google searches and look for evidence of your market hypothesis. You won’t typically get enough info here to be data, more anecdotes. But it might be enough to guide early thoughts/directions or help quickly identify a potential pivot that requires more investigation.

Ten minutes

Lastly “What can we do in 10 minutes?”

Even ten minutes is enough for Quick Info Wins. This is kind of a mini versino of Short Burst of Research. Send off a couple emails. You can buy a small ad campaign and measure how many clicks it gets over time. Counts cohorts in LinkedIn (are you marketing to poele in X profession? go check out how many people are in that profession to get a sense of scale). Anything you can do or setup to get Information from Outside your Team is great use of early hours on a project.

Wrapping it up

As you play the WCWDIX game, each step forces you to reduce “Time to Learn” by an order of magnitude. You can hopefully shine light as early as possible on the fact that you may be building the wrong product or solution.

The suggested activities (Fake Product, Market Discovery, etc…) are just examples. If you have alternative ideas that roughly fit in the respective timeframes, go for it!

However, the output of each step must make your smarter in some way. You could spend a few hours setting up a CI/CD system or learning about a new javascript framework. That’s work, and you have made technical progress, but you’ve learned nothing about your product, it’s viability in the market, or your ability to sell into a market. The bulk of your technical progress should (ideally) be after you’ve proven market and channel viability.

Companies don’t usually fail because they can’t build a product. They usually fail because they build the wrong product at the wrong time or they build the solution that ends up being wrong for a market that can’t or won’t bear the appropriate costs.

Always make sure to the best of your ability that you are building the right product!

2020 11 11

Manager's Hierarchy of Concern

As a manager you have a lot of things to worry about. It’s possible to broadly categorize into three buckets:

To me, the bulk of your job is in the third bucket. You have to be able to foster empathy, make people excel and intervene when things begin to go wrong.

This post is about that intervention point.

To the surprise of no-one but the clueless, the more “wrong” things have gotten, the faster and more forceful you should be intercede on behalf of your people.

Let’s go through them:

1. People who feel unsafe

You need to take care of these people immediately. This is Big Red Button territory. Especially in the very rare extreme cases of physical or sexual violence. In the case of psychological safety, intervention should still be as rapidly as possible. Diminishing psychological safety is one of the inevitable ways to reduce team performance.

Find out what or who is causing feelings and resolve it to the best of your ability.

2. People who are actively threatening to quit

No one wants to lose employees. Obviously, we aren’t talking about people who are moving for family reasons or people who got a job with a different company (though you should understand why every employee leaves).

This is about people who are burnt out or angry or fed up or otherwise pull a surprise resignation. You may not get them to stay and even if you do, they probably won’t stay long. But it is important to understand their situation and figure out a) what you can do and b) what you could have done to have prevented this outcome.

3. People who are underperforming

Finally, we are out of “Big Red Button” situations and into Red Flags territory.

Underperformance doesn’t usually happen all at once. Your immediate concerns are mitigation & communication. Does the underperformer know that they aren’t meeting expectations? Oddly, the answer is that they are usually clueless. Let them know, give them a chance to succeed. Sometimes this means training, sometimes a transfer. Occassionaly you do have to let them go.

The worst possible outcome is for the employee to be unaware for an extended period of time. Long term, not dealing with underperformers tends to drive away your best people.

4. People who don’t get along with their boss

In various HR surveys, “Not getting along with your manager” is often at the top of reasons why people leave their jobs.

It doesn’t have to be their boss either. It could be someone who controls their work in some way, like a project manager or a peer reviewer.

If their boss is you, dear reader, it’s time for some open minded self-assessment. See if you can figure out why. What behavior changes. Potentially see if an internal transfer makes sense.

5. People who are bored

Bored people quit. Not always, but often enough that it should be a yellow flag for you. How can you challenge them? What work can be shuffled or reassigned? Can you split the boring work among multiple people?

6. People who aren’t learning or aren’t being challenged

Similar to the above, this one is a just a yellow flag. This one is often tricky to diagnose, because someone could be good at their job, but stagnating. In most circumstances you want your people to grow. Does their career seem static by choice? or due to lack of opportunity? or maybe they are jut quiet introvert who don’t know or aren’t comfortable asking for new opportunities? Figure out why. Help them get new opportunities or help them learn how to ask for new opportunities.

What do they all have in common?

This is by no means an exhaustive list. There are many reasons to be concerned about your reports. The important thing is to assign the appropriate urgency. Being casual about “Big Red Button” situations means someone has to endure a terrible situation and typically results is bad outcomes. Similarly, being forceful about yellow flags often comes off as being pushy or micromanaging.

Making sure the right level of timeliness and intervention is a big part of getting better outcomes and successful employees.

2020 11 20

Judging Other People

I used to judge people. All the time.

“They must be a bad parents.” “He might not be good at his job.” “What a terrible driver.” “That person is definitely a mean spirited asshole.”

At some point, I realized this was not a good thing to be doing. People and their circumstances are complicated and the amount of missing information I have is huge. So I started to play a game.

What situation or context could I invent that would excuse or explain a person’s attitude or behavior?

This helped quite a bit. Instead of seeing someone take an elevator and thinking they are lazy, I would think instead: “They may be recovering from a foot or ankle injury.”

If I see someone who looks healthy parking in a handicap spot, it’s not they borrowed the tag from their grandma, rather it becomes “that person must be working hard on their rehab.”

Instead of lazy dads I started to see a single parent dealing with family health emergencies. Instead of road rage, it became someone distracted and stressed due to a divorce or death in the family.

Not every explanation had to be so dramatic. Sometimes little things, that person spilled something on their favorite pants and is late for an important meeting. Or that person’s favorite team lost an important match and of course they are a bit grumpy.

The most powerful was imaging myself in their shoes. When have I acted in a imperfect manner, what was my reasoning?

After a while, it occurred to me that not judging is a powerful form of empathy. And this kind of empathy, repeated over an over is a powerful tool in helping control my own mind. In particular it helps keep my brain from slipping into fight or flight mode. This is useful in a professional context and especially as a parent.

Rather than judge people, imaging what situations or context would make you behave in a similar way. You won’t always be right. In fact the majority of your rationalizations will probably be wrong. But at the same time, your initial negative judgements are almost always lacking enough context to me 100% correct as well.

Again, I used to judge people all the time. I do it a quite a bit less these days.

the fine print:
aboutarchivetwittertwitchconsulting or speaking inquiries
© matt nunogawa 2010 - 2020 / all rights reserved
back ⬆