Tuesday, November 23, 2010
Enterprise Architecture: What Color is your Hat?
I am neither a WhiteHat nor BlackHat. I am of the new breed known as a GreenHat who focuses on innovative ideas and off-the-wall creativity...
The GreenHat provides an opportunity to look for new answers to the question under discussion. Questions come up all the time where there seems to be only two or three options. A GreenHat loves to expand the possibilities by looking for other ideas.
A GreenHat believes there is always another option you haven't thought of and that maybe the decision can be deferred or made unnecessary by some other action affording the opportunity to think deeper about it.
The BlackHats are known for exploring negative consequences and the worst things that could possibly happen, while the WhiteHats are the polar opposite and stand for altruism. Of course, we got RedHat which is all about what you think in your heart and goes with gut instinct. This of course drives the notion of being open. We also have BlueHats which are into MetaThinking and tend to be from companies such as IBM that push Process over People...
| | View blog reactionsThe GreenHat provides an opportunity to look for new answers to the question under discussion. Questions come up all the time where there seems to be only two or three options. A GreenHat loves to expand the possibilities by looking for other ideas.
A GreenHat believes there is always another option you haven't thought of and that maybe the decision can be deferred or made unnecessary by some other action affording the opportunity to think deeper about it.
The BlackHats are known for exploring negative consequences and the worst things that could possibly happen, while the WhiteHats are the polar opposite and stand for altruism. Of course, we got RedHat which is all about what you think in your heart and goes with gut instinct. This of course drives the notion of being open. We also have BlueHats which are into MetaThinking and tend to be from companies such as IBM that push Process over People...
Monday, November 22, 2010
Enterprise Architecture: Stop Outsourcing, Start Open Sourcing...
In 2003, at the industry's first enterprise architecture conference, I stood on stage proclaiming that enterprises should avoid outsourcing and instead concentrate on open sourcing. Let me share some rationale as to how this benefits the enterprise...
In the United States, there are hundreds of Property and Casualty insurance companies, all who are pursuing outsourcing redundant work to destinations such as India, Sri Lanka and Trinidad. Enterprises using this model, have gotten limited savings by taking advantage of rate arbitrage (difference in salaries of workers) but otherwise haven't unlocked sustainable savings.
Within the insurance ecosystem, every single insurance carrier has at least one policy administration system. These systems cost a lot of money to purchase and maintain, yet provide zero competitive advantage. Since much of the insurance industry is regulated, many carriers are paying hundreds if not thousands of people in an outsourcing context to do the same work across companies in order to comply with regulatory compliance.
The possibility in eliminating waste by figuring out ways that the work could be done one time and shared across the industry still continues to be unexplored. What if carriers made their non-competitive systems open source such that they could retain US jobs and share across company boundaries over outsourcing redundant work?
As the United States unwinds from a fiscal crisis and bailing out the insurance industry, with the largest bailout being AIG, did the federal government explore all possibilities in unlocking value?
There are many challenges that would need to be overcome. I can envision the challenge of enterprises suffering from the lack of having a software vendor spoonfeeding them information and instead requiring them to step up and understand for themselves as the first impediment. We can also count on the fact that many industry analyst firms either are incapable of covering this type of activity and would not align with magic quadrant thinking.
I can also see the challenge of executives not understanding that competitive advantage in this scenario as CIO would need to revisit thinking around championing functionality that favors their business over functionality that benefits the entire ecosystem equally, but does that mean we should leave money on the table...
| | View blog reactionsIn the United States, there are hundreds of Property and Casualty insurance companies, all who are pursuing outsourcing redundant work to destinations such as India, Sri Lanka and Trinidad. Enterprises using this model, have gotten limited savings by taking advantage of rate arbitrage (difference in salaries of workers) but otherwise haven't unlocked sustainable savings.
Within the insurance ecosystem, every single insurance carrier has at least one policy administration system. These systems cost a lot of money to purchase and maintain, yet provide zero competitive advantage. Since much of the insurance industry is regulated, many carriers are paying hundreds if not thousands of people in an outsourcing context to do the same work across companies in order to comply with regulatory compliance.
The possibility in eliminating waste by figuring out ways that the work could be done one time and shared across the industry still continues to be unexplored. What if carriers made their non-competitive systems open source such that they could retain US jobs and share across company boundaries over outsourcing redundant work?
As the United States unwinds from a fiscal crisis and bailing out the insurance industry, with the largest bailout being AIG, did the federal government explore all possibilities in unlocking value?
There are many challenges that would need to be overcome. I can envision the challenge of enterprises suffering from the lack of having a software vendor spoonfeeding them information and instead requiring them to step up and understand for themselves as the first impediment. We can also count on the fact that many industry analyst firms either are incapable of covering this type of activity and would not align with magic quadrant thinking.
I can also see the challenge of executives not understanding that competitive advantage in this scenario as CIO would need to revisit thinking around championing functionality that favors their business over functionality that benefits the entire ecosystem equally, but does that mean we should leave money on the table...
Friday, November 19, 2010
Should your CIO champion Telecommuting...
Collaboration is important, but fiscal responsibility is more important...
The vast majority of CIOs are leaving money on the table. They already know how to achieve productive IT workforces in an offsite manner. Isn't it ironic that you can outsource thousands of jobs to another country but won't trust a local coworker to work from home?
As an Agilist, I believe that the best architectures are built via face-to-face conversations, but even I also acknowledge that collaboration isn't something required every single day in a face-to-face manner. Has anyone ever thought about cultures where executives hide behind the excuse of collaboration and calculated the cost of interruption? The ability for anyone to start a conversation randomly with anyone else at any time is both empowering and self-destructive. Does anyone in their right mind not believe that the potential for productivity can increase if you remove interruptions?
Telecommuting isn't happening on a larger scale for one and only one reason. Let's face the reality as it almost always boils down to a lack of trust! No process, methodology, HR policy and so on will address the root cause. This is a leadership challenge that every organization faces regardless of telecommuting or not.
Has anyone ever considered how much real estate costs on a per-employee basis? Consider the scenario of a thousand person IT shop where people have to work a variety of shifts. You aren't just paying for real estate for IT personnel, but also need to account for additional real estate tied up in parking lots, the cost of security guards and even subsidies provided to feed these people in the cafeteria. If you happen to be located in a metro-area such as Boston, New York, Chicago, etc, you may be paying even more for parking and even putting your employees at risk. Think about the potential and the liability for a woman walking from their place of employment at night to a remote parking lot simply because she wanted to do a good job at work late?
Working from home is not for everyone. There are people who prefer to come to the office because they like the face-to-face interaction with their colleagues and find it easier to communicate and work with others personally rather than virtually. Working from home takes a certain amount of discipline, to stay on schedule. Yes, many employees who work from home, may satisfy the urge to do housework, shopping for Black Friday or watch TV but this shouldn't really matter. If I am an onsite employee, my mind may be thinking about shopping anyway and isn't it better to also people to remove this type of distraction vs letting it linger?
Corporations need to rethink the traditional models of hiring employees. An employee assessment and signed agreements might play a role. The 80-20 rule would certainly be a major factor (20% of the people participating would cause problems for the 80% by abusing their privileges). These 20% are the same ones who continue as problem children even without telecommuting.
| | View blog reactionsThe vast majority of CIOs are leaving money on the table. They already know how to achieve productive IT workforces in an offsite manner. Isn't it ironic that you can outsource thousands of jobs to another country but won't trust a local coworker to work from home?
As an Agilist, I believe that the best architectures are built via face-to-face conversations, but even I also acknowledge that collaboration isn't something required every single day in a face-to-face manner. Has anyone ever thought about cultures where executives hide behind the excuse of collaboration and calculated the cost of interruption? The ability for anyone to start a conversation randomly with anyone else at any time is both empowering and self-destructive. Does anyone in their right mind not believe that the potential for productivity can increase if you remove interruptions?
Telecommuting isn't happening on a larger scale for one and only one reason. Let's face the reality as it almost always boils down to a lack of trust! No process, methodology, HR policy and so on will address the root cause. This is a leadership challenge that every organization faces regardless of telecommuting or not.
Has anyone ever considered how much real estate costs on a per-employee basis? Consider the scenario of a thousand person IT shop where people have to work a variety of shifts. You aren't just paying for real estate for IT personnel, but also need to account for additional real estate tied up in parking lots, the cost of security guards and even subsidies provided to feed these people in the cafeteria. If you happen to be located in a metro-area such as Boston, New York, Chicago, etc, you may be paying even more for parking and even putting your employees at risk. Think about the potential and the liability for a woman walking from their place of employment at night to a remote parking lot simply because she wanted to do a good job at work late?
Working from home is not for everyone. There are people who prefer to come to the office because they like the face-to-face interaction with their colleagues and find it easier to communicate and work with others personally rather than virtually. Working from home takes a certain amount of discipline, to stay on schedule. Yes, many employees who work from home, may satisfy the urge to do housework, shopping for Black Friday or watch TV but this shouldn't really matter. If I am an onsite employee, my mind may be thinking about shopping anyway and isn't it better to also people to remove this type of distraction vs letting it linger?
Corporations need to rethink the traditional models of hiring employees. An employee assessment and signed agreements might play a role. The 80-20 rule would certainly be a major factor (20% of the people participating would cause problems for the 80% by abusing their privileges). These 20% are the same ones who continue as problem children even without telecommuting.
Tuesday, November 16, 2010
Enterprise Architecture: Why your leadership eschews real innovation
If you take a can of yellow paint and throw it at your CIO, followed by a liberal dosing of feathers doesn't result in innovation but does result in CIO feature differentiation...
Let's agree that genuine innovation is risky. I have observed that businesses often don't like "powerful" ideas because they are too risky from a business perspective. If done wrong, they can be very problematic. They also make recruiting more difficult because the ability to use and debug the powerful technique may be beyond what a manager or colleagues can test and interview for. They are sort of like the financial derivatives of software design: you can make a lot of money off them, but when things go wrong with them they really go wrong.
Businesses usually don't like that kind of risk, especially larger ones. Smaller businesses sometimes take such risks because they are willing to take a gamble to get a jump on the competition. But, larger institutions don't have the digestive system for such because managers are more often chewed out for what goes wrong stronger than they are rewarded for what goes well.
I have observed that businesses which avoid "powerful" ideas often lose competitive advantage to those which effectively leverage such ideas to improve productivity, sales, or product quality. Indeed, when things go wrong, they really go wrong, but when they go right, they really go right.
| | View blog reactionsLet's agree that genuine innovation is risky. I have observed that businesses often don't like "powerful" ideas because they are too risky from a business perspective. If done wrong, they can be very problematic. They also make recruiting more difficult because the ability to use and debug the powerful technique may be beyond what a manager or colleagues can test and interview for. They are sort of like the financial derivatives of software design: you can make a lot of money off them, but when things go wrong with them they really go wrong.
Businesses usually don't like that kind of risk, especially larger ones. Smaller businesses sometimes take such risks because they are willing to take a gamble to get a jump on the competition. But, larger institutions don't have the digestive system for such because managers are more often chewed out for what goes wrong stronger than they are rewarded for what goes well.
I have observed that businesses which avoid "powerful" ideas often lose competitive advantage to those which effectively leverage such ideas to improve productivity, sales, or product quality. Indeed, when things go wrong, they really go wrong, but when they go right, they really go right.
Monday, November 15, 2010
Documentation cannot compile, run or do useful work...
There are documents that aid developers in understanding the problem domain that are created by architects and business analysts and then there is documentation that developers create that are mandated by the lifecycle. Care to guess which one is backtested as having the most value...
Imagine firing up Notepad and writing a few hundred thousand lines of code in it so that managers can argue over your punctuation style and practice the fine art of word tweaking, only to months or years later try to compile and run it. What do you think the outcome will be?
Documentation is a sort of error-ridden prototype whose errors and glories are equally mysterious. Have you ever asked one of those PMP-certified Project Managers why they are passionate about documentation yet when forced to tell the truth would acknowledge that documentation is largely an unscoped effort? There is no clear indication of "done-ness." The result is the effort is largely driven by an end date and the number of bodies thrown at it.
Many people complain about the lack of documentation but never acknowledge that even if documentation existed, it would more than likely not be useful. Can we agree that good documentation requires thinking about people rather than computers, something anathema to most IT developers and architects. The vast majority of developers or IT employees at large are introverts by nature, so what do you think is the outcome of having them write documentation for others to consume?
Sometimes, the process weenies periodically move away from traditional waterfall thinking and embrace being Agile and iterative, but constrain the possibilities to documentation alone. Let's agree that if you make documentation a team sport and you do so upfront, that the majority of the team at design time doesn't understand the problem space well enough to communicate anything, as you are (by definition) still exploring it.
Consider the below scenarios and ask yourself which one would you prefer:
I am of the belief that documentation should explain decisions taken and not taken, Why an approach, architecture or algorithm was selected and what else was considered and rejected. Bet the developer in most shops wouldn't have documented this since he/she may not even have visibility into the choices made along the way. So, when you are asking for documentation, what are you really asking for...
| | View blog reactionsImagine firing up Notepad and writing a few hundred thousand lines of code in it so that managers can argue over your punctuation style and practice the fine art of word tweaking, only to months or years later try to compile and run it. What do you think the outcome will be?
Documentation is a sort of error-ridden prototype whose errors and glories are equally mysterious. Have you ever asked one of those PMP-certified Project Managers why they are passionate about documentation yet when forced to tell the truth would acknowledge that documentation is largely an unscoped effort? There is no clear indication of "done-ness." The result is the effort is largely driven by an end date and the number of bodies thrown at it.
Many people complain about the lack of documentation but never acknowledge that even if documentation existed, it would more than likely not be useful. Can we agree that good documentation requires thinking about people rather than computers, something anathema to most IT developers and architects. The vast majority of developers or IT employees at large are introverts by nature, so what do you think is the outcome of having them write documentation for others to consume?
Sometimes, the process weenies periodically move away from traditional waterfall thinking and embrace being Agile and iterative, but constrain the possibilities to documentation alone. Let's agree that if you make documentation a team sport and you do so upfront, that the majority of the team at design time doesn't understand the problem space well enough to communicate anything, as you are (by definition) still exploring it.
Consider the below scenarios and ask yourself which one would you prefer:
- A developer writes a great program. He finishes it completely and eliminates all known defects. However, he does not write any user documentation or documentation for other developers that follow him. He did however write self-documenting code.
- A developer writes a horrific application. She does not finish it and it barely works. She however thoroughly documents her approach, her assumptions and the code she already has, dead-ends and rat holes she's run into and the user requirements as to how they related to the chosen design
I am of the belief that documentation should explain decisions taken and not taken, Why an approach, architecture or algorithm was selected and what else was considered and rejected. Bet the developer in most shops wouldn't have documented this since he/she may not even have visibility into the choices made along the way. So, when you are asking for documentation, what are you really asking for...
Sunday, November 14, 2010
A Developers Perspective on IT Project Management
Have you read the parable of the idiot flowers? Today, let's explore the relationship between IT developers and others IT roles...
Once upon a time, in a land far, far away there was a developer and a business customer where IT and the business were aligned. The developer and the business customer worked hand in hand to develop high quality working software. Iterations were frequent, quality was high and process was minimal.
One day, the developer was asked a strange question in which he didn't know how to answer. He knew he need some help from his peers but they didn't know the answer. The one day, out of the blue a person appeared wearing a cape. He was known as the Architect. The developer asked the architect for insight and the architect provided the answers with ease. The developer became delighted and wanted to work with him going forward.
The developer and architect were happy, they did lunch together but yet something still was missing. The developer wanted to spend more time writing higher quality code and figured it would be good if he could get some assistance in writing documentation, taking meeting minutes and being able to concentrate on things he enjoyed. Then out of the sky appeared a business analyst who came to his rescue and quality improved.
The developer, the architect and the business analyst all became happy friends and had a synergistic relationship. The three of them combined were able to do the work of five developers working solely and the business customer became even more delighted. The team wanted to improve and realized that they were close to perfection, but still wanted to get better.
The developer asked himself, is it a good practice for me to quality assurance my own code and concluded that testing before handing over to the business customer could further increase the delight of his business customer and the quality assurance engineer was born.
IT was at its peak, business aligned, delivering high quality working software in a cost effective manner. The team was whole and satisfied. Then one day, a strange person appeared on the scene carrying a checklist and a clipboard. Then team inquired as to who on the team requested this individual but no one did.
The project manager immediately started to implement requirements on the team that had absolutely nothing to do with delivery of software and instead changed the team's focus to process. Going forward, every time the developer talked with the architect, they were required to document their conversation. Over time, the team stopped talking to each other.
The project manager then introduced a methodology that was supposed to aid the developer in estimating how long something would take but over time, the estimation process started to take longer than the process of writing code and morale took a turn for the worse.
The project manager also required weekly meetings which caused everyone to wait till the meeting to discuss issues instead of talking with the frequency observed in the past. Not to be outdone, the project manager declared themselves emperor of all things IT and made the business customer talk to no one else.
Anyone care to guess why IT suffers from cost overruns, lack of business alignment or stifled innovation?
| | View blog reactionsOnce upon a time, in a land far, far away there was a developer and a business customer where IT and the business were aligned. The developer and the business customer worked hand in hand to develop high quality working software. Iterations were frequent, quality was high and process was minimal.
One day, the developer was asked a strange question in which he didn't know how to answer. He knew he need some help from his peers but they didn't know the answer. The one day, out of the blue a person appeared wearing a cape. He was known as the Architect. The developer asked the architect for insight and the architect provided the answers with ease. The developer became delighted and wanted to work with him going forward.
The developer and architect were happy, they did lunch together but yet something still was missing. The developer wanted to spend more time writing higher quality code and figured it would be good if he could get some assistance in writing documentation, taking meeting minutes and being able to concentrate on things he enjoyed. Then out of the sky appeared a business analyst who came to his rescue and quality improved.
The developer, the architect and the business analyst all became happy friends and had a synergistic relationship. The three of them combined were able to do the work of five developers working solely and the business customer became even more delighted. The team wanted to improve and realized that they were close to perfection, but still wanted to get better.
The developer asked himself, is it a good practice for me to quality assurance my own code and concluded that testing before handing over to the business customer could further increase the delight of his business customer and the quality assurance engineer was born.
IT was at its peak, business aligned, delivering high quality working software in a cost effective manner. The team was whole and satisfied. Then one day, a strange person appeared on the scene carrying a checklist and a clipboard. Then team inquired as to who on the team requested this individual but no one did.
The project manager immediately started to implement requirements on the team that had absolutely nothing to do with delivery of software and instead changed the team's focus to process. Going forward, every time the developer talked with the architect, they were required to document their conversation. Over time, the team stopped talking to each other.
The project manager then introduced a methodology that was supposed to aid the developer in estimating how long something would take but over time, the estimation process started to take longer than the process of writing code and morale took a turn for the worse.
The project manager also required weekly meetings which caused everyone to wait till the meeting to discuss issues instead of talking with the frequency observed in the past. Not to be outdone, the project manager declared themselves emperor of all things IT and made the business customer talk to no one else.
Anyone care to guess why IT suffers from cost overruns, lack of business alignment or stifled innovation?
Monday, November 08, 2010
Alarm Bell Phrases for IT Interviews
Many of my friends are currently exploring opportunities with other employers. Figured I would share a few alarm bell phrases that when heard should cause their spidey senses to tingle...
Be careful of when you post to a position that mentions new technologies but yet the interviewer is keenly interested in your background and spends a lot of time on legacy technologies. While it is important for a company to have legacy skills to transition from current state to future state, sometimes current state is future state.
If you hear phrases such as "we have a flat organizational structure" or "we don't have titles around here" it is probably a predictor of one of two things. The first, is that no one really knows who is responsible for anything or they will expect you to do things that aren't described in the job description. Be on the lookout for tasks that are below your job grade.
Job descriptions almost always seem to have phrases such as "This position requires a highly motivated self-starter who has an excellent track record of accomplishments". You can translate this into "you should have zero expectation of any training now or in the future" or "we need a loner cowboy who cuts corners and who doesn't have the wrong accomplishments on their track record".
Of course the best alarm bell phrase has to be "we have to move fast" which means that you aren't going to spend time sharpening the saw. This reminds me of Abraham Lincoln's famous quote: If I had eight hours to chop down a tree, I'd spend six sharpening my axe.
The absolute best alarm bell phrase has to be: "On this project, failure is not an option". You should say to yourself, it must be a certainty then...
| | View blog reactionsBe careful of when you post to a position that mentions new technologies but yet the interviewer is keenly interested in your background and spends a lot of time on legacy technologies. While it is important for a company to have legacy skills to transition from current state to future state, sometimes current state is future state.
If you hear phrases such as "we have a flat organizational structure" or "we don't have titles around here" it is probably a predictor of one of two things. The first, is that no one really knows who is responsible for anything or they will expect you to do things that aren't described in the job description. Be on the lookout for tasks that are below your job grade.
Job descriptions almost always seem to have phrases such as "This position requires a highly motivated self-starter who has an excellent track record of accomplishments". You can translate this into "you should have zero expectation of any training now or in the future" or "we need a loner cowboy who cuts corners and who doesn't have the wrong accomplishments on their track record".
Of course the best alarm bell phrase has to be "we have to move fast" which means that you aren't going to spend time sharpening the saw. This reminds me of Abraham Lincoln's famous quote: If I had eight hours to chop down a tree, I'd spend six sharpening my axe.
The absolute best alarm bell phrase has to be: "On this project, failure is not an option". You should say to yourself, it must be a certainty then...
Sunday, November 07, 2010
Why do those with integrity fail in interviewing...
On several occasions, people have pinged me soliciting advice for an interview with "fill in the blank" consulting firm and have gotten overconfident in thinking that actual knowledge/experience/skills is what makes them perfect for the role. In order to emphasis the challenges faced by good people, I have written a skit...
Anyway, IT people are very specialized--it's hard to do another job, especially when you're a geek - so we're a temp work force: millionaires if you have lived between 1996 and 2008, unemployed afterwards! What about having a world strike and stopping all the systems to show who is the master of the world?! [It's a joke!!]
In Connecticut, if you want to find a job, you probably need to deal with recruitment agencies. The cliche about people who work in an agency is that they don't know anything about technology - they just think they do!
Here is an example of communication failure:
* Recruiter: You're not suitable for that role because you don't know X, Y, Z (Database X, Software Y, etc ...)
* Candidate: I have 12 years of exp with IT: 7 years of professional experience and 5 years in University. I have learned many tools in my career and it should not be a problem. I have a strong potential and I am a high motivated individual. I am a quick learner and you think too much short term, give me an interview and your client will judge.
* Recruiter: You are not suitable because you don't know X, Y, Z
* Candidate: I have 5 years with databases, including 6 months with B; I have also used B for 1 year at university. I am a quick learner. I know very well database theory (SQL, stored procedures, all the acronyms the recruiter don't understand). Ask me any technical question instead of telling me I don't know!
* Recruiter: You are not suitable because you don't know X, Y, Z
* Candidate: I have used 5 years with OS Z at university, therefore I should be able to use it. Skills on a CV are not the only things about a person. Two people with the same profile may be very different. Why don't you ask about my personality and my objectives ?
* Recruiter: Ah ah ah ah (laughter). You are not suitable because you don't know X, Y, Z. YOU ARE NOT SUITABLE (with a very nice voice which means : you're a piece of shit)
* Candidate: Screw you!
Many candidates believe that recruiters should focus on your potential and what you can do, not what you don't know! They don't care finding you a job and they don't care finding the best person for clients since even the client themselves may not know exactly what they need. The challenge for candidates is to simply be pleasant.
Sadly, the world of IT causes people who know their shit to act like they know their shit. Recruiters are looking forward to meeting a quota and tend to focus more on the human aspects of technology than anything related to competency. We all know that companies once they make a commitment tend to have a difficult time correcting mistakes they made and will simply stick with it. We also know that even when you make it past the recruiter, other interviewees are probably squeezed for time and have more interesting things to do than to figure out if you are competent or not.
Let's face it, when the status quo is that IT can't align with the business, the vast majority of projects are either over budget and/or late, this proves that competencies aren't that important in the grand scheme of things.
In terms of the skit above, the candidate made the fatal mistake of only focusing on skills and didn't think to mention process. After all, look at how methodologies are sold. Haven't you yet figured out that the vast majority of people still think that process can be a substitute for competence...
| | View blog reactionsAnyway, IT people are very specialized--it's hard to do another job, especially when you're a geek - so we're a temp work force: millionaires if you have lived between 1996 and 2008, unemployed afterwards! What about having a world strike and stopping all the systems to show who is the master of the world?! [It's a joke!!]
In Connecticut, if you want to find a job, you probably need to deal with recruitment agencies. The cliche about people who work in an agency is that they don't know anything about technology - they just think they do!
Here is an example of communication failure:
* Recruiter: You're not suitable for that role because you don't know X, Y, Z (Database X, Software Y, etc ...)
* Candidate: I have 12 years of exp with IT: 7 years of professional experience and 5 years in University. I have learned many tools in my career and it should not be a problem. I have a strong potential and I am a high motivated individual. I am a quick learner and you think too much short term, give me an interview and your client will judge.
* Recruiter: You are not suitable because you don't know X, Y, Z
* Candidate: I have 5 years with databases, including 6 months with B; I have also used B for 1 year at university. I am a quick learner. I know very well database theory (SQL, stored procedures, all the acronyms the recruiter don't understand). Ask me any technical question instead of telling me I don't know!
* Recruiter: You are not suitable because you don't know X, Y, Z
* Candidate: I have used 5 years with OS Z at university, therefore I should be able to use it. Skills on a CV are not the only things about a person. Two people with the same profile may be very different. Why don't you ask about my personality and my objectives ?
* Recruiter: Ah ah ah ah (laughter). You are not suitable because you don't know X, Y, Z. YOU ARE NOT SUITABLE (with a very nice voice which means : you're a piece of shit)
* Candidate: Screw you!
Many candidates believe that recruiters should focus on your potential and what you can do, not what you don't know! They don't care finding you a job and they don't care finding the best person for clients since even the client themselves may not know exactly what they need. The challenge for candidates is to simply be pleasant.
Sadly, the world of IT causes people who know their shit to act like they know their shit. Recruiters are looking forward to meeting a quota and tend to focus more on the human aspects of technology than anything related to competency. We all know that companies once they make a commitment tend to have a difficult time correcting mistakes they made and will simply stick with it. We also know that even when you make it past the recruiter, other interviewees are probably squeezed for time and have more interesting things to do than to figure out if you are competent or not.
Let's face it, when the status quo is that IT can't align with the business, the vast majority of projects are either over budget and/or late, this proves that competencies aren't that important in the grand scheme of things.
In terms of the skit above, the candidate made the fatal mistake of only focusing on skills and didn't think to mention process. After all, look at how methodologies are sold. Haven't you yet figured out that the vast majority of people still think that process can be a substitute for competence...
Tuesday, November 02, 2010
Connecticut Voters Guide 2010
In the Manchester Court House, inscribed in marble as you enter is the phrase: Laws are made for men of ordinary understanding. The funny thing is that the court is filled with lots of ordinary people who don't understand and are being rapedassisted by lawyers guiding them through the process...
The democrats made history this year with the passage of healthcare reform. Some believe that they ignored the values of the constitution, while others believe they did it to provide aid to those who otherwise couldn't afford decent healthcare. Regardless of where you stand on this issue, we can all acknowledge the simple fact that the bill contained thousands of pages in which no currently elected senator or congressman actually read in its entirety nor fully understood.
It is one thing for us ordinary citizens to not understand laws, but it is another for those who make the laws to not understand the laws. While intent of the law may be noble, it is really responsible to have so many laws on the books that no one understands?
With this thought in mind, I am encouraging the residents of Connecticut to consider the following when casting their vote:
| | View blog reactionsThe democrats made history this year with the passage of healthcare reform. Some believe that they ignored the values of the constitution, while others believe they did it to provide aid to those who otherwise couldn't afford decent healthcare. Regardless of where you stand on this issue, we can all acknowledge the simple fact that the bill contained thousands of pages in which no currently elected senator or congressman actually read in its entirety nor fully understood.
It is one thing for us ordinary citizens to not understand laws, but it is another for those who make the laws to not understand the laws. While intent of the law may be noble, it is really responsible to have so many laws on the books that no one understands?
With this thought in mind, I am encouraging the residents of Connecticut to consider the following when casting their vote:
- Do not vote for anyone who is a lawyer. Candidates with business backgrounds are less likely to wrecklessly execute in this manner. Business people are more inclined to keep things simple.
- Do not vote for anyone who is a career politician. In order to grow the economy, we need fresh ideas and new thinking. Doing more of the same, won't result in a different outcome.
- Don't vote along party lines. Being a democrat doesn't automatically make you a liberal. Being a Republican doesn't automatically make you a conservative. Vote for people who share your values.
- If you are Black, don't vote for a candidate solely because they are Black. The same goes for other ethnic groups. Politicians don't really take specific actions targeted at ethnic groups for their benefit as they are there to serve all people.
- We need candidates that are pro-American. Anyone know of friends, family and coworkers where their jobs were outsourced to another country? Ask which candidate will remedy the world trade imbalance which starts with local policy.
- Don't vote for candidates that have never had to make payroll. The subject of job creation shouldn't feel academic or conceptual. We need candidates who have real-world experience creating a payroll. We don't need candidates that wouldn't even be successful running a Hot-Dog stand.
- Vote for candidates who have demonstrated they will uphold constitutional rights. Regardless of whether you are pro-gun rights or anti-gun rights, it is vital that the candidate support the rights as outlined in the constitution, for without it, we will be a nation of lost people with no framework to guide us forward.
