Categories
Code Quality Corporate Development Engineering

Why Your Code Base Needs an NPS Score

Engineers hate sloppy code. It’s hard to understand, harder to change, and even harder to scale.

But show me an organization that doesn’t have a gnarly code base. At Google, where engineers are brilliant and know how to write good code, it still takes them something like six months to get comfortable making even simple changes.

And that’s a problem. Because arguably, from Day 1, code quality is right up there with serving the right product to your customers.

Engineers are the customers of your code base. If they don’t like your product, they’re going to stop using it.

– Dan Loewenherz

This is because the engineers who contribute to the code base are the customers of the code base. And unless someone is trying to hear and address their needs, there are a few ramifications:

  1. Poor retention
  2. Lengthy on-boarding
  3. Slower scaling

The highest stakes? Recruitment and retention.

People get really frustrated having to contribute to something that’s hard to work with. If it takes ten hours to get Feature X into one code base when it could take an hour somewhere else, that’s not great for morale.

So how do we prevent this?

Ideally, you have someone keeping your code in good shape the moment you start writing it.

Because it gets exponentially harder as an organization grows.

Now, let’s say you have 30 engineers in your organization. Ideally, you’d have a couple of cross-functional team members, with background in all elements of coding your products touch – whether that’s frontend, backend, mobile, iOS, etc. These are folks that are willing to take on the more thorny issues. Make taming the code base their sole purpose, and you’ll avoid a lot of code rot.

“But I don’t have the funds to clean up the code base. I need to ship features to my customers!”

You don’t need to address all the issue immediately, but you need to have a plan in place. You may not have a shovel, but you need a spoon. You have to make forward, incremental progress, otherwise the time and energy it takes to add even simple features to the code base will grind to a halt.

So yes – it may seem like you’re shipping some features later than you wanted do. But if your developers quit, we promise that’ll delay your roadmap a whole lot more.

How should code base NPS be measured?

While a pure Net Promoter Score (NPS) is useful here (i.e. “Would you recommend this code base to a prospective employee?”), we think companies should use a couple of others to triangulate:

How long does it take for a new employee to get up to speed? In our opinion, this shouldn’t exceed 2-4 weeks – though this obviously changes based on logic and components. But pick a number – because ideally, it should never change. If it does, that’s a sign you need some cleanup.

How comfortable are engineers making changes after X number of days on the job? This should generally reflect your NPS score.

Imagine: You’re new to a job and the code base has architectural changes that are alien to you, because you’ve never made those changes in his work. And deployment in particular is a huge hole – and there’s fear behind it. Fear that your peers will break the website if they deploy.

This is terrible for morale – and not great for productivity either. Engineers are at their best when they have the freedom and creativity to solve problems, and a complex, restrictive code base doesn’t allow for that.

With a solid code base, anyone should be able to kick off a deployment. Whether it goes to production is another story, but it needs to be easy. The moment your developers are afraid of breaking the website, they start being less productive. They’ll be thinking about whether a seemingly benign change will break the website – is what I’m doing safe? These should be two separate questions.

So how can larger organizations improve their code base NPS?

It depends who you are. If you’re the CEO or CTO, you either need to take the lead, or pick someone from your organization who will be your right hand person in implementing a code base”tiger team”.

The first thing to do is establish guidelines for what’s acceptable.

  • What metrics will you use to measure on-boarding?
  • How will you measure ongoing code base satisfaction? (which, btw, is a really good predictor of employee satisfaction)

Once you have the metrics in place, build your team – and this will depends on the size of the organization. With 500 engineers, 1 person won’t cut it. So pick up a team from different parts of the org, and make sure the code base is super usable based on those NPS metrics.

Remember, your code base is the product you’re building for your engineers & future engineers. It needs to be something they feel happy working with.

Categories
Development Market Research Product

Focus on Why, not How

Most engineers focus on HOW to do something – not whether they SHOULD.

Engineers tend to be very intellectual – curious about how to solve problems, because that’s fun. But asking whether a problem should be solved is something everyone should be doing, at every level of an organization.

Dan recently started working for a great mid-sized startup (a departure from many years of ideating & building MVPs. During his interview, he was given a coding task – and part of the ask just didn’t make sense from a product perspective. He didn’t see how adding this feature would benefit the customer & the business, so he didn’t do it. 

When Dan explained this to his interviewers, they were surprised – apparently no one had ever done this before. But they loved it. Because all organizations need contributors who can improve the bottom line of the business, not just execute a development task.

The Cost of HOW 

The challenge here is that most organizations aren’t structured to empower engineers to make product decisions. And a result, it’s a skill that many engineers never cultivate.

And this makes sense – there’s a lot of value in splitting out functions and teams as businesses start to grow. But when your engineers are disconnected from the customer, the market, and why the product exists to serve them, there’s a cost, from…

  1. Wasted development dollars, to
  2. Lower employee morale (and potential burnout), to
  3. A “kitchen sink” product – rather than a lean machine focused on customer needs

Don’t get me wrong – having engineers who understand how to do something is critical. But HOW is only valuable after you’ve decided the SHOULD. 

In fact, sometimes the best solution is one where you have to write no code at all – and that saves time and money.

But this runs counter to a lot of today’s work culture. We equate seeming “busy” with contributing value – and as a result, we’ve trained our engineers to do those tasks in JIRA, simply because checking them off shows their managers that they’re productive. 

And when those tasks include features that aren’t really impactful? This has huge implications for employee morale because no one wants to work on something that no one will ever use.

Creating a SHOULD Culture 

In a perfect environment, everyone is comfortable saying NO. The default is, we don’t work on something unless a customer really needs it. Because too often, the impulse is “this is exciting, let’s build it”.

Now, let’s say you do have an engineer (or you are an engineer) who IS thinking about whether something should be done. If that engineer isn’t involved with the product process until the development stage, saying NO threatens egos upstream – because people have spent a lot of time and energy up until that point. 

In order to make this a part of your culture, you have to involve engineers at the beginning of the product ideation process. This has 2 key benefits:

  1. Engineers are deeply connected to the customer, their needs, and WHY a product is being built – so they CAN say no later on, with good reasons for doing so.
  2. Product / business stakeholders get early technical feedback, which can totally change how they approach requirements.

In practice, you’d have at least 1 engineer who will be working on features involved in product discussions from day 1 – from inception, to execution. So in theory, by the time a product brief is delivered to your developers, SHOULD has already been addressed from their perspective.

So that’s a perfect world. But in the real world, where most organizations silo product decisions from development tasks…

How can engineers develop a SHOULD mindset?

Think critically about whether or not this thing you’ve been told to work on makes sense to you. 

If it doesn’t make sense to you, then either it’s not being communicated well enough, or the inherent value isn’t obvious. And if the value isn’t obvious to YOU (who know your company and your product), it isn’t going to be obvious to someone who is a customer. 

Now, if you don’t feel like you understand your customers’ needs, go find out. Product marketers can be a great place to start. Talking to customers can be even better. 

Because if you don’t understand what pain points you’re trying to solve, and who you’re solving them for, a task will only ever be a task. Key into the why and the SHOULD, and suddenly your code feels like real, tangible impact.

Categories
Development Product Saving Money

Pad Your Pocketbook: Avoiding Feature Creep

Feature creep. Scope creep. Slow and stealthy, this can take you by surprise if you’re not careful, and is a major driver of development costs.

Be wary of death by 1000 cuts. When building software, time and cost directly correlate with the features you want to include.

Picture this: Each feature you’ve carefully designed is simple, and has real value for users. But before you know it, your budget has doubled and you aren’t sure how you got there.

So how do you avoid this? This is a tough one because as a startup, you’re constantly evolving your product ideas. Changes are normal, and important, because they’ll get you closer and closer to the right product to test your market. Don’t be afraid of this.

As you go through product design, wireframing, and visual design, keep asking yourself the following questions:

  1. Is this feature necessary for my MVP to work?
  2. Is this feature part of the core value proposition of my product?

If the answer to either of these is “no”, consider putting that feature on your product roadmap for a future release.

Remember, by launching with a slimmed down MVP, you can test your idea with the market without too many sunk costs. It’s easier to scale up your product once you KNOW what to include, than to re-work what you THINK your market wants.

Categories
Development Market Research Product Saving Money

Build an MVP (Not Everything but the Kitchen Sink)

The Challenge

One of the top mishaps we see with startups getting off the ground is trying to build everything but the kitchen sink. At this early stage, it’s easy to dream big about what could be – those sleek UI elements that’ll jazz up a user’s experience, that nice-to-have that would really make the product pop, and the handful of features needed just to meet comp. You’re vision-boarding what your business will look like – which naturally means that you’re thinking about those key market differentiators, and the polish that you’d expect from a fully-fledged product.

But watch out – while this is all critical to making your business a long-term success, trying to building too much for an MVP can kill your product.

MVP = Minimally Viable Product

Consider the Pareto principle. In this case, we tend to see that 80% of the action happens in 20% of the product. That 20% is your MVP, and will capture most of what users will ultimately get to do with the product. The other 80% may be necessary to the product’s ultimate success, but isn’t necessary for launch. Ask yourself – are these features necessary for the product to be usable at launch? By necessary, we mean will the product cease to function without them or lose its core value proposition? Or could they be added in V2 or V3?

A Lean, Mean, MVP Machine

So why does this all matter? Why not just build the product as you envision it for round 1? A few reasons for this: 1) Time, 2) Cost, and 3) Investment.

  1. Time: The longer you take to get to market with an MVP, the longer it’ll take you to start turning a profit, and the more runway you’ll need to self-fund.
  2. Cost: The more features you add, the more expensive your MVP will be.
  3. Investment: The purpose of an MVP is to test the market – do they really want your product? What do they like / dislike? Is it solving the problems you thought it would? If it turns out you’re wrong, by building an MVP, you won’t have invested all your $$s in a product that isn’t quite right. It’s easier to add features that you KNOW are right, rather than test features that might be wrong and have to go back and re-work them.

Ultimately, your biggest asset as a startup is your ability to be fast and flexible. You may not have all the money in the world, but you can do things quickly to respond to the market. Learn something new about a competitor? Change your product. Partnership opportunity just came up? Add the one feature they need to make it happen. Not quite sure what customers want? Test your hypothesis on the cheap, then pivot if you’re wrong.

The net-net

The purpose of an MVP is to test an idea with your market. Building a lean MVP saves you time and money, and gives you the flexibility to change course if needed. Features can always be added later when you have the resources to do so, and the market validation that you should.

Ready to streamline, but don’t want to lose track of those extra features? Sign up for our email list to get a preview of our upcoming post on  how to create your product roadmap.