Vision, Mission, Roadmap - But First, Eat What You Cook

I recently had a conversation with a mentee who is a new SDM.

"I have a Technical Project Manager (TPM) who handles project management and a tech lead who takes care of the engineering side. I attend meetings and keep myself busy. But sometimes, I wonder... what am I really doing here?"

"Indeed, what is the purpose of all these stuff?" I laughed, "Aren't we just a group of bureaucrats, following rules that no one understands and writing documents that no one cares about?

However, I would argue that the most crucial role of an SDM is to define the purpose of their team and themselves: the vision of what the future should look like, the mission of why it matters, and the roadmap of how to get there."

"That all sounds correct, but where do I start?" the SDM asked.

"You can begin by using your own product and experiencing it as a customer," I answered. "A chef once said something that resonated dearly with me: 'You have to be willing to eat what you cook. If you don't even want to eat what you cook, how can you sell the food to others?'

Vision, mission, and roadmap are all abstract concepts until you start using your own product - and eat what you cook.

For instance, I was playing AWS CodeWhisperer yesterday, a generative AI product that acts as your coding companion. I asked it to generate a Python function to find the key ARN using a KMS CMK's alias. It wasn't as straightforward as you might think. Here's the code it generated:"

# Map key ARN from a given key alias name to a CMK by calling KMS APIs

def key_arn_from_alias(alias_name):
 kms_client = boto3.client('kms')
 response = kms_client.list_aliases()

 for alias in response['Aliases']:
  if alias['AliasName'] == alias_name:
   return alias['TargetKeyId']

 return None

"Not bad for an AI agent. So, what's the problem? Firstly, it's inconvenient that we have to list all the aliases. We can use KMS' describeKey API, but the API doc is too hard for the AI, or a human, to get what it means. Secondly, the code does not return the key ARN as I wanted, but a key ID, which is a UUID-like string. Key ID is part of the key ARN, but not the full key ARN. A key ARN looks something like arn:aws:kms:us-west-2:account-id:key/key-id.

So, as a customer of AWS KMS API and CodeWhisperer, I found two issues:

1. CodeWhisperer does not yet understand the difference between KMS key ARN and key ID.

2. KMS API does not offer a straightforward way to get a key ARN with a key alias, not until you read the describeKey API doc three times.

Will we fix these problems immediately? It depends on the resources, timing, and priorities of the respective teams. I will certainly bring it up with them. But at least I am experiencing my own product firsthand. I eat what I cook.

So, my advice to new SDMs is this: before you delve into your team's Vision, Mission, and Roadmap, eat what you cook first!"