Tag: Are Right A Lot

Straight Talk

Straight Talk

Much digital ink is spilled on LinkedIn pontificating about hiring processes, what recruiters and hiring managers should and shouldn’t do, etc. There’s some truth amongst the noise, but I get a good chuckle when perspectives are shared with no basis in either data or experience.

This is especially true of management advice. If you haven’t actually been a manager, your opinions on how to do it are worth less than a byte stored in S3 (i.e. not much). Go give it a try and let’s talk again, eh?

Even if you don’t see yourself in such a role long-term, I recommend everyone do a tour of duty as a people manager if they can. You’ll gain valuable insights into what it takes do the very human work of running a business.

The Struggle Is Real

The Struggle Is Real

This week I got into a friendly debate about developer onboarding in two different fora (the Rands Leadership Slack and an in-person CTO Lunches gathering). My hot take: technical onboarding documentation is at best over-rated, at worst counterproductive, and most organizations shouldn’t give it much thought.

Before you pick up stones, hear me out. My logic is based partly on experience, and partly on a theory. The experience is that writing detailed onboarding steps takes considerable time, usually from well-tenured developers whose attention is better spent elsewhere. Keeping said documentation up-to-date takes even more time and is nearly impossible to do with a fast moving product. And having half-baked or incorrect instructions is worse than nothing for a new team member. Putting in all this effort just to save a little bit of onboarding time doesn’t make sense. The juice isn’t worth the squeeze.

But there’s more. My theory is that having an onboarding process spelled out in painstaking details actually robs the newcomer of the chance to build muscle through struggle, shortcuts creative exploration of how things could be better, and sets an expectation that “getting up to speed” means following a mechanized set of steps instead of self-directed discovery of a codebase and getting to know fellow team-members and their institutional knowledge through asking excellent questions.

Sure, this might mean some initial frustration. That can be managed. And it might mean a new developer is slower to begin delivering value. But my hypothesis is that once they do, they’ll be better prepared to provide broader and deeper value in the long run.

And besides, it’s likely your system isn’t as complex as you think it is, and you should be looking for the kind of people that can do their own problem-solving. If it takes someone many days just to get an app running, you’ve got more serious problems. Which makes me think this could make for an interesting interview exercise: “Here’s our code repository. Get it running in a fresh environment.”

Keep It Real

Keep It Real

I did tons of hiring during my time at Amazon. I haven’t done as much in my new role, but that’s starting to change (any open roles I’ll put on my LinkedIn profile if you’re interested in checking them out).

There’s a lot I could say about the work of both identifying good candidates and presenting yourself well when you’re looking for a job. But I’ll keep it brief today.

First, when it comes to resumes, I could not agree with this advice more.

And second, during interviews, my number one thing: tell me what you did, not what you would do. Unless I specifically ask for a theoretical answer, I want to hear actual stories of actual work and actual outcomes. Experience is evidence.

Leap Day

Leap Day

The world is a complex place. Time is hard, as evidenced by the plethora of things going wrong today. Naming is hard. Designing architectures is hard. Getting GenAI right is hard when the answers really matter.

And as it turns out, color is hard too! Did you know there are “imaginary colors”? I didn’t? How cool!

This is not an argument to run away from technology, but to say that we who do this work must be vigilant and realistic. The answer to “how long” is never “five minutes”. And we must engage across a broad set of disciplines, because our own perspectives are limited.

When confronted with complexity, the wrong answer is to retreat to comfortable simplicity. Read. Listen. Have an open mind and broaden your view of the world.

Two Things True

Two Things True

On the same day I wrote about radical responsiveness, I came upon this post that seems to contradict it. I really respect Ethan Evans and enjoy his writing (especially this bit about why you fail to get promoted). And I understand the point he’s making about fragmented attention. The temptation to conflate interruptions with importance is real, and amplified by modern communication technologies. But I’m not prepared to say he’s right and I’m wrong.

For one, I believe it’s possible to be both radically responsive while remaining reasonably non-fragmented. Some degree of interruption is inevitable, but using techniques such as pomodoro can help protect focus while still ensuring important messages don’t get missed for long. Good old-fashioned discipline is required to stick to a plan, but it can be done.

The discipline gets easier with a well-configured set of tools, which is where many folks fail. Learn your tools! And not just the basic features, but the myriad of options for managing notifications, filtering messages, scheduling reminders, etc. It’s not a badge of honor to be “bad at email” or “not understand Slack” if you’re a professional in 2024.

(If any of my coworkers are reading this, they may quickly point out that as recently as last month I didn’t know how to join cell phone calls into a conference. Which… is true. But I learned! And now I know for next time).

Finally, Evans makes an assumption about communication that I don’t believe holds true. It comes through most obviously in this statement:

“Allow chaos to build up within the trivial (the inbox) to accomplish the meaningful.”

Did you see it? The assumption that messages in an inbox are trivial? Tell that to your customer who is informing you of a serious issue with your latest release, or your team member whose employment status is in jeopardy if you don’t respond to their immigration lawyer. Yes, we all get spam, but sometimes interruptions truly are critical and need attention. To lump all of that into the category of “trivial” for the sake of personal flow is a leadership fail. Communication is part of the job; sometimes it’s all of the job.

Of course, I could be wrong. Read the posts and decide for yourself.

Not All Who Wander

Not All Who Wander

There’s a danger in over-indexing on successful outcomes when evaluating a decision. As a LeBron fan I respect making the right play even if the shot doesn’t go down. When watching football (I hear there’s a game today?) I shake my head at coaches who punt when the data says taking a bigger risk is worth it. The same is true when making business decisions and evaluating technical tradeoffs.

Simple math makes the above obvious in certain cases. Whether a decision has a 90%, 60%, or even 51% probability of success, it is the right decision to make, even if it doesn’t work out (presuming the cost of failure is equal no matter what decision is made).

Of course a nice probability cannot be known in most real-world situations. It’s in those moments when it’s especially important not to focus too much on the outcome. Because a failed result doesn’t tell us anything certain about the original likelihood of success, as even 95% certainty fails 5% of the time.

I don’t say any of this to mean that a pattern of failed outcomes should be ignored, but that full context should be used in any process that attempts to evaluate the road that led to certain results.

To The Point

To The Point

Today I finally came up with a layperson’s descriptor of the CTO role that I’m happy with:

Responsible for making sure we build things right, but more importantly, that we build the right things.

Yup, that sums it up nicely.

Distant Well-Wishers

Distant Well-Wishers

Of all the sources of happy birthday messages (which are truly delightful, by the way), one I least expected was a text from the customer service agent at CoveredCA that I worked with to get health insurance after I was laid off nearly 5 years ago, and haven’t interacted with since.

I get that it’s trivially easy for any organization that knows your date of birth to send out such messages, but…

That’s gotta be some kind of automated message, right? Or a mistake? In any case, thanks for “thinking of me” on my special day!

Taste The Rainbow

Taste The Rainbow

I’m sure there’s research out there that says people do better work when they’re happy. But anecdotally, it’s an obvious truth. Of course there are limits (“fun with respect to work” will almost always be “work with respect to fun”). But in general, fostering a positive work environment and encouraging employees to take care of themselves is good business.

Last week a colleague of mine was revising the spreadsheet we use for high-level estimation, and as part of her adjustments added a few splashes of color. The highlights had a functional purpose, yes, but they were also simply more pleasant to look at. It made me want to work on the spreadsheet at a subconscious level.

Isn’t that nice? I suppose the 49″ ultrawide monitor doesn’t hurt either. 😛

Another obvious example of this phenomenon is font quality and syntax highlighting. Take a look at the following “identical” code samples; which one would you rather work with?

Literally as I was drafting this blog I learned about Monaspace. Taking code aesthetics to the next level, I dig it. Describing the process of adjusting glyph widths as “texture healing” is an especially humanizing touch. Happiness matters!

Godwin’s Law Redux

Godwin’s Law Redux

As a tech discussion grows longer, the probability of a mention of Generative AI approaches one. It definitely happened at today’s 4S Tech meetup; we didn’t even make it all the way through the introductions.

Additional common topics: biometrics, productivity hacking, ways to get funding, something someone heard on a podcast.

Buy Me A Coffee
If you found this blog helpful and want to say thanks, I like coffee.