Left somewhere up and high

If you can’t find the accountable and responsible people defined, you may find people complaining about

– the number of the emails they receive

– repeating same mistakes

– no central location for documents

simply because you are not learning from your mistakes.

Accountable people normally pay the bill of a mistake, and make sure they are not going to pay it twice. If a process is not in place, people get confused, but if they are really nice people, they will try to keep the system going without looking for an accountable.

Responsible people make sure that next time they have a smart way of doing it, at least by not repeating the same mistakes…

No accountable? No bill?
No responsible? No assigned people?

Some people enjoy this as this is an opportunity that they learn a “different task” each time. The environment is so slippy that they can be “x manager” this week, “y manager” next week. Do they know what “x manager” should do/know/implement? No…
Has their task finished? Yes, not the best one, but they managed to get it working [with silly hours of work]

So, because it is working, some people enjoy; the people suffer plays the nice guy…  because they are all nice…
If they want to object/comment/suggest, they are left somewhere up and high …

Interview questions should be presenting your domain!

You need someone, and you had spent enough time on the job spec, to identify the details of the practices/skillset you need. Either those skillset matches what you are doing right doing, or what you want to achieve. In this blog, I will go a bit deep inside to show a more deep insight to the both sides’ feelings.

Matching is a word I use for the technology knowledge and practice knowledge matching.

Knowing X,Y technologies/languages/platforms does not necessarily that person can fit into a set of software development practices, vice versa works true also.
A. If you are a market leader/first implementer technology company
If you want a .NET developer, implementing TDD; and all the interview went theoritical concept of talking, probably you have missed a couple of things during the way

You might chance of getting the right person that could fit in, but you were not aware of it…

Let’s say you are asking the candidate to write a piece of code to calculate 5! and s/he writes it. So was that all about? Writing a recursive function to calculate 5 factorial. This is the first homework/example that an undergraduate/high school level person can answer. And believe it does not tell anything about the candidate [unless the candidate takes it seriously and writes a framework for it.]

It should not be set of questions because some people are selling them, writing books, or Scott Hanselmann listed, actually not someone else’s question, it should presenting your domain, your own challenges!

Please do not ask/expect for output caching as a response to “if a page is getting lots of hits…” Ask types of caching and when to use which …

You have adversited the skillsets your team has, and the practices those you are following [either with best practices/or not].

Markhneedham argues that if you are implementing pair programming, why not you have pair-programmed interview?

I will keep the same argument, and continue:

– If you are/want implementing TDD, why not ask the developer candidate to write TDD tests beforehand the code. If you are insisting on 5! Give three pages of blank papers, and see the talent there!

– If you want to see how experienced the developer is, like how he/she can cover the code,

Ask to write some unit tests, if not all, ask her/him to list the tests s/he would do.

B. If you have one client on a specific industry or you are the enterprise company dealing with only one industry:

If you want to see how experienced on that domain/industry, ask an existing project and see how he/she would think about it. Do not ask 5!, unless you are doing lots of recursive functions, functional programming. Let’s say you are in retail, ask about how a checkout can work, how the delivery address can work best with sessions objects, or product page can benefit from new technologies like silverlight/flash, does s/he has any experience on those domains, and what does s/he thinks…

– For more senior positions, ask about the architecture for your latest project. Which patterns could be used to start a nice discussion to see the depth.

You may not need depth, the people asking questions may not be interested in details and whys, but after a fixed keyword to hear, who will stop listening after they catch that.

And HR can have hours of competency tests similar to GRE/GMAT/Belbin questions on top of that, so without seeing you, they will judge you with you test results…

I tried to tell the points where you should stay away…

Agree to Agree

Thanks to LondonGeekNightsat Thoughtworks yesterday evening, I had the chance to enjoy Pat Kua and Liv Wild, talking about the “conflicts” happening during the projects, and how to solidify, materialise these soft issues.
They have done a fantastic presentation, and obviously good preparation.
The bits I found quite useful are :
– use a structure before starting conversation:
ORID [1.Objective, 2.Reflective, 3.Interpretive, 4.Decisional]
– Importance of how you give/receive feedback and preparation for this.
– Rituals [having something every week where you can talk anything but work, teas, lunches]
– Doing proper/regular Agile Retrorespectives
[technical and personal agile retrorespectives] and a book suggestion
-Using six thinking hats while doing retrorespectives
-Team disruption, changing members
-Being explicit when you are playing the devil’s advocate.
On my side,
The conflict starts when both side feel sentimental about the subject and can’t put emotions beside. Let’s give example of Andy and Betty working in the same team. Any decision required can instantiate a talk between them. The ultimate goal should be sharing their experiences and enlarging their understanding on the subject.
However, human psychology starts with starting the things “they know”, “they believe”, totally living in their comfort zones. It is quite common that people are coming from different backgrounds; and maybe people like playing “devil’s advocate.”
Crucial Conversations Tools for talking when stakes are high” was a useful book in this subject. Leaving emotions aside, being able to communicate, and having an agreement while you are keeping the relationship longer…I have realised that I have blogged about this book before, so I reckon it is the time:

Start with your Hearth:
– State what you really want
– State what you don’t want
– Find alternatives and creative solutions

Analyze your stories:
-Question your feelings and stories
– Don’t confuse stories with facts

Get Back to Facts:

-Separate fact from story by focusing on behaviour
-Spot the story by watching for “hot” words

Watch out for three clever stories:
– Victim [it is not my fault]
– Villian [it is all your fault]
–  Helpless [nothing else I can do]

Use a structure: [STATE]
-Share your facts
-Tell your story
-Ask for others paths
-Talk tentatively
-Encourage testing

In addition to these, obviously there are personality differences, Belbin roles, and colors of people during normal state and in conflict state, which are all subject to another blog, until then take care!

That’s all folks for today, hope you enjoyed!