Thursday, August 16, 2007

My Dream Job (What's Yours?)

Around 10 years ago, I was working with Microsoft's DirectX technology. As Microsoft was an important partner (as they are for everybody it seems), I attended the Microsoft DirectX Conference following CGDC. I was introduced to my dream job at that point. This person was the DirectX Evangelist. Later on, I briefly met this individual in Redmond at a campus visit, and that cemented my desire.

What brought this to mind was a job listing I saw recently. Like most technologists, I spend time running around the Internet looking at what other options are available. A notable large organization has a position open as their OSS Evangelist. This got me reminiscing about that DirectX Evangelist and dream jobs.


Being a champion for a technology would be awesome. Needing to be highly technical to champion the technologies to other technologists while remaining human to the non-technologists is hard; hard is fun. It is like when I would "act" in the high school plays: a little stage fright, a few jitters, and then doing some improv when I forgot my lines.

I guess I'm the weird technologist. I actually like interacting with people. Go figure. I also recognize not everybody is like me, so, to the point.

The real issue is getting from the ranks of Everyman and into a position that you love. As one's "love" changes over time, it is important to be constantly working towards it. Take opportunities to grow, even if you don't think you'll need it now. Present at a conference; take a product management class (great for software developers!); find somebody in another organization and become "job buddies" and teach each other about your jobs.

I once looked at the resume of a guy who had literally spent 10 years working on the dialogs in a word processor. He had not pushed himself at all, and, not surprisingly, we did not even consider him for the position. Even today, a good friend I worked with there and I still joke about it.

Don't be the Dialog Guy! If you can't find a way out of being the Dialog Guy at the company (and, truly, you should be able to), change jobs. Keep learning new things. Stay passionate. Again, don't be afraid to change jobs to get closer to your passion.

And, yes, I did apply for the OSS Evangelist job.

Development Management in Large and Small Organizations

In an Agile world, what is the responsibility of the Development Manager? The answer, not surprisingly, depends on the organization. In some respects, their responsibilities are the same: ensuring individual growth, managing conflict, etc. As there are numerous books on that, I won't address it here.

On the other hand, the responsibilities do change between a small organization and a large organization. It is important to understand the difference because the personality that will thrive in a small company dev manager role will suffocate in a large company. Conversely, a personality that would thrive in a large company may flounder in a small company.

Large Organizations

I don't want to use the word politics. The negative connotations associated with that don't help get the job done. But what is the job?

Communication. And communication. And more communication. Nobody makes command decisions in a large organization, so accomplishing anything requires communicating with others. Communicating status, assisting others in communicating their needs for you, interacting with others to meet the people you need to know, and then communicate some more.

Once you've done all your communication, do it some more.

Once you've done it some more, you are ready to begin moving roadblocks in front of your staff. And this is your job! You are the silent tow truck, strongly letting noodles think they are moving themselves, unaware that you are pulling them where you want them to go. As your developers run across problems, you need to use your communication skills to find ways around them. Find the people you've interacted with and help them understand how they can help you and how you can help them.

Small Organizations

In a small organization, the primary need is to know the customer. That will provide you the foundation to understand everything else in job.

You need to understand your product. You need to have an understanding of what you are building and why you are building it. To have a very productive team, you need to be in a position to answer developer's specific questions about requirements. You don't answer what should be built but you need to be able to answer questions about how to build it.

More specifically, the dev manager is the multitasker. Obviously, communication is still important, but you are now a key stone in getting things done. Product owners will not have the time to get you everything you need. Customers will have questions that services (if it exists) will not be able to answer. There will be 10 times the work to be done than you could ever hope to do. And everybody is going to look to you for the answers.

Both jobs are challenging. Different people will excel at one more than another. As you look at moving from one organization to another, there will be a lot of things going through your mind about pros and cons. Make sure this is one of them.

Thursday, August 9, 2007

Reducing Maintenance Costs


I saw this one over at the Geekend Blog and had to share. I guarantee, if everybody (including, but not limited to developers) worked with this mindset, maintenance would be MUCH cheaper!

Saturday, August 4, 2007

Building Great Teams

I admit I am not an expert on this topic. I have not built dozens of teams, picking and choosing individuals for their individual merits, capabilities, and personality types. I have not read dozens of psychology texts on interpersonal interactions.

On the other hand, I have been on teams that have worked amazingly well and that have failed miserably. Based on that experience, I have identified the key success factors in building great teams.

I recently changed jobs and left the best team I had ever worked with. The team was the single strongest motivator I had to stay at the job, and to this day I still get together regularly with most of the team. I was managing the team, but I don't take credit for them being the exceptional team they turned into. In fact, I was traveling a lot, and I think that actually helped in strengthening the team.

Here are the success factors in building a great team:

Believe in the Product - Work for the Customer

I do not believe that it is possible for a team to become great if they don't truly believe in what they are doing. This is one of the areas that I think I was able to influence my team, because I believed in the product and I did everything I could to pass that on to the team. I spent time with customers, my team spent time with customers, we worked closely with product management, sales, and services to understand the customers. We knew that our product could make our customers' lives better.

To that end, we were all working towards a single goal of making our customers' lives better. Many times, there are ulterior motives driving people: wanting to look good for the boss, strengthening one's resume, etc. My goal was to make the customers, their needs, and how our product addressed those needs real for the team, and, in the process, all of the ulterior motives disappeared.

Self-Direction

My team didn't have a choice, as I was out of the office a great deal of the time. In many cases, teams can begin to wander aimlessly in those circumstances, but a great team will not have that problem. The key is the customer focus mentioned above. While there may be occasional disputes on what is best for the customer (especially when the customer isn't always in the work room as Agile methods would like), those disputes are healthy and usually result in a better product (provided decision making is accounted for as mentioned below).

Agile methods promote the self-direction of teams for many reasons, but in my opinion, the greatest benefit of this is teams become closer. People have to learn to interact and disagree with others amicably. People don't always worry about themselves and their needs. They begin propping others up, instead of mentally tearing them down. Work starts to happen as a team instead of a group of individuals.

Leadership

Leadership is important, but not in the way many people think. As the manager, I had leadership responsibilities. As technology specialists, some of the engineers had leadership responsibilities. The reality is that everybody had some leadership responsibilities.

Rather than a top-down leadership style, a great team will come together with everybody leading in various ways and at various times. More importantly, a great team will not have members who place themselves above other members. Every member realizes that every other member has strengths and weaknesses, and by bringing those together, the team and the product become better for it.

The true leadership in great teams is helping people overcome their shortcomings and increasing their capabilities.

Decision Making

Self-directing teams that are completely focused on the customer...there should be no need to have a final decision maker, right? Wrong. Occasionally, there will be disputes about the best way to accomplish something. If left unchecked, these disputes can cause wedges that will eventually break a team apart.

On features, the final decision is the job of the customer. That may be the actual customer, the product manager, or some other person who is THE designated customer proxy. Technology is a tougher issue, because people get religious about technology and customers are often unable to make those decisions.

It is critical that somebody be designated as the decision maker for those decisions. Typically this person is designated the "architect", but the title isn't important. What is important is that she is trusted by the other members of the team to make sounds technical decisions and to do so with the customer's best interests in mind.

Team Size

Keep teams small. If you have a large group, break them down smaller. Agile methods encourage this for a reason. The smaller the groups, the easier it is for people to grow together and teams to become stronger. If you have to break groups apart, pick representatives of each of the groups and let them come together in a group of their own. Great groups are rarely larger than eight or 10 people.

There is obviously much more that could be said about how to build great teams. However, I strongly believe these five items are the most important predictors of success. Cultivate these, and your teams will become stronger; starve these, and your teams will become brittle.

To the team I worked with from around 2002 through 2006, thank you for giving me an amazing opportunity to see what a team can be.

Friday, August 3, 2007

Agile: More Cost Efficient

Now that we've talked about how we got into the bad habits of waterfall processes, let's switch gears and talk about why Agile methods should be embraced within the organization.

Software is expensive. It is a significant investment, and, as with any investment, there is an expectation of a return. In the IT world, the expectation for the return is based on reduced business costs, improved business function, or some other measurable benefit. In the product world, the expectation is that the return will, in some way, generate additional revenue. In any case, if the return is less than the return on a savings account, then the company is better off banking the money.

Am I arguing to not create software? Definitely not. However, I am arguing that thought needs to happen on how to maximize the return. I'll discuss three aspects of that: the costs of quality, the problems of over-engineering, and the pain of failure.

Quality

The costs of fixing an error in a software project increases non-linearly over time. These are real costs in terms of resolution time and schedule slippage. The worst case is an error found by a customer, which costs the most, affects new product development, and impacts brand reputation.

Waterfall methods have quality scheduled in, but is not a core to the methodology. Worse, testing is back-loaded on the project, significantly increasing the cost involved to fix a defect.

Agile methods, on the other hand, have a very strong quality focus and testing is front-loaded on the project. By front-loading testing, defects are easier to find and easier to fix, with significantly less cost.

Over-Engineering

Studies have shown that nearly half of features developed are never used. Another fifth of the features are seldom used. Each of these features increases the cost and risk of the product without providing any additional value.

Waterfall methods try to pull together all the requirements up front. Because of the challenge of prioritizing all of the requirements, I've often seen prioritization happening at the feature or use-case level. This means that if a use case has three scenarios, A, B, and C, and only A is high priority, all three scenarios will be implemented, even though B and C are not important.

Agile methods encourage building only what you know you need as you know you need it. Rather than implement A, B, and C, Agile methods encourage working with the customer at the time of implementation to determine that you only need to build A. B and C are not implemented, so the costs are not incurred from a development and testing perspective.

Failure

Failure encompasses two problems: outright project death and projects that become significantly challenged through cost and schedule overrun, poor quality, or developed software not meeting the customer's needs. As software complexity increases, likelihood of failure also increases, reaching as high as three-fourths of projects failing.

As complexity has significant correlation with failure, anything that can be done to reduce the complexity also reduced likelihood of failure. This is one of the great benefits of Agile methods.

I am reminded of the epigram (which is way overused), "How do you eat an elephant?" Answer, "One bite at a time." Agile methods help all aspects of the project to be carved up, from requirements through testing.

This covers the software cost issues at a very high level. In my next installment, I will talk about the suitability of a software project to a given need, problems waterfall methods introduce with that, and how Agile methods shine in solving that problem.