DevSquad is Phil's consulting firm helping other founders build their SaaS products. They do this by providing product teams composed of engineers, designers, testers, and anything the client would need:
"When they hire us, they don't need a CTO or a technical co-founder because we will help them with that part."
Meanwhile, his product DevStats supports the same mission by providing customers the tools to help their engineering teams:
"We give you the tools to help your engineers be more productive, avoid burnout, and help you run a high-performing development team."
Common engineering mistakes
Over-engineering
Thinking too much about the possible problems in the future (e.g. huge traffic that could come to your webpage), companies end up over-engineering:
"They take too long to go to market, making a product so complex that only senior developers can work on it."
Using technology that's popular but not well established
"Many times they're using technology that isn't well established. They're using the 'hottest new thing' which will change in six months."
Building your engineering team
Product engineers vs. software engineers
When you're able to raise funding, it's best to use a portion of it for hiring engineers, specifically product engineers.
"You want to hire product engineers and not software engineers — there's a huge difference.
A product engineer is a person that's going to think with you about the product and find their own success in getting a product to market. They find success when people are using the product. They think about the product metrics and they want to solve a problem for the final user.
A software engineer might be great at writing this amazing code or using the newest tech knowledge. There's definitely a place for software engineers, but these are usually in big and established companies."
And this is a common mistake teams make when looking for developers:
"They're going to hire a developer that's very good because he worked at Google or Apple, but they were working at only one thing for four years. They never did the full flow and they never got an actual product to market."
Because when you're trying to get a product off the ground, you'll need the generalist (product engineer) on your team. A specialist (software engineer) can come in later:
"When you're thinking about who to hire, they have to be generalists. They have to think about the big picture.
Generalists build companies. Specialists scale companies."
Experience level
But how about the experience level (i.e. junior, middle, senior)?
Phil says that it depends on the complexity of your product:
"I would say about 80% of SaaS products can be built by mid-level engineers. SaaS products are usually not very complex. There are technologies out there that give engineers everything already decided for them."
To keep things simple, he recommends having one mid-level engineer and one junior engineer. If you have more resources, you can have one senior and one mid-level engineer. But remember, you have to make sure that this engineer has experience in building and launching a product.
Start with at least two developers
If you're starting your own team, it's best to have at least two developers on board so they can do code reviews:
"It's a very important part of building software. The developers can swap their work for review so they can learn together."
Aside from the knowledge sharing, the benefits of having two developers are:
- Low turnover
- Higher product quality
- No single point of failure when a developer leaves
- Healthy competition
The relationship between engineering and design
At Phil's consultancy, their product trail is composed of a product manager, a product engineer, and a product designer:
"The three of them work together to shape what we're gonna build next. And then we hand it to the development team that builds it. So I think design is very important."
But for the clients with fewer resources, they could create design systems and other things. This helps avoid redesigns down the line.
However, not all developers are open to polishing the design of the product. Phil emphasizes that nowadays, users expect an amazing experience with any product:
"It doesn't matter if you're QuickBooks or HubSpot. People are using those products and they expect your level of usability and the user experience to be very similar. I think it's very important to take the time and make sure software is easy to use and the design is polished and beautiful."
But this would also depend on the size of the pain point and the audience you're serving:
"A lot of companies that come to us build version two of the product, and their version one is horrible. It looks super ugly but they're making seven figures in revenue. If the pain is big enough and if the market's underserved, people will be more patient with a product that doesn't look amazing.
But if you're serving marketers, developers, and others who are really used to seeing a lot of great products, you better have an amazing design."
Mismanagement of resources
Phil shares that having too much money can become a curse instead of a gift because it leads to overcomplication:
"Some clients have too much money in their hands and then they overcomplicate stuff. They want to redo things that were already working. They just keep wanting to build more and more on the product that they forget to actually sell the product and make sure people want that product."
He also saw other clients put too much money into engineering and not enough in other aspects of the business.
Building an engineering culture
Phil shares that you'll want to build an engineering culture based on open communication where people are okay with giving and receiving feedback.
You also want a culture of getting things done and engineers understand the bigger picture:
"Understanding what's important for the engineers, what's important for the product, what's important for design."
Building this kind of culture encourages solving problems as a team:
"I believe it all comes down to openness to communication. And when there are problems, the culture should not ask, 'Who's at fault?' but rather 'What can we fix in our process so this problem doesn't happen again?'
Because it's usually not an individual person's fault. It's your process' fault. So ask: what process didn't work? Why did that break? Why did that happen?"
The motivation behind DevStats
Before there was any engineering performance software like DevStats, Google and Microsoft created their own surveys to gauge it.
Google's DevOps Research and Assessment (DORA) metrics were used to answer two questions:
- How do we define a high performing development team?
- How can I track and determine if my development team is doing well or not?
The four key metrics in DORA are:
- Deployment frequency
- Lead time for changes
- Change failure rate
- Time to restore service
However, Google's DORA metrics didn't really help people learn how to become high performing. That's why in 2021, Microsoft came up with the SPACE framework to define:
- How do you actually get your team to perform?
- What metrics should you track?
The framework had five dimensions for developer productivity:
- Satisfaction and well-being
- Performance
- Activity
- Communication and collaboration
- Efficiency and flow
After surveying companies and seeing that each one's different, Microsoft and Google thought it'd be impossible to measure and monitor the metrics through software.
"A bunch of companies decided they were wrong about that. They started building software to track data and then give people reports and insights that could help their team improve in those areas."
Taking care of your developers' well-being
Phil shares that the developers' well-being is the hardest piece of software, that's why it's important to track it so they don't burn out.
Reduce unplanned work
"When developers have unplanned work, that really stresses developers out."
While there are instances that this couldn't be avoided, you can reduce it by improving the planning of the workload.
Track the number of works in progress (WIP)
"We track daily WIP because it's common for developers to go 100 directions instead of starting and finishing one task. We track if they're working after office hours and if they're working weekends."
Monitor employee NPS
Similar to a customer NPS, this is used to somehow quantify the sentiment of your team members:
"We send a survey for all the developers using the product and they answer on a scale of zero to ten. And then we look at how many promoters we have, how many detractors we have, and how many people are passive. And then we try to improve it from there."
And while it doesn't exactly tell you the problem, it's still a good indicator to tell you if something's wrong.
"Because if your promoter score is low, you know that you have a bad culture for your developers."
What non-technical founders can do better
Even if you're not going to work on the product yourself, understanding the basic concepts and how the software gets built will help you in decision making:
"If you're going to be a founder of a technical product, you should take 20 hours and learn the basics so we can have conversations that's going to help us make trade-offs."
A common mistake non-technical founders make is they outsource all the trade-offs for the engineering team:
"That's a problem because the engineer doesn't have the big picture, or they make very bad trade-offs because they have zero understanding of what's going on there.
Founders need to be able to understand and tackle tradeoffs to a point. Engineers can help them to get there."
You can start by taking basic courses or reading books on the topic.
Final advice
Do simplify stuff and try to build the simplest products.
"One of your core values should be simplicity and to think about the simplest way to build a solution."
Don't copy the big companies because they're in a different stage than you are.
"Best practices don't work if you're not the same size and don't have the same resources as they have."
Thanks for listening! If you found the episode useful, please spread the word on Twitter mentioning @userlist, or leave us a review on iTunes.
