What To Do When Things Go Wrong

Posted on October 3, 2025 by aknudson

Another one of my mantras (witticisms? Sayings?) is:

People don’t remember what you did when things were going well. People remember what you do when things go wrong.

If a leader walks up to your desk and things are going great, then they usually don’t remember the interaction. But if they walk into your office because the website is down, they’re definitely going to remember how you behaved, how quickly you solved the problem, and how you kept the problem from ever happening again.

Many people have told me that I’m calm and focused during a crisis. This is partly because of this mantra – people remember what you do when things go wrong. But it also goes back to my childhood.

I was an excellent swimmer (e.g., I set the all-time record on my community swim team for the 14-and-under 50m breaststroke). And excellent swimmers become lifeguards. And lifeguards learn CPR and first aid. And the relevant bit – how to focus in a crisis – has stuck with me.

Within the professional setting, I learned that when things go wrong, that’s the time for you to think very hard about what the BEST thing you can do is, and then DO IT. Don’t let fear hold you back or drive up your anxiety. Don’t hesitate, but be slow, thoughtful, and calm. In a crisis, slow is smooth, and smooth is fast.

And I also learned that the best way to deal with a crisis is to be prepared for it, train for it, and make dealing with it routine. That’s the reason that CPR has a book, and why ER doctors ask you what day it is when you roll into the room, and critical software systems have disaster recovery plans.

Good leaders invest time to ensure that your best practices and SOPs are well documented. Ideally, get them done before the code goes live, but realistically, as soon after the launch as you can. Document what you should do when things go wrong, BEFORE they go wrong, because they will go spectacularly wrong.

The first and most important thing is “stop the bleeding.” On the internet, this usually distills down to “never roll forward; always roll back,” because 9 times out of 10, that’ll stop the problem. Yes, it means that feature you rolled out earlier today isn’t live anymore, but hey, the checkout page is back, and we’re back to selling products, so that’s a good thing.

During this phase, don’t ask why it happened. Don’t focus on finding the bug in the code, and don’t try to blame someone for writing that bug. Sometimes, yeah, you need to understand the bug to understand the problem. But most of the time? Roll back the deployment. Get to the last good state. Stop the bleeding.

But sometimes rolling back isn’t an option, or doesn’t solve the problem. In those cases, take in all the information available. Scour your dashboards. Listen carefully, find the thing that smells fishy, and relentlessly poke at every assumption. When you’re brainstorming hypotheses, look for one that explains more symptoms than the others. Then look for other signs and symptoms that would be related, if that hypothesized root cause was true. If they’re there, then you’re closer to truth. If not, try another idea. Again, your goal is to stop the bleeding; prioritize the thing that does that.

Once you’ve stopped the bleeding, then start doing the investigation into why it happened. This can happen right away, or the next day, or during the next ops review meeting, but it has to happen. If you want to learn how to do that, check out the “5 whys” [https://en.wikipedia.org/wiki/Five_whys] for a great summary. Amazon uses the 5 whys because ultimately, you need to be able to ask, and then answer, the real question: how can we do better next time, or ideally, keep this from ever happening again?

To answer that question, you’ll have to ask others: What changes to our processes should we make to prevent a recurrence? Did the SOP tell you how to identify the root cause? Did it tell you how to stop the bleeding? Was it clear enough for you? Do we need to update it? If things had gone worse, how would they have done so? Assuming that worst-case scenario, what should we do that we didn’t do this time?

Every time an engineer gets paged due to an issue, as a leader, you should ask those questions. My goal was always to create a culture where we get paged less often next week than we did this week. This kind of continuous improvement means that two weeks (or six months, or two years) from now, we’ll be building new code, rather than fixing the code we’re writing today.

Posted in Being a Good Leader | Tagged , , , , , , , , , , , , , , , | Leave a comment

Don’t Be Afraid

Posted on September 26, 2025 by aknudson

Another one of my mantras is: don’t be afraid. It’s easy. I tell it to myself all the time. When I get worried, or stressed, and I’m not sure what to do, I’ll tell myself: don’t be afraid.

Why? Because fear is an overweight counterbalance in the risk equation, and measured risk creates progress. When you give into fear, you’re sacrificing potential for comfort. You’re giving up the long term for the short term. You’re saying safe is better than awesome.

Don’t be afraid…

… to ask questions. Questions are the best way to learn. It’s not showing that you’re stupid, it’s showing that you are curious and want to do the right thing.

… to look for answers on your own. You’re getting paid to solve problems. Getting better at the meta-problem of how to solve problems is the best way to create long-term success.

… to try something that you’re not sure you can do. We grow by getting slightly outside our comfort zone, trying something new, and learning from it.

… to ask for help. Nobody can solve every problem. Not all problems can be fixed by one person. Your boss’s job is to help remove roadblocks and obstacles. They can’t remove obstacles that they don’t know about.

… to try to do it on your own. You’re usually more capable than you think. Even if it’s scary, it’s usually the fear that undermines your success, not your skill.

… to make a mistake. We learn from our mistakes. Good leaders embrace mistakes as learning opportunities. Bad leaders criticize or fire people that make mistakes. If they do, it’s their problem, not yours.

… to escalate. If you think you’re right, and they’re wrong, push it up a level. If a peer manager is blocking you, escalate to their boss and your boss. Talk to your skip-level manager if your boss is being a bad boss. Speak up when your boss is screwing up.

… to move to another role. We grow not only by being promoted, but by trying new things. Go back and read my article about how you gotta do what makes you happy, because it talks a lot about how to do this.

… to persevere through difficult times. Perseverance and grit usually lead to better long-term happiness. You get a salary because what you do is sometimes hard, boring, or annoying. Get through those tough times, to get to the good ones.

For me, the key is that you need to check yourself when making a hard decision, and ask if fear is what’s holding you back. If it’s a reasonable fear – meaning the risk of something going horribly wrong is reasonable – then yeah, don’t do it. But if it’s irrational fear (as it usually is), and the likely outcomes range from “good” to “meh, kinda bad, maybe?” then you should go for it.

Particularly if one possible outcome is “awesome.” Never devalue awesome!

Now, I also recognize my privilege. I talked about it in my post about luck. I’ve had the luxury of never being afraid to speak to power. What are they going to do, fire me? For me, that’s always only been in the “meh, kinda bad, maybe” category. Therefore, I recognize that ideas like “don’t be afraid to escalate may not always be the best advice. If you’ve got a job that’s keeping your head barely above water, and you’ve got a boss that’s a jerk, and you’re sure you’re going to get fired if you go over his head, then yeah, maybe don’t escalate. Remember, if the fear is rational and reasonable, then don’t do it. (But maybe look for another job? If you can, of course.)

Unfortunately, I’ve also worked at companies where, if you make a significant mistake, the CEO will walk down the aisle and fire you on the spot. The result is stagnation – people will put in a lot of effort to look busy, without actually doing anything. At those companies, “don’t be afraid to make a mistake” can be bad advice (and yes, I looked for another job).

So… what are you afraid of?

Posted in Being a Good Leader | Tagged , , , , , , , , , , , , , , , , , , | Leave a comment

How To Ask For Help

Posted on September 19, 2025 by aknudson

So the last article was about gophers vs. hair-on-fire, and how they do (or don’t) ask for help. In it, I alluded to coaching people on HOW to ask for help – and that’s what this article’s going to be about.

First, before you ask for help, you need a problem. I recommend against asking for help when you don’t have problems – in fact, it’s a good way to get fired.

I’m not going to go over basic problem solving, like sizing problems, effective searches, and the like. That’s perhaps a different article for a different day; if you’re interested, let me know. Today’s article is how to ask for help.

So, assuming you’ve hit a wall, and assuming you’ve invested a reasonable amount of effort to get over it, the right thing to do is to go to someone that you think can help. When you do, say the following three things:

  1. This is what I’ve done: …
  2. This is what I plan to do next: …
  3. Am I on the right track?

If you say those three things, in that order, it tells people:

  1. You’ve thought about the problem, and
  2. You have a plan (maybe not the BEST plan, but A plan), and
  3. You’re open to feedback if it’s not the most effective or efficient one.

The key to this problem-solving technique is that it lets them help you with the meta-problem of how to solve problems, rather than asking them to solve the specific problem for you. This is the best possible outcome for the long-term: you expand your library of resources, you learn new things, and (hopefully) you can solve the next problem on your own.

So you’ve gone to someone, used the three lines, and asked for help. Their possible responses are:

(1) Yeah, you’re on the right track, go for it! – this is great! Congratulations! And if you’re the type of person who leans towards the hair-on-fire approach to problem solving, this question and response shows that you’ve done the leg work, and they can tell that you’re approaching problems in a reasonable way. It’s much less annoying to them, and much better for you in the long run.

(2) No, the wiki’s wrong, the answer’s actually over there… – this is also great! You’ve short-circuited the issue, and you’re on the right track quickly. You also learned about a new source of information, which will be useful in the future. If you’re the type of person that leans towards the gopher approach to problem solving, this means that rather than wasting an hour on your (bad) plan, you have an answer in seconds. Oh, and if you can fix the wiki, that means the next newbie’s not going to have the same problem you did, so probably do that too…

(3) I don’t know, but person X knows more about it. – also great! You’ve found something out about the team, and the people on it. Next time, you’re short-circuiting the problem again and can approach the right person the first time. Go find them, use the same three lines, and lather, rinse, repeat until you’ve made progress. Don’t forget to update your library (and the wiki)!

(4) I don’t know, that’s a good question! – the best! You both get to learn the right answer! This is the best possible response, because you’ve found an interesting and difficult problem, and you’re probably going to make the team, the org, and the company better by solving it.

I’ve used this pattern – this is what I’ve done, this is what I plan to do next, am I on the right track – at every stage of my career. It’s the most useful approach I’ve found to not only solving the immediate problem, but also getting better at the meta-problem of problem solving. The best leaders (and the best employees) are the ones that are good at the meta-problem, because it makes every problem easier.

Posted in Being a Good Leader | Tagged , , , , , , , , , , , , , , | Leave a comment

New Hires: Gophers vs. My Hair’s On Fire

Posted on September 12, 2025 by aknudson

In my last article, I made the point that people are complicated, diverse creatures with many motivations, quirks, and ideas. Trying to distill them into models that lump people into categories, like Myers-Briggs, is always wrong, because no one is ever that simple.

I then disregarded this point entirely, and proceeded to wax philosophic about a particular vector that I use: enablers vs. fixers.

So what next? Let’s do it again! This time, it’s gophers vs. “my hair’s on fire!”

Remember, first and foremost: this model is wrong. People are diverse. Don’t treat them as things, treat them as people. Use this model to think about certain behaviors, not certain “kinds of” people. I’ve found that it helps me be a better coach, particularly when working with either a new hire or a new professional (i.e., a recent college grad or an intern).

The “gopher vs. hair-on-fire” spectrum measures how someone behaves when encountering an unexpected, blocking problem. They’re stuck, and don’t know how to proceed.

At one end of the spectrum are the gophers. They take the problem, retreat into their hole, start searching and prototyping, and a week later, they emerge with a solution.

At the other end are the people whose hair is constantly on fire. As soon as they hit a snag, they leap up, start running in circles, and scream “help me! Help me! Help me!”

Both extremes are bad, and nobody is ever fully one extreme or the other. Everyone is smeared out somewhere on this spectrum. But if someone leans heavily on being a gopher, they might spend a week solving a problem that, had they asked for help, could’ve been done in an hour. And hair-on-fire is bad because (a) it’s annoying, (b) you’re interrupting other people with a problem that could’ve been solved with a 5-minute wiki search, and (c) you’ve been hired to SOLVE problems, not have other people solve problems for you.

As a leader, I pay careful attention to how new hires and interns respond to their first significant problem. I talk to their peers, review their updates at daily standup, and watch how they interact with the team. I try to assess where, approximately, they are on this spectrum.

Most novice professionals (i.e. new college grads and interns) tend to be more extreme on the spectrum, but even experienced individuals in a new job or role can exhibit poor behaviors. This may be because it’s a new experience for them, and so they might be prone to being more panicked, and thereby more hair-on-fire. Or they might want to prove they can “do the job,” and so they take it fully on themselves and go it alone.

What’s even worse is that new college grads have been coached for years that they must NEVER plagiarize, that the work they complete MUST be their own, and nobody’s told them that’s not true anymore. Good professionals steal code, ask for help, use LLMs, and do whatever they need to to get the work done quickly. New hires – particularly gophers – often need to learn that.

I coach both of them on how they should ask for help (which is the topic of a future article!). I coach both of them on how to be a more effective member of the team. And I help them learn the meta-skills on how to solve problems in general, rather than helping them solve ONE specific problem at a time.

So for gophers, I teach them about timing and sizing the problem: if they hit a problem, that they think might take a few hours to figure out, then go ahead and work on it for a half-hour or an hour, and then ask for help. I encourage them to not be afraid to ask for help, and I teach them about the sunk-cost fallacy. I check back with them, and with the team, to monitor progress, and give positive feedback when they’ve done the right thing.

For hair-on-fire, I teach them basic skills on how to search wikis, how to assess problems and impact, how to map out potential solutions, and then how spend a reasonable amount of time trying to solve it for themselves before asking for help. I might then give them – or ask a peer to give them – a relatively straightforward problem, and watch them apply what they’ve learned. Then give them feedback, coach, observe; lather, rinse, repeat.

So which are you? Which one’s better, and why? Feel free to leave a comment or question, I’ll try to respond.

Posted in Being a Good Leader | Tagged , , , , , , , , , , , , , , | Leave a comment

Trying to become a writer…

Posted on September 5, 2025 by aknudson

I’ll be attending the Pacific Northwest Writer’s Association (PNWA) conference from September 11-14!

Ping me if you also plan to be there and would like to meet up. I’ll be attending a bunch of seminars & sessions, plus pitching my book to try to find an agent / publisher. Wish me luck!

(Margaret Atwood’s giving the keynote, which is going be pretty amazing…)

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Fixers vs. Enablers

Posted on September 5, 2025 by aknudson

People are complicated, diverse creatures with many motivations, quirks, and ideas. Everyone has dozens of vectors of motivations, each one pushing them in different directions within their “behavior space,” and each vector gets increased or decreased in magnitude, minute-by-minute, based on their background, personality, coffee intake, or who won the Westminster Dog Show last night. Leadership gurus like to create models that lump people into categories, like Type A vs Type B, Myers-Briggs, or men-are-from-Mars, women-are-from-Venus.

All of these models are wrong. Nothing and no one is ever simple. Humans are complex and fickle beasts.

So… yeah, I’m going to talk about a spectrum that I find useful – because I find it useful. I recognize that it’s fundamentally flawed, and there’s no way to simplify people down to just this one dimension. It’s never true, but thinking about it helps me help other people.

In this model, the dimension that I want to investigate is the “enabler vs. fixer” spectrum, specifically as it applies to managers.

The question is: given a problem, when does your manager step in? Fixers will step in at the slightest hint of trouble. Enablers will let the team solve the problem themselves.

Both extremes are bad. 100% fixers are micro-managers, telling you what to do, how to do it, and taking full control at the slightest hint of a problem. 100% enablers are laisse-faire, do-nothing bosses, that teach people what to do, but then never step in when something goes wrong, thereby letting other people take the blame.

Fixers can be very successful leaders, because they get shit done. Senior management tend to notice when shit gets done. Fixers fix stuff through sheer will. But when a fixer fails, they fail hard.

Enablers, on the other hand, usually fail more often, but less severely. They almost universally end up with happier and smarter teams. They create cultures of trust, they educate rather than direct, and they share the celebration on wins. They let their diverse teams solve complex problems that one person alone couldn’t solve. But when an enabler succeeds, they often don’t get the credit for the success.

Neither of these are good, just like neither one is bad. Every leader is smeared out somewhere on this spectrum, each person perhaps leaning more in one direction than another.

Where I find it most useful is when I change teams. I also coach people on what to do when they’re thinking about changing teams, or jobs, or roles. When they do, I tell them to ask your new (potential) boss: are they a fixer or an enabler? Understanding your manager’s style helps you better understand when, and how, they’ll step in when something goes wrong. And when compared and contrasted to your own style, it tells you a lot about how each of you will react when that happens.

I know, for example, that I lean slightly towards being an enabler. I do step in when I need to, so there’s no small amount of fixer in my boss DNA, but if I was forced to pick one, I’m definitely more enabler than fixer.

Early in my Amazon career, I learned when that can be a problem – specifically, when my boss was a fixer (and a pretty strong fixer). One day, I walked into his office, because I had a question that needed a lawyer’s opinion. It was a question related to sending emails to customers, and I don’t remember the specifics, but I needed to know the answer to clarify some software requirement. I asked my boss, “is so-and-so still the right person if I have a legal question?”

He said, “yeah, what’s the question?”

And I told him, because it was the natural thing to do. And the next logical and natural question was, did he know the answer? He didn’t, but he slapped his knees enthusiastically, jumped out of his chair, said, “let’s go find out!”… and walked past me and out the door.

We went upstairs, and learned that the person we were looking for was out of town. We poked our heads into a few more lawyers’ doors, and eventually found one that knew the answer. Satisfied, we both went back down the staircase.

And as we walked down those stairs, I had a realization. I said, out loud, “I just let you do that.”

I’m an enabler. I came to him asking if person X was the right person. I had the right intent to get the right answer, and was just looking for confirmation that I was on the right track.

He was a fixer – and so he decided to step in and solve the problem. I didn’t ask him to solve my problem. I essentially asked: this is what I know, this is what I plan to do next, am I on the right track? And when he didn’t answer the question, and instead inserted himself into the solution, I let him. I enabled him! Without thinking about it!

We talked about it, and agreed that both of us were wrong, and we both needed to be better about it in the future (which we were). I learned from that point that I needed to be more clear and more assertive when I just wanted confirmation that I’m on the right track. And he learned that when the question is just that – am I on the right track – the right answer is a simple yes or no.

Posted in Being a Good Leader | Tagged , , , , , , , , , , | Leave a comment

That Supernova Was Weirder Than We Thought

Posted on August 24, 2025 by aknudson

So one of my happiest sets of pictures is the supernova that happened in the Pinwheel Galaxy in 2023. Below is a sequence of 5 photos; they’re the same ones you can find on the Galaxies page. The first is May of 2022, a year before the supernova. Then May 26th, 2023, just after it happened. Next is a week later, on July 1st; and then almost 2 weeks later on July 13th; and then finally 3 months later, in October. Note that the position of the supernova changes relative to the camera. I’ve rotated the 2nd and 3rd image so they align with the orientation of the first image, but images 4 and 5 are rotated about 90 degrees counter-clockwise. The supernova appears in the top-right arm of image 2, at about position 2:00 on a clock (with up being 12 o’clock), and then images 4 and 5, that arm is around 10:30 on the same clock.

  • May 2022
  • May 26, 2023
  • July 1, 2023
  • July 13, 2023
  • October 6, 2023

I don’t usually discuss scientific papers on this blog – it’s mostly about astrophotography using a cool telescope – but I first saw a video, and then skimmed the actual paper, about how weird this supernova actually was, and I wanted to share. The video is one of Anton Petrov’s: https://youtu.be/7KAurwygjgc?si=pYE0VyAQH39hieq5 (and he’s a great science communicator, check out his channel). The paper, referenced in the video, is here: https://iopscience.iop.org/article/10.3847/1538-4357/adea38/pdf – feel free to read it if you want. I only read the abstract, skimmed most the rest, and spent some time looking at the interesting graphs and pictures.

The short version of why this is weird is: this appears to be a case where two stellar objects – one, a large, bright star, about 10 times the mass of our sun, and the other, a black hole also about ten times the mass of the sun – spiraled into each other. It’s even possible that the black hole went inside the larger star! For the four to five years prior to the explosion, the spiraling black hole ripped off 2 different chunks of the star’s gas and spewed them into space, causing the apparent brightness of this star to grow. And when I say “chunks” getting spewed, I mean “about two or three solar masses of material,” each ripped away over the course of a few months to a couple years. And when I say “ripped away,” it’s possible this was caused by the black hole, or just instability of the star itself; either way, stuff got thrown into space.

Finally (and this is where the black hole may have actually gone into the big star), the black hole caused enough instability to make the star explode. The huge explosion of gas and dust then raced outwards, smashing into the closer bubble of previously-ejected material (causing the initial brightness spike), and then around 240 days later, hit the earlier-ejected material (causing a second brightness spike). Now, 240 days after May of 2023 is mid-January of 2024, and unfortunately, I have no pictures of this galaxy from around that time.

So the weirdness of this supernova comes from two things: one, the fact that those before-the-explosion events caused a brightening of this star for years beforehand; and two, the fact that this explosion was caused by instability due to interactions with a companion black hole, rather than the more humdrum stellar-collapse supernova, making it a type IIn supernova. Type IIn supernovae have been theorized, but Anton’s video seems to imply that this is the first time that a paper is claiming to have evidence for one.

It’s very cool that I got to take pictures of what may have been a previously-unobserved phenomenon!

Posted in Space on the back porch | Tagged , , , , , , , , , , , , , , | Leave a comment

Three Strikes and a Couple Hits

Posted on August 23, 2025 by aknudson

Last night I wanted to try to get some new targets, and so rather than just relying on what the Unistellar app suggested, I used the search function. I searched for “nebula,” and then started clicking through the resulting set, looking for something that (a) had a positive elevation (meaning it was “up” in the sky), and (b) was something I didn’t already have a picture of. It worked for the veil nebulae (see my recent post about them), so I figured, sure, let’s give a few a try.

I started with an old favorite to make sure everything was dialed in:

M51 – Whirlpool Galaxy

14m

2025-08-22

Another great photo of a great pair of galaxies.

Great! Let’s try one. Beach Ball Nebula? That sounds interesting.

Beach Ball Nebula (NGC 6058)

28m

2025-08-22

An attempt at a new target, and it proved to be nothing much. If you zoom in on the middle, there’s a small blob of blue, maybe? Looking it up afterwards, it has an angular size of 24 arcseconds – about 1-2% of the width of the circle. Yeah, that’s as good as we’re gonna get.

Ok, zero-for-one, let’s try another one. Maybe… the Cat’s Eye Nebula? The online photos of it look really interesting, let’s go for that one.

Cat’s Eye Nebula (Caldwell 6)

10m

2025-08-22

Another attempt at a new target, which proved to be not a good target for the eVscope 2. The core is the bright spot at the center, and with an angular size of only 25ish arcseconds; that’s tiny. The outer halo is 5 arc minutes, or about 1/6th the width of the circle, but it’s too dim for me to make out from inside a city, especially with such a short dwell time.

Alright, there’s still good night left, let’s try a third.

Elephant’s Trunk Nebula

63m

2025-08-22

If there’s a nebula here, I don’t see it. I even gave it over an hour of dwell time – it can produce great results on nebulae like the Horse’s Head or the Veil. Here? Nothing.

So, the next day (today), I looked around online, and it turns out I did hit the dead center of something called IC 1396A, which is a nebula that’s six times wider than the field of view. This thing is huge! It clocks in at around three degrees – compare that to the moon, which is about 0.5 degrees, and would fill most of the circle. The center of the nebula is the dimmest and most boring part, so I got a whole lot of nuthin’.

The Elephant’s Trunk, which is PART of the larger nebula, is only about 10 arcminutes, which is about 1/3rd the width of the moon. That’d be perfect! Unfortunately, it’s about one or two fields-of-view away from this shot. So it turns out that the Unistellar catalog is wrong: what it thinks is the “Elephant’s Trunk Nebula” is actually targeting HD 206267A, which is the super bright triple star in the center of the larger IC 1396A nebula.

I need to come back here and reposition the camera to point at some of the more interesting locations within the nebula complex, and see what I can catch.

So that the night wasn’t a total waste, I went back to the one that I shot the previous night – but out of focus – to pay homage to a great galaxy for the eVscope. It was nice to end the night on a win, instead of three strikes in a row.

M101 – Pinwheel Galaxy

53m

2025-08-22

Long dwell times definitely help this spectacular galaxy come alive.

So, in the end, I learned that for the most part, the Unistellar suggestion as to good vs. bad nebulae is mostly right, but obviously not fully correct, because the Veil Nebulae were great, and should be included (with accurate targeting info!). And I learned that the catalog is wrong…ish, since for the Elephant’s Trunk Nebula, it’s targeting the wrong thing, but in the right nebula, which is too big for the telescope, but the part you’d want to capture with the eVscope is almost perfect, so they should fix it!

Posted in Space on the back porch | Tagged , , , , , , , , , , | Leave a comment

Unveiling… the Veil Nebula!

Posted on August 22, 2025 by aknudson

We finally got a clear night last night in Seattle. It’s been cloudy and rainy for a while, which is great for the plants, but bad for telescopes.

I started by trying to catch an old friend, the Pinwheel Galaxy, and only after it’d been running for a while did I notice the focus was slightly off.

This emphasizes something I learned early on with the eVscope 2, but keep forgetting: tiny bumps to the focus knob (e.g. while moving it in or out of the house, or putting it away in your backpack or container) QUICKLY mess up your photos. I often don’t adjust focus before I start, and honestly, I should. These were adjustments that I was able quickly make with the Bahtinov mask, and I only needed a few millimeters of tweaks to get the focus dialed in. That’s how sensitive the telescope is: even though the focus for the images below were only a few millimeters off, … yuk.

So if you’re new to using an eVscope, or really any telescope, the process of getting set up should include a focus check. If you don’t, you’ll end up with a pictures like these:

M102

17m

2025-08-21

This is what happens if you take a picture when it’s out of focus.

M101 – Pinwheel Galaxy

19m

2025-08-21

Out of focus! Well, if you’re out of focus, it looks like this.

So… yeah. I’m not going to include these in the galaxies page, since they’re so bad. But I include them here as examples and reference, so you know what to do when your stars start looking like squares with crosses in the middle.

Once I fixed the focus, I decided to try for a new target – one that I’d read about, but I never remembered seeing on the eVscope list of available targets: the Veil Nebula. I don’t know why the Veil Nebula doesn’t appear on the list of available objects. If you search for “veil,” though, you’ll get 2 potential targets: the eastern veil nebula, and the western veil nebula. And then, when you pick one, the telescope complains that it’s not in the visible area. The elevation might be in the 30-60 degree range, with a reasonable azimuth, but the “visible during” is listed as “???”. But I encourage you to ignore the complaints, slew to the target, and start the dwell, because you end up with shots like these:

Eastern Veil Nebula

68m

2025-08-21

The Veil Nebula is the visible part of a huge complex called the Cygnus Loop, which is the remnants of a supernova from 10-20 thousand years ago. The Eastern Veil is one of the larger and brighter bits, and it only shows up faintly despite the long dwell time.

Western Veil Nebula

8m

2025-08-21

The Western Veil is another bright part of the Cygnus Loop. This shot got interrupted, but even though it’s only 8 minutes, I really like the fact you can clearly make out both blue and red elements of the cloud.

Western Veil Nebula

57m

2025-08-21

A longer shot of the western veil, and even though this was almost an hour, you can only make out faint elements. The bright star is 52 Cygni, which is what’s called a “foreground star.” The veil nebula is about 1,470 light years away, whereas 52 Cygni is only around 201 light years away.

Posted in Space on the back porch | Tagged , , , , , , , , , , | Leave a comment

A Slightly Wonky Follow-up on Pay, After the “Talent is a Power Curve” Post

Posted on August 22, 2025 by aknudson

If you read my article about Amazon’s new pay structure, and you also read my article about how talent is a power curve, the insightful among you may have noticed an interesting correlation between them. Specifically, could Amazon’s talent curve, when combined with the target compensation ranges, actually be a good way of compensating people “fairly?”

Well, let’s start with questioning the word “fairly.” As noted in the paper I cited in the talent post [https://www.hermanaguinis.com/pdf/PPsych2012.pdf], people don’t really like it if someone else is paid three or four times what they’re paid… even though the “someone else” is objectively three or four times more productive than they are. So “fairly” ends up a loaded term.

But I COULD believe an argument that asserts that’s what Amazon’s compensation ranges were trying to accomplish. (I’m not saying I do believe it – I’m just saying it’s possibly true.) Going back to my post, I had an example where the 50th percentile for performance was 41% more productive than the least productive person, whereas the 90th percentile was 216% more productive.

I’m pretty sure the top of Amazon’s compensation ranges are NOT three times higher than the bottom of the range, at least at levels 7 and below (Sr. Manager, Principal Engineer, etc.). Therefore, by at least one measure of “fair,” it seems it can’t be. The fact that talent is a power curve means you WILL have people that are two or three times more productive than another person in the same role. But the compensation ranges mean that you can only compensate them, what, maybe 50% more?

On the other hand, if you’re constrained by the market and by industry averages, and you want to try to pay those superstars closer to “fairly,” then maybe this new compensation model gets you closer to that goal. And by the same argument, if you can’t tell the difference between the 5th and 10th percentile, and the 20th percentile isn’t much better than either of them, then maybe lumping them in at the bottom of the range is close to the best you can do? I don’t know, though – having 65% of the people making 20% or less of the pay range would imply a very steep power curve (i.e. an alpha well above 3). Maybe that’s justified? I don’t have the data to tell.

My gut and experience tells me that software engineers aren’t that polarized – there are some ineffective ones, a lot of somewhat effective ones, and while there are only a few hyper-effective ones, I’m thinking 1 out of ten, not 1 or 2 out of 100. That would suggest a flatter power curve than the one implied by Amazon’s compensation targets.

Posted in Being a Good Leader | Tagged , , , , , , , , , , , , | Leave a comment