As a technical director at a software agency I’ve encountered many different technical teams, products and processes. In this document I’ll dive into the pragmatic quality metrics that I used to create a suitable advice for the way forward, including whether or not we should engage with them as a client.

Determine goal of current and next phase of company / product

Usually, when I encounter companies they are somewhere in one of the following phases. Based on which phase is the next phase, I would adjust my approach on what qualities to look for and judge a team on.

  • Ideation: still creating first version of product, possibly still need to pivot once or twice
  • MVP: first version is operational, now creating improved version of product, possible rebuild with features and V2 features in mind
  • Growth: product version with traction that needs to be scaled to the next level but not
  • Maturity: product version with traction that needs big scaling

desirable qualities per phase

For each of these phases, different qualities in teams, products and process are desirable:

  • Ideation
    • small team or just or two high skilled engineers with focus on value and product market fit
    • efficient light process
    • fast and lean framework and infrastructure, high prototyping speed
  • MVP: first version is operational, now creating improved version of product, possible rebuild with features and V2 features in mind
    • slightly bigger teams, separation of specialisms, focus on customer experience
    • light structured process to keep bigger team synched with business, increase quality on experience
    • start thinking about more durable infrastructure and codebase, optimise for runway to tweak product
  • Growth: product version with traction that needs to be scaled to the next level but not
    • grow team with experts in specific fields
    • structure cross team process and implement quality monitoring
    • create plans how to stretch current product and infrastructure to next step (without going overboard), identify pain points that need to be solved in next architecture
  • Maturity: product version with traction that needs big scaling
    • changing team culture of protoyping mindset to maintainability mindset: move from getting it done to doing it right
    • heavy process while keeping high continous delivery as goal metric
    • design and implement global scalable architecture

typical qualities to measure technical teams, process and product by

Team

  • are all vital technical archetypes covered in the team (either all in one person or spread amongst people)
  • how motivated and committed is the team to the product
  • how open is the team for changes in team/process/product
  • what is the relation between technical team and business like
  • how does IT fit into the culture of the company

Product

  • does the overall code quality match the phase of the company
  • does the technology stack match the phase of the company
  • how many moving components
  • which components are known pain points
  • for which components is there hesistation to adjust them
  • how quickly can infrastructure be rebuilt in case of catastrophical failure, and does that match the risk appetite of company

Process

  • is there a process by which technical work is structured, and is it sufficient for the needs of the next phase
  • how is the process documented
  • is there a design process in place
  • is there a clear distinction between ready process and implementation process
  • does the process supply accurate estimations
  • how is reflection and adjustment covered (in the process)
  • is product ownership separated from implementation

vital technical archetypes

  • the user experience advocate
  • the getting it done prototyper
  • the ops and servers person
  • the technical communicator
  • the progress overseer
  • the DX (Developer Experience) person
  • the architect (can be temporarily available)

references