What is a Defect?

I received some interesting feedback on a previous post of mine (Defect Count is Constant), and it really prompted me to define what is a defect, and why I believe that the defect count is fairly constant. This comment was from a developer, but I'm sure applies to many more people and roles in software.

I definitely don't want to ship a non-perfect product. Especially because I just got out of school (a year ago) and every assignment I handed in (except one) was perfect.

Before I get into what is a defect, let's look at an official definition:

• Dictionary.com - "The lack of something necessary or desirable for completion or perfection."

So why do I say it is inevitable that all software will have defects? It's easy to say that my experience has proven this again and again, but that's a coward's answer. The truth is that there are a number of reasons. First, here is my definition of a defect:

The software does not do something that it is supposed to do.

I know my definition seems fairly vague, and that is by design. Every piece of software is supposed to do something. What that is, who determines it, what the customer wants, these are all negotiable and this is where some of the confusion sets in. If a customer wants a button that turns the screen green, and the product manager writes a specification to make the screen blue, the programmer could make the world's most perfect button, the code could be beautiful, and the testing could pass without a hitch; and it is still a defect. The customer is not getting what they want. Don't think that I feel the customer is always innocent, sometimes they say green and mean an off shade of lavender, but that is a different post for a different day. While this may seem like a very simple issue, and one that could be fixed quickly, start to image an exponentially more complex scenario. 250+ customers, 50+ high priority customers, all who want the same features to work in different ways, 10 people in product management writing specifications, 60 developers spread across 3 countries, 5 timezones, and 2 continents, and 60 testers, only 10 of which have any experience with the prior iterations of the product. Now you can start to see where things fall through the cracks.

Sources of defects:

• Poor Programming
• Poor Requirements
• Missing Requirements
• Missed Defects in Testing
• Misinterpreted Customer Requests
• Untested Usage Scenarios
• And Many More.....

The Point of this Post

Again, why does all software have defects? The truth is, there is software out there that literally has 0 defects. According to my previous post, that software's constant defect count could be 0. All versions of that software should ship with 0 defects. But as you increase complexity, dependencies, and requirements, the defect count will always increase. I won't begin to project percentages of the defect could that could be attributed to any particular source, and that is usually dependent on the team and its process. A team with a really strong customer interaction and strong product management probably has very few requirements defects. This also typically trends to a higher level of developer defects since the requirements contain additional detail, and that leaves additional details to be missed during the programming process.

The other hidden truth in a constant defect count is the severity of these defects. Sure, the number of defects remains virtually the same, but the average severity should continue to decrease throughout the testing phase of the product lifecycle. A critical defect, in my mind defined as a defect that you can't ship without fixing, will get fixed. While re-testing is, the tester may find a typo on the screen. Now, the total defect count hasn't changed, but I think everyone would agree it's better to ship a product with a typo then a product that doesn't install properly (example of a critical defect).

At the end of the day, everyone is human. The more complex the task, the higher the risk and occurrence of defects. This is to be expected, and it becomes the role of the leads and managers to work through the list of defects. So yes, it is possible for software to be perfect, but the likelihood of that is inversely proportional to the size of the project. The true skill is in being able to manage a product and ship a release that isn't perfect, but having a solid enough understanding to ship the important pieces well, and make sure that all of the known defects are manageable.

I'll be making another post soon on how to manage a product's defect list during the development cycle. Until next time .....

Technorati : Development Management, Management, Methodology, Program Management, SDLC, Software Development, Software Development Lifecycle, Software Management

What Salary should you Offer ... Part 2

Wow, a few very good comments on the first post. Let me first respond to something that I want to make sure was very clear.

The option of applying the 15% raise almost blindly, based on the employee's previous salary, is a typical HR tactic. It is not something I personally believe in, and don't ever blindly advocate. Sometimes it works out that the proper salary to offer someone is a 15% raise, but that is based on merit and coincidence, not some arbitrary program.

I can classify the rest of the suggestions into two categories: a structured, planned incentive program, or paying market value on hire. Both options have their pros and cons, and I just wanted to play devil's advocate a bit here.

First, the structured incentive program. This looks like the best option for both employee and employer. The employee doesn't pre-pay without seeing performance, and the employee has direct compensation incentive for performing. While this is great in theory, there are two major roadblocks I've come across with this one. The first one is bureaucratic, and probably only applies to larger organizations. In a large, publicly traded company, it is not that easy to ever process through an adjustment of more than 10%, or more often than once a year. This is usually a mechanism put in place to maintain some centralized control over expenses, and allows a pre-planned bump in quarterly expenditures for

Wall St . Most raises over a certain % also require either senior management or executive management's approval. The other risk that comes into play when following this course of action is that it could create a jealousy / competition scenario with your other staff, and all of a sudden you're being asked to put in a bonus / incentive program for the whole team. Again, something that probably makes sense for a small team, but far less feasible in a larger organization.

The advice to just pay market value up front has one big risk, identified by Jacob,

Hiring people is a very real risk. Someone can look very good on paper and present himself well and turn out just not to work.

I couldn't have said it better myself. This is the big risk. You are paying for perceived performance, rather than results. If you are hiring a superstar, then excellent; but what if hire a dud? What if he doesn't mesh as well with your team as the interviews led you to believe? These are the types of decisions that in aggregate will make or break your management career. If you have to fight to get the offer you want to offer, and the candidate bombs, everyone will forget the candidate, no one will forget that you fought for an employee who didn't work out.

At the end of the day,

A manager is nothing more than someone empowered to make decisions, and trusted by senior management to usually make the right ones.

As another commenter said, "you can be replaced with a calculator" if you just follow an inane formula and don't use the judgment you are paid to impart.

I'm hoping for even more comments on this post, so fire away .....

---

Link: Original Post

Technorati : Development Management, Management, Program Management, Recruiting, Software Development, Software Management

Weekly Recaps are Useless

I started this blog with the intent to post a play by play of my job on a weekly basis. Based on some feedback, and monitoring which articles are read the most, I'm not going to bother posting a weekly "In the life of" type of posts, but will definitely continue to post my thoughts / rants / musings on the world of commercial software. Comment below if you think there is value in continuing these posts and I could probably be swayed to continue posting.

Here is a link to the original post: Link

Technorati : Development Management, Program Management, Software Development Lifecycle, Software Management

What Salary should you offer a New Employee

Updated Response on June 19, 2006: Link

One of the most difficult topics facing managers today is compensation. There are several factors that come into play, and software further compounds these issues since it is the only field that I know of where the same job can have a 30%, 40%, 50%, or even 100% swing between companies and even employees at the same company.

This was a dilemma that came up for me this week; I decided to make an offer to a candidate from another company, and the offer would be a promotion for him. He was moving from a test engineer to become my test lead with a few direct reports. His current salary was within the range for his position, but towards the lower end. He was an impressive candidate with more than 10 years of experience, and 3 years of experience with a competitive product to ours, so he would be able to ramp up very quickly with a domain specific product. Here are the three scenarios I could choose from:

1. 15% Raise. This is a fairly standard tactic. You want to give a candidate incentive to move, but you don't want to give them too big of a salary jump. Personally, I don't believe in this theory and think you should pay an employee based on ability, not what their previous employer was paying them, but nonetheless, this is a widely held practice. For my situation in particular, a 15% raise would put the candidate at the bottom of the range for a test lead, but still making more than the direct reports he would assume. This is typically pushed by HR who never wants to knowingly see an employee jump more than 15% in salary, or by managers who have rule-based compensation procedures.
2. 30% Raise. A raise of this size would put him at the ideal midpoint in the test lead range. In the world of fairness, keep in mind that the real world isn't fair, this is where the employee should be. If he is qualified for the job, then regardless of what he asked for or what he used to make, he should be offered the target salary for the position. I know this is a candidate's best case scenario from a hiring manager, and takes some of the fun out of the negotiation, but I'm a firm believer that compensation is not a game you want to play with your staff. Personally, if you can take salary off the table as an issue of contention amongst your group, and make sure that your employees are compensated fairly compared to the market, I think you get exponentially more productivity from them. My experience has shown that money is the number 1 issue of complaint, and also the number 1 factor in morale and general happiness. As far contrary remarks about budgets, outrageous salary demands, escalating salary ranges in the market, and the rest, I still believe it is a small price to pay when compared with the costs of recruiting, hiring, and training a new employee. For those small companies that cannot afford the higher salaries paid by more established firms, you still have plenty to offer: bonus incentives, stock options, company equity, balloon payments, etc... There are always creative options.
3. The Low Ball. This is the other tactic that is out there. Offer a candidate less than you're willing to pay. Offer what they're making now. Offer a 3% - 5% raise. Basically, less than would be fair, and less than you'd accept if you were in a similar situation. Try to sell the point of the opportunity, and it is worth more than the money to be made somewhere else. These are all fair tactics, just not ones that I subscribe to. Refer to point #2 for why I think compensation needs to be fair, but basically I think this approach leads to a disgruntled employee 6 - 12 months down the road when the experience is not what they thought it was, or they had a bad or stressful week, or anything to make them even marginally unhappy. The immediate thought will be "I'm not paid enough to put up with this." This thought leads to reduced productivity, reduced morale, and those attitudes spreading throughout the rest of your team.

I'm interested in feedback. What would you do in this situation? What is the right approach? Does giving a 30% raise set an expectation that annual raises are more than a standard 4% - 6%? Well, I ended up going with option #1 to satisfy my manager and HR, with an already budgeted plan of giving the candidate another 10% raise after 6 months of probation / performance review.

Did I miss any other options? What are some other tactics for luring away an employee? These are basically the options I considered, but I'm sure there are more out there.

I look forward to any comments below .....

Technorati : Development Management, Management, Program Management, Recruiting, Software Development, Software Management

Howard Stern is Streaming on Sirius

Launch the Sirius Player Here: Link

Sorry for the miscellaneous blog entry, but I'm a huge Sirius Satellite Radio fan. As of today, Sirius's largest personality, Howard Stern, has both of his channels streaming through the website. This will be the next big boon for increasing Sirius subscriptions. I'll admit I'm not even that big of a Howard fan, I just think it is great for my stock investment and the company's health in general.

Congratulations Sirius for the content upgrade. Now, can we the rest of the original programming channels to stream?

Link at the bottom too: Link

Technorati : Howard Stern, Sirius, Streaming

This Week's Reading Assignments for Software Development Managers and Aspiring Managers

Here are some collected readings from around the web that relate to managers or aspiring managers

• Climbing out of Technical Debt - Link
• Shipping a 1.0 Product - Link
• Understanding Managers - Link
• Non-Technical Skills for IT Staff - Link
• Painless Estimation Tools - Link

Please comment if you find any other valuable clippings.

Technorati : Development Management, Management, Program Management, Reading, Software Development, Software Management

FREE Entry to the World Series of Poker (Free Tournament)

Real quick post....

Over the last few years, I've developed a new hobby of playing poker. I know this is very trendy right now, but I actually got into it about a year before it really became big on ESPN. Well, the World Series of Poker is THE tournament in poker. It is played in Las Vegas towards the end of July and the entry fee is $10,000 and this year the winner will take home between $7 and $12 Million. There are plenty of online tournaments that require you to play / win in 3 or 4 or 5 successive tournaments to win a seat and pay an entry fee ($5 - $500).

Well, for all of you poker addicts who are looking for their best option to win an entry, here it is. Poker Stars is offering a free, 1-day, top 9 take all tournament. The tournament is only open to bloggers, but a new blog is easy enough to setup on Blogger / WordPress / others that this is not much of a requirement.

See you all in Vegas!!!

Registration Page - Link

Technorati : Gambling, Poker, World Series of Poker

What is More Important? Time or Quality?

I came across a post that raised a few very good questions about the software business, so I thought I would respond.

• How partial can the initial result be and still matter?
• Partial in features or partial in quality?
• Is a later corrective delivery a separate, on-time delivery, or a completion of the initial delivery, thereby making it late?

The underlying question here is how do you make the decision when you can't deliver on scope, quality, and timeline, how do you choose what to sacrifice? The original author makes a good analogy:

If you're running for a plane and lose a shoe. Better to make the plane and buy new shoes at the other end, right?

And of course, the counter point:

What happens when the client you were going to visit by plane is on the plane, sitting next to you?

To be consistent with the focus of this blog, I think there are a few rules that apply here to software development teams:

1. Know your users. What will your users accept? If this is a critical, life or death piece of software, quality probably can't suffer but timelines are allowed to move. If it is an business process automation application, then maybe quality can slip since the ship date is critical.
2. Use your Product Manager. I made a previous post about the value of product management (link), and this is another benefit. Usually, product management owns the customer base and profit / loss accountability. (In your organization, this could be sales, marketing, or a business unit GM. In those cases, target them with this advice). At the end of the day, your team is not held accountable for P & L. Your team is responsible for fulfilling requirements provided by product management. You are not directly tied to the customer or the sales cycle (yes, I know this is slightly different in small companies, but realize that the roles are there, you are just wearing different hats). Let the product manager determine which aspect of the project to sacrifice.
3. Use your best judgment. In the event that you are left to make the decision, go with your experience. If you were the user, what would you prefer? Could you postpone a feature? Could you delay part of the product? Someone has to make a choice, you just need to accept that no choice is going to be popular. Everyone will want all features with all quality on time. Your job is to get past the emotion, and recognize that it just isn't going to happen this time, so it's time to make a mature, rational decision about how to proceed. The inevitable "how did we get here" question will certainly come up, so you need to be prepared for it. Remember, history is a great instructor for the future, but it can't be changed regardless of how much you talk about it.

These are decisions that come across my desk all the time. As a general rule, I try to stick to rules #1 and 2, but in the event I need to decide, I do so. Trust me on this one, indecision is far more costly than the wrong decision. I've made a bunch of decisions about projects and scope. Some were right, some were wrong, and some were very, very wrong. Bad decisions happen, the trick is to manage past them, not to let them define you.

The full post can be found here: Link.

Technorati : Development Management, Management, Product Management, Program Management, Software Development Lifecycle, Software Management

Scoble is Leaving Microsoft

I realize this is all over the web, but I'm just getting it now. Robert Scoble, one of Technorati's top 100 (#26 as of this morning) bloggers, is leaving Microsoft for startup PodTech.Net, Here are a collection of links that are a valuable read.

• Scoble's take - Link
• Niall Kennedy's Homage
• Chris Pirillo - Link
• Silicon Valley Watcher Article- Link

I've been reading Scoble for over a year now, and I must say that he is truly a blogging superstar. He is the first blogger that I can think of who did a great job of balancing his insider access as working for a major software company with his general geekdom passion by writing very openly about anything in the world of technology. While no one in the blogosphere will miss out with his continued postings, and Microsoft will continue to have over 3,000 other bloggers, they have certainly lost their heavy hitter in the blogging community. Good luck Robert!

Digg to Expand Beyond Nerds

According to Rob Hof from Business Week, Digg's CEO announced today that his team is hard at work to expand Digg beyond tech news and sites, and expand into news, politics, and all other worldly events. Read the full posting here.

Technorati : Digg, Reading, Software

As usual, Joel Spolsky is Right on Point

Joel Spolsky is an incredibly interesting author. He's written a few books, posts regularly on his blog, and at the same time runs a successful software company. You can search through his blog and see some of his other postings on software management and development, his process and theories behind hiring summer interns, but I recently came across what I think is his best idea yet: The FogCreek MBA program. His premise is that to be ready to run a software company, an MBA doesn't do you any justice, but he is planning a three year crash course for recent graduates that at the end should prepare them for anything the world of software has to throw at them.

You can read all about the FogCreek MBA program it here. Joel also posted a recommended reading list for this program that can be found here.

Technorati : Development Management, Joel Spolsky, Management, Reading, Recruiting, Software, Software Development, Software Management

How to Hire Talent

I may be in the software industry, but this is a problem that affects every manager in every field. How do you recruit and hire the best talent? There are the general cliche's like "Hire people smarter than you" or "Hire someone you could work for," but these don't actually give any information you could use.

Everyone has their own process for hiring and I've been through several as both a candidate and an employer. The best tip that I can offer for how to run an interview is that the candidate should meet with several people, and all on the same day. This makes it a one-stop shop for the candidate, and allows the company to react quickly if they decide to move ahead with an offer. I'll make a future post on my idea of a recruiting / interview process.

Anyone who's ever given an interview should know that they are walking into the interview preparing to answer one question when they're finished: "Should the company hire this candidate?" The question sounds fairly easy to answer, but the process to get there is complex, and sometimes requires a crash course in psychology 101. I've compiled some tips below that I try to follow with each interview I give.

First, let me put my interviewing frequency in context. I am one of the key interviewers for my company, usually giving 5 - 10 interviews / week, ranging in candidates like test engineers, software engineers, software architects, project managers, program managers, and product managers. While a typical interview with me lasts for 45 minutes, I probably have 2 - 3 hours worth of interview material.

The biggest struggle that I see, especially in first time managers, is the ability to recognize talent. Senior people are always easy to hire; they know their area of expertise, they pass all of the technical interviews, they have the experience of several software projects, and they are mature enough to give the expected answers during the interview. For them, it just comes down to personality fit and they either mesh with your team or they don't.

It's the diamond in the rough that seems to be the most difficult to identify. And these people are the most critical to your project; the 'B' players; the group who makes up 70 - 80% of your team; the group who'd you love to see a few grow into 'A' players. So how do you sort out the candidates with potential from the ones who are just repeating what they memorized in the latest programming book they read. The basic knowledge is usually the same. The candidates most all be competent in your technology of choice, they must get along with your team, and they must fit your budget range. Now the hard part, once you've identified a few candidates that fit these basic criteria, how do you know who will really succeed? Who will improve your team? Who will exceed your expectations?

1. Evaluate Problem Solving. Try and find out how the candidate works through a problem that they don't know the answer. How do you weigh a 747? Why are manhole covers round? How many cars are there in New York City? Questions like this are not designed to reach the answer, but to see how the candidate thinks. How do they respond to help? Do they ask questions? Do they break down the question logically or randomly? These are some key indicators for imaging the candidate 6 months down the road when you have to develop a solution that no one on the team has ever seen before. Maybe an obscure defect that you can't reproduce These situations will inevitably come up, and you want your team best prepared to handle the unknown, and be able to breakdown a problem logically.
2. Hire Smart People. When in doubt, hire based on intelligence. Generally speaking, intelligence has a direct correlation to ability, adaptability, and efficiency. I'm not saying this is a black and white issue, but when you can't decide between a few candidates, the smarter candidates have a higher probability of success
3. Admitting Ignorance. Throw out some questions that the candidate has no way to answer. Don't throw out a brain teaser for this one, but throw out something extremely technical or deep, or on a technology just outside of their knowledge level. You already know that they don't know the answer, the test is whether they'll admit it, try to dance around it, or engage you in a conversation to get to the answer. As a rule, anyone who tries to give me a b.s. answer, I immediately won't hire. Anyone who can admit they don't know something when they are engaged in an interview is someone with the maturity you are looking for. Professional maturity is a great indicator for future success, knowledge transfer, and constant growth.
4. Communication Counts. Try to get the candidate to explain something complex to you. Did you understand it? Was the information presently structurally or randomly? How long did he consider his answer? Was he comfortable launching into a diatribe? At the end of the day, communication is key for any team, and yours is not any different. As long as someone can clearly express their status, position, opinion, thoughts, really anything, then your chances for team success have just gone up exponentially.
5. Career Goals are Good. Senior talent generally know what they are looking for, and have usually already achieved some career goals. Entry level people probably have no idea what they're looking for, but just have some skills out of school and are looking to learn. Again, it's the middle group who really have something to prove. You want to make sure that your candidate has some goals, and he's on the path to reach them. The actual goals aren't very important, it is that there is a career plan being executed. It shows forethought, direction, and purpose. The one exception to this rule is if the candidate's career goals don't map to your field. For example, if someone came in and told me their ultimate goal was to save up some money and move to Outer Mongolia, and they are 4 months away, I probably wouldn't hire them. Outside of that, you're in good shape.

I'm sure that there are other beneficial characteristics to look for, but these are a few that I use. Anyone who'd like to post more tips, please comment this post. And remember, interviews can never determine if someone will be a successful candidate or not. Interviews can only increase your probability of selecting a good candidate, and all you are trying to do as the hiring manager is to hire the candidate with the highest likelihood of succeeding.

Here are some other links around the web that I've found as good reading.

• Guy posted a reader's email - Link
• About.com article - Link

This will be a future post, but here are some postings about how to retain talent once you hire them.

• Why Developers Leave - Link
• Harvard Business School on Lost Motivation - Link
  

Technorati : Development Management, Management, Program Management, Recruiting, Software Development, Software Management

Upcoming Posts

I thought it might be nice to post a list of the initial topics I plan to post on. I'll update this post with links as I post the content

In no particular order

• The Value of Product Management
  
• How to Negotiate Scope
  
• SDLC in the Real World
  
• How to Hire Talent
  
• What Salary should you offer a New Employee
  
• How to Grow your Employees
  
• The Value of Automated Testing
  
• Strategies of Software Teams: New Development vs. Maintenance Development
  
• Strategies of Software Teams: How to transition to a New Technology Platform
  
• Does anyone really want to be a CTO?
  

I'm open to any input for other topic suggestions. Like I said above, I'll be posting in a fairly random order, but I'll be trying to post at least one topic a week.

Technorati : Development Management, Management, Program Management, Software, Software Development, Software Development Lifecycle, Software Management

Dopod S300 / Qtek 8500 Mini-Review

The first step is admitting that you have a problem. I have a problem: I'm addicted to cell phones. I can't get enough. As soon as I hear about a new phone or accessory that is coming out, I turn into a kid the night before Christmas. I read the gadget blogs, hang out in the phone forums, contribute to some open source pocket pc apps, and anything else I can do to stay involved with the community. Anyway, since I came across this phone weeks before it is released in Europe or North America, I though I'd take the opportunity to publish a review.

First, the summary for the folks skimming this entry:

• Style: 5/5
  
• Functionality: 5/5
  
• Performance: 4/5
  
• Battery Life: 3/5
  
• Reception: 5/5
  
• Email: 4/5
  
• Music Player: 3/5
  
• Overall: 5/5
  

Style


This phone looks like a RAZR, but improves on the RAZR's shortcomings. A better keypad, better camera, better reception, and better operating system (Windows Mobile 5 Smartphone). Another nice feature for me is that the phone is slightly longer than a RAZR when it's opened, and since I have a huge head, it better positions the microphone near my mouth, rather than the side of my head. Color wise, black is in. Apple has made all of their products available in black. Computers come in black. Hip cell phones come in black.


The other cool feature is the external display. It's customizable to have a few different styles of analog or digital clocks, but it also shows notifications of new email messages, missed calls, appointment reminders. If you press the camera button with the phone closed, the camera is fully accessible from the outer display. And the music player shows current track status, volume, running time, and paused / playing / stopped state.



Functionality

This phone has it all. It runs Windows Mobile 5 Smartphone, and that basically opens it up to all types of applications. I use the phone to synchronize my calendar and contacts. I also use the features in the Windows Mobile 5 MSFP (Microsoft Feature Pack) that adds real-time push email, similar to a blackberry. In the tests I've run, the email arrives on my phone within 15 seconds of arriving at the Exchange server. It also supports address checking against the server, so you don't need to have everyone added to your local address book. The phone also has the standard collection of Windows Mobile apps like Windows Media Player, Internet Explorer, Pocket MSN, MSN Messenger, and the rest of the normal applications.

Operation while using the phone is a breeze. I was even listening to music while I received a phone call. The music paused, I received my ringtone through the wired headset (not sure if this works over Bluetooth yet), answered the call, and when I hung up, the music resumed where it had left off. This may not sound like a big deal, but it is definitely a small feature / big win piece of functionality.

Dopod included a few custom applications that I found interesting, but ended up uninstalling them to save space. They packaged a custom 3D menu, that looks cool for a demo, but ultimately is slow and doesn't expand for new menu items. there was also a custom MP3 player, but again, Windows Media Player works fine for me.

The once feature that was very important to me when selecting the phone, but one that I haven't had a chance to test out yet is the wireless stereo over Bluetooth (A2DP). This technology allows you to listen to music (MP3 or online streams) through Bluetooth headphones. My dream headset is the Sony Ericsson HBH-DS970 (Link) that I already have on order, but it's not released yet.

Performance

My last phone before this one was an I-Mate KJAM (also know as a Qtek 9100 / HTC Wizard / T-Mobile MDA / Cingular 8125 / etc...), and that ran Windows Mobile 5 Pocket PC Edition. While the operating system was richer in functionality, the phone had the exact same processor as the S300 does, the 195MHz OMAP processor. I always thought the KJAM was OK in performance, but was certainly not a speed demon. My opinion is very different with the S300. Menus are snappy, IE opens quickly, messaging opens quickly, I can have several applications open at once without much trouble. I can even switch between the camera application and IE back and forth without much lag.

The only performance issue that I've had is when I had IE, Messaging, File Explorer, and Media Player open. Then, I went to MIDLet manager and launched Google Maps mobile. This seemed to be too much for the phone to handle. I was eventually able to switch to the task manager and kill a few tasks, but I ended up rebooting the phone since it was sluggish after that. This could be a knock on the phone, but I think it is more likely a sign of an OS instability that will be ironed out in future ROM versions.

Battery Life

Of my short list of my disappointments with this phone, this is top of that list. Granted, i use my phone a ton. Email synchronizing all day long, contacts and calendar sync'ing too, 2 - 3 hours of talk time per day, a fair amount of web surfing from the phone, listening to music, and a few other things. Should I expect more than 1 day of battery life with this usage? I'm not sure, but I'd like to. I'll try to keep my talk time down one day, maybe this weekend, and see if I can get more than a day of battery life. I think this might be a downfall, but at the same time, the battery life isn't any worse than my RAZR, which I used only for talking, and still only managed about 1 day of use.

Reception

Simple answer. The reception is unbelievable. Better than my RAZR. Better than my KJAM. Better than my SMT5600. Even better than my old Nokia 6610, up until now, the phone with the best reception I've ever had.

Email

Real time push email is a life changer. I didn't invent the term crack-berry, but it is very fitting. The great news is that I have instant access to my email. The trouble for my personal life is that I have instant access to my email. My only complaint, and this is really just trouble with any non-QWERTY device, is that responding is a little painful. On my KJAM, I would write 15 - 20 emails a day. On this phone, that count is down to 5 or less. The T9 is great, and works surprisingly well, but it's still hunt and peck, instead of typing.

By the way, my phone is from Asia, so it has the Extra characters. Trust me, the entire phone operates in English. Without that, I've be very, very lost.

Music Player

I know the form factor has been out there for a little while, but this is my first "music phone" that I've owned, and I must say, I'm using it much more than I ever thought I would. My iPod Nano is now sitting in my drawer. I have 1GB of music loaded onto a memory card, and when I head to the gym, I only need to bring my phone with me. One device, light weight, one I always have with me, and there's my music. Another nice feature is that if I get bored with my MP3 collection, I just start streaming Sirius radio (Link), something my iPod definitely can't do.

I did notice one small issue, but this is definitely a software bug more than anything else. If you wake up the external display with the track forward or track backwards button, it doesn't always change the track. Sometimes you need to hit the play / pause button first, and then the track skips work fine. A minor issue, but a bug none the less. Another thing that got me the first time I used the music player is that when you pause the playback, that is not the same as stopping the playback. Lesson learned when my phone was battery dead at Noon. It seems that pause still chews up a ton of battery life, and you have to hold the play / pause button for a few seconds to get the playback to stop. Of course, I'm sure I'd have known this if I actually read the manual, but I'm in software, and RTFM is an acronym for users, not for technically savvy people ;).

Overall

In summary, I can't give this phone enough praise. I know it will be a big hit with the enthusiast market, and I can't image how well this will move once Cingular / T-Mobile / (Major GSM Operator) releases the phones. It has every bit of functionality that power users have been waiting for in the form factor that the RAZR proved was possible and the most convenient. I'd recommend to anyone that they NEED to pick up this phone. For any fellow / future owners, enjoy the new toy.

Here are some other published previews / reviews

• MSMobiles.com (Most comprehensive so far
  
• the::unwired
  
• the::unwired #2
  
• the::unwired - Comparison photos with other phones
  
• Mobile Whack
  
• CNet Asia
  
• Smartphone Reviews
  

---

Update (2006-06-14)

• Phone manual in English - Thanks YW

Technorati : Cell Phones, Dopod S300, HTC StarTrek, HTC StarTrk, Smartphone, WM5, Windows Mobile

SDLC in the Real World

SDLC - System Development Life Cycle (SDLC) - a methodology used to develop, maintain, and replace information systems.

I've run into more than a few project managers, developers, testers, and product managers that have caught the SDLC buzz word fever. They've either latched onto the newest, latest, coolest, hippest methodology, or they read in a book that you can't succeed without one, or (most likely) their manager said that they need to have one. However they get to this state of mind, they usually follow the same course of action.

1. 
   
2. Go to bookstore and buy 1 book
   
3. Read at least the first few chapters of said book. Some even make it all the way through
   
4. Go to their next team meeting, and declare that they are implementing an SDLC. No one else can ask questions or offer input, because the book says it will work exactly as its written
   
5. Meetings are called with subjects that mysteriously match the book's chapter headings
   
6. The rest of the team has no idea what is going on, but they are following their enlightened SDLC leader blindly. It still seems like they're writing and testing code, so at a granular level, most everything seems to be the same
   ...... The Project Continues .....
   
7. Utter chaos ensues, the product is late, the quality suffers, and it is deemed that SDLC's are worthless
   
8. Team reverts to prior process, and ships with previous efficiency, tracking, quality issues, and date slips. While that may sound bad, they still ship and shipping software is a key test of success or failure in commercial software.
   

So where does the value from using a methodology come from? For me, it all comes down to one thing: change management. If there was only one programmer, and he knew the customers, wrote the requirements, wrote the code, tested the code, fixed the code so it was bug free, packaged the product, and shipped it, there would be no need for an SDLC. OK, now back to the real world. Requirements change. Team members quit. Testers miss bugs. Developers write more bugs when they fix the bugs QA already found. Customers can't articulate what they want. The list goes on and on. This is where having a defined methodology helps. It gets your entire team on one page. When someone falters, everyone knows, and everyone understands the impact of what that means and can adapt. It is not a blame issue, but one of good communication. When you have a team driving toward a common goal, working in a common way, helping each other succeed, then you have a team with a shared vision. A team with a shared vision can do amazing things. They can have requirements change at the last minute, and everyone knows where to help, who is impacted, and how to react. The same scenario goes into effect when someone on your team leaves. Normally, the team is lost for a bit. Some piece of critical information or a critical process lived only in that person's head, and now that they are gone, the team is lost. Again, common steps, common process, common knowledge, shared vision, and teamwork. All of this leads a team to be adaptable to change, and having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software.

Having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software

Then how does all of this apply to me? I've been through a handful of projects, and I've learned the most important lesson about SDLC: No SDLC is perfect. All of those books look really good in print, but they are all based on best case scenarios and case studies. The key is to learn as much as possible, study many methodologies, and adapt a methodology to your team. I have a personal methodology that I usually try to follow, with parts taken from a few different communities, but with each new team and each new project, the process is adapted. The value of a process is to help organize your team, not to organize your team according to the process. There is always pain, resistance, and adaptation when implementing change, but it should be for the betterment of the team, not because you are trying to fit the team to something from a book.

This is the general methodology that I have used successfully in the past. It is a combination of a traditional waterfall development cycle, but focuses on short term, iterative deliverables during the development cycle. These are similar in principal to sprints from the SCRUM methodology (my personal term is protocycles), but with a different up front planning process. There are also aspects of XP and MSF woven throughout, but I won't get into that many details in this post.

1. Establish high level requirements. These need to be detailed enough that the technical design can be built from these requirements. This deliverable essentially drives the vision for the release. A 3 release roadmap is also required, so that the development team can understand what the future product plans are, with as much clarity as possible.
   
2. Define the detailed requirements. This task takes the high level release requirements, and drills down to a sufficient level of detail required for the development team. As each detailed requirement document is completed, it is sent for peer review and acceptance by a representative from development, quality assurance, architecture, product management, and development management. This task happens in parallel with the technical design.
   
3. Define the technical design (Architecture). Based on the high level requirements, establish a product architecture taking all three releases requirements into account. The architecture deliverables for version 1 should be at sufficient detail for the development team to use, and mock architectures should be vetted in order to validate feasibility for the version 2 and version 3 requirements. This task happens in parallel with defining the detailed requirements.
   
4. Product Development. The development team executes the detailed requirements and the technical architecture. This process is somewhat agile in nature, since features can be started once the specification for that component is complete, rather than waiting on an entire requirements package.
   
5. Quality Assurance. The QA team validates the software created by the development team meets the defined requirements. Test cases are created for each completed requirements document, following its peer review acceptance. For a test engineer, the requirements should read like a contract, validating that development met their end of the contract. As is typical during a development cycle, requirements will change. These will be handled as requirements addendums or modifications.
   
6. Release to Manufacturing. This is the final step in the process. Once a product is ready to be delivered to market, this step represents the processes preparing for general availability. Depending on the organization, this could include source code escrow, marketing coordination, gold CD creation, retail packaging, etc... The timing for this process is generally organizationally dependent.
   

There it is, how to ship software in 250 words or less. I'm not trying to demean what any of us do, but at the end of the day, it all sounds so simple, doesn't it? Define what you want, research it, document it, code it, test it, give it to people who will pay you for it.

Technorati : Development Management, Management, Methodology, Program Management, SDLC, Software, Software Development, Software Development Lifecycle, Software Management

Google Introduces a Spreadsheet - Competition for Microsoft

There's plenty of press about this one, but I thought Scoble had a good quote:

I want better software. Competition brings better software. It gets product managers to worry about customers. It causes discussions of features that were long-ago decided on.

If you want to see the other articles, click here.

Technorati : Reading, Software

Good Reading for Development Managers

I try to spend a few hours a week reading articles on the web. To me, the word "article" has a loose definition, but basically anything someone has taken time to put together that adds knowledge or value, I'll read if I can stumble across it. Here are this week's selections:

• All Code Has Bugs - Link - Full Article
  
• Google Hiring Strategy - Link
  
• CEO Reading List - Link
  
• Art of Recruiting - Part 1, Part 2
  

Technorati : Development Management, Management, Program Management, Reading, Software Development, Software Management

Good Reading for Software Architects

My background is in software development and architecture, so here are some good blogs that I try to read regularly.

• Martin Fowler - Enterprise Architecture
  
• Don Box - Windows Communication Framework Product Team
  
• Architect Linkblogs
  
• Tim Berners-Lee - Father of World Wide Web
  

Technorati : Reading, Software Architect, Software Development

Read RSS on your Windows Mobile Device with AvantGo

AvantGo has finally released an updated reader for Windows Mobile devices that supports RSS. Find the full story here at MSMobiles.com. Download it here.

---

Update... June 11, 2006

This link all of a sudden made it to the front page of Digg, so I'd like to respond to some of the comments.

• Good wrap up of Pocket PC RSS Clients on About.com.
• My personal recommendations for Windows Mobile 5 RSS clients
• • PocketRSS - Link
  • pRSSreader - Link (Thanks to deadhobo for the recommendation)
  • NewsGator Mobile - News - Download
  • moRSS - Link

More importantly, there has been a bunch of slamming on the Windows Mobile platform since it is from Microsoft. Most of the nay-sayers are basically saying that any product from Microsoft isn't free and sucks on principle. On the desktop platform, this is an argument that's gone on over and over again ... Linux, Mac, PC, Open Source, and I don't think it will be settled anytime soon. However, on the mobile platform, the options are more limited. If you're looking for a smartphone, it is basically Blackberry, Palm, Symbian, or Windows. Take a top of the line phone that runs on any of those platforms, and they all cost the same. The OS can't be purchased by itself, so you can argue that it's free with the hardware, or it costs the same as any other smartphone OS. Anyway, the key of this post was to highlight that there are starting to be viable offline RSS readers for the Windows Mobile 5 platform. For those who aren't as addicted to phones as I am, the OS only became commercially available in the last few months, and very few viable applications have been ported over yet.

As far as the smartphone OS debate, that's one I'd be happy to engage in, and I think these comments have given my fodder for writing an upcoming post on the topic. I've owned more phones than I can count, and I've used every single smartphone OS. I have a preference for Windows Mobile right now, but that actually has a lot more to do with form factor then with OS. As long as I can get my email, sync my calendar and contacts, and surf the web, I could care less about who wrote the OS.

Until the next post .....

Technorati : Cell Phones, Reading, Smartphone, Software, WM5, Windows Mobile

Defect Count is a Constant

One of the most inspirational people in software that I've come across is Jim McCarthy. I had the privilege of seeing him give a presentation, and he had a few quotes that made a lot of sense. The one that really stood out to me was

"Defect count is a constant."

This became very clear to me last week, as my team went through a Bug Bash. In 48 hours, we closed out over 400 defects, but the number of defects open with development stayed almost level. I could go into the details of the defects, such as priority, severity, category, and so on, and we did make some substantial progress, moving our average defect severity from critical to medium, but at the end of the day, all software has problems bugs defects. And this was one of the most difficult lessons I've ever had to learn:

Shipping software is an act of reality, not a pursuit of perfection.

This lesson was extremely difficult since I come from a development background, I always want my software to be perfect, to be bug-free. Unfortunately, the larger the project, the less control that you have over it. As a manager, your job is about steering the ship, and you have to trust that your staff is all rowing in the same direction. There are things you can do to get more involved with the low level tasks, and I recommend that you do, but at the end of the day, you can't spend 40+ hours per week with each member of your team (Trust me on the math, after 4 employees, this model doesn't scale). In the world of software management, you need to accept a product that is less than perfect, and understand what is critical to ship and what is not. I'm not saying that you should ship a garbage product, but at the end of the day, if a new feature isn't ready, you can probably cut it, ship the release, and your world will not come to an end. Note the exception list here is long, like if the feature is contractually committed, or highly marketed, or the center piece of your release, etc...

I added some links at the bottom for more information about Jim McCarthy for your reading pleasure.

Jim McCarthy - I highly recommend that anyone involved with shipping software, especially in any leadership position, should check out Jim's book and video if you can get your hands on it.

• Book
  
• Video / Signed Book
  
• Reprint of the 21 Rules - Link
  

Technorati : Development Management, Management, Program Management, SDLC, Software

The Value of Product Management

When I started out, I thought that it was critically important for each developer to know all the ins and outs of the end user. If you are writing a financial application, the developer should be able to pass for an entry level accountant. Well, then I got into healthcare, and I realized that it's impossible for developers to know anything close to what an end user knows. This is when I saw the light on the value of product management.

A great product manager will perform three tasks:

1. Drive a product's strategic road map. This means that the product manager understands the end user's needs and understands the competitive marketplace. Understands which features are competitive disadvantages, market differentiators, visionary features, and customer satisfaction issues. The road map will align these features by priority and usually group them into 3 releases. A near-term, tactical release, a longer term strategic release, and a long term visionary release. Dates on these releases are irrelevant, since the road map defines what needs to be done, and then the timeline can be wrapped around that.
   
2. Cut features from a release scope. Inevitably, customers, marketing, and product management will want more features than the development team can support in a given time frame. It falls to the product manager to work with the program manager and reduce the scope list (The entire scope planning process is another topic for another day). The product manager must balance the needs of sales, marketing, existing customers, and new customers to prioritize the list and make some tough decisions. A good product manager understands and accepts this. A tell-tale sign of a poor or inexperienced product manager is one who will kick and scream to make it all fit into the scope, rather than accept the constraints of reality.
   
3. Understand the customer's business. This is the most critical skill above anything else. A great product manager truly understands their customer. Usually, this means that they came out of the field that your product is now servicing. Maybe they were an account if you are developing accounting software, or a nurse if you are developing hospital software. This allows the product manager to converse with the customer in their vernacular, build a repore, and gain insight to new developments in the industry. The other benefit is that they become a key resource for the development team. The development team will not understand all of the intricacies of a particular business function, but the product manager should. And if they don't, they've built relationships with key customers that they can contact to get the exact answer. This allows your team to correct an issue in the design phase, rather than waiting until it is in the hands of customers, and is 10 times more costly to repair.
   

The key takeaway for anyone in development is that product managers are the ones responsible for the domain expertise, and the rest of the team should leverage and benefit from that.

Technorati : Development Management, Domain Expertise, Management, Methodology, Product Management, Program Management, SDLC, Software Development Lifecycle, Software Management

Wow, this is really cool - Stream Sirius to your phone

Listen to Sirius on your Windows Mobile phone. I've used this and it is very handy.

Read
Download

Technorati : Cell Phones, Smartphone, Software, WM5, Windows Mobile

Interesting Reads

I've added a link to my links section, but one blog that I've found very informative is Guy Kawasaki's (http://blog.guykawasaki.com). He has written a few books, and has plenty of experience in the VC space. He posts very frequently, here are a few of my favorite posts.

• Top CEO Lies - Link
• Top Engineer Lies - Link
• Top VC Lies - Link
• Scott McNealy Top 10 - Link

Technorati : Development Management, Management, Program Management, Reading, Software, Software Development, Software Management

New Cell Phone - Qtek 8500 / Dopod S300

I also have a personal hobby obsession with cell phones. From time to time, I'll post a quick piece about something cool I've found, or a new phone that I think more people should know about.

Well, I just got a new phone, the Qtek 8500 (Details). Let me just say, this phone is AWESOME! It is about the size of a RAZR (Details), but it runs Windows Mobile 5 Smartphone. This OS lets me get my email in real time, like a blackberry, keeps my calendar and contacts sync'd with my Outlook, and with a 1GB memory card makes a very convenient MP3 player. I'll be posting a mini-review a little later.

Here is a quick history of my phones, for a frame of reference:

• I-Mate KJAM (Details)
  
• I-Mate JASJAR (Details)
  
• Motorola RAZR (Details)
  
• I-Mate SP3 (Details)
  I've had a bunch of other phones, but they are older at this point and not much fun to talk about

Technorati : AKU2, Dopod S300, HTC StarTrek, HTC StarTrk, MSFP, Qtek 8500, Smartphone, WM5, Windows Mobile

How I Manage Email

One of the most frequent questions I get is how to I manage the volume of email on a daily basis. Here are a couple quick tips:

• Use Rules. I have emails that come from my management chain, product management, and my directs automatically go to a dedicated folder that I ready every day


• Filter out Work SPAM. Every company has announcements that go out via email. These are usually just reposts of what ended up on the intranet. I have all emails from these addresses automatically go to my work SPAM folder, and I never read them


• Don't read emails that are more than 3 business days old. This may sound strange, but if I don't get to an email within three days, I stop worrying about it. If it is really important, it will be resent, or I'll get a phone call about it.


• Isolate Customer Email. All customer emails should be sent to their own folder. Read these ASAP. No one is more important than the customer, and if they are taking the time to send you an email, you need to take the time to read and respond.


• Never Delete Anything. I have hundreds of emails that I've never read, but I don't delete a single one. All of my emails get archived monthly, and I use a desktop search program to make all of the information accessible. It doesn't matter which one, they all work basically the same. Just make sure that you have a record of everything you've received and everything you've sent.

I'm not advocating any particular method, and I'd be interested to know how others manage hundreds of emails a day. These are just a few tips that I follow to keep my Inbox manageable.

A Week in the Life of ...

Here is a summary of how I spent last week

Monday
Holiday

A holiday for me means that my daily email load is down from 200 to about 50. I have teams located in three countries, so there is no such thing as a true holiday for me. No major customer issues today, only a few administrative questions from me team. I'm able to answer most of these from my phone's email, and I only have to make three phone calls, 1 to each of my leads.

Tuesday
And the week begins. Today I received my typical 200 emails. Most of the requests fall into a few categories:

• Development Questions


• Question from Sales about feature set


• Question from Sales about a future feature


• Question from implementations about fixing a "bug", which really means helping them configure the system


• Questions from support that they are escalating for help from development


• Customer Issues

Of my 10 hours today, I spent 3 on the phone with customers addressing everything from product concerns, future product vision, complaints about other groups (support, implementations) that were directed to me since I was on the phone, and general issue management. I spent 2 hours with my leads between a few different meetings, going over this week's reported customer defects, upcoming installations and upgrades, and a status meeting on an upcoming release of software on our older product platform. I spent about 2 hours going through my email to read the 200+ that I received today (I'll post my theory on email some other time). Of my remaining 3 hours, I dealt with administrative issues: I checked in on some of my staff, took one guy out to lunch since he has just been killing himself and exceeding all expectations, talked with a developer who is falling behind on his development tasks and put a daily status tracking system in place that he is sending directly to me and his dev lead, and met with my QA team to address holes in our testing process, and ways to improve on this release.

Wednesday
Today was similar to yesterday, as yesterday was a fairly typical day. Spent most of my day fielding questions and phone calls that have to do with current customers, future sales, current installations, or current product problems. I got through less than 50 emails today. I also spent some time developing a high level staff allocation template to share with my peers on other products. Short day today of 8 hours, since I have to catch the red-eye tonight.

Thursday
Today and tomorrow represent what our company calls a Bug Bash. These happen a few times during the testing phase of a product development cycle, and the goal is to get the entire team, and anyone else willing to help out, to put in extra hours, eat meals in the office, and get to a predetermined goal of a resolved number of software defects.

After last night's red-eye, I'm in the office at 6:30. This is perfect since I need to prepare the tracking sheets, status conference calls, and goals for the bug bash. The goals include targets for development, QA, and the team in general. They are also broken up into today's goals, and tomorrow's goals, so that we can track better. By 8:00 AM, I have an email with an Excel attachment sent to my team, and ready for our 9:00 AM kick off call. This gives me time to run out and pick up breakfast for the team, since the catering service didn't show up (They are still coming for lunch and dinner). Our goal for this bug bash is to get from 500 outstanding defects down to 150 in the development queue, and 0 left for QA to validate. We'll be having a quick status meeting at Noon to make sure that everyone has their roadblocks out of the way, and again at 5:30, to check today's progress. Most of our team is in the office until 7, the last person leaves at 8:30, and I walk out with them.

When you're team is putting in long hours because they want to, that's one thing. When you ask them to do it, then you better be there with them, first one in the door and the last one out.

In between the coordination of my team's bug bash, I go back to my typical day's tasks of answering questions for sales, and working with implementations and support on customer issues. Today's email count: 306. Today's read email count: 42.

Friday
Second day of our Bug Bash. We have a quick status call to kick off the day again, and to celebrate the team's amazing progress on the first day. Last night, I sent an end of the day status sheet, and highlighted a few major accomplishments in the email. I intentionally copied our team's VP and CTO, hoping that one of them would respond to the group reiterating the congratulations. To my surprise, both of them did. The team reached 80% of their two day goal on day 1, reduced the QA defect queue to 0 by 6:00 PM (of course, this goes back up as development resolves more issues), and started onto our stretch goals of attacking some of the low priority defects.

Nothing gets your team motivated like knowing that their accomplishments are being announced and recognized by senior management.

As their direct manager, I am responsible for giving my team praise, but also responsible for giving criticism and keeping everyone on task. Since my team does not interact with senior management on a daily basis, seeing any of them take time out of their day to publicly acknowledge the team gives a huge morale boost that I could never give.

Unfortunately, today's bug bash is not as successful as yesterday's. Almost 100 new defects are created today, most of which focus on 1 module. The module has a very complicated set of requirements, and most of the defects relate to a misinterpretation of the requirements, but they are defects none the less. Also, the frustration of the product manager not having the developer understand the requirements affects her efficiency. I spend some time with her, understanding the defects, and then take on the task of translating them to the developer (English is his third language).

I also have a weekly management meeting today. I'm hoping today's is cancelled since I have plenty else to do, but it is not. For added fun, today we'll be discussing the new budget planning process that we need to start engaging in so that we're prepared for the budget meetings that start in July. The meeting goes almost two hours, instead of the normal 45 minutes. During the meeting, I'm taking notes, reading emails, sending emails to my team, checking our defect tracking system, responding to instant messages, and speaking to the group for a few minutes on some division wide initiatives that I'm responsible for.

At 3:00 PM, it's back to the Bug Bash. The team is starting to drag, and we have just a little further to go in order to make at least one of our goals, getting the QA backlog to 0. I call a quick pep talk / status call. On the call, we reassign the remaining defects among the entire group, and agree as a team to get these all cleared out within 60 minutes. Our configuration manager leaves the meeting early to get the latest version of code onto our QA server, and at 3:30 PM our team hits the pavement for one final sprint. By 4:15 (15 minutes early), the team is finished, we have a congratulatory call, and everyone heads home for the weekend.

Except me. Now, I need to finish my weekly tasks. Timecards, expense reports, travel itineraries, double checking reservations, checking in on my other products that are in less critical stages right now since I've ignored them for the last two days. I also have a handful of blogs that I read and I never like to fall more than a week or two behind, so I spend 30 minutes catching up on the latest news, trends, product reviews, conferences, and projects. I leave the office around 8:00 PM.

Saturday
As a rule, I try not to work weekends, but we have a customer going live this weekend, and the implementation has had its issues. I have a status call with the on site team at 10AM, and make myself the key contact if anything needs to be escalated to development. Typically, they would contact my dev lead directly, but he just put in some serious hours with the bug bash, and he's actually in the office still working on defects. I'll try to absorb as much as possible, and only defer when I have to.

Only one phone call today, so basically an easy day.

My Background

It probably makes sense to start out by introducing myself and my background

Resume Paragraph:
I have over 13 years of software development experience, ranging from custom development, enterprise development, enterprise application integration (EAI), ASP commercial software, packaged commercial software, architecture (software, enterprise, and infrastructure), SDLC (RUP, XP, Agile, SCRUM, MSF), and project management. I have held varying levels of leadership and management positions of groups sized between 5 and 40, and been responsible for communications at al levels within and outside the organization, including staff, executives, and board members.

How I got here...

• Owned my own custom software development company for 6 years. This is where I got my start, made a tone of mistakes, and learned the value of customer service above anything else. If you've never interacted with your end user on a regular basis, you need to. It will be an very humbling, eyeopening experience


• Fell into a very lucky opportunity and joined a global Fortune 100 company to help through ERP customization, Y2K readiness, CRM Global Installation, and lead a custom development and data warehousing team. This position lasted 2.5 years.


• Then I moved on to a commercial software company focused on all sectors of the health care market, providing both packaged and ASP software. First, I ran a team that developed real time data extract and portable data warehouse product to the pharmaceutical industry. After the success of that project, I received my second lucky break. I was selected to run a new initiative for the company from the ground up. I hired the team, architected the product, and managed the relationships with key partners and customers. This position lasted 2.5 years


• After that, I moved into my current position. Now, I am responsible for the strategy, development, and support of one of my company's products. We have two different generations of products, so I manage two teams, each consisting of anaylsts, developers, and testers. My company does have a separate product management organization, and there are two product managers dedicated to my product (I'll post about this later, but never agree to anything with an industry specific product unless you have dedicated product management with experience in that industry). Current tenure 1.5 years and counting

Current Technologies:

• Microsoft .NET Framework (C#, VB.Net)


• Java (J2SE, J2EE, Tomcat, Weblogic)


• SQL Server (4.2, 6.0, 6.5, 7, 2000, 2005)


• Oracle (7.1.3, 8i, 9i, 10g)


• Data Warehousing


• Enterprise Architecture

I won't pretend that I've earned my positions based solely on merit. While I do think I am very qualified for my position, and I've been successful in my previous positions, I did receive a couple lucky breaks. Everyone gets a few chances presented to them during their career, but it is a matter of timing and execution to make the most of those opportunities. The other key that has opened several doors for me is that I have a strong set of soft skills. This is especially key for engineers, and is one of the easiest ways to set yourself apart from the rest of the pack. Anyone who understands the technology behind a software solution, this could mean an analyst, developer, or tester, and this person can effectively communicate (written and verbal), concisely summarize technical information, and understand the relationship between technical and non-technical information has a very bright future ahead of them. The last key attribute, and this might be the most important, is the ability to inspire others. People talk about leadership, courage, and confidence, and there are shelves of books at Barnes and Noble discussing these ad-nauseum, but I believe that it all comes down to one attribute that makes the difference between successful and unsuccessful leaders. If you can inspire others, push them to do more than they thought they were capable of, make them believe in a common cause, make them want to help the team succeed, then you've got it. I don't think this is a skill that can be learned. It can certainly be honed, trained, perfected, but not learned. And you don't need to have a management position to start inspiring others, it just happens naturally. Do you notice that your peers come to you for answers? Are you usually the one persuading a group in a planning or design meeting? Do you find yourself worrying about how your peers are doing on their tasks, and want to help them to finish on time or overcome a difficult challenge? If so, then you probably have it.

Well, enough preaching for now, I know I tangent a great deal, but as I create more posts, they will be more and more focused.

Introduction to this blog....

I currently manage a commercial software product, and one of the most frequent questions that I get from both my staff and staff on other product teams is "How do I move into management?" I've been answering this question for a few years, and have decided to start a blog so that I can answer these same questions for more people than those that I interact with at work. Not only would I be happy to answer questions through comments or email, but I'd also be interested if there are any other program managers who would also be interested in posting.

The answer I always provide in one form or another to developers / testers / analysts looking to move into management is always the same, and always in the form of another question. "Do you know what management is like day to day?" That's the question that I plan to address with this blog, but not only answering questions and going into my background and how I got to where I am, but to chronicle the day to day activities. I find that it is critical for people to understand what a move into management truly entails, and that they are motivated and ambitious for the right reasons. Generally speaking, the motivation that the only way to make more money is to move into management does not really apply to software, and the same concept is spreading to more and more knowledge based industries. Companies are learning that talent comes in many forms, management being no more or less of a skill than a deep technical expertise.

I've been thinking about this blog for a while now, so I have some pre-planned entries that I'll post in the days to come...