Courage

Courage

This is a word that has been showing up around me now for a number of months.  This word would sometimes show itself to me deliberately, maybe as part of a conversation I was having, and sometimes would show itself to me in casual ways by showing up around me in my reading or in posts from friends. I had not been giving the word a great deal of thought though until this past day or two - which is ignoring my own rules about coincidences that go on around me.

So why am I bothering to write about it now? Life seems to be pointing me this way - so doing it seems appropriate now.

Courage is defined like this:

Courage, n.

1. The ability to do something that frightens one.
2. Strength in the face of pain or grief.

But I think courage goes quite a bit deeper than this definition. I think courage involves a great deal more than just overcoming something that scares or frightens. I think courage may involve a life time of things built up that may require being torn down before it can surface in a singular moment of overcoming what has been placed before you.

I would say that courage is not something that exists alone - it comes with fear, it comes with baggage and experience of ones past that can magnify the effect of a situation far beyond the regular "I don't want to get on that roller coaster." sort of fear.

Courage is something that seems to get harder as you get older due to carrying emotional and physical scars from everything that came before. Courage seems to grow to be hard because we all grow up and our social interactions start to take on apparent enormous meaning.

"Be who you are and say what you feel because those that mind don't matter and those who matter don't mind." - Dr. Suess

The people in your life that matter will be taking the time to understand who you are - they are the ones you don't have to careful around. Unfortunately we seem wired to also care about people who will not take the time to get to know who we are - we worry about bruising egos and causing trouble with the words we say. I am not saying that we shouldn't be observant enough to know when 'not' to speak, rather I am saying we are far more careful than I think makes sense.

From the movie "Finding Nemo":
Marlin: Now it's my turn. I'm thinking of something dark and mysterious. It's a fish we don't know. If we ask it directions, it could ingest us and spit out our bones.
Dory: What is it with men and asking for directions?
Marlin: I don't want to play the gender card right now. You want to play a card, let's play the "let's not die" card. 

Dory spends time attempting to help Marlin to loosen up and to try things he has not or would not normally try. Throughout the movie Dory is challenging Marlin to see things in a different way - to see the things that are being missed rather than the things he is purposely doing. This constant pressure from Dory is forcing Marlin to ask 'WHY NOT' in relation to trying things - or allow others to try things. Dory is asking Marlin to bend his own internal rules, built up over time and as a result of Marlins having lost his wife. We can all get caught up with following the rules, when the rules are mostly self imposed and are not always in our best interest.

My point - doing anything courageous involves occasionally (ok, more than occasionally) overcoming a great deal of built up opinion, and baggage accumulated across our entire lives. The first moment of being courageous is hard, like going on a roller coaster for the first time, but each occasion there after gets easier and easier because we can see the positive benefits of having that courage in the first place. We have to be able to let go - and be ok trying the same thing more than once. We have to be willing to experiment with our lives, sometimes risk things more than we may like, but it is the only way to succeed in getting past things that may have hurt us in the past. Its painful to keep trying, and it can hurt - but you can not let it discourage you from doing so because the worst thing you could possibly do is give up.

 

Forward compatible data consumption

Forward compatibility means ignoring new fields should they arise ... passing them through if possible, ignoring them if they can't be passed through.  i.e. FOCUS ONLY ON WHAT YOU ALREADY KNOW and ignore the rest.

This means in XML parsing, if you are using annotation based parsing - tell it to ignore fields and objects it doesn't understand and continue with the rest, or if manually parsing to only concentrate on known objects and ignore the rest.

Same thing for json, annotations (like Jackson) need to be told to ignore fields that can't be mapped into the objects in a known way and to proceed with everything it does understand.

This way other systems can include new information that could be consumed at some later date without impact to the system at hand.

Why is all the above at all relevant or important - these steps are vitally important to the compatibility of APIs that you might be developing. In order for the API to be forward and backward compatible as changes to it are made the API system must be able to accept new things or ignore things it does not currently understand. APIs have to hold themselves accountable for what they 'know' they can do - and things that can safely be ignored.  If the API you are developing can't ignore things it doesn't understand, then errors get returned to the clients that may have otherwise resulted in a useable response from the API.

Agile Funding / Product envisioning - A lunch conversation

So - in a conversation recently where we were talking about how a large corporation like Big Co. deals with financing their programs, projects, products.  The conversation turned to when is the appropriate point to include the engineering teams in the product development mix.  The jist of the conversation was that similar to the idea in software engineering that it is terribly costly to use production to find basic coding bugs (bugs that can be caught with unit testing, and code reviews) it is terribly costly for product groups to be using engineering resources to test their theories about what the customers would like to see in the products that Big Co. produces.  Adding to this conversation was an ongoing undercurrent of finance at Big Co. having a difficult time understanding how to measure and supply money to the organization in an 'agile' way, meaning how do you make the bean counters happy when talking about how to manage finances in an agile development structure.

So the question that followed from the discussion was - if finance at Big Co. is always looking to squeeze cost out of expensive things like engineering and they are having a difficult time trying to predict and forecast the overall cost in an agile development world, what is a way that product development could be structured that would make things easier on both sides (engineering and finance) as well as help the product folk find and refine their thoughts before ever having engineering develop anything?

I tossed out the following idea, what if you structured product development and finance in a pyramid like the following:

At the bottom of the pyramid, you have lots of really small, experimental teams.  These teams could be made up of a product individual, an engineer, maybe an experimenter (someone to help setup customer experiments).  Each one of the these teams would be financed based on the ideas that they are testing and each one would be given a finite amount of money, lets say $50k.  Each team would also be strictly time-boxed to no more than 2 weeks work on a given idea/hypothesis.  Big Co. could then run lots and lots of these little hypothesis tests and know for sure how much they wanted to spend because the dollar amount would be fixed to the number of test teams in flight at a given time. 

Further up the pyramid each one of the teams near the bottom that uses the $50k they have been granted and produces a hypothesis that they can prove and have proven, a slightly larger team can then take up the mantle.  This next step up gets a larger amount of money, lets say $200k, and their time box grows to something in which they can make the idea from the lower level a little more concrete and real - lets say 6 weeks (for Big Co. currently, this is two sprints worth of development).  At any time these teams may run into insurmountable road blocks, or things that have no solution - in which case work can stop and they can move onto the next thing coming from the lower level.  If however they produce something adding to the previous levels work, this can move onto the next level higher and be funded further.

Even further up the pyramid - we are getting to the point where things are much more well defined, there has been a fair amount of testing and verification of hypothesis indicating that the idea is sound and can turn into a product or a products new feature.  The money granted can be quite a bit larger say $500k-1M or more.  The time box to create can be slightly larger as well, say 24 weeks (half a year).  I should note that increasing the time box does not mean that the shipment of this new thing waits for 24 weeks - it should still follow agile practices and be deployable at the end of every iteration (or in the Kanban case, after every story is marked complete).  This is where the final delivery to the customer can happen.

At each of these levels the product team or business can choose to cut their losses based on real data from real customers saving them from having to finance what doesn't work and keeping the process moving as quickly as it can.  This also prevents what I will call "Whim Based Product Development" because all the product work becomes based on testable and measurable facts.

Would love to hear your thoughts on these ideas - as they are just that, ideas.  Like most things, they need work.

Your ORG Chart is a BLAME flow chart

Your organization's org chart might be more about defining a flow for blaming someone rather then helping you to understand how the organization actually works.

Traditionally companies create an organization chart to provide order to the madness and chaos.  The org chart generally contains a name, and a title and provides this nice neat way to see who reports to who and who might have information that you might need to get.  Boxes neatly contain people, grouped into other groups who report to managers who report to VPs and so on.  The problem I see is that this same problem solving org chart can be used as a huge bat to bonk you on the head in an organization that values a command and control attitude.

In a traditional company (one that is likely headed for a huge spiral of death at some point, another post for sure) the managers all feel the need to manage.  Managers are provided arbitrary features, that need to be done by arbitrary dates or at least it seems that way.  Work items tend to lack context for why they need to be done in the first place.  The missing context forces managers to attempt to fill in blanks with what they already know or can easily find out.  This picture will be incomplete - but the all important DATE which was derived based on this information will be held sacrosanct.  The team will work to deliver by that date, but will invariably run over and release some time after the original date.  Sometimes this late delivery causes other things to slip and on and on.

No one is specifically held accountable for these date slips in the organization, but what starts to happen is that work items requested and placed onto a group but not completed begin to get noticed by anyone in that reporting tree on the org chart (remember that all important information dissemination device). This is a terrible reflection on the ability of that group of people from the org chart to deliver so blame starts to be laid.  This blame may start at the lowest level, but soon works its way up the org chart and around the org chart following the connections on the org chart.  This is a terrible feedback loop however, as blame makes people more defensive, and more likely to want to have really tight control over what is being requested and what promises are being made in relation to delivery.  In the end - the org chart might actually be the worst thing for the company as it describes a way to shirk accountability off onto someone else for a failed effort.

In the reverse this same chart can indicate who to praise when things go right, but lets face it if your organization is already command and control it might be the exception rather than the rule that someone is getting praised for independent effort and thinking.

Imagine what would happen however if the org chart showed nothing more than how the 'teams' (cross-functional teams) related to one another, you might still be able to assign blame, but now its a team blame - which is easier to own up to and take accountability for.  You org chart now isn't describing reporting structure and is less useful in providing a blame path and more useful in providing a way to discover where answers to specific questions can be had.  It revalues the relationship of who reports to who into a teaming thing and a matrix idea.  We might be better for a change like this in our companies.

Just a thought.

EDIT: I should add that this thought process was inspired by the comment from Claudio Perrone's presentation @ LSSC 2012.

Gentle Strenth - Wizdom Applied

My friend Karl Martino said to me one day a few weeks ago that I had wisdom. I laughed a little at the remark, which in retrospect I think I should apologize to Karl for as he was genuinely attempting to pay me a compliment. I thanked him but told him that I do not feel wise. I did however walk away from that conversation with a number of things spinning around in my head. These thoughts coalesced the Sunday of that same week when I was @ church, and my churches minister delivered a sermon on "Gentle Strength".

My minister opened with saying he was standing in a mess hall with the 3rd Battalion, 47th infantry regiment - waiting to deploy to the middle east with a peace keeping force. There were pictures hung all around the room with quotes under neath them - the picture above his head had the following quote:

"Nothing is so strong as gentleness and nothing so gentle as real strength" 

Which he wrote down in his notebook and noted that the quote was not attributed to an author on the picture.

Going further into the sermon - the minister asked (and I am paraphrasing here):

Is gentle strength like the lioness carrying around her cubs despite those same jaws being used to feed her family by killing during a hunt her prides next meal, or the mother grizzly caring for her cubs but being the largest and potentially most fearsome of the North American animals. These animals are gentle with their young, but would resort to extreme violence in order to protect their young or if the need arose to go get food.

I really got caught up with this idea of gentle strength because I saw similarities in what Karl had called wisdom and what I was trying to become in my life - strong in leadership, but gentle in my exercise of the same. I really want to be a force to be reckoned with but to do so with a disciplined power, a gentle strength - so as not to leave a path of dismayed and destroyed in my wake and charge to make the world a better place.

My desire for this comes from several places, but I believe it to be brought from my experiences, the places I have been, the people in my life and the childhood I lived. I have certainly struggled to get my 'strength' under control, using my words to cut people, cut at them, or cut them down. However eventually being able to understand that I had an ability that others did not and what that abilities really deep and lasting affect on others was lead me to want to change that interaction. Call it self knowledge or self actualization but it came as I was on an internal search for a way to harness what was available to me and was 100% under my control.

I had used the ability to read and understand people to great positive and negative effect (mostly negative). My interaction with one person in particular had always had some ups and downs but was most of the time caustic and rather vitriolic. My understanding of the impact of this ability however was made clear to me in a single moment one winter around Christmas.

That year, many years after all those interactions had faded and were somewhat forgotten, a friend of mine indicated what sort of affect my words had on who they were, and what the affect of my "ability" was on the person they eventually became, how the way in which we spoke had impacted them, how my action had impacted them. That simple point, an instruction on life, THE thing that helped to move me along my path was right there - sitting in front of me and asking for nothing in particular, nothing more than clearing the air with me. That moment provided so much too me, I am ever so grateful for.

What solidified for me right then is that these types of learning experiences are all around us and can surface in ways we do not yet understand or expect. Take for instance how this post opened - with a friend of mine saying simply that he thought I had wisdom. I don't feel wise, I am just trying to live my life and leave people better for having met me, better for having known me, better for having touched paths with me - no more and NO less than what I get from them... those people that I interact with. I can expect nothing more and can give NO less than my very best every day - I can only attempt to apply a gentle strength to everything I do and apply wisdom (even if its just a perception of wisdom).

Oh, for those interested - that quote from unknown - the minister did find the original author eventually: The quote was from St. Francis DeSales, a man of faith - coming from a different place to the same conclusion.

The forgotten PhillyETE presentation tracks

So I am at the PhillyETE conference this week attending sessions on new technologies and systems that are available to me to work with in order to build systems that make my employer money. There are two tracks of talks that are decidedly non-technical at PhillyETE that while I am here I often attend. These other two tracks conference tracks do not often get very large audiences but I believe that they should, they are the management track and the agile track. The management track and the agile track are all about how work gets done inside of BigCo; these two oft neglected tracks are attempting to address how a development staff works together to get work accomplished. The problem is that the topic of how the work works is not particularly important to the development community - who seems to be happiest when they can sit and develop and not worry about those 'gory' details of what happens when they look up from their monitor now and again.

It's a game of people

Inherently, unless you happen to be the sole proprietor of a start-up doing all the work, development, hr and paperwork yourself, you are part of a system of getting work done at the company who currently employs you. This means that you, dear developer, are part of a system of people all working towards a goal. Hopefully you are all working towards the SAME goal, but I think that is the topic of a different post.

Because you are part of a system it is difficult for you to be 100% introverted - this is not to say that there isn't power in being introverted, I think that everyone needs time and space to ponder and consider things on occasion. The problem exists in your being part of a system that inherently requires interactions to a degree and level that you may not be comfortable with, development is a game of people, not one of code. The game is around having good people focused on accomplishing a goal, code, good code, is a consequence of that game of people. Each and every developer should be concerned with this game of people because it impacts how their work works. This game of people can affect how much time developers have to concentrate on their code due to unwanted or 'un-required' interruptions in the work day. The PhillyETE Management and Agile tracks are providing information on how to organize and structure teams so as to have those teams gel and become highly performing. These two tracks (management and agile) are all about helping teams to understand the game structure that they are playing within. PhillyETE is providing the tools for us developers to work with the system we are presented with at BigCo. to maximize our productivity and happiness rather then rail against it. The shame is that far to few people realize that these two tracks of management and agile are attempting to help teams of people (teams of developers in at least PhillyETE's case) to make the most out of the systems they work with and within. It shows in the low attendance numbers of these two conference tracks.

Reach out past your comfort zone

Developers are constantly reaching out past their comfort zone to learn new ways of doing their development work, new languages and new frameworks are constantly being developed and iterated on. There is a constant motion, ebb and flow of ways to accomplish a given programming task. I would love it if the development community would reach out past the code and the technology and realize that they work in a system of people and learn to 'code' the people system just as easily and simply as they code their computer systems. By learning to program the people system developers would very likely be making their lives and the lives of a great many people at the companies they work with and for hundreds of times better than currently exists.

We have to work with the systems we are given, but it doesn't mean that we can not work to change them and cause them to be better to achieve the things requested of us. What a much easier place to work BigCo. would become if this were the case - all of us working to improve the system we work in. I look forward to the opportunity to make those system impactful changes, day in and day out, I hope you will too.