Artisanal Concatenations of Sentient Emanations

Happy Sunday. This week I will continue my incredible, two-week streak of not writing about quiet quitting. I feel like I want to put up one of those signs: “It has been 14 days since we have written about quiet quitting.” I am so proud of myself. This week’s article is unofficially brought to you by ASUS Monitors, linked here shamelessly with my Amazon Affiliate code. If you need a reasonably priced WQHD monitor with a decent refresh rate, choose ASUS. ASUS!

Maybe someday I will have some kind of official sponsor for my blog. If you are interested and want to send me a free T-shirt to wear as I write my thinky thoughts, I am open to that. I might even take a picture of it and share it with everyone. Is this how one gets huge on Only Fans? Okay, okay maybe that is too far. I will slow down.

Let’s talk about one-on-one meetings.

I have a little speech I give to a new team member when they join a team I am managing. I tell them that it is important for their success to have a half hour of my time each week in order to ask questions or raise concerns. I like to tell them that it is their meeting, and if they wanted to spend that time reading their own poetry, or doing karaoke together, then that is what we will do. To be clear, I have not had a lot of takers on poetry readings or karaoke, but people like to know the option is there. It is their meeting.

A one-on-one meeting is an important meeting for many reasons. It is an excellent early warning system in case one of your team is becoming disconnected. It is a great way to ensure your team has everything they need to be happy and successful, and also it is a great venue to make sure that you are conveying important messaging.

Early warning

One of your roles as a leader is to keep your team together and reduce churn. Your one-on-one is a great place to get a heads up that someone is about to depart the organization. In at least one specific case, one of my direct reports told me flat out they were going to resign. They explained why, and I agreed that it made sense. Other times, you can get a sense of people’s satisfaction or stress from how they are talking about their work. You might also observe that people are more “checked out” in their one-on-ones. This is another indicator that someone is unhappy with their role.

I find that people will ask to cancel or defer their one-on-ones under two situations. They will cancel their weekly one-on-one if they do not have any concerns or issues to discuss, and would rather spend that time being productive. This is generally a good thing. As a rule of thumb, it is wise to keep at least one monthly one-on-one just to catch up, even if there is nothing to talk about.

They will also cancel their weekly one-on-one if they have one or more feet out the door.

Clearly one of these is not a good thing. The trick is to figure out which is which.

Happy and successful

Another important part of your one-on-one meeting is ensuring that they are happy with their work and being successful. These are important in equal measure. If someone is happy with their work and not successful, then that requires some work to determine how to make them successful. If they are not happy and they are successful, then there will be a different kind of work needed. I am not necessarily convinced that every person on your team has to be “tattoo-it-to-face” passionate about their everyday job, but they should at least be happy with it. This might mean they are happy with the compensation, they are happy with the team, or happy with what they are learning from their role—Maybe it is all three!

Important messaging

The final part of a one-on-one meeting is to ensure that everyone on the team understands where they are going. This includes career goals, team goals, and company goals. One of the biggest challenges for most leaders is making sure everyone is aware of the overall direction for the company and for their particular organization. You can hold frequent all-hands meetings, write weekly newsletters and even have people memorize and repeat parts of the company mission statement to help make sure they understand the direction they are headed. Sometimes this is not enough. Sometimes you will need to sit down with people and repeat the creed personally to them and give a personalized version of it to help make sure they are getting the message effectively.

There are probably a half a dozen more reasons to hold regular one-on-ones with your team members, and these are just three of the more important ones to me.

Here are some additional things you can do to have effective one-on-ones.

Do not schedule one-on-ones back-to-back. Try to give a 15 to 30 minute buffer after a one-on-one meeting in case it goes long. Rushing to complete a one-on-one meeting can leave a team member feeling frustrated and unheard.

Have the employee schedule it. It is their meeting. After the two of you agree on the time, they should add it to your calendar for a couple of reasons—the first of which is that it helps them psychologically own the meeting. It also helps me to prepare future leaders because I can learn how comfortable they are with managing their calendar.

Keep a shared document where the team member controls the agenda. Add weekly notes to it, and make sure to track action items and follow ups where necessary.

Never cancel a one-on-one with your team member. If you need the time for something else, then ask them for a replacement time slot to reschedule it.

Thank you for reading along today! Please let me know what additional things you like to see in a one-on-one meeting. If you have some cool pointers for effective one-on-one meetings, we would love to see those too.

Looking forward to continuing the conversation next week where I will not shill three hundred dollar affiliate merchandise. I will also continue to not talk about quiet quitting.

The last two weeks I took a break from ranting about engineering management topics to talk about Minecraft and World of Warcraft. I apologize if you were uninterested in my foaming-at-the-mouth word spray. Fistbumps for the rest of you!

I really want to write an article about the whole Quiet Quitter phenomenon. I am fascinated by it to say the least. I started my career deep in the throes of the dotcom “revolution”, and I was snorting nosefuls of meritocracy powder and flexing boldly every day. There is at least one of you reading this right now with an energy enhancing product in one hand, reaching for some kind of hustle culture totem to ward off the mean man’s words in the other.

Good news! I am not going to make today’s rant about that.

Today I am going to talk about one of the few things I miss about being in the office.

I miss taking people on a walking one-on-one.

I was surprised how much I like having one-on-one meetings with people. There is a good mix of learning and teaching happening at the same time if you do them well. Today we are not going to talk about your standard one-on-ones.

In 2003 I was blessed with several coworkers who enjoyed going out for midday walks. We would cover a lot of ground in these walks, both physically and mentally. It was the first time I held a leadership role at the director level, and I struggled with some aspects of it.

To say that these walks were helpful and therapeutic were an understatement. I do not know that I gave the people on my team enough thanks for getting me started on the habit.

There is just something really special about a long, meaningful conversation while walking around. Something something health benefits, amirite? Setting those aside, the breadth and depth of the conversation changes when you get outside the formal meeting room environment and just talk to people.

I am sure there is more scientific mumbo jumbo out there to back up why this is important. I would search out a good book on Amazon and link it here for you, but you and I both know that you wouldn’t click on it. Jeff Bezos is almost as disappointed as I am.

All I will say is that while I am the President of the Work From Home fanclub, and have been hard at it for many more years than most people, this is one of the things I miss.

If you are back in the office and want to do something different for one of your next one-on-one meetings, I heartily recommend suggesting going outside for a nice afternoon walk.

Thanks for reading along. This is a little short today. I am back from a week of travel with the family and it is hard to write thinky thoughts on the heels of hours of sitting in a minivan with a large assortment of children. We will return next week with more SrS BzNz posts. I do not think any of them will be about Quiet Quitting either.

I have one more mister gamey gamerpants post to make this week before we get back to the land of engineering and education. I appreciate your patience. I am still at zero dollars trying to get you to read books that I have not yet read, and I suppose shame is not a powerful marketing tool. I guess I shall keep working for a living.

We finished migrating all of our family Minecraft accounts from Mojang to Microsoft this year. As a result, I now have Minecraft goodness on many different devices. Since it is almost as good a game as Terraria, and is much much shallower, I decided earlier this year to start a clean world and go through to Win The Game by killing the Ender Dragon. I used to do this all the time on classic minecraft.

How hard could this possibly be?

To begin with, there are now two flavors of Minecraft: Java Edition and Bedrock Edition. I decided to play Bedrock Edition. I started my world, ripped up some trees with my bare hands and started building Chateau de Szeder, as one would normally do.

The first thing I learned is that the bottom of the world is no longer zero. You do not dig down to level 13 to 16 anymore in order to load up on lucrative diamonds—You Must Dig Deeper!

The new world goes to -64, and the bottom of the earth is filled with a new type of rock that is harder to mine. Finding diamonds is now harder and slower.

You might see where this is going.

Once you get enough diamond to make a diamond pickaxe and mine some obsidian, the next step is to get into the Nether and find a Nether Fortress. Nether Fortresses have two things that are important. You will find blazes in Nether Fortresses that drop blaze rods. These are needed to create Ender eyes and win the game. You will also find nether wart. Nether wart is needed to make potions. These are not strictly necessary to win the game, but they sure do help.

Exploring the Nether is frustrating. It is filled with lava and a number of creatures that are frustrating to fight. I spent the next two months intermittently running around and making tunnels and bridges, trying to find a Nether Fortress without much luck. The big problem is that while the spawn rate for Nether Fortresses within specific Nether biomes has not changed, they added a number of new biomes that made finding a Nether Fortress harder.

I decided to do a little reading online to learn that the recommended solution is to get a saddle, either from a chest or by purchasing one from a leather worker in a town. I was not able to find a saddle in any chests, and none of the nearby towns to my starting zone had a leather worker.

I was reasonably frustrated and decided to start over.

This time I prioritized finding a leather worker before going to the Nether. Fortunately, the third town near my starting point had a leather worker. You have to level up the NPC leather worker through tedious, mundane trading in order to get them to a skill level needed to create a saddle. While I was going through the process of killing rabbits and dodging polar bears, I wondered why they did not simply let you craft a saddle, like every other item in the game.

After getting set up with a saddle, I finally proceeded to enter the Nether and start traveling around on the surface of the lava on a lava strider. It did not take me long to find a Nether Fortress. I was able to farm blaze rods in order to create the Ender Eyes needed to open the final portal. I did need to explore around the lava quite a bit more this time around in order to find another structure that contained Nether Wart.

At this point I made a time consuming mistake. Rather than going back to the origin of the world, I decided to use the Ender Eyes near a portal that could take me right back to the Nether Fortress. This is a bad idea because the final portals to the End spawn according to a radial pattern, and it took me a few days to triangulate the location of the End portal. I should have backtracked to my starting point, because they generally drop one at a reasonable distance from the starting coordinates. I built a road to the portal when I finally found it. It was roughly 10,000 units away from where I started looking. This is about 30 minutes of running which is more than an entire Minecraft day.

The portal itself was under water (of course) and required some significant excavation work to reach successfully.

At this point I was able to enter the End level and confront the Ender Dragon. There was one final frustration. The Endermen in the End level are much more aggressive than in other zones. Not only do you have to deal with a giant dragon flying around and regenerating until you smash its multiple regeneration orbs atop large pillars, you will also have 2-3 random angry Endermen trying to crack your skull open.

There was really only one good way to handle this: I decided to death-run the pillars with stacks of sand. 

If you carve a pumpkin into a jack o’lantern, you can stick it on your head and then you will not aggro any of the Endermen.

So I spent about an hour and a half making giant stacks of sand, running around the final level of the game wearing no armor except for a pumpkin on my head. All I could think about as I died around twenty times, trying to destroy the glowing orbs on top of the pillars in the End, was “I am going to have to write a post about running around the End level wearing nothing but a pumpkin on my head, aren’t I”?

I was able to beat the game shortly after, but it was a time consumed, friction-filled process. It was nowhere near as pleasurable as it used to be.

For a new player, the expanded biomes and new mechanics may be fun. If you ever played through the original Minecraft, it was easy and frictionless to get to the end, possibly too easy.

For me these changes do not make the game better.

I do think that the Minecraft team is headed in the right direction by adding updates. I think that the one thing they are doing wrong is making significant changes to existing zones, creatures, and biomes.

I think that Minecraft would be twice as successful as it is today, or more, if they decided instead to leverage the portal model. Put new creatures, new rules and new biomes into new worlds that are gated by portals. Instead of having all of these friction filled changes threaded into the existing worlds, add a new portal recipe that is usable in the End to create a new gate to a world that contains these biomes. The dopamine fix you get from “first night syndrome” in Minecraft is i n t e n s e. If they released a new set of worlds with a new set of biomes every six or nine months they would be able to dramatically increase the value of the franchise.

Thank you again for reading along! I hope you derived some mirth from my four months of Minecraftian struggles. It was a valuable experience for me even if I think that the game sucks more than it used to. I promise to return to engineering leadership conversations again soon. I have at least a month of new material from conversations in the past few weeks. These past two posts on World of Warcraft and Minecraft have been therapeutic. You know what else would be therapeutic for me? Getting some free nickels from Amazon for an Affiliate purchase. You cannot go wrong with Ben Rigg’s interesting book on Dungeons and Dragons!

My efforts to become a professional Amazon Affiliate continue to be met with zero success. There was not even one pity purchase from the list of books that I have not read. You are a tough crowd.

In today’s random internet musings I want to talk about World of Warcraft.

I love this game and I hate this game. It is only an MMO in the same sense that the automobile is a carriage. Both convey people and cargo, and both are measured in horsepower. I do not consider WoW to be an MMO so much as it is an MMO killer.

For anyone that wants to step up and play the semantics war, just remember that everyone who logs in and plays the story is “The Champion”, and even though there are 10 to 30 of you, only one of you gets the kudos in the cinematic for killing the Jailer at the end of the tier. In essence, playing WoW together is kind of like a bunch of two to three year olds playing. You are not playing with each other, you are playing near each other. You are vaguely aware of other people’s presence, but not really doing anything clever in that interaction.

This burns my fucking soul.

There are lots of things to like about World of Warcraft. There are lots of people who are famous on the YouTubes for this even if they occasionally talk about the warts and the small scars that riddle the game. Something something borrowed power amirite?

The deep truth is that the game has done such a good job of utterly destroying most of the competition that in order to grow they have decided to feast upon the echoes of their past by launching previous expansions as standalone games to recapture nostalgia dollars. Kudos to them for erecting a gigantic moat around their hundreds of millions of dollars of investment into the technology to power their audience.

I am not writing this to gripe about borrowed power, or the fact that “bring the player not the class” only goes up to the point that you do not have warlock soulstones or a heroism in the raid. The latter, at least, can come from three classes. You need very specific buffs that give you benefits that require at least one of a handful of classes. As someone who recruits for my raid team, it is a pain in the ass. Also: Where the hell are you, all you late night warlocks?

I think WoW actually started off as an MMO. You could earn cool things that were exclusive and time limited. I recall the awe of seeing people who timed Zul’aman for their mounts, and seeing someone with a Scarab Lord title wandering around. I soared around Dalaran on my 310 speed achievement protodrake and also spent one month flying around my server as the first person to get the 25-man 3 drake mount from Sartharion.

Then came the day that the first raft of players completed the 365 days of holiday achievements for their purple proto drake.

I logged in that day without realizing what was happening until I set foot on the Dalaran landing pad. There were no less than five people who were glitching their mounts to fly upside down and backwards, giggling and emoting to their heart’s content.

This was the day that I realized that I was no longer the target market of the game and that their focus had shifted. In order to get a 310 speed mount prior to that moment there was a tremendous amount of work and coordination to achieve something magnificent via raiding or player vs player battles.

Now, all you needed to do was to click on a pile of random buttons during all the major holiday events. The fancy mounts reserved for the players who did amazing feats in the game suddenly were joined by a new crop of people: People who could login consistently and click some buttons.

It is interesting to see how each WoW expansion mirrors something happening in other games. The farms of Pandaria were reflections of Farmville and social games. The garrisons were bizarro universe replicas of Dungeon Village. The pet battles were essentially Pokemon fighting games. Even now people make comparisons to Path of Exile and Final Fantasy IXIVVI or whatever number it is up to.

I really enjoy raiding with my guild in WoW. I enjoy the aesthetic of the game and how they have opened up their UI for players to configure and tailor. I admire their on-ramp for new players, and how it gently takes you from “kill 10 bears” to raid readiness. Very few games take you to elder play so seamlessly. 

There are many things this game has done in order to wrap thick coils of rope around the neck of the MMO category and strangle the life out of it while staring deeply into its eyes to watch it die.

In 1998 I drafted some interesting game designs for an MMO I wanted to build with overlapping social structures built around competing social dynamics for groups at various sizes. The design called for groupings for families, cities, nations, and religions. Each of these groups has its own goals and sometimes they would be in conflict. The interesting decisions of the game would be for the player to decide how they wanted to align their actions while they played.

Here we are decades later and we are no closer to MMO 2.0 than we were when people made Barrens Chat into a thing. Innovation in MMOs became animation styles for question marks over NPC heads and how to manage instance loot drops with as little drama as possible.

MMOs and social games, to me, should be more about creating reciprocity loops and players managing internal conflict.

I still sit on two interesting design ideas that I would love to experience as a player someday. In the late 1990s during Halloween I was inspired by the monster portals in UO to want to play a game with zero AI critters or monsters. The entire game creature population would be a managed economy that has a stock market for people to trade up their monster types based on earning points for playing roles needed for the game to thrive.

The other design idea is the social mechanic above.

Are there games that have flavors of these out there? Sure. I would love some recommendations for games to examine if you feel they have flavors of these. 

I am skeptical we will see successes from ideas like this at scale and that means it is going to be hard to find 20 (or 50?) million dollars to crank out one of these games any time soon.

You might argue that there are platforms out there that give you the ability to implement games like this. Sure. There are. At least four or five people are going to become billionaires off of laying the plumbing so there is more opportunity to create cool, emergent game designs.

These platforms are real and will solve this problem soon. I do not dabble in any of these platforms until it is clear that I can get enough of a pile of cheddar out of it on the way up to pay my Californian-head-of-household bills. I doubt we will see any of that changing any time soon since they are still figuring out their product-market-fit, plus we are in “the difficult times”.

In the meantime, I could use a late night warlock or two if you want to come play WoW with me. I fully intend to enjoy my time inside the monster that is killing the genre that inspired me to become a professional game developer. Eventually WoW will feel a tap on its shoulder and turn to see a grinning competitor staring intently as the loops of rope settle into place.

Thank you for reading along. This is a little angrier and a little darker than normal. If you want to see less of this then go search for last week’s post and buy one of the books I linked. If that does not happen then you can expect a few more game design rants in the coming months. See you soon!

I sometimes visit the Amazon Affiliate Reports page when I need a chuckle, and I was surprised to see a non zero dollar amount there. I am shocked and humbled in equal measure. Thank you for sending me some of Jeff Bezos’s nickels.

I am going to ramp it up this week by Actually Promoting Things I Have Purchased That You Might Want To Purchase Too! Disclaimer: This list is all linked to my Amazon Affiliate Code because I am drunk with the dizzying power of all those free nickels.

Without further ado, I hereby present:

The top eleven books that I have purchased and have not yet had time to read!

(number five will totally shock you)

Solomon Gursky Was Here by Mordecai Richler – This book was recommended to me by a leader I work with because it is a great book… and I am painfully Canadian.

Algorithms to Live By by Brian Christian and Tom Griffiths – This book was recommended to me during a meeting when we were discussing how to manage people and discussing mentoring. I am certain that more than one person has recommended this book to me now that I think about it some more.

Aging Backwards by Miranda Esmonde-White – I do not remember who recommended this book. 

Disunited Nations by Peter Zeihan – This book was recommended by a friend on Facebook.  

Slaying the Dragon by Ben Riggs – I purchased this book because Ben Riggs shared some fascinating sales statistics on old TSR™ products and I wish to reward this kind of awesome transparency with nickels and eyeballs.  

Elements of Game Design by Robert Zubek – Robert Zubek is a Zynga alumnus and is someone I know. If you wrote one or more books and you are my friend, I will buy at least one of your books and creep on you for a signature eventually. 

The Power of Kindness by Piero Ferrucci – This book was recommended to me by someone I met on LunchClub.ai   

The Story Factor by Annette Simmons – This book was recommended by a product marketing leader that I cannot afford to hire to help me with my https://derfdice.com product.

Semantic Software Design by Eben Hewitt – This book was recommended to me by a mentee that worked with me at Zynga.  

Mulligan Stew written by Gilbert Sorrentino – This book was recommended to me by someone I work with—the same person who recommended the Solomon Gursky book above. 

An Elegant Puzzle – Systems of Engineering Management written by Will Larson – This book was recommended to me by someone I am mentoring.  

I am woefully behind on my reading this year, and I need to get caught up. It might be hard to spot, but there is a common thread to almost all of these recommendations—they all came from conversations with really smart people. I hope that one of you feels inspired to buy and read one of these books, and not just because I am squeezing nickels out of you in the process, but that you learn something interesting and exciting.

If you do not wish to read and/or learn, then I will present you with an alternative. Please enjoy this extremely expensive children’s indoor playset where you can roll around safely and mirthfully for hours without learning anything interesting. See you next week! 

I am presently mentoring people at three different career levels: Lead/Manager, Director, and Vice President. There are new skills and habits that you need to learn in order to be effective at each of them. As you progress professionally it is important to be able to teach these skills, and to teach people to teach these skills. That is subtle but important.

In addition to teaching your direct reports, it is also important to provide the right amount of teaching and mentoring to your indirect reports too. This is tricky because you want to give enough space for your managers and directors to be effective as well as making an impact on multiple levels of the organization.

It is a good idea to get to know as many of your indirect reports as you can. There is this notion of the Dunbar Number that is worth knowing here—the suggested cognitive limit to the number of people with whom one can maintain stable social relationships. If you have a high Dunbar Number, it certainly helps you to maintain the right amount of contact with everyone in your organization. The real question is: How many of them should you be mentoring and advising in addition to your own direct reports?

The correct answer is not zero and it is not one hundred percent. If you are mentoring and advising one hundred percent of your organization, you have too much time on your hands or your organization is too small.

Over the years I have concluded that there are three groups of indirect employees you should be investing time in understanding: Your top performers, your struggling performers, and the named successors for your direct reports.

Having a named successor is important. I try to identify the most likely person on every team I run to replace me if I get struck by space debris. I also encourage managers to identify their successor too. Investing time in training and mentoring your organizer’s named successors is a great tool for helping to grow your team and to retain them. I highly recommend it. Whether or not you explicitly tell the named successor that they are a named successor is entirely up to the manager in question. Some people take it well and use it as a learning tool, while other people might wield it as a cudgel on the rest of the team. If you see the latter activity happening, you definitely know that you have some work ahead of you to address that issue. I like to make sure I am spending enough time with named successors for the organization to help give them visibility into problems they will encounter at the next level, and to build a communication channel for them to ask questions and give feedback.

Investing time in mentoring your top performers is also very important. This is an excellent retention tool for your team’s best people, and it is one of those intangible benefits that they will need to balance against “shiny new title” or “three new flavors of sparkling water!” with a BATNA (BATNA is an acronym for “Google it”) at NewCo. I have also found that building relationships with star performers at one company has led to some great lifelong friendships, and I have been blessed to work with them again at other companies!

Finally, it is important to develop relationships with your struggling performers. Managing the bottom of your team and trying to lift them up is hard. It is also very important. Sometimes their direct managers might not have the experience or vision to figure out how to unlock their potential. By investing time in understanding the team members who need the most help to be successful, you might find that they have team fit or skillset issues that prevent them from doing their best work. It is worth investigating how you can help these folks serve the organization better, and as the manager-of-managers you might have more ability to move them elsewhere to see if you can find a more suitable role.

In summary I heartily recommend finding the right level of interaction for you and your indirect reports. For your organization’s best performers and future leaders, having your indirect managers investing time is a great way to accelerate their success and make sure they are really engaged with their work and current team.

Thank you again for reading! I still do not have a sponsorship from Raid Shadow Legends, nor an endorsement from 5 Hour Energy Drink. I will keep trying to get those endorsements. At a bare minimum, if you have derived no value from this article, or any of the deranged scribblings on this site, allow me to encourage you to purchase this Amazon Affiliate Linked Book to help you understand your part in all of this.

There are terms for pluralities of various things: A gaggle of geese, murder of crows, et cetera. I am trying to figure out the right term for one of these myself. I narrowed it down to two so far, and I could use your help in deciding. Is it “an excessance of Twitter engineering leadership opinions” or a “bullshittery of Twitter engineering leadership opinions”? I cannot decide. You might see where we are going today.

There are so many people giving their popular prognostications on the notion of engineering ladders that it makes my head hurt. I will not link them—they have thousands upon thousands of followers already. Everyone has their own flavor of whether or not you should consider jumping from the IC track to the Management track, and almost all of them are completely wrong. I am here to give you my own flavor of wrongness on the subject.

I think it is important for every engineer’s long term growth to contemplate a role in engineering management and for some subset of those people it is important to attempt it. There is no one-hundred-percent-all-of-the-time rule for each person, or even for each company, as to when this makes sense and when it doesn’t. The sheer number of people who are online making an argument that sticking to the IC track or jumping to the Management track seem to ignore one fundamental thing: The individual themselves. I have met engineers who are very far away from leading or managing, and I have met engineers who need to be fast-tracked into one of those roles due to exceptional ability.

For the individuals who are very far away from the ability or desire to manage, I think it is worthwhile conversation to have. You may not have the interest in managing people or the ability to manage people. I think that a lot of people fixate on the latter. If you are great at writing code, there is a blanket generalization that you must not be great at managing people. I have met people who possess both skill sets, and they are incredible assets to your team. The big question is: If you are a great coder, how do you become a great people manager?

This is the biggest part of the problem. When you give an engineer a battlefield promotion into a management role, they often get very uncomfortable because the skills they used yesterday to be successful are very different from the skills they now need today.

I have helped people through this transition in the past, and it starts out with about six weeks of pep-talks and ad hoc meetings where we describe the challenges of the new role they will experience and what they need to learn. I have turned this into a formal list a few times for a few different employers. You will find various snippets of that buried in various portions of this very blog.

If you are going to transition someone from an IC role into a manager role with the goal of getting leverage, it is important to make sure they have proper support and training to be effective in that role. This is one of the largest reasons that many people do not make the transition successfully.

When I have transitioned people into a management role for the first time, I generally give them three to six months to decide whether or not they want to keep the role. This is very important. It gives people some amount of comfort to know they have a way back to a comfortable place if things get too far out of control. If you do not have a conversation about how to move forward if someone does not want to be a manager or is not successful at it, they will just go find their old job at a new company.

Between creating a comfortable space for a new manager and also giving them some coaching and mentoring on how to be successful at it, I believe that every talented engineer is capable of being a talented manager.

Let’s get to the spicier part of the conversation and talk about compensation. The other thing that makes me twitchy is the blanket generalizations about which path gives better compensation and career opportunities. This is so completely dependent on the company that everyone’s generalizations about this make my brain bleed.

All companies value management, leadership, and individual contributors differently. Some will have similar bands for compensation, and some will even have nearly identical titles. Some of this has occurred because of fast-following for recruiting purposes, and some of this has occurred because of the changing needs of the organization.

Regardless of which path you take, the opportunities to progress professionally get smaller the farther up the stack you go.

Many organizations have “Staff Engineer” or “Engineering Fellow” roles. These are preserved for the very best of the best. It is hard to get recruited into one of these roles directly. Most companies like to award these prestigious roles for heroic feats or accomplishing specific goals that impact the whole company. Some companies hand them out based on time-in-role in addition to specific milestones. The time-in-role requirements for these types of roles are measured in years, if not half-decades. While there is a need to create these roles to retain your most senior engineers, once a group like this springs into existence, one of the first things they do is institute gate-keeping processes so they can control the membership. There are a number of people who I have spoken with who have wanted to join one of these internal engineering upper echelons who were not able to do so, often for utterly banal reasons. Nobody likes to talk about the ratios of top tier engineers to lower tier engineers within their own organization because it might highlight some of the hidden gatekeeping by people who love their own scarcity.

Now that we have explored some amount of issues related to engineering promotions, let’s cheerfully return to our initial question: If it is dependent upon the individual and their abilities and their desires, as well as the companies and their internal structure, the question I would ask most engineers is this:

Why limit your options?

If there is a company with an urgent need to hire a vice president of engineering who can grow their plucky 20 person team to 200 people, that is often just as valuable as being the chief architect who can scale their output to 20 million customers.

It is not in your best interest to listen to a glorified 10x engineer to say that his ladder is the best ladder. It is clearly true for that person, and the companies they have worked for. Congratulations on your single point of data. Okay that is not fair. Congratulations on the six points of data from you and the people in your scotch/book/co-investing club.

It is in your best interest to maximize your skillset and see what you are capable of accomplishing. There are individuals and companies out there who will help you get there from where you are now. If your current employer is not one of them, then maybe that is one of the first things you should change.

Time to insert my personal sales pitch here.

I have switched a few times between management and IC roles over the course of my career. Most of said career has been shaped by responding to SOS calls from people I trust and admire. I am grateful that the last decade or so has been mostly working with previous coworkers who know I will come in and catch anvils for them.

Rather than listening to a bunch of tweetholes about what you should not be doing, I would love to have a conversation with you about what you are capable of doing. I have helped a considerable number of people on my teams in the past grow into new roles. Some of them have even surpassed me!

So give me a shout if you want to talk about where you want to go professionally, especially if you are not sure how to get there.

Alternatively, you can click the “Like” button on someone telling you that you shouldn’t bother. Some of them make tremendous amounts of dead presidents with their negative armchair prognostications. If you are in this bunch of sheeple and you simply do not care about opening new career doors and growing your own capabilities, I only ask that before you leave you click on this link to this overpriced hammer that I am giving to you as an Amazon Associate, so I too may profit from your random clicking. You get a very nice hammer and some percentage of proceeds go to veterans and first responder causes. In fact, if ten of you buy this hammer out of spite for my gaslighting, I will also buy one.

One of the interesting challenges about software development is how non-linear the work can be.

Sometimes you can rathole on a problem for hours or days only to find you have chased a dead end, or even worse, discovered that work you have already done is suddenly useless.

Welcome to the world of negative work.

Negative work is one of the most frustrating parts of software development. We talked previously about the importance of planning your work, as if you were building a bridge.

Preventing negative work is really hard. Most of the time it is due to incorrect assumptions which may also include random things like language constraints or possibly even deployment security issues.

I do not have many silver bullets for preventing negative work—sometimes it just happens. The most I can do is to counsel patience when you discover it and try to understand how you got to where you are. If you are lucky, it is something you can add to your leadership playbook as a preventative tool in the future.

The most important thought I have about negative work is to realize when you have avoided it. There have been times when I was making software that I narrowly dodged negative work, but actually did not accomplish meaningful forward progress. While it is frustrating to have zero forward momentum, it is nice to avoid creating an engineering deficit.

Sometimes the best you can do in those situations is to share this discovery with your team and then say “Hey we did not move forward, but at least we did not do negative work!”

I am going to give the salty signoff a pass today with the hopes you spend some time examining the times you have created negative work, or narrowly avoided it. The better you are at identifying it and preventing it, the more effective you will be as an engineering leader in your career.

I cringe every time I hear someone say “Software Engineer”. Some of this has to do with growing up in Canada where there is actually a “Professional Engineer” organization, and some of this has to do with the way that people view the profession itself. There are some odd parallels that people associate between building software systems and building bridges that I think have warped people’s expectations. Be prepared to have this metaphor taken to extremes today.

Estimating project size and scope is one of the most daunting problems that happens as a result of lumping software developers into the engineering bucket. After all, if it took you six months to build the last bridge, it should take you six months to build the next one, right?

It is not that simple. The difference probably comes in the planning. If you are building a bridge, you will generally do a lot more up front work. What are the elevations at every point along the project? What is underneath the bridge? Is there clay, silt, or bedrock? Will the bridge need to be elevated to a certain point for river traffic to flow underneath it?

The average software project does not have nearly as much up front effort put into it. Imagine if you are starting to build a bridge over a river and you did not do all of this work in the beginning. If you did not check the riverbed to determine whether there is soft mud or bedrock underneath, you might expect that there will come a moment where you will need to invest more time in making sure that the piles needed to support the bridge are deep enough and tall enough. “We did not do enough planning” might sound familiar. It happens all of the time, especially if someone in your team is fond of saying things like “something something agile!” when asked about your processes.

This is the problem that gets created when you slap that “Engineer” sticker on the forehead of your software developer. There is not enough structure and planning around the average software project for the term “Engineer” to be appropriate.

We can fix this in a couple of ways. I sneak the word “Developer” into discussions whenever I can. This is not really a solution, but it prevents me from screaming out loud and clawing at my eyes due to the horrible burning sensation created by most software projects. I have been given feedback that people on my teams do not appreciate it when I do this for the duration of the post mortem meeting and it is a super bummer during sprint planning. Feedback taken.

The real way to fix this is to help educate the non-technical leadership around you about what software development takes and why it is so gosh darned hard.

Let’s go back to our bridge example. If we are building a simple bridge for foot traffic and bicycles, that is an entirely different proposition than building a high throughput multi-track railroad bridge. The amount of support work, the types of materials needed, and general planning that goes into making the railroad bridge is going to be significantly more involved.

The choice of materials might not feel like it translates into software development, but it kind of does. You have to choose your deployment strategy and the language/environment in order to bear the proper amount of load. If you choose your database infrastructure poorly for a high intensity system, it will be the same as trying to make a railroad bridge out of simple timbers and pedestrian bridge materials—it will come falling down.

The farther we go into this the more you might be looking at me and asking “Aren’t you basically proving that the two of them are really the same thing?”

You might not be wrong here.

The bridge metaphor helps to highlight where the difference is and why most software development projects are not really engineering endeavors. Let’s go over the differences.

Planning and approvals – There is generally a document or two that exists in every project before people start building. Most software development projects do not have enough of this. It is one thing to have a few requirements sketched out and another to have deeper architecture dive done before actually getting started. This goes back to those surveyors and architects. 

Architecture – This is one of the big problems in software development. Certainly at some larger companies, or more mature companies, there is a group of people who have to think long and hard about the deployment environments, development tools, and scaling strategies. The average software project does not have enough of these. Most software architecture is ad hoc and has poor assumptions about infrastructure and deployment. Even more controversial is that some of the people who design the architecture for some software systems are also the people who end up building them. The kids might tell you this is “totes cringey”. The software development projects I have been on that have been the most successful are the ones where there has been enough independent oversight in place to help steer software developers towards a successful deployment.

Complexity – Last but not least is our good friend: complexity. This is not to say that bridge building is not complex— it is. Software complexity is its own beast and is largely the reason that many software projects struggle or outright fail.

There is a big difference between linear complexity and geometric complexity. Google yourself some math terms if you wish to be educated on the shape of those curves. The best software development projects reduce the scope of their complexity at the planning phase. It is very hard to do this until you have blown up a project or two. I now ask myself “How can I reduce the complexity of this system?” at every part of the software development cycle.

Over the course of thirty years I have seen many different kinds of software projects. I interned at Motorola Canada working on an ISO-9001 certified waterfall software development project for emergency dispatch software. That was probably one of the more thoroughly planned out projects I ever worked on. A modern day Agile developer would have turned blue and clawed their eyes out at how much up front planning and process was involved. It was also a great project that shipped in a reasonable amount of time—and it saved lives!

So where do we wind up? I will still twitch a little when I hear “software engineering” and that will probably be true for some time. This is because so many companies have poor processes for planning software projects. As we march blissfully towards the heat death of the universe I hope that we see more architectural support for projects and more thought about software complexity. This will go a long way towards making me feel better about the phrase “software engineering”.

I hope it gives you an opportunity to reflect on the subject also.

Thank you again for reading. I hope that my angry fist-shaking-at-the-sky rant about software engineering has exploded your brain and left you completely shook. At the very least, it has moderately amused you and convinced you to come back next week to read some more.
If you do not plan on coming back for more, then you should immediately go purchase this six-pack of colorful clown wigs (disclaimer: This is Amazon Affiliated Merchandise) that you can buy and wear to work. You can see yourself out.

I mentor half a dozen engineering leaders. Half of them have very specific career goals they are looking to achieve and the other half are tremendous leaders who just want to have feedback on their growth.

I have observed some patterns of career growth over twenty years of managing and leading people. I do not know if these things are universal truths or if there are textbook studies that confirm or deny these things but I want to talk about transformative career opportunities and how to find them or create them.

You will have more growth opportunities and a faster career trajectory at a smaller company. There are many reasons for this. Larger companies generally have an established hierarchy and existing engineering leadership at the top. The existing engineering leadership has an obligation to help you grow professionally. They also have their own jobs and careers to think about. If you are an exceptional engineer who learns quickly, you might run into a ceiling because there is no room for you at the table due to scarce thinkers in leadership, or just due to the need to follow career growth processes which often include time in role. I have found several talented engineering leaders who were “stuck” in this situation. Most of the hard problems might already be solved at a large company. The ability to build a large scalable system is different from the ability to add features to a large scalable system. Every once in a while you will get the opportunity to participate in a refactor or rewrite but these opportunities are few and far between.

Growth opportunities in smaller companies vary from organization to organization and there are some things to look out for. If the business is growing, then the engineering organization will need to scale up to suit. If the business is not growing and the products are largely the same year-over-year, then there is no need to grow the team and generally there is no need for people to develop “next level” skill sets.

So what do you do if you do not have a transformative career opportunity at work?

There are a couple of things you can do.

Change employers – If you have spent two or more years at a company and it is not clear what your growth opportunities are, you might want to hit the reset button. I will confess I did this too much early in my career and if you are like me, you might have to spend fifteen minutes in every job interview explaining that.

Change teams – Sometimes there are different organizations within your own company that present career growth opportunities. There are rules about how to switch teams in most companies and you should certainly talk to your manager prior to getting too committed to changing teams. That might even be the catalyst for your manager to find something that will enable you to grow in your current role!

Join an internal committee – You may have internal technology groups or task forces that exist at your company. Many companies have different groups for managing the state of their platform, or have mentorship groups dedicated towards cross-team learning and promoting growth. Getting involved in one of these shows you are dedicated to your employer and should help you get visibility for growth opportunities!

Join an open source movement – If you are not able to find a new opportunity then you can also consider contributing to an open source movement. There are a lot of projects out there and some of them need help. I have seen a number of engineers grow professionally by doing this and I approve of it. It is not something I have done myself but it bears mentioning because I have hired people with strong open source contributions.

Write your own software – I will start by adding a caveat that some companies and jurisdictions have rules against this. I think that is unfortunate and if you feel like you want to write your own software, then I would recommend moving to a new location or changing jobs to give you the opportunity to do this. This is the thing I do the most. I have written a significant number of independent projects. Some of them have even launched! You learn quite a bit through the end-to-end software development cycle and this is one of the things I look for in a resume.

Do a consulting gig – The previous warning on companies and jurisdictions applies here. If you do not have any big ideas of your own, you can always find someone who needs urgent help or discounted labor because they cannot hire an entire engineering team. You can help someone build a prototype or repair an existing system to get some professional leverage and get paid for it at the same time! If someone does not have a large budget, you can always discuss equity in the project or ownership of the code. The latter is valuable if you want to use the code in the process of looking for more opportunities as a demonstration of your skills.

You might notice that all of these things sound hard or time consuming. This is true. Growing professionally is easy at first and after a certain point the number of professional openings at the next level decreases. You can always sit around and wait for that opportunity to appear in your current job. The problem with that approach is that you might find someone who has made more of a time investment into their career growth. You might get passed over by someone who is demonstrating that they want it more through some of the items above. Your recourse at that point will be to look for that next-level role elsewhere, with the understanding that if you have spent multiple years in your current role, you might only be eligible for career sidegrades instead of career upgrades. I caution people against doing this. Which brings us to the last thing you can do.

Retain a mentor – Hello and welcome to the sales pitch! If you are struggling with any of the above things and want to grow professionally, then you should consider finding a mentor. Some companies will have a Mentor Program. Some companies will give you a learning and development budget to hire a mentor. If neither of these things are true then there are some people out there who mentor out of the kindness of their heart for free. If none of those things are true for you, there are a dozen or so places you can go, present company included, to hire a mentor at whatever frequency makes sense for you at whatever price is affordable. You do not have to figure this stuff out alone!

So there it is! No begging for Amazon nickels this week. I have zero billion of those already. I have some limited capacity for new mentees and I am happy to spend an hour or two discussing it with you as a courtesy. That is right. If you are willing to give this car a test drive, you might be able to drive it home today. I always tell people I am willing to spend a few hours a year with them for free and any time after that is stealing time from my children. They are open to bribes and if you need to meet quarterly or monthly (or even weekly) then let’s talk Hard Cash Money. I don’t even need to go in the back to talk to my manager—I can either help you or I can’t.