Artisanal Concatenations of Sentient Emanations

Hello again! I almost convinced myself not to write today. Between staring at the legal kerfuffles happening over at Hasbro’s under-monetized tabletop rulebook revenue extraction unit, and the unrelenting rain hammering away outside my residence, I had a strong urge to just stare at the ceiling instead of clickety-clacking away at this keyboard. It is important to me that I keep writing, so here I am!

Everyone is good at something. Some people, however, are really great at very specific things. I have been told that team building and recruiting pipeline management are among my superpowers. There are two specific superpowers I look for in team members. The first is the ability to create documentation. The second is the ability to iterate on documentation.

Creating documentation is hard. Not everyone can sit down in front of a blank page and successfully get from zero to one. This is also true for making presentations. I will probably save that for its own post sometime in the future. My best guess is that some people experience fear and anxiety around drafting a document:

• What if the format is unacceptable?
• What if there is information missing?
• What if it is wrong?

These are natural feelings. There are a few ways to mitigate some of this fear. One way is to have a reference document that enshrines the “gold standard” for the document you are writing. This may include some templates, as well as criteria for completeness. Another way to mitigate this is to have a trusted party who can give you feedback on the document. It is good to have peers and managers who you can trust to look at a document, and give you actionable feedback to make it a better product.

This leads us to the second superpower: being able to iterate on a document. Today, modern document sharing platforms make this very easy. Being able to leave comments to people for areas they should change, or using “Track Changes” functionality to put those edits in for someone to approve/reject, are really good tools. Every once in a while you will get feedback like “I do not like this” or “This is not correct.” Teaching people how to give actionable feedback is really important. Include examples or more details as much as possible when working on a document with someone.

I have observed that some people are really good at one of these two things, but not both. Some people can create new documentation really well, and some people can iterate on documentation really well.

This is one of those areas where I encourage people to get out of their comfort zone. If you are not great at creating new documentation, you should try to do it more often to get better at it. If you are not great at reading a document and iterating on it, then you should do that more often for the same reason.

As a leader, It is important to know what superpowers exist for members on your team. It is also important to leverage those people to help other people refine their own abilities, and perhaps turn them into superpowers over time.

You know who else has amazing superpowers? Green Lantern. Green Lantern was my favorite superhero growing up. He still is my favorite superhero today. In the time honored spirit of randomly linking Amazon Affiliate Merchandise that is clearly labeled as such, I give you a link to this awesome looking Green Lantern t-shirt.

As always, thank you for reading along and I hope to see you back here next week!

Welcome to 2023! After a two week hiatus, I am once again back to maintain my title as Amazon’s Worst Affiliate Marketer. For a brief period of time this title filled me with deep shame. I have decided this year to lean into it. I embrace my badness at compelling you to buy things on Amazon!

This is an excellent segue into this week’s conversation. This week, let’s talk about doing your very best.

Throughout the course of your career you will discover that some of your efforts will give outsized results. At some point in your career you will do your very best work. For example, a friend of mine was part of the team that made the pinball game that shipped with Microsoft Windows. Not only do lots of people hold that up as the gold standard for many subsequent pinball games, it was arguably one of the most played games on the platform by virtue of it being bundled with the operating system.

Every game that my friend worked on afterwards probably had fewer players and also was less well distributed. You could make the argument that every other game he has shipped afterwards has paled in comparison to that shining gem. I bring this up because once you have had a certain level of success in your career, you will find that it is hard to replicate. Note: There are lots of better examples of this in the games industry, but if I am going to throw someone under the bus, I want to be able to call them up and apologize to them for it.

There are a lot of examples of this outside of games. It certainly applies to startup founders. Every once in a while a startup founder will experience an outsized exit, and then spend a considerable amount of time trying to replicate it. People will apply some sort of cognitive bias that amazes me. “I did this one incredible thing once, which means I can do it a dozen times more with a high degree of certainty”.

I always make the statement that I think that a successful founder’s second startup is likely their worst because they probably did not internalize why their first one was successful.

Let’s focus on games again for a moment. Games are very much a hits-driven business. Building hit games is hard. I was fortunate enough to have been making games from 2001 to 2005 in early mobile where the platform limitations meant you could make a lot of games with very small teams. This helped me to figure out my hit generation potential as a game creator. With 30 shipped titles, I have had six excellent successes. I can confidently believe that my hit rate is one in six. Yes, I know the number above suggests it is one in five. I also know that you want to be cautious in measuring success and I would like to leave some margin for improvement.

If you look at that math, what that meant is that every hit game title needed to pay for itself and five other titles for our studio to stay alive. That held true for early mobile for the years where mobile carriers were taking 500 games a year. They decided to reduce that to 100 games a year, which reduced the number of games we could release as an independent studio that co-published some of our titles. I have spoken elsewhere about this and how it eventually led to us shutting down our studio.

It is important to understand the economics of success and the economics of failure in your current role. It is also important to understand that sometimes you will have outsized successes in the course of your career.

Every once in a while I run into someone who has had an early and outsized success in their career. I engage with them carefully until I have a good sense of what they learned from that success, if anything. It is my belief you can always recreate your career successes under carefully controlled circumstances.  If you have not learned enough from your success, and possibly subsequent failures, then I am not sure that you are operating under carefully controlled circumstances.

As you tear into your 2023 workload, ask yourself what success looks like. Ask yourself some hard questions.

Are you trying to exceed your previous career success?

Are you working with someone who has a previous success that they need to exceed?

Are the circumstances for replicating that success carefully controlled?

These are hard questions to answer, especially if you are only asking yourself. I know this from experience. Early in my career I did not think enough about these things, and I believed that continued and increased success happened just by showing up and working really hard.

I now know that there are lots of other factors that contribute to success, and some of them are outside of my control. Understanding what you can and cannot control will help you be successful, and it may also help you realize this year might not put you on the leaderboard for “best professional outcome”.

Thank you for reading along! If you are looking for some actual actionable advice on how to be successful, I encourage you to read the-cheerfully-Amazon-affiliated-linked-book: The Power of Habit. I have recommended this book to two people I currently work with, and I also cheerfully shove this book into every professional book club in which I participate. Helping think about your habits will help you with your success. Consider this your call to action to click this link and buy this book. Otherwise, I will continue to gloat about my place at the top of Worst Amazon Affiliates.

I am looking forward to many more conversations this year!

Nothing more to see here for the end of the year everyone.

Looking forward to conversations on engineering leadership in 2023.

I am a little under the weather this weekend. That means spending lots of time pointing my sinus-irritated face at my shiny new 32 inch Samsung 4k monitor and watching Netflix instead of writing code or web content. Yes, that is an Amazon Affiliate Link. Click on it. Buy it. Love it.

At any rate, I want to talk about decision making.

I helped a friend of mine build an application that he uses to help make decisions. Users add deadlines, priorities, and a variety of other category tags for things they need to get done, and the app reduces that to a number in order to prioritize them. I was hoping to get him to be a guest writer for a week, and it does not look like it is going to happen in the near term. In the process of developing the application, he introduced me to the concept of the Eisenhower Box as the basis for his “get stuff done” formula. 

Rather than provide a detailed definition or explanation, I am going to just include this pretty picture of what the Eisenhower Box is.

I am not paid by the word here, so I am not going to include a page of explanation for each of these—Google is your friend!

I decided this would be a nice, lightweight post because I found myself spending a little bit of time explaining “urgent” to a few people in the past few months.

I also want to call out the “Not-important not-urgent” quadrant. Engineers have a genuine tendency to wrap themselves around an axle here. It is easy to have an idea that sounds really good and to decide to spend cycles on it because it is new and fresh in your mind. There have been moments in my career where I have been guilty of this, and later was asked by an executive “Why did you spend time on this?”  “It was shiny” is not a very good answer. Delete might sound a little extreme as an outcome, but it is probably the right thing to do. If people fixate on something that is not important and not urgent, and refuse to accept that it should be deleted, then you should concede the point and put it on a backlog—probably somewhere near the bottom. It is a good idea to keep a catalog of ideas and their relative priority. It is also good because it lets additional stakeholders look at the ideas on their merit and reinforce the business priorities.

Engineering teams occasionally put urgent technical items that are hard for stakeholders to understand into the backlog. One of the important jobs of engineering leadership is making sure that those tasks get addressed in a timely manner. This can be accomplished by asserting a window of time that this work ought to be done, or by negotiating with stakeholders by discussing the risks associated with the work being discussed. This is important because if a stakeholder decides that it is “Not Important” then it should be deleted. If this is erroneous, then it is important to educate them about why they need to upgrade it to “Important”, or else assert that it simply needs to be done.

As a final thought, be sure to invest the time in educating stakeholders as much as possible about items that are “Important” on the backlog. You will burn goodwill by asserting engineering leadership privilege and doing something that is important to your team. I would recommend keeping the frequency of these events to two a year at most, even if it means clumping together a few unrelated technical tasks.

Thank you again for reading along, and sorry for being a bit brief this week. I am not well. I hope my sinuses are back to normal again next week so I can be appropriately angry at things instead of feeling sorry for myself.

I spent quite a bit of time today brooding about this week’s post. I have a list of engineering leadership topics that should take me well into 2023, but something happened this week that I wanted to talk about.

As some of you may know, I play World of Warcraft. A new expansion dropped recently, and that means new Marketing and Promotions. There was some really cool stuff over on Twitter where you could generate your own one or two sentence story for your WoW character. That was reasonably fun. This past week they announced a promotion with Twitch where you could earn an in-game mount in exchange for watching World of Warcraft on a Twitch Stream.

By itself, that sounds like a good idea. I decided I wanted to earn this reward and proceeded to link my experimental Twitch account to World of Warcraft and commence the en-stream-ening.

This is where things went into the no-so-good-idea category. I did the thing that most people would do upon joining a website with a list of channels—I clicked on the first one. The topmost stream during this promotional event had seventy thousand people watching and was more than ten times the size of the next six or seven streams.

I am not going to name the individual stream I was following. A little simple math and Googling of things will bring you to their name and their internet location. About ten minutes into the stream I realized that the channel I was watching was an incredibly profane and angry person exploiting a launch bug in the game. They were farming a large number of recurring drops from in-game monsters that were supposed to occur once per day per person.

As he was doing this activity, someone alerted him to a battlenet thread where someone watching the stream complained to tech support that this was happening. He started looking at names in the thread to find if any of the participants were in his group of exploiters so he could kick them out. Let’s set aside for a second that the most popular stream for the game during an official partner promotion was showing a large-scale exploitation operation in realtime. I was appalled at the language and attitudes of the people in the channel.

About thirty minutes into this, the game team hotfixed the game and removed the exploit in real time. It was quite fascinating to watch the reaction of all of the people in the channel. The streamer spent about ten to fifteen minutes brooding about the sudden change in fortune before starting to do something else.

Around this time I was explaining to people online what was happening. One of my more thoughtful team members suggested I find a different stream to watch in order to earn my free mount. I switched to the channel that he recommended to find that this new streamer was actually having an in-channel debate about what just happened to the original exploiting streamer—There was no escaping it.

So what the hell is the point of this story? We will get there. Let’s fast forward a couple of days first.

 A company that runs Smash Tournaments announced this week that Nintendo had revoked their license and this year’s tournament was canceled with very little notice.

Nintendo followed up with a statement claiming “We canceled their license but we verbally gave them permission to run this year’s event since we did not want to ruin the fan experience”.

I am not a Smash Brothers fan, so I do not know how big or serious this is. Both of these things do not sit well with me and bothered me enough to set aside all of my engineering mentorship conversations for one week and talk about them.

Marketing partnerships are hard.

In the case of the World of Warcraft / Twitch partnership, a substantial number of players looking for a nice, free mount had their ears and eyes assaulted with vitriol for hours. It is not clear to me what the requirements are for a channel to have DropsEnabled in order to participate in company marketing events. If it was my brand and I cared about it, at the very least I would want to have some kind of ability to request that the flag be taken away from people who are publicly streaming exploits in my game and abusing them for personal gain, even if they were not verbally abusing people in the process. I was shocked that it was such an immensely popular channel and it did not reflect well on either Blizzard or Twitch.

Similarly, the cancellation of the Smash Bros event reflects poorly on both Nintendo and their partner company. Nintendo maintains that they have high brand expectations for these events. They revoked the license and then admitted verbally they were willing to extend it for this year to preserve the events for its fans.

Verbally?

Let’s pretend we are the leaders of the partner company for just a moment here. If you had an official license to perform some partnership event with a billion-dollar international company, and then you were verbally informed to proceed with this year’s event, would you still do it? If someone at Nintendo chose to take legal action against you, either through ignorance or malice, you have quite the burden of proof there. I would be hard pressed to suggest that “the show must go on!” on those terms.

One would think that if you really cared about the experience for fans, you might commit your 2022 license extension to a written notice.

Both Blizzard and Nintendo have large and loyal fan bases. Both of these feel like horrible failures to their fans and customers.

So why did I write a post about this?

I hope I never do something so stupid to a fan or a customer in the future that I come back and read this post with regret.

If you have fans and customers, please care for them. 

If you are going to partner with other companies, please make sure the experience is well-thought and sufficiently curated.

If those partnerships are going to change, please communicate those changes with your partners with your fans in mind.

Both of these stories could have had outcomes that were orders of magnitude better than the outcomes that actually happened.

Thank you for listening to my ranting this week. If I am not chasing teenagers off of my lawn next week, I hope to resume my regularly scheduled engineering leadership conversations.

Twas the night before Christmas, getting here was a chore
It all started off with the Ukranian war
Setting aside Putin’s international extortion
The Supreme Court threw out the book on abortion
People online got incredibly bitter
Everyone retweeting they are all leaving Twitter
Disney is swapping out Bobs for its bosses
Will the board get changed for their cultural losses?
Some people named Chrisley have their fortune in tatters
I have no idea who they are, or why the news thinks this matters
Centralized crypto funds continue to dwindle
Deregulated leverage is totally a swindle
FTX turned out broken, corrupted and shady
The news also tells us Gisele is leaving Tom Brady
But that’s not the only thing sweeping the nation
Let’s not forget the crazy inflation
Gas prices, food prices, and also the cars
And eight dollar check marks, instead of going to Mars
Everyone started to cut down on their spending
Ten percent layoffs are totally trending
Unless you worked at Twitter, let’s check the facts
Over half of the workers have gotten the axe
The midterms have happened, America has spoken
There was no red wave from Spokane to Hoboken
Trump announced to the world he is running once more
No one is shocked, we have seen this before
We all watched enough “Orange is the new Red”
Many hope that someone will Ron for office instead.
For all of the crazy things we see regressing
Next year cannot possibly be this depressing
So let’s raise our glass and attempt some good cheer
And have a Merry Christmas and a Happy New Year!

I have a little row of Post-it Notes attached to my monitor for blog conversations. Most of the topics listed are pretty self explanatory. Today I made a note to write about “Push vs Pull”. I spent about two minutes staring at it this morning, trying to figure out what the hell I meant by that. As it came back to me, I realized that everyone is going to automatically assume this is some sort of spur-of-the-moment Twitter thing—except it isn’t. Let’s talk about Twitter for a few moments, and then we might come back to “Push vs Pull”, assuming I don’t get tired and want to go lie down.

I have helped to pivot a business in the past. It is brutally hard. It probably took a decade off of my life expectancy, too. I wish the people still collecting a paycheck at Twitter all the luck in the world because they are going to need it.

When we were pivoting hi5, we were also switching stacks. We were going from a site written mostly in Java running on open source operating systems, to C# and running on Microsoft Windows. If you intend to change your business direction, I want to tell you there are positives and negatives to changing your stack at the same time. One of the changes, positive or negative, is that you will have significant organization turnover—up to 100% of your engineering team.

Elon understands that he needs to enact radical change to get his business where it wants to be. There is considerable noise in The Media and in The Socials about how he is getting there from here. Given the size of the task he is attempting, we should not be surprised that he is going to make some mistakes. I do wish him luck with the endeavor. Whatever happens to Twitter in the next two years will make for great grist for MBA textbooks around the world.

The deep truth is the moment that Elon and his stupid sink entered the building, the majority of that team was at risk of de-Tweeps-ing. You are more than welcome to disagree, but if the majority of people were doing the right things, the business would be in a far different place than it is today.

So how do you “right-size” such a mammoth organization effectively, intelligently, and with grace? I do not know that you can. I do think that some of his pronouncements and processes for decreasing the burn were not graceful. Elon made a point of shoving people towards the exit doors quite forcefully. I appreciate his reasons for doing so even if it is massively dramatic and poorly executed.

I could dissect this further, but other people are going to do a far better job at it. At the very least I am thankful that it has taken “quiet quitting” out of the mainstream conversation. I am slightly disturbed that it gets more clicks than FTX stories, and I am also ashamed to say I do click on all those juicy Elon headlines. I am part of the problem here. The good news is that it has not made me tired yet and I can talk about what I originally planned to talk about: “Push vs Pull”.

You are seldom going to get 100% utility out of your engineering team. Your engineers might have health issues, they might be needing to replace a leaking tire the day they purchased new brakes, or there might be juicy stories about Elon Musk that are just breaking. Your goal as an engineering leader is to make sure to call people to attention enough times to make sure that you are meeting your deadlines and possibly improving the efficiency and quality of your work over time.

There are a lot of tools at your disposal to help your teams be more successful. You can push your teams, as demonstrated by the shoving example above, or you can pull them.

I originally expected to tell you all that pulling is by far the best way to get your teams to make your teams successful. On the spectrum of “I am leading people” to “I am managing people”, pulling is very much on the leadership side of things. Pushing your teams is also necessary, and yes, this is more on the management sides of things.

In an ideal world you do not have to push your teams. In some subset of ideal worlds you do not even have to pull your teams. There is some magical universe where everyone just perfectly does their work and even the product managers walk around the office smiling.

When things start going off of the rails is when you need to make decisions whether to push or pull. Your team definitely appreciates it more when you pull. Rallying people to get their work done, unblocking their issues, and even jumping into the trenches to assist them definitely scores major points.

At the risk of mixing up the metaphors too much, sometimes there might not be enough carrots to go around, and you are left with using the stick. I dislike pushing people because I dislike being pushed myself. I will grudgingly acknowledge the times I am being pushed, and I take that little bit of self awareness with me when I push people on my teams. I do my best to tell them I am pushing them, and there are times I am apologetic about it, and other times I am explaining why it is that I am pushing them. Sometimes I do both in equal measure.

I did not want to go back to Twitter for an example, but it is easy to do so. Elon is clearly pushing his engineering team. He is pushing them very hard to the point that it is a violent shoving exercise. While I may disagree with the exact tactics of the past few weeks, he is absolutely doing something that is aligned with his vision on how to fix the business. He cannot pull his way to victory with Twitter. He needed to push people. If the first week he arrived at the office he started gracefully offering packages to people and reviewing the overall business, it would take him six to nine months to bring the team down in size to where he wants it to be. That six to nine month process would be hideously expensive, on top of all the money he already paid. Like it or not, this was always going to happen from the moment that former Twitter leadership decided to sue Elon Musk to close the deal.

Remember that leadership is generally accountable to shareholders and not accountable to employees. The best leaders are accountable to their employees because that is how you build amazing teams. Given how little conversation there was about employees in the middle of extracting shareholder value through the Twitter sale to Elon Musk, I would be hard pressed to work for one of the former leaders of Twitter. I think they did their teams dirty. Before you cancel me on The Socials, I would be equally hard pressed to work for Elon Musk. I probably would have been looking for a job the day there was enough of an agreement present that it was an inevitability. While I believe in Elon Musk’s goals for humanity with electric cars and space travel, whatever he is doing at Twitter is an aberration and a distraction from those goals. He also practically walks around with a coffee mug that says “Remote work sucks” and expects people to work insane 2001 hours in 2022. It bears mentioning that most really rich people own a very fancy car and if you work really long hours and commit yourself to the business, then next year they might own two.

Okay I will stop. The important thing here is that you need to balance pushing your teams to be successful and pulling alongside them to make it happen. I apologize for talking too much about Twitter, even if some of what is happening is somewhat related to leading and managing, and the difference therein.

We are getting closer to my holiday poem… So why not make yourself comfortable by indulging yourself in a Clearly Labeled Amazon Affiliated Oversized Blanket? While Amazon’s Marketing Algorithms tell me I ought to be shamelessly plugging tech merchandise, I believe that you all want more creature comforts. You deserve it. Prove the machine wrong by purchasing one of these blankets for yourself or someone you care about today.

See you all next week!

I have recently had conversations about software development processes and have heard the words “scrum”, “Agile”, and “waterfall” thrown about with tremendous ceremony. I have worked in many places where people use words in conversation in a way that implies that they are important and sacred and to the speaker they have no meaning. “Where are we with Brand and Budget” I might hear someone say. There is an equal and opposite effect when I hear someone say “This Is Not Agile”.

If you have ever uttered these words, you have missed the whole point of Agile.

I am not going to be one of those people who writes a bombastic article that Agile is dead, or that it is a fraud perpetrated on teams by management, and that most of it is fiction.

The deep truth is that most Agile is an approximation anyway because the following user story will never appear on your scrum board:

“As a software developer I need Christmas to arrive one week late.”

So what the hell is Agile, and why does this sound like it makes me so angry?

Before I answer, I want to time travel to 1993.

John was a software development co-op student in 1993 working for Motorola. Motorola had a design center in Toronto where they made devices to help improve communications as a part of 911 software systems. I had the blessed fortune of joining a team to produce highly redundant systems that helped save lives. The work was all hard core modular C programming and designed to work on highly available hardware. This is important because we all had log books, strict documentation requirements, and were also ISO-9000 compliant. The only way our work would have been more waterfall is if we were doing it under a big water feature in Niagara.

The project shipped on time, on budget, and it was a fantastic work experience—even if one of my jobs was to take a copy of the project source code on magnetic tape and walk it to an offsite location to be signed into a vault for safekeeping and redundancy.

Let’s come back to today.

I bring this up because every time I enter into the conversation on how we get our work done, I have to point out that for each team and each product there are different methods that work well, and there is no One True Answer.

This is especially true for Agile teams.

The process of doing work on an Agile team is a conversation between the product customer, the product designer, and the product implementer.

There is one more participant in that process and that is the scrum master.

I have had to adopt the scrum master role as a part time job in the past. I am usually doing one or more other roles at the same time. When I am either volunteering for the role of scrum master, or having it thrust upon me, the first thing that I do is gather all of the stakeholders and  declare that I am taking the role with a known conflict of interest and ask for everyone to trust that I will handle that. I also ask them to call me out when I am failing at it, and to keep me accountable.

The scrum master role is not well understood by many people. I have had the great fortune of working with many amazing scrum masters over the course of my career. They help everyone get things done. They are great coaches, they are wonderful listeners, and they are excellent facilitators.

I have also had to work with many scrum masters who struggled with their role. There are a lot of traps to fall into and I do my best to help people work their way through them.

“This Is Not Agile”/”This Is Waterfall”

The number of times I have had to drag people kicking and screaming away from the Semantic Scrum Master debate is beyond counting. It is important to remember that Agile is all about people over process. Anything your people want to do is Agile. Even if you were a fully ISO 9000 certified process and you declared you were an Agile team, you are now Agile. Do you ship software on time or do you improve your velocity? If the answer is no, you are still Agile. You are just doing bad Agile. If your teams really want to do something and it sounds like it is not Agile, just ask them if it helps them get the work done. Measure it over time, and see if you get better at it.

“This is not the way I want it done”

As a scrum master, you are a coach and a facilitator, not a dictator. You have to let go of your notions of control and ownership on anything but team improvement. What works for one team does not always work for another. Your best successes will come by laying out options for the stakeholders to think about, debate, and adopt. Any time I see a scrum master trying to push people towards something, I have to gently coach them off the ledge and get them to take a more team-centric view of how work gets done.

“Measure twice, cut once”

Even more egregious than needing things done your way is making changes to the way your team works without really understanding the data. I appreciated the many times I have been brought into an organization to help them ship faster with better stuff. That process takes a lot of time. You need to get to know the people on the team, and watch what they do. Listen to them, and ask them questions. Make notes for when you are ready to give them options on things they can consider changing in order to improve. I have joined teams very early on with a lot of process dysfunction. I have my own playbook for urgently addressing these situations, although my preference is to take six weeks or so to watch what is happening before I make any changes.

These are the most common scrum master mistakes I have seen. It is very easy to get defensive and frustrated when you make a mistake like this and you are confronted by your stakeholders.

I have had some success in working through issues like this with a number of scrum masters over my career, taking them from struggling with a single team to being able to work concurrently with three or more teams while creating speed and quality improvements on all of them.

Part of this stems from a six hot dog / eight hot dog bun problem in early stage companies. When you get your first full time scrum master you might only have one team. There is a human need to feel like you are delivering some kind of value by changing things, and it is an easy win to make yourself look successful by telling your new boss “hey, look what I just did!” Unfortunately, this might not be what your team needs. You are better served by being patient and learning what your team is capable of doing before starting to make measurable sustainable changes.

If you are contemplating hiring your first scrum master, it might be worth asking yourself if you want to have someone else take the mantle for a while, especially if it is a single team. You will get great mileage out of people you are grooming for leadership, and it will help avoid a number of problems when you hire a scrum master who is likely underutilized and might accidentally thrash your teams in order to show that they are earning their paycheck.

Thank you for reading along. This was a heavy topic. There was a time in my career when I was frustrated with educating my peers and more senior leaders in a given company and I was resentful for it. This post, at some level, is penance. I hope you enjoy it and that you reflect on the people you work with to ask yourself how you can help them be successful—much the way I have assisted a number of scrum masters on their roads to success.

Stay tuned for next week where we will continue to not talk about quiet quitting!

I spent quite a bit of time this summer building up a Twitter presence for derfdice.com. In the past week the number of impressions and new followers has slowed. It would be easy to assume that I was doing something different, or something wrong. If you take a look at the news, you could assume that something had changed and it might not be my behavior. I am a big “no spoilers person”. You can Google “Elon Musk Twitter” if you want a better understanding of what is happening. Clearly Twitter has undergone some changes.

If I had to distill what I do down to two words, it would probably be “managing change”. Creating and deploying software is all about changing things. You are changing versions, or changing servers, or changing industries. The older you get, the more experience you have with experiencing change—both good and bad.

If you are working on a software team, you are experiencing change. The product is changing, the platform is changing, the team is changing, and even the company itself is changing.

Coping with change is hard. I always tell people that it is important for them to become “comfortably uncomfortable”. In the past year I have helped a number of awesome engineers on their path to transcend their career arcs. Almost all of them have expressed their discomfort in the process.

If you want another trite and two word summary of what I endeavor to do, let’s try “retaining teams”. Getting people to cope with change is hard—this includes both good change and bad change. If there are good changes happening in your company, you might experience those as bad changes. I have experienced something like this. When you inherit a new boss, or the organization restructures, it is entirely possible that lengthening reporting structures make your existing role feel like it is a relative demotion. Other times, you might be thrust into a role where you have too much responsibility for you to be comfortable managing.

These are both unstable states. As a leader, it is important to understand when you have made things uncomfortable for people, one way or another. It is equally important to address that discomfort in some fashion.

I do not know if I emphasized that enough. If you have created an unstable state in your organization, it is the responsibility of leadership to manage it. If you ignore the issue or you fail to manage it, the consequences will be some mix of team churn or loss of morale.

So what can you do?

Be Accountable

I can no longer count the number of times I have stood in front of a room full of people and told them that we are about to enact significant changes. Tell everyone what is changing and tell everyone why it is changing. Sometimes you are changing for growth, sometimes you are changing for lack of growth. Sometimes you are changing things because things are not working.

If you believe someone is negatively impacted by these changes, arrange a private meeting to hear their perspective on these changes.

Be Authentic

Tell people how you feel about the changes. Tell people if you are excited by them or if you are frustrated by them. If people can understand how you feel about these changes it might help them to express their own feelings about it. 

Be Available

When you are finished talking, understand that the next most important thing to do is to listen. Set up office hours and private meetings for people to talk to you about the changes and what it means to them.

Be Considerate

If someone is inheriting a new boss, or their reporting structure has changed, talk to them about how you can make it easier to swallow that bitter pill. Any token gesture you can make in the middle of changing things for people is greatly appreciated, whether it is work related, compensation related, or even some extra days off to think about it.

I have employed all of these tools when organizations have changed and have found they are helpful in getting members of your team to accept change. If you are not doing enough to manage change in your organization, they will tell you as much—by quitting.

If you have enacted a massive change to your organization, look at the subsequent departures to understand whether or not you have done everything you can possibly do as a leader.

For all the news and noise about Twitter, this is the thing to watch next. Steve Jobs did something similar when he rejoined Apple, and look at where it is now. I am not saying there are direct comparisons between the two people, but both companies are in similar places. The more important question to ask yourself is whether or not your own company is in the same position.

This week’s post is brought to you by IOGear HDMI 4 port adapter. I bought one of these a few weeks ago to connect all of my consoles to one display and I could not be happier. IOGear.

We are returning to double digit days on not talking about “quiet quitting”. Every day is a new battle. See you next week!

As you go further into your software development career, you will need to be thoughtful about communication patterns. One of the skills you will need to master is communicating progress in a way that is meaningful for senior leadership.

This post is a penance for a recent transgression. It is very easy to give a weekly status email that tells you everything that is in progress and conveys almost zero useful information to the recipient.

Engineering leaders need to become accustomed to answering the following questions in their updates:

Is everything on schedule?

Are there any new risks that need to be discussed or managed?

It is very easy to write an email describing the weekly activities of your organization in a way that does not answer any of these questions.

Making sure that leadership is aware of any changes to completion dates for a project, and identifying areas where there is increased risk is very important.

You might make an assumption that there are no changes to a schedule, and that there are no changes to risk in a weekly report. I would encourage you to add that explicitly to your email in the future—especially if it is a long status email.

While it is nice to convey your team’s status at this level, it might prove to be dense and inscrutable further up the chain. They will want to have a quick one or two sentence summary rather than digging through the email to confirm the overall project status.

It is a good habit to get into, and one you can start tomorrow regardless of your current level of seniority.

That’s it. That’s the whole post. You might find shorter posts are highly correlated with holidays. I will be outside trying to climb the neighborhood Halloween decorations leaderboard for the balance of the day. I would love to shamelessly give you an Amazon Affiliate link to some of the merchandise I am putting in the yard, but it is better to go buy all this stuff on discount from the various halloween stores and aisles on discount in 48 hours. This is how you can fight “The Inflation” for next year.

See you next week!