Category: Monocategorized

This past month was largely conversations directed at people who are doing some soul searching in their career. Does their employer value them sufficiently? Are there jobs that they are interested in? Do they have the tools to go find a new job?

In the process of having these conversations with some friends who were hiring managers, I talked about how important it is to value your great engineers.

My friend asked me the following question:

“What makes a great engineer?”

There are a lot of attributes I have seen in great engineers over the years. Many great engineers possess one or two of these attributes and some of them possess more. I do not know that I have met a great engineer who was excellent at all of these things.

Shipping software

First and foremost, the best of the great engineers I have worked with deliver software over the finish line. There comes a time in every project where you have a list of remaining issues and someone decides “we will ship this today.” Very few projects are perfect and even fewer are defect free. A great engineer will take software over the finish line and deliver it to production.

I have met some very capable engineers who can get a project to eighty or ninety percent, and then they require someone else to help them over the finish line. Shipping software is a key attribute of a great engineer.

Communicating ideas

Another attribute for a great engineer is the ability to communicate ideas. This can be both translating ideas into layman’s terms or it can be expressing the intent of a system so a more junior engineer can maintain it long after that engineer has left the company. I want to talk more about the latter than the former. We all make jokes about opening one of your projects from five years ago and having no idea what any of it means—and when I say five years, I mean five months. Great engineers will leave highly maintainable code in their wake with sufficient breadcrumbs and tombstones that someone can pick it up and maintain it without too many surprises showing up in production.

Recognizing patterns

Recognizing patterns is a very important attribute of a great engineer. I believe it is one of the most important skills to have as your engineering career goes into the world of Staff Engineer/Architect/Director of Engineering. If you can identify patterns of behavior of people and software, you will be able to create solutions you can apply to those patterns consistently over time.

Choosing software

This is probably the hardest attribute for an engineer to learn. Being able to make a pragmatic choice for a software language, platform, or software package is really important. Too many engineers attempt to apply new software to a problem. It is great to experiment and learn new tools. Sometimes production environments for large projects are not the place to do it. A great engineer will sit down and evaluate the requirements of a project and the capabilities or interests of their team before choosing software. It is dangerous to choose software in a vacuum. What percent of the team would be comfortable with that? Who in the organization will be strong enough to be subject matter experts in it? There are a lot of things required to make a decision on a language, development tool or software package. This is especially true for larger teams. If you are a software engineering leader and you mandate a big change in your software choices for the team, be aware that you will create delays, frustration, and employee churn. If you are a more junior software developer and you are bringing in new tools to a team, it is better to have an up front conversation with the team and team leadership about the pros and cons and include a prototype of some kind to demonstrate what the value will be.

Deleting code

You might expect me to say a great engineer writes lots of code. There is an even split for the most voluminous software writers I have worked with between “great engineer” and “I am firing this person”. I do not think there is a good correlation between volume of code created and greatness.

By contrast, I do think that great engineers are experts at removing code. Software engineering projects are complex beasts. Any time people can simplify software or reduce it in complexity is a good thing. Deleting code helps reduce noise in the codebase. This is very important for software systems that are mature. I have seen far too many people chasing down urgent defects and serious issues in large codebases where they have wound up wasting time in dead code. Great engineers help to reduce that distraction and inefficiency by cleaning up after themselves and other people.

“Software spider sense”

I wish I had a better name for this attribute of a great engineer. Great engineers have an uncanny ability to identify complex issues in software. I have run into my fair share of issues in production environments that defy the ability for teams to reproduce them and address them. I refer to hard-to-find-and-hard-to-fix issues as “Heisenbugs”. This is perhaps one of the rarest attributes of a great engineer. I can name less than a dozen people who I know who have a magical ability to “think like broken software” and work with a production environment to isolate and categorize symptoms that result in fixing or mitigating defects.

Comfortably uncomfortable

The last element of a great engineer is that they are very calm under pressure. This is an attribute that is the easiest to acquire through repetition and exposure. Dealing with production issues and urgent deadlines is stressful. It is also a crucible of fire. If it does not break you, it will forge you into a great engineer who will be able to step into a dire emergency situation without getting stressed or anxious and help you to focus other people’s energies and efforts to address the issue.

Thank you again for reading today. I make a living helping engineers unlock their greatness and I consider it to be pleasurable and rewarding. There are probably other attributes that great engineers possess—I may revisit this article in the future with an updated list. If you have worked with a great engineer and you think that I have missed one of the key things that makes them great, I would love to hear about it!

PS: Amazon.com suggests that this is a frequently repurchased item on their website, so I am attaching a shameless affiliate link that will result in generating revenues for yours truly if you click here and become the proud owner of a case of Orange Mango Recovery Water . I have now made more than one dollar as a professional Amazon Affiliate. Eventually I will unlock the magical powers of influencer marketing to turn this into a livelihood.

After last week’s article I gave a few people a courtesy review of their resume.

I am always happy to look at someone’s resume and give them some feedback. That is just as true this week as it was last week as it will be every week. Do not be shy. If you are reading this post, you are two to three clicks away from figuring out how to reach me via email or socials.

Unfortunately, most people do not like to click two or three times. That is why I am really crappy as a paid Amazon Affiliate—even when I pimp delicious unsweetened cherries. To make your lives easier, I am going to give a quick review of what I look for in a resume.

Is the resume reasonably sized?

I am not a fan of a ten page resume. There are times when it does make sense, if you are including speaking engagements, publications, patents, or significant experiences. I think of a resume like an Executive Summary—I want it to be short and concise. The ability to distill your professional experience down to a few pages is important to me. I expect one to two page resumes for people who are relatively early in their careers, three pages for most of their career, and maybe four pages if they have over fifteen years of experience.

Does the resume feel consistent?

The next thing I look for is the verb tenses for job descriptions and consistency across job descriptions.

I appreciate reading sentences that start in the past tense to describe accomplishments:

• Increased Revenue 15% through deployment of a new feature
• Developed a hiring pipeline to scale the engineering team
• Coordinated GDPR requirements with legal and platform team

I struggle when someone starts with this kind of formatting and in the next section of their work experience they swap to a different format:

• I built a new framework for cross platform mobile development
• I was responsible for three key releases for new titles.

I deliberately added a period to the second sentence as another form of inconsistency.

If possible, try to make sure your various job descriptions remain on the same page. I have seen far too many resumes that are three pages where the third page of the resume is just one line of text.

Does the resume include a mission statement or career goal?

This is not as important as other parts of the resume but I do love it when someone has a strategic career goal and can explain it to me.

You run the risk of someone reading your long term career goals and deciding that the role is not aligned with them. That is probably for the best, because that will become evident to everyone soon enough after you start the job anyway.

Are there specific successes or metrics included?

I like to see specific outcomes included in people’s career accomplishments. Did revenue increase by a percentage? Was there a decrease in site outages? Did the product ship on time or under budget? The more senior you are in your career, the more important this becomes.

Are there too many errors in the resume?

If you have too many typos or grammatical errors in your resume, I get nervous about the quality of work you will leave behind for someone else to maintain. I have a three-strikes policy with peoples’ resumes. If you have one error in your resume or possibly two, you might be sending out your resume under duress. If there are three or more things wrong with your resume, I become nervous about how to keep accurate documentation and accounting for your work output.

Is this person just a bad resume writer?

After I have finished going through a resume with my blowtorch and pliers, I take a step back and ask myself one last question: “Is this a solid employee who is just bad at writing resumes?”

If I believe this is true, I get pretty excited about interviewing this candidate. If they are a good worker who is bad at writing a resume, then they will get fewer interviews and I have a better shot at hiring them.

It is also something I can help fix. I am really happy when I can teach something really valuable to a potential employee.

How can you tell if someone is just a bad resume writer? That is really the million dollar question here. Unfortunately, I have yet to be able to articulate it well to other people. I am still working on describing patterns I see in a resume that indicate a really compelling candidate who simply needs to work on their resume writing skills. “I know it when I see it.” I would love to be able to explain it better.

You should take some time to give your resume a once-over. If you have a friend who has experience interviewing and hiring people, It would make sense to ask them to give your resume a once-over too.

If you have no friends, or none of your friends have experience interviewing and hiring people, then shoot me a note. I am happy to give it a once-over and ask the questions I have outlined above.

Thank you for reading along as usual. This post is not brought to you by the shameless profiteering of my Amazon Affiliate Link nor is it sponsored by my tool to help TTRPG DM’s improve the quality of their stories (derfdice.com). Raid: Shadow Legends has not driven a truck full of nickels over to my house and I am not getting an endorsement from the calorie-free smooth delicious taste of Diet Coke: Enjoy Coke! 

Maybe I should put half of my random ranting behind a paywall over at Substack? Information wants to be free, but John’s minivan also wants to be paid off.

See you all next week.

This is a follow-up post to git payed.

If you have just finished going through your end-of-year review and did not get what you felt was reasonable, now is the time to start considering your BATNA. If you don’t know what that means, please read the above post from last week.

If you want to get your hands on a BATNA, you are going to have to start applying to other jobs. The good news is that there are a lot of jobs out there. The bad news is that you are going to struggle to get one.

The problem is that the interview process is exhausting and filled with bureaucratic nonsense. If you are like most people, you probably have not interviewed in a long time, or have done it frequently enough to really do a good job at it. Maybe you have been in the same job for several years and your skill set is adjacent to modern technology stacks (meaning some of the machinery in the interview process is chewing up and spitting out your resume before anyone even sees it).

Depending on your skill set and your urgency to find a new role, you might be operating at a disadvantage. You should be honest with yourself about your position against other candidates and what you feel are your strengths and your weaknesses. On more than one occasion a few friends of mine have gone into an interview for their dream job and did not succeed in getting it. There are a variety of reasons for most of these and in at least one case the rejection was entirely preventable by some upfront coaching.

So what can you do to prepare yourself to interview for a job when you need a new one?

The best thing to do would be to interview for a job when you don’t need one.

If you see a really interesting job that is available, it might not hurt to reach out to one or two other companies, especially if you see a competitor is hiring, so you can get some practice at your interview. Especially if it is a company you REALLY want to work for. The practice will be worth it. If you get turned down from a company that you really want to work for, you might also realize that you conducted your interview differently from one of the other companies. I have seen a number of very enthusiastic candidates try to jump through hoops to get a job just a little too eagerly, or choke because they started overthinking things.

If you like sports metaphors, you can think about this like batting practice. The best hitters in baseball do not just show up one day and start slugging the ball out of the park. They are in the cages hitting the ball. They have people soft-tossing to them on the field. They are watching video footage of previous games. All of these things help them increase their performance when it matters.

If you think that is creepy or weird, I can respect that. I do think that if you arrange a few additional interviews you get a few things that are worthwhile. You may get a more competitive offer to increase your leverage in negotiating a salary. You may also get a sense for what tools or technologies are common today and what “state-of-the-art” looks like by talking to multiple companies. You will definitely get experience in managing the stress and negative energy that comes from being in a high-stakes interview where you are trying to demonstrate that you are worth being offered a pile of money.

These are not the most important things to me when I interview with a company. The most important thing for me is to understand their challenges and what kind of people I am going to be working with.

Quite often I am being recruited into leadership roles and generally will be meeting with peers, or potentially with staff members who will be joining my team. In many of these cases the first thing I want to do is to break the script and take control of the interview.

When interviewing with peers, most of them will not be in engineering roles. I break the script with them to understand what it is they are currently not getting out of their engineering team, or what they see as current problems. This helps me to relate their current problems to situations I have dealt with in the past and how I was effective at generating positive outcomes.

When being interviewed by technical people, half of the time you will be asked questions that you might not be able to solve. This is one of the biggest fears for most engineering candidates. If you are being interrogated by someone who knows something really well and you know almost nothing about it, your best bet is to just own it. I had at least one interviewer in the past ask me a question and I did not have a great answer. I took it as far as I could and then changed the subject to talk about an interesting project that I had just finished. It happened to be written in Golang, and I had some particular issues with using Golang in that capacity. The conversation resonated with the interviewer immediately. It sparked off an interesting discussion on language choices and how to make decisions on that level for various teams.

This is not a tactic that works well all of the time. I have found times when my attempts to take control of the conversation made people uncomfortable or irritated. I generally do not get upset when I get the “best of luck with whatever you do next because it is not working here” email. It honestly feels like I dodged a bullet.

I heartily recommend taking control of your interview, especially when the interview is being conducted poorly. If you are asking a potential VP of Engineering to get up on the whiteboard and solve your favorite brain teaser question, you might be doing the wrong thing. It is in your best interest to point that out. It might be the case they actually do not even want a VP of Engineering, but a very senior coder who will help put butts in seats if the next round gets closed. When this happens, many of these companies will proudly proclaim “we are a lean company”. Over the years I have learned “Lean company” generally means “poorly managed”. Most of the time they just expect everyone in the engineering organization to be spending half to three-quarters of their time writing code. That works great for ten people and not so great for one thousand.

If you spend enough time interviewing with different companies, you will develop a knack for figuring out what a company is actually trying to hire for. Sometimes they do not really know—they just know they need to hire someone to do something differently.

This probably does not work so well for you if you are interviewing for “Software Engineer I”. 

That is okay. Sort their linked list, answer their Big-O question, or just steeple your fingers and say “this is a great place to use MapReduce”. If they give you an obvious brain-teaser question, it might be worth saying that their process encourages cognitive bias towards a particular set of employees. Just move on when they ask you to leave the building. You did not want that job anyway.

Another benefit to some practice interviews is understanding if your resume is any good. If you applied to five or six jobs and no one responded, you might want to see if there is something wrong with your resume. A good resume should be able to get you an interview.

If you do not manage to get any interviews, you should ask someone who has some experience interviewing people to conduct a mock interview. There are lots of places that have practice interview questions (some companies will actually construct their list of questions from these books) and lots of people out there who can do a mock interview for you.

If you are struggling with your resume, feel free to reach out to me. I have looked at thousands of them and can generally give you some kind of actionable advice on what to do to improve yours.

Who knows? If your resume is solid enough, I might even recommend a company or two to check out, because I think there is a fit.

Thank you again for reading. You might have guessed I am very passionate about hiring and team building. I am also passionate about eating unsweetened dried cherries. This link may contain a referral code that will make me crazy rich if you all go buy these cherries. You don’t buy the books (which I have not read) nor will you buy the t-shirts (which I do not own). Maybe you will go buy a product I actually really like? I do not know how all of this works.

See you all next week.

Many software companies will go through a period of time when they institute a series of reorgs. There are generally two reasons for this. The first reason is that they are growing and they are shedding their old org structure because it needs to adapt to the increased size of the team. The other reason is that their org structure simply does not work.

There are many ways to think about doing a software reorg. Many people will talk about the need for product oriented organizations. Many other people will talk about the power of the matrix organization. Someone will invariably invoke Conway’s Law and before any final decisions are made another person will inject the notorious “Will this scale?” meme.

I have been in the middle of a number of software reorgs over my career. In the last few I noticed something very interesting.

It did not really matter what model was being applied to the eventual end product. Whether it was a matrixed organization, or one with teams dedicated to specific products or verticals, they all had one thing in common: The final organization matched the capacities of the team leads and managers.

Without much success, over the past few years I have attempted to explain this to people in the middle of their own reorgs.

Whether the reorg is happening top-down or bottom-up, there comes a time when someone has their favorite slideware open and they are attempting to put names into hierarchical boxes. There is a pool of unallocated leaders that gets assigned one-by-one like picking kids for your dodgeball team at recess.

About half to three quarters of the attempts to reorg a team will break down at this point because the chosen model results in too many unpicked managers/leaders, or they are too skewed towards one particular team or structure. I have stared at enough broken org charts at three o’clock in the morning to realize this is a recurring pattern.

Regardless of what model you choose to get those boxes filled in and all of your leadership allocated, you will always wind up going over each team and asking yourself a set of questions:

• Who is going to quit because of this structure?
• Who will need help supporting their team and/or products?
• Who will reap the most learning and career upside?
• Who will be unhappy about this?

There is some calculus that the management team will do in their head to determine churn, team satisfaction, and “what gaps will we need to manage through”.

At the end of that calculation there is an inherent “Yes, this will work” or “No, do it over” boolean response based on some unspoken feeling that one of those three variables is not within acceptable parameters.

If a reorg makes your team unhappy, or it causes your best people to leave, or leaves too many important things without an interim owner, then it does not matter what model you employed to get to that point. You will need to feed your homework to the dog and do it over.

I am going to call it out in the hopes that someone writes it down on Wikipedia someday for posterity. Heck, you can even call it “Szeder’s Law of Team Reorganization” and make me as famous as whoever the heck that Conway guy is.

“No team reorganization will succeed unless it takes into account the capabilities and satisfaction of the existing team”.

-John Szeder

I have run through this process enough times now that I sit down and start with the team allocations first. I try to pair up the most important people and the most important leaders with the most significant work. I make a list of people who will quit their jobs if given horrific assignments and attempt to assemble a working model that will make the fewest possible concessions to the team.

If the organization is big enough, then you might only be able to do this down to the director or team lead level. You might have a team big enough that you cannot go any further on your own. At that point it is worth it to engage your leads and conduct ranked team wish lists, a team draft, or something similar in order to construct viable models that make the most sense.

No reorg is perfect and you will generally have regrettable losses whenever you put up the final output of your efforts onto a screen in a company meeting. It is important to sit down and make sure you minimize those losses and successfully have an interim plan for any gaps that exist through a reorg.

If you do not do this then you will discover an unfortunate truth: If your reorg is not successful, you will have to do it again. Each successive reorg will have more churn and create more unhappiness, and suddenly you are trapped in a vicious cycle—reorgs all the way down.

One of two things will happen at that point. One option is that you will accidentally get it right, possibly through the team shrinking to the point that it is a much simpler problem. The other option is that you will have realized that your reorg approach is inherently flawed and will have applied a better filter to your reorg plans, managing to design one that takes into consideration the organization’s growth and retention based on the individuals in the organization themselves.

I hope you keep this in mind the next time you are staring at a list of employee names and an empty set of boxes in reorg-version-23.ppt at three o’clock in the morning.

If you do not, at the very least you are about to get really good at rolling out reorgs. Hashtag silver-lining.

Thank you for reading along! I hope you learned something valuable in today’s short post. If you did not, then why not buy this funny titled book (which I have viciously hidden under a short link, in an attempt to gaslight you for a click) that I randomly found on Amazon. Per Amazon’s Affiliate Policy: I must urgently warn you that I will enrich myself unfairly and gleefully indulge in shameless profit-taking should you click on this link and make a subsequent purchase. I hope to see you again next week for another random conversation on engineering and software product development!

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

Record scratch noise.

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

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

Do you like your boss?

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

Do you like your team?

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

Do you like your work?

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

Have you been in your current role for too long?

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

Have you been at your current company for too long?

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

Have you been at your current company long enough?

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

Are you getting compensated well enough in base pay?

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

Are you getting compensated well enough in equity?

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

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

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

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

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

What do you have to lose?

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

No I did not get the covid.

See you next week!

One of the biggest lessons I have learned professionally is that software development is a team sport. I can mentally picture a few people hitting their caps lock key and getting ready to tweeter at me. Maybe the better phrase is “the business of software development is a team sport.”

I did not play many team sports as a kid and I was not a big fan of watching most sports on television. I think I developed an appreciation for the intricacy of team sports when I started to volunteer my time as a coach and as a referee for youth sports for my oldest son—I learned a considerable number of valuable lessons from that experience.

I spend a lot of time regurgitating the phrase “shared understanding” at work. I think that you get much better software outcomes if everyone has shared understanding. I appreciate it when I work with people who ask good questions when they do not have shared understanding. I also appreciate it when people write their product definitions for development teams in a way that fosters easy shared understanding.

I have talked about shared understanding in the past and will probably talk about it again in the future. Today I want to talk about something else. I want to talk about baton passing.

The term comes to us from relay races. I think a lot of activities in software development resemble relay races and include moments where people must pass the baton from one person to another.

Sometimes people are not aware that they are in a relay race. It is really hard to win a relay race if you do not know you are waiting for a baton, or if you do not know you should be passing a baton. In software development terms I have seen people finish a task that someone else is waiting on without any communication that the task is complete. I refer to this moment as “dropping the baton”.

You might see this pattern at work yourself. It is a dangerous pattern because it creates inefficiency and delays. Even worse, it can create emotional baggage as people try to pin blame on folks for the baton-drop. 

It is not important to blame someone for dropping the baton when it happens.

Whenever I spot a dropped baton, I try to do two things.

The first thing is to make sure that the baton gets picked back up. You should get back in the race as fast as possible.

The second thing to do is to figure out how to prevent the baton from getting dropped again.

This is harder than it sounds. It takes time to build good communication habits. I generally tell my relay race story to people once or twice a year in any given organization, especially after witnessing one or two baton-drops.

I have seen a significant number of baton-drops in the past few weeks and thought it would be good to write about it.

I may have even dropped one of those batons myself.

It is important to make sure you know what relay races you are running as a part of your job. It is good to communicate your expectations around baton passes to people in front of you and to people behind you. The more explicitly this gets communicated, the more successful the relay race will be.

I do not have much more to say on the subject.

I need to go pick up some batons and make sure that they do not get dropped again in the future.
Thank you for reading my short anecdote today. I apologize for not having a funny closing statement. Instead I can offer you a chance to slide some sweet, sweet nickels into my pocket by putting a referral code in a hilarious business poster you can put on the wall to gaslight your coworkers (Per Amazon’s Affiliate Policy, I must disclose that I get crazy-mad profits if you Buy This Sweet Merch).

I am back! I took a week off to travel with my family and spend some time in the real world, if there is such a thing.

A friend of mine once asked me a question that stuck with me. 

“I have been doing startups for twenty years, how come I do not have Mark Zuckerberg kind of wealth?”

I want to talk about that.

It really has a lot to do with timing. And honestly, quite a lot of luck.

There is a saying from someone famous that goes “the harder I work the luckier I get”. It is one of those things you see on startup posters, tshirts, hats, mugs, and tombstones. I have a speech where I talk about my own tombstone. I don’t get an affiliate fee from Amazon but you should totally click on that link.

Back to talking about luck. Startups are hard. Quite often people don’t realize that in addition to building a product, you are also building a business. Sometimes you are also building a team too, unless you happened to preassemble that from previous companies.

My son plays baseball and I find that interesting because a baseball player is successful when he bats .300, or gets 3 hits in 10 plate appearances. I like to compare this to startups because a startup person is successful if they are batting .003, or getting .3 hits in 100 attempts. For those of you who struggle with math, those are not very good numbers.

There are people who love to gamble on startups. Sometimes they gamble their time, sometimes they gamble their lunch money and sometimes they gamble a few billion dollars on behalf of other people. With these odds, you have to understand you will burn quite a bit of money on things that are not successful for that really rare company that winds up becoming a Facebook or an Amazon or a Netflix or a Google.

I spent some time looking at various companies—what they set out to do at the start, and where they are today. The goal of that exercise is to try to figure out how to ensure a new business venture is more successful than its predecessors. Here are some things I have learned along the way that are mostly supported by my own empirical observations.

Timing is a big factor.

We all love our fancy iPad and Android tablets, but the Apple Newton was not a well-loved product. You can always create a product that is too early to be successful.

Similarly, you can also make a product that arrives too late. I am looking at you, Palm Pre. I loved that phone but it was a dead product a year before it arrived in consumer’s hands.

There is a narrow window for every product to have a moment where it catches on with consumers and reaches critical mass. Sometimes there are multiple moments. You can see the console wars between Sony, Microsoft and Nintendo for a good example of this.

Something something pivot.

If you look at the origins of Facebook, Google, and Netflix, they all started doing something very different from what they are doing today. You could say the same thing about Walgreens if you want a low-tech comparable.

I tell quite a few people who are starting companies that you will likely start to build a product and, in the process of developing or marketing that product, you will discover there is a better business opportunity. It is always hard to predict “product-market-fit” until you have something in a customer’s hands. The best businesses have a tendency to move towards a better marketplace based on what they have learned along the way.

When I hear a friend say that an investor declined because they did not like the product or service, I have to scratch my head. I believe there is probably a deeper reason they did not invest, given the lack of correlation between original idea and success of many unicorns.

Taking Advantage.

When you are building a business, you have to be able to ask yourself what it is about you and your team that makes your business special. To get to an unreasonable outcome, you need to have unreasonable advantages.

If you cannot explain your unreasonable advantage to someone, it probably is not much of an advantage. Let’s talk about a few of them.

First mover advantage is a flimsy advantage most of the time—you can be grossly outspent by fast followers.

Sustainable competitive advantage is a better one. Whether it is team, or technology, there are things you can do that you can claim you will always do better than other people. It is a good thing to have in your pocket.

Unique unreasonable advantage is the last one. I almost wanted to call it an unfair advantage, but people who own them would probably take offense at the thought that it is unfair. A unique unreasonable advantage is a business relationship or intellectual property position (such as a patent) that is generally unassailable by competitors. You might have some incredible license to a brand, or a partnership with a distribution channel. You might have a patent you can use to leverage your way into your competitor’s revenue streams, or even to block them from access to their own markets.

Good leadership.

If you look at the last three items, almost all of these require some amount of thinking and decision making. This is the responsibility of leadership. You might be slightly early to a market opportunity, and have a decent amount of advantages. It is the job of leadership to figure out if it makes sense to stretch the runway to wait for the market, or to decide if that is too great of a risk and to change direction. The wrong decision usually dooms a company. 

Amazon talks about this in their book The Amazon Way (ironically linked here on Amazon with an affiliate code).  One of their fourteen principles is “Leaders are right a lot”.

Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

I haven’t worked at Amazon before but I did interview once there. If you plan on doing that I highly recommend reading this book.

Up all night to get lucky.

This brings us to the point I wanted to make. You can have everything going in your favor at your company and still fail for really random reasons. The odds of success are really, really low, like hit-by-space-debris kind of low. Okay maybe better than that but not by much.

You seldom see a first-time entrepreneur create a gigantic unicorn out of the blue. Generally there is a seven-year story behind every overnight success.

Interestingly the second-time entrepreneur is probably the worst bet to make. They might believe so strongly in everything that they did the first time around that they are guaranteed to hit another one out of the park. I have seen some truly crazy second-time entrepreneur pitches. I am curious if someone has done any analysis on this particular thesis, but I believe that the second startup by a founder is probably their worst performing one.

By the time they get around to the third or fourth one, most of them get a deeper sense of the patterns around them and what things they can control. More importantly they get a deeper sense of what they cannot control.

Of all of these factors, I always try to tell people that luck is a really big factor. You can increase your odds in many many ways, but the odds are very dismal to start with. The internet tells me Wayne Gretzky said “You miss 100% of the shots you do not take”. I agree with this.

My personal specialty is creating products and creating development teams. There are two things I can control in that process. How many shots on net can I take? How can I increase the likelihood of a goal with each shot?

I have about three months of time to figure out how to create customers for my most recent shot on net. I missed the first shot on net with it, and I think I can get a goal on the rebound.

If not, then I will have to figure out what to stack on top of it. Maybe I will become luckier with the next product.

Thank you as always for reading along. Five stars best readers would write for you again!

We apologize for this one week interruption of your regularly scheduled update.

We will return next week for your usual happy fun time story!

I maintain a Google Drive filled with “to do” articles. I sat down this morning an hour later than usual and stared at all of the topics I wished to write about. I want to apologize because I am not feeling any of them at the moment. So I am going to ramble about my own product for a few minutes.

I wrote a while ago about my Joe-the-elf problem and how tedious creativity is a problem for storytellers. I decided to take my own solution for this tool, which I have been using on and off since 1997, and “productize” it. You can picture me doing the finger guns things when I say “productize”. I give you permission to do that.

I have managed to get it in front of a dozen users now and I am internalizing all of their feedback. Some of it is amazing, some of it is helpful, and some of it is concerning. What do I mean by that? I just finished saying I am internalizing it, didn’t I?

The one piece of feedback I am taking action on comes from spending some time embedding myself in the tweeters and the discords. I took the liberty of joining a few TTRPG (table top role playing game) Discord servers and spent a while lurking before reaching out to the administrators to blatantly ask them to try my stuff. I similarly set up a Reddit account and I went there for five minutes. We will not speak of what happened there—the pain is too fresh.

My cold-calling efforts were predictably mixed. Some people flat out said no with varying levels of politeness. Some people said that sending strangers random looking links over the internet is creepy. I suppose that is fair. At least one Discord owner took it to heart to check out my merchandise and spent an hour giving me absolutely valuable feedback. I am sponsoring the prizes for one of his upcoming Discord events as a result. If you care to give this charitable soul a follow, here is his clever twitter handle. 

The takeaway from the conversation is that I have a presentation problem that I need to solve for Derfdice. There is a vibrant TTRPG homebrew community out there. They have been building, sharing, and even selling content to the gaming community at large. The result of this is that homebrew consumers and buyers have become habituated to a specific look and feel. The best example of that is this amazing site.

I already incorporated rules for people to make their tables “public” to other registered users. If you make your table public, other users of the site can roll on it to their heart’s content. If you are a premium user of the site (thirty dollars a year, great value!), then you can also copy a table, with the caveat that it comes with a tag indicating that this table originated with a different user.

The next step for me is to modify the site to let people make their tables “superpublic”. A “superpublic” table is one that can be rolled on by anyone, without the need for a registered account. It will also (eventually) include the ability for content creators to show the table itself. If someone has a better name for this feature, I am open to suggestions.

I made a few of my own tables “superpublic” just to show what that looks like. Over the coming weeks I will modify the output so it can be presented in a format that people are already familiar with.

There are some additional things to consider here. How does a player get to make their own “superpublic” tables? The best I could come up with is “earn 10 premium followers”. The more astute among you might realize this turns my power users into marketeers. I am very aware of that. I don’t want to make it just any number of free followers. It is far too easy to make 10 or even 100 accounts just for the sake of amassing fake followers.

Do I create a parallel “superpublic” option? Is this a one-time fee that users, who do not have 10 people willing to click a button on their behalf, would be willing to pay? I honestly do not know.

I am going to wrap this up here for two reasons. The first is that I am not feeling it. I told you that at the beginning. The second is that I am going to throw up a superpublic page that is not just this:

We are now at the point where I am iterating from my DRMVP (Da Real Minimum Viable Product) into product market fit.

I hope you all find this journey as interesting as I do!

Next week stay tuned for some more heavy duty writing and perhaps another entertaining amazon dot com affiliate link!