In Nature There are Only Two States: Evolving and Dead.

Editor’s Note: This is the third article in a series covering best practices for building a great product & engineering team featuring advice from Yoav Shapira and Craig Daniel. Read the first two installments here and here.

In a world where most code only lives for a year or two, engineering managers must maintain a constant balance between the desire for perfection and the need to build an evolving product that fills the needs of its customers.

Here, Yoav Shapira, Engineering Manager at Facebook, and Craig Daniel, VP Product at join.me, explain how they find a balance.

Do not over-engineer.

“What I learned early on in my career as an engineer,” says Craig Daniel, “Is the saying YAGNI, you ain’t going to need it. In other words, do not over-engineer. It’s vital for engineers and product managers to build a good relationship with clear communication. Because without it,” he adds, “There is a default position to over-architect. Engineers are always looking to build their next masterpiece.”

“But, most of the time” Daniel continues, “That’s just not necessary. You have to continually avoid the urge to build that masterpiece because the code – if it’s a good product and a good business – won’t last long. And, if it’s not a growing business you’re going to be put on ice and it won’t matter anyway.”

That’s a harsh reality for many engineers to face, but it’s an important lesson, especially for new engineers coming from high-achieving schools.

“This mindset is especially an issue with engineers out of elite schools,” adds Daniel. “They want to build their masterpiece and we’re forced to say ‘Just strip it.’ It’s a little controversial, even inside our own walls, but it’s necessary to get the code shipped.”

Yoav Shapira agrees. “The key takeaway is that you’re going to rewrite the code anyhow. In nature there are only two states – evolving and dead. It’s also important to note that you’re either growing and need to add new features, or even if you don’t need to add new features, six months later or a year later, there’s going to be some interesting tech to make the product better, you’re going to rewrite it. So, don’t obsess too much.”

The art is knowing where the balance is.

For Shapira, balance is key. “It’s not always easy – not to obsess over some small detail – but if you have a major use case that you’ve already committed to including in your product, the engineering manager needs to refocus her team’s time on priorities.”

“Again, you’re going to rewrite it anyhow, so plan for it like there’s an anticipated cost. This isn’t something that’s done on nights and weekends, nor is it a hackathon project,” Shapira notes. “You need to plan for the impact on your feature release schedule. And once you plan for it, you can normalize it. Rewriting code isn’t a reflection on any developer, it’s evolution.”

For Daniel, it’s vital that his engineers not get hung up on a rewrite. It’s not about ego, it’s about efficiency and doing what’s best for the product and company. And, if engineers really want to build a masterpiece, Daniel says “They can architect a testing system that tests code automatically. Most of the stuff that we touch now because of our testing system is really, really hard to mess up on production. We put the discipline in. We have tests.” And that makes for a true masterpiece in the end.

Get your team to feel the customer’s pain.

At the end of the day though, some developers aren’t at ease with this idea of avoiding perfectionism. “Some engineers want to build a perfect code. A fast-growing startup is probably not the place for them to work,” says Shapira. “There are plenty of other places that will hire them, all sorts of R&D labs, but a high-growth startup is not the right fit. And that’s certainly a hiring trait we screen for. We ask ‘How do you think about shipping? How do you balance?’”

When engineers do land at a fast-growing startup, communication is key. “We buy lunch for everyone and we sit down and talk about the nasty problems that came up that week,” says Daniel. “If we had a bad week in sales we ask why. ‘What happened?’ ‘Why did we lose the deal?’”

“More often than not, the engineers go home on the weekend and work on solving the problem. They clean up the eCommerce flow or tweak something in the code that will help. Maybe they A/B test something to see if that will help. You want to create this environment where it’s okay to continually iterate. You spend $100 on lunch and you inspire your team to do better.” It’s well worth it.

“A lot of times it’s easy for engineers and product people to forget they’re literally building something that makes people’s jobs easier. You have to get them to feel the pain of the user,” adds Daniel. “So whether you’re doing ad sales or building a utility like join.me, at the end of the day, your users have to eventually want to pay you.”

“And they’re happy to,” says Shapira, “So long as you’re continually working to solve their problems.”

While an engineer’s default stage might be building that masterpiece, it’s not about what they want in the end. You need to remind your team of the goal – making the customer happy. Because at the end of the day, that’s all that really matters.