Priority One All The Way Down

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!