In the recent economic turmoil many more professionals have found themselves on different paths than what they thought they would experience. For many it is their first time or so long since they have gone through the experience that their pain, confusion and angst is understandably high. Even the most seasoned professional looks at the situation with some degree of frustration and confusion. After all they were doing fairly important work and now suddenly they are out of an organization they have given so much of their efforts to.

I often find myself giving advice to many professionals in these situations from my own personal perspective in that I have gone through it myself several times. Many have found my advice useful so I thought I would share some of my thoughts on the subject:

• Why is a company laying off? Answer - economic reality bites. Let's face it, many companies are not necessarily well prepared for change especially rapid, downward changes. So when they do take actions, it is often more of a reaction than any truly planned action. This is not to say that any organization releases employees lightly. Quite to the contrary they are loathe to do so. However it is not something that they adequately prepare for nor practice until times call for it. Quite simply it is beyond an organization's control on when they lay people off. It just happens.
• So why am I being laid off? Answer - it's nothing personal, it's just business. Most companies view their employees as valuable resources not necessarily as individuals. Even in the most individual-oriented company, everyone has a value that has to be weighed by the company process in terms of being retained or released. For example younger more agile individuals even those who have contributed significantly to a company can find themselves released while others are retained. Why? The company weighs their value to the company. If a person only contributes in a certain way that can be more or less valuable to a company versus others who do more. To be honest there is no real "formula" or "scientific process" being applied. It is matter of perception by decision makers beyond an individuals control.
• Was it something that "I" did to get laid off? Answer - Plain and simply no. In almost all instances of being laid off I can personally recall every "mishap" that might have caused my being released. From personal experience that is the wrong avenue to take. While it is true that one might have made mistakes, if they had been heinous enough to cause a layoff more than likely one would have been released due to disciplinary actions prior to being laid off. One of the biggest wastes of energy is looking at a company and imagining any number of scenarios as to why one was laid off. It ranges from "so-and-so was out to get me", "I should have explained my value more", "I should have done more tasks", etc. I have seen executives of profitable divisions who did outstanding work, engineers with PhDs and patents, and sales personnel who brought large deals to an organization released in the same wave as other professionals who were not as well known. It is never one's fault for being affected by a layoff in such dire economic times. 
• What do I do now? Answer - Simple. Find a new opportunity. Note how I always call it an opportunity and not a job? This is an important distinction. An opportunity is something that interests you whereas a job is something that does not. It is the passion driven by interest that attracts employers. If you are interested in doing something it shows.

One of the major perspectives someone being laid off tends to forget is how their departure among the number of their fellow employees impacts their organization. I am not merely talking about immediate work efforts but rather morale as a whole. How an organization deals with a layoff is not only important to those leaving, but those staying as well. While it is true that many employees will react out of fear of losing their positions, energy that is fear-based lasts only a short while. Employees will become resentful, fearful and stressed resulting in any number of issues to an organization ranging from late projects, to health-related absences, to a poisoning of the company culture - just to name a few. Essentially when a lay off occurs, it erodes the goodwill between employee and employer. How well the transition is managed determines how much erosion occurs and how soon the healing process begins. I often advise those who are let go that their worries are over and their course of action is clear. Those that remain behind are the ones that need sympathy and support as their turmoil will take a long time to settle down.

One of the greatest lessons being laid off teaches a professional is how to be entrepreneurial - to find opportunities, to network, to grow, to find business own their own, to face repeated rejection with optimism and enthusiasm, and to ultimately believe in themselves. As companies continue to lower their costs by letting employees go, they are in my opinion inadvertantly creating a newer, better workfoce that will have several traits:

• More self-reliant and self-motivated.
• More focused on doing what they themselves are capable of doing for others both inside and outside of an organization.
• More confidant in their capabilities and values in delivering quality, affordable and effective solutions to customers.
• More capable of making significant decisions that affect their lives with greater clarity and determination than before.
• More unwilling to "settle" for something as opposed to going out and "making" it happen.

These are not bad traits to have in any employee. It is just that employers will find a more mindful, independent workforce than they previously thought. This workforce will not only have the talent but the the motivation to focus on what interests them. For any professional going through a transition focus on the future, not the past. Trust me, it helps.

However another thing to keep in mind is the power of perspective. Often times what technical folks consider "not a very big thing" is actually quite innovative. Generally speaking I find that less experienced technical professionals tend to overlook or downplay their achievements. A couple of cases that I have seen that illustrate my point:

• In an all Java shop, an engineer creates outside of Java a framework that allows for dynamic provisioning of services complete with versioning, tracking, dashboards, automation, and self-service in an automated fashion that is cross platform and fast. Initially the engineer did not think much of their solution, however their solution so impressed with the framework and the architectural vision behind that approach such that it became a key component for the company's offering.
• In a large enterprise that favored purchasing vendor solutions, a group of young and eager college students created a Java-based server that handled hundreds of millions of transactions a day with larger ordering and provisioning systems with minimal cost in terms of hardware. Their solution included custom tools such as telnet clients and queue maintenance screens, workflow, customizable parameters via xml, prioritization and scheduling, as well as failover and recovery. They even honed their deliverable to include some great screens, reports, dashboards, and performance monitors. Not bad for a group of 2-3 programmers from college. Their entire server was very scalable capable of handling significant growth starting from a mere 10M requests a week and growing in 3yrs to handling over 200M a day. All of it ran on only 4 quad-core Intel-based Linux servers. To the several business and internal technology leaders their product was quite inspirational. Yet to these programmers, they thought of their solution in a more humble manner often times referring to their achievement as "no big thing". 

In both cases the technical professionals noticed problems, determined how to tackle them, implemented them, had tremendous impacts to their organizations, and were ultimately very humble about their results.

I am certain many organizations have at least several individuals that fit this category. Often times such achievements are recognized not by the individuals who actually delivered them, but rather the business that relies on them.

What I tend to find is that such a trait of humility is both a blessing and curse. Such talented individuals tend to find themselves in challenging roles but not necessarily fulfilling ones. After all even the most talented individual wants the freedom to grow and expand, which may or may not be alignment with their current organization. However it is during transitions that such talent finds challenges since they are not always presenting their accomplishments in the best light. Sometimes they appear potentially too arrogant, other times too timid.

In the long run, such talented individuals will always find their way not because they necessarily the value or not in their innovative ideas, rather that from their perspective being innovative in their solutions is the only way they operate.

There are two major dimensions to any maintenance: the items to be maintained and the timing of the maintenance. A PeopleSoft system has quite a few things to consider:

• Logs. There are many logs ranging from the web server to the application server. All of these logs need to be spooled off or cleaned from running production instances periodically based on how quickly they grow. Simple scripts can handle the work quite well.
• Dumps. These happen. They are very useful at times to analyze problems but when the issues have been resolved these need to be moved from production as quickly as possible to save space. If dumps are not frequent nor of significant size, then they may not be as pressing.
• Temporary files. This happens from time to time as well. It is important to remove any temporary files from reports, XML, errors, or whatever other process is creating them as soon as they are not needed. Also be judicious about the use. They do take up space and processing power that could be better spent in the system.
• Domains. Every so often domains need to be brought down and recycled. While it is true a PeopleSoft application can go on quite a while without bringing them down, the domains will actually degrade over time due to use. Ideally the production architecture has several domains in place with capacity to spare. Cycling through domains at planned intervals is the best way to continue business operations while refreshing domain resources.
• Database. Whether it be Oracle, DB2 or MS Sql Server the databases need their own maintenance as well. Usually adjusting the various parameters for growth and defragmentation. Since PeopleSoft stores both meta-data and application data in the same database just in different structures, the database tends to be the most important area of maintenance. It is also the most frustrating for many companies since the PeopleSoft schema is not necessarily managed by the native database in the sense of being what could be considered compliant. For example the lack of many things such as procedures, triggers, referential integrity, etc. tend to drive DBAs insane. This is because the nature of a PeopleSoft system is to have the application servers perform all that logic. Collaborative efforts between PeopleSoft experts and the DBAs is essential to a healthy production instance.

The timing of maintenance will have been made available via the architecture such as multiple domains and clustered databases coupled with targeting low activity periods within the system. In the end caution around production applications will drive when and how maintenance activities need to occur.

Finding the right amount of maintenance will be based on the amount of activity and growth the system bears over time. High degrees of instability are the most common signs that maintenance activities need to be reviewed in terms of comprehensiveness and timing which can lead to unwanted service issues or even outages. So plan, implement, review and repeat as often as you can. A well maintained production system can last years with no downtime.

The interesting thing is that most professionals try very hard to be what they think employers want. In truth they all ready are: they are valuable individuals. The challenge is making prospective employers understand their value enough to want to hire them. 

I have found the most effective manner to tackle this is looking at your own unique value. For example, you may have a title of "Software Engineer" or "Chief Technology Officer". There are certainly quite a few thousand at least in the various industries. Does this mean that every person with these titles are the same? Of course not. They are commonly understood titles to provide a general basis of communication. However, the individuals within these positions are far from common. They are in fact professionals who individuality, experience, creativity, and other traits make them invaluable to their organizations. Therein lies the key that most professionals miss... being invaluable.

Now this concept is always something elusive. People believe for any number of reasons that they are not invaluable. Some common examples are being laid off from their employer, being within a common level within an industry, or merely being humble. While all true, it is also true that these individuals happened to be generating value for their organizations in their own way. Circumstances may have impacted them in some way but overall they are still valuable and have a lot to offer.

It is the professional's individuality that is a big part of them being valuable to any employer. This is what is many times forgotten or never realized. By being who you are and by changing who you are over time, allows someone to be very valuable to others in a variety of ways. 

I often advise other professionals seeking new employment opportunities to take the time to really understand what they want to tackle next, why, write that all down, and then highlight key elements from their career that demonstrates their value towards their next endeavor. I also let them know it is something fundamental and takes some time to work out especially for professionals doing it for the first time.

Once a professional has these basic and powerful elements they can start to craft branding statements, value statements, cover letters, resumes, elevator speeches, and any manner of communications necessary to present themselves in the best light possible. Especially in today's hyper-competitive marketplace, being yourself and standing out is absolutely essential in being able to prosper.

In complex system interactions there are many places for useful information to hide. One of these places are the little gems known as log files. Pretty much every application and system under the sun produces them and they are often captured for analysis. Some of the more advanced shops have their own tools again either by their own development or acquired that parses the logs and presents information. Others are a little less sophisticated. However log files are often an excellent way to look at events at various layers of an system to determine whether or not there are problems.

Often times log files are hard to read. This is especially true for those produced by applications from vendors whose formats and data vary wildly from one to another. A PeopleSoft application is no exception. There are several different logs produced that one has to consider for a variety of situations:

• Web Log. This is the typical web server whether it be WebSphere, etc. It holds the core information for all web interactions which include both standard users and automated web interactions.
• PeopleSoft Web Log. These are maintained on the PeopleSoft side usually kept in the webserv directory. It contains the stderr, the stdout and also the application gateway logs which contain web activity for a PeopleSoft application.
• PeopleSoft middleware logs. These are a collection of logs used to describe what is occurring within the layers of the PeopleSoft application. They include:
  • Application Server Logs - Used to describe what is occurring within the application servers.
  • Tuxedo Logs - Used to describe what the transaction servers are actually doing from a resource and request level.
  • Dump Files - Usually only occurring when something strange has happened, these files can appear usually in the application server logs for extreme system events.
  • REN (Realtime Event Notification) Server Logs - Similar to Application server logs but for REN events.
  • Process Scheduler Logs - A small collection of logs for each part of the process scheduler that describes what is happening at each level.
• PeopleSoft Application Data. These are the tables and constructs such as the messaging constructs (PSAPMSG*) or the process scheduler (PSPRCS*) that have useful information that may or may not be inside the previously mentioned logs.

The first thing to notice is how many logs there are and then secondly how disperse they are. They are spread across an entire infrastructure. Another point to consider is that often times some hint of a problem can be determined within these logs, but only if you set the logging levels to something meaningful. I am not talking about high levels of detail, but even summary information has it's limits. Factoring in constant and perpetual logging in a running production environment is typically seen as a "No-No" in terms of performance. However, logging takes little overhead if set properly and background processes that periodically "clean and archive" the data for processing can minimize the disk worries. Typically the overhead for a PeopleSoft environment is usually anywhere from 5-10%. This has to be weighed in terms of the time it takes to identify a production issue.

In my experience being proactive means having a good logging level, a means of capturing all that information, analyzing it, and presenting it such that you have in addition to all of your existing tools a holistic and historical view of what your application is doing relative to the business transactions.

Some issues such as web-based transactions using the integration gateway happen to be one kind of problem that requires traversing several different tiers. The reason is simple: all the information about the layers of the integrations are not stored in the same place. Each layer has a different story to tell and can be of great help in determining problems. Based on this I used the following process to look at integration issues:

• Is the integration synchronous or asynchronous? They have different structures in the database in terms of what to look for.
  
  • Synchronous are typically not logged unless one sets that up in the PeopleSoft web screens (called PIA). Setting these to at least a "Log Header" will store the information in the database in the PSIBLOGHDR and PSPUBCON. Setting it to "Log Detail" is a lot more overhead and typically unnecessary unless you want to look at the contents of a message itself.
  • Asynchronous are usually logged. They are stored in different structures such as the PSAPMSGSUBCON.
  • Errors for either if the PeopleSoft developers have put in error handling will appear in the PSAPMSGPUBERR or PSAPMSGSUBERR. Overall errors will be placed in the PSIBLOGHDR.
• Next the actual logs may contain information. Usually integration transactions run in their own application servers separate from standard transactions. Why? Because putting them both in a single domain usually overloads the application servers in all but the smallest of shops. Even if they are in the same domain, the logs will still contain additional information about their events.
• Tuxedo will be able to present information on the messaging as well in terms of requests processed, requests currently waiting and the workload being processed. This is informative in the historical context against business transactions to see if there are any load issues occurring.
• The gateway itself can produce information about transactions. There may be errors connecting to a service, there may be formatting issues, there may be even Java memory issues for a particular request. These can be seen in the PSIGW for any PeopleSoft integrations.
• The web server. In the case that there is insufficient memory resources for Java or other issues, these will appear in these logs.

Most of the time getting the basics is pretty easy if you have all the access, scripts, SQL, and information readily at hand. Typically this is not the case. I find that many shops have different people covering different areas, each area can have different requirements, these requirements may or may not have the appropriate level of data needed to make a determination. All of this is time. If in a dev or QA function, time may be flexible. In production outage situations time is not on your side.

Having spent a lot of time helping companies solve production issues for their mission-critical applications the processes are not really all that different from one application to the next. Typically the challenge is finding the correlated data, piecing it together quickly and efficiently, and having the proper automated tools in place that can quickly answer a question. If people are being used for all issues, the length of time to find a problem is very high and usually not proactive enough to address production problems. Many implementations fail to properly consider the amount of on-going development used to meet the on-going SLA commitments for their projects.

Good luck on your own implementations!

• Growth. This is based on three dimensions: past usage, predicted usage, and actual usage. All three of these dimensions need to be collected, retained and actually compared on a regular basis. Preferably in an automated fashion. This is usually left to operations to "deal with" however the analysis is very important and goes beyond operational staff to analysts who should actually be mapping their predictions to actuals, especially with regard to the accuracy of forecasts. If you are wildly off base then that is just as important as being right on target.

• Stability. This is a real simple thing often times well misunderstood. This is the adherence to an SLA. However there are several important elements that should always be considered:
  
  • All user applications have an operational SLA of 100% availability. The application should never, ever, ever, ever go down in terms of it's operational aspect to users. Most companies I have seen have this set to 100% or 99.9999%.
  • Individual component SLAs can be whatever is appropriate so long as they do not negatively impact the end user SLA.
  • Tie SLA performance to compensation for the various groups: development, operations, planning, etc. Leaving it as a high priority to one group and not the others will create infighting due to the appearance of lackadaisical attitudes.

• Innovation. Relational databases are one of the most well understood, stable, reliable and hence common store of data in most companies. However often times common data management practices are well behind the times in actually keeping up to date with innovative techniques that can help the business. Some of the more common examples I have implemented:
  • Search engines. This goes well beyond the common datamarts, rather this is the ability to mine the data for relevant information based on search techniques. Imagine being able to access the legacy data as easily as running a Google-like key word search. Most companies think of this as a "nice to have". In truth using the approach even with operational information such as dumps, logs and error handling is useful. It can speed up the operational response to issues, help users find key data without overly taxing the main data store, and it can even help address data aging and replication without compromising the core data set. Search engines can also help compress data requirements so that they become more manageable. Case in point: relationally speaking regional order data for a large telco  for 30 days to their national customers was about 2-4 terabytes a month with many reports often times taking a full 48 hrs to retrieve. Converting several dimensions of the data or raw portions of it to the open source Lucene search engines reduced the actual informational requirements down to about 1TB with access times in the milliseconds.
  • Data replication and abstraction via NoSQL. This idea is common but usually with relational engines. One proposal for any legacy company is to take a segment of their data and move it to NoSQL solutions such as Hadoop. This allows for better recoverability and accessibility of data in an inexpensive and agile manner, while still leveraging existing data stores for current business needs.
  • Enablement of web services (especially REST). Often times there are so many demands on the data store that at some point the argument always arrives at ownership vs. consumption. In truth it is a little less about ownership and a whole lot about maintainability. Many shops are ill-equipped to handle several dozen clusters of sharded data let alone the growing demands for what could be hundreds if not thousands of requests. The best answer is to allow a little sharding via SQL or NoSQL solutions, but with a mindset towards web services especially with RESTful interfaces. The idea should come as no surprise given the fact that one of the most scalable eco-systems happens to be Twitter. By providing basic interfaces on a REST approach, thousands of applications are able to be constructed. Throw in some good corporate governance, there is little reason data infrastructure should not be similarly positioned to provide the maximum flexibility for internal groups trying to provide key applications to the business. 

• Data retention. The most commonly adopted mechanism for databases is what I call data retention. All groups ask how long they should keep "the data". The answer is always something akin to like 5years or so. In truth data should never really be discarded. There is little reason to given the litany of alternatives to store the data and the usefulness of keeping this data to better position the business. Take for example Google. They do not really get rid of data per se, as opposed to putting the most "hot" data on top and with the other "cold" data eventually getting buried. This enables them to create very rich analytics for new products, services and to make better overall strategic decisions. Every piece of data being "thrown away" is something being lost to the business. 

• Speed of access. Data should be made available quickly and reliably. Often times this boils down to creating really fast access to the data. This is where things get ugly because in almost all cases, what data adminstrators want is less access while consumers want more. Web services can help mitigate the argument however replying quickly to data requests is absolutely paramount. Heck if people can get queries from FaceBook, Google or Twitter in milliseconds over the internet, intranet queries should not be taking minutes. Creating a rich, useful and scalable access approach lies in the data administrators domain and should be regarded with a much larger view than simply SQL or reporting queries.

Often times in many companies I see "new" initiatives lock horns with the "old" data wranglers. There is never a need to have these confrontations. Both can work really well together to deliver new and exciting options to any business. Hopefully just looking at the world's growing demand for immediate information and how internet companies are handling that issue will help foster better solutions for companies.

Yet as these products roll out to consumers and businesses, I am utterly amazed at how current companies are viewing the situation. Many legacy companies are still wrestling with change from 20 years ago and are facing daunting internal challenges just to keep fractions of their infrastructure and businesses somewhat modernized. For example, even after 3 years of market introduction iPhones, while very prevalent for many in their workforce, are still shunned in many corporate environments. Even with the possibilities of locking down the devices and creating applications specifically for their own needs, even the largest companies with billions in revenue do not take advantage of such new technologies to improve themselves.

Being unable to see the value in products that their consumers want creates a lot of stress on existing business models. Take as a classic example of industries that have not adapted well - music and movies. These companies have had decades of experience and insight into their customers yet missed the biggest marketplace via digital technology. Making CD like quality digital products is absolutely fantastic for consumers; they are light, portable, easily transferable between different products that consumers have (i.e. smartphones, portable players, entertainment centers, and computers), and can be saved from the ravages of time far more elegantly than tape or disc. However rather than adapt, these industries became protective and antagonistic towards their customers. In my opinion, these industries have acted liked internal IT departments within companies - always saying "No!" to their users requests rather than attempting to come up with solutions. Is it no wonder that Apple's iTunes has done so well? Apple's product is pretty reliable, easily accessible, and while not the best for every circumstance, it meets several needs of consumers in many categories. Even as incomplete as Apple's offering is, it has enough consumer interest to be a big revenue stream.

Not all industries fare so poorly. One of the best examples I love to point out is the automotive industry. It has been around for quite a while, innovating at business, operations, technology and business models consistently well. Most consumers today have an array of choices such as new automatic steering, rear-view cameras, GPS, entertainment, computerized lighting, and even heads-up displays. None of this innovation comes for free nor did it come overnight. However they did arrive into vehicles at price ranges that consumers would accept.

In my experience, the difference between the two is a mindset within the company culture expressed through every individual. One fundamentally accepts that consumers and times change and that to hold onto customers they have to adapt. The other mindset sees the fact that their customers have little choice to go anywhere else for their service/product, and that their service/product cannot be replaced. The sheer arrogance of the secondary viewpoint is what makes them blind not only to changes in their markets but also to any possibility of change at all.

The difference in how they operate and tackle problems is also very clear. The ones that know they have to change actually create a culture of looking out for their customers, creating products and services that make the customers happy by delivering excellent value with great reliability/quality at an affordable price. The other side has lost sight of delivering customer value because they have lost sight of what customers actually consider valuable.

One of the most visible and perhaps demonstrative examples of how new products can have huge implications for current companies is the Apple iPhone. The incumbent handset manufacturers, mobile operating system companies, mobile application companies, and telecoms had been in place for decades with little reason to change. After all according to their own viewpoints, customers loved what they produced. They literally did not see the frustration and resentment of their customers in terms of less-than-stellar usage experience with their products. Then relatively overnight, Apple introduces their iPhone. Most of the industry even if they did not always voice it, behind the scenes considered Apple's offering as a non-threat. I heard such comments as "iPhone will be a fad", or "iPhone is a joke", or "iPhone delivers nothing that current products deliver" not just in one company but from many companies at industry gatherings. Everyone now knows that the iPhone became the biggest game changer to those companies by becoming the "gold" standard for smartphones everywhere. The end result is that the existing companies scrambled to come up with new products, services, and capacity to meet their customer demands. It still remains to be seen how well they will do.

It is clear that the innovative companies are not idly standing by to let the incumbents catch up. Apple for example in the iPad purchased a company that produced the chips for their new product. Why? While no official word from Apple has come out, and more than likely never will, there is much speculation that the current chips being produced for the mobile market are simply not up to Apple standards of what they want to deliver to customers.

Another example is that of Google's plans to build a high-speed network. This is obviously something that the company feels that they need to do not only for themselves but their customers. There are undoubtedly other reasons for them doing so but their actions is what even the Federal government would like to see more of from others in the US.

Clearly change is on the wind. In my opinion the dire economic times are the most obvious reason for the push to innovate. Creating new products and services that consumers will spend their income on is what companies need. And all innovative companies know that when something is not working, you try something else that may, and you do it quickly. That imperative has never been more true and more needed than now. It is an imperative that is not only changing companies, but also the prospects for the employees within companies. If professionals want to stay valuable, they had better prove that they are valuable to the business of the future, not the present.

It takes a bit of getting used to. Basically I think it has a lot of promise. So here's what I like about it:

• Integrates with Gmail. Something familiar and works well with existing conversations.
• Works really fast and gets a lot of people.
• There seems to be no growth limit.
• Let's me "mute" threads of conversation. This is better than say "unfollowing" someone, rather it let's me "unfollow" a particular discussion that I may not want to see.
• Pretty intuitive overall.

Now the bad things about Buzz:

• It is very browser intensive. Running it in FireFox is bad. Heck even running it in Chrome is bad. Chrome is obviously better, but keep it up for any length of time and it bogs down. I am sure there are browser settings to improve the experience but really need to find those.
• In terms of sharing I was sort of hoping to be able to share Gmail items via Buzz. The only way to share is via a link and that is severely limiting especially if what you want to link does not yet have it's own URL.
• There has got to be better organizational methods than what is currently presented. The filtering in Gmail works for Buzz but it is not really all that great. Being able to create better lists based on filters, better notifications, priorities, etc. Are all what I am used to seeing and having via Seemic, etc. Gmail is good but needs a lot more work.
• Closed system. Unlike Twitter, FriendFeed or even FaceBook, Buzz appears to be a very closed platform. There are very few ways for developers to create better experiences or even different clients to handle the traffic than what is being presented. This may change over time but this is a big hurdle that needs to be overcome. Case in point, many followers of mine in Twitter are not available in Buzz. Same goes for FaceBook. As a result, Buzz while interesting is not anywhere near as useful.

Overall I like the direction of Buzz because it is tackling what I have been looking for from others - integrated social communication. Having email, chat, and social networks woven into a single experience for the user is absolutely the right direction. However, it does pose some significant usage challenges.

Quite frankly I have far greater faith in say Twitter or even FaceBook to create a better user experience in social mechanisms than Google. Why? Google is certainly possessed of brilliant people but they are fundamentally engineers that seem to have long lost touch with the average person about how to design certain aspects. Remember back in 2009 when UI experts like Bowman left Google? One of the criticisms happened to be how Google engineering practices tend to overrule basic human interactions. In my opinion so long as Google is content to "study" people and not really "understand" them enough to help them, Buzz is most likely to remain an interesting tool but necessarily the next big leap forward in social communication. Too bad. I was sort of hoping for more.

In my opinion Apple has introduced more an evolutionary device based on a more revolutionary and very quiet success - the Apple iPod Touch. As a recent item illustrates the iPod Touch has been doing fairly well. Almost as well as the Apple iPhone. Some have commented that it is a market of one product with no real competitors nor going after any existing device currently in the market. Interestingly, in spite of many questions about it the iPod Touch has quite the following.

It is not too much of a stretch of the imagination to see how the iPad concept could be a success based on the iPod touch. There are some questionable items missing such as a camera among many other items which could be more of a negative than a positive. However it is entirely possible that the same consumers that liked the iPod Touch may in fact really like the iPad as well. Heck even some iPhone users may move over. 

It is also possible that maybe the iPad is just a big Kindle competitor and Apple wants a slice of that pie as well.

Yet one could see a lot of really good potential in a device that has a good display, long battery life, somewhat portable, in settings such as hospitals, schools, manufacturing, chemicals, etc. If it had a camera, throw in augmented reality applications to overlay real time information for such things as a patient condition or damaged shipping box and the iPad could in a generation or two be far more useful than anything Apple has made to date.

In the end I see a lot of potential in the iPad even if I personally think there are a lot of shortcomings in the current generation that leave me wanting. It is the promise of the future that makes this device more appealing. After all, the iPhone had taken 2 generations to get what was called "an absolute necessity" of cut-and-paste. That was 2 years of consumers supposedly "not accepting" the iPhone because of that and many other flaws. However iPhone did quite well. I expect the iPad will too.

When interviewing candidates for positions I look at it as an investment. Firstly I am spending a lot of time and consequently money in the process, and the person will be with the organization for a long period of time, potentially up to 5 years if the match is good, longer if the match is great.

Personally and professionally I find very little value in what I call "memorization" questions for technical professionals. Most of the management I meet ask for a basic set of questions for vetting purposes. However I see these questions more ineffective and wasteful than anything else. I care less for someone who has memorized every buzzword or specific syntax for languages or commands; this is what things like Unix man pages and Google searches are for. Just because someone is good at memorizing things does not make them a good fit for creating solutions.

When interviewing I look for the following:

• Are they leaders? Senior positions are not followers but rather leaders in their own right. So I ask questions about initiative taking, risk management, and investments.
• Can they think outside of the box? In almost all of my situations the initiatives being undertaken have not really been done before. As a result, there is no "best practice" solution that someone can look up and solve it. The senior positions have to have the ability to see this situation and move ahead, figuring things out along the way. This includes new approaches, new viewpoints, new technical implementations, etc. It can be even a new way to do something on older approaches.
• Do they ask for permission rather than for forgiveness? In many cases what I am looking for are the necessary leaders and initiative takers that will sometimes bend rules. Not important ones mind you such as regulatory compliance, but rather set-in-stone mind sets that need to be challenged. I want the person to be independent so the questions along this line are what I am looking for.
• Can they play well with others? Regardless of how stellar an individual is, they are still working on a team. From a 2 person startup to 300,000 person fortune 50 company the needs are the same. This is very important to determine since prima donnas often derail efforts rather than build them.
• Do they have what I call "I am a hammer, everything is a nail" perspective? In my experience specialists are needed for certain specific tasks but leaders need to be demonstratively better cutting across boundaries than specialists. Especially in technical professional ranks, I often come across people that are very good at a certain set of technologies: all Java, all C, all Python, all systems, all Oracle, etc. The questions that I ask determine whether or not they can cross multiple specialities and using generalist thinking quickly understand, grasp and apply what they have learned to the problems at hand.

Often times memorizers make very poor fits for effectively solving problems. They wait for requirements as opposed to going out at getting them, they are geniuses with certains sets of tools, but horrible when learning new ones, etc. In any organization that is looking to grow, they need to see and build towards the future, not what is front of them for the moment.

This process has worked out very well. I have had professionals who had done very poorly at the memorization and at my insistence have been brought back for another session. In many instances, these individuals that I have helped to hire turned into excellent and capable contributors and leaders, delivering outstanding values to the organizations that hired them.