Silhouettes: understanding unique talent

My favorite skateboarders these days are Rodney Mullen, Ben Raybourn, Chris Haslam, and Chris Cole. There is an interview of Rodney Mullen where he says he is looking for a special "silhouette" in skaters. In fact, he is saying the he is looking for uniquely talented skaters that have internalized their skating into their cognitive growth process. To give you a mental image of what I am saying:
We all need things we can lean on to grow. What I mean by "leaning on something", is that we use it to support us, we use it as dependable reference. When we are young we lean on our parents. Later, most of us lean on our social/economic "fabric". Yet others lean on their own selves. If you are unlucky, this self "leaning" may make you a unpleasant narcissistic person, yet if you are more lucky you do not lean on a "synthetic" self created social reference, like a narcissist person, but on a self created non-social reference. And for the people above, on a self created skateboard cognitive reference.
This all sounds complicated, yet in fact it is not, Rodney Mullen has already "said it all": look at the silhouette of these skaters, are they connecting to you like others, do you see them like others? In fact, neither: they are not connecting to you like others, and you do you see them like others. There are connecting to themeselves, and we perceive this as a combination of a unique "character" or style of skating, plus a slight social disconnect.
You probably need to have been a skateboarder to "see" what I mean when I talk about these people. But if I say: Steve Jobs, David Bowie, Cat Stevens, Stevie Wonder, Eric Schmidt, maybe you get a feeling of what I am talking about.

(Say thanks, to Splat for having ask me to explain this)
All original content copyright James Litsios, 2013.

Market connectivity

Financial exchanges can be seen as big computer clusters that are accessed through specialized APIs.  There are usually a few different ways to access an exchange. The connectivity can be direct or indirect, and there are usually different APIs for the different services.  Direct connectivity is the fastest way to interact with the exchange and pretty much implies that you are a member of the exchange or that you are working closely with an exchange member. If you cannot afford or do not want to bother with direct connectivity then you access the exchange indirectly: your system will connect to a broker’s system that is connected to the exchange.  Such a broker access may bundle up the different services into one API (e.g. using the FIX protocol). Direct connectivity usually has different APIs for different services.  Typically there might be a trading API, a price feed API and a clearing API. Orders and quotes are entered and updated on the trading API.  This API may or not receives confirmations of these trading commands, but will normally at least report own trade activity. Overall market activity is reported through the price feed API: it reports trading and quoting activity of other participants. Trades are reported as “last price”, quoting activity usually comes in multiple levels of details. For example, level 1 reports best order and quote activity, while level 2 reports all order and quoting activity. The clearing API tells you what happens “after” trades happen. For simple financial products like stocks, it is mostly just confirming your trading activity, but with more complex products like options, the clearing API will report exercise activity where the options are converted to stock or to cash.

In time critical trading activities like algorithmic trading or market making, the specifications of the trading API are not only what can be sent to or received from the exchange, but how much and how quickly these communications can be made. Trading commands usually have a very short validity lifetime: they become out of date with new information. All APIs have physical limitation that will cause them to block or queue-up when used with too much data or too high a rate of data. Therefore, delays will happen if too much trading activity is attempted through a trading API, and these delays may make you lose money. Some trading APIs provide extensive details on how much trading activity they allow. They may document the throttling algorithm used within them. For example, they may specify that no more than N trading commands be sent by given period of time. Other trading API may simply block when overused, or worse they may silently queue up trading commands without any form of indication. A way to avoid having the trading API queue-up always limit your trading activity. Yet that is not so simple because although you may decide when to enter an order into the market, the decision to update or cancel that order is often triggered by new information provided by others. Therefore too much new information will either cause you to try to overuse the capacity of the trading API, or leave you with “stale” orders that will be picked up by others (and bring you loss). For this type of issue, some APIs allow “mass cancelations” commands that allow all orders and quotes to be held as soon as possible, while using a minimal amount of API bandwidth. Note however that not all trading APIs offer mass cancelation options, and that the mass cancelation command may itself be subject to delays because of previously entered commands, or may have higher priority access to the exchange but then cause trouble with previously entered but not yet processed commands.



All original content copyright James Litsios, 2013.

Energize your team: analogy between agile teams and lasers

Electricity, magnetism and time are tightly intertwined. You can try to work separately with them but that will not give you the whole picture. While if you consider the dynamic relation between all three, you can do magical things. For example, you can “bounces” electrical energy back and forth into magnetic energy resulting in alternative current, which magically almost avoiding the need to actually carry “real current” (which is expensive). Or you can “juggle” these energies while moving forward, and thereby creating photons and light.

In project management, tasks, resources and time are also tightly intertwined. You can try to work with them separately but again at risk of being inefficient.  It is a bit of a stretch to compare project management with electromagnetism, yet it is intuitively pleasing. In electromagnetism, work is created by “applying” electrical currents and magnetic fields on each other. In project management, work is creating by “applying” tasks and resources on each other.
I could argue how a waterfall process is comparable to an electrical motor with a rigid physical setup to maintain a well-calibrated cross product between the magnetic field and the flow of currents, but instead I would like to focus on the photonic aspect of light and how it can be compared to an agile process.

Here is the idea: a photon of light is a “self-encapsulation” (wavelet) of oscillating electrical and magnetic fields. (I am not a physicist, so please excuse an abuse of interpretation here). Comparing this to a work process, the photons can be seen as agile work cycles that are “bouncing” between defining the tasks and applying the resources on them. Every cycle of an agile process (e.g. Scrum), can be seen as the photons running through a single frequency cycle.

Agility is the ability to “bounce” your energy between “defining” tasks and “doing” tasks. Stretching the analogy a bit, you might say that the repetition of each agile iteration (or sprint) and with its generation of client deliverables and new future tasks, is a bit like a laser where photons “hit” energized states and generate new photons. The beauty of this analogy is that we can all “feel” how the coherence of light produced by a laser is somewhat similar to an agile team efficiently bouncing past results and knowledge into the definition of new tasks, and then efficiently executing these tasks within an agile iteration.

The laser analogy goes even one step further: lasers produce light that usually goes all in the same direction with the same frequency. If you are very lucky and your product backlog is very much aligned with what the customer needs and your past work always matches up with your new needs, then yes, you too can have a “laser” agile team that goes straight and coherently over your tasks to your goals. But, if your backlog needs to undergo changes (e.g. because there is important new information to interpret), or if you have made mistakes (and we all do!), then this focus on coherence and “straightness” is actually a great risk: a “laser” like team may well end up with the wrong product and possibly with the wrong technology. Again, the issue is that if you try too much to make your new tasks match up with your previous work, you end up going straight, but not necessarily in the right direction. And although the product owner may realize that something is amiss, it is not easy to understand what. One reason is that the team does not understand that it could turn away from an obvious “coherent and straight line” future, and therefore may never indicates to the product owner that the future could be different. Another reason to by wary, is that being a “laser team” feels good: it is great to feel tasks fitting together with marvelous coherence, it is great to have a fantastic history of “little refactoring”. Yet that great feeling is also blocking the team from questioning its actions, because that “would not feel as good”. Without enough self-questioning the team is too much influenced by its previous actions and may end up elsewhere than desired.

So what should a team do about this? The thing is, if you are aligned with your long-term goals, then following the feelings of coherence and alignment is the right thing to do. It is only if you are not aligned with your goals that you are fooling yourself. The product owner is therefore key here: he or she must work hard so that when the team feels that everything is fitting together, the team is also going in the right direction. Said differently, the product owner’s or product manager’s primary job is not to check that the team is aligned, but to ensure that when the team feels “right” it is also going in the right direction. To use the laser image again, the product owner wants to assure that work will be aligned with the overall goals at the creation of each photon. He/she cannot do so by physically controlling each creation and execution of task because that would simply not scale. Instead the product owner strives to provide a “higher level” guidance that ensures this alignment. In scrum, this is why the stories are not tasks. In practice good product owners evangelize their teams so that they “see the goals” and therefore produce tasks that are aligned.

Lasers work because the materials are in “energized states”. Pushing our analogy all the way, (and using scrum), we can say that the product owner energizes the team in such a manner that when the team creates and implements tasks, in a coherent and aligned manner, these tasks are also directed towards the product goals.

Who wants to work with clunky electrical motors when we can all have high-powered laser devices?