jamesladdcode.com

This post is about the bad Customer Service I received  from Dell’s online chat facility and how I think putting Customer Service Operators in front of Customers without the proper tools is tantamount to sending troops into battle without weapons. Your going to loose the battle for a happy Customer, and your staff are the casualties.

About 10 years ago I had a Motorola mobile and I wanted to know if I could use it in the United States. I rang the local provider I was with to ask. The Customer Service representative said they could not answer my question and that I should try Motorola directly and could I hold. I then heard a flicking noise like the pages of a telephone directory were being turned. This was 10 years ago. I asked the operator what she was doing and she responded “I’m looking up Motorola’s number for you, I can’t put you through but I can give you their number.”. What helpful service. I was a customer of the provider for quite some time after that and I was very happy with the service.

Today I read an article on on the new Dell XPS 13 Developer Edition which comes with Linux installed. I went to Dell Australia and searched for it. No Luck, so I went to the Dell US site thinking that maybe it has been released in the States and down under might be lagging behind. Nope, no Dell XPS 13 Developer Edition on the site. I used the search box top right. Why would Dell announce a product was available and yet not list it on the site. Frustrating.

I was just about to leave the site when a window popped up  and asked me if I would like to talk to a Customer Service Operator and I clicked Yes. What follows is a transcript of that discussion, which Dell emailed to me when I closed the chat window. I have removed the names of the operators since this post isn’t about them, it is about the bad Customer Service I received because of the tools provided to them. Needless to say I didn’t buy a Dell today and I’m not sure if I ever will again. Although I probably should not even have considered them after the Battery in the Dell Latitude I have failed to charge just 3 months after getting it. Another story.

What I want to happen is for the search to return the product I’m looking for.  Secondly, when dealing with Customer Service I want the first person I deal with to be able to handle my query. When being handed from one person to another I expect not to have to repeat my story, especially when it is in electronic form for all to see.

Dell, please don’t send your troops to the front line without proper support, its abusing them and loosing you Customers. Please don’t tell me your systems are not compatible or don’t talk as that is just an excuse. I write software and I could make them talk.

When Customer service systems don’t align or sync to provide Service then you are simply automating a processes to upset customers quickly. Do you really want that?

I received an email from a friend regarding my interactions with him, and the positive effect they have had on him and his interactions with others. It appears that courtesy is catching.

Here is the email:

“We haven’t had a chance to chat for a while but the things you write have had an impact on my interactions with others. One thing I noticed is you take the time for a pleasantries like “nice to chat with you”. I always try to be polite with others when I interact with them but never quite as far as showing appreciation just for the opportunity to interact. Lately I’ve been adding a few of these kinds of pleasantries when interacting with others. Even with people I have good working relationships with, I’m finding they appreciate the acknowledgement and I enjoy giving it. So it is a bonus for everyone.

So thanks for leading me by example. “

When a Team starts on a piece of work they implicitly know the goal is to get the job done as efficiently as possible. There are probably other goals that are not verbalised and therefore not implicitly in the minds of the Team and this is a big problem, big enough to destroy the Team and significantly hamper getting the job done. A shared understanding of the goals of the Team helps focus decisions as each decision can be related to how it helps accomplish the goals. Without established goals decisions making can break down into a battle of wills which is extremely costly in multiple ways (this is covered in the book ‘Getting to Yes’ which I blogged about here. The goals of the Team are not just the Company goals they are also Team members personal goals like ‘I want to learn technology X’ or ‘I think the design should be Y’. These personal goals are rarely explicit bubbling along just below the surface with a building current that can derail a project.

Explicit and honest goals can help a Team focus and make decisions quickly and in a manner that feels more cohesive and transparent rather than driven by the loudest person, biggest personality or <insert sterotype here>. What follows is a proposed technique for making the goals of the Team explicit and prioritised to enable a Team to move forward efficiently with a transparent mechanism for making decisions quickly, reducing personal conflict and focusing the Team on getting the job done. After all, getting the job done is always the number one goal.

A Goal Pyramid is a hierarchy of ten (10) Goals starting with one at the top, two on the next row, three on the next and so on to form a Pyramid. It is suggested that the Goal Pyramid be kept to ten (10) goals. The first and highest priority goal is the core Business goal, “to get the job done as efficiently as possible”. If this isn’t the Goal at your Company then you should change the first and highest priority goal to that. This top goal is not a negotiable goal like the rest that make up the pyramid. To find and fill out the other goals you need the team to list all the goals they can think of and then prioritize them into the top nine (9). These top nine (9) goals will make up the rest of the pyramid from left to right, top to bottom starting on row two. The goals on row two have a higher importance than those on row three etc. A pyramid is used rather than a list or another shape as it allows the number one (1) goal to be clear while allowing the remaining goals to share in importance on each row, and have priority over those on lower rows.

The list of goals to prioritize should be succinct and clear to each team member so they know what they will be voting for to form their top nine (9). Each goal should have a title, a description and a “because when we don’t …” section which lists the impact/remifications of not focusing on the goal back to the number one (1) goal. For example, “Goal: Clean Code. Description: We should follow the principles set out in the book Clean Code. Because: When we don’t the code base becomes harder to work with slowing our ability to ‘<number 1 goal here>’”. In arranging your pyramid graphically I suggest putting the ‘Goal:’ in the Pyramid and having a legend under it to elaborate on the ‘Goal:’. However, nothing should stop you from having all this information in each pyramid segment if you wish.

A difficulty and thing to watch out for in forming the pyramid is getting the team members to be open, honest and transparent in why the goal matters. For example, a goal of “Keep Simple” looks fine until you dig deeper and draw out the fear behind this goal which might be a fear of meeting the deadline or a fear of a design that is not fully understood. ie: I want to keep the design simple because I don’t understand your proposed design. This particular example draws out a different issue, that of information sharing / knowledge transfer to understand a design more. This is an intended side effect of forming the Goal Pyramid. Encourage your team to think hard about the goals and to be as honest and fearless in presenting them to be voted upon. Wanting to use a particular tool or approach is a fine goal and it needs to be related back to the number one goal, made known and prioritised with the team. Letting the who team in on a goal means we can all work together towards multiple goals. A win-win situation.

• • Goal: Simple Goal statement
  • Description: A longer more informative description of the goal.
  • Because:  A set of reasons for the goal.

Once your Goal Pyramid is formed you can refer to it in situations where a decision is required, helping focus the discussions on the goals and to break deadlocks which can occur when Team members are in a battle of wills. A systematic analysis of how a path of action effects reaching the number one Team Goal will usually be resolved quicker than battle of wills and assist in preserving ego. For example, lets say a Team member wants to use a new and exciting piece of technology and a goal in the pyramid is “Goal: No risk. Description: Don’t take unnecessary risks. Because: When we take risks where a tried and proven path exists we jeopardize our ability to ‘<number 1 goal here>’, we can say no in a non-personal and professional manner by pointing out this ‘agreed’ team goal. Note, we don’t have to say no, we can say yes in a way that meets our goals. For example, in the same case above we might ask the team member for a plan or strategy for mitigating the risks, or offer our own like “why don’t you make a branch and work on this after hours or weekends to prove it out, taking the risk away from the team?”.

I have not yet tried a Goal Pyramid, and I plan to do so as soon as I can. I formulated it because I see a use for it in solving problems I have experienced in my career. One thing I have learnt in many years is that there are rarely if any technical problems that hamper a team delivering, rather people problems have been the root cause. I hope to use a Goal Pyramid as a tool to facilitate getting through some of these people challenges. Should you make or use a Goal Pyramid then please let me know as I would like to provide feedback here on success or failure of this approach. I will do the same.

Edit: This link was emailed to me and I think it is relevant to this post: http://blog.8thlight.com/brian-pratt/2011/10/25/simplicity-of-teamwork.html

Monday mornings at work there is a buzz about the weekend, especially the outcome of sporting events. Someone is usually strutting around on a high because their team won, or ribbing someone because their team lost. This social interaction is what PlayUp have captured in their flag ship application PlayUp Live, along with live scores, fixtures and more. You should click this link now and check it out.

The journey over the last six months to get the iOS version out (support for other mobile platforms is coming) has been quite a challenge and this post is about those challenges and key take-outs you wont want to miss if you are developing an iOS app that connects to a back end. PlayUp is really exciting and it will grow to be as big as a Twitter or a Facebook, so Im expecting a few more challenges and growing pains and it will be worth it. While this isn’t a job advertisement feel free to contact me if you think this sort of challenge is for you (james dot ladd at iplayup.com).

These are my personal top #5 take-outs from working on the project

#1 Small Team

The number one #1 learning from working on the project is to keep the team small, with two people on the UI and two people the backend integration with the server. The server side is not factored into this count as this is quite variable, however the typical code base size for an iPhone app suggests 4 - 6 developers maximum.

#2 Shared Vision

The team should share a consistent vision of the product they are building. Multiple competing visions or changes in the vision can derail the project significantly. There is a reasonably common held belief that a key person leaving a project can kill it, and this is even more so if that person is the vision holder. A vision holder who is strongly focused and driven to reach that vision with good communication skills is a must.

#3 One Application

The back end of an iPhone application is as important as the front-end, and involving both teams in understanding the requirements of the other is essential. Both parts are crucial to the overall success of the product and directly effect the schedule and outcomes. A shared design and understanding of the architecture is key.

#4 Fast Feedback

The cycle time on building a feature and showing the relevant stakeholders effects the schedule and this loop should be as small as humanly possible. Getting the app onto the stakeholders device is nice and in some cases essential but it takes longer. Getting the stakeholders to be ok with a ‘first-draft’ that isn’t pixel perfect is another way to reduce cycle time to get feedback quickly, so is not writing tests for this ‘first-draft’. However, there are some cases where writing tests in the ‘first-draft’ will allow you to make changes faster later on. You know your app and will have to decide on your own balance.

#5 Libraries

Depending on your application you may need to use off the shelf libraries, and these libraries need to be thoroughly evaluated. Take the time to do this because in the heat of battle is probably not the best time to find out it was not the most robust choice.

I was inspired by this post by Kent Beck to write a fan letter to Redline Smalltalk, written in the voice of a deliriously satisfied user. This is an excellent way of articulating a vision.

Dear Redline Smalltalk,

I have been using Redline Smalltalk at work and in personal projects for a while now and I just had to let you know what a joy it is to use and how productive I am with it.

My work situation means I have to work on the Java Virtual Machine and I have been looking at alternatives to Java so I could be as productive as possible and stay away from those little Java annoyances and hurdles that slow me down. Having a background in Smalltalk I jumped at the chance to put your Redline Smalltalk through its paces and I have to say I couldn’t tell the difference between your Smalltalk and the others, in fact I think yours was a little faster.

At home I like to use IntelliJ and your plug-in support in the IDE is brilliant, the mix of old style Smalltalk-80 browser, refactoring and file based support is smooth and complete and just what I needed, especially the source level debugging and profiling which I could not live without.  At work we use Eclipse and I can’t tell the difference between the plug-ins so now I’m getting a few other developers to try it, and I think I made some converts.

One developer at work, Steve, keeps banging on about how Ruby On Rails is this and how Ruby On Rails is that, how we need rspec, gem, rake, and how awesome it is to script things and try stuff out with irb. You should have seen his jaw drop when I showed him how I can do all that in Redline and how quickly I could create, test and deploy my Seaside Web App and then push changes to different environments with a simple commit, even while they were running. You really did think of everything to make things complete and integrated with Smalltalk everywhere.

I wondered what you could add in the next release and I just can’t think of anything but if I do, Ill be sure to let you know.

Thanks for a wonderful product that has really changed the way I work and made it fun again.

Regards,

John Q. Geek.

We coders are probably all familiar with code smells that possibly indicate deeper problems in our code, and the need to refactor when they are found, but do you see interpersonal smells and the need to refactor yourself?

I often reflect on the interactions I have with team members and think about how those interactions went, mostly when I feel the outcome is negative or not what I expected. To me, these situations are interpersonal smells that possibly indicate a deeper problem in my interactions. Some interpersonal smells may be serious and some not, but I analyse each just like code to determine what if anything should be refactored in myself.

Just like code smells there is often a subjective judgement as to whether an interpersonal smell is really a smell or not and sometimes you need to call on others to help hold a mirror to your behaviour so you can make an informed decision. This is hard for a number of reasons, not least of which is having some good colleagues you can call on that will be honest and frank, as well as having the courage to carry out this reflection. Having others help you reflect is very important since a real interpersonal smell is like body odour, something that offends but the offended have a really hard time telling you that you have it. So how can you find out what you don’t know about yourself?

Depending on your circumstances you can just ask people you trust or you can use a more formal approach like that described in the Johari Window. The Johari Window is also referred to as a ‘disclosure/feedback model of self awareness’, and by some people an ‘information processing tool’. The Johari Window actually represents information - feelings, experience, views, attitudes, skills, intentions, motivation, etc - within or about a person - in relation to their group, from four perspectives. I have not used this model myself, but I know from research that it is apparently the thing to use. It can be used with groups as well. In my case I didn’t want to get that formal.

I asked some people I have worked with over the last five (5) years to give me a list of strengths and weaknesses so I can reflect on them and refactor my interpersonal smells. This is a hard and daunting task and one helper said “it really is ridiculously brave.” I suggest you also ask for strengths since you can read a weakness then a strength and use this to keep things positive and in perspective.

Here is a list of some of my strengths, as viewed by those helping me:

• Innovative and creative –> “an ideas man”
• Highly focused and results driven
• Always striving for a better outcome
• Technologically ‘hip’
• Protective of his team
• Values and encourages team input
• Highly congruent behaviour - Acts consistently with stated values
• Constantly learning and encourages team learning
• Customer and User focused
• Constantly identifying new ideas/opportunities that can exploit your technical skills/knowledge.

I’m not going to give the list of weaknesses as they are smells I am working on and hopefully going away by the time you read this. I am really glad to say that there were no surprises which means my process of reflection is working! Reflection on myself to identify interpersonal smells is important to me and my career. I encourage you to do it as well, and although it can be confronting the results are worth it. Let the refactoring begin.

I will be presenting at the next Melbourne Patterns Group on LISP. It will be a quick and simple introduction to the language and why I think you should use it.

There will be two special guests to support my presentation !!

The date and time is September 3rd at 6:30pm and the address can be found at the web site linked above.

I hope to see you there.

I am passionate about every aspect of design, and not just software or user interfaces, but other areas too. Architecture, Industrial Design, Clothing and many other aspects are of interest to me. This is why I read the book “Sketching User Experiences, getting the design right and the right design.” by Bill Buxton.

The book is inspirational and educational as well as long and with small print. It makes you think about the role of design the the importance of taking the time up-front to do designs. It also takes you through many practical approaches to designing for different mediums, including the User Interface. I practice Agile XP software development and I think there is still a need and a place for design, but I wont discuss that now. If design and the process of designing is important to you, then please get this book.

There are some quotes from the book which I just have to share:

In reference to spending time on Design -

”

Let me end this section by addressing a comment that usually comes up at this stage:

This is all well and good, and in an ideal word this might be fine. But in the real world, we have to meet deadlines and work under limited budgets. We simply don’t have the time or money to add this kind of process. Shooting for the ideal is just not realistic. ‘Good enough’ is all we have time for.

My standard response to such comments nearly always takes the form of the following two counter-questions:

How is it that we can never afford to do proper planning and design, yet we always seem to be able to afford to pay the cost of products being late as well as the cost of fixing all of the bugs that inevitably result from inadequate design, planning, and testing?

How can this be when the cost of design and planning is nothing compared to the cost of being late to market or having a defective product?

”

Sketching User Experiences goes on to show how Design as a profession is as rich as math or medicine, and I totally agree. Here is another nice quote from the book to drive this point home:

“Being able to add up your grocery bill does not make you a mathematician. Likewise, decorating your home does not make you a designer.”

Design is everywhere, but not all design is good and not everyone can design although they can play a part in the process of design. The Design Files is a nice blog about the design in different products and industries. The content and imagery may move you, and that’s by design.

Good written and oral communication is much harder than writing software, at least for me it is. I learned a good lesson recently about writing in a confrontational and non-confrontational way. I hope this post helps you.

The building where I live has had some problems with lax security resulting in damage and theft and so I wrote a letter to the Body Corporate asking for more attention to security. I sent the email to a friend to proof before sending it onto the Body Corporate manager.

My friend responded saying that my “tone” was confrontational but I didn’t see why, all I did was state my case something like this:

Dear Manager,

I would like to meet and discuss the recent security problems with the apartment block.
Please tell me a time that we can meet?

Regards, James

So what is confrontational about this I wondered and I asked my friend to explain. He said that using words like “I” and “me” make the dialog direct and this directness can be confronting depending on the individual receiving the message. He suggested that I make the message indirect and therefore less confrontational. This is what I wrote:

Dear Manager,

Could we meet to discuss the recent security problems with the apartment block.
Please suggest a time we can meet?

Regards, James

Personally I would not have a problem with the first version if it were sent to me, it is clear and factual. However, I do want my communication to be effective and confrontation is not effective. From now on I will be trying to look for and adapt my writing to remove direct speech and incorporate more collaborative words like “we” and “us”.

This is probably not the best or most thorough explanation on direct and indirect speech, so if you see a better one elsewhere then please send me a link.

Aegeon (the best company I have worked at in my 23 years of work) are hiring !

I thought long and hard about putting this in my blog but the enjoyment I get from working in such a great atmosphere of empowerment, trust, learning and teaching have swayed me. We also have a great laugh or two. It wouldn’t be right for me to keep all this to myself; would it?

Aegeon do in house product development, in-house and on-site consulting, mostly in the Web 2.0 space. We are passionate about our culture, learning to improve our craft and to teach others. We are also active in our development communities and support user groups and open source.

We mostly use (but are not limited to) Java, Spring, Spring MVC, Hibernate, Groovy and Ajax toolkits. We practice Agile XP, Test Driven Development and use Continuous Integration tools. We focus on delivery and we routinely deliver solutions we are proud of.

Management at Aegeon rocks !

So if your interested in knowing more then contact me directly at Aegeon:  james dot ladd at aegeon dot com dot au