Link Search Menu Expand Document
Virtues

Capabilities First

urn:js:virtue:aspire:proposal:31.1

TL;DR

All squads working on building ASPIRE MUST make use of our capabilities to deliver their solutions; or else they must present to Decision Forum why not.

Rational

Why Capabilities First?

  • Return on investment; we spend a lot of engineering budget on designing and developing our capabilities, we would like to see a return on that investment.
  • Developing a great engineering culture; by adopting one another’s capabilities, we help to promote:
    • Continuous learning and development for one another
    • Shared code ownership
    • Respect for one another
    • Focus on high quality code
    • Developing towards the right software abstractions that really work for us
    • A functional maturity for ASPIRE that is greater than the sum of it’s parts

What about teams “picking whatever technology we want”?

“Picking whatever technology you want” has always been about promotion of trust, empowering individuals and enabling autonomy of teams. It is a valid statement that Capabilities First erodes that trust, sanctions individuals and couples teams based on technology dependencies. We could aim to balance this with the following:

  • Teams still pick their own technology provided they can prove their use case won’t be satisfied by our existing capabilities; or when our capabilities can’t be feasibly augmented to meet their use case.
    • Either technical feasibility or due to time
  • Teams can still choose not to use capabilities; provided they can justify the reason to the decision forum.
  • Teams can propose their own capabilities if they feel the portfolio is not broad enough.

Won’t this stifle creativity, innovation & healthy competition between squads?

This is a good point and shouldn’t be overlooked. It is true, that cutting off access to areas of development and filling them with capabilities we may be closing the doors to innovation in these spaces. However, at the other extreme we may end up with many different (innovative and creative) systems and solutions that are effectively doing the same thing. Both outcomes at their exteme are undesirable for the business. Capabilities First has been given a sunset clause and escape clauses for squads that choose to not use capabilities.

What are our capabilities?

Refer to this link for the list of engineering capabilities.

What are our capabilities?

Refer to this link for the list of engineering capabilities. Engineering Products

But our capabilities are rubbish - do we really want to insist on using them?

Firstly, let’s remember that our capabilities have been a labour of love from our colleagues and are often passion projects; so let’s be mindful of how we critique one anothers work. Furthermore, our capabilities will continue to languish unless we start to use them, provide valuable feedback, iterate, improve and innovate. Now, let’s take a moment explore some sentiment behind this

The capability doesn’t have a feature that I need

Have you given this feedback to the capability owners? What is their change process? Can you work with the owners to write this feature and contribute this back?

I don’t understand how to use it; it’s poorly documented and I need the maintainers to operate it for me

Again, have you given this feedback to the capability owner? I’m sure they’d be happy to up-skill you on operating their capability. And, if you feel the documentation could be improved, then why not spend some time improving it for the next person? Confluence, sample code, integration tests patterns - all great ways you can support your peers develop their product so that it benefits everyone. In future new capabilities will be independently assessed to ensure they are sufficiently mature for general consumption, if other teams want to use them before this is the case they are welcome to contribute to the shared effort. The criteria for assessing maturity can be found here: Maturity Assessment Template

I’d rather just use /insert flashy new technology here/

That’s great! /Flashy new technology/ is awesome and we should always be looking to experiment and challenge assumptions about our capabilities. I’m sure /flashy new technology/ can perform 10X better, faster, and cheaper. But before strapping on your cape and immediately shipping to production ask yourself some questions;

  • Does the business really need this technology right now?
    • What about the non-functional implications? Ways of working, training, business change, etc.
  • Are you in any way force-fitting it into your solution?
  • Are you set up to run this as an experiment? If you still believe that /flashy new technology/ is worth the investment then proceed with your proof-of-concepts.

Do we really need this principle - if we had the right capabilities we’d recognise their value immediately and not need look elsewhere?

This is true, we should review this decision with a view to sunset this principle once our capabilities (and our process of developing and evolving capabilities) is mature.

Does this mean that I need to rewrite all of my products to use the capabilities?

We should be pragmatic.

  • New products should be designed to leverage our capabilities where needed.
  • Products in development should have their designs reviewed and decisions to incorporate our capabilities if feasible to do so.
  • Products in production can remain as is, but should be reviewed. We should label these products (or part thereof) as ‘legacy’ such that there are no new improvements on these products unless they are to retrofit our capabilities.

Implications

None.

Appendix

Migrated From Confluence

link Original Author : Pine, Ben