
Poornima Vijayashanker is the founder of Femgineer, helping entrepreneurs and tech professionals (especially women) level up their careers.
As technologists, we want to build software that is friendly, fast, beautiful, responsive, reliable, secure, and scalable. And we expect ourselves to deliver it on time and under budget, because our ultimate goal is to have lots of happy customers who can do what they want.
But time and energy are finite, and we simply cannot deliver it all at once. We need to choose our priorities, and this choice is one we should make consciously.
Evaluating our software development priorities while dealing with constraints is known as the tradeoff space, and is influenced by:
- Your technology stack
- Your business model and customer needs
- Cost of a mistake and a companyβs appetite for risk
- Onboarding employees
Want to make smart tradeoffs when developing software products? I recently interviewed Jocelyn Goldfein, the former Director of Engineering at Facebook, to talk about the tradeoff space and how to evaluate your priorities.
Start with your technology stack

Where does your software product sit in the technology stack? Its place in the hierarchy can impact the kinds of tradeoffs you can make. βDifferent technology stacks lend themselves to different solutions,β Goldfein says.
For example, if youβre building a web application, youβre at the top of the stack:
- This gives you the freedom to build quickly by reusing a lot of existing libraries and frameworks. You donβt have a lot of control over them, but youβre saving a lot of development time.
- You can also deploy your application to your own servers or a managed hosting provider. Regardless of which you choose, web servers have similar environments, so you donβt have to worry about device-level variability.
- Bug fixes are a cinch! Since you control when you deploy your web application, you can make fixes and updates quickly and frequently.
As you move down the stack, you donβt have as many libraries or frameworks to build applications quickly, but you have more control of what the application does.
For example, if youβre building a native mobile application, you have access to the device. Unlike a web application, your app can use the deviceβs camera, the accelerometer, and interesting metadata like the userβs exact location.
But you donβt own the deployment environment. A third party has to certify your application before it can be released to users, and, βyou have to think differently about how frequently you can update,β says Goldfein.
Next, factor in your business model and customer needs

Itβs easy for us to make tradeoffs based on the limitation of our technology, but as Goldfein says, βitβs not a technology-driven decision alone.β We need to think about what matters most to customers and what their expectations are for your productβs benefits.
We get really wrapped up in thinking that a productβs benefits are based on its features, but Goldfein argues that benefits are actually driven by your business model.
For example, when building enterprise software, reliability is a key benefit. If a product isnβt reliable, then it can impact the bottom line of your customerβs business.
Contrast that to consumer Internet applications: reliability is less crucial as a benefit, because consumers usually donβt need to use an application (but they should want to). . So instead, itβs important that the product is compelling and the users want to use it. This is one of the reasons many consumer Internet applications prioritize user experience over things like reliability or high up-times.
Ultimately, it doesnβt matter if your tech stack has the capability to do more, if thatβs not a top priority to your customer.
βWe have to be motivated by the person using our software. We have to remember that we cannot do everything in the world weβd like to do, so we should do what matters most to that person. When we design for the person, we do our best work,β says Goldfein.
Weigh the cost of a development mistake against your companyβs appetite for risk

βItβs easy to think of appetite for risk as a character trait or a moral quality. But itβs not,β Goldfein tells us. She continues, βWe think itβs just about philosophy or [founder] personality.β
As she puts it, risk comes down to asking yourself: βIf you make a mistake, what is the cost to fix it? And what is the pain to my customer?β
But there are real reasons why some companies have a greater appetite for risk than others.
It goes back to the two dimensions of technology stack and business model.
If youβre building a web-based consumer internet application and you introduce a bug, thereβs less pain for the end user, because they have a want-to-use mindset. You can also quickly fix the mistake. Hence you have the freedom to make a lot of mistakes without jeopardizing your business..
But as you move down the stack, the cost of fixing an issue goes up, and the pain to users goes up.
For example, if you are building systems-level software like VMWare and you introduce a bug you cannot easily deploy a fix like you can with a web application; you often have to get third party approval. This takes time and resources, which hurts your end user and shifts your teamβs focus away from other activities. So if youβre building systems-level software, you have to prioritize having a careful process and testing before your release.
Onboard new employees so they know your values and tradeoffs

The last thing you want is two leaders to make tradeoffs that cancel each other out.
When you bring in leaders, you need to be conscious that they come from a background that emphasizes the same values as your organization. Even if the new hires come with a different set of values, thatβs OK. Itβs more important that they can adapt and you can onboard them thoughtfully.
To hear more from Jocelyn, watch the interview on Femgineer TV.
Read Next: Being a manager doesnβt make you a leader
Get the TNW newsletter
Get the most important tech news in your inbox each week.