Using metrics to improve your engineering organization

Using metrics to improve your engineering organization

PR review time, Rework, Feature time - plenty of git metrics out there. It's clear how things like Multitasking or Oversized PR alerts can be handy in weeding out apparent bad practices. Overarching goals, on the other hand, can be vague even for experienced engineering leaders.??

Here is our top 4 to optimize for and balance between:

  • Quality - how much regular maintenance is required to keep us afloat??
  • Predictability - how accurate can we predict releases in the upcoming months?
  • Responsiveness - how fast can we deliver change to a live product?
  • Resilience - how well our product & organization can survive rapid scaling?

All 4 seem important, pushing for one while ignoring the others may harm the organization. That's exactly why Codigy strives to give a holistic view of the organization so that trade-offs could be considered.

We already check 2 of 4:

  • Resilience - through engineers confidence map
  • Responsiveness - through exact measurement of your feature cycle and monthly throughput.

We are now adding predictability to our toolkit. Using existing data from your feature pipeline, we create a scatter plot like this one??

No alt text provided for this image

No more guesses, pure facts based on historic data:

  • Does this team has seasonal throughput deviations?
  • How many features can we expect to deliver in a given month?
  • What is a certainty that a feature will be delivered within given time?
  • How uniform your features are in their scope and production time.

While certainty range can be wild at the start, we now have a tool that will help us cut features into more uniform and predictable chunks. Science!??

要查看或添加评论,请登录

Igor Podoprygora的更多文章

社区洞察

其他会员也浏览了