Artisanal Concatenations of Sentient Emanations

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!

Hello and welcome to March! If you are presently working at a public company, you are probably getting your end-of-year review and corresponding financial bonus. It generally takes some time for these things to work their way through compensation committees, HR review, and planning. As you put your well-earned benjamins in the bank and mark your stock grants, this is an important time for reflection. Am I getting paid enough for this? If not, what is your BATNA?

Record scratch noise.

What is a BATNA? A BATNA is a Better Alternative To a Negotiated Agreement. That means “another job offer”. It could be inside your company, or from an entirely new employer. It is important for you to look at your total compensation package, your time at your current company, and the time you have spent in your current role holistically. If things do not add up to your satisfaction, maybe you should figure out if the market agrees with your assessment.

When figuring out the numbers, here are some important things to think about.

Do you like your boss?

If you like your boss and they are helping you move forward in your career, you should give that a high premium towards keeping your butt in your seat. It is important for both of those things to be true. I have met many people who loved their boss despite the fact their boss was essentially just sitting on them and preventing them from growing. It is hard to assess this personally—sometimes it helps to get a third-party perspective on this.

Do you like your team?

The more clever among you will notice that I am putting the people first in a conversation about numbers. This is on purpose. If you love the people you work with, you should really hold onto that!

Do you like your work?

Once you have established how much you like the people, you should evaluate how much you like your work. Are you doing enough interesting things day-to-day? Are you getting to learn new things? If neither of those are true, then you should consider what you want to do professionally for the next five years and maybe contemplate a change.

Have you been in your current role for too long?

Many software engineers in the bay area are experiencing title inflation as a cheap retention tool. A Senior Software Engineer in Menlo Park means something different now compared to six or seven years ago. Most employees really like a clear and fancy title. When you get to Staff Engineer and Principal Engineer levels, this process slows down. You can expect substantive level ups to happen every three to five years, assuming you are keeping pace with your career progression. If you talk to your manager and they are not conducting a “gap analysis” with you on what it takes to get to the next level professionally, you might want to consider exploring an alternative role.

Have you been at your current company for too long?

If you have been at the same employer for many years, you might develop some fear or anxiety around interviewing elsewhere. Let’s face it—interviewing sucks. Most companies are bad at recruiting and the people conducting interviews are often worse. It is a painful process and people hate it. Interviewing elsewhere every once in a while is a great way to practice being uncomfortable as well as understanding what the marketplace looks like for skills, tools, and processes. If you are using five-year-old tools at your current company, it might be harder for you to interview for a new role elsewhere. It is good to know what people are looking for even if you are happy with your job—you never know when you might have that choice taken out of your hands.

Have you been at your current company long enough?

This is another one that I think is very important. I recommend that you spend two or more years in your current job or role if you can. I suffered from itchy feet early on in my career and I would often bounce shortly around the one year mark for various reasons. If you really need to change your role after one year, you have made a significant mistake of some kind and you should think really hard about it.

Are you getting compensated well enough in base pay?

People talk about their compensation more and more now. I think this is great. It is good for you to know what you are worth. FAANG, or whatever that acronym changes to with company names changing, have a tendency to compensate people very highly to get them in the door and keep them for two years. Use this to your advantage as a tool to price your talents, and make sure you are getting paid. If you are going to a startup, make sure you are getting sufficient equity to cover the “opportunity cost”.

Are you getting compensated well enough in equity?

This is the part of the equation that most people ignore. If you are at a public company, your equity is generally stock grants or restricted stock units. This is a cheap way to compensate you for your efforts. Most of these come in four year grants and have one year cliffs.

If you are in the third year of your grant and you are not getting re-upped for stock, then you are experiencing a pay cut—even if they come close to matching it in cash via a cash bonus for a year. If you are not getting a decent drip feed of equity, you are not getting to participate in the company’s upside and it also probably means there is someone else in your organization that received some that you did not. If other people are receiving strategic awards from your leadership, that usually tells you something.

Those are some questions you should ask yourself about your current job and your current compensation. I am not going to open up Google documents and make you a pretty, pretty flowchart. It is important to note that this is the best moment to make sure you are getting paid what you are worth. If you are not getting compensated well in stock, or not getting much of a bonus, your boss is gambling that they have a year to make it better somehow—if they want to make it better at all. If that is the case you might want to vote with your feet.

I have seen a few people defer conversations on changing roles or changing careers due to their end of year bonus—the math is not hard. Now that moment has arrived, it is time to take a long, hard look in the mirror and ask yourself what your goals are for the next few years, and maybe now is the time to entertain a BATNA.

If you are having trouble figuring out what you should do, by all means reach out. I have made this decision, both well and poorly, many times over the course of my career. I can share my experiences and perspective. It might also be the case that I can make an introduction to someone who is hiring, who might value your work and creativity more than your current boss does.

What do you have to lose?

I apologize for the lack of content. I am recovering from being afflicted with an ailment.

No I did not get the covid.

See you next week!