Sunday, January 30, 2011

What is :: Hackmode - Flow - The Zone

I've always been interested not only in the specifics of software itself, but also  in the method of how software is created, and what surrounds it. That being teams, leadership, management, external factors, business constraints and likely most importantly the sociology and psychology of creation.

More of a holistic systems view of the whole process I believe.  My degree and area of interest is Software Engineering Management so some of the how as well as the what.

I realised I've found myself explaining the same topic repeatedly to people in a business context (i.e. suits) who don't develop software, but who interact with people who do.

So I thought it best to just write it up, then I can direct future people I encounter who ask or need to understand it to here. Also share my thoughts and hope to elicit ideas and experience from others, as this topic really interests me.

The topic is that of the psychology of a developer, when operating a maximum capacity (relative to them). What's it like, how do people get there and what are the good and bad aspects of it.

Typically I find organisations (mid level managers usually) expect and demand maximum output of developers at all times, in any conditions and with no support. Any failure to achieve this with a (typically) negative or unsupported environment is wholly the developers fault (see my other post on burnout for what happens then !).

The usual analogy for that situation is a Dickensian work house, where more hours and faster (more frantic speed) should equate to more output.

Obviously nonsense, though still lots of places like that about, and it's all of our responsibilities to eradicate them.

 

The Mind Set

The mind set of a developer when at maximum level of creation and development is covered by an area of : Positive Psychology. in particular "Flow".

Introduced by Mihály Csíkszentmihályi it is a well accepted description and understanding of the mental state of individuals, who are wholly engaged and passionate about an activity they are doing. There have been many posts on passion in developers being one of the main things, and I agree (we just need to educate recruiters now).

The wiki page for Flow covers a lot of the general aspects of the topic, so I'd like to relate/translate that to software creation and teams. The page does mention professionals and references Hack Mode and The Zone.

One way that I attempt to explain the state of being in Flow to people who haven't been, or can't understand it in a developers context is to reference Star Trek Generations. While a techie film itself, it's still more likely to have been seen by someone I'm explain to, than them reading psychology just for fun.

In the movie there is a character, Soran (Dr. Tolian), played by Malcolm McDowell (yes, I know he must be the evil baddie he's English .......)  who is attempting to get back into the Nexus.


The Nexus is described as :

"The Nexus is an extra dimensional realm in which one's thoughts and desires shape reality."

by Memory-Alpha.org (which is one of the better descriptions I've heard).

This is a fairly fanciful analogy I'll admit. Though there are a lot of comparisons of being in an place/zone where everything you can think of just happens, where you laugh at test units and write and re-write swathes of class/functions in moments. Code of pure gold flows from the keyboard etc.

And it's a true pleasure, not only are you creating at a pace that would make accountants shiver when calculating your hourly rate vs effectiveness.

Though far far more importantly, you are doing what you enjoy and are feeling the rewards of creativity near instantly. Maslow would likely describe  you as in a state of : Self-actualization.

For me there is no reward, monetary incentive or management manipulation that can either induce this, or surpass the reward of experience itself (though for sure I'll accept a health pay check/equity for it when it does happen !).

I'm not sure I'd destroy a planet and it's people (as Soran was prepared too), to get back to it on demand, though I'd think about it ........

Though it raises two very interesting points for me :
  • How do you get there ? 
  • How do you stay there ?

 

Allowing it to happen

Personally (and in the research I've done) the path must include a level of passion and/or very high engagement. This typically can't be demanded by management or forced onto a person.

It's much like (my aversion to) the TV self-help demagogues, who are forever telling (prescribing to) people how to live, opposed to the people creating and embodying the answers for themselves.

In counselling, it's called client centered. Zen and other eastern philiosphys continually talk about the energy and power within, and that's where the source of a lot of this comes from.

The main thing that management, and more suitable team facilitator(s) can do, is create and protect the environment to allow the developer(s) to reach this state. Once that is in place, communicate the challenge/goal and desired outcome, then stand back and get out of the teams way. Ego is the typical reason this doesn't happen as weak management has to feel "in control". A shame, though a common human failing.

Attaining Flow is a skill and ability, it comes from engagement, curiosity, the challenge and having the skills to overcome the task.

Meaning you have to be good enough for the challenge, that you're not battling with your tools. Be that, a programming language, the server configuration, understanding of a protocol etc.

So the things needed are :
  • A sufficient challenge, it's engaging and enticing
  • You have to be "up for it", personal motivation and external encouragement
  • Have sufficient skills enough "to take it on", and not be over whelmed

As per the diagram (I grabbed from wikipedia) :



Staying there for the individual is a matter of practice, of concentration and immersion. Much like practicing to meditate, I remember when I started meditating I would last two maybe three minuets and my mind would wander, years later and half an hour is no real challenge within itself (more so the motivation to actually begin now !).

Staying There

I find the single most important piece in a development environment that is lacking, is the understanding of the other individuals (hence writing this so I don't have to keep repeating myself).

It can take any where from 15-30 mins for an individual get into this state, and become engaged and start producing while there. The constant inquiries of "Have you done it yet" or "Lets all have a meeting to listen to me talk" is doing nothing but breaking that lead in time, and hitting the reset switch for getting back into it. I'm all for communication, of course, teams and organisations need it. Though when necessary and in context.

I think the only thing that is more disruptive (and mentally painful) from being stopped getting to the Nexus ....... err a productive state of mind ..... is being ripped out of it once there. It's so jarring I've contemplated drowning people before ..... though have put it down to their ignorance opposed to malice.

Nerf guns in an office are for play time ........ not 24/7 while people are trying to work.

Shouting into phones in (or at people on the other side of) an open office (which themselves are very negative to focusing) isn't helping.

Typical management is driven by interruption, Jason Fried 37signals has talked about interruptions lately, and way pre-dating him is Peopleware that covers it in much more detail.

Thoughts

Personally I become very frustrated when subjected to the kind of environment that stops productivity and high quality productivity at that.

I (and just about all developers I've ever talked to) can do far more in 4 Flow hours than 8 of typical office, and it's far better for everyone involved. Let alone the future as the software is of a much higher quality : think lower Technical Debt.

So why not let it happen and protect it ?

As ever take care of #1 and have a thought for others trying to get things done.

Cheers
@JeremyHutchings


P.S. The statistical support of this is here

Tuesday, January 18, 2011

Dealing with challenging behaviour in IT groups

I recently saw a few tweets pushing a piece entitled : When Smart People are Bad Employees.

Luckily the sense of many comments shone though, and the author was eviscerated for what appeared to be short sightedness, poor understanding of behaviour and basically poor posting.

Though it did get me thinking about the amount of confusion and reactionary behaviour there is out there by this kind of management, which that author appears to be representative off (thankfully small and diminishing in my experience, though still present).

Another case of trying to enforce "us and them" I'm right your wrong, opposed to "we".

We're all human, and we're all fallible at times.

I found the majority of this kind of behaviour and approach comes from a lack of trust, of oneself mostly, and then the team. A fear response to attempt to control, opposed to having the will power and self control to resist such behaviour.

(There was another piece I saw on : Managing Nerds, while better and nearly saving itself with some tongue in cheek humour, it was ultimately "us and them" tactics as well as being simplistic and condescending)

Hence why I'm going to review some of the points  give my take on what is going on. Then actual options for how to deal with it, opposed to the original advice of :

"Put up with it, blame them, then fire them" .......

Behaviour

Though firstly, I think it is valuable to separate behaviour and the person.

One of the over whelming messages is the original post, is that you judge people and describe them from their behaviours. I suggest that you don't and you define and isolate the behaviour that you find challenging, and see it as your experience of that behaviour instead.

Keep the faith that most people are positive and want the same things, just some have trouble expressing it or communicating frustration.

Once you have identified the behaviour and stopped trying to judge and  blame the person, you can do the first best thing, and that is asses yourself.

There are volumes written yearly akin to : "What pisses us off, tells us about ourselves" etc. I could quote all kinds of philosophy, but you get the idea.

Is the behaviour you are experiencing out of place or inappropriate, or is it your reaction and perception that is magnifying it ?

As with just about anything in life, self awareness is key and also as elusive as it is time consuming to develop, though obviously well worth it.

If possible, consult with someone who's there that you trust. Possibly a colleague or team member. Remember it's by way of understanding are things how you see them, opposed to an opportunity to complain or try and build sides.

Communication

Just about all issues (of this kind) I've come across come from poor communication (and expectation), be it typical or deliberate.

Project groups are collections of people attempting to get a common goal achieved. Though within that you have collections of individuals who all see the challenges at hand in a different manner (which is a real strength by the way).

As well as being people, and all that goes with that themselves.

The usual kind of approach for management that reports all these difficulties is mandating and dictating to a group, how to solve the issue as they see it.

There are two fundamental issues here. First, the team will solves the challenges, that's what project teams do, when allowed, and support by facilitation. So focus on the issue, not trying to tell people who likely know better than you how to do it.

This is where trust and respect come in, not the iron first of weak managements "I'm in a suit and have a big title, I have to tell you what to do, what else am I hear for" (that topic I'll leave to Dr Paul Thomas).

One of the most important things to do is communicate, and the most important part of communicating is listening, not talking.

If you are experiencing what you perceive to be negative behaviour by people who are "negative" or "questioning you all the time" .......... find out why!

Resistance is typically a good thing when it's about a project, as someone who can see something you can't is likely trying to tell you something.

Control

If you are from the Dickensian school of management (lets call it "the 80's" and you have a huge Motorola mobile phone you like to shout into in the middle of the office), then control is going to be second nature. Anything Zen is going to involve "Asian people in silk pyjamas waving their hands about".

(As it is I rather like Tai-Chi, it's taught me lots about  dealing with energy, negative or positive, and how to go with the flow and re-direct a lot of the time. Also the costs of going head to head, Yang vs Yang, feeding anger etc.)

There are times when legitimate control and power make sense, for instance a parent physically stopping a child walking into a busy road. Another typical one is the military, because of chain of command (though even there there are caveats for disobeying certain orders).

Now unfortunately I've seen groups that are run at one extreme or the other, a crèche or a military dictatorship.

I'd suggest will intelligent professionals, both are pointless and counter productive.

Though what is apparent to me, is when you have a clash of expectations, within the team. A lot of managers attempt to actually run and direct individuals within a team, i.e. that age old term : micro-managing. The vast majority of IT/software people are going to be resistant to this as they know how to do the job and need support and facilitation, not a condescending head master.

So from the managers point of view, they are resisting and being difficult.

A common and unfortunate mistake, also when done in the context of "I'm more senior, I must be right" there can only be one assumption.

The key here, once again, is the self awareness of what is going on, and what is more important :

Being "right" and in control .... or helping the team to get the job done.

I do make distinction from control and direction, though well functioning teams given a challenge when allowed to will typically self organise and become directive.

Context

Given I'm talking about work, it is a professional environment, there is money changing hands for effort & time, it's not social or family, or personal relationship.

Therefore there is a defined environment, be that an expectation of work or hours spent in a location. Now all good management (or rather team facilitation) is flexible, but to a point.

Allowing someone to be absent for weeks (or even days) and not taking action but to wait and stew until their return and explode is about as far from a constructive or well functioning choice as you can get.

The key here is professional environment. I am not condoning Prima donna behaviour or "the end justifies the means" excuses, though I am advocating that there is mutual respect and acceptance of responsibility, on both sides.

If some one doesn't turn up for work for days in a row, sure you check in on them find out what is going on (it could be an emergency). But you don't simmer in the office "tolerating" their behaviour because they are a technical genius and then explode when they return, you deal with it. It's contractual if nothing else.

Personal

There are two sides to the personal aspect that strike me.

First, is that most of these issues come from ego, of any team member. It  could be "da management" or members of the project team. Personally I don't differentiate or accept that any team issues, are only "the workers fault", there is a shocking amount of managers with challenging behaviours, just as there are workers.

So there can be ego on both sides. Management by responsibility of position are there to be aware of, and mediate this, opposed to taking it personally and attempting to "control" the staff.

Specific behaviours of anger, passive aggressive, negative etc, don't particularly bother me as they are just the symptoms of something else. It's just that individuals behaviour to a given situation. There are whole sites about how to deal with individual behaviours, google will help with that.

Find out what is behind the behaviour, and if it is relevant to the project, or if it's personal to them ........... which brings me on to....

Point two: being that we all have our own personal issues, and the vast majority of the time, for the vast majority of people (in my experience) separate that from work. And to a degree that's good, it's professional.

By way of example, the original poster advocates blaming an employee for experiencing an addiction and firing them. Luckily as someone pointed out, in many places that is illegal. Let alone immoral to me.

Some times we are overwhelmed by the situations in our lives, be that burnout a personal crisis, life in general, etc.

How a company supports it's people is very telling of how it's people are going to support the company I've found. My experiences are more of Europe than North America, though I've seen provisions for HR and employee support on both sides of the water.

I don't personally want to run a company and turn it into a counselling help session all day long, though I do accept there are responsibilities and healthy ways of supporting people. Respect at work is a two way street.

Shouting at people or threatening them for not working weekends consistently, and then firing them the first day of holiday they take is no way to do business.

So my advice is to lay off the condescending approaches of :
  • how do we control them
  • how to deal with people who don't do what you say
  • Nerds are X, and this is how you manipulate them
  • etc
And try and look at the bigger picture, and most importantly yourself before trying to blame, control, understand others.



@JeremyHutchings