Artisanal Concatenations of Sentient Emanations

Introduction

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

Without further ado, heeeeere’s Steven!

Priority Ones All The Way Down

Let’s walk through a situation together.

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

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

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

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

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

Weigh all the trade-offs

Theory

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

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

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

Practice

An example of this looks like:

The best way to think about this is:

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

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

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

Solve for the ask: Outcomes or Product?

Theory

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

Practice

Outcome-based goals

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

Product-based goals

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

Smaller shippable pieces

Theory

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

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

Practice

Running this exercise with our project, you could:

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

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

Work in parallel

Theory

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

Practice

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

Bring in the cleaner

Theory

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

Practice

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

Ship it today, revisit it tomorrow

Theory

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

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

Practice

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

Wrapping it up

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

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

Thanks for reading!

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

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

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

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

So why does orthogonal thinking work?

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

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

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

Rubber Ducking

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

Doing other work

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

Turning it all off: First edition

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

Turning it all off: Second edition

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

Turning it off: Third edition

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here are some of the common responsibilities for a CTO.

APIs and Interfaces

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

Documentation

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

Technology Platform Choices

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

Buy vs Build Decisions

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

Operations and Infrastructure

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

Research and Development

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

Technical Roadmap

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

Due Diligence

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

Intellectual Property

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

Compliance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How do you learn a new language?

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

Tell me about your current successor.

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

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

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

Trade-offs

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

Technical debt

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

Refactoring

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

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

Deprecating

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

Recovery

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

Learnings

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

Compliance

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

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

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

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

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

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

So let’s start going over them.

How many people have you managed?

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

How many managers have you managed?

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

How many managers have you created?

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

How many managers have you promoted?

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

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

Have you ever had to fire anyone before?

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

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

What time frame is suitable for handling a struggling employee?

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

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

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

Describe the best person you have ever managed.

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

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

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

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

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

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

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

Describe the worst person who has ever worked for you.

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

Tell me about your proudest professional accomplishment.

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

What questions do you have for me?

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

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

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

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

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

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

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

I look forward to writing again next week!

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

I want to talk about watching strangers touching my stuff.

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

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

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

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

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

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

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

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

Jiggle the gems

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

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

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

Get them inside quickly

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

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

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

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

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

Play though the tutorial

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Be Compassionate

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

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

Confidential Conversation

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

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

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

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

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

Time To Cure

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

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

Written Confirmation

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

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

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

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

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

Pattern of Behavior

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

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

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

Three Strikes

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

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

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

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

Tell Me What You Learned

I deliberately put this point out of order.

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

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

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

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

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

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

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

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

Understand Your Liabilities

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

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

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

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

Read All The Signals

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

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

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

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!