Design and User Interaction

I came across this very interesting presentation on design and user interation.

http://www.slideshare.net/tmo/the-web-in-the-world-presentation

Inside Druker’s Brain

A few weeks ago, I read Jeffrey Krames’ book “Inside Drucker’s Brain”. It is a short and simple introduction to management guru Peter Drucker’s thoughts and philosophies on Management. It covers all his important ideas like Leadership & Execution, Strategy, Innovation, Management etc. This is not a comprehensive treatment on Drucker’s teachings, but a quick introduction. Most thoughts are definitely interesting but there were 2 chapters that got me thinking. Here are some ideas that i was very much interested by

Idea 1 : Abandon all but tomorrow

Krames quotes Drucker as follows

“The first step in a growth policy is not to decide where and how to grow. It is to decide what to abandon. In order to grow, a business must have a systematic policy to get rid of the outgrown, the obsolete and the unproductive”.

“increasingly organizations will have to plan abandonment rather than to try to prolong the life of a successful policy, practise or product”

Drucker’s litmus test of abandonment is  to ask the question “if we did not do this already, would we go into it now, knowing what we know? and if the answer is no, the organization has to ask: And what do we do now? it has to do something, no just another study”

Idea 2 : Ouside-in

Krames summarizes Drucker’s eight realities for every manager. Two of them are thought provoking for me. They are
  
Results and resources exist outside the business : Drucker stressed that there are no profits within an organization, only cost centers. Results never depend on anyone within the company but, instead, on customers in the marketplace.

Results are achieved by exploiting opportunities, not solving problems: solving problems can only return an organization to prior status quo.

The paradox of Constraints

When one thinks about the word constraints, it conjures up a fairly negative image on limit on something. In reality, there are many situations where constraints are good and can help a lot. Below are some benefits an organization might gain under constraints

• Constraints encourage creativity : If you have to do more with less then the only way is to be creative. For example, if you have limited budget, and still want to get a big bang for it, you will have to be creative. If a product has limited features, sales/marketing has to get creative in applying it.
• Constraints encourage effectiveness and efficiency : Again, if you have to do more with less, you are forced to be more effective at what you do. Although efficiency seems like the obvious thing, it can lead to ineffectiveness. So first be effective then efficient
• Constraints encourage discipline : It is very easy to splurge when you have no constraints. But having a constraint lets you prioritize and really stick to core values. Fiscal constraints encourage fiscal discipline, resource constraints encourage scope discipline etc.
• Constraints may lead to simplicity : Many a times it is difficualt to solve a problem or design a solution which has many degrees of freedom. Constraining a few of the degrees actually helps solve the problem or simpligy the solution.

Organizations in their early stage of growth/setup are better off being constrained than not because more often than not, it teaches a lot of valuable lessons. So next time you are constrained by something, try to take a positive outlook and figure out a way to exploit the constraint and make use of it.

How to determine the right level of detail for requirements

Karl Wiegers in his book “More About Software Requirements” provides guidelines to determine how much details should requirements capture. Here is a quick summary.

When more detail is needed

• Development will be outsourced
• Project Team members are geographically dispersed
• Testing will be based on requirements
• Accurate estimates are needed
• Requirements traceability is needed

When less detail is appropriate

• Customers are extensively involved
• Developers have considerable domain experience
• Precedents are available
• A package solution will be used

He also puts this in the context of what he calls “Cosmic Truths” about requirements. The ones that I like are

• Requirements development is a discovery and invention process, not a collection process
• Change happens
• Customer involvement is the most critical contributor to software quality
• Even the best requirements document cannot and should not replace human dialogue
• You are never going to have perfect requirements

Read the book for a more comprehensive treatment of the above.

The new hire orientation guide

I have sometimes felt  that my handling on new hires in my team could have been much better.  I feel that no matter what kind of hire, there are some things which are the same.

So I am putting together a blueprint for new hire orientation that I would like to follow for my next new hire.

 

Before the start date

 

1.       On the day, the person has been hired

a.       Work with HR to make sure thyy process the hire correctly

b.      Work with IT or equivalent to make sure that they get the process rolling for the following

                                                               i.      Computer

                                                             ii.      User accounts to key systems including

1.       Network login

2.       Version control system

3.       Defect tracking system

4.       Wiki

                                                            iii.      Licenses for tools

                                                           iv.      Other items like VPN etc.

 

2.       Setup meetings  (during the first week of new hire start) with appropriate folks to give him introduction to the different key aspects of the product, process and organization

 

3.       Also identify a buddy/mentor for the this person who can engage/help/guide him during the first few weeks. Meet with this person and make sure, he knows about it and is prepared

 

4.       Communicate to the team/relevant stake holders about the new hire (within a week of the start date )

a.       Who the person is

b.      A summary of his experience

c.       Any special skills/experience he would bring to the table that is worth noting

 

5.       Follow up with the new hire

 

a.       A week earlier to confirm that everything is going fine and looking forward to his joining

b.      3 days earlier to confirm the start time, who will be meeting him

 

6.       3 days before verify that all the necessary logistics are in place (machine, login ids work etc. )

 

On the day of start

 

1.       The direct manager should be the person receiving him

2.       Give the person an understanding of what would happen during his first day/week/month

3.       Hook up with HR to take care of paperwork

4.       Make sure the person has logged into the computer and has access to all necessary systems ( email, source code )

5.       Pair up with the buddy

6.       Introduce him to the team

7.       At the end of the day, make sure you meet with the person and inquire about  his day was and if anything was left to be desired

8.       Give him a goal to achieve for the first week

 

During the first week of start

 

1.       Make sure he has met with all relevant stakeholders

2.       The most important stakeholder who appreciates this hire ( CTO/CEO …. ) meets with this person and reiterates the value he will bring to the team

3.       Meet with the person  every day for a few minutes to see if things are going well and if he needs any help

4.       Make available key documents/blogs/wiki pages to read that give a more comprehensive understanding of the product, architecture etc.

5.       During first week, the new hire should get a clear picture of

a.       People

                                                               i.      Who the key stakeholders are

                                                             ii.      Who would you need for some common tasks ( HR contact, IT contact etc. )

                                                            iii.      Organizational chart

b.      Process

                                                               i.      SDLC

                                                             ii.      Key team traditions

                                                            iii.      Values and principles of the team/company

c.       Product

                                                               i.      Architecture

                                                             ii.      Key features (demo)

                                                            iii.      Some important customers using it

 

End of first week

 

1.       Get first impressions on team, process and product (this is a great opportunity to get feedback from a fresh pair of eyes )

2.       Review the goal and indentify the next goal ( maybe for a week, 2 weeks or a month)   

3.       Introduce him to the goals of the team, department and company

4.       Reinforce the decision to hire the person

5.       Make sure the managers sets his expectation from the hire and understand the employee’s expectations of the manager

 

During the first month

1.       Meet with him weekly and see if things are going well and if he needs any help

 

End of the first month

1.       Get feedback and suggestions on team, process, product again.

 

This article titled “A manager’s guide to orientation”  is a great read on this topic.

Effective Status Reporting

I have always been challenged by figuring out the right way yo communicate status and over time have tried out various techniques and formats.  Status reports can have various information in it like accomplishments, milestones achieved, issues, risks, next steps, summary,  metrics for quality, cost etc. Any reports that I write now is based on the SMART principles. SMART reports are

• Specific : Be specific and focused on the information you intend to communicate. Do not use generic  language. For ex: instead of saying “Design is almost done” you could say “Overall design completed for all modules except the security framework”. As stated above statements like “50% done” , “fairly good quality” mean nothing. it is very subjective and inaccurate.
• Measured : This communicates how the status item was verified. For example in the previous section, how did you verify that overall design was completed ? You could mention the fact that design reviews were done and no changes recommendaed. That would definitely communicate that the task was indeed completed. Also make sure the information provided is accurate.
• Actionable : After reading a report, the reportee should be able to take actions if necessary. Actions might include communication to the same status to somebody else or to help with issues/challenges.
• Relevant : The information presented should matter to the reader. Operational managers expects more details than an executive. Make sure you write the report with the consumer in mind and what that person is hoping to achieve after reading this report. If the report is distributed to different folks ( operational managers,  executives etc.),  you may want to modify the content or presentation.
• Timely : Reports should be delivered, distributed in a timely manner. It works best when done on a regular/recurring schedule. Try to not to miss it or alter it.

4 other considerations for a status reports are :

• Report should have a format that you do not change : folks get conditioned to look for items of interest
• always have the date of report creation and author
• have an overall title for the report it is
• always highlight anything abnormal/outstanding ( good in green and bad in red or such color scheme )

At the end of the day somebody who reads a report should understand where the project stands, what next and what are the key challenges to achieving the goal.

Also I found this article very informative.

Bakers Dozen

Simon Baker at Energized Work has a set of principles for agile teams. I think this is a great set of principles. My favourite principles are

• Focus on purpose, not process
• Keep things simple
• Working code beats everything
• Let things evolve
• Be effective before efficient

Read the complete list and its details on the original post

Team Traditions & Rituals

Just like family traditions and rituals, team traditions and rituals are an essential part in the success of a team.  Team traditions are beneficial in the following ways

• Give a sense of identity to the team
• Teach team values
• Create a sense of belonging
• Create positive feelings and memories 
• Connect new team members with the old

You can create traditions for almost anything. Some major categories are

• Team milestones like anniversaries, major achivements etc.
• Personal milestones like birthdays etc.
• Company milestones like major sales, company aniiversaries
• Holidays
• Just plain old fun

Here are some guidelines for performing thee rituals and traditions

• Regular participation in the traditions prevents an inclination for teams to lose their emotional bonding.
• Traditions do not have to be expensive, but rather symbolic and practical. Keep in mind it’s value is in bringing the team together
• Follow a reasonable number of rituals. Do not over subscribe
• Evaluate your rituals from time to time and feel free to adapt, stop or start new traditions.
• Have a purpose. And if possible at the beginning of the celebration quickly review the purpose

Barriers to effective listening

For any leader or manager, one of the most important communication skills to master is Listening. Effective listening is a very rarely seen capability. Many many years ago, when I became a manager, I had a tough time listening to people. Over time I realized this as an issue and worked hard to improve my listening skills.  A good and quick introduction to this topic  is in an excellent article by Michael Webb titled Eight Barriers to Effective Listening.

Below is a summary of the eight barriers to effective listening:

• Knowing the Answer
• Trying to be Helpful
• Treating Discussion as Competition
• Trying to Influence or Impress
• Reacting to Red Flag Words
• Believing in Language
• Mixing up the Forest and the Trees
• Over-Splitting or Over-Lumping

The following books were also immensely helpful.

• Listening: The Forgotten Skill: A Self-Teaching Guide
• Are You Really Listening?: Keys to Successful Communication

I have observed that listening is one of the most difficult skills to master, but definitely a worthwhile one. In the coming posts, I will try to summarize the books listed above.

Management Indecision

Many a times I have seen that managers cause a lot of pain in the development time by not making effective decisions in a timely manner. These indecisions cost time and demotivate whole teams.  In my experience I have observed the following as the key manifestations of indecisions

• Analysis Paralysis syndrome : This happens when someone  keeps on analyzing the problems and solutions and never can prioritize the solutions/problems and hence does not make the decisions. This can also happen if there is no clear decision making criteria defined.
• Lack of data syndrome : This happens when someone puts an exhaustive criteria for decision making and is not willing to commit to a decision until all data points are available. More often than not many scenarios involve making decisions with less than ideal data.
• Afraid of making wrong decisions or afraid of committing to an option : This happens when someone does not know what to do and hence is not clear about making the decision, or plain afraid of making wrong decisions. Happens many time with newbies in management.
• Committee decision making : This happens when there are many people involved in making a common decision but cannot agree to the problems or solutions.

There are many times where making a decision quickly (right or wrong) is more beneficial than waiting long to make a right decision. As Maimonides put it “The risk of a wrong decision is preferable to the terror of Indecision”.   This blog also has some interesting points.