Hamstaa!

How do you view and hence refer to the people who buy your software or services? As Customers or Clients?

While it sounds like a simple case of semantics, it is a significant change in how you look upon them and how you treat them.

To explain the difference, consider the following analogy.

We refer to the doctor, lawyer and accountant we use as "My Doctor", "My Lawyer" and "My Accountant" but we never refer to the shopping centre we go to as "My Shopping centre" . It's referred to as "The Shopping Centre".

A customer is someone who you don't build a relationship with. You don't necessarily gain repeat business with. They are someone who can easily switch to a different product (shopping centre)

With the subtle shift to considering them as Clients, you are focussed more on working with them, finding solutions to their problems and gaining their appreciation and repeat business.

Yesterday I had the opportunity to hear Alan Noble, Engineering Director for Google Australia/New Zealand present on how they are tackling Google's expansion. While there were many interesting facts (for example, Google receives 12 resumes every second) and insights (like Google's approach to products, "Build it and see if people use it"), the one that I found interesting is regarding Branding.

We all know the value of and hence focus on building our companies brand. In today's environment, it needs to be dynamic, exciting and have "sizzle", as they say. When it comes to recruitment however, we tend to have a bland, boring, "check list" approach. Alan highlighted the obvious issues with this when trying to recruit highly talented professionals, especially "Generation-Y". On the one hand you represent a dynamic exciting work place, on the other your recruitment message says the opposite.

As Engineering Managers, I see it as part of our job to build "brand awareness" of our engineering team. This can include involvement with universities and the local technical community but it's also important to consider what message we are giving when we advertise for positions. 

At Ephox we have a team of outstanding developers working on the edge of technology. They work hard as a team and have a heap of fun doing it. It's this kind of message I want to get across when building awareness of our technical team, but it is also important to get this across when we advertise for new team members.

During the recent session of my leadership course the presenter (Karl) raised an interesting point regarding the under-recognition of Capability compared to Competence.

If you aren't familiar with this, consider the image on the right. For any Situation, there are known and unknown situations. Similarly there are known and unknown Problems. Our ability to deal with Known Problems in Known Situations is reflected in out Competency. When we are presented with an Unknown Problem in an Unknown Situation, it is our abilities that assist us. This is our Capability.

The problem is that Capability is both hard to define and hard to measure.

Many in industry want be able to put a "tick in the box" when it comes to a persons abilities. This usually results in competencies being essential. Like Karl, I feel Capability is under-valued due to the difficulty in measuring it.

This also fits with my long held belief that in the "People versus Process" equation, People stand out. Sure process ensures replicable results, however when the inevitable problem arises that the process doesn't address, having good people with the autonomy to make decisions will get you through. It is their Capability that delivers in the end.

In the second session of the "Growing Team Leaders" course, Karl Buderus from Success Solutions presented "Leading IT Projects".

Karl started out stating that "Leading Projects" is different to "Managing Projects". Project management involves activities like planning, budgeting, organising, controlling and problem solving while leadership is about vision, alignment of people, motivation and inspiration. So, where management is a Science, leadership is more of an Art and involves enabling, empowering and supporting the team.

One of the key messages I took away from this session is that Leaders helps people find the answers versus telling them. In most cases, team members know the answers, by assisting them to find the answer, you not only grow their abilities, but empower them solve problems without your involvement.

Similar to the previous session, good communication was highlighted as essential, along with negotiations skills. This time, communication with project sponsors was discussed. Identifying how the key people required to make your project succeed want to be communicated, is essential to your success.

The remainder of the course then focussed on things like governance, organisational alignment and management tools.

So when you are working on something involving high innovation, which can result in high risk, good leadership is essential to succeed. Share the vision, excite the team and ensure key stakeholders are involved, clearing the way for your team to innovate and deliver.

I was recently reading a post on InfoQ, "Frequent Retrospectives Accelerate Learning and Improvement".  As it's title suggests, the key messages in the article is about having frequent retrospectives to aid in the learning and improvement process.

When we adopted XP (eXtreme Programming) we undertook to have a retrospective at the beginning of each development iteration, preceding the planning game. With weekly iterations, we have a chance to reflect on the previous weeks pluses and to formulate some changes/improvements (deltas) identified from the week.

In the article the author made the following comment,

In fact, looking back is only half of the retrospective pattern. Reflection is not learning. To bring about learning and improvement, it is necessary to identify areas for improve and explicitly document a brief action plan for which the team becomes accountable.

We regularly come up with a number of delta's and then choose the highest priority ones to be tackled during the next iteration. We even assign someone to "own" the task. So we are on track to learn and improve however what we struggle with is when we have too many delta's to be done in a single iteration.

Currently we review the previous retrospective deltas at the beginning of the retrospective and copy any un-addressed ones to this retrospective's delta list. The problem with this is that the list is getting bigger.

I'm not really sure what the solution to this is yet so if you have an suggestions I'd love to hear them. For now, we'll continue to tackle the most pressing or productive delta's and keep reviewing the previous one.

While writing a post about retrospectives and deltas, in response to an article by Deborah Hartmann on InfoQ (Frequent Retrospectives Accelerate Learning and Improvement), I noticed a disturbing comment mentioning the "traditional blame party". 

Deborah's post referred to and quoted from an article by Rachael Davis entitled "How To: Live and Learn with Retrospectives". The quote from Rachael's article included the following sentence.

Without these in place, conversations are likely to be full of criticism and attributing blame

Rachael's comment, when put into context of her article, is about avoiding a situation resulting in blame, however, while the commentor's remark may have been facetious, it seems "blame" in retrospectives is a reality.

Attributing blame, be it in a retrospective or in the development process seems to me to contradict some important elements of eXtreme Programming. 

The principle of Accepted Responsibility and the practice of Collective Ownership (which comes out of the Shared Code practice) both imply that the team accept and own the decisions collectively. Pointing the finger tends to do nothing but breed resentment and cause people to "switch off" to potential solutions to the problems.

Finally, attributing blame in a critical manner ends up breaking the core value of Respect. 

I think it's an important role for a manager to encourage an environment where people feel "safe" to raise issues in a retrospective without feeling that blame will be attributed.

As I mentioned in my first post one, of the reasons for this blog is to help engineers new to management. 

When I first started in management, I went looking for books that would help me develop the skills necessary to be a good manager. On the "Management Books" page you will find a collection of books I've read so far.

These range from management and leadership in the form of the "One Minute Manager" series, to the "Fish! philosophy", a way to drive productivity while maintaining a sense of fun.

I mentioned the other day that I had recently attended the first session in a course on leadership. While waiting for the session to begin, I chatted to one of the attendees. Like many technical people in management, after many years in development, they are promoted to a management role with little to no training or management experience. As such he was struggling with the balance between managing people and development. 

More importantly, because he had been with the company for a number of years prior to his promotion, he knew the code base intimately. As such, when one of his engineers had something complex to do, he would inevitably do it himself, in case they failed to do it right.

He realized that as a result he had becomes the bottleneck of his team. In addition he is failing to give opportunities to his team to develop skills. 

When I joined Ephox, I had a heap of experience with J2EE but only a limited experience with Swing. What this meant was I focussed on building my management skills, growing the team and putting in place the processes to ensure we provided the best code, without taking anything away from the team.

Once I'd built up some skills in management and put in place the processes to continue to improve the team, I could then focus on regaining the slightly rusty technical skills to be able to play a key part in the architectural design of our products.

When you start on your path in management, don't be afraid to let go some of your development  focus in favor of management skills. Give your team the opportunities that you were given, to show what they can do, and to grow in their abilities.

ACS recently started a new course entitled "Growing Team Leaders" that I feel might compliment my management reading and learning. This post is the first in a series associated with the course.

The first session, "What is a Leader", presented by John Ware of Dale Carnegie Training was on this month. I was pleasantly surprised by the number of skills I was already aware of and am doing as part of my role. There were however a few points that I can continue to work on. One I particularly liked was "Micro manager yourself, macro manage your team". What this essentially means is manage your own time and tasks in detail and provide guidance to your people, trusting them to do their job.

With respect to leadership however, the main point that I took away from the session was that good leaders are focussed on people. This was highlighted by the statement "Managers manage process, leaders lead people". Management is all about managing the processes that achieve results. Leadership however is about vision and hearts & minds.

The bulk of the course then focussed around techniques to balance motivation and accountability within your team and building outstanding communication skills.

So if you really want to lead your team well at all levels, focus on people management along with your other management skills. Understand what motivates your people, give them the opportunities to grow and take them where they might not go themselves.

Like many tech companies, we support our employees blogging, so it was great to see that Suneth has joined the growing number of people at Ephox that blog.

Suneth is the constant in our support team. He is forever looking for ways to improve the experience our clients have when they come to support. His formula for support in his first post, "Life in Ephox" illustrates this dedication.

I look forward to seeing where Suneth takes his blog. I'm sure there will be some interesting insights into providing outstanding support. He is definitely an "important fish in the small pond!"