Let's talk about engineering metrics. There are 2 types of metrics you should look at when it comes to measuring the success of a software engineering team. More 🔽
The first type of metric is qualitative which can be achieved by talking to customers. Many software companies use NPS (Net Promoter Score) to measure this. Looking at these metrics ensures your software engineering team is delivering value to business and customers.
The second type of metric is quantitive. They can be represented numerically and obtained scientifically.
Recommended quantitive metrics that can be used to measure/manage quality, delivery and productivity in software product development are: 1) Time to delivery
-- Cycle Time
-- Lead Time
2) Quality
-- Defect rate
-- Percentage of test coverage
-- Up time (reliability)
--- Latency
3) Time to recovery
-- Incident detection time (MTTD)
-- Incident recovery time (MTTR)
-- Average age of closed bugs
4) Team velocity
-- Number of releases
-- Number of story points completed
-- Rate of story completion
I’ve written it in my book, The Engineering Manager’s How-To Guide (link in bio), about the importance of measuring what matters. Otherwise, software engineering teams and software engineers become too distant from the why of the business.
What metric are you currently measuring for your software engineering teams?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Today's question is on hiring and scaling a startup: Is it advisable for small companies or startups to hire a temporary consultant to build a team of developers and designers?
If you’re hiring for more than 5 people, I’d personally hire a CTO, CPO or find a co-founder with prior experience in building teams first, and then work with a recruitment agency.
Because hiring or filling headcounts is not the end goal, you’ll need to make sure the new people are onboarded properly, and they have a roadmap to work on.