Skip to main content

Agency, skill and mastery

Agency, skill, and mastery are topics on which I have so many thoughts, and I am still discovering myself. This writing summarizes my position as of roughly April 2024.

Agency, as pictured below, is to take on things, doing hard things without waiting for conditions to be perfect or otherwise blaming others or your circumstances.

Examples of low agency:
  1. I could develop so much faster if only the code was not so crappy! 
  2. We would be already finished if this or that team had done their job properly! 
  3. If only my boss (or company) understood me, I could really do great things for this Company or my team!
High agency behavior: 
  1. I'll try to make changes to the code/add tests/etc as I work on parts of it so that I will, over time, be faster.
  2. Let's see if there are ways that I/we could help that team complete/do their work in a way that we both benefit.
  3. I've observed my boss is good at X, but not so good at Y, so I'll try to adapt my behavior to minimize the Y and maximize the X so we can have an effective relationship.
Agency requires skills to be effective. That's why the drawing connects both. 
And maybe there's one more axis needed: judgement but then it gets too complicated for today so let's stay on just agency and skill.

People with high agency and high skills (top right) are the so-called game changers. They will have an impact well beyond their own area of responsibility, and, most importantly, will exert a long and profound effect on all areas which they can reach with their influence. 

People with high skill and low agency are still effective contributors to the organization objectives. 

People with low skills and high agency (bottom right) can move upward and become game changers. Importantly: skills can be taught and can be learned, while agency requires a special mindset which is more difficult, but not impossible! to achieve in the right conditions. 

When it comes to skills, I feel that the best motivation for skilling-up is mastery, that is the desire to master your craft. Another powerful motivation can be ego, but I find ego to be less reliable and more difficult to manage. Also, ego leaves us vulnerable to outside influence as the things on which we rely to motivate us can be taken away from us. 

Examples of ego motivation: 
  • recognition by others 
  • economic success 
  • competition 
  • spite-driven-development 
With mastery as a motivation the above become second-order effects. We are recognized because of our good work, as opposed to doing work to be recognized. Economic success is a result of our impact, not the driver.

Signs of an ego vs mastery approach can be recognized by how we react to failure or difficulties:

ego...
 
as a motivation

mastery...
 
as a motivation

How do we react to failure/difficulty?

embarrassment

curiosity

anger

acceptance

obsessing

judgement


It seems to me that mastery, as a motivation, is a much more kind master.

References

To write the above, I've mixed together content from the following source(s):

Comments

Popular posts from this blog

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in

From 0 to ZFS replication in 5m with syncoid

The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive. Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.

How to automatically import a ZFS pool built on top of iSCSI devices with systemd

When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import. This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname> after boot, either manually or from cron. A better, more elegant solution is instead to hook into systemd events and trigger zpool import as soon as the devices are created.