Join my daily Newsletter

Subscribe to get my latest content by email.

    I respect your privacy. Unsubscribe at any time.

    preloader

    Mastery vs Purpose

    • Thursday, Jun 18, 2020
    blog-image

    [Reading time: 1 minutes 47 seconds]

    Maybe you’ve read Daniel Pink’s Drive.

    In this book, Pink argues that there are three factors to increase performance and satisfaction:

    • Autonomy — The desire to be self directed
    • Mastery — The urge to get better skills
    • Purpose — The desire to do something that has meaning and is important

    This is taken to apply to the feelings of a person, the foundations of their motivation.

    However I’ve come to realise that the same categories can not only apply to the things happening inside a person, but also to their actions.

    Recently I observed a discussion about a software team lead who subverted their team’s efforts by “improving” their code over night, or changing the architecture of the product to something “better” – when the product was on the verge of shipping, and already behind schedule.

    Of course, this was not viewed fondly by onlookers.

    It occurred to us that what happened here was that there was a mismatch between mastery and purpose.

    Right before shipping is probably not the right time to streamline a product’s architecture, unless something critical is going on, such as performance issues.

    The architect’s actions may have been good for the code (maybe his improvements were objectively improvements) – but they weren’t good for the product.

    This person approached everything from the perspective of mastery, neglecting purpose.

    This is very interesting because similar things happen very frequently: actions are taken because they are the technically right thing to do, but aren’t an improvement from the customer’s (or business’s) point of view.

    Purpose conversations are just much harder. They make us leave the safe, familiar, supposedly objective tech world.

    On the other hand, this is where you need to go if you want to create compelling products.

    Weigh the mastery against the purpose: sure, improving the technological foundation of your product is a good thing – but is it the best thing for the product right now?

    DevOps, combining technology with confusing human aspects, may pose a trap there, may lure you into eschewing one factor for the other.

    Don’t fall into that trap.