Identify which wireless access point you are connected to

Sometimes you want to know which wireless access point (AP) you are connected to. From a Windows laptop you can do this by running the following command

 netsh wlan show interfaces

In the output, look for the BSSID, which will be in the format of a MAC address. Then look for this ID either on the AP itself, if you are able to physically access it, or via whatever wireless controller software you use to manage your APs.

You Build It, You Run It

A key tenet of the agile, DevOps-focused project-to-product transformation mindset is the concept of "You build it, you run it". That is, if you and your team were responsible for creating the thing, typically a bit of code in the DevOps world, the same team needs to be responsible for running it on a day to day basis. This probably works in the case of software, due to the way most of the "running" can be automated and therefore also turned into code. "Running" the code then simply involves a continuous improvement of that code, to be self-reliant and resilient. It would make sense for the team who know the core code, i.e what was "built", to also be intimately acquainted with the peripheral code, i.e. the code around the outside that automates the "running" of the core code, making it more resilient and reliable.

However, how does this idea translate into less automated products? Traditionally, highly skilled teams will build a product and leave the running, along with some heavy documentation, to an often lower skilled team of individuals. The highly skilled teams are your "developers", whether or not it is software they are developing. The teams left to do the often relatively mundane running tasks are your "operators". DevOps seeks to bring these development and operations teams together, hence "You build it, you run it." Can we translate that model into more traditional products, or does the success of the "You build it, you run it" concept depend heavily on whether or not running the product can be automated?

Can we keep our highly skilled developers involved in the sometimes mundane running of their products, without risking boredom and frustration? Perhaps it is this very boredom and frustration that inspires them into continuous improvement of the products. This might be wishful thinking.

Even better, how do we up-skill our operators to a level where they can further develop the products they are responsible for operating? This feels like a more uplifting path.

Product Management - Making Everyone's Day Better

I've been in a product management role for the last nine months and it has been a paradigm-shifting experience. Due to an unrelated opportunity I'll be moving on from this role, but someone who was interested in potentially replacing me, asked me what I did. This is how I, as someone who is still figuring it out myself, described it to him. A seasoned Product Manager would probably tear it to pieces, but I can only describe what I've managed to gather in a short 9-month stint.

The Work

The analogy I like use is to take a 600ml bottle of Coke. It is by no means a perfect analogy, but it helps create an initial picture.

The Product Manager's job is to weave between the following activities in any order at any time:

• Work out if the client truly wants Coke

Assuming they do

• Work out if 600ml is the optimal size (for client satisfaction, frequency of purchase, profitablilty, etc. All sorts of factors could help define "optimal")

Assuming the above are both true

• Work with the marketing team to make sure the advertising material says "600ml Coke"
• Work with the delivery (manufacturing) team to make sure the label says "600ml Coke"
• Work with the delivery team to make sure the bottle is in-fact 600ml
• Work with the delivery team to make sure the bottle is in-fact filled with Coke (few people want 800ml of Fanta, if they're expecting 600ml of Coke) 

Then

• Work out if the client still wants Coke. If yes, rinse and repeat above. 😊

If client wants "Fanta" or even just "Vanilla Coke"

This is an area I didn't get too much into, but we'd then start looking at

• Work out whether we should run the products side-by-side
• If not, work out plans for sunsetting the old product and bringing new ones online 

I think there are so many more intricate pieces to each of these items, and probably some major items missing from this list, but these are the things I had the privilege to work on.

Purpose

The purpose of all of the work above is to optimise the client experience, that is just make it awesome for them. That leads to repeat business, referrals, improved relationships, increased profitability, and so on. Ultimately, our work tends to improve the experience of everyone involved, which is potent motivation.

• The finance team find things easier to bill, as everything is well set up within the billing system.
• The sales teams find things easier to sell, as they have collateral, they know what they're selling (and what they're not), and how we can address out-of-product queries quickly and easily. Their customers are happier and therefore like them more.
• The delivery teams find things easier to deliver, as they know what is expected, what tools are available, what's included, what is not, where and how to find additional support.
• The leadership team's job is easier as they have more engaged, more satisfied staff to manage.
• Execs and owners are happier as more efficiently delivered products are more profitable (assuming we have priced right!), and staff are happier and more productive.

So you are a highly appreciated team member, which is an intense buzz.

Approach

So this is going to sound super lazy, but I found the key to the product management role was to try to do as little of "the work" as possible. This maybe more of a goal than a reality.

Your role is to inspire, delegate, excite, support. You're managing people that you have no authority over, which is a thought-provoking challenge. However, people find what you're doing so helpful that they are almost clamouring to assist. You need to get teams to own their part of the bigger picture, as much as possible. For example, technical teams need to keep technical wikis and processes up to date, the marketing team has to create the collateral, and the sales team have to engage with what has been developed to keep up to speed with what the organisation can deliver. All the while, you tie it together using various tools such as Product wikis, presentations, communications, reinforcement of consistent language, and more.

You're a conductor. A coordinator. A consultant. A facilitator.

Summary

So make the customer's experience excellent, by inspiring teams of people to make their individual pieces the best they can be in service of that goal.