Monday, April 25, 2016

Needs, wants and everything in between

I don't think that the following statement should be surprising to anyone but:


The reason, I think, is that everyone wants to feel like they have equal shot, equal footing to have their needs met. It isn't possible to have your needs met when the other people involved in a conversation are not interested in listening to what you have to say. Beyond that it is increasingly difficult to have your needs met if you are not able to articulate what you actually need.

Sounds easy right - you just have to be able to say what it is that you need... You just have to put it out there and allow it to be heard and then your needs might potentially be met, so what makes it so amazingly fucking hard to ACTUALLY do?

Social interaction, moral codes and judgements

My theory is this - over time we are taught as kids by our parents, and elders about things that we can't say or can't do. Kids are negatively reinforced by their elders about how they use their words and are told that the choices that they make can hurt people. As kids we are taught to take care with other peoples feelings and often the ways in which we are taught to do this are statements like:

"...don't say that..."

" can't say that to people, you'll hurt their feelings..."


But we are rarely positively reinforced for using words and other statements to state what we feel and need while also not hurting the people we are interacting with. Think of it like sharing that toy that there was only one of when you were little. Someone else was using it at the time you wanted to also play with it. Now you have choices, you can walk over and take it, you can ask to play with it, etc. However when young we often don't consider beyond ourselves and we don't often have a role model for interacting. We learn as we go about what gets us in trouble and what doesn't including some of the sneaky "I get my way without getting in trouble" actions that can be taken.

Speculate for a minute though - what IF what we modeled for our kids and others was as truthful as kids tend to be, telling things like they see it with few filters but the words were chosen to be clear and concise and non threatening.

Marshal Rosenberg lays out a discussion and conversation model called nonviolent communication. Where he describes the ideas of stating clearly what you observe about a situation, describing how it makes you feel and as a result what needs you have around it. Seems straight forward but is actually amazingly difficult to do. Think about the last argument you had with someone, do you think that you would have been able to be level headed enough to not escalate the conversation with angry commentary but rather stop and say what you observe and what you feel? Ya, I didn't think so - I know I certainly don't - but I am trying.

Imagine if you will

Now - lets go back to the kids. I mentioned them earlier because I wanted to speculate what our adult interactions would be if we were able to example for our children when they were young a method like nonviolent communication. Kids are unfiltered and wonderfully blunt, they say what they see and their interpretation on it. Kids are not afraid to tell us how they feel, but somewhere along the way as we grow up the interactions we have and the things we are told by our elders drum out of us the ability to just say how we feel, and what we need. I love to speculate how much better a place the world would be if we could all get our needs met. I for sure am looking to get my needs met, and using nonviolent communication where I can to help me articulate them.

Friday, April 8, 2016

Trust - Ebbs and Flows

I find myself thinking about trust a great deal lately - it is another of those life things that seems to be rising to the surface enough that I should likely pay attention to it. A friend of mine in fact just said

"Trust once lost, is hard to regain."

Which is why I am now sitting here typing out this post.

From a very young age I found that I was able to read people fairly well. I was certainly not perfect at it as 'reading' someone is a bit of an inexact science but I found I was fairly good at determining quickly if I was bound to trust the person standing in front of me long term. Sometimes body language would say one thing and their words something different which would leave me feeling like I couldn't trust them. Overall I was often left wondering about interactions with individuals long after they had occurred trying to understand why the conversation broke out the way it did, why certain things happened and sometimes why certain things didn't happen at all. The interesting thing for me is that while my instincts may tell me not to trust someone I often trusted them anyway. Glutton for punishment I suppose.


I have wondered for myself why it is the case that I always seem to start from a default of trusting someone implicitly even when my instincts may tell me otherwise. It seems to be my nature to start a relationship with giving it my all. I want to trust, I want to know I am trusted, I want to exchange ideas and know that ideas can easily be exchanged with me. To put it simply, I pour myself into the relationships that I have because I think it is important to be fully engaged and fully involved. This makes having lots of incidental relationships super annoying, because I am not much for incidental. I want people in my life that are willing to connect that way. I want people in my life that allow me to pour a bucket full of my trust into the relationship, instantly. In the reverse I hope for the same from them, but I can do no more than hope as their trust isn't in my control...

Trust Exchange

I had a conversation with my friend Maurice Gaston at one point about trust and trust as a flowing exchange between people. The idea that trust isn't something all on or all off at all points, that it more flows like a river or comes and goes like a tide. The discussion framed up some thoughts around why some discussions I have feel more relaxed and others feel more strained, as if some conversations require a great deal of concentration to get right and others go right naturally on their own. I think it does boil down to the trust that we have and the mental model we have built up of the person(s) we are talking to.

Chris Argyris, an American business theorist, wrote about these mental models we create for our interactions. He outlined that people over time generate a 'theory' of the person that they are interacting with and how that person will or won't react in situations that they are placed in. When we interact with someone else we try to reconcile the actions that individual takes with the theory we have in our mind for that person, if they match, we reinforce the theory being the 'right' theory for that individual. When the theory and the actions that are presented mismatch we get suddenly lost trying to reconcile and come up with a new theory for them that fits the new data and situation. He called out that this all occurs very quickly - likely at a level we don't realize we are doing it. Stay with me... bringing it back around.

I think the reinforcement or the discontinuity of conversations likely line up with the level of trust and the ease with which the conversations seem to occur. That trust ebb and flow maps directly on-top of Chris' commentary. When my theory of an individual is reinforced by that person's actions, I feel more likely to trust and less like something odd is going to happen. When my theory is constantly being challenged, I feel less likely to trust and the conversation and exchange is harder.

I am sure that there is MORE (much more) to this. This post just represents a part of my consideration of trust.

Trust for me means - Getting Hurt

I am a very trusting person, if you ask me a question I will give you the answer, personal or not. Comes with the ADHD and lack of mental filters for what I should or should not say. I have gotten better over the years about picking my words more carefully so that I don't come across as so blunt or surprising, but I haven't stopped trusting people by default. I want it to be the case that people I am involved with trust me and understand that as a friend of mine, that I would likely move heaven and earth to help them, often times at my own detriment. This has made me try to limit the number of close friends I have - but the reality is that most people I see often enough I would consider my friends and they all get equal treatment that way. Move the stars if it would help. It is painful though because often enough that trust only flows in one direction, and for me its hard to turn off allowing me to get hurt or used more than once. That too has changed over the years, but I am likely still not as careful as my experiences would dictate about how much trust I provide people (including those that have hurt me more than once).

Trust can also hurt when I don't pick my words more carefully and a raw feeling escapes to the surface and out my mouth. It often comes as a surprise to the individual involved.

Why is trust so hard to get back

I think that this is only human, we tend to focus on losses more than gains leaving people less able to see how much was there in the first place. It means that we feel so much more keenly the lost trust, no matter how small, rather than all the trust that has been exchanged over time. Changing that around is difficult because people are not wired that way. Consider your avg. IT help desk and all the vitriol they get tossed their way, no one ever calls them to say "Hey, great job your doing". We unfortunately focus on the negatives. Feels odd to me, because I get burned and go running back in, I wonder what does happen when you let go.

Tuesday, April 5, 2016

Enterprise source (Open source for the enterprise)

What is enterprise source

Enterprise source for me describes a way in which I can manage software development that involves more than just 'my' team in order to accomplish a given task within my organization. In a host of ways enterprise source mirrors how an individual contributor would work with any open source software project - building up a change that adds a missing feature or fixing an existing bug and then submitting that to the project. What I build/submit might be something of value to everyone, or it might only be of value to me specifically but it is up to the project as to decide if what I submit is worth while to merge and make available as part of their project. The same process is used in enterprise source with some interesting hitches that are worth noting which we cover in slightly more depth later.

Why would you want to do enterprise source

So - in the very small scale of the word organization you likely wouldn't have need to do this at all. If your a company of 10's of developers there may not actually be any occasion to do this at all. Enterprise source however makes a great deal of sense when you are a corporation of significant size, multiples teams doing work across the organization. In the the large corporation sense what you would like to have is teams that are decoupled from one another in a way that allows them all to move to deployment and delivery independent from one another. Different teams will have different product drivers and potentially be working on completely different lines of business that require them to operate independently. At deeper levels in the technical stack however the teams may all have to interface with a back office, or an API set.

In the typical organization the team in control of the API set will have their deployment schedule and will take stories and other content for delivery from teams needing things around them. The stories are organized and prioritized but may not meet everyone's needs. So rather than ask them to write the new code, I give the requesting team (the one with the need) the ability to write the new code into the API code base. Here is where things start to get really interesting.

How does it work

So now I have a change that one team can't do but my team can in order to essentially 'unblock' myself to move forward. Awesome. That API team allows me to submit code to their code base a-la Enterprise Source and get it deployed to support the actual feature function my team was asked to produce. I write what I need following their guidelines for development and using the information that they have provided to me in order to work in their code base. I make my change and submit it for code review which gives them the opportunity to give me feedback on the change my team was looking to make. A few rounds of code changes back and forth between my team and the team I am submitting code to and then the code is merged. That team then deploys on their normal schedule (hopefully following continuous delivery, so as quick as humanly possible).

What are some of the pitfalls

There are some human and technical drawbacks to this way of managing code bases and dealing with things inside the organization. Lets start with the technical drawbacks:

1) Who owns the machinery / hardware that gets deployed to

So my team submitted code to another team and they have deployed that code to their existing hardware providing me with access to the endpoint that I just wrote but this doesn't address situations where what I needed isn't like what anyone else needed. Now things get a little odd because with my team and the team I submitted code to we need to decide if new hardware would get stood up. Who manages that new hardware? Should the new hardware be something I deploy to all the time? Is the deployment in control of the team who 'owns' the code OR is it the responsibility of the team that submitted the code to get deployed? This can get messy quick. This writer also doesn't have a direct answer to these questions. It is an exercise in experimentation to find out what path works best for your teams and your organization.

2) Who owns the deployment process

As noted above this is a decent sized question that goes hand in hand with which team owns the hardware. You might be able to make use of the existing system for deployment easily, you may not and this will vary from team to team as while the infrastructure you are working on might very well be the same - in any company of size - the use of that infrastructure will differ and MIGHT differ greatly. 

3) Arguments about the submitted code being 'Up to snuff'

Remember that in all cases there are humans involved so as a result personalities may clash. Teams should be aware that this is an almost 100% guaranteed conflict. As the owning team looks at their own internal process and moves the cheese for other teams that are submitting code to them. Things like code review, code style, testing style can become quite contentious if the discussion is not held in the open.

Benefits and impacts to the organization

The benefits to the organization focus mostly on allowing parts of the organization to slide past one another in a way that allows people to continue to move forward producing value. If one team gets blocked by another, dates become a discussion and people start to play games with he said / she said about when something might be able to be delivered. If teams are completely autonomous and allowed to do work at their own pace, then they control the dates and the delivery to their requester which prevents the dependency from causing to many if any issues. This form of organizational lubrication can be amazingly helpful.

Enterprise source is an excellent way to allow sections of the organization to share a common core code base and to continue to deliver on promises when everyone cares about the quality of the submissions and ownership of that shared code. If you find your team having dependency on another teams code base but they don't have time to make changes for you - consider offering to make the changes for them. Its a conversation starter that may lead to having a more open code environment for your organization.