en-us http://www.keithwatanabe.net/index.php Keith Watanabe's Website http://www.keithwatanabe.net/blogs/2007/7/22/dd0b3ae6d0dbe0565ea408af5c5ed09f.html
I work in life insurance (finance) and it is well known that the environments for such companies are not typically suited for creative, bombastic and non-conservative types. Then when you work in a place like Tokyo, the arena becomes even more competitive since the proximity of IT companies allow for people to easily switch companies. If a company then cannot afford good engineers, what can they do?

Engineers are fickle and typically are not the most easily social bunch. They have idiosynchrasies that basically are best described in the online comic Dilbert. To put in words though, engineers have certain requirements/tendencies when it comes to work:

• They are NOT business people
• They do not easily understand requirements, nor usability; they merely build it
• They enjoy technology for the sake of technology
• All tools ought to be fair game
• They are very skill minded and constantly worry about the technologies they use to update their resume
• There is a general tendency to dislike suits and stylish clothing
• They are lazy and do not have good physical habits on average (washing, brushing, eating healthy)
• They are creative and must be respected for this aspect
• They do not like being pushed around and have even less respect for those who are mentally inferior and/or accomplished less than themselves
• They are intellectually competitive
• Money is not necessarily an end goal
• Long hours in front something that makes them go blind, have swollen hands, and bad backs make them even crankier
• We are not slaves
• We do like women; very BEAUTIFUL women

These attributes I think most average engineers would agree upon. Those who don't probably either belong to a special echelon or are wannabes that are seeking money. With this in mind, my suggestions for employers having problems locating good engineers are as follows:

• Never create a prohibitive environment; engineers are smart and will find some way to beat the system anyway
• Never monitor your engineers' activities. We all have probably read 1984 or at least recite from it on occasion. We all read slashdot.org and are against draconian business environments
• Allow for casual dress. If you start to restrict how your engineers dress, your focus on the IT department is completely misguided
• Never allow your project managers to ever think for a second that they know more than the engineers, unless they have been in such a position for a significant amount of time to allow them the privilege of guiding such a group
• Allow engineers gadgets and tools for them to do their work. You can't build a house solely with a single hammer.
• Enterprise standards are good; but make certain that those standards make sense to the engineers
• Allow engineers signficant periods of time between meetings to perform their work. Building systems is a heavily intellectual process and requires a great deal of concentration. Meetings and constant distractions are a detriment to an engineering project.
• Allow engineers to dictate when project needs to get released. Project failures that I've seen are a result in misguided assumptions about deadlines. Engineers know better than anyone their own limitations and what they can and cannot do on a project.
• Allow the engineers to decide which part of a project they will take up. Again this goes back to the idea of engineer's capabilities
• Engineers need like minded people to bond with. Engineers are a bit snobbish and will call people dumbasses behind their backs in believing that they know more than the people around them.
• Engineers care about the reputation of their company. The company's reputation is a reflection of the engineer's potential next job. If the company is doing poorly in the IT aspect, it will likely only attract the poorest level of engineers.
• Upper management need to be a reflection of what the engineering department should look like. Your upper management should know more than the engineers. Never put a puppet CIO/CTO or whatever in charge as it will only cause confusion and resentment amongst the people in IT.

These are the abstract levels of building a good department. In addition, here are some interesting methods for growing this idea with some hard benefits:

• Offer a growth program for engineers. Set aside a budget for all permanent employees hired per year that involves things like seminars, online courses and certification. You need to reinvest in your engineers to improve the quality of your department.
• Afraid that the above will only cause engineers to be depleted? Have a contract that says engineers can only be allowed to take such courses so long as they stay within a certain period
• Provide perks related to the engineers' interest. Discounts to computers, PDAs, or other forms of equipment. Setup deals with companies that benefit both companies.
• Attract good looking females and make them "one of the boys." Everyone who's been around IT for a significant amount of time probably has realized that the guy-girl ratio is quite bad. Add that to the usual "sexual harassment" policies, and you're creating a sausage fest of frustration. But just adding token women isn't a true encouragement for this situation to improve. Women need to become more "geeklike". No, not thick taped glasses wearing, PDA carrying people who don't bathe (i'm certain even geeks would avoid these beings). I'm saying offer opportunities but never allow women to take advantage of their looks or whatnot to gain an advantage. Show true equality but giving them a chance, but making them earn it as well. This is a two way street that needs to evolve.
• Allow for more work-life balance styles. I do my best work at odd times of the night. In fact, I find most working hours to be counter productive for me since I'm a late person. We're in the age of Web 2.0 so I can't see any realistic reason for people to maintain the old 9-5 work hour schedule. Also, allow for engineers to cut down on the necessary days in the office. Things like 3-4 day work weeks should become more en vogue; it certainly makes more sense for an engineer to concentrate on a piece of his project for 8+ hours straight rather than breaking his concentration and outputing only 4+ hours of quality work per day. And offices need to realize that trying to suck out more energy from an engineer does not necessarily imply higher quality work.

Anyway, these are some small ideas to get started. Hopefully, some major employers will see the true merit behind these.]]> Sun, 22 Jul 2007 03:53:38 -0600 http://www.keithwatanabe.net/blogs/2007/7/22/dd0b3ae6d0dbe0565ea408af5c5ed09f.html http://www.keithwatanabe.net/blogs/2007/8/7/c15a7710f8917f5c8e8ced53e930ca17.html
What's wrong?

There was an article a while back on the failure of IT projects. I'm in one right now where you're seeing these symptoms. And it's not pretty.

This is not the first time I've been in this situation either. Actually, I've worked at quite a few places where this situation occurred.

I've also been in companies where I've worked with highly successful projects that were delivered on time. So by that logic, I know the fault wasn't entirely on me.

Yet, do you ever get the feeling when you know failure is imminent, no matter what you do and how hard you try? What I described above is that clear sign of failure. But I think the root cause is far deeper.

- Reactionary management. When management begins making arbitrary decisions, it implies that they are only looking at deadlines and deliverables, not the overall picture. I find reactionary management going on in smaller companies where processes are not well defined as well as in start ups or companies with little experience in handling IT projects.
- Unfocused agenda. You need to understand why a project exist in the first place. Do a CBA to really get a better picture of what goes on. More importantly, understand the goals of the project. In my situation, one of the key drivers was building an in house team to deliver higher quality code while bringing knowledge in house. Part of that situation was utilizing an existing pair of systems which were problematic in the dual maintenance and consolidating them for the distributors' sakes. At this stage, all the focus has gone towards the code deliverables because a vendor took over. Well, again going back to the original idea, we were supposed to move away from using vendors and increase the in house knowledge of our people. Management had forgotten this, or rather never cared as hidden agendas started popping up. Still though, one key premise was removed from the project's goal, which is why the team lacks focus and is frustrated.
- Missed milestones. This is obvious, but people rarely want to blame lack of planning as a root cause. You have to clearly reason and allow for margin of error when it comes to choosing deadlines. You won't truly understand a hard deadline until people really get into a project. Otherwise, you need a truly experienced planner to detail the breakdown of the deadlines.
- Never overpromise. Promises are made to be broken. This is just a rule of thumb. Live by the software rule: underpromise overdeliver. Don't promise something until people truly understand the extent of the problem.
- Constant scope creep. Scope might not necessarily come in the form of just requirements. It could hidden requirements or implied requirements as well. Hidden or implied requirements are those that come up at a later time that people realize are necessary, but only at the time when being dealt with. Be forgiving on this point at people cannot always foresee everything little detail.
- Changes in requirements during build phase. This only hurts if you're working with an inflexible model. But once requirements are nailed down, they must be signed off, never to return under all reasonable circumstances.
- The waterfall SDLC. It sucks. Plain and simple. They should delete this from software engineering classes and put it as a footnote in the failure of human history.
- Adding more resources. Read: put more people on the project as the project goes on. Especially engineers. Wrong reasoning. The starting team needs to end the project together, unless people have personal reasons for taking off.
- Allow for about 10-15% margin of error. Japan needs to start understanding this aspect of software engineering. Then again Japan needs to start being more flexible and understanding in general.
- Scattered requirements where people are asking the same question more than once. That means that the format and ways of locating the requirements have been poorly executed. Don't overcomplicate requirements and don't go into every little detail for requirements. Most of all, make sure those requirements are easily available for anyone to reference. Definitely don't have them on some shared drive displaced in multiple areas.

I can go on about this (and I might add to it later). But I have to return to my failing IT project. Happiness.]]> Tue, 07 Aug 2007 18:36:56 -0600 http://www.keithwatanabe.net/blogs/2007/8/7/c15a7710f8917f5c8e8ced53e930ca17.html http://www.keithwatanabe.net/blogs/2008/4/30/1552e09e2743b78d0e4bcd86f274bbc0.html
The future of computing will be server based applications with dumb terminals connecting users to the web. Again, Larry Ellison and Sun were completely correct in their assumption that the network is the computer. However, as with any betting situation, correct timing is everything. In this situation, I estimate we're about 5 years away from this move so maybe Larry can push his little network computer idea again in 2013.

That said, I look at desktop computing as being simply an outsourced function. You just rent from Dell, HP/Compaq, IBM, etc. But rather than having an overly complicated setup where you get your Exchange Servers, your virus protection software, your shared folders, your LDAP/Active Directory services, etc. you'll just be unified through a single entry point on Google, Yahoo, etc. with your applications built upon one of these massive computing clouds. The hardware itself will be simply a screen, maybe a wireless interface to the network and some other interface for interacting with the web, kinda like the iPhone. When you do your outsourcing, Dell or whoever will come down, give your terminal, setup your network with your provider, maybe even provide some customized desk space. But the need for desktop software simply will vanish.

I kinda see things like the cable guy going to your house to install the cable box. After that, everything is pretty much done and you just use your little pointing device to handle the rest.

As far as the customer service aspect of the IT Help Desk role, it probably will be more automated and integrated with some web CRM like PeopleSoft, or SAP (if they can scale down the cost). The role of the IT Help Desk manager will simply be transformed into an account manager with the supporting service provider (which is why Google needs to start working on their enterprise support service section).

The nice thing about this scenario is that it'll weed out all the wannabe hobbyists who think that hooking their keyboard up, turning on their monitor or installing a game at home is REAL IT and move the aspects of computing back towards pure programming. Then people who are truly knowledgeable about hardware, systems, etc. can focus their time on solving scalability, outage, etc. type of problems.

I'm not saying that these wannabe hobbyists should be discouraged from getting into IT. I'm just saying that the competition will weed the ones who help stagnate the industry and motivate the ones who want to really understand the overall picture of IT by forcing them to constantly improve themselves.


]]> Wed, 30 Apr 2008 15:02:14 -0600 http://www.keithwatanabe.net/blogs/2008/4/30/1552e09e2743b78d0e4bcd86f274bbc0.html