Artisanal Concatenations of Sentient Emanations

I have spent a decent amount of time in the past few weeks experimenting with marketing. Some of this involved flat out spending money on audio equipment and some of it involved “Collabs”. Some of this also involved figuring out how to inspire curiosity on the tweeters.

For those of you who did sign up at derfdice.com as a result of all that marketing—Thank you! I have been randomly handing out premium account upgrades like they are candy due to the volume of good feedback I have received from people.

I am super glad to see that I am starting to get traction.

I will be sprinkling more of my personal learnings into my weekly posts. I am very sorry if that is less interesting than my reflections on decades-old career mistakes. I cannot pretend to know the desires of the silent majority and I have not yet gotten any requests for content from the vocal minority. Do I even have a vocal minority? If that is you, say something!

Today I want to talk briefly about making cool tables. There are a lot of people out there writing about the problems that Derfdice solves and even some well-dressed internet people posting videos about it.

I discovered this week that there is considerable value in show don’t tell.

I initially just started sharing the text outputs from a few really good tables. That did not get me many stars on the Yelp.

So I decided to leverage The Power Of The Internet And Technology. I have been using some really cool procedurally generated art tools from starryai to help generate some more visually compelling posts. I think this has been successful.

I think I started getting more success when I decided to create my own new tables to show the art of the possible. In a magical world of tomorrow I am hoping to feature other people’s tables but for now I am going to eat my own dog food. You can Google that if you like—it is a popular enough and important enough early startup activity that merits its own gross-sounding soundbyte.

This week I built a table to generate ominous random buildings and that is when people started showing up to the party.

The good news is that making tables is fun. The bad news is that I need to figure out how to get people to stick around on the site long enough to want to make a table or two. Part of the magic in making tables is in using other people’s publicly available tables.

I am going to include the top level of the Ominous Fantasy Buildings table for an example:

Ominous_Fantasy_Buildings

1d13	Result
1-3	{cthogan::Somewhat_Sinister_Site_Names}, {Building_Descriptor} {derflib::Fantasy_Religious_Buildings}
4-6	{cthogan::Somewhat_Sinister_Site_Names}, {Building_Descriptor} {derflib::Fantasy_Civic_Buildings}
7-9	{cthogan::Somewhat_Sinister_Site_Names}, {Building_Descriptor} {derflib::Fantasy_Military_Buildings}
10	{cthogan::Somewhat_Sinister_Site_Names}, {Building_Descriptor} {derflib::Fantasy_Religious_Buildings}, {Building_Special}
11	{cthogan::Somewhat_Sinister_Site_Names}, {Building_Descriptor} {derflib::Fantasy_Religious_Buildings} built on the ruins of a {derflib::Fantasy_Military_Buildings}
12	{cthogan::Somewhat_Sinister_Site_Names}, {Building_Descriptor} {derflib::Fantasy_Military_Buildings}, {Building_Special}
13	{cthogan::Somewhat_Sinister_Site_Names}, {Building_Descriptor} {derflib::Fantasy_Religious_Buildings} built on the ruins of a {derflib::Fantasy_Military_Buildings}, {Building_Special}

This is probably a bunch of noise to most of you but the above table from derfjohn uses tables from both derflib, an account I made that was populated with a bunch of really simple tables, as well as cthogan, a good friend who created some really cool tables.

If you scrutinize this table closely what you will see is that it generates a handful of really common structure names 9 out of every 13 times. There are a few different building types to add variety.

If you look closely at the remaining 4 out of 13 times, it generates a Special description.

Building_Special

1d11	Result
1-3	shrouded in dark clouds.
4	in the heart of a decaying forest.
5	on the edge of a rumbling volcano.
6	amidst a corpse-strewn plain.
7	atop a treacherous peak.
8	in a misty valley, reeking of death.
9	overlooking the ruins of a destroyed city.
10	surrounded by a swampy moat.
11	where {Royal_Male_Name} fell in battle.

The end result is a pretty wild collection of ominous buildings.

You will notice that some percentage of these entries are pretty much trash—This is okay!

The beauty of this site is that it generates a whole pile of randomly rolled stuff so you can pick out the parts that you want to use.

It is far easier to pick three really cool sounding things out of a list of ten items than it is to create three really cool sounding things.

You will notice that there is a hefty amount of special buildings that are shrouded in dark clouds.

This table is a work in progress. I expect that will eventually just be “1” instead of “1-3” on the table. There are some tables in derflib that have 200 entries.  At the end of the day this will probably be closer to 20 than 11 but you never really know.

Feel free to check out derfdice.com if you need to generate random content—whether it is for a TTRPG game or for a bunch of NPCs in a video game or even if you want to make a funny spicy internet startup name generator.

As always, please feel free to Socials this post. Hopefully you find something here interesting enough that is worth sharing.

If that doesn’t happen I think I have enough eyeballs here to start assaulting you soon with Raid: Shadow Legends ads. I am hopeful it will not come to that!

See you all next week.

I am going to start off this week strongly recommending you read The Power of Habit. Yes, this is an Amazon Affiliate Link. Yes, I fully intend to profit madly from it. Yes, I am aware that this is totally wishful thinking even though I liked this book so much that I have purchased it repeatedly.

I first became aware of this book when visiting the office of a random HTML5 game company and noticed that they sprinkled copies of this book around the office. It piqued my curiosity and I decided to buy my own copy at home and read it for myself.

I wish I had read this book in 2004 even though this book was published in 2014. Reading this book would have helped me to understand why one of my game publishing experiments was doomed from the beginning.

One of the important parts about releasing a successful game is understanding that you need to release one or more unsuccessful games before that happens. You need to build a lot of stuff to ship a game and very seldom will you fire on all cylinders right out of the gate. I have come to understand that you sometimes need to build these pieces in isolation so you can stack your successes on top of each other. You are correct if you think I have written about this before.

The previously mentioned doomed game publishing experiment was a Flash game that I released on Kongregate. I decided to create and publish a game that included some fun narrative elements. In order to keep the costs down and reduce the schedule I wanted to keep the feature set very small. I wound up making it too small. I decided that building a progression system was not important to the story and therefore would not add much to the product.

I am going to fast forward a few months to the blistering comments in the three star reviews. The universal feedback that I received is that this would be a much more engaging product if it had some progression systems built in.

So how did I wind up in that place?

The answer is a strange one and an infinite one. In fact, it is also an adventure and it is space.

For those of you who assembled the keywords correctly, I am in fact talking about Strange Adventures In Infinite Space.

Strange Adventures In Infinite Space, referred to as SAIS for the rest of this post, is an entertaining little roguelike game where you are piloting a spaceship into a vast and unforgiving universe.

Every game you played was randomly generated and filled with unequal amounts of wonder and dread—emphasis on the dread. Most of the time SAIS is a very short and brutal game. You launch yourself into the cosmos, you encounter horrific and bewildering aliens, and sometimes find mildly better technology for your ship.

The vast majority of endings are terrible. You either die in the nether reaches of space, or return home unprofitably and wind up broke.

I wanted to love this game so much, I really did! Unfortunately playing SAIS is like scratching a mosquito bite—it is fulfilling in the moment but leaves you with painful welts and scars.

If you are a dirty roguelike lover, you are probably mad right now. I accept that. I am happy to have made you angry because that is the response that loving a roguelike inspires—it makes you angry. You should probably slide your chair away from your computer and count slowly backwards from ten while you process your emotions… I assure you that I am gaslighting you from a good place.

SAIS is absolutely a “critically acclaimed indie masterpiece”. That means it did not sell millions of copies.

I do think that the creator of this game would have similarly benefitted from a read through of “The Power of Habit” which I have linked above in an effort to steal nickels from you and Jeff Bezos at the same time.

I will not steal the thunder of the aforementioned book. I stand to profit from vaguely encouraging you to read it in many many ways. I will at least say that I have accepted into my design tools the importance of habituating players to games.

And this is where SAIS and many roguelikes have failed.

It is important to get players into the game as fast as possible and experience what a game has to offer. Through the power of modern analytics, we can put most games under a microscope and understand things like “replayability” and “churn”.

A deep study of graphs and data from mobile games will show you how fast a player will yeet out of your game. I know these are very scientific terms and I hope you will believe me when I say that a player is much more likely to stick around and play your game if one of two things happens: They have to be rewarded for their time in some capacity or at least believe they have the ability to be rewarded in the near future.

Modern roguelikes have accepted that this is important and similarly learned the lesson of my failure on Kongregate—progression is important! I will call your attention to the elegantly crafted “Vampire Survivors” game. It has tens of thousands of overwhelmingly positive reviews on steam, and is a game where you tend to die frequently and horribly.

Regardless, they have added a sufficiently valuable progression system that lets you carry some success forward from your failure in the form of collectable gold coins you can invest in your baseline character for marginal gains for each replay.

This is an important lesson to learn if you are building games. It is also an important lesson to learn if you are building consumer products in general. Establishing habits and rewards for players is a very important factor in the success of a product. Habits and rewards would have improved the outcome for my little publishing experiment. Habits and rewards would also have catapulted SAIS to greater success and fame.

The most amazing part of SAIS for me was its sequel. I do not think that there is a sequel for a game that has failed so hard to be better than its original than the sequel to SAIS. It is so bad that I do not want to name it or link it. It is so bad that I actually feel like I need to give you one of those “this product may cause injury, rashes, pain, or worse” disclaimers like one of those creepy tv commercials for medications before you go off looking for it.

I talk quite a bit about SAIS because I wish to make my own version of a space exploration game. SAIS was very close, as was another similarly unrewarding mobile game called “Out There”.

A space exploration game that is more fun and more enjoyable than SAIS is in my list of top five products I wish to make. There are probably a hundred things in that list or more. I always tell people I am more than happy to talk about items six through one hundred because I know I do not have time or ability to do anything about them.

I talk a little less about items one through five because they are My Ideas and they are Precious to me like that stupid One Ring is to Gollum.

I will share “John’s Big Five List Of Games I Want To Make”, even though talking this much about them takes me completely out of my comfort zone.

1. An MMO where every sentient creature (monster, animal, and player) is driven by players rather than AI.
2. A survival game where crafting patterns are granted one at a time to the world to “craft progenitors” who create artifacts for a time limited window that get incorporated into world lore before patterns become widely available.
3. A train game. Heck yeah! Who doesn’t love train games?
4. A space exploration game with delicious emerging narrative. See SAIS. Also see: The Expanse.
5. A modern Gateway To Apshai variant, which just so happens to be the 8-bit successor to Diablo.

I reserve the right to reorder this list of Audacious Projects and move things up and down into the top one hundred. I have seen items from the middle of the list emerge into the marketplace as novel products with varying levels of success. There are no new ideas I suppose.

In the meantime, I hope you at least decide to take a look at SAIS and perhaps even read the previously linked book on Habit. Hopefully you have all made a Habit of reading my weekly ranting.

Speaking of weekly ranting, this one would not be complete without me attempting to gaslight you all into being my marketing department. If you enjoyed this assemblage of letters dancing over your eyeballs then Retweet! Share! Print-and-fax if that is all you can do!
See you all next week when I once again fail to get nickel-inducing clicks on my precious and clearly labeled affiliate marketing links.

I know I generally set aside some time to write posts on Sunday but today I spent the whole morning writing documentation. I would feel terrible if I did not sit down and say something for a whole entire week.

I am going to take this opportunity to talk about my Derfdice product. I previously described the problem late last year as the “Joe-the-Elf” problem. It is a problem I have found in my own games and I believe that it is a problem that exists for other game masters. I have found some evidence this is true.

There is a bunch of my personal and professional philosophy wrapped up in this product, which I won’t get into much here. Not today. I want to talk to you about the marketing journey that I am undertaking.

I have to start by saying I do not know much about marketing. I can spell the word and that is basically about it. I have at least two friendly marketing friends who are spending time, out of the goodness of their hearts, to help me learn a little about their craft.

Here is some of the stuff I have learned so far:

If You Use It, You Love It

I am now getting unsolicited feedback from people who are creating tables. A few table creators have made tables that they will start clicking on them and completely lose track of time. Some people are also using these tables in their live games and sharing stories about outcomes from their games.

Product Market Fit

I do not know if I have product market fit… Yet. I have a product—I have yet to see a complete stranger get into said product and independently decide to pay it. I am early enough in development that I happily gave a free year or two of premium access to literally everyone who has communicated to me that they have signed up. I am hopeful with the next round of FTUE changes that I will be ready to see if everyone agrees with the economics for the product I have proposed.

Content is King

I also know that as much as I wanted this to be a pure creator’s platform, it is actually more of a consumer platform than I believed it would be. Derfdice will live and die by the quality of the tables that people can share with other people. I have made a few tables now and ultimately I think that people making their own amazing tables are a smaller subset of users than folks who just want to come and randomly click on prebuilt tables. This may have been obvious to other people—it was not quite so obvious to me.

Socials

I have spent some time trying to get good at Twitter. I am better at it now than ever before and that is not saying much. I created an account specifically for Derfdice and I am now attracting followers and sharing fun stuff. I have created a table of random promotional items that takes advantage of the linking feature to promote awesome homebrew creators and their fine quality items.

I have joined a few Discords to talk about my product—with varying degrees of success. I have sponsored a few prize pools for user competitions with the best of these because the quality of their community is really great.

I am also about to experiment with TikTok. Do not hold your breath for me to get up there and start twerking. I do not wish to hurt my knees or your sensibilities. Enough people have encouraged me to go this direction that something will soon arrive—yes I am vaguebooking.

Video Production

At the gentle urging of my marketing mentors, I have created some video walkthroughs for my product. I acquired new hardware for this exercise and created a “not terrible” tutorial channel. Nearly immediately after, I discovered new words like “subsonics” and “microphone shock mount”. I am going to be doing a before and after comparison on these once I have finished assembling my new toys. I may as well include an Amazon Affiliate link to the Pop Screen too since I ordered all three. These videos are linked to the friendly welcome screens that adorn the front page.

PS: Yes I am actually linking Affiliated Links for products I actually purchased!

I Have Amazing Friends

Even as recently as yesterday I have gotten text messages from people who are evaluating Derfdice with constructive feedback. Sometimes it is hard to test all of the screens on all of the devices. I am super grateful for all of the feedback I have received from people who have checked things out and informed me when there are issues. I am extremely grateful for all of the feedback I have received on the journey so far.

Speaking of the journey, it is only just beginning. I have a few low cost marketing experiments to conduct over the summer and I am still in the process of looking for suckers early access partners from friends and family who may want to play around with a dungeon master’s tool—especially if you are feedback oriented!

I will keep you all posted on the journey. I am probably going to follow up again about some of the marketing experiments I have conducted and maybe share some fun stories. In the meantime feel free to check out the site at www.derfdice.com or check out a few tables I have shared publicly including some that are created in collaboration with dungeon masters.

See you next week for more story telling with about fifteen percent less shameless self promotion!

One of the most important things to do as a leader is to give people enough space to make their own mistakes. It is really hard to do and it is important. Some people learn better from making mistakes as opposed to being told that they are making a mistake. Ideally, they learn over time that it is better to listen to counsel than to keep making mistakes.

Now it is time for me to tell a story about my father.

My father hated everything about computers. I understand his reasoning although given what I do on a day-to-day basis you might expect that we disagree on this point. He has done multiple jobs over the course of his life—farmer, butcher, woodcutter, and many others. Over time he built up a beautiful farm where I was raised. I did not appreciate that very much when I was growing up—I was too busy trying to figure out how to escape to pursue my own dreams.

I have two older brothers who continued on with my father’s way-of-life. I watched from the sidelines as my father attempted to teach them valuable lessons. More often than not, they would hear my father’s advice and choose to do their own thing—they wanted to make their own mistakes.

I wanted to write about this because I realized recently that he was trying to impart his wisdom to them and I was struck by one phrase he used repeatedly.

“You are going to stick your hand into the fire. The problem is that you are dragging my hand in with yours.”

He would say this with a visceral amount of frustration. I could hear it in his words and see it in his pained expression. Nonetheless, he would let them stick their hand in the fire and shake his head sadly when something went wrong.

I still do this from time to time—I stick my own hand into the fire, as well as have my own hand dragged into the fire by someone else.

I appreciate his frustration and pain much more now than I did when I was growing up on the farm.

The hope is that you can communicate the pain of a mistake sufficiently to someone else that they can agree not to stick their hand in the fire. It is much harder than it sounds.

If you get burned by sticking your hand into a fire, it is a good idea to admit it and acknowledge it to anyone whose hand you dragged into the fire with you. You owe them the courtesy of the mea culpa.

It is also equally important to admit it to yourself. This will help you appreciate someone’s advice in the future when they are going to counsel you not to stick your hand in the fire.

If you scoffed at this article, then please click on this link. This is a book about making mistakes. For example, it would be a mistake for me to link this book and not tell you that I am going to get paid as an Amazon Affiliate. Maybe it is a mistake for me to recommend products on Amazon that I have not actually bought? Either way, thank you for reading along this week and I apologize for last week’s holiday induced hiatus. I truly appreciate you reading along even if you are not providing me with a veritable shower of nickels and dimes from sweet, delicious Amazon Affiliate merchandise.

See you next week when I hope to have all of my FTUE stuff live. 

PS: If you are all about that hashtag TTRPG and you also think that tutorials are for suckers, you should go and sign up now before I go and improve site onboarding.

Nothing to see here, move along.

I remember one event vividly in the first seven years of my career. I was working with a peer on an incredible product. We decided to go grab coffee. Out of the blue, my colleague decided to pop off on one of the other products. The language was shockingly coarse and the tone of the entire conversation was angry and surprising. My colleague continued on in this manner for about ten to fifteen minutes. At the end, he took a deep breath, looked at me and sighed in relief. 

“I feel better,” He said with clear satisfaction, “Now let’s get back to work.”

I believe this was my introduction to venting.

So what is venting? What is good about it and what is bad about it?

Venting is a method of relieving stress and tension. Over the years I have seen many flavors of stress relief—from disconnecting, quiet introspection (often while walking), and venting.

Venting is when you articulate many or all of the things that are bothering you about a particular subject. I have met many people who want to vent about their problems before they can constructively solve them. There are times that I like to vent about things.

When I am venting about a subject, I am not always looking for feedback or any action items to address the problems. I just want to articulate what is bothering me. The act of putting words to topics that are angering or frustrating me feels good. I think this is true for others because I have heard many people vent about issues to me also.

It is important to pick your audience when you are venting. It is very bad to vent to the wrong person. You might find your angry words come back to haunt you if you decide to “go off” and the person to whom you have vented is not a friend or confidante. I have had many of my subordinates vent to me over the years and I generally double check with them to see if they are just getting things off of their chest or if they need my help with them. I absolutely relate to someone if they tell me they are just venting.

I am not sure if there is a good or easy litmus test for how to pick someone you can trust to vent to. Sometimes it is a peer with whom you have been through a stressful work event, sometimes it is a good friend who you do not work with directly, or maybe it is a family member or a mentor.

If you are on the receiving end of someone venting, you should listen to them and empathize with their situation. I have caught myself a few times wanting to offer feedback or advice and I try to refrain unless I know that is what they are looking for. Sometimes someone just wants to be heard.

Another tendency to be careful about is to minimize their experience. It is easy to say “I had it worse” or “is that really your biggest first world problem today?” It is not always helpful to the person who is venting.

If someone is venting to you, it is important to realize it means they really trust you. You should listen to them intently and keep their frustrations in absolute confidence. You should talk to them about how you can help with these problems and they might tell you “I just needed to talk about it, I do not need any help.” You should absolutely respect their wishes in this regard. This is a hard one for me because I love to solve problems.

The longer you work professionally, the more likely you will develop a trusted relationship where you or someone else are capable of venting.

If your boss is venting to you, you should cherish that. You are getting a glimpse at what problems are like at the next level and it means that your boss trusts you.

I decided to write this because recently someone started venting to me. I appreciate when people decide to demonstrate that level of trust. It is a special moment.

If you are not in possession of a trusted friend or colleague, then please consider buying this obviously promoted and super expensive spiral bound venting journal from Amazon. Yes I am an Amazon Affiliate, and yes I found the most expensive product to shamelessly shill. This is also the first time the product I am suggesting to you is related to the topic—and probably the last. 

Unless, of course, you are moved to purchase said item by the mental imagery of writing down your angry thoughts coupled with the thrilling sensation of ripping that page from your journal, crumpling it up and setting it on fire (disclaimer: be responsible in your use of angry fire) as a means of solo ranty release: Behold my smooth words!

If this works you can take pleasure in the fact that you set me on the road to riches and greatness. Remind me later that you are the reason that I am successful and I will let you follow me on the Insta.

Hashtag Grateful

Hashtag SeeYouNextWeek

This past month was largely conversations directed at people who are doing some soul searching in their career. Does their employer value them sufficiently? Are there jobs that they are interested in? Do they have the tools to go find a new job?

In the process of having these conversations with some friends who were hiring managers, I talked about how important it is to value your great engineers.

My friend asked me the following question:

“What makes a great engineer?”

There are a lot of attributes I have seen in great engineers over the years. Many great engineers possess one or two of these attributes and some of them possess more. I do not know that I have met a great engineer who was excellent at all of these things.

Shipping software

First and foremost, the best of the great engineers I have worked with deliver software over the finish line. There comes a time in every project where you have a list of remaining issues and someone decides “we will ship this today.” Very few projects are perfect and even fewer are defect free. A great engineer will take software over the finish line and deliver it to production.

I have met some very capable engineers who can get a project to eighty or ninety percent, and then they require someone else to help them over the finish line. Shipping software is a key attribute of a great engineer.

Communicating ideas

Another attribute for a great engineer is the ability to communicate ideas. This can be both translating ideas into layman’s terms or it can be expressing the intent of a system so a more junior engineer can maintain it long after that engineer has left the company. I want to talk more about the latter than the former. We all make jokes about opening one of your projects from five years ago and having no idea what any of it means—and when I say five years, I mean five months. Great engineers will leave highly maintainable code in their wake with sufficient breadcrumbs and tombstones that someone can pick it up and maintain it without too many surprises showing up in production.

Recognizing patterns

Recognizing patterns is a very important attribute of a great engineer. I believe it is one of the most important skills to have as your engineering career goes into the world of Staff Engineer/Architect/Director of Engineering. If you can identify patterns of behavior of people and software, you will be able to create solutions you can apply to those patterns consistently over time.

Choosing software

This is probably the hardest attribute for an engineer to learn. Being able to make a pragmatic choice for a software language, platform, or software package is really important. Too many engineers attempt to apply new software to a problem. It is great to experiment and learn new tools. Sometimes production environments for large projects are not the place to do it. A great engineer will sit down and evaluate the requirements of a project and the capabilities or interests of their team before choosing software. It is dangerous to choose software in a vacuum. What percent of the team would be comfortable with that? Who in the organization will be strong enough to be subject matter experts in it? There are a lot of things required to make a decision on a language, development tool or software package. This is especially true for larger teams. If you are a software engineering leader and you mandate a big change in your software choices for the team, be aware that you will create delays, frustration, and employee churn. If you are a more junior software developer and you are bringing in new tools to a team, it is better to have an up front conversation with the team and team leadership about the pros and cons and include a prototype of some kind to demonstrate what the value will be.

Deleting code

You might expect me to say a great engineer writes lots of code. There is an even split for the most voluminous software writers I have worked with between “great engineer” and “I am firing this person”. I do not think there is a good correlation between volume of code created and greatness.

By contrast, I do think that great engineers are experts at removing code. Software engineering projects are complex beasts. Any time people can simplify software or reduce it in complexity is a good thing. Deleting code helps reduce noise in the codebase. This is very important for software systems that are mature. I have seen far too many people chasing down urgent defects and serious issues in large codebases where they have wound up wasting time in dead code. Great engineers help to reduce that distraction and inefficiency by cleaning up after themselves and other people.

“Software spider sense”

I wish I had a better name for this attribute of a great engineer. Great engineers have an uncanny ability to identify complex issues in software. I have run into my fair share of issues in production environments that defy the ability for teams to reproduce them and address them. I refer to hard-to-find-and-hard-to-fix issues as “Heisenbugs”. This is perhaps one of the rarest attributes of a great engineer. I can name less than a dozen people who I know who have a magical ability to “think like broken software” and work with a production environment to isolate and categorize symptoms that result in fixing or mitigating defects.

Comfortably uncomfortable

The last element of a great engineer is that they are very calm under pressure. This is an attribute that is the easiest to acquire through repetition and exposure. Dealing with production issues and urgent deadlines is stressful. It is also a crucible of fire. If it does not break you, it will forge you into a great engineer who will be able to step into a dire emergency situation without getting stressed or anxious and help you to focus other people’s energies and efforts to address the issue.

Thank you again for reading today. I make a living helping engineers unlock their greatness and I consider it to be pleasurable and rewarding. There are probably other attributes that great engineers possess—I may revisit this article in the future with an updated list. If you have worked with a great engineer and you think that I have missed one of the key things that makes them great, I would love to hear about it!

PS: Amazon.com suggests that this is a frequently repurchased item on their website, so I am attaching a shameless affiliate link that will result in generating revenues for yours truly if you click here and become the proud owner of a case of Orange Mango Recovery Water . I have now made more than one dollar as a professional Amazon Affiliate. Eventually I will unlock the magical powers of influencer marketing to turn this into a livelihood.

After last week’s article I gave a few people a courtesy review of their resume.

I am always happy to look at someone’s resume and give them some feedback. That is just as true this week as it was last week as it will be every week. Do not be shy. If you are reading this post, you are two to three clicks away from figuring out how to reach me via email or socials.

Unfortunately, most people do not like to click two or three times. That is why I am really crappy as a paid Amazon Affiliate—even when I pimp delicious unsweetened cherries. To make your lives easier, I am going to give a quick review of what I look for in a resume.

Is the resume reasonably sized?

I am not a fan of a ten page resume. There are times when it does make sense, if you are including speaking engagements, publications, patents, or significant experiences. I think of a resume like an Executive Summary—I want it to be short and concise. The ability to distill your professional experience down to a few pages is important to me. I expect one to two page resumes for people who are relatively early in their careers, three pages for most of their career, and maybe four pages if they have over fifteen years of experience.

Does the resume feel consistent?

The next thing I look for is the verb tenses for job descriptions and consistency across job descriptions.

I appreciate reading sentences that start in the past tense to describe accomplishments:

• Increased Revenue 15% through deployment of a new feature
• Developed a hiring pipeline to scale the engineering team
• Coordinated GDPR requirements with legal and platform team

I struggle when someone starts with this kind of formatting and in the next section of their work experience they swap to a different format:

• I built a new framework for cross platform mobile development
• I was responsible for three key releases for new titles.

I deliberately added a period to the second sentence as another form of inconsistency.

If possible, try to make sure your various job descriptions remain on the same page. I have seen far too many resumes that are three pages where the third page of the resume is just one line of text.

Does the resume include a mission statement or career goal?

This is not as important as other parts of the resume but I do love it when someone has a strategic career goal and can explain it to me.

You run the risk of someone reading your long term career goals and deciding that the role is not aligned with them. That is probably for the best, because that will become evident to everyone soon enough after you start the job anyway.

Are there specific successes or metrics included?

I like to see specific outcomes included in people’s career accomplishments. Did revenue increase by a percentage? Was there a decrease in site outages? Did the product ship on time or under budget? The more senior you are in your career, the more important this becomes.

Are there too many errors in the resume?

If you have too many typos or grammatical errors in your resume, I get nervous about the quality of work you will leave behind for someone else to maintain. I have a three-strikes policy with peoples’ resumes. If you have one error in your resume or possibly two, you might be sending out your resume under duress. If there are three or more things wrong with your resume, I become nervous about how to keep accurate documentation and accounting for your work output.

Is this person just a bad resume writer?

After I have finished going through a resume with my blowtorch and pliers, I take a step back and ask myself one last question: “Is this a solid employee who is just bad at writing resumes?”

If I believe this is true, I get pretty excited about interviewing this candidate. If they are a good worker who is bad at writing a resume, then they will get fewer interviews and I have a better shot at hiring them.

It is also something I can help fix. I am really happy when I can teach something really valuable to a potential employee.

How can you tell if someone is just a bad resume writer? That is really the million dollar question here. Unfortunately, I have yet to be able to articulate it well to other people. I am still working on describing patterns I see in a resume that indicate a really compelling candidate who simply needs to work on their resume writing skills. “I know it when I see it.” I would love to be able to explain it better.

You should take some time to give your resume a once-over. If you have a friend who has experience interviewing and hiring people, It would make sense to ask them to give your resume a once-over too.

If you have no friends, or none of your friends have experience interviewing and hiring people, then shoot me a note. I am happy to give it a once-over and ask the questions I have outlined above.

Thank you for reading along as usual. This post is not brought to you by the shameless profiteering of my Amazon Affiliate Link nor is it sponsored by my tool to help TTRPG DM’s improve the quality of their stories (derfdice.com). Raid: Shadow Legends has not driven a truck full of nickels over to my house and I am not getting an endorsement from the calorie-free smooth delicious taste of Diet Coke: Enjoy Coke! 

Maybe I should put half of my random ranting behind a paywall over at Substack? Information wants to be free, but John’s minivan also wants to be paid off.

See you all next week.

This is a follow-up post to git payed.

If you have just finished going through your end-of-year review and did not get what you felt was reasonable, now is the time to start considering your BATNA. If you don’t know what that means, please read the above post from last week.

If you want to get your hands on a BATNA, you are going to have to start applying to other jobs. The good news is that there are a lot of jobs out there. The bad news is that you are going to struggle to get one.

The problem is that the interview process is exhausting and filled with bureaucratic nonsense. If you are like most people, you probably have not interviewed in a long time, or have done it frequently enough to really do a good job at it. Maybe you have been in the same job for several years and your skill set is adjacent to modern technology stacks (meaning some of the machinery in the interview process is chewing up and spitting out your resume before anyone even sees it).

Depending on your skill set and your urgency to find a new role, you might be operating at a disadvantage. You should be honest with yourself about your position against other candidates and what you feel are your strengths and your weaknesses. On more than one occasion a few friends of mine have gone into an interview for their dream job and did not succeed in getting it. There are a variety of reasons for most of these and in at least one case the rejection was entirely preventable by some upfront coaching.

So what can you do to prepare yourself to interview for a job when you need a new one?

The best thing to do would be to interview for a job when you don’t need one.

If you see a really interesting job that is available, it might not hurt to reach out to one or two other companies, especially if you see a competitor is hiring, so you can get some practice at your interview. Especially if it is a company you REALLY want to work for. The practice will be worth it. If you get turned down from a company that you really want to work for, you might also realize that you conducted your interview differently from one of the other companies. I have seen a number of very enthusiastic candidates try to jump through hoops to get a job just a little too eagerly, or choke because they started overthinking things.

If you like sports metaphors, you can think about this like batting practice. The best hitters in baseball do not just show up one day and start slugging the ball out of the park. They are in the cages hitting the ball. They have people soft-tossing to them on the field. They are watching video footage of previous games. All of these things help them increase their performance when it matters.

If you think that is creepy or weird, I can respect that. I do think that if you arrange a few additional interviews you get a few things that are worthwhile. You may get a more competitive offer to increase your leverage in negotiating a salary. You may also get a sense for what tools or technologies are common today and what “state-of-the-art” looks like by talking to multiple companies. You will definitely get experience in managing the stress and negative energy that comes from being in a high-stakes interview where you are trying to demonstrate that you are worth being offered a pile of money.

These are not the most important things to me when I interview with a company. The most important thing for me is to understand their challenges and what kind of people I am going to be working with.

Quite often I am being recruited into leadership roles and generally will be meeting with peers, or potentially with staff members who will be joining my team. In many of these cases the first thing I want to do is to break the script and take control of the interview.

When interviewing with peers, most of them will not be in engineering roles. I break the script with them to understand what it is they are currently not getting out of their engineering team, or what they see as current problems. This helps me to relate their current problems to situations I have dealt with in the past and how I was effective at generating positive outcomes.

When being interviewed by technical people, half of the time you will be asked questions that you might not be able to solve. This is one of the biggest fears for most engineering candidates. If you are being interrogated by someone who knows something really well and you know almost nothing about it, your best bet is to just own it. I had at least one interviewer in the past ask me a question and I did not have a great answer. I took it as far as I could and then changed the subject to talk about an interesting project that I had just finished. It happened to be written in Golang, and I had some particular issues with using Golang in that capacity. The conversation resonated with the interviewer immediately. It sparked off an interesting discussion on language choices and how to make decisions on that level for various teams.

This is not a tactic that works well all of the time. I have found times when my attempts to take control of the conversation made people uncomfortable or irritated. I generally do not get upset when I get the “best of luck with whatever you do next because it is not working here” email. It honestly feels like I dodged a bullet.

I heartily recommend taking control of your interview, especially when the interview is being conducted poorly. If you are asking a potential VP of Engineering to get up on the whiteboard and solve your favorite brain teaser question, you might be doing the wrong thing. It is in your best interest to point that out. It might be the case they actually do not even want a VP of Engineering, but a very senior coder who will help put butts in seats if the next round gets closed. When this happens, many of these companies will proudly proclaim “we are a lean company”. Over the years I have learned “Lean company” generally means “poorly managed”. Most of the time they just expect everyone in the engineering organization to be spending half to three-quarters of their time writing code. That works great for ten people and not so great for one thousand.

If you spend enough time interviewing with different companies, you will develop a knack for figuring out what a company is actually trying to hire for. Sometimes they do not really know—they just know they need to hire someone to do something differently.

This probably does not work so well for you if you are interviewing for “Software Engineer I”. 

That is okay. Sort their linked list, answer their Big-O question, or just steeple your fingers and say “this is a great place to use MapReduce”. If they give you an obvious brain-teaser question, it might be worth saying that their process encourages cognitive bias towards a particular set of employees. Just move on when they ask you to leave the building. You did not want that job anyway.

Another benefit to some practice interviews is understanding if your resume is any good. If you applied to five or six jobs and no one responded, you might want to see if there is something wrong with your resume. A good resume should be able to get you an interview.

If you do not manage to get any interviews, you should ask someone who has some experience interviewing people to conduct a mock interview. There are lots of places that have practice interview questions (some companies will actually construct their list of questions from these books) and lots of people out there who can do a mock interview for you.

If you are struggling with your resume, feel free to reach out to me. I have looked at thousands of them and can generally give you some kind of actionable advice on what to do to improve yours.

Who knows? If your resume is solid enough, I might even recommend a company or two to check out, because I think there is a fit.

Thank you again for reading. You might have guessed I am very passionate about hiring and team building. I am also passionate about eating unsweetened dried cherries. This link may contain a referral code that will make me crazy rich if you all go buy these cherries. You don’t buy the books (which I have not read) nor will you buy the t-shirts (which I do not own). Maybe you will go buy a product I actually really like? I do not know how all of this works.

See you all next week.

Many software companies will go through a period of time when they institute a series of reorgs. There are generally two reasons for this. The first reason is that they are growing and they are shedding their old org structure because it needs to adapt to the increased size of the team. The other reason is that their org structure simply does not work.

There are many ways to think about doing a software reorg. Many people will talk about the need for product oriented organizations. Many other people will talk about the power of the matrix organization. Someone will invariably invoke Conway’s Law and before any final decisions are made another person will inject the notorious “Will this scale?” meme.

I have been in the middle of a number of software reorgs over my career. In the last few I noticed something very interesting.

It did not really matter what model was being applied to the eventual end product. Whether it was a matrixed organization, or one with teams dedicated to specific products or verticals, they all had one thing in common: The final organization matched the capacities of the team leads and managers.

Without much success, over the past few years I have attempted to explain this to people in the middle of their own reorgs.

Whether the reorg is happening top-down or bottom-up, there comes a time when someone has their favorite slideware open and they are attempting to put names into hierarchical boxes. There is a pool of unallocated leaders that gets assigned one-by-one like picking kids for your dodgeball team at recess.

About half to three quarters of the attempts to reorg a team will break down at this point because the chosen model results in too many unpicked managers/leaders, or they are too skewed towards one particular team or structure. I have stared at enough broken org charts at three o’clock in the morning to realize this is a recurring pattern.

Regardless of what model you choose to get those boxes filled in and all of your leadership allocated, you will always wind up going over each team and asking yourself a set of questions:

• Who is going to quit because of this structure?
• Who will need help supporting their team and/or products?
• Who will reap the most learning and career upside?
• Who will be unhappy about this?

There is some calculus that the management team will do in their head to determine churn, team satisfaction, and “what gaps will we need to manage through”.

At the end of that calculation there is an inherent “Yes, this will work” or “No, do it over” boolean response based on some unspoken feeling that one of those three variables is not within acceptable parameters.

If a reorg makes your team unhappy, or it causes your best people to leave, or leaves too many important things without an interim owner, then it does not matter what model you employed to get to that point. You will need to feed your homework to the dog and do it over.

I am going to call it out in the hopes that someone writes it down on Wikipedia someday for posterity. Heck, you can even call it “Szeder’s Law of Team Reorganization” and make me as famous as whoever the heck that Conway guy is.

“No team reorganization will succeed unless it takes into account the capabilities and satisfaction of the existing team”.

-John Szeder

I have run through this process enough times now that I sit down and start with the team allocations first. I try to pair up the most important people and the most important leaders with the most significant work. I make a list of people who will quit their jobs if given horrific assignments and attempt to assemble a working model that will make the fewest possible concessions to the team.

If the organization is big enough, then you might only be able to do this down to the director or team lead level. You might have a team big enough that you cannot go any further on your own. At that point it is worth it to engage your leads and conduct ranked team wish lists, a team draft, or something similar in order to construct viable models that make the most sense.

No reorg is perfect and you will generally have regrettable losses whenever you put up the final output of your efforts onto a screen in a company meeting. It is important to sit down and make sure you minimize those losses and successfully have an interim plan for any gaps that exist through a reorg.

If you do not do this then you will discover an unfortunate truth: If your reorg is not successful, you will have to do it again. Each successive reorg will have more churn and create more unhappiness, and suddenly you are trapped in a vicious cycle—reorgs all the way down.

One of two things will happen at that point. One option is that you will accidentally get it right, possibly through the team shrinking to the point that it is a much simpler problem. The other option is that you will have realized that your reorg approach is inherently flawed and will have applied a better filter to your reorg plans, managing to design one that takes into consideration the organization’s growth and retention based on the individuals in the organization themselves.

I hope you keep this in mind the next time you are staring at a list of employee names and an empty set of boxes in reorg-version-23.ppt at three o’clock in the morning.

If you do not, at the very least you are about to get really good at rolling out reorgs. Hashtag silver-lining.

Thank you for reading along! I hope you learned something valuable in today’s short post. If you did not, then why not buy this funny titled book (which I have viciously hidden under a short link, in an attempt to gaslight you for a click) that I randomly found on Amazon. Per Amazon’s Affiliate Policy: I must urgently warn you that I will enrich myself unfairly and gleefully indulge in shameless profit-taking should you click on this link and make a subsequent purchase. I hope to see you again next week for another random conversation on engineering and software product development!