Author: jszeder

If you have been in enough meetings with me, you will see shadows and glimpses of angry John from years ago. I have done the math and have determined that most people are eligible for four to eleven hours of active meeting non-aggression. At that point, I have to go down a flowchart with words like “business customer” or “pays my salary” to determine if I re-up those hours. If you hit zero, I will attack you like a nineteen seventies cigarette ad, which means I will attempt to reshape your daily habits and make you look cooler to everyone around you.

I wish to crumple up and toss at least one of your habits into your mental waste bin. It is not your most obnoxious behavior; it is your use of double negatives. Perhaps thou didst observe what I didst there. There is nothing that chaps my jimmies quite so much as the thoughtful person at the end of the table nodding over their steepled fingers and raising an eyebrow to state, “That is not a bad idea.”

This just in: It could be a good idea.

Let’s set that aside for a moment, along with the gaslighting you get from being told your idea isn’t that bad.

The deep truth is that most ideas are, in fact, bad ideas.

And that is okay.

Having bad ideas does not mean you do not have good ideas. In fact, having bad ideas is a necessary condition for having good ideas. Everyone has some internal ratio of bad ideas to good ideas; generally speaking, the number of bad ideas you have is larger than the number of good ideas.

This is still okay.

It is important to tell you that this is okay and you are okay.

I have just as many bad ideas as the next person, and I have accepted this.

People participating in ideation might already know this deep secret of Idea Making… Perhaps they do not. Your goal is to have as many ideas as possible and have a safe enough place where your ideas can be shared so that you do not suffer ego death when someone takes a raging dump on them. Ideas should live or die by their merit. You will eventually find your ratio of bad ideas to good ideas, and as you succeed with good ideas, your volume of bad ideas needed per good idea will go down.

In early mobile game development, I reached the point where one idea out of five was good. Each good idea at that time generated enough revenue to fund six more games. Based on that math, the odds were reasonably good that I could keep making games and publishing them profitable enough to live to ideate another day.

I have already talked elsewhere about “not a bad idea.” The point I want to make today is that you need to have a thousand bad ideas to generate any number of good ideas.

It is okay to say something is a good idea. It is also okay to say something is a bad idea. The most important thing is to keep having ideas and improving your tools and filters to know which is which.

With that in mind, it is time to talk Amazon-Affiliate-Linked-Recommendations.

Good idea: Delicious 16-Year-Old Lagavulin Scotch Whiskey. It puts out the fire and keeps in the warmth!

Bad idea: A 36-pack of alcohol-free White Claw. My own experience with White Claw is limited to “I was there when it happened, officer,” and that is how I want it to be. I cannot fathom that there is a customer out there for one, let alone thirty-six cans of “The Taste of White Claw.”

You may now take my very best Greta Thunberg stare into the weekend. It will be a great weekend if you hurry up and get an amazing bottle of scotch from above. I have no idea what kind of weekend you will have with that many alcohol-free cans of White Claw, but you have a right to do you.

I wish I could say that today’s blog post was delayed so I could experiment with posting schedules—it wasn’t. As parents and professionals, sometimes we fail to make enough time. I forgive me, and I hope you forgive me too.

On the subject of time, I am staring at my calendar today and asking myself a plethora of questions. Why does this look like Swiss cheese? Who hates me so much to schedule so many meetings so haphazardly? How will I fit all my one to two-hour tasks into these tiny thirty-minute holes?

I started by taking the first of those thirty-minute meeting gaps and scheduling a meeting with me as the only attendee. The meeting subject I chose was “Feel sorry for myself.”

It would be easy to do that for all the remaining thirty-minute chunks of time. Then, I would look busy on paper and feel really smug about how self-satisfying that is. Unfortunately, none of the really important stuff I needed to do would get done.

Shelley wrote about this when he wrote: “Look on my Works, ye Mighty, and despair!”

Are you super-sad for me yet? Sad enough to need an Amazon-Affiliate-Linked box of Kleenex (most popular?)

I didn’t think so.

So, what can you do to preserve some calendar time and some sanity?

Good reader, I want to remind you that there are companies out there that have created packs of six hot dogs, and other companies that have created packs of eight hot dog buns. This is a very real problem.

I have decided that I am going to apply an anti-pattern here and lean into the two-bun gap.

The best way to preserve my sanity is to reverse-defrag my calendar.

Let me explain. Everyone loves a thirty-minute meeting. To preserve my sanity, I will start scheduling forty-five-minute meetings and “do not book” blocks.

For everyone else out there, stuck in their thirty-minute thinking, all their meetings will start at the top of the hour or half past. They are going to either help add fifteen minutes to my anxiety-inducing gaps, which makes them slightly more useful to me, or book them so that I only have fifteen-minute gaps, which I will use to turn away from my computer and scream into the void.

Insert a double-finger-guns emoji here, and profit. Win-win here amirite?

In all seriousness, we are ruled by our calendars, and scheduling can feel like warfare. Sometimes, you need to bear down and get stuff done. You can do things to create odd-shaped gaps in your calendar if you need to.

Conversely, this is also a tool you can use to help your fledgling leaders delegate more. On one hand, you can schedule a handful of forty-five-minute meetings with them. On the other hand, in more extreme cases, you can book an hour or even longer to ensure they don’t have time to cannibalize their teams by doing IC work.

So now we find ourselves at the end of another weekly blog post, and everyone is wondering, “Is John fucking serious?”

Maybe. Sometimes, you have to get serious to get stuff done. And if that means you need to turn the calendar into a weapon, so be it. Eat those six hot dogs and those six hot dog buns.

You will thank me when you are all finished, and you have tossed the two expired hotdog buns in the trash.

See you next week!

You might have noticed that I did not share my blog post yesterday. I recently received an education on how to LinkedIn better, and part of that process is experimentation. I am not doing this to try to induce you to buy some Affiliate-fee-collecting Amazon items, but if you are going to buy anything, it should be a portable monitor like this one. Normally, someone posts a link because they endorse it, but I know better. Maybe one of you will be momentarily piqued and buy it because no one talks about portable monitors, and you can tell me if it’s a useful product or not. Twice a year, or slightly more, I find myself in a hotel room wishing I had a second monitor for my laptop. It is almost frequent enough that I would drop about two hundy on solving this problem. A personal recommendation from one of you super smart people would go a long way to make me click. Is that not the most bullshit sales pitch you ever heard? It’s like I am using psychology to reverse-recommend something to you.

I intentionally made us all feel collectively dumber. Today, I want to talk to you about something that requires you to feel less intelligent: your company’s internal wiki page.

I am as angry at the word wiki today as I was when I first heard it during the War of 1812. It is a dumb word, and you will be worse than disappointed if you Google its Origin Story. I got used to Yahoo and Google. I even accepted the word Zune, if only out of spite for the word podcast. When I drew the line of acceptable technology words, wiki landed on the other side. The sad part is that while wiki is such a ridiculous word, it does belong to an item of serious importance to your company’s long-term growth and success.

Let’s step backward about fifteen years. A bright-eyed and bushy-tailed John Szeder has just become VP of Engineering at hi5.com. The company is several years old, and stuff is breaking in production. I have to give the engineering team credit here. They were excellent at applying tape, glue, and rubber bands to keep this website hurtling forward in time. I would frequently attempt to understand some of the more arcane fixes we had to put into production and wander around on the company’s internal wiki and the comments in the code repos to learn more about what was built and who was responsible for it.

Random polling from some of the longest-tenured engineers yielded significant shrugs when I asked them if they worked with some of the authors of the ancient features. I had never worked in a code base before that was old enough to attend public school. The notion of source code archaeology was novel to me then.

We can fast-forward significantly to today. Between then and now, I had a tour of duty at Zynga and repeatedly had the opportunity to see an old legacy system in production. It is interesting to see an old-old codebase with half a dozen eras of engineering resignations wrapped around it like tree rings from big forest fires. It teaches you to respect documentation.

Every time you join a team working on an existing product, you will add a little more to your own respect for documentation. Each README file is its own little exhibit. Each wiki page is a document for archivists to pore over and contemplate when its wisdom is called on.

You want to be careful when you are working on a product, and someone tells you, “Let’s have a meeting to go over your onboarding; the documentation is out of date,” or your product manager wants to gather you around the campfire late at night to regale you with tales of functionality. We do not call them user stories because we transmit them orally, like the bardic lore of the Middle Ages, so let’s not treat them that way.

The best-performing businesses do a very good job of recording their traditions and thinking in the form of documentation. As dumb as I think the word wiki is, I value the need to turn folklore into fact.

When someone joins a team and is instructed to follow the onboarding documentation, I always include an important addendum: “If this document is outdated, please update it. It is important to leave it better than you found it.” The next person through will thank you for it, trust me.

I think about this quite a bit as I write my blog. I also think about it when I hear game companies discuss their best practices. I am excited by some of the work we are doing at Game Data Pros because we are creating many interesting tools and processes to help companies succeed. An artifact of some of these new tools and processes is how well they are formalized.

Internal documentation, customer documentation, best practices, everything. The more things you write down, the better off you will be.

I’ll see you next week, possibly on Tuesday. I reserve the right to do some tuning over the rest of the summer as my profile becomes increasingly impressionable.

I intermittently fall victim to one of the biggest problems with the internet. I want to tangle with a friend on Facebook for something they posted. I take an adversarial position, and sometimes, I may go a little too far with the adverbs and adjectives. This might be a many-months-too-late apology for saying someone was a batshit lunatic. The emotions run high sometimes when trying to protect the soul of indie development, you know? I stand by the claim that it is always simultaneously the best time and the worst time to be making games.

Today’s discussion has almost nothing to do with game development. It concerns everyone’s favorite attempt to bring game-thinking into their not-game-thinking world. I want to talk about that popular subject that every B2C non-games company loves to never fund sufficiently: Gamification.

When that word is uttered, there are equal parts eye-rolling and vigorous nodding. The best is when the same person does it at the same time. I may be that person from time to time. I would love to build me some gamification for someone else’s SaaS business. The problem I run into occurs when I discuss the needification for budgetification. When I explain how much it would cost to inject some liquid G into their business, the only streaks that appear are in the CFO’s shorts.

That is some five-star imagery right there, and I am not sorry.

There are many books on this subject on Amazon, and I shall link the whole category in a crass attempt to get some Bezos nickels into my pockets. I know you are not big internet spenders, so I am going to skip talking about why Yu-Kai Cho’s book is good or why you should scroll down and check out Gabe Zichermann’s book. I remain hopeful that someday I will climb the ladder as an Amazon Associate, and today is not likely that day.

So what is the big deal?

Detractors will tell you that if you need to add gamification to your app, it is probably not worth it in the first place. Other people will sneer at the labors of habit-forming, considering it to be some sort of PBR tallboy in a world of fancy, delicious, snobby beers that are more pleasing to the palette. If you had to Google PBR Tallboy, you may mentally substitute White Claw or Two-Buck Chuck. The point is that they consider it to be cheap and beneath them.

I decided to sneak a phrase into the previous paragraph to help explain what I think is important about gamification—habit-forming.

I first stumbled into this term while trying to peddle my services to a random game publishing company that was essentially flopping about the internet like a fish out of water. They accepted a meeting after I gave them a reasonable dissertation on some simple product improvements for one of their better products without explaining that in my neighborhood, a truck comes around on Tuesday each week to pick up stinky cans of content that have much in common with their ideas.

As I made my way to the conference room for some random “apparent decision maker”, I could not help but notice dozens of copies of a yellow book scattered around the office.

I noted the author and the title and bought it when I returned home. If you are ever going to buy anything I link in these blog posts, this is the one thing you must buy: The Power of Habit.

The meeting was otherwise unproductive, and that company has since caught fire, fallen over, and sunk into the swamp.

That book made the whole visit worthwhile for me. I learned how to stop chewing my fingernails and applied some of the book’s logic to lose significant weight.

In addition to “Very Life Change, So Habit”, it also helped to explain a significant amount of the importance behind gamification.

The book’s point is that habit-forming is hard, and habit-breaking is nearly impossible. If you can find ways to incorporate new habits into your application, you will make friends — and by friends, I mean customers. This is really what you need to do to be successful with gamification.

The problem with bolting gamification into your application is that oftentimes, your application is not wired for event-driven systems or is missing the necessary “Zazz.” If you need to know what that looks like and have been living under a rock for the past decade, you can download an application called Duolingo to get a sense of what a decent gamification implementation looks like.

I see a few Spock-eyebrows going up in the audience. Yes, I believe that Duolingo has a great implementation of gamification. I have shelled out a few dollars for Duolingo, and neither I nor my children are better Italian speakers. How can I say it is a great gamification system if we didn’t become Italian speakers? Fair question. I can objectively look at a system and admire its form and function and, at the same time, be a disinterested churn statistic.

I think that last point is worth making. While gamification gives you a little boost in engagement and may become a new habit for some people, it is not a universal magical tool that will grant you total world domination.

Now that I think about it, maybe that last bit of brutal honesty is why no one has paid me to make a Gamification for them.

That is all for this week!

Numbers are a funny thing, especially when you run out of them. A while ago, I was sitting in a meeting discussing making a series of marketing messages with numerical priorities. I opened my mouth to issue a warning when someone on the team said, “We should assign these messages priority values as multiples of ten for future consideration.” My heart! I blinked back some tears of gratitude, and the meeting continued.

Assigning numbers to things creates some unusual problems. I recall working on a team long ago where we had a series of popups with assigned priorities. The priorities were assigned numbers, with zero being the highest priority. The priorities were also assigned in software by complicated marketing rules, meaning changing these values introduced risk. It should come as no surprise to anyone that, eventually, there was a more important message to send to the user than the one assigned to the highest priority.

The proposed “solution”, which I have seen repeated on more than one occasion, was to create a new class of marketing popups with a higher priority than the existing chain of popups. For fun, let’s call that the super popup.

For a period of time, everything was fine. As with the original popups, a higher-priority popup would eventually be sent to the application’s users. The original popup product manager and the super popup product manager had already moved on to other teams or jobs. The new product manager put together a design for a new system of popups that would be checked before the super popup and the original popup—the hyper popup!

I was in the room when this was announced to the engineering team. You could literally hear souls shattering and sadness exponentially growing throughout the room. One team veteran calmly pointed out that this would be the third time we are building a prioritized popup messaging system and that this one, much like the others, would eventually become obsolete. We would eventually need to display a higher-priority message after popups, super popups, and hyper popups.

There is a lot to unpack here. The first is that decreasing numbers for increasing priorities is a very dangerous pattern. You quickly run out of positive numbers that are less than zero.

The second thing is that while there is something psychologically satisfying about turning increasing priorities into decreasing positive integers, it is upside down and backward. “This is a priority zero!” is a much more satisfying declaration than “This is a priority three hundred and seven!”

In the first paragraph, a wise soul declared that it might be good to future-proof the system by making things multiples of ten. Why stop there? Why not a multiple of one hundred or even one thousand? If you are averse to increasing numbers to represent increasing priorities, you can buy yourself some time by spacing these numbers out into larger values this way.

This is one of those design mistakes that most people learn about by doing once. The first time I had to build a set of prioritized messages, I made this mistake and ran out of numbers smaller than zero. The message numbers were C++-based #define assignments, which meant a quick edit pass fixed the problem. If you are working on a legacy system with multiple client and server codebases outside your control, you would need to do something different here.

That’s it. That is the whole post. This is probably as close to actual coding or architecture advice as I am going to give on my blog. Ideally, you do not have to inherit a problem like this in your career. Also, if you build a set of prioritized items, you pick magic numbers like 1000, 2000, 3000, 4000, 5000 vs 0, 1, 2, 3, 4 for priorities.

The eventual person who has to inherit your feature will thank you for it. See you next week!

To be an effective leader, you need to develop many skills. Communicating is one of the harder leadership skills for software developers to master. One of the reasons I started this blog is to help spread my painfully acquired knowledge about engineering leadership to people… If one person changes their actions as a result of a blog post, then that was a blog post worth writing. Writing this blog is not a community project—I have a great editor and a premium Grammarly subscription. I am grateful beyond words for these two things.

I also write this blog because it helps me be a better communicator. Communication is an important part of leading people, and I have a few more posts about it in the queue.

Today’s post is about editing.

As a leader, you need to apply many filters to your messaging. This gets complicated because you might need to apply these filters in real-time or figure out how to artfully retract or edit a misstep in your messaging. Thankfully, Slack allows you to delete or edit your messages, which is one of the features I appreciate tremendously. You can sneer all you like at me, confessing to posting a message in an incorrect channel or for an incorrect audience. Karma will fax you your comeuppance eventually; it has happened to me and will happen to you.

Here are some filters you may apply when putting your words onto the internet for all eternity.

Does this violate human resources or employer policies?

This is generally an easy one to follow. Most of us have common sense, an understanding of confidentiality agreements, and possibly training about what is and is not acceptable in professional communications.

Am I being unreasonably aggressive to one or more people?

This one is tricky. When you want to give someone really hard feedback, it is important to give it privately. It is also important to couch it professionally. I enjoy the “coaching sandwich” approach to written messages. You start by saying a positive statement, followed by your feedback (generally not positive), and you close with another positive statement.

“Hello, Sam. You just took down production due to an issue in your code. It appears to be a single line change, and do you even test this stuff?” is one way to communicate an issue to a team member.

“Hello, Sam. Thank you for taking point on this week’s release. Production went down for a small window of time due to a small change in the code. In the future, it would be helpful to verify changes, even little ones, to our deployments.” is is a better way to say it.

I do think that there are times to publicly tell your teams that there are issues that need to be addressed. My general approach is to message them privately first. If multiple people are making the same mistake, I might politely message the team publicly once or twice while I figure out what the overall issue is with what I am saying because sometimes the message might not carry the right level of concern or severity. Eventually, I might get to the point where I tag them publicly after I have exhausted all possibility that I am making a mistake in my communications and have given enough hints that I believe the time to wait for habit-changing has passed.

Am I hurting my team’s morale?

This is a tricky one. I have developed a good sense of what doesn’t hurt my team’s morale—by saying enough things that have driven a bus over their morale. Sometimes, I even went so far as to back that bus over the team for good measure, giggling like a madman.

Figuring out the right tone to talk to people on your team takes some time.

“Hello, I need to delegate this task to one of you, my direct reports, so I can do more important things” is one way to communicate that you need something done.

“Hello, I need someone to take on an important team responsibility that presently does not have an owner” is another way that says the same thing.

Here are a few things to note. First, don’t talk about your team as “my team.” Instead, talk about it as “our team” or “us”. I am a big fan of the “we” when talking about work. Second, do not make it sound like the work is beneath you. I will do a shift of QA when it’s needed to get stuff done—I am not proud. Presenting task choices to people as an opportunity to lead and own things is a much better approach than looking for a minion to delegate your work to.

Is this the right time for this message?

There are a few elements to message timing, especially on Friday. Please don’t fuck up somebody’s weekend if you do not have to. If I have bad news for someone, I will do my best to deliver it to them earlier in the week or on the following Monday. I know some bean counters out there will mumble about lost productivity for the dark cloud you just hung over someone’s noggin, but if it is work-related, that should be okay. Don’t send someone home to be all pissy when they take little Timmy to Little League on Saturday morning.

You will also want to avoid Friday if it is an important message. Or, if you have to deliver the message on a Friday, send a reminder to yourself to reiterate the message the following Monday. People will blow up their mental stack of work over the weekend, and if you expect everyone to have full recall and clarity after a Friday announcement, you will be disappointed.

Am I giving enough context for this message?

This merits its own article. Sometimes, people are in the middle of doing something, and when you ask them a question, they have no idea what you are talking about. Not everyone is in your head 100% of the time, and they might not understand what you are asking without a decent explanation. I am working on improving my own context-setting in messages.

Is there anyone I can ask to look at this before I send it?

This last question is the hardest for a new leader to answer. Many assume they must demonstrate that they have A+ Advanced Communication Skills on day one of their job. This is far from true! I will send draft messages to peers, managers, and even select team members who report directly to me to make sure it makes sense. You absolutely are not alone on your road to leadership, and if you have a good relationship with your boss, I 100% recommend that you take advantage of their guidance and advice in communicating with teams.

This brings us to our final two questions.

How do I feel if I pretend to be my audience and read this message?

Being able to read a message as if you are someone else is a hard skill to master. It is also an important skill to attempt. If you cannot successfully imagine how your message reads to other people, your leadership journey will be hard, if not downright impossible.

I feel like I ought to be clapping with each of the last four words above.

If. Not. Downright. Impossible.

I am sorry if I just clobbered you on the chin with a size twelve shoe.

Leadership is hard, and communication is really important. You can have individuals at work with whom you may assume some familiarity and relax one or two of these rules. You will also have times when you will need to go through this list two or three times for a really important message. You should start to develop the habit of reading messages like you are someone else if you want to take your professional growth seriously.

This final question is meant to be thoughtful and to take you away from feeling like I just shoved you down the stairs.

Does this message make sense?

This question makes me want to grab my Slack window and shake it violently. I would love to have some kind of magic voodoo software to parse my Slack messages ultra-fast and better catch goofy typos and incomplete sentences. The red squigglies underneath a mistyped word are insufficient, and I struggle with mid-stream edits when I am urgently capturing or transmitting information. I do not think I am alone in this. I think that we sometimes take it for granted. Some software does better at post-whargarble-entry error correction, and some teams do their own forward error correction correctly enough that it does not matter significantly in some environments. In other environments, you look like a zoomer fr fr, and that might not be a good look.

Thank you for reading along today. I do not have a tantalizing Amazon Affiliate Link for you today. I also don’t have a crappy one.

See you all next week!

I spent some time this weekend assembling an inexpensive pergola that we purchased from Amazon.com. I will not link it here, it is functionally equivalent to a tattoo that says “NO RAGRETS.” As hard as it is to believe, I do not need to steal nickels from Jeff Bezos that badly. I wanted to compare and contrast this with a different purchase I made the week before. I purchased a fancy pillow (and yes, I will steal nickels from the fancy pillow).

The inexpensive pergola aims to provide photon shielding for my children when they enter the backyard. I have purchased enough backyard items to know that everything we leave under the California sun’s withering glare will be swiftly reduced to crumbling rubble. This is even before any planned obsolescence is taken into account. The opportunity cost of buying an expensive backyard item that gets destroyed in equal time is simply too much. You can buy two cheap things and get twice as much utility over time.

On the other hand, I purchased a very high-quality pillow. You will spend hours daily with your face mashed against a pillow. By the same logic, I also want to get high-quality mattresses and high-quality chairs. You will spend lots of time rubbing parts of your body on these items and something-something posture. I would love to take this moment to call out my fancy Secret Lab Co Chair. Unfortunately, none of Jeff Bezos’s nickels get stolen should you buy yourself one of these chairs.

When I said high-quality, you knew that I meant expensive. Some things are worth it at any cost. You cannot really put a price on the quality of your sleep or your posture.

What does this have to do with engineering leadership? Plenty. You will find that there are many things that fall into the same category of Pillows, Beds, and Chairs in the software world. You will spend many dollars on Slack, email, and GitHub licenses. When designing your organization and choosing the products you wish to buy, you must ask yourself, “Am I buying an inexpensive pergola, or am I buying a fancy pillow?”

That’s it. That is the whole post. This is small enough that I could make a TokTok on it and get huge on the socials. Just maybe?

A girl can dream…

See you next week.

I have been coaching and mentoring engineering leaders for at least a decade. There was a recent article in Forbes about formal mentoring, and now that I have mentioned it, I cannot find the specific article. If you feel like using some Google power, there is a whole pile of older ones. I cannot link it because I just hit some monthly five-article limit on Forbes articles. Unrelated to Forbes and its paywall, I learned about some interesting tools and frameworks to apply to mentees as a result of my own transcendental coaching experience.

I recently established a formal coaching relationship for an engineering leader. Finding a good coach is difficult and becomes more difficult because each person responds differently to different coaching techniques.

When I was interviewing one coach, he asked me what specific issue I needed him to help fix. I responded that we do not yet have a particular issue and we just wanted to give a developing leader a coach. The coach was super puzzled by this. He responded, “I usually do not get called in to fix something until after something is broken.”

I had an “aha” moment occur here.

Let’s go back in time for a moment first.

I developed an informal ten-week program for training new managers ten years ago. About five years later, I wrote down all the parts and created a formal boot camp. Everyone involved appreciated the training, and they were surprised how much of it was based on stuff I had to learn the hard way—from the school of hard knocks.

My “aha” moment was that most people generally do not invest in coaching or mentoring their engineering leaders until they find a gap that needs addressing. Rather than ensure they have a strong foundation for leading and managing based on some foresight and preparation, they would rather let people figure out some of the hard stuff and pay for a coach when the gaps are clear.

This strikes me as disturbing.

I respect that bean counters would rather pay for fractional coaching to solve a specific problem. However, I also think that is myopic and dangerous. Suppose your engineers are highly valuable knowledge workers. In that case, you should consider it a wise investment to prepare them to manage said high-value workers to ensure their happiness and productivity at work. Gambling the health and well-being of your engineering team is incredibly risky, and the cost of replacing key staff is significantly higher than the cost of getting coaching for your newly promoted leaders and managers.

One side effect of this is that there are many coaches out there with a toolkit for helping fix specific reactive issues and coaches with a more far-reaching and proactive curriculum of materials.

You can guess which bucket of coaches I have sorted myself into.

• If you are contemplating getting a formal coach, ask them some questions.
• Do you use any formal assessment tools on mentees?
• Do you assign “homework” for items that your mentee needs to work on?
• Do you have a comprehensive list of conversations for every particular mentee?
• How often do you provide report cards or feedback to your mentees?

If your prospective coach struggles with some of these questions or provides evasive answers, they might be a better reactive coach who can help drill down into prospective areas and help a struggling engineering leader with their day-to-day issues.

If they have good answers to these questions, they are more likely to be a good proactive coach.

I do not know if there is any correlation between the two styles. Are people who are good proactive coaches also good reactive coaches? Any answers here would be purely anecdotal.

I do both types. If I have the luxury of time, I like to get started with a proactive set of materials. However, there are times when I am brought in as a reactive coach and have to jump right into firefighting.

My secret hope in writing this is that people will talk more with their existing bosses and leaders about formal coaching. According to Forbes, there are some material benefits to this. I acknowledge that this is a very self-interested statement, and you might argue that this is a sales pitch.

I am not going to disagree.

See you all next week!

I attended an OC CTO Tech Talk this week. The speaker was impressive and told an awesome story about migrating from Redshift to Databricks on AWS. There was a really well-built slide in the middle about the importance of mapping your long-term technical roadmap projects to business objectives and metrics, and this one bullet point stood out to me: “Avoid chasing shiny new tech.” I scanned the audience on this slide and witnessed an ocean of furrowed brows and puzzled expressions. At the end of the talk, there was this hilarious schizophrenic Q&A where about half of the questions came from the audience around shiny new tech and tactical questions, and I had my hand up to ask a series of related questions around soft skills, coaching, and having a mentor.

I talked with the speaker at the end of the event and thanked her for an amazing presentation. We spent a few minutes discussing the challenges of growing people professionally. In particular, we both commented on how there is a decent amount of trauma from previous bosses for most people who join your team at a startup.

Sometimes, managing people feels a little like being a professional psychologist. I first encountered this phenomenon over twenty years ago at Digital Chocolate. I was in my first director-level role and struggled a little with some of the business strategy and product direction. After some of my 1:1 meetings with company leadership, one of my peers, a producer, would ask me how the head shrinking was going. Five years later, I reflected on that comment while managing a team. We hired a new developer, and I spent considerable time unpacking that team member’s issues to help them be more successful.

Let’s fast-forward to today, after many years of high-velocity team building. I have learned that most people’s performance is heavily impacted by their previous managers—sometimes positively and sometimes negatively.

If you have an employee who has had a toxic manager or a manager with a scarce mindset, you will need to spend considerable time helping them work through that trauma to make them successful. I know that my two worst managers have shaped some of my behaviors. Now that I am in a leadership role, I find myself staring in the mirror occasionally to see if I can see them staring back at me. Whatever my faults are as a leader and a manager, there is a subset of behaviors that I self-regulate heavily to make sure that I never manifest them.

I don’t want to make light of people with startup trauma, but making them successful long-term is a lot like rebuilding Humpty Dumpty after his wall incident. It takes a lot of effort to get people into a place where they can deliver great work and feel safe to take important professional risks.

What are some things you should look out for?

The frightened messenger. If people try to hide bad news or get others to deliver it on their behalf, they fear being held accountable for it. If something breaks, it is important to confidently tell leadership there is a problem, especially if it is serious. The sooner, the better.

Swimming in denial. Have you heard someone say, “We will be late on the deliverable, and we will move the deadline by one week” three weeks in a row? Understanding how far something is behind and what needs to be done to deliver something is important. “I need more time!” is not enough. “How much time do you really need?” is needed.

Superman syndrome. Volunteering to step in and stop the bank robbers is also another problem. This is a super serious problem if you save it and still do not manage to move the needle on a struggling project. It is also a problem if you do it too many times because if you are good at doing your team’s work and you do it enough times, they will develop learned helplessness. Sometimes, this is absolutely necessary, but it is less often than most people think.

The hedge-hog. If you think about considering the possibility of contemplating a decision after consulting with stakeholders to align synergies, you might be a hedge-hog. A trivial example of this behavior is asking someone, “What is the ETA for your current task?” They reply, “I am working on it right now!” Sometimes, people do not love committing to dates because they have been punished. It is important to make decisions and commitments.

The hungry hoarder. When I took too much food at the family dinner table, my parents would look at me and ask, “Are your eyes bigger than your stomach?” Taking on too much work and not necessarily reconciling that work against your existing commitments before accepting it suggests that someone may be a people pleaser. If they over-commit and under-deliver, they may have had a toxic manager in the past who rewarded people who would work long hours and try to push through as the hero who saves the day. This is an unhealthy behavior. I recall offering some strategic tasks to a team member as an optional activity. I was interviewing three candidates and suggested they could shadow one or more candidates to see how I do my initial screens. I know they had some tasks that were due soon, and in my mind’s eye, I believed they would decline to do all three if they were worried about missing deadlines. They cheerfully accepted all three optional interview screens, and a week later, they missed delivering on their core work. It was an unfortunate situation.

When I encounter some of these behaviors in team members, I often spend time with them unpacking the source of the behavior. If we can figure out where it started, we can create a plan to fix it.

After giving someone an opportunity to stretch and grow, like the previous hungry hoarder example, you will have a pretty clear “teachable moment” to discuss with your team member what went wrong and help go through the decision-making that led to the unfortunate result.

A previous boss often constructed hard tasks for his direct reports to observe how they got stuff done. He would assign them a challenging project with insufficient information or resources to witness their “default tendencies.” He would do this under a controlled environment to be prepared for their default tendencies when there is an actual work crisis.

It is an effective way to understand what your people are capable of, although it is a bit “old skool” as a way to learn how your team operates.

You cannot learn this early on as a leader or manager. This is one of those things you develop over time through hard practice. You will also develop the skill of fixing team members through breaking deliverables, teams, or entire companies.

Situations like these are why I choose to mentor and coach people. I have had some people who have started a new role, and from the way they describe their new boss, you can tell that there are rocks in the waters ahead. I do feel a certain amount of relief when I can help someone steer through those waters clearly. I also feel empathy during the times when we are not able to clear the rocks together, and the ship gets wrecked. Talking through what went wrong and how to do better next time is a part of professional improvement and personal healing.

I suppose this is where I make the sales pitch. I like to mentor people and help them professionally. Let’s talk if you feel like you have team members in these situations or bosses who exhibit some of these traits and want a partner to give you perspective and help steer you through some of your challenges.

Have an excellent week!

The most challenging UIUX work is in video games. I almost want to stop there and say, “That’s it, that is the whole post.” It is not like I get paid by the word, nor do you click on any of the books or random items I link here with the hope of stealing nickels from the Bezos. Okay, a few of you clicked—enough for me to get paid once in the many years of writing. Thank you for that.

When I was designing my own mobile games, I had a small office located above a Starbucks. I played a game of my own there because a decade or so ago, there was a pretty easy way to get a third of your coffee from Starbucks for free. I remember explaining this to a friend of mine. His wife used to work at Starbucks, and the brand loyalty was so deeply etched into her soul that she got angry at my cheeky stunt and punched me in the arm. If I do not post the sneaky trick everyone in your town is talking about, I fear the internet will punch me.

Enough about Starbucks hacking.

In addition to intermittent free Starbucks coffee, I also went there to test whether my games were good. I would go to the staff or occasional regular that I recognized and thrust a test phone into their hands. “Here is my game!” I would proclaim loudly, “tell me what you think!”

You can guess what happened next: Nothing at all. People would invariably freeze up for two reasons. The first is that they did not know what to do. The second is that they were afraid of doing the wrong thing.

This was my introduction to user testing. I quickly learned I should add animations to my mobile games to help drive decision-making and button pressing. This was the first of many places where I added subtle pieces of animation to help unfreeze people in possession of one of my mobile games. I should have learned this lesson years before while playing Bejeweled. If you stared at their match three board long enough without finding three in a row, it would give you a subtle hint that there was a possible match. I confess to being so focused on getting that dopamine fix from counting to three that I may have missed the learning moment.

This is an essential thing for game developers to learn. Okay, there two things game developers should learn. First, you should always try to put your game into “n00b” players’ hands to see whether your game explains itself without you, the developer, talking. Your players might not survive by their wits alone. Second, player testing is incredibly valuable. The more people who play your game who satisfy the requirement of being “not you,” the better off your final product will be.

That’s it. That is the whole post.

See you all soon!