Artisanal Concatenations of Sentient Emanations

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!

One of the biggest problems in software development is trying to figure out when something will be finished. Unfortunately we do not understand the software development process as much as we understand the process of building a house or a car. Maybe that is not actually true. People make this comparison because there are some similarities in the end-product. There are some differences that need to be understood in order for the metaphor to work.

One of these differences is in the nature of available components. If you have all of the pieces well designed, then making a car is very easy. This is where the metaphor falls down. No one asks the question “What if you had to design a gearbox as a part of building a car”? And this is really where the problem exists.

Most attempts at creating a pipeline of features or products do not take into account the design elements needed as a part of creating new software features or products. This makes the process hard to plan out because there is generally geometrically increasing complexity in the interaction of systems as you put them together.

So how do we make this process more manageable? Ultimately this question is what birthed Agile Programming. As I say that magical phrase, half of you are cheering and half of you are rolling your eyes. I want to apologize to all of you because I am not going where you think I am going next.

There are some good things to Agile Programming and there are some bad things to Agile Programming. The best thing that comes out of Agile for me is the ability to develop work in sprints. I like two-week sprints for most projects. I will slow it down to three-week sprints sometimes when we are building very deep infrastructure and engineering teams need time to really think about what they are building. I have yet to move to a four-week sprint but I can believe there is a software system out there that would benefit from it.

So why do I like two-week sprints?

I like two-week sprints because two weeks is the amount of time I will tell you it will take me to build something that I do not know how to build. Two weeks is a safe number to say because it buys me some time to think about something and it buys me some time to experiment with some software interfaces.

And it is almost always 100% wrong.

I like two-week sprints because it is really difficult to make a great piece of software in two weeks.

I will tell people this from time to time. I want to be called out when I wave my engineering magic wand in the air and close my eyes and soothingly say “this will take me two weeks”. I want to be told I am wrong and I want to readjust my estimate up or down based on an examination of facts and perhaps a shorter window of time to do some experimenting.

I have led some great teams using Agile Programming to build software. Some of these amazing teams delivered very usable software in a timely manner that improved tremendously over the life of the project using two-week sprint-based development. I am happy to tell you all how this worked out for me. There are a few things that an Agile Programming approach has that work wonders on making software. Let’s start by discussing an anti-pattern: Fake story points.

We all love to hate story points. I recall the visceral project manager reactions when they are told the value of a story is 8 and another story is 5, and they have no basis to translate that into an effective number other than “the 8-point story is less complicated than the 5-point story”. The difference really has no basis in reality to planners and managers and they feel like they are utterly lost without a fixed reference point. In order to get to a shared understanding, I decided to throw away the abstract points and pin them to a very rough engineering cost. This is why I call them “fake story points.

Here is how that works:

Every story point should approximate a half day of work for a simple task.

All stories should be 1,2,3,5 or 8 story points. If it is 13 or 21, you likely need to break it down further before accepting the work.

Regardless of the previous rule, every external dependency on either an internal or external team automatically bumps up an estimate and should be preserved as such because dependencies are a gigantic risk.

So why does this work so well?

For starters, while it violates the steeple-fingered engineering abstraction that some people crave with their story points, it does provide some basis to do actual estimates that people can measure. If you are doing a two-week sprint, and each point is a half day of work, you are likely looking at 20 story points of capacity, minus 2 to 5 points depending on how involved your planning is. I would say that 15 points is safe, assuming you are doing sprint planning, grooming, and a sprint review and retrospective. While each person’s numbers will be different based on their own skill level, it will help planners assign a velocity score for the team.

The other nice thing about this is that if you are using 1,2,3,5 or 8 point stories, getting to 15 is relatively easy. However, getting to the right 15 story points is a very complicated process that involves looking very critically at each task and figuring out what is most important. Fitting all of the work into these 15 points is a critical negotiation between engineering and project management that ultimately results in both parties having a stronger shared understanding.

After applying fake story points it is important to capture all of that data into a spreadsheet. It is important to keep a running log of appetite vs accomplishment, sprint over sprint. You will notice that there will be trends in the work asked for and the work completed regardless of whether it is one team or five teams.

For a solid team that is getting more and more familiar with the project management requirements and more comfortable with the designs of systems they are needing to stand up, you will see the appetite vs accomplishment numbers converging over time quite nicely.

If it is not converging then you are identifying a problem that needs to be discussed at planning and at retrospectives to figure out why.

I was recently working at a company with a large number of teams who all had tools tasks. One of the things I observed is that the estimates for the amount of work needed to complete tools tasks never converged to a solid number. There was always a very high cost to every tools story, and there was also a smaller number completed compared to other tasks.

This could tell you a number of interesting things, any of which may hold true for you.

1. The tool designs were not sufficiently specced out enough to be meaningful
2. People hated working in the technology to build the tools, which usually is different from the tools they use to build their core software
3. People love building products more than they love building tools
4. On completing the tools that were asked for, they later get asked to just write a CSV importer due to the tools not working great after the use case for the software develops emergent complexity or emergent use cases that require nearly immediate iteration. This is a special case for 1) that needs to be called out on its own

If any of the above holds true consistently then it identifies that there is a gap in either designing or building tools that is not getting better. You can solve this by making an explicit tools team whose mandate is to ensure these problems go away. If that does not work, then it is potentially a place where you can leverage an outsourcing company.

The last thing to do is to be very public with the aggregate data. I have had some people very ashamed or upset when they do not make their numbers. It should be called out very early on and very frequently that this data will be available to everyone for review. It is important to communicate that out before sharing or people will be very upset. By having all of the data available for review, you will spark pattern recognition across the whole organization and spur meaningful conversations on how to address problems or highlight great successes. Improvement over time is something everyone should be invested in.

Fake story points, measurement, and sharing may sound simple, but it takes time and discipline to get to a great place.

Let’s discuss some times when these rules fail, because they will. Almost every time they fail you can spend time discussing how and why they failed and what to do about it.

The team is too small

The first time this does not work is when you have 3 or fewer people on a team. Even real story points that are abstract fall apart when you have too few people and numbers to get good measurement. If you are trying to figure out a small team’s velocity then the points will not do much to help you accomplish that unless you have a large number of sprints of data to stare at.

There is only one team

Another time this does not do great is when you only have one team. Similar to above, you will need to amass a large number of sprints to extract meaningful data about how the team is doing on story points. You are better using a much simpler metaphor, maybe even just stories accepted and stories completed.

Team instability

One of the biggest problems with any software team is churn. When people are joining teams or leaving teams, it causes a lot of instability in productivity and the ability to measure. There is a trite “don’t shake the Jello” comparison here. The best teams are the ones that get to gel over time. The more time you give them, the more successful they are. If they are not improving sprint-over-sprint on their own it may be entirely possible that the team does not work well together and that there needs to be some overall rearranging. This is a tool of last resort since it will cause the numbers to thrash a little.

Lack of shared understanding

Finally, you might just be a victim of a failure to communicate. It is very hard to improve on building out systems if you do not have a shared understanding between the people needing the systems built, and the people who are building them. I am pretty quick to ask “do we have shared understanding” when I see failures in accepting delivered work. If it is not declared “done”, generally that means that the process of communicating the work to the builders could be in need of improvement. This is one of the hardest problems to solve. I was introduced to “grooming” by one of my team members a long time ago as a means of solving this problem. Grooming is a painful weekly meeting where the product owners bring stuff to the engineering team to review without a commitment to accept the work. Anyone is able to ask questions and the first few of these meetings will bring out some amazing questions that should be educational to all parties. After a few months of grooming, I have observed that there are often repeated questions by engineers that turn into answers being added proactively once the pattern of questions is clear. This generally means that as shared understanding improves, the meeting gets shorter and shorter.

So there you have it! If you read this and are willing to adapt some of these practices to your work or teams, I should warn you that it takes over six weeks to really change your team behavior for the better. If you are two months into changing your team’s processes and not seeing a positive result then you at least have a good framework for measuring the gaps that can be freely discussed by all parties.

Thank you for reading this week’s article. Please comment, share, or otherwise Socials my weekly brain-spray into the ether. Feedback is a gift and who doesn’t love getting gifts?

Hello everyone! I might be a bit fixated on career development and promotion subjects for the next few months. That is probably because everyone else is too.

If you work for a large-enough company to have a compensation committee then you are likely at the one-third to one-half mark for doing your end of year reviews and performance calibration for your teams. How very exciting!

This week I wanted to talk a little about time-in-role. We previously touched on trying to accelerate your career plans and short-cutting time-in-role using your dry powder stores. This week let’s ask about the other extreme:

How much time is too much time for you in any one role?

Of course, the higher up the leadership ladder you climb, the longer your time-in-role becomes. If everyone shared the same time-in-role guidance, every company would be half full of vice presidents and staff engineers, or their equivalent. It should also be noted that getting title progression and getting career scope progression is a means for retaining people.

If you move people up the ladder too quickly you risk losing them when they are in their prime and have the most authoritative knowledge for your teams and products. This is very risky and very expensive in terms of tribal knowledge retention. Some companies use fast promotions as a retention gimmick. If they have sat down and figured out the expected churn for their average new hire, then they may accelerate career milestones for people to keep them engaged for an extra year or two.

The downside is that it may encourage itchy feet for people who are not getting their desired promotions or increases in responsibilities.

If you are working at a company that does frequent or consistent promotions, I would recommend making sure that there is an honest conversation between a manager and all of his team members on what their expectations are around promotions and new responsibilities. I will confess to being late to helping one of my team get a desired promotion fairly recently. In my own defense, I was new to the team and we did not discuss it amongst his goals for the year. At some companies, correcting that kind of issue may take a year or more, the more senior the candidate is.

If you move people up the ladder too slowly then you risk losing them before they have the opportunity to maximize the return on your knowledge investments in them.

If you are working at a company that does infrequent or inconsistent promotions then you run the risk of driving your talented rising stars out of the organization. Some of this may be as a result of working previously at a company with frequent promotions. If you have people who are conditioned to have frequent level-ups and have not communicated with them about the pacing of their career and when they can expect it to change (slowing down, usually) then you run the risk of them looking for greener pastures and creating churn for your organization.

Finally, you might have someone who should not be moving at all. Some people gravitate towards a certain potential level and are perfectly happy staying there. I struggle with this personally, because I do not identify with being perfectly happy at work. I have been conditioned by years of startup roles to be very uncomfortable at work and finding ways to push change and growth for the teams I work with and the software they work on.

So what does that really mean?

Generally you can expect that a first-time software engineer should be in their role for one to three years before getting some additional level-ups and/or increases in responsibility. It is interesting to me to see how there has been some “title inflation” over the years. Several years ago, “Senior Engineer” meant 7 to 10 years of professional experience as a software developer, and now reflects more like 3 to 6 years of professional experience. Many places have titles such as “Principal Engineer” or “Staff Engineer” that formerly represented 15 to 20 years of experience and now is more like 7 to 10 years of professional experience.

In addition you might find some companies have special titles that are at the top of the chart. “Distinguished Engineer”, a title at Zynga, is a good example of this.

Some companies will have a leveling system to include some intermediate milestones on your career progression. I am a fan of this model. If you can break down people’s promotions into smaller pieces, it gives you a lot more tools as a manager to work with people and keep them happy and growing. You might see “Software Engineer” as a band with a number after it. Some places have three bands (I, II, III) and some places have more like ten bands (1-10).

Your current employer might have different definitions or expectations for their titles and teams. That is totally reasonable. These are things I have observed as accepted patterns for engineering titles and promotions.

This is also not a “one size fits all” model. Some people reach a professional plateau and stay there, either consciously or unconsciously. I do try to talk to people about their career goals and what I can do to help with them when they are in this situation. Sometimes I have tools to help advance people along their path, and other times I may not have those tools and have to help come up with a plan for how to keep their work interesting and relevant.

If you have questions or concerns about your current role, or how to get to the next level, you should absolutely talk them over with your manager. I would recommend avoiding setting up ultimatums for career progression. Sometimes things might be out of their control. What I would recommend instead is working with your manager to come up with a step-by-step plan to demonstrate you are ready for additional responsibilities or a new title. Sometimes there are clear lists of things you can do in order to demonstrate you are ready for it. Sometimes it is more ambiguous and you will need to work with your manager to understand what decision-makers need to see or hear before they can give you a promotion.

If you have asked your manager about how to get into a new role or earn new responsibilities, you might not get the answers you are seeking. It is easy to read into that and think that your boss does not like you. Before you reach that conclusion, you might want to ask yourself some questions.

Are other people getting promoted?

If no one is getting promoted then there could be business headwinds that are keeping everyone stuck for a while. If there are very few people getting promoted it may also mean that there are some caps on either budgets or title allocations that need to be navigated. These might be more common than you might think.

Am I not responding to feedback?

This one is a personally frustrating one for me. I quite often give people very direct feedback, both verbally and in writing, about things they need to change or improve in order to progress. When I see someone partaking in destructive behaviors or ignoring my feedback about some of their professional habits then it is harder for me to lobby for them to get a promotion. I have tried to couch some people out of habits that are destructive for meetings, and provide communication guidance to other people to help show they are ready for more responsibility. If your peers are consistently giving you heavy guidance on your code reviews, or your features are slipping due to quality or system scoping reasons, these may also be soft forms of feedback that you need more time in your current role.

Is my manager looking out for my interests?

This one is a lot harder to figure out. I have had good managers and I have had bad managers. It is easy to be confused about what kind of manager you have. Sometimes a good manager is hard on you to help you change some of your habits and can feel like a bad manager. Sometimes a bad manager is trying to be your friend and not helping you grow professionally and may wind up feeling like a good manager. There are lots of ways to find out if your boss is looking out for you and trying to help you grow. Whenever I have a new boss I try to give them a year of grace to learn what kind of boss they are. I generally can tell in a month or two, but I think that there is some level of professional courtesy merited in a working relationship even if you decide early on that you have a bad manager.

Do I want to be promoted?

Now that we have gone over all of the external factors, let’s stare into the mirror for a while and consider all of the internal factors. Clearly we all like raises. Do we all like new responsibilities? We may just be comfortable with our current job. This gets tricky. Sometimes the person who “just does their job” does not get rewarded at the same pace as someone who is thirstily climbing to find their local maximum. What you might find is that your cost-of-living adjustments and what the actual cost-of-living is do not line up. Over the years, you might also become frustrated at seeing other people reaching higher professional altitudes and clearly making more money for it. You will find that eventually someone in this position will want to move out of your team or possibly even out of your company. The sad and frustrating part is that you might not be in a position to do anything about it as a manager.

Have I done this job for too long?

Now that we have taken a look into the mirror, let’s go deeper and stare into the abyss for a moment. What happens when you get stuck? For example, If you were a Flash developer up until now, you are in for a rough year. The Flash web browser implementation was finally taken out behind the shed and put down this year once and for all. If you have spent the past six years as a senior software engineer making games in Flash, you are going to have a hard time finding a new role either at your current company or at a new company. I have worked with many people who are specialists in technologies that have fallen by the wayside. There are no easy answers here. If you have spent too much time with one technology or on one team then you are going to struggle to get into something new and exciting without spending some time showing that you can adapt to a new situation. It will be hard to establish that proof, especially if you have spent many years in that role and have gotten extremely comfortable.

I know this is not an exhaustive list. These are pains I have experienced myself or pains I have witnessed in my teams and peers. I hope you look at this list and think long and hard about what your current time-in-role is, and what your next steps should be.

As always, thank you for reading along! I generally get five to six direct responses to these articles each week and I am grateful for all of the dialog that ensues. See you next week everyone!

Hello there and welcome! Last year I found I had a two-month window where I was coming up with ideas for an article at a rate greater than once a week. I am slowly grinding down that reserve of subjects and it is giving me a little bit of anxiety. Can I sustain this pace through 2021? We will see.

One of the interesting things about startups, and in particular startups that seek venture capital, is that they tend to share a similar shape. The founders have specific pedigrees or they have depths of domain experience. The plan is sketched on a napkin or it is presented in ten slides with a pretty SWOT analysis that simply begs for term sheets. Sometimes it is possessed of certain magical incantations that imbue it with depth and complexity.

My favorite of these is the use of the word “platform”.

Everyone loves a pitch with the word “platform” in it. Either you will start off with your pitch to an institutional investor describing how you are building a platform, or they will look at your idea and figure out if it is worth their time to tell you that “you should make this into a platform”. Sometimes the use of the word “platform” in your pitch does not even make sense, but if it is there, it adds a level of certainty to the success of your outcome.

So is it really that simple?

Actually no, it is not.

Because saying you are making a platform is incredibly easy. Actually making a platform is brutally hard.

For every platform out there that existed, there are nine hundred and ninety nine who did not make it over the finish line. In some cases they barely made it past the starting line.

So let’s talk about them for a minute. To make things simpler, let’s give them a cheeky name.

Today we are going to talk about the splatform.

So what is a splatform?

Splatform, Noun: A splatform is a platform that fails to get relevant market share.

I will start off by saying this is probably the dumbest word I have ever invented. That is not an apology. Lots of people invest millions of Other People’s Money into trying to create platforms, and I think that it is worth talking about some early warnings for people wanting to make a platform, with the hopes of increasing the odds of their success.

If you find that you are one of these people, and you have read this far, then you should stop reading this post and email me. I am available for “s-tragedy-ic consulting”, if I may invent another word. Ok fine. I know you are not going to do that, so just keep reading for free.

Here are some signs you are making a splatform.

Zero million users

Platforms are not a Field of Dreams. There is no guarantee that you will build it and they will come. If you do not have a pretty good use case or you do not possess something that is in demand then you are clearly headed towards splatform territory. I know every platform starts small. Most of the time you need to beg, borrow, or steal your first one thousand users. Pay attention to them carefully. If there is a “there” there, they will let you know. If there isn’t then you should find out what is missing.

Timing

This is going to be one of the biggest “the dog did it” excuses for most splatforms. In some cases it is probably true, but most of the time it is just a convenient thing that everyone tells themselves when they failed and need to feel good about themselves. If you failed to launch then you should take a really hard look at why. It could be pricing, it could be demand, it could be team, it could be Tuesday. For all the times I have heard “we did not time our platform correctly” I would say maybe a third of them were true, and the other two thirds were really a combination of other factors.

Roller Coaster Metrics

This is especially true for social platforms and consumer applications. It is one thing to get everyone to show up at the party. It is another thing for them to buy drinks all night, and even come back next week. If you are not engaging people long enough or convincing them they should come back then you will be burning through your marketing and acquisition spending for insufficient returns. I sometimes call this the “leaky boat” phenomenon. I just called it “Roller Coaster Metrics” because It Will Totally Shock You!

Nyet Promoter Score

There is this notion of the “Net Promoter Score”, a means of telling if your customers will recommend you to their friends. Let me introduce you to his cheeky Eastern European counterpart, the “Nyet Promoter Score”. If you are getting ‘2 – would not recommend to a friend’ or lower on your scale of one to five, you are probably on your way to having a splatform.

A-Meh-zing Content

This is more true for consumer platforms than business-to-business platforms. You have to have a killer app. If your content is simply a-meh-zing, you are not going to have people beating down your door to give you all of the moneys. As a business platform, you can get by with a-meh-zing content. You just have to be that much cheaper than Johnny-Do-Better and make it up in volume.

Buy-nary customers.

The categories get cleverer as we go, but if you build a platform you have to make money somewhere. Either you are directly selling things to consumers or businesses, or creating a two-way marketplace where you get paid as a middle-man for making fetch happen. The real problem here is that you might have the wrong price, or the wrong product, or the wrong customer. If ‘nary’ anyone buys anything, you might have a splatform on your hands.

Marginal Atrocity

These days, early-stage companies are being inundated with capital to reach scale. You have to make money at some part of your business, eventually. If you are banking on the cost of scale to save you, you might have a splatform on your hands. This cost could be inefficiencies in the marketplace, or they could be the cost of R&D to reduce your price-per-widget. If you are banking on these margins changing then you should prepare for a lot of down-rounds in your future as you fight for the day that the numbers work for you. The good news is that there are a lot of people willing to make an investment to scale up your business, assuming you have a wonderful story, and compelling numbers to support it.

That is not an exhaustive list but it covers some of the worst offenders I have seen.

If you find that you are building a platform and you have one or more of these symptoms, you might not be having a good time in the near future.

So what ultimately happens to splatforms?

“Pivot!”

This is one of my least favorite buzzwords in all of Silicon Valley. I almost want to make a whole Devo remix about it:

I get why people do it, and I get why people say it. No one wants to go to a board meeting or potential investor and say “We were bad”. This is how we gracefully say “we were bad” and don’t have to apologize for it. Besides… Learning!

“We just sold to a larger company! Good news: We are not shutting down our service!”

Narrator: In four weeks time, they are shutting down their service. 

Not sure what else to say here. High tech companies are full of hundred-million-dollar problems and it is easy to buy a team to solve them wholesale. Sure they did not succeed with their big ideas. Fortunately for multi-billion dollar tech companies, it is worth it to short-circuit the team-recruiting and team-gelling problems in exchange for some cash and stock. Sometimes you will get bought because you have a solid revenue-generating company that a larger company would like to add to their balance sheet. Other times, you have a splatform on your hands and you get hired to be disassembled for resources and maybe a little bit of extra money for investors and employees alike. At the very least, understand that this is a pretty decent base-hit outcome from a bad idea. Hey, you will at least get new business cards!

“Everyone go home”

I have lived through this one before. Sometimes, for whatever reason, you just have to turn off the lights on your way out of the room. There is no after party and you have just enough time to sober up and think about what you did wrong before you have to do it all over again.

“Just keep swimming!”

Sometimes the outcome is not a win or a loss. Sometimes it is just a tie. This can be good and it can be bad. If you are staying in business serving some customers and keeping revenue and features flowing steadily, I guess there is nothing wrong with that. Ultimately the market rewards growth for businesses, which implies that spending years treading water might not be the best use of your time or energy.

There are probably others that are variants of these outcomes. I am happy to have discussions with how to better catalog the symptoms and outcomes for splatforms!

As a final thought, I would be remiss in talking about splatforms if I did not make a few observations about games splatforms. Some of these are doozies! I am not going to name names here—you all know who they are.

Games platforms are the hardest of the hard modes for startup businesses. I have tremendous admiration for anyone who tries to make them. I also have the hardest criticisms for their failures.

What causes games platforms to fail?

“No Genre Defining Hit”

Think of all the game platforms out there. When you think of Nintendo, do you envision a game or franchise? How about XBox? Or Sony? Almost all of the time, when you buy a new piece of gaming hardware, you are just acquiring a dongle for must-have content. Wing Commander sold 16 bit sound cards, and Myst sold CD-Rom drives. If you are making some kind of gaming platform, and you do not have an exclusive hit, you are in for a long hard road. I will specifically call out Half-Life: Alyx for VR here. A lot of people say it is a platform-defining hit for VR. I disagree. The problem with Half-Life: Alyx is that it did not grow the marketplace for VR. It was not “must have” content for consumers. The customers for Alyx were a complete overlap of people who loved Half-Life, and loved VR already. There are similarly good VR games out there on other platforms. None of them are “must have”. I do not feel the need to play Beat Saber so badly that I need to buy a VR platform for it.

“Three Top Ten Apps”

I have been paid in the past to stare deeply into the abyss of games platforms—and yes, it did indeed stare back at me.

One of the problems most people have is in portfolio management. I have had the good fortune to know many people who were around to launch games platforms who all told me the same thing: You need to have a sound portfolio strategy.

It is a win condition to possess a “must have” franchise. If you do not already possess that property or franchise, you need to have enough of a portfolio strategy for it to become clear.

Sit down and look at your consumers, and your product offerings, and even your competitors. Do you have enough categories of content to appeal to people? Are you making enough bets for outlier niches of users that you can identify a nascent product market fit before anyone else?

I would argue that Farmville was one of the products that was a nascent product market fit for Zynga. It was not clear that it would dominate the platform in the way that it did. Candy Crush was that success in mobile.

When I talk with modern day developer relations people, quite a few of them have this real hands-off attitude with their developer partners. “We do not want to tell you the types of games you should make” they say.

When I was at hi5 as developer relations, I flipped the script a little. I absolutely told everyone what I was looking for. I did that because we needed to. We had one really strong app on hi5, and a lot of medium performing games. What we did not have was a cohesive content strategy. I wanted to put five or six specific titles onto our platform that we did not have because they were present in all other casual games marketplaces.

When you are building a games platform from scratch you might not know enough about who your customer really is, and that is when you need a really wide shotgun-blast approach to content.

Even if you do know who your customer really is based on your competitors, it is worth it to fire off a few outliers to generate evergreen niches.

“Please eat the grass!”

You may have heard me complain about buy-nary customers earlier. This is indeed a problem. However, it is important to have something for your grazers. If you have people coming in, trying one thing and leaving, that is a bad sign. However, if you are having people coming in and trying a little bit of everything, you have a customer. You are just not negotiating with them sufficiently.

Mispriced games and overly generous freemium content are both conditions that can lead to fatality. Provided you have some room to experiment, and some tools to gauge the outcomes of those experiments, you can generally recover from this condition. Most of the time that this gets diagnosed in a splatform is about one or two quarters after the problem has gotten entrenched and player expectation gets trashed trying to keep the lights on.

So there you have it. I was afraid this was going to be a very short article. Now I feel good that I have gotten this off of my chest and I have told you everything I know about splatforms. I am going to give myself five stars on Yelp, and tell myself what a good job I did. I am doing that because when I tell you all to give me feedbacks and socials, I hear from the same five or six really special, really wonderful people. I would love to hear from the rest of you! Otherwise maybe I will turn this into an hour long weekly zoom call and spare my diligent editor an hour or two every week poring over my bad grammars.

See you all here next week!

Hello again! The focus of my writing for most of 2020 was career-defining experiences and the lessons learned from them. While that will still continue in 2021 I will also sprinkle some product-related conversations into the mix, like last week’s post. If those posts fall outside of your interests I apologize. This week we are going to go back to career conversations. We are going to talk about dry powder.

I mentioned in my “Twenty Lessons Learned in Twenty Years” that you should figure out what your limits are fairly early on in your career. As you also get older, those limits will change for the worse. There will be times when you will be asked to do unreasonable things in order to complete projects that are in crisis or perceived to be vital for business reasons.

This is a much more sensitive conversation than it was twenty years ago, or perhaps even ten years ago. There is a need to make sure that everyone respects established work-life boundaries, and if you are putting in extra time to complete urgent work, that there is some downtime taken in consideration. This is a wonderful thing for people with families and personal obligations to others.

You will encounter moments in your career when you will be asked to go above and beyond your normal duties, and there will be moments when you may counsel others to do the same. I will confess that early on in my career I jumped on as many critical projects as I could—I honestly would not advise this due to the multiple associated downsides. So over the years I have built myself an informal framework for evaluating urgent work. The first thing I decided to do was to figure out a cap for the amount of unreasonable work I would do in a given year. In order to communicate it better both to myself and to others I gave it a name. I referred to it as dry powder.

I attempted to google “dry powder” to help unearth its historical roots—all I found was contemporary finance references. Dry Powder stores come from the 17th or 18th century and the need to have available gunpowder for guns and cannons for war time. I find that to be a pretty accurate and amusing metaphor for software development.

So when should you use your dry powder? There are some obvious cases.

Meeting revenue numbers

Every product manager and project manager is nodding slowly at the hat tip I am giving them with this one. This is especially true at public companies. It is also exceedingly dangerous for the same reason. Companies make quarterly earnings statements and it can be really addicting to create overly ambitious plans for generating revenue, and expect the engineering team to make up for the gap between appetite and availability in order to generate business results. In the short term it is nice to go above and beyond to deliver a revenue win, however it is dangerous to do this repeatedly. I generally advise teams to do this at most twice in one year, and then it is time to have a conversation with leadership about planning. If it happens once a year at most, with a short duration, it is likely sustainable provided you get to share the rewards for the team’s success with the people who burned their dry powder.

Promotion hunting

Some companies have formal systems for acknowledging when it is time to promote somebody. It is worth taking on a more ambitious project than your role is scoped for, and burning some dry powder for it. This is especially true if you have had more than one year in your current role and based on other people’s feedback and comments, you are confident that you would be successful at the next level.

I would exercise some caution here in doing this too often. If you are taking on too much work like this it has some negative effects even if the project is successful. You can burn yourself out doing too many dry powder projects and it may also impact your primary responsibilities. When deciding on whether or not to burn dry powder on, I advise that you discuss it with your manager to determine if they can use that work to get you a promotion. It can be frustrating to do a bunch of extra work and then not get rewarded for it in the way you expected to be.

Compliance

I had the great fortune of working with a team of really talented engineers shipping a GDPR compliance feature for a large and successful product. This project had a very immutable deadline. I had to spend a significant amount of time talking with everyone on the team about its importance to the company, and to make sure we could get it live by the deadline. We had to spend a considerable amount of time working with leadership to communicate risks and request additional resources to ensure it was completed. This is a great use of dry powder.

Management changes

This one is tricky. I have been inside organizations when there have been leadership changes. I carefully measure dry powder allocation when there is a change in who I report to. If you are in a senior leadership position, you might already find yourself on a shot clock to be replaced by trusted people from your new leader’s previous organization, in which case nothing you do will make any difference for your long term career goals. While going through the process of getting to know my new boss or my new bosses’ boss, I take all of my dry powder evaluations to them to learn where they like to spend their dry powder. Quite often, you can pretty reliably predict what your new boss is going to do with you, and quite possibly your team, based on their replies. If they expect you to burn through all of your dry powder at every given opportunity, then they have little interest in you or your people—It is generally a good sign that your days are numbered and they want to extract as much value out of you as possible while gaslighting you on the way out the door.

Alternatively you may inherit new leadership who will listen to your conversations when you ask about whether or not you should burn dry powder, and will either give preferences or balanced pros and cons. When that happens and they ultimately say “you should make this decision yourself”, then you likely have a pretty good boss who is being helpful and supportive of letting you own your outcomes. It is too easy to be cynical and consider this to be some sort of trap. Half the time I assume that it is and just walk into it anyway. If I have that kind of boss I want to know sooner rather than later. It is worth burning some dry powder to determine whether or not your new boss has a long-term interest in having you around.

Are there other times you should burn dry powder? Absolutely. This is not an exhaustive list.  It is an effort to give a few examples on when I choose to burn dry powder, and what filters I apply to make that decision.

Are there times you should not burn dry powder? Absolutely. Especially if that answer is “Every Friday fixing a release”. If you are in an organization that is burning your dry powder excessively then you should try to change that. Work with your management to figure out how to get well soon. If they are uncaring, or you are struggling to get to normalcy, then perhaps it is time to figure out some sort of team change or career change. It goes without saying that this is easier to do if you have some dry powder on hand!

You should always be able to have a conversation with your manager, your peers, and  your subordinates about when to spend dry powder. Even if the outcome is not what you desire from that conversation, it will teach you something about the people and the company involved. You can also use that information to make very important decisions in your career and in your life. 

If you are nervous about talking with your manager, your peers, or your subordinates about when to burn dry powder then you should ask yourself why. It is likely the fear that everyone will always be expected to burn all of their dry powder. I personally would not consider that to be a wonderful or sustainable work environment.

Thank you for reading along. If you have not thought about your dry powder reserves before now, I hope that you start to think about how you should manage them. I look forward to hearing from you, and to writing more things to think about for next week!

Hello everyone and welcome to 2021! I thought I would start off this year by continuing to talk about positive team-related activities. So without further ado, let’s discuss how your team can choke to death on small pebbles.

Woah… Wait… What? Let’s back it up just a little bit. Because it is January, just about everyone working for a company is about to write the end of year reviews for themselves and their subordinates. This process can take days or it can take weeks depending on who controls the budgets for compensation adjustments and just how deep into Workday your current company is invested. All of the Bidness Leadership are looking at the graphs to find the best way to capture how much Value they created and why they should be at the front of the line for the stock handouts and fat stacks of cash.

As they go through this exercise, they probably have a list of projects that were completed as well as what “moved the needle” on metrics that they can put into a Pretty Pretty Presentation to Senior Leadership.

Every place I have ever worked, I have seen these presentations and the graphs that show the numbers going up and to the right. Universally, this is how businesses grow, and also how people get rewarded.

So what is wrong with this picture?

The problem is that this puts some pretty strong incentives on making small meaningful incremental steps in your product that could lead to deeper problems in the long term.

There is significant interest in getting releases to your customers on a cadence that is measurable and also that tells a particular story for management and investors. If you happen to be working for a public company, the yardstick that everyone applies to these stories is known as the Quarterly Earnings Report. This means that every three months you are going to need to have a pretty significant nugget of data and numbers to feed to your hungry investors and shareholders.

Even if you are not a public company, you may have investors who work at venture funds, or leadership who previously worked at public companies. There is a bit of conditioning and reinforcement from those roles in expecting to hear something interesting on a drip-feed basis. I am not at all saying there is an unhealthy addiction to this schedule. Okay, maybe I am.

The problem this creates is that it puts some pretty drastic limits on what you can get approved for your engineering teams. As an engineering leader you will find that you might be put on an aggressive schedule of projects that requires a pretty fast turnover from inception to release date. If you are lucky, you might have two or more teams who can stagger the release schedule so it is more sustainable. If you are unlucky, you are going to have to take a deep breath for the brisk unending run you are about to take in your particular hamster wheel.

There are also some pretty ugly side effects to the need to do meaningful releases on a schedule like this. The first of these side effects is that you will have a shot clock on infrastructure projects. This gets more and more serious the more successful you are and the older your product becomes.

The pace of tool updates, library updates, and platform updates introduces obsolescence into your project relentlessly. I have inherited decrepit old projects that still work in production with old code in a state that you cannot even rebuild from scratch without the benefit of a hoarder’s repo of old tools.

Upgrading your software to keep it maintainable and current is a huge problem. It can also be a massive investment of time. As a result, it is likely going to be deprioritized repeatedly in favor of smaller “revenue positive” projects that will give “more bang for the buck”. Expect the person who delivers this verdict to you to wink and point finger guns at you. I don’t know why they do that.

The problem there is that if you continue operating a coal-powered locomotive in modern times, you might have difficulty obtaining coal to keep it operating, or worse, you might find that steam engine parts are only available by robbing a nearby railroad museum. Not only is this illegal, but it will make train-loving children cry.

In my head I am already reliving all of the panicked hand waving and appealing to senior leadership that I have done related to this particular situation. I am also reliving all of the times that this was taken out of the roadmap in favor of incremental revenue. Unfortunately, there are a high number of times this turned out to be a fatal mistake. It is also one of the reasons why a lot of people are nervous or afraid of experienced engineering leadership on the team. If you have fought these battles and won, the only real measurable upside is “we are still alive to keep doing this again tomorrow”. “We are still here!” is not a real compelling metric.

Also, nobody in product management understands that deferring this kind of upgrading is one of the best ways to inspire resume updating by people who you do not want to have sending out resumes. The older your product gets, the harder it is to maintain. The harder it is to maintain, the harder it is to add new things to it. The harder it is to add new things to it, the less exciting it is for people to work on it. The less exciting it is for people to work on it, the more likely the people are to leave for something more interesting to work on. It is a pretty frightening slippery slope.

So if you find yourself in this situation, what can you do about it?

The first thing you need to do is to sit down and measure the effort for each of your projects. I like to use the pebbles-to-boulders analogy here. Small projects are pebbles, medium projects are rocks, and large projects are boulders. You will find that the product roadmaps for most companies are loaded with small pebbles, and sometimes will have the intermittent rock. Very seldom do they have boulders.

What you need to do next is to point out that a slow and steady drip feed of pebble-sized projects will only ever be a constant incremental improvement over time for your business.

This means if you are in second place, you will always be in second place. You can assume most times that the people above you are there because they have a good cadence of releases and growth, and it can be sustained. That means to cover ground you are going to need to create genre-busting step functions to catch up to them and surpass them.

If you are in first place, we can assume one of two things is true. 

First, we can assume that you are more successful than your competitors at shipping new features, in which case you will continue to push pebbles into the marketplace which will slowly create a drag on your business. 

Eventually, you hit a failure-state where something has a cascading problem and your dependence of consistent pebbles being released into the marketplace will suddenly be broken which opens the door to your competitors to catch ground. In my opinion, Jira is one of the best examples of a marketplace leader who ships a lot of pebbles. We will see how that works out for them in the long run.

Second, we can alternatively assume that you are not more successful than your competitors at shipping new features, in which case you are eventually going to be surpassed by them and lose your position at the front.

Very seldom do you find a product that is far out in front and stays there. If you find yourself in that position, congratulations on getting a job at Apple.

If you are not that fortunate, then you need to figure out how to change your organization’s behavior to be more successful, and generally you will find that the companies that suffer the most from this are slowly losing their forward momentum on a small-pebble strategy.

Until you point out to them that you are choking to death on those small pebbles, you will likely struggle with getting them to agree to taking on rocks or boulders as a part of the product roadmap.

Please do not promise magic silver bullets for your first time doing this. Temper their expectations that it will take a few tries to perfect step-function changes. It is not likely that you will get it perfect right out of the gate.

Be patient with this process. It is a very difficult position to be in and it will likely be a great ‘growth opportunity’ for you. Engaging with your peers to change organizational behaviors for the better is really hard and you are likely to encounter resistance at every step of the way. I assure you that it is worth it in the long run.

If you do not want to do this or are unsuccessful at getting buy-in on performing preventative large scale maintenance, you should take a deep breath between pebbles. Eventually you will be fed enough of them that you are going to choke to death on them. Hopefully you can successfully convince enough people that it is worth doing something about those pebbles before that happens.

At any rate, if this all sounds like rubbish to you then maybe you just like to eat pebbles. See how many pebbles you can eat in a business quarter—then try to beat that record!

Thank you again for reading along. I hope you find some value here. I love comments and questions in response to my weekly articles—feedback is a gift. Failing any feedback, I will give you some more of my thoughts to consume in deep contemplative silence next week!

Now that we are rolling into the end of the year and most of you are doing holiday things, I thought I would find something a little warmer and fuzzier than normal to write about. So I am going to talk about one of the things I work hard to find with teams: Shared understanding.

Over twenty years of being involved in software development I have seen every flavor of process management. I have signed off on weekly status reports for ISO-9000 certified waterfall releases, and I have released software without a single Jira item logged against it.

Through all of these processes and philosophical arguments with people over what is and what isn’t agile, I have come to understand that different people and different industries tend to ship software effectively according to different rules.

Writing dispatch software for emergency works and 911 systems requires more deeply embedded waterfall design and structure. Making entertainment software tends to work better with shippable masters that are iterated upon using agile methodologies. I acknowledge that this is my personal experience speaking and that everyone has their own preferences for how to get stuff done.

One thing that is universally in common in all of these systems is the need for the people who design and plan for a product, and the people who build and maintain a product, to have a means of negotiation on what done means. Sometimes the things that are asked for require refinement or introduce special edge cases that need to be accounted for. Sometimes the requirements for the end product are not even possible as defined at the start.

One thing I have come to realize, through building lots of software and managing lots of teams, is that the best outcomes all had one thing in common—everyone was working to improve their shared understanding.

I am going to illustrate what that means through a badgile story. Yes I made up a word. Bad Agile equals badgile.

Once upon a time I was working on a consumer-facing website that had commerce integration. We partnered with a credit card processing company and we had a two week sprint to finish a set of tasks related to making credit card transactions work.

One of the developers picked up a task to generate a token that gets surfaced to the end user when a transaction gets approved by the credit card company.

At the end of the sprint, the developer in question demonstrated the api call and showed how entering in valid credit card information resulted in a Unique GUID that gets created and stored into the player’s account and added to his payment history.

The project owner shook his head and said “No, that is not done. This token is not human readable, I cannot approve the story.”

Record Scratch Noise… Wait What?

We stopped the meeting at this point to have a sidebar conversation. What we had here was a hidden acceptance criteria that was not communicated in the story, nor was that intent clear anywhere. On the surface, I can see the value of having a token that can be read aloud to a customer service agent over the phone, but that is extra work that was not in the scope of the original work request.

The good news is that everyone had an “aha” moment about this and we were able to declare that the work was done, and that we added a new story to modify the GUID to be human readable as the next task.

This is about the best example of a lack of shared understanding as I have ever seen, and I use it to help people understand its importance.

When I am working with new teams I do my best to try to introduce a few core concepts to help make them successful. The first and easiest is the notion of quorum, taken from multiple terms in student council while still in school and also taken cheerfully from Robert’s Rules of Order;the book that everyone loves to hate.

When I attend a meeting, I make sure that all the stakeholders are in attendance, and I am eager to ask people if we have quorum. If we do not then there is no point in starting the meeting only to regurgitate large amounts of it when all of the relevant stakeholders arrive.

The next thing that I do is teach the notion of shared understanding, which is one of the most important things I do when working with a new team.

I do not think that you can build great software as a team without shared understanding.

I also do not think you can develop shared understanding quickly without pointing out its importance.

It turns out that shared understanding is a powerful safety word for software development. I am the first to tell everyone to pump the brakes when I am confused, whereupon I will freely state “I do not think we have shared understanding here”.

It is a great way to get everyone to stop, think about what they know, and more importantly, how to communicate what they know to other people so we can all agree on the knowledge.

If you can get your teams to a point of declaring a lack of shared understanding, then suddenly the focus rapidly becomes how to communicate that understanding from the person who has it, to the person who does not.

Over time it is a beautiful process to watch. The act of declaring a lack of shared understanding helps people to refine their communication tools and to improve their ability to define and accept work.

The next time you are on a team and things are not working well, you should take a step back and ask yourself: Do we have shared understanding here?

If you do not then I suggest you declare it to all parties involved and try to figure out how to reach shared understanding together.

Thank you for reading along. This week’s article was short and sweet. I look forward to writing more articles next year, and as always I treasure your feedbackey-words, your likey-clicks, and your linkey-shares. The more social reciprocity you give me as adults, the less I will use cutesy-wutesy words to endear you to perform said activities.

There are many things I learned in my career that I could never explain to a younger version of me and expect him to accept it and understand it. Today we are going to talk about one of my favorites. We are going to talk about being right.

I was painfully right early on in my career way too often. I recall many times sitting in a room patiently waiting to say something that I knew either was true, or soon would be true. Maybe I wasn’t sitting patiently all of the time. Sometimes I would steamroll the conversation to get it out there. Regardless, even now I can feel the awkwardness of many meetings after making a powerful statement that would pour cold water over the mood of the room.

It was at least six years of being “that guy” before I started to realize it was a spectacularly unhelpful activity. About half of the time I would say something that was painfully true, and nobody wanted to acknowledge it or change it because of the size and nature of the pain. We can chalk those times up to the sunk-cost fallacy and move on. Equally frustrating were the times when I would say something horribly true and nobody at the time understood it, or agreed with it.

The downside of both of these activities is that if you are the first person to bring these things up, or are the largest source of this kind of information in your organization, it starts to rub off on you, and people will avoid you like you have cartoon stink-lines emanating from your body.

I recall being on a team creating a games publishing lineup and learning from a very experienced designer/producer how to model revenue and predict sales. We did a pretty comprehensive analysis of our competitors’ products, and projected initial revenues for our own products. My friend and I were very proud of ourselves, and decided we would share this with the rest of the company.

Our prediction was not well-received and I recall the horror and puzzlement on everyone’s faces. Part of the problem is that we predicted our own product would outsell everyone else’s products. The fact that a month later, we proved to be correct was not a soothing balm to the stinging rebuke we received organizationally. We were castigated as troublemakers from that point onwards and nobody wanted anything to do with us despite the fact that we not only gave sales projections for our products, but also gave advice to people on how to improve their products to sell better!

I think this particular case was when I hit rock-bottom. I was thoroughly confused that the two people who had the most revenue-impact on the business and had demonstrated the most knowledge and foresight were pretty much shoved into the corner to sit down and think about what we did wrong. And so we did. We sat there for a long time and neither of us could make sense of the situation.

I watched a great presentation yesterday where someone told a similar story about making logical presentations of information and having it rejected. I realized we both had a very similar epiphany moment, although she reached hers professionally way before I reached mine.

What we both learned is that sometimes people do not want to have the truth poured over them like scalding hot water—you have to weave it into a story for them to accept it as their own.

Some of you know I have a deep love of story telling. I love movies and books, and I weave much of the more interesting parts of what I watch and read into my own Dungeons & Dragons game. It took me a while to make the connective leap from from story telling for fun to storytelling for work.

It turns out that is really important. I heard in the presentation I watched yesterday that there are six stories people tell. I have read in science fiction literature that there are twelve. I ordered someone’s book yesterday to learn about six types of stories because six is easier to remember than twelve. Yes, I am that basic.

I am going to put this out there as some low-hanging fruit for you, Mr or Mrs Right: If you find yourself getting shoved into a corner because you are constantly right about things, you are going to have to figure out some new tools for helping people to understand your point if you want to rejoin the other kids in the classroom.

So let’s go over story telling and some additional tools to help you get your point across to people.

Storytelling

As someone who was a product evangelist, a part-time writer and a conference presenter, I cannot stress the value of this skill enough. You have to be able to tell a story. I have some innate storytelling abilities I have used intermittently over the years, but I believe I do not use these enough professionally. Even now I am ordering my first storytelling book because I believe I can learn to do this better and more frequently.

Consensus Building

At a previous employer, we had these meetings that people dreaded called “Architecture Reviews”. The reason they dreaded them is because people would go into the review, present a plan, and then sit there while more senior staff tore it apart in front of the whole room.

Some of the people on our team experienced slightly better success with these for one reason: They set up separate private meetings with stakeholders to review the plan up front. If you pre-sold your architecture document to senior staff, generally they would go over all of the roadblocks and speed bumps that needed to get addressed.

Many people would use the meeting as a way of getting people to look at their plan, and if it was the first time people saw it, someone would start picking at it publicly. Generally this critique is delivered by a senior staff member, which sets the tone for everyone else in the room. Everyone would suddenly sharpen their swords and find something to nitpick as a part of the festivities. If this was your architecture document, you just had a very bad time.

If you spend the time with subject matter experts privately to go over the material and explore facts, you will get a better outcome when discussing it publicly. The same goes with being right about something. Go over it with everyone in advance individually to get them to figure out options or minor course-corrections on their own time and dime. If you publicly flog them with some kind of truth, you will likely get a similar negative reaction that will take all of the wind out of your sails.

Verifiable Data

If you are struggling with getting your point across, it never hurts to appeal to authority. If you can demonstrate the validity of your data, that certainly helps your position. Making sure this is combined with the above two never hurts. Make sure it is clearly spelled out. “Do YoUr OwN rEsEaRcH” is not a good way to get people to be persuaded to accept what you are telling them. I may have been guilty of this far more than I would like to admit.

Soak Time

Bad ideas are like stubborn stains—sometimes they need to be soaked in something to be removed. Fun fact: The duration of one meeting is insufficient soak time. For anyone out there who ever sat in a meeting with me where I was furiously trying to pave over your stupidity, consider this to be a part of the apology I owe you for not giving you more time to figure out that I was trying to help you in my own horrible gaslighting way.

For small ideas, you might want to give people a day or two of soak time. For big ideas, be prepared for the window of time to be a week, or possibly even a few months.

Dark Powers

When all else fails and you really need to do the right thing, you can always throw in the towel and go crying to their manager. I will ask you to exercise caution here, because if you go to this particular font of dark power, it is a dangerous place from which to extract utility. It is addicting and all-consuming. Do this privately and gently and cautiously. I have done this a few times publicly and all it netted me was putting my name at the top of other people’s nasty little revenge books. I put this here as a last resort and something I seldom did except in extreme circumstances, and I was punished in different ways for each of them.

If you are going to someone else’s boss to rat them out for doing something dumb, just understand that it is functionally equivalent to violence, and violence is the last refuge of the incompetent. This means you are unable to solve the problem on your own and you are asking someone else to do your work for you. If you are going to go there at least sit down and write out the problem and self-soak in it for awhile so you can at least develop better tools for the future.

So there you have it! It sucks to be right, and it sucks even more to be the messenger that gets shot for communicating that. Try to develop some tools to help communicate that better to people. 

There are ways to get your point across, good and bad.

It will take some time to develop the right tools to make sure you can get people onto the same page as you, and even for me this is a work-in-progress.

So here we are at the end of today’s rambling screed of learnings. I hope you all can absorb some kind of value from the summation of these keypresses.

If you think there is someone in your life who could benefit from this message, think of how you can convey it to them without just passive-aggressively linking them to this article and saying “HEY DO YOU KNOW ANYONE WHO COULD LEARN FROM THIS” and laughing to yourself all the while—or possibly crying.

In any event, stay safe out there and give me some feedbacks. I am not yet trending on twitter, and I am not yet twerking on tiktok. I cannot decide which of those is more important for me in 2021.

So here we come into the end of 2020 and it is time to wrap up my twenty lessons in twenty years. It has been amazing to hear from the many people who have accompanied me on this journey; they have offered both feedback and encouragement for these subjects. It is hard to capture in words how much I have appreciated learning all of these things over the years, and I sincerely hope that people can use what I have written on their own quests for meaning.

If you are joining us late, here are links to the original three posts.

Without further ado, here are the last of my twenty lessons:

Choose Your Boss

I think that this is probably one of those things that you should learn earlier in your career than I did in mine. Your boss really matters for quite a lot. Your boss is more than someone who approves your expense reports and decides how many stars you get in your end of year review. Your boss ought to be considered a source of training, guidance, and experience. I will admit to having bosses I did not enjoy working with, and many I have considered great friends. When I am hiring other people, I try to market myself for what I can do for them as a boss to help them accelerate achieving their career goals. It is only recently that I realized that I never put my own early career choices through that lens.

It really matters for more reasons than I can put words to. There are a handful of people I have worked for whom I would work for again. There are a slightly larger number of people I have worked with as a peer whom I would work for as an employee. There are even a small number of people who have worked for me whom I would consider working for similarly.

If you find yourself in a situation where your boss is not helping you enough, then you should contemplate how to fix that. You should give that person the courtesy of a year if at all possible and then figure out how you can gracefully transition to something else that makes more sense for you.

Put Your People First

This is also one of those things that took too long for me to learn but I truly appreciate. You have to put your people first. I have suffered for this personally a few times over the years, but without regret. I have forsaken some promotions and tried to structure compensation and rewards according to this principle. There was one time when we were working at a struggling startup when I suggested to leadership that we offer each employee in the  company a $1000 reward for hitting a very important milestone. We jokingly called it “The Grand Bonus”.

This may not have meant much for some of our most senior people, but I will say that it made a lot of difference for our more junior team members and people in roles that were not as heavily compensated as engineering.

Quite a few people on the team realized this, and I think they worked harder to get the milestone completed for the sake of making sure everyone was rewarded.

Watching people on this project, and how they adopted a caring attitude for their team in taking this project over the finish line for the benefit of others was humbling.

There are many times I have seen people go above and beyond to help other people professionally. 

At the same struggling startup, when the end finally arrived, I spent three weeks after we closed our doors ensuring that I could do the most to help place our people into new roles and careers. That was painful for me financially as a parent; however, at the end when we had finished placing the team members into new roles I felt like a great burden was lifted. I would work with just about everyone from that team again—they were all amazing people.

The Serenity Prayer

I have commented on this before. I find myself quoting variants of the Serenity Prayer to people at work:

God, grant me the serenity to accept the things I cannot change,

courage to change the things I can,

and wisdom to know the difference.

I do not know how much more explanation that needs. Quite a few of the lessons I have learned over the years revolved around me trying to move items from one category to another. There are many times I tried to change things I could not, and many times I did not possess the serenity, or patience, to accept things that I could not change.

It is a great first-pass filter for events happening around your workplace and in fact the whole world around you too. 2020 as a whole, for example, is a master class in things we probably could not change. I am sure we are going to look back at this year for all of the things we did and scrutinize what we did with that time and how we applied serenity, courage, and wisdom to reach those outcomes.

Manage Excessive Risk

I have recently been speaking with one of my peers about their long-term career goals and how they can get there from here. Quite a bit of the road ahead of them is fraught with risk. The challenge now for them is that they will not get to take on some of that risk at their current company, nor will they get a job tackling that risk if they make a lateral move to another company.

This puts someone into a real chicken-and-egg situation. There is a solution to it, however. They are going to need to make a substantive life-change to increase the risk profile of their career.

If you are a director-level person and you want to break into your first vice president role, you might find that all the seats in your current company are taken for the next few years. There might be a clear succession already established or you might have better-qualified peers. This is one of those situations you should look at carefully for what you ought to do next.

Making the transition from one category of responsibility to another is hard. This is one of those times when it might make sense for taking a professional sidegrade. The challenge here is that you have to look at the size of the business and the size of the role accordingly. If you are too long in your current role at your current employer you might need to find a smaller company with a smaller number of existing directors and vice presidents to increase the chance you will get a viable promotion that suits your career goals.

The challenge is that this constitutes a very significant risk.

If you are only making changes to the risk you are managing at work, you are not going to accelerate your ability to transcend it. Sometimes you are going to have to take on more responsibility professionally than people will give you currently, and the only way to do that is to take a leap of faith into a new role.

This is an excessive risk; however, if you do not take excessive risk, you will not reap outsized rewards.

I am now spending some of my time with former coworkers helping them evaluate their career goals and the amount of risk they are managing. Some of these conversations are weeks old, some of these conversations are years old. In almost all of them, they are taking excessive risks to accelerate their careers.

It is terrifying to do that, honestly. I am relieved for them that they are not doing it alone, and happy to help coach them through the evaluation process and sometimes even the negotiation process that ensues.

Make Time For Little Things

The last lesson I learned that I want to leave you with is the importance of the little things. Downtime. Books. Hobbies. Cooking. Side projects.

Please make time for little things.

Writing every Sunday morning for me is one of the little things, as is a Saturday morning ritual to make a full pancake-and-eggs breakfast for the family. I make time for these things the same as I make time two nights a week for World of Warcraft raiding.

No one will force you to have a hobby or to do little things in your life for yourself or other people. You are going to have to carve out that time explicitly and just make it happen.

I am pleased that, in the most recent months, I have inspired someone to commit to writing more, as well as helped a friend build a small application that we will be publishing and talking about here in the new year.

With everything going on in the world today I picked up a small gardening hobby as well as committed to taking thirty to forty minute walks every day since I no longer commute to work.

I also explicitly make time every week to connect with someone not related to my current job. Either I am reconnecting with a former coworker or classmate, or meeting someone new on Lunch Club. Almost every single one of these meetings has been instructive or educational for me or for the other participant in some way.

Take a look at your weekly routine and if you are consumed with obligations, you should take a step back and ask yourself what you are doing for yourself, and what you are doing for your family. It is easy now, with all the electronics, to be answering emails and Slack messages around the clock. World events may have infected you with an unrealistic sense of urgency to be omnipresent professionally. I am not certain that is healthy. I have taken some mindful steps to ensure I have mental space and time for little things.

You should too.

And that wraps it up for my twenty lessons! Please share my statements of supreme obviousness on the socials, tweeter, facebake and linkum. Give me some likes, clip-claps, and stars. The more you reward me for writing, the more I will feed you. I believe this is equitable, and I hope you agree.

Thank you for reading along and I hope to engage with you in deep discussions on things to help us all be a little better every day!