en-us http://www.keithwatanabe.net/index.php Keith Watanabe's Website http://www.keithwatanabe.net/blogs/2007/8/6/3cd7b550e3c8b9aca58eaf5415d3d8a9.html
1) Creating a team
2) When to hire junior level people

1) Creating a team

The importance of this is generating the chemistry between members so that they understand their role and can function well. In other words, they should at least be able to get along with each other since they'll probably be working closely with each other for the next few months or years on a project. Don't throw people together at the last second on a project. Make sure a team has been pre-assembled before starting a project or else you'll find yourself scrambling desperately for a contingency plan.

On my project, our HR was late (and cheap) in trying to get people. By the time the project started, we lacked resources so I was the only person really handling the code. As a result, my manager (along with others) decided to add a vender's staff for the project. HUGE MISTAKE. Why? These guys were inexperienced and incapable of handling a project of this level. Worse yet, there was one guy in particular who attempted at every turn to take the project for his company and push the rest of us out. Now, I got burned out and my manager ended up favoring the vender. But in reality, what my manager's poor decision making had cost the company was alienating his key team members for the sake of the project, rather than ensuring the morale of his team was good to move on.

Not to mention that the vender continued to bring in low quality developers that ended up costing the company a heavy amount and expanded the project deadlines.

2) When to hire junior level people

We can't always say that the ONLY thing to hire are extreme senior programmers. Otherwise, there would be no room for the next generation of developers and all a company would receive in turn are these aging guys at Country Kitchen Buffet. So obviously, there needs to be a strategy for hiring kids out of school. So the question is when and how?

- Hire junior level people when your system is stable and you need some maintenance done. I've seen people transition from areas like QA into development or other minor coding (like templating) to development since they are more familiar with the problems of the system.
- Hire junior level people when your company business is considered relatively stable. Meaning that you don't need monstrous levels of hardcore programming where you're facing issues like downtime, etc. These issues are well known and should be handled by more experienced people. Junior level people excel more in using their enthusiasm and eagerness to appear and learn through doing more mundane problems.
- Use junior level people to solve non-critical problems. Get them familiar with how things ought to be done. Make sure you have seniors who are able to mentor these people. Getting them to work on production issues, simple bugs and related tasks are needed at first. Once you get their trust that they are capable of handling their work, you can move them towards more difficult problems.
- Never use junior level people to do architectural things. Architectual elements are the role of architects. Decision making should be kept far from junior level people. They are around to execute, not really think about company decisions, just focus on the problem before them.]]> Mon, 06 Aug 2007 18:23:38 -0600 http://www.keithwatanabe.net/blogs/2007/8/6/3cd7b550e3c8b9aca58eaf5415d3d8a9.html http://www.keithwatanabe.net/blogs/2007/8/7/80b8d9e23e796351110a7ea432ef9328.html
I have to revisit my earlier thoughts on how the IT industry needs to have something like a global union. They need to divide IT workers into various classifications, scale the pay accordingly, and tier it. So for instance, classifications would be web developer, software engineer, architect, production support, DBA, network engineer, system administrator. The pay needs to scale according to the demand and difficulty level of the position. So things architects are hard to come by, especially good ones. Thus the payrange would be quite high. However, a Windows administrator or support worker might make a significant amount less considering the difficulty and quantity available. The tiers would work according to experience and successfully executed projects. This methodology would provide for a balance of allowing older, wiser people to gain more pay yet force them to be competitive and competent, even after proving themselves.

Another key element as I mentioned in a previous article is that unions should require formal testing to progress through the tiers. In this manner, people won't be forced to graduate with a degree in computer science or information sciences (although it may help). However, it would induce all people to remain competitive on the market through constantly upgrading their skills. The unions could utilize their fees partly to help subsidize for some of this cost. But ultimately it would come down to the responsibility of the individual to maintain a standard of excellence for themselves if they wish to progress through the tiers.

One key advantage that these tests provide is standardizing ways to measure the competency of an employee. I've seen wide ranges of interviews (and given them myself) and there isn't a single one that truly gauges a person's ability (although another huge issue is the person's character, but that should be besides the point). One thing this can provide is a range of tests to assess the level of competency a person has in different fields. A Java developer might excel in areas like JSPs, JSTL, servlets, but might be somewhat weak in threads or Swing programming. He might also be tested for creative problem solving and communication ability.

Tests can be progressive. If a person feels that they've succeeded at a certain level, they can continue to aim at higher levels until they hit the top tier. Or they can try for other tests if they decide to follow a separate career path. Also, the tests must be translated in all languages to be fair.

Returning to the issue of standardizing salaries, one thing I felt was to make salaries relatively equal. Not between positions and levels, but between countries so that companies won't get a competitive edge by outsourcing. The only problem of course is where the cost of living is so low, those people would gain a huge advantage over their counterparts in the world. Alternatively, the union from one country would have to partly subsidize the loss of jobs in another country if wages are forced to be lower.]]> Tue, 07 Aug 2007 11:01:52 -0600 http://www.keithwatanabe.net/blogs/2007/8/7/80b8d9e23e796351110a7ea432ef9328.html