Artisanal Concatenations of Sentient Emanations

iMonopoly

I worked for a year for Trip Hawkins, the founder of EA. I really enjoyed playing many of their early titles during my formative years and I believe that playing some of the early EA games like Seven Cities of Gold, Archon, Ultima IV, and Pinball Construction Set were the foundation for my career as a game developer.

One of the things that made EA successful early on was their decision to eliminate the middleman in going to retail. There is a lot of documentation on the business innovation and technology innovation that EA did in order to generate outsized returns compared to their competitors.

I first made BREW and J2ME games in 2002 for feature phones. More recently I have worked on iPhone and Android games for smart phones. Throughout both of those eras, there are large incumbent platforms who have similar properties to the middlemen that EA circumvented.

This brings us to today and the Epic Games lawsuit against Apple. Oh yes they are probably suing Google too and everything or whatever. But let’s talk about the Epic Games vs Apple lawsuit.

I think this is going to be the games industry lawsuit of the decade.

It goes without saying that I am often an indie or startup developer, and so as a “temporarily embarrassed billionaire” my sympathies lie with the content creators and my own person-of-the-year: Tim Sweeney. If you think that prejudices my opinion, I can accept that. I-yam-what-I-yam. I also think that the games industry is still formative and we are still figuring many things out. Every penny that we can keep inside of a game company is a penny that gets reinvested in better games.

Accordingly, I want to talk about thirty percent and why I am rooting for an independent games store (like the Epic Games Store) on Apple as an eventual outcome from this case.

Let’s start by asking an interesting question: What does it really cost to make a game?

The answer varies. It is like asking “what does it cost to make a wheeled vehicle?” A bicycle is cheaper than a car is cheaper than a semi-truck. They all have different material requirements, different sizes, and different assembly processes. You have teams of various size comprising varying specialties. There are games that are made by one person, and there are games that have high profile actors, hundreds of software developers, and special effects production teams similar to those of the movie industry.

It is hard to say what it truly costs to make a game because of this range. There are so many different ways for people to make games that it the best time ever to be a game developer. I am also fond of saying that because it is the best time to be a game developer, that makes it the worst time to be a game developer too. Everyone and their sibling has a studio opening up and we are blessed as players with a lot of different choices available when we sit down and want to play something.

So what does this have to do with the thirty percent cut of the platform store?

Almost nothing, unfortunately, but I wanted to break down All-Of-The-Costs that people think about so we can focus on the ones that matter: Transaction costs, security costs, and marketing costs.

I think that we can all agree that there is an intrinsic cost for doing a credit card transaction. Tim Sweeney over at Epic Games said repeatedly that fifteen percent is a good number for that, and that is what the Epic Game Store charges. I like that number. It is reasonable. Fifteen Percent is also less than Thirty Percent.

So let’s ask about that other fifteen percent.

Apple has said they provide a secure platform for players and for game developers. They have a closed ecosystem for content and safeguards to keep people in their garden. I can respect that security is worth something—when it actually works.

You can make a case that they are investing time and money from their app store profits in protecting users. You can also make a case that they are fighting a losing battle. They have created a low moat to content developers to get into the store, and also have created an attack vector potential that exposes them to bad actors like the dubious app described above.

I certainly hope, as a result of asking for 30% of app store revenue, that they will provide some recourse for the individual above who lost their life savings to an Apple Approved™ product, right? Does this work like FDIC deposits in a bank? For a trillion dollar company, it should.

I am also skeptical that this is the case.

Setting aside that one specific piece of weak empirical evidence, I want to talk about marketing costs. This is where the pain for most developers truly begins. Because we are blessed with such a golden era of game creation capabilities, we are flooded with an assault of content on a daily basis. Never have we had more choice for what to play on every platform. On mobile you are even luckier than on other platforms because you can download the vast majority of games for free. Free-to-play game developers make their revenues through repeated digital purchases on the back-end. There is such a voracious appetite for buying in-app items and currencies that the one percent of customers who do pay, pay so much that it supports the cost of the development and marketing for just about every game genre out there.

As companies get successful and as brands start to get built or enter into this space, suddenly there is a need to promote and market content to players. Of course, this is what some of that thirty percent is for, isn’t it?

Incorrect. If you asked the average top 500 mobile game developer what their budget was for marketing and user acquisition, it is not going to include any of the money that gets taken by the platform and it will generally be half or more of the developer’s margin because they are racing to outspend their competitors on acquiring eyeballs. Welcome to the red ocean, everyone!

And this is why I think that Tim Sweeney from Epic Games is talking some sense when he says fifteen percent is reasonable. If you are not getting marketing built into that thirty percent, then that is a pain point and a place to improve if you want to help developers have more money to build and promote their games.

I worked at hi5 Networks way back in the day and we tried to encourage people to come to our platform off of Facebook Canvas. We included a promotional package as a part of coming to our platform and aggressively marketed games within a framework based on expected Daily Active Users/Monthly Active Users (DAU/MAU) ratios. If you had a very good game that was retaining users at a high DAU/MAU ratio, we would promote you as a platinum-level partner. If you had acceptable numbers, you were gold or silver. If you didn’t have good DAU/MAU numbers, we would put you into an experimental rotation and sit you down in the corner while you figured out what you did wrong.

Our long term goal was to find a minimum transaction cost for people, say in that fifteen percent range where we say “we will be a transaction partner for you” that would include zero marketing for zero percent revenue. We wanted to build a slider for game partners where you could ratchet that up as high as you wanted in exchange for preferred promotion.

When you launch your game you want to have the marketing percentage low while you figure out your game’s success rate. When you have figured it out, then you probably want to give a larger percentage of revenue to the platform in exchange for marketing or promotion to attract users. Once you have established a healthy audience you could drive that sliding revenue share back to “just the transactions” for new users.

In the current era everyone has to install one or more ad networks or ad network aggregators. All of this has to be done outside of existing platform fees and the developers are forced to pay extra tariffs to extra companies in order to get players into their game.

I often wonder why other platforms are not doing this. I think it makes a great deal of sense for everyone. I think if we had this today in all of the platforms, then we probably would all be better off as a game industry.

So let’s get back to the lawsuit.

I want to ask four more questions.

• What would I do if I was Apple?
• What would I do if I was Google?
• What would I do if I was Epic Games?
• What would I do if I was me?

What would I do if I was Apple?

First of all, my answer would be “What was that question? I can’t hear from atop this trillion dollar pile of money.” Oh wait—that is what they are doing. They have agreed to create a special small business program for companies that are not making any money to have fifteen percent until they are actually making money. This solves the problem for ninety-five percent of the developers out there. It is pretty clear that they understand what small percent of companies are making serious money. It is good to have thirty percent of all of the big revenue games and they do not really care about that extra fifteen percent of zero million dollars. I think that making this concession was a shrewd move and took some of the sting away from the younglings in the game developer ecosystem. The suggestion I would have for Apple is my idea from hi5 that I outline above. If you want to retain a larger percentage of revenue from developers, start giving them larger marketing value. Absorb or obsolete the inefficient third-party markets that developers are using after paying thirty percent. Heck, even make the sliding window of revenues that I suggested above. If it was effective, you would make more than thirty percent from some developers!

What would I do if I was Google?

If I was Google, I would focus on what Google does best. If you don’t know what that is, look it up on Google. Google is not a credible competitor in In-App Purchases for a variety of reasons. First, they did not train their users with years of habit-forming 99 cent purchases for music (hello there iTunes). Second, they are an ads business, and that is their core competency. Finally they have a less affluent audience, pound for pound globally, compared to their higher-priced-prestige-branded competitor.

So embrace that. Rather than do an also-ran strategy of matching fifteen percent for small app developers, go all in. Partner aggressively with your content people and make it fifteen percent for everyone. Accept that you are not winning this battle. And you already let your brand partners like carriers and handset makers offer their own store fronts. You may as well say “Yes we support this lawsuit and we support our content creators and we are going to move to fifteen percent for everyone and embrace our content partners’ success and want them to reinvest their winnings in content our users love!” What do you get out of this? For starters you are suffering some pain at the expense of creating deeper pain for a competitor. That has to count for something. You might also find that people will suddenly care more about merchandising on your platform and want to aggressively work to get you better content as a launch partner. You could also find that the halo effect of providing service to your content partners will be reciprocated by people trying to find ways to incentivize their VIPs to play on your platform. After all, some of the biggest VIP payers in these games would probably recoup the cost of a free high-end Android device over a small window of time.

I think there is a window of opportunity here for Google to outsmart a competitor and win the love of the developer community and put a “best foot forward” for becoming the platform of choice for developers. I think the long term rewards for Google would be worth it.

What would I do if I was Epic Games?

I think they are already doing many of the right things. They have a storefront created. They are giving away games that players love. They have a handful of brands and great experiences they are leveraging to break down the monopoly on content stores. They are providing tools and technology to developers to get behind their push towards greatness. They even had a contest to give away “Free Fortnite” hats as merch! Yes, I own one. Yes, I love it.

So if they already have a pretty good story, what else could they do?

I think they could probably invest some more time finding examples of Apple behaving like a monopoly. I am going to tell a story here to give an example of things to look for.

When I am talking with Apple developers I am constantly inundated with stories about how painful the process is to submit an app. There is an interesting subset of these stories that has an extra wrinkle.

Apple itself has its own content guidelines and they often reject submissions for technical reasons as a way of enforcing rejection for subjective reasons. Years ago, I had a number of friends who were working on applications that were reviewed by Apple and rejected. Sometimes they add a message to the rejection to the effect that “this might not be a suitable application for Apple for its store and you should consider maybe just sharing it with your friends using ad-hoc provisioning.

This is a curious position to take for a store. This is only half of it. Let’s talk about how insidious the process really is.

Apple has a set of submission guidelines, and generally they have a feedback system and a reasonable turnaround time for processing your application.

The majority of times that someone runs afoul of this process they will find themselves getting a single rejection reason, and it will come at a painfully slow rate.

Apple will use their technical submission process as a weapon to apply a death-of-a-thousand-cuts to an unwanted title with the hope that you finally give up and stop submitting your application over and over again.

You can generally expect that they will continue this process up to a year. For the people who had goofy apps, or stuff that was not really exciting to Apple, every one of them who persisted in submitting over and over eventually got through. This is a subset of people who attempted. Apple has done a very good job of using technical reasons to keep stuff out of their store that they do not like.

If you ask me, that sounds like a monopolistic practice. It is also one that can be means tested, or discovered, to add more fuel to the fire.

For example, what if you made a game called “Rotten Apple Smasher” and tried to submit it to the store? Or made a game called “Idle App Store Submission Process Rejector Tycoon” where you were a process reviewer for games?

You could create a technically viable application that takes cheap shots at Apple. I would wager it would not pass the subjective content smell-test and they would do their best to tell you not to submit it back to their approval process.

If your application was developed with ten “violations”, and submitted independently with a similar game with the same issues, would you find that there was subjectively different treatment for two different experiences?

I would bet money that you would.

So what would I do if I were me?

First, I would start experimenting with Progressive Web Apps. Second, I would write some articles leading towards discussing ecosystem issues as it got closer to Apple’s day in court. Third, I don’t really know. I am currently still on the second thing. 

Long term, I would love to help turn my part-time efforts to make web content outside of the app store into something bigger. This is the same elimination of the middle man strategy that EA did which helped them attain dizzying heights as a game publishing juggernaut. I believe strongly that we will see interesting innovations and iterations in mobile content in the coming five years to tackle the problem that Epic is tackling.

Thanks again for reading. I hope you enjoyed tagging along as I just crossed “Work at Apple” off of my list of potential things I could do with my life, for all the world to see. Is it a bad idea to alienate a company this way? I don’t know. I do not buy their products as a consumer and I do not believe they have my best interests at heart as a creator. Does being self interested in the advancement of content creators make me a bad person? I sure hope not.

Stay tuned for next week’s article. I doubt it will be as bombastic as this one, but it certainly cannot be worse than last week’s “John Szeder gives himself a report card and thinks he mostly did a good job last year with his writing” article.

I have dabbled on and off as a writer for a while now. It was a natural step to take for someone who enjoys storytelling. It is also probably a large part of why I love working on video games. Video games always tell a story, even if it is not a story-based game. This week’s random article is about writing and story-telling.

Last year I made a commitment to blogging weekly as a way of working on my writing skills, and I am still maintaining the habit. I never got to figuring out “the twitter”, which was the other commitment I made to myself. I may revisit that one soon. Part of the problem is that I have an extensive community on facebook and they give me plenty of social reciprocity for my limited story-telling. Also, Linkedin is a serviceable platform for broadcasting my writing.

Let’s talk a little about my goals for my blog this week. Here are the five goals.

• I wanted to get better at writing.
• I wanted to write regularly to build a habit.
• I wanted to offer some education from my career.
• I wanted to build an audience.
• I wanted to start promoting things I am working on.

As an exercise, I am going to evaluate myself on each of them.

First Goal: I wanted to get better at writing.

I would say I am  “just successful” here. The metrics week-over-week would disagree. I am blessed with a good friend who reads these articles and takes most of the cartoon stink-lines out of them. I generally get 10 corrections per page per week, split between grammatical syntax fixes (80%) and rephrasing requests for my stream-of-consciousness writing. I generally pour most of these articles out in a single session lasting thirty to seventy minutes. It is hard for me to re-read my own writing and catch the subtle errors.

Second Goal: I wanted to write regularly to build a habit.

I am going to say I am “very successful” here. I have lots of things to write about yet, and I am maintaining a pace. I get nervous every few months when my “to do” pile of articles runs dry. I think I can sustain this for at least another three to six months. Caveat: I say that to myself every three to six months.

Third Goal: I wanted to offer some education from my career.

I am going to say I am “very successful” here. I am actually humbled by the number of people who reach out to me when I write an article. It is seldom zero and it gets up to ten people sometimes. I really appreciate everyone’s feedback and validation on what I am writing. The majority of people with whom I have discussed some of my articles have been people I have worked with in the past. A smaller number are people who have read something that touched them and wanted to learn more.

Fourth Goal: I wanted to build an audience.

I am going to say I am “just successful” here. I was tempted to invent a new category of “successful” for my audience-building goals, but I stopped. It started to read like one of those long articles in an online recipe that you scroll past because it is just a random wall of text that isn’t the recipe you came to find. So let’s just say that I am pleased with the slow growth of my little writing habit, even if I am not an internet marketing guru. I am also going to skip past using this as a not-so-subtle plea to all of you to share these articles with your friends. Maybe. I am going to have to spend some time thinking about things I can do to make that “very successful”.

Fifth Goal: I wanted to start promoting things I am working on.

This is where it falls apart. I am not successful at promoting things I am working on. I have at least one hobby-project that I completed last year that needs to find its legs. I also have another project in the works that has suffered from some unrelated delays. I did write some horrible e-books I am going to link here ironically (desperately? curiously?) to see if anything happens. If nothing else, you can see how far I have come from the amusing little stories that were the genesis of my writing experiences. I also have some other things I want to promote. I have a game I am building that I want to talk to you all about when the time is right. I made some little web apps here and there. I also would like to participate (on a part time basis) in building venture studios. Perhaps these other projects have all moved a lot more slowly than I wanted them to because I am spending time focusing on my writing, working through a global pandemic, and supporting a family. Regardless, the other goals have been met so well that I do not regret being unsuccessful here.

I make myself take a local hike after I am done my weekend writing. It gives me time to reflect on what I have said and what I should do differently. I may write a follow-up post to this article if I decide that I need to revamp my writing goals for this year.
Thank you again for reading! I apologize that this is a lot shorter than usual—blah blah blah Easter. For upcoming articles I have some thoughts on the Epic Games’ monopoly lawsuit, some opinions on “ad-hoc extracurricular education” while working professionally, and more ongoing lessons-from-the-trenches about engineering-management do’s and don’ts. The rambly ranting will resume next week!

Hello everyone! I am reaching deeper into my bag of made-up-things-to-talk-about. This week I want to severely abuse the english language and the notion of metaphors to talk about imperfect teams.

Throughout the course of your leadership career you will find that you have individuals on your team that are not quite perfect for their existing role. I find that figuring out what to do in those situations is one of the biggest challenges in team management.

It reminds me sometimes of this.

I have found that it is worth it to spend a little extra time making sure that everyone has the best possible role on a team, even if it is not perfect. I wanted to talk about a small handful of specific individual types I run into pretty regularly.

The obscure specialist

As systems mature and evolve you might find that you will have one or two people with an indispensable skill set. They are very good at one specific thing, and not so great at many other tasks. If this person was not employed here, and a specific piece of technology broke, your customers or your partners are going to have a bad time. A long time ago I worked at a startup where we needed to have a Flash developer around for emergency fixes for a legacy piece of software. This was not a full time job. The individual in question was a decent developer, but was not really suited for delivering back-end software, which was primarily what the rest of the team was working on.

So what do we do here? I find that I have to do a little calculus when this situation appears. The first thing you should do is to figure out the potential frequency of issues and the resulting dollar impact to your business. In this case it was used by a large percentage of our customers. An incident happening once a year would approximately cause enough of a cost to the business that would justify a year’s salary. Flash updates or security issues happened at that frequency year over year. So even if he did nothing all day but put out fires, it was a good return on investment.

That being said, I am not a fan of keeping team members on the bench and I know that most people who love making software dislike sitting around too. So the next thing to figure out is what they should do when they are not dealing with urgent software issues. Sometimes you can give them low-hanging-fruit tasks that they may not be terribly excited about. This is risky because it distracts other team members who may be needed to help train them or spend time improving code that may be sub-optimal. Alternatively you can make up some projects that better align with their skill-set on the legacy feature they are currently supporting. There is no perfect answer here. In the end you will likely experience a regrettable loss to your team and need to figure out how to find a contractor to deal with emergencies. Unfortunately this is not very cost effective.

The butterfly programmer

Engineers love shiny. Golang, rust, kotlin, there is a new flavor of amazing technology coming out every year and it is super important to learn the latest and greatest thing. Since everything ultimately resolves down to zeroes and ones in binary, what is the downside to staying current on leading-edge software development practices? The answer is “plenty”. There is a fine line between leading edge and bleeding edge. Early on in my career I indulged far too many people in letting them play around with new technology in production environments. They come in, get everyone using new tools and suddenly learn that sometimes the technology is not quite a good fit, or it is not production ready. This is when you discover if you have a butterfly programmer on your hands. A butterfly programmer will suddenly vanish at this moment, off to the next project or company, like a delicate butterfly going daintily from flower to flower sipping only the most delicious of nectars.

When someone wants to use a brand new technology on a project I stare at them real hard before saying “yes”. I want to make sure that if they inflict a new technology on the team they will be the sort to take it over the finish line and ship it. If I am not convinced that they will get it to 100%, I will likely refuse them their request the first time. If they are a butterfly programmer they will likely leave the team before they ask me again.

The squirrel chaser

This is another variant of an easily distractible engineer. The squirrel chaser cannot stay on task. Especially if it is something they do not love to do. Sometimes you will task someone with a two hour project and five days later it is not done. It is probably because they saw a squirrel, and who does not love chasing squirrels? This is a dangerous behavior. If you have something important that needs to be done, you have to be careful about giving it to a squirrel chaser. They are masters of coming up with reasons why they should ignore their clearly-assigned task and why this other thing is more important at the moment.

Sometimes you cannot fix your squirrel chasers. It is worth it to try. Quite often reactive live operations people are squirrel chasers. They love the thrill of fixing things more than the fulfilment of creating new things. I have found that the best thing to do for squirrel chasers in the long term is a role adjustment, especially if they are amazing squirrel chasers and there is a great need for their skills.

A dog named cat

In the process of making your teams you are likely hiring people. You only have a finite number of time and tools in the hiring process to bring people in. Sometimes you may wind up hiring someone unsuitable. Despite advertising “looking for a cat”, and counting legs, checking if it has fur, and seeing if it has a tail, you might actually hire the wrong animal. Welcome to having a dog named cat. So now what do you do?

In some places, employment law gives you a thirty-day window to evaluate an employee. Unfortunately that is a horrible and cruel way to solve a problem. If you were trying to hire a cat and wound up with a dog, that is clearly a misfire on your internal tools and processes. What I prefer to do in this situation is to see why exactly we hired this person in the first place and what can they contribute effectively on a day-to-day basis. I have had great success in bringing people into teams where I discovered that they were not perfect for the position, and were a better fit in a different role.

Sometimes I have also been successful in helping transform their skillset. You originally looked for a cat and now you have a dog. That is okay! I have successfully turned dogs into cats and I am convinced that it is worth it for you to try if you are in this situation. Even if you are not successful it is a valuable leadership exercise.

The leaky tire

Finally I want to talk to you about one of the more difficult edge cases in team management: The leaky tire.

Sometimes you will have an individual on your team who has variable output week over week. You might discover eventually that their performance is directly correlated to the level of praise or visibility on their projects. A car with a leaky tire will require you to stop moving forward, get off of the road, pump it up as much as you can, and then get back to moving forward. A leaky tire employee is the same thing.

I struggle with this one because it is hard for me to relate to leaky tires. I always have intrinsic motivations for everything I do. I will invest a few months of time into a leaky tire and see what the ratio of time invested to output looks like. I still do not have a one-size-fits-all answer for what to do with a leaky tire. If I have to spend five hours a week with a leaky tire, that does not scale well. If I have to spend thirty minutes a week pumping them up, I can keep that up for a considerable window of time.

A leaky tire will sometimes maintain a steady pace. Other times, they will subconsciously realize you are giving them a steady amount of positive feedback and start to require more pumping up without realizing it. When I find that someone is an unstable leaky tire, the best thing I have done is to instill gradual self-awareness of the issue. If you tell someone directly they are a leaky tire, they are apt to blow out nearly immediately. The best thing to do is to introduce them to the notion by giving them an example and saying “Hey look at that person, they are a leaky tire” and wait for self-awareness to hit. Half of them will react positively to the indirect coaching, the other half will get mad. If you think you have the latter case on your hands, it is best to be surprised and then say “I never thought of you that way before but let’s work together to understand this better”.

I tend to spend a lot of time trying to address this one because leaky tires tend to be high performers when they are “on”. If you can make them aware of their leaky tire issue and get them to correct it, then you have helped to transform them.  This will accelerate their professional development tremendously!

So there you have five archetypes to watch out for on your teams. While not exhaustive, this is a list of engineering types that I have had the pleasure of helping over the years.

As always, thank you for reading. If you are struggling with managing some individuals and want to reach out to ask particular questions, I am always happy to help!

It is pretty easy to be mad while at work. I learned that early on in my career. Lots of things made me furious and I took it upon myself to self-righteously attempt to address each and every one of them. I cannot stress enough what a bad idea this is. Every once in a while you will take the thing you are angry about and wrestle it to the ground. The vast majority of the time you will be sitting alone in the burned out wreckage of the battle you just “won” wondering what exactly just happened.

I am about to share one of the biggest things I have learned professionally over two decades:

If you are going to be mad at something please be mad at the right thing.

Dear students, welcome to Compartmentalization 101.

Before I get into this I want to state that the vast majority of things that make you mad at work should not make you mad at all. I think that was probably the first thing I did wrong. I got mad at just about everything.

Don’t like other people’s buggy code? Get mad. Don’t like being told your feature is not a priority? Get mad. Don’t like that your recommendation to change to a more scalable server platform got rejected without justification? Get mad. You can clearly see the pattern.

Any time you find yourself mad at work, you probably should take a step back and ask yourself “should I really be mad at this?”

I assure you the majority of the time that answer should be a firm and resounding NO.

These days it takes quite a lot at work to make me mad at a situation or at a person. I will not say that it does not happen. Most of the time it happens I can catch myself before doing something dumb about it.

This is why I urge people to learn to compartmentalize their emotions at work. If you are going to get angry at work you should understand why you are angry and what you are really angry about.

If you can get to a solid place of self-reflection you will find that when you are angry at something at work you are often angry at the wrong thing. This happens quite a bit with customer service. When I have a problem with my bank or my credit card that makes me angry, I am very apologetic to the person on the phone because I want them to understand that I am not mad at them—I am mad at the situation. I think that so many people take out their frustrations on these poor customer service people that they appreciate the heartfelt acknowledgement and it feels like they are more willing and able to help me get to a good outcome accordingly.

So how can you find out what you are really mad about?

I am very sorry. I do not have any magical ideas here to help with that. It will take a lot of practice.

The best place to start is to take a look at things that you do while you are angry. If you can get in front of those with some self-reflection, that is a good first step. It is also a very important one.

If you are angrily getting into conversations or angrily writing emails, you are probably going to create drama, tension, and unfortunate outcomes—especially if you are angry at the wrong thing.

I find that the time I slip up with this the most is before I am done my first cup of coffee in the morning. I am not yet fully engaged with my plan for the day and not yet fully caffeinated. I try to spend the mornings doing a little information absorption from the world around me while getting started with my day, and it helps get me into a positive mental framework. Because I am reading and thinking, I am also not grumpily digging into things or starting angry conversations. If you find yourself starting off the day blowing stuff up all around you, I strongly suggest you consider switching your day to input-mode like I do.

There are two other things that I do that help me catch myself when I am about to do something angry.

The first is to start off my emails with something like “I apologize for the delay” or “I appreciate your time”. The cognitive dissonance of trying to write that statement while angry is nearly comical. The other one is to end as many of my emails as possible by typing “Warm regards”. It has the same effect.

The additional side effect of the latter statement is that people who receive many of my emails directly or indirectly will see this. At least once a year someone will notice when it has been omitted from an email and they know that I am in a place that is either concerned or angry. I appreciate hearing from someone when they see I have left off my “warm regards”.

It is harder to get in front of an angry conversation. Being able to catch yourself in the moment takes a considerable amount of self-awareness. I would say that there is some significant percentage of time that I do not realize I am in an angry conversation until after I have already started digging into something aggressively.

I generally become self-aware about it before the conversation is over and then I have to stop, back up, and acknowledge it to the participants.

This is another good thing to do. If you cannot catch yourself before doing something angry you should be able to catch yourself consistently in the middle of doing something angry.

I am happy to be on the receiving end of gentle mockery and good natured ribbing after having a mea culpa moment. If I can get to a place of saying “Hey folks, I just realized I am angry about this situation and I should not be. Let’s back up a second here and discuss what the problem is,” then I am more likely to get to a good outcome. It will certainly be a better outcome than if you get into a meeting, proceed to set everything on fire, and then storm out of the room smelling of tears and ashes. I, um, may know someone who was good at that.

So why is it important to process your anger in this way?

For starters, you are probably angry at the wrong thing. You just cannot see it because you are angry. I have found myself angry at people when I should have been angry at situations, and angry at situations that have been created by people.

Identifying what you are really angry at is hard. It is very easy to be angry at people. Ironically, the more easily you get mad at someone, the less likely they are the reason you are angry. Unpacking deeply layered sources of frustration is a fine art and even twenty years into your career you might not realize the grand sum of all the frustrations you are carrying. Quite often you are just lashing out at the most recent thing added to a giant pile of frustrations.

If you can get to the place where you can identify when you are angry at work, and then start unpacking the things you are really angry about, that is a good place to be.

In addition to being angry at the wrong thing plenty of times myself, I have observed it in other people and generally make an effort to unpack what they are angry about. I will try two to three times per person to try to help them see past that and unpack what they are really angry about.

Being able to reduce the amount of things you are angry about and the amount of times you are angry at the wrong thing is an important part of transcendent career changes.

I am grateful that I have grown past the vast majority of things that made me angry, even if it took me a long time to do that.

If you find that you self-identify with this post, you might have some of the same problems early in your career that I did. Now I will tell you why it took me a long time to fix them.

For starters, if you are angry about things, then people are going to avoid you. Especially if you are angry about the wrong things. You can swiftly make yourself persona non grata on your team by constantly lashing out and constantly blowing up. When I first became painfully self-aware of how much I was angry at random things, I was immediately irritated that no one helped me with that. In hindsight I understand it better because I had a very large blast radius. There was a high probability that someone trying to set me on the road to self-improvement would have accidentally set off some kind of chain reaction and have been on the receiving end of some of the damage.

The second thing to mention is that angry people are also very easy to manipulate into a box. The worst boss I have ever had was pretty good at yanking my chain and getting me to do angry things as a default behavior. While you always want to give your boss and your leaders the benefit of the doubt and do your best to do things to help, sometimes you find that out after the fact that you were being set up for failure to advance someone else’s goals. I have not ran into this many times in my career but I have ran into it enough times that I know it when I see it and I know to control my reactions far better when being told to go dance blindly in the minefield while other people are clapping and cheering.

So there you have it.

Please do not get mad at work.

If you are going to get mad at work, you had better be mad at the right thing.

If you are mad at work and mad at the wrong thing, you are likely going to find yourself lonely in the best case, and weaponized by others in the worst case.

I wish I had some more concrete steps to help you get there from here. There are so many things that happened around the time that I started calming down professionally that I cannot really ascribe causality to any one of them.

If you find yourself in this situation, you might find you are going to hit a professional ceiling at work. Of course the instant you get made aware of that, I am expecting that you will probably be angry, and probably at your boss who did not promote you.

Which begs the question: Did you even read this article?

Heyooo!

Please share this article with your friends. Especially if you think it will make them angry. 

If you just got this article from a friend and were angry at them up until this sentence, please send them a thank you note. They are probably trying to tell you something you don’t want to hear.

That is the article today. Over the past month I have managed to find another half a dozen topics working with a few people who have asked for professional mentoring. If this is something that you are interested in, please reach out. This is absolutely a shameless sales pitch.

Introduction

This week we are going to do something slightly different. I have a guest post written by a friend of mine, Steven Ramirez. We worked together at Zynga and I really enjoyed being his professional peer. I thought it would be wonderful to share some of his thoughts with you all.

Without further ado, heeeeere’s Steven!

Priority Ones All The Way Down

Let’s walk through a situation together.

After a long roadmap exercise, you finally get a chance to sit down with your team to plan out the work. As the friendly neighborhood project lead, you talk through the integrating Facebook auth to raise user conversion and the team helps break out the deliverable chunks. Milestones are defined and the team is excited to get started. All signals point to success!

Halfway through the project you realize that you are stretched thin. Integrating this new auth flow took longer than expected. Luckily, you thought ahead and prioritized everything so that features could be cut in order to hit your timelines. You go talk to your boss knowing that this would’ve happened and came prepared. But then they hit you with the words that make you go cold: “We need to ship everything so the company stays afloat.”

Hi, my name is Steven Ramirez and if you’ve been here before you are not alone. In software development the seedy underbelly people don’t tell you about is that everything must ship is a reality that you deal with sometimes. In 14 years of working on software, here are the guiding principles I’ve used to get out of these sticky situations:

• Weigh all the trade-offs
• Solve for the ask: Outcomes or Product?
• Smaller shippable pieces
• Work in parallel
• Bring in the cleaner
• Ship it today, revisit tomorrow

Let’s jump right into the theory and practice of it with this project below!

Weigh all the trade-offs

Theory

First and foremost, most projects have wiggle room for dates and deliverables. Software development practices like Agile have evolved to handle this kind of uncertainty. Building a shared understanding of the problem and trade-offs when making choices is a practice that takes work to get right and should be exercised when this type of scenario happens. What is important here is that you can present to your stakeholders a restaurant-menu-style list of choices that are succinct and clear. These types of choices should include:

• Goals
• What are the risks
• What are the assumptions
• What are the constraints
• Potential mitigations

With a good breakdown of this list, hopefully you can align on just what is possible and not possible. Another factor is being clear on whether choosing one option rules out another. 

Practice

An example of this looks like:

The best way to think about this is:

• Risks = Known unknowns that can cause your goal to fail and you do not know if they are true or not
• Assumptions = What is believed to be true to meet the deliverable
• Constraints = Time, budget, scope, and/or quality that limits the likelihood of success
• Mitigation = Options for removing the risk given the previous statements

Using this, you can work out with stakeholders what is possible and in what context. It’s like a game of Tetris in finding the correct blocks and rows in which you can reasonably work. What is important here is to truly understand what are “must haves” and what can wait. 

If all other options are exhausted and everything must still ship, try these next few exercises.

Solve for the ask: Outcomes or Product?

Theory

Depending on whether you are working on an outcome or a product, there is room for creativity. Outcome-based goals leave room for hitting them in different ways. You likely have a few options from previous roadmap conversations that can be looked at again for inspiration here. However, in cases where you must deliver a specific product, your options could be more limited.

Practice

Outcome-based goals

If an outcome for your team was to increase user sign-ups by x percent, and adding Facebook auth was a way to achieve it, then perhaps an ad campaign could be tried if it could be done faster and at lower risk. 

Product-based goals

You are working on milestone-based projects and have to show that you have integrated this social network auth to your business partner. In this case, you need to identify all of the high risk areas and proceed accordingly. 

Smaller shippable pieces

Theory

The bigger the deliverable, the more likely it will fail. Look again at what is being worked on and engage with your team on how it can be sliced and diced to be shippable chunks. Agile emphasizes this point for a reason.

If the size of the deliverable remains the same try seeing if technical milestones can break it down. 

Practice

Running this exercise with our project, you could:

• Identify features in the old auth flow that must be supported
• Create a new flow that supports this new auth as simply as possible
• Change the pre-existing entry point to use this new flow
• Port over the auth features that are required for this flow to work and no more

Once you have done this exercise, be sure to stack-rank deliverables in priority order. Lean on Agile practices and focus on finding what the smallest things are that can be consistently delivered. 

Work in parallel

Theory

If you can itemize your dependencies, consider relying on the organization to help you. If other teams have the skillset and staff for a deliverable, ship that work to them and track its progress. Coordination and communication with stakeholders will be key on making this work. The more you can do to minimize overlap here and keep people in sync, the better. One way to make this successful is to have representatives from teams tackling work sync on a cadence so that people are aware of status and blockers.

Practice

We identified that we need a new database schema. If we had another backend team available, we could have them tackle this work while our team works on the frontend changes. Teams should ensure there is a clear API contract between the frontend and backend while meeting a few times a week to go over concerns.

Bring in the cleaner

Theory

Avoid the Mythical Man Month, but see how you can staff things within your organization with subject matter experts who can hit the ground running. Think about pulling these people into one of the teams executing on the larger roadmap. This is usually senior staff with foundational knowledge and overlapping skill sets to what you are working on. When you are bringing these people in, be clear with everyone what the expectations are, what needs to be done, and when they can go back to their respective teams.

Practice

Looking back at our example auth project and database change—if a team was not available to help but a senior backend developer (or however many) was, then we can temporarily merge them into our team to help close out the project.

Ship it today, revisit it tomorrow

Theory

Products not shipped provide no value. Tech debt does not necessarily mean that the worst solution was decided, but that a choice was made given the constraints of that time. As the team makes decisions on what can be achieved, document the resulting tech debt and make it obvious to future developers that this must be maintained or replaced. When the software is revisited in the future it will be good to have the constraints and limitations well understood.

If the product succeeds, invest in solving previous tech debt for that product in the next iteration. If the product is not successful, consider removing that debt so that it does not come back to haunt you in unexpected ways later. In either case, it is best to make a decision and clearly document it such that future people can understand what and why those decisions were made and when they need to be addressed.

Practice

Let’s say we decided to do the new login through a forked code path with half of the features of the old flow—but we got it out on time and started seeing that our sign-ups went up a resounding 10x what we were expecting! Now all of the business stakeholders want to integrate more social networks! While we want to strike while the iron is hot, we do not want the tech debt from the old flow complicating future iterations. Now is the time to make the proper “fix” and refactor the legacy system. Luckily, the team documented the code with the understood limitations so that this next iteration can have the necessary context.

Wrapping it up

If you’ve made it this far, hopefully one of the above exercises has jolted your creativity and helped you be successful in these cases. All software development is about:

• Itemizing and understanding trade-offs
• Understanding what is truly desired
• Breaking out deliverables into bite-sized chunks
• Parallelizing work where you can 
• Start with what’s easy
• Realize what needs to be done now and what should be tackled later

Thanks for reading!

I have spoken in the past about how I value the Serenity Prayer and how you should use strength, patience, and wisdom at work. There is one more fundamental tool in my problem-solving toolbox that I want to talk about.

I recall back at my first job in California having a real doozy of a technical problem for which I simply could not find a solution. It was about four-thirty in the afternoon and I realized that I was not going to power through and come up with a solution in the next thirty minutes. So I got up from my desk, packed up my laptop, went over to my bosses office and said “I am going to go home and go to sleep”.

That might strike you as an odd thing to declare to one’s manager before five o’clock. I will say that he clapped his hands excitedly and wished me a good evening. At this point I had worked there long enough and had done this enough times that he understood that sometimes the best way I solve a problem is to go and think about something completely different or perhaps think about nothing at all.

Welcome to orthogonal thinking. There are a lot of studies coming out about the nature of software development and knowledge work. I think more and more companies are learning that longer hours do not always yield better results. The longer you work creating software systems the more you realize it is not a completely linear process like building cars on an assembly line. Sometimes you need to make non-linear intuitive leaps in order to get to a fully finished product.

So why does orthogonal thinking work?

If you are creating software systems, you are generally managing a mixture of constraints and emergent complexity. There are things you learn in the process of building that did not manifest themselves in the process of design. There are constraints, platform issues, bandwidth limitations, and data quality issues.

The more you run into these, the more clever your software design needs to become. Sometimes there are non-obvious ways to simplify the systems you are building and it takes some time to absorb the new inputs in order to fully process the shape of a solution. The best thing you can do is park it in your subconscious and wait for that absorption to be complete, or perhaps wait for a leap forward that occurs during a moment of inspiration. The more intensely you work to solve a problem—commonly referred to as “tunneling” on it—the less likely you will be thinking about it in larger or more abstract terms. You will find that systems that do not benefit from this kind of emergent discovery will likely be the biggest source of pain in a large software project.

So what can we do to create orthogonal thinking opportunities? Here are some common things I do to mentally unlock a solution when I get stuck in a problem.

Rubber Ducking

Rubber ducking is a term by which you describe a problem to a rubber duck(real or otherwise) in the simplest terms possible. I know that sounds strange. Sometimes I will ask a coworker to be a rubber duck for me. I get extra mileage out of trying to explain a problem in simple terms to another person because they ask me lots of questions that I need to answer so they fully understand it from their point of view. Rubber ducking distracts you from staring at the problem too much and rat-holing due to your own perspective. Sometimes hearing people asking me questions about my problem will trigger a flash of insight and give me some great ideas.

Doing other work

Second to explaining the problem, sometimes I will just stop working on it entirely. It is like when you forget the name of an old TV show while talking about it to someone and then thirty or forty minutes later the name suddenly pops into your head. I could not speak to the science behind this but I know this works for me in solving problems. I park it in another part of my head and start something else while the gears of my subconscious grind away at a solution.

Turning it all off: First edition

There are a lot of flavors of this and I will talk about three of them. The first is to play a video game or open a book. I prefer getting away from the computer and reading an actual book when I need to disconnect and think about a problem, but popping open a game where you have some sort of sublime activity that puts you into a state of “creative flow” will also work. For me, that default computer game is Minecraft. I like to start a new world, find a really tall mountain, and fuse a multi-layered dwelling into it. It is a low-intensity, pleasurable cognitive project that lets me consider problems in the abstract.

Turning it all off: Second edition

The second thing you can do is to get away from your computer and go outside—ideally taking a walk for more than half an hour. Getting physical separation and bombarding your senses with new inputs, sights, sounds, and smells will help get some separation from the problem. As an added bonus the exercise is probably good for you. I will sometimes pair this up with Rubber Ducking, either via a phone call or bringing someone along to talk to while walking.

Turning it off: Third edition

The third thing I do is to shut it all down and go take a nap or just flat-out go to bed early. When I have a difficult task where a novel solution is evading my grasp I will go to sleep thinking about it. It might sound weird to dream about work but I will wake up and have a pretty good solution most of the time.

I know this is a shorter article than most, but I think it is a powerful one. There are a lot of conversations about crunch in software development and how it is harmful to people. I do not think that enough people measure the impact of crunch on the product. I think that unmitigated crunch is unfortunate and also can create substandard software. I believe in cognitive diminishing returns—and taking a break from a problem is sometimes the best way to solve it more effectively.

The next time you find yourself stuck with a work problem, I encourage you to try out some of these approaches. You might find that some are better than others for you.

Thanks again for reading along! I hope you enjoyed this article or learned something from it. I am going to avoid asking for clicks, sneeps and twikbooks this week to see if you do it on your own. Thank you for indulging my anti-pattern and not making me ask for some sort of social reciprocity.

So last week I wrote a quick cheat-sheet for how to conduct an engineering manager interview. I used the words “engineering leader” interchangeably with “engineering manager” in the article and I did it on purpose. There is another kind of engineering leader to consider and today I am going to write about it.

Imagine having a cool startup idea—not like your regular Thursday “this is a cool idea” idea—that makes other people nod and stare into the distance thinking “Wow! That is a cool startup idea!”. You take your idea and you have enough social capital to get a meeting with a serious investor. The meeting is going really well. He actually puts down his phone to listen to you. He is engaged and has interesting questions. He is leaning in as he can see a new product or service that can scale and the two of you really like each other. The excitement is palpable. At the end of the presentation he asks two really solid questions that lead you to believe that this is going to be discussed on partner-Monday at his firm next week.

Then he wants you to flip back to the team slide for a moment. He leans back ever so slightly and asks “Who is going to be your CTO?”. There is a momentary pause before you say “I do not have one yet” and before you can add anything else he has reached for his phone and is getting ready for his next meeting.

I hope this never happens to you. If it was about to happen to you, count yourself lucky you are here. Today I am going to give you a primer on how to hire your CTO, or architect.

A CTO means many different things to many different people, especially to investors and to company leaders at various points in a company’s life cycle.

For most startups, a CTO is “the most senior coder we could afford at the time who is willing to create interfaces and write documentation”.

For companies at a later stage, a CTO is “the person who can negotiate the product roadmap between keeping legacy code working and growing, and adding new features at a rate that keeps forward momentum going”.

For a public company, a CTO is “a talented engineering leader who can communicate with the board, the rest of the C-staff, set technical direction, and respond to technical and governmental policies that impact the day-to-day operations of the business”.

Finally for struggling companies, a CTO is “the engineer with the most amount of tribal knowledge who we promoted to CTO so they don’t quit, leaving us with a site that no one understands”.

When you are hiring your CTO you should understand what you need and why.

Here are some of the common responsibilities for a CTO.

APIs and Interfaces

Creating systems that are usable, re-usable, extensible, and maintainable is really hard. There are so many shortcuts you can take to get in front of customers that each introduce their own flavors of pain, from increased cost to decreased performance at scale. Navigating those waters and making a system that you can grow with and give to other people to use is a challenge.

Documentation

Whether it is something for the board, the customer, the team, or even yourself, you should get a CTO who can present things in writing. Bonus points if they are good speakers too but at the very least they should give you a usable diagram with the cloud bubble and the database cluster in it that represents what it is that you are using and/or building.

Technology Platform Choices

Are you on AWS? Are you using Go, Java, or PHP? What operating system is needed for development? What tools are needed for deployment? There are many factors that play into choosing your technology stacks and this should be one of the duties of your CTO. There are many people who will advocate for a particular language because they are familiar with it. Sometimes it is the wrong choice for the business.

Buy vs Build Decisions

Similar to the languages and technologies being used, your CTO should be able to look at a product in the marketplace and the size and budget for the engineering team and make a decision whether or not to spend X dollars or Y months of time to build something. At the very least they should be able to present realistic arguments for why it is important to the business or what risks are entailed by going one way or the other.

Operations and Infrastructure

Choosing where to host your applications or what devices to target comes with risks. If the marketplace being addressed is all android phones, or all mobile phones, what features are not supported on older handsets? What are the different problems created by using AWS vs Google Cloud? What is the cost of your partnership there? What kinds of lock-in to your partner are you accepting by using them and their various flavors of exclusive services?

Research and Development

This is the best and the worst part of a CTO role—managing the business risk. Are there new technologies being created or developed? Does some complicated math need to be used to create a new library? Are there new hardware or software packages to be looked at to help find the product-market fit for your business? Tinkering with technology is a wonderful pastime. It is easy to get lost in solving academic problems and coming up with cool new systems and tools.

Technical Roadmap

As you build your business, what are some of the legacy decisions that need to be revisited? Are there old systems you have purchased that are past their end-of-life? Do you have older systems that are slowing down new feature development? Did something change in the usage pattern for your business such that previous assumptions need to be reconsidered for what storage to use?

Due Diligence

If you are looking at using technology, acquiring talent, or flat out buying whole businesses, who is looking under the hood? Does the data they use to facilitate a business transaction hold up under scrutiny? Is their software homegrown or cobbled together from other systems? Does it have security risks or is it functioning poorly under heavy loads? Usually half of the people who are open to selling their business have peaked in some fashion and are trying to make the prospect of acquiring their business or assets look more attractive than it really is. Finding that inflection point where things are about to slow down is key in order to make sure that you do not overspend on an asset that is not growing or scaling as projected.

Intellectual Property

What happens if your data warehouse gets hit by a meteor? How fast can you get back to servicing customers if the servers are suddenly turned off? How are you protecting your intellectual property from theft or replication? Are any of your ideas patentable? What security measures are put in place to safeguard your customer’s trust?

Compliance

Do you have GDPR compliance for Europe? Do you conform to California’s new data privacy laws? If you are giving away chances to win things, are you falling into gambling or lottery laws? Are you collecting PII from your customers? Are you looking to increase your PCI compliance for the purposes of deepening your payment relationship with your customers?

It seems like a large list of things to cover and it is hard to find people who have done all of these things. Here are some questions you could ask while you are hiring your CTO.

What is the difference to you between a CTO and a VP of Engineering?

I am deliberately not going to answer this question. You absolutely should ask the candidate this question. I have seen a VPE act as a CTO and a CTO act as a VPE. You will likely want to hire one and assume they are going to do the work of both because those gosh darned engineering leaders are expensive. It is rough to hire one who is also going to be doing the job of the other. They have very distinct responsibilities in the long term and you should be comfortable with that. If you do not know the difference between the two, this will be an educational process for you too. If this fills you with an overwhelming existential dread then reach out to me privately and I will give you a more direct answer.

What language do you like to use when starting a new project and why?

This gets back to the personal choice question above. There are times when you choose a language you love and there are times you choose a language that other people will love more. Do you want to hire lots of people fresh out of school? You might want to look at what modern languages they learn. Are you building mobile games? You are likely to want to use Unity or Unreal Engine for your client to make the cost of supporting Android and iOS more bearable. Pay close attention to what languages they love and why. I have built stuff in C#, Java, PHP, Go, C++, and a myriad of other languages—each for different reasons at different points in my career.

When you are joining a team with a project in flight what are the first things you want to know about it?

This is a little bit of a softball question. Ultimately you want to know how many times the candidate has joined a team mid-flight. If they do not have questions here it means they may not have had to join an existing project, and usually not one in crisis. I have my own battery of questions that I love to ask people when I join an organization.

Why would you use document storage vs relational database storage? Which flavors of each do you prefer?

Oh the joy of discussing NoSQL and SQL! It is such a fun conversation to have with people and everyone has their own opinion on it. There are no right or wrong answers here. Okay that is not entirely true. If you are dealing with customer payment transactions, you probably want to store stuff in a relational database. There are whole companies and communities that exist to argue the pros and cons of what kind of storage to use and when.

Design one of the following connected systems for me at a high level using a whiteboard: Authentication, Payment Flow, Chat, or Presence.

If you are building online services, your CTO had better have built one of these in the past. If you are building client only technologies there are similar systems you can whiteboard out. You should not necessarily expect someone to get a perfectly functional solution in twenty minutes on a whiteboard, but they should cover all the relevant storage pieces, data transactions, and also speak to what the requirements are. I have been asked in broad terms how to set up all of these things at one point or another in my career.

What is the hardest technical problem you have ever had to solve?

This is another softball question. The hardest problem I ever had to solve happened so early in my career and is so arcane that is essentially irrelevant in today’s world. However it was an interesting business problem and an impossible hardware problem, which is why it is the story I tell people when asked. A lot of people really struggle with this question because it is so vague. It is by design because I want to look at the shape of the answer. Did it scratch their curiosity itch? Did it save a company money? Did they unlock a new marketplace? What was the outcome of their solution?

What is something you wish you knew when you started your career?

Most engineering projects are a collection of hastily made decisions and huge enablers of massive hindsight. It is good to listen to things people have learned along the way. I often want to know this from someone so I can figure out what their biggest regrettable moment was and how they have grown from it. I know the two or three things I would tell younger John Szeder. I suppose it is actually a pretty big list but a couple things really stand out for me.

How do you learn a new language?

This is an important one for me. I struggle with recruiting leadership that does not possess professional curiosity and a love of learning. I hope everyone is trying new things all the time— that is how growth and abundance happen. If you are not looking at new technologies or trying out new ideas or tools, you are at risk of suffering skillset obsolescence in a decade or possibly less.

Tell me about your current successor.

Finally, and most importantly to me, is the need to know you are preparing for the day that something happens—either a promotion, or a change in career direction. Can you leave the organization in capable hands? If you are grooming a successor and comfortable talking about it, that is a measure of confidence and ability I respect. I always try to find one person I am grooming to fill my shoes at any given moment, sometimes multiple people. There are risks and challenges with having multiple successors—they all want their moment in the sun. It is possible you can set a group of talented peers at each other’s throats if somehow they think that succession is a zero-sum game.

That is a lot of questions and each tells me something interesting about a candidate.

One of the biggest challenges with this whole process is that you probably do not have all of the tools to properly validate all of the things your candidate is telling you. Here is a set of terms to look for when you are having conversations with a potential CTO.

Trade-offs

This is the biggest thing I want to know about a CTO or an architect. Are they looking at the Total Cost of Ownership (TCO) of something? Did they look at all the vendors? Did they measure the time versus the cost of different partners and tools? Every choice has pluses and minuses. The ability to measure the trade-offs before making an informed decision is really valuable to me.

Technical debt

Everyone hates this word. Your CTO should have some experience with managing technical debt. Every large scale business has it and everyone has a method for mitigating or reducing it. If you have a CTO candidate who cannot speak to their experience in managing technical debt, I would be very worried.

Refactoring

Another dirty word. Almost every software system is built out of a design that existed before a product-market fit was found. When the system is live it often requires changes that do not fit within the existing structure.

Refactoring is an often maligned but very healthy part of maintaining software. If you are not updating your systems regularly then you risk having a bloated pile of unmanageable software within the next four months to ten years.

Deprecating

Turning off a system is sometimes impossible, especially in a SAAS world. How are you managing old systems? How are you mitigating the risk of old deployments? Managing the lifecycle of old systems and sunsetting older APIs and servers is important. The more you maintain full backwards compatibility on systems, the more drag you are creating on forward momentum. There is always a moment where you sit down and say “this is where we draw the line”, whether it is every week, every quarter, or once annually. Making a software system deprecated means it is still live and not fully supported. It is a key step to deleting or obsoleting a system. I consider it a deep-orange flag if someone turns off a system and says “it is deprecated”. It is an important thing to know and I have caught people saying this incorrectly.

Recovery

How long does it take you to relaunch your service after a catastrophic event? How long does it take a developer to get a fresh laptop after theirs gets filled with coffee and rendered unusable? The ability to recover things and get going quickly is very important in the modern day SAAS world. Whether it is time to push a build from a fresh laptop, to how long it takes to service a customer on a freshly spun-up cloud instance, this is an important thing to talk about.

Learnings

Another thing I want to hear in response to my questions is what they learned along the way. “Profit from your successes, learn from your failures” is a nice mantra. If you are not learning things from your mistakes, you are likely to repeat them. I need to find evidence of learning from failure through the interview conversation.

Compliance

This is an important one for legislated industries or public companies. Being able to navigate the compliance processes for your business is hard and takes a specialized skill set. You need to be able to gather requirements, negotiate with stakeholders, demonstrate functionality, and triage failures. Every part of that process requires care, especially as you add zeros to the size of the business.

That should be a good framework to help you evaluate potential technical leaders, whether CTO or senior architect, for your company.

My final thought on this matter is that this is something you can get outside help with. There are lots of people out there who can assist in reviewing the qualifications of a potential CTO and give you the upside and downside of a respective candidate. You should always balance getting a formal assistant in reviewing their qualifications against your own gut feeling. If you get a strong signal from an external candidate review and you have reservations or you get a lukewarm assessment but you really like the candidate, you should understand that you will be living with this person day in and day out as you build your company together. Ultimately that should be the filter that you apply to this whole process.

And here we are at the very end of another article! I hope you enjoyed it, or learned something from it. Maybe both? I value your responses and questions every time I write one of these. Please keep the comments and feedback coming!

I have recently had a number of conversations with friends who are on the prowl for new roles given that we are coming out of the end-of-the-year review cycle. I could not help but notice there was a pattern to some of the questions and responses. As a result, and to help prepare you for those kinds of conversations, today I am going to talk about what someone looks for when they are interviewing an engineering leader.

When I am interviewing someone to join my organization I have a standard set of questions that I use. It turns out that I am not alone in this. Each of these questions is designed to tell me something about the candidate. I have seen candidates who realize they do not have a good answer for some of my questions. That is okay. Not having a perfect answer to all of my questions does not disqualify you from your candidacy for the role—it tells me how much work we need to do together to get you to address any gaps that you have to be really successful if everything else is in alignment.

So let’s start going over them.

How many people have you managed?

This question has two parts. I deliberately leave it as a one-part question, to see if they understand it is a two-part question. I want to know how many people someone has managed directly, and how many people they have managed indirectly. If someone supplies the answer in that form, that makes it clear to me they understand multiple levels of management and have participated in it. If you have managed a team of 30 people through 4 direct reports, that is very different from managing a team of 7 people who are all direct reports.

How many managers have you managed?

This is a question that flows naturally from the previous question. I want to know what your experience is at managing managers. It might sound silly but if you have more than 10 people in your organization and you are not breaking that up into groups, that gives me a lot of things to think about. Either someone in your leadership is not setting you up for success, or you are having some kind of other problem. I want to understand what that is. Managing managers is a very difficult skill to master. You have to have the right amount of trust in people to let them make choices, even if they are not well thought out, in order to see the outcomes and adapt to them.

How many managers have you created?

This is really what I want to see in a successful engineering leader. Have you successfully created an engineering leader or manager? Taking someone from being a rank and file individual contributor role and retraining them to learn the skills to manage or lead people is an important professional transition to make. I used to do this in previous companies instinctually. When I was at Zynga, I wrote down all of the steps I took with new first time managers and we turned it into a multi-week conversational boot camp.

How many managers have you promoted?

This is another logical extension from the previous question. Not only do I need to know that you can manage people successfully and transform them from individual contributors into managers or leaders, but can you also convince the rest of the organization that they are growing well enough to get promoted?

Promoting managers is a sign of having a growth mindset. I have seen far too many leaders who create an organization that delivers to the company at the cost of slowing or inhibiting the career goals of its anchors. I do my utmost to take my direct reports on any team and open the kimono to them about my worries and my goals so I can prepare them for the day they transcend their current role and take over a role at my level.

Have you ever had to fire anyone before?

I hope this question does not seem odd to you. Management is mostly about how you handle the extreme cases on your team. What do you do to encourage and grow your top performers? Also, how do you handle people who are performing poorly or participating in incurable, destructive behavior?

This is a horrible skill to have to learn and it is time consuming to teach to people. I do like to make sure all of my managers have had conversations about what this process looks like from start to finish before they ever find themselves in need of having to terminate an employee.

What time frame is suitable for handling a struggling employee?

Every person and every company has different rules for handling how employees struggle. Sometimes people are not performing well. Sometimes people are breaking things for everyone around them. There are very few things that people do that breach trust so completely that it requires an immediate termination, but it does happen. How many times do you try to help someone before it is past the point of trying again? There is no clear answer here. I have done my best to give people three strikes except in extreme situations.

What is the largest production issue you have ever had to manage?

This one comes slightly out of left field and might be more suitable for producers and product managers than engineering managers. Sometimes you learn something interesting based on how they define “largest”. Are people concerned about the volume of users affected? Are people concerned about the cost of an issue? Are people worried that there was a loss of profit? I am more looking for how they framed the term “largest” than anything else here. I want to know what their default behavior takes them to for measuring the impact of a crisis.

Describe the best person you have ever managed.

I am very clear in asking that I do not necessarily want this person’s name, but I want to know why they were the best person that you managed. I listen carefully for the terms they use to describe them. Quite often people try to give this one a pass, or sometimes even want to talk about multiple people. I insist they narrow it down to one person and tell me the most interesting things they can.

Where is the best person who ever worked for you now?

This is a follow up to the previous question and I will state that people react viscerally to this question if they do not have an answer.

I still keep in touch with many amazing people I have worked with. If you take anything away from this article, please set up a 30-minute meeting to reconnect with someone you really enjoyed working with.

There is an old saying “the devil you know is better than the devil you do not know”. I feel this is true. I am constantly hiring new people and adding people to a large and growing pool of people I would love to work with again.

One of the big things I look for is people to bring their existing network power as managers and leaders as a force multiplier to my own problems. This happens less than you would expect. I do my best to help promote my current employer to people I love and respect, and I try my best to find new roles for those people when they need them even if my company is not currently hiring for their specialty.

A lot of people do not value their existing network power as much as they should. I will often ask this question and it will create a momentary panic in a candidate when they realize they do not know where the best person that worked for them is today. That is not the goal of this question. If you find yourself asking this question and catching someone off guard, I recommend changing the subject and talking about something unrelated for a few moments to give them a chance to recollect their thoughts and continue.

Describe the worst person who has ever worked for you.

Similarly to the previous question, I am looking specifically for the attributes that made this person the worst person. Naturally, I do not follow up and ask where they are now.

Tell me about your proudest professional accomplishment.

After putting someone through the ringer on management questions, I generally toss them a softball question to let them bring it all home. If they need a few moments to think about this I will tell them my own proudest moment story to give them something to think about.

What questions do you have for me?

Finally, I try to give the candidate ample time to ask me questions. For a leadership role I generally expect questions. If there are no questions I will ask why not. In the past I was recommended to roles where my friends are working. I have stated that as a reason. “I was recommended to this role by a trusted friend and I have no questions accordingly.”

You might note from these questions that I am not asking a lot of architecture or problem solving questions. I typically partner up with someone else to probe domain-specific knowledge. These questions help me assess whether or not I have an engineering leader who can manage people, or if they are more focused on developing their individual technical leadership skills. There are a handful of candidates who excel in both areas of career progression (technical leadership vs people management) and I want to make sure that I have a full picture of what their experience is and where they can go. Sometimes I will find people who have not yet managed managers, but want to add that to their skill set. If that does not work out I want to make sure I have a different role to offer them in case we are not succeeding together.

When I am on the receiving end of this interview, I will note the shape of the questions I am asked because it will tell me about the problems I am being hired to solve, or at least about the perception of what those problems are by the people doing the interview.

I set up all of my hiring processes with a standard pool of questions to break that pattern. I strongly recommend making a standardized hiring process to every hiring manager I speak to. Especially if you are hiring for a large number of roles.

So now you know just about everything I think I know about interviewing managers.

I hope you find this interesting or useful. I have recently had multiple conversations on career direction with former peers whom I respect greatly. If you have questions or concerns about where you are in your career, I am happy to listen to them and see if I can give you perspective on them.

As always blah blah blah social, blah blah blah gratitude.

I look forward to writing again next week!

Making consumer products is hard. Making games is even harder. Quite a few people play games and have so much fun that they can imagine making games is some kind of super easy dream job. It’s not. Today I am going to talk about one of the things I learned to help me craft more enjoyable products, whether they are games or just applications.

I want to talk about watching strangers touching my stuff.

Half of the fun I have at work is finding irreverent ways to describe things, and this is certainly no exception.

I will start by taking us on a trip back in time to 2001 when I started making early mobile games for feature phones. Making phone games in this era was a wonderful experience. You had some of the user constraints of early computing platforms from the 1980s and early 1990s, with all of the tools of convenience of modern-day software development tools.

During this era I had the pleasure  of meeting many of the early game industry pioneers who crafted game experiences that helped propel me into a career in games. Developing experiences with input and output constraints is one of the experiences I really came to enjoy during this era. It was also one of the places where I learned a great deal about the craftsmanship needed to create top-selling software.

It goes without saying that I was having a lot of fun quickly making multiple end-to-end games. Some of the development cycles were only weeks long. Some of them were months. Starting a game project and quickly shipping the end product was a nice feeling. It was also a great opportunity to learn how to make things better.

I had my own little studio in the middle of nowhere when I was building my games. I would frequently talk to people in coffee shops and at conferences about what I do. I was The Invisible Man of the games industry. “You made which games?” people would ask me as well as “Where can I buy them?” I was eighty percent product developer and twenty percent salesperson and trainer. I was curious about the consumer side of the business I was working in. I would shamelessly ask people in meetings or on commuter trains what game they were playing. There was a nonzero number of people who were playing a game I was somehow responsible for putting into their hands. Some of my games came preinstalled on phones, and others were even featured on the front box of the handset. I checked off quite a few of my bucket list items for professional game development in the span of half a dozen years.

There were also some awkward moments. Early on, people had no idea how to play games on their phones. I was often in the process of trying to have an excited conversation with a complete stranger about making games, and I would put a test phone into their hands to give them something to try. Half of this was me looking for some sort of validation, the other half of this was me doing some super cheap focus-group work on products I was building.

I learned something very interesting doing this. People would subconsciously recognize that I was looking for some sort of positive feedback from them, and then figure out the fastest way to provide that. When confronted with a feature phone game, there was generally a lack of a clear path to a “oh this is cool” reply from the moment I thrust the device into their hands. So the vast majority of people naturally did the same thing—they did absolutely nothing.

It was disappointing and sometimes awkward when it happened. I realized that it was a pattern of behavior and that there had to be something I could do about it. I began to experiment with the initial user experience and learned some very important things that are more design related than engineering related. I am going to go over them here because it is valuable to have some of these guidelines if you find yourself building software for other people, especially if it is consumer software.

Jiggle the gems

One of the first problems that early mobile phone games possessed is the introduction screens. Many games just sat there with a small assembly of words and maybe if you were fortunate there were some images.

While “Start the game” was presently the selected menu option, hardly anyone could figure that out the first time they were experiencing this, even if it was outlined in an ugly, green, two-pixel box. Early casual games suffered from a variant of this phenomenon too.

The best way to get people to do something within a digital experience is to intermittently give them a nudge towards action. I think that Bejeweled was one of the first games where I witnessed this. If you were frozen long enough on a screen, it would subtly jiggle the gems to let you know that you had a valid move you can make. I did a variant of this in many of the mobile games I worked on, including having the start of the game being a wobbling “PLAY NOW” banner that generally gave enough reinforcement to the average complete stranger that it broke through the freeze reaction.

Get them inside quickly

Any of you UIUX types out there are probably snickering by now. I am somewhat going through “Product Experience Design 101”. Your guffaws are merited. I started doing this early enough with small enough teams that we ended up lacking formal designers. We had to make up a lot of this stuff as we went along.

While the first game I ever shipped met the modest goals I put in front of it, it failed to really thrive as a product. I think one of the cardinal sins I had there was that I put in a massive 10 page intro story without a skip option.

While “Portals of Arnak” was planned out as this first game in a three game series that told an interesting story, the subsequent sequel was massively scoped down and the ultimate conclusion was never developed or released due to a lack of sufficient demand.

The more buttons you have to push before you get to do something fun, the more likely you will lose a player. The industry term for this is “friction”. My first product had excessive friction. Some of my best-selling games were ones where you had as few clicks as possible between “start the game” and actually, you know, starting the game.

It is important to get people started on doing things fast. If you do not engage with them very quickly, they are likely to wander off and start thinking about something else or, even worse, start doing something else.

Play though the tutorial

I attended a GDC presentation one time where the developer started off talking about how you start playing World of Warcraft and you essentially have one button to hit at level 1, and your first job is to Kill Six Wolves. You jump into the action and start mastering the verbs and nouns of your play experience in this new space very quickly.

He then put up a picture of the UI for an endgame raider, with all of its tricked out add-ons and rows upon rows of buttons, juxtaposed against the cockpit of a commercial aircraft.

Players are so subtly ramped up into sophisticated endgame players that you do not realize that the tutorial for World of Warcraft is wedded into the game itself. You learn to do simple things quickly and your mastery of new skills is curated and broken down into bite-sized chunks of mechanics that are layered in on the leveling path.

This is counter to some of the frustrating social games tutorials. Many of them create a tour guide of the experience that is largely driven by an arrow that shows you where to click for each thing you are supposed to learn. The “follow the arrow” tutorial generally goes on to do this several times, increasing your speed at clicking on the desired button without necessarily increasing your knowledge of the reasoning or the outcome.

Eventually you get really good at “follow the arrow” and really good at clicking on stuff quickly. Generally the “follow the arrow” game disappears completely at this point and you are left in a foreign game with minimal retention of all the stuff crammed into the tutorial. This is a suboptimal outcome for a consumer. I had to evaluate ten to twenty games like this each week for part of my job once. Doing this many “follow the arrow” tutorials was an inescapable circle of hell I would not wish on anyone.

These are some good rules that apply to all types of application software development: Games, consumer applications, and tools. Maybe they now teach that to the kids these days. I hope that they do. I had to figure these guidelines out on my own and you might notice that these principles are at work in some of your favorite software applications.

This is coming up because I run into these issues on a daily basis at work. I am also working on some web-based applications for consumers and prosumers as a weekend hobby. It stands to reason that other people might have some of the same problems, and should consider some of the same guidelines and approaches.

If you are building software for other people like I do regularly, I encourage you to give it to strangers and to watch to see how they touch it. If you learn anything interesting I would love to hear you talk about what you learn!

Thanks again for reading along. The bucket of unwritten articles continues to empty at a steady pace. I will do my very best to refill the bucket with verbal chum so you continue swimming along with me.

I also want to thank those of you who do reach out to me directly for deeper dives into these topics for your own education or benefit. It does happen and I do love the dialog immensely. For the rest of you, I hope you can reciprocate the time you spend absorbing this vast assemblage of vowels and consonants with a like, or a share, or a retweet.

Heck, I will even take one or more emojis in the comments if that is all you have time for!

I am starting to reach deeper into the trough of words to find stuff to put here. I will be panicking in a month. It has been a long, crazy journey so far and I am very glad you are coming with me.

Today we are going to talk about delivering feedback. Every time I talk about feedback I put my hands together calmly and say as smoothly as possible “feedback is a gift”. While it has a soothing effect on other people, I assure you that I do this largely for my own benefit.

So let’s talk about how to give feedback to people who are doing something… unfortunate.

Before I jump in, I do want to state that these are things I have learned by poorly delivering feedback to others in the past. You should be sure to have a few conversations with people before delivering feedback that might have an impact on their careers. You might wish to discuss it with your manager and your company’s human resources department. If it is regarding unfortunate behavior that is terminal to their employment terms, you absolutely should discuss it with your company’s legal representatives.

So here are some things to think about for giving people the gift of unfortunate feedback.

Be Compassionate

When you are talking to people about problems or issues, please be kind. They may be going through things they have not disclosed to you for whatever reason. Often they may wait until they get called to the carpet before discussing unrelated drama that is affecting their performance because they are just hoping that the problem goes away and they can just move on with their lives. It is natural for people to want to avoid confrontation and challenges, and you should give them space and time to come to grips with that.

Whatever it is that is happening, make sure you listen to them fully and hear their side of the story. Sometimes people are going through a rough patch and need a little time and empathy. If this is happening, try to be helpful and supportive as much as possible.

Confidential Conversation

Any time someone does something bad, you should make sure you have a private conversation with them about it. Outline what the issue is or what the behavior was. It is important to communicate what you perceive and what your concerns are.

Make sure you describe what happened, and also what your expectations are. If it is around quality of work or professional conduct, you likely want to make sure you explain it in those terms.

You might be informed about people’s personal issues when trying to understand what is impacting someone’s job performance. It is a good idea to keep this in confidence as much as possible.

If they have a medical condition that is affecting their work, this is a conversation that should be taken to human resources. It might be the case that someone needs special consideration as a result of issues or treatment, and it is in everyone’s interests that this gets discussed and any compassion time taken gets set up officially. As their manager, you should be telling people that they have an accommodation for their issues and that we can be appreciative of it without disclosing any of the details.

At some companies certain situations might cause you to be concerned about having a fully private meeting with someone because it could then become about your word versus theirs. In these situations, it is good to discuss with a human resources representative present.

Time To Cure

Make sure you are giving people time to address issues or concerns after you have identified them. Make sure you clearly identify the time frame and the changes that need to happen for someone to be successful. If they have only five days to fix something then tell them they have only five days to fix something.

Be very explicit about the issue, be clear that everyone wants a positive and productive outcome, and be clear that there is still time to fix things and move forward. 

Written Confirmation

Sometimes things go so far that it is time to make a change for the team that impacts someone’s career up to and including termination. It is unfortunate, but sometimes that is the unavoidable outcome. When this happens it is most ideal to keep a solid documentation trail about ongoing conversations.

In the past, when human resources and legal counsel has gotten involved in handling unfortunate situations, I have been consistently asked for all emails and written documentation about the individuals in question to summarize where we are.

Emails and written documentation give you clear timestamps on communication, and can help make it clear if expectations are not being met, and that everyone has done their best to get to a good outcome.

If you have not done your part in keeping written conversations, you might have to add multiple weeks of time while you document everything and share it with your human resources and legal partners. If this is your first time going through this process, do not be afraid to ask them for help in proofreading or even writing some of these communications. They are specialists in this area!

If you are on the receiving end of one of these emails, please understand that you might be doing something that could affect your job. You should figure out what you can do to fix the problem and make it clear you are doing your very best to do so. It does not hurt when you get to the end of a situation like this to have a follow up meeting where you confirm with your manager, or perhaps with human resources, that the issue is fully closed and everyone is satisfied.

Pattern of Behavior

The conversations that you have with people, and the written feedback you give to them, may feel terrible. If you are on either end of this kind of conversation right now, you have my sympathies and I hope it gets better soon.

After seeing a series of issues, especially related ones, I make sure to discuss with the individual that they have a pattern of behavior. It is easy to fix a one time problem. It is much harder to fix a pattern of behavior.

If someone informs you that you have a concerning pattern of behavior at work, be mindful that this is a dangerous place to be and it might mean you should be thinking really hard about fixing your pattern of behavior, or working on your resume—possibly both. If you cannot get it fixed to the point that people are satisfied, it is generally considered acceptable grounds for sending you off on a new adventure elsewhere.

Three Strikes

This is a big one for me. I hate firing people. I am very big on supporting people in being successful in their roles, and if they are not in the right role, then I will try to address that. That is a process that can take some time.

When someone is struggling in a job and they do not have the right role for their skill set, I will have a conversation with them about it.

If it keeps being a problem then eventually I accept there is not much I can do anymore and acknowledge that we all tried our best to make it work together.

Generally speaking I do my best to give people three strikes. I think it is a fair approach to make sure that I am also spending sufficient time with the people who are excelling in the organization to keep them growing and moving forward.

Tell Me What You Learned

I deliberately put this point out of order.

When I am having a meeting with someone and I am concerned that the issue is not fixable, I will present them with my concerns, their behaviors, and my expectations.

Early on I discovered a way to get some early indicators about what will happen next.

At the conclusion of a private meeting outlining expectations I will ask the individual “Please tell me the most important thing that you are taking away from this meeting”.

Sometimes you will get a hopeful response out of the individual about wanting to fix things. Sometimes you get a frustrated reply that they acknowledge there are problems.

You might also get a sarcastic or flippant reply. I explicitly look for these and examine them carefully. Some people use comedy or sarcasm as a defense mechanism. Be careful when this happens because it is hard to improve the outcome from this position. This is a sign that I need to tread very carefully and do what I can to be supportive.

Other times if you get a reply that is defiant or flippant, this is a sign that things are going to take a turn for the worse.

Following the meeting, be clear in your documentation that you asked them what the most important takeaway was from the meeting, and what their response was.

This has historically been one of the most highly correlated signals for me that I am going to have to take significant corrective action.

Understand Your Liabilities

As a manager of people, you may have some personal liability for some of your interactions with them. Before you take leadership responsibility you should understand what that means for you and the legal jurisdiction where you work because it varies from state to state and country to country.

Some companies have management training that will give you a good summary of what your obligations are. I think I was managing people for multiple years before getting my first formal company management training. I was shocked to learn what I could be personally sued for as a startup founder. At larger companies, often public ones, there are compliance training sessions you may be required to take every year or two.

If things go poorly in giving feedback, you might be asked to collect all your documentation with the individual in question and forward it to human resources or legal representatives for review.

The more thoughtful and proactive your correspondence is, the more likely it will help you avoid getting entangled in things personally for doing your job.

Read All The Signals

My final thought here is that you should be aware of all the inputs in delivering unfortunate gifts of feedback. If someone is not fitting in with a team, and you are getting feedback from below and sometimes even above, understand that while you might not have a problem with someone, other people do. This is one of the hardest situations to be in. You will find sometimes that senior leadership will be cryptic about it or perhaps not very clear in what they expect. On one hand, they want you to manage your people and be successful. On the other, they may be encouraging you to do something that might be for your own good. If you go to your boss and ask “Should I get rid of this person?” it is not often they will point blank say “Yes”. Generally they will remind you that it is your job to manage your people and maybe give a small list of pros and cons to the situation for you to weigh over.  When they do point-blank say “Yes”, you know you have some urgent work to do in order to figure out how to fix the problem to everyone’s satisfaction, including your own and the employee in question.

So there you have it! I hope you enjoyed this week’s dive into some of the more brutal work conversations I have participated in. Some of you were there and I know you are going “holy shit I remember that”. This is a learning process and a journey for all of us. Hopefully it makes us all better people. I will close by saying I have seen a number of people who I have given unfortunate (and sometimes terminal) feedback go on to soar to amazing heights professionally.

See you all back here next week as I struggle to refill my big bucket of ideas. Does my nervousness and anxiety create a sense of urgency for you to need to read this scarce supply of nuggets of wisdom? I know I want to see how it turns out!