Avoiding "ownership" of particular areas, both within the technical side and between the technical and business sides, may help. For smart people, it's frustrating getting stuck in one area and being told not to work on something interesting that's considered outside of one's field or expertise.

In particular, you might let the more senior folks start to contribute more to the business side of the company. Being involved in that adds meaning to software one's working on, and you may also find it benefits the company significantly because the developers will have a much better grasp of the cost/benefit tradeoffs of particular technical decisions (once they learn the business side) than the business folks will.

Looking through the agile development, particularly Extreme Programming, literature may produce some ideas, since that tends towards avoiding compartmentalization, at least within the technical domain.

This sort of thing was in fact why I ended up starting my own company. Doing something like using Haskell instead of Java for a major project is for me as much an economic decision as a technical one: I've found sufficient evidence to convince me that it's a worthwhile business risk, because it has the capability to put me ahead of my competition. But that's a business decision that someone non-technical is probably not capable of making, and thus it was never going to fly in most companies. (Notable successes in this area, such as Jane Street ^[1], have very strong technical skills in their upper management.)

I'm looking for an answer to this myself! It sounds as though you and I are in very similar positions!

The most important thing I have found so far is to listen to them -- they all want something a little different, and what doesn't seem like a big deal to you might be very important to another individual.

The whole problem is very hard -- you want to give everyone something to keep them fulfilled, but there might be limited opportunities to do so.

One thing that I've learned is that every person responds a little differently. In some cases, it made sense to expand someone's role or responsibility. As we got bigger, my own responsibilities increased in volume, and it was hard to keep them all in balance. The need to have people to help out created growth opportunities within the team.

As has been mentioned above, conferences and training can be a big factor -- since you don't have 100 mouths to feed, it can be much more practical to try to send developers to conferences such as TechEd, the PDC, etc. These are great because your devs will love them, and those conferences directly impact your company's ability to stay sharp technically. They have been worth every penny.

Is working from home an option? As a small software company, we don't have a lot of red tape to deal with, and we are able to be flexible when life makes it easier to work from home. This will be a bigger deal as your employees age. When we started, we were all young and single, and it wasn't a big deal. today, those same developers (and new ones) have kids that get sick, they have to be home when repair work is being done, etc. The whole demographic of developers is changing.

Can you provide some degree of responsibility rotation? This one is tough, and it doesn't work for all developers. However, sometimes you will get a person who feels they are at a dead-end because of the project that they are working on. On the one hand, it's often most efficient to keep them on that project/product, because they have the domain knowledge. On the other, you have to weigh that against the cost of losing them completely if they grow tired of their responsibilities. (others prefer to work in their comfort zone, so this really depends upon the person). I don't know if I would call it "rotation" so much as "migration". there are some costs in doing this -- more processes and design must be written down, cross-training is required, etc. But those very processes will make the company more effective and better able to cope with a lost employee. For the employee doing the crosstraining: if they do a good job of it, they are better poised to take on the next New Thing and not be boat-anchored to an older product.

I think your best resource for ideas on how to do this are the people giving the feedback. Ask them what it would look like for them to take on additional challenges. One idea would be to take an idea from Google and give them 10% time to work on independent projects that spark their curiosity. I think people learn alot from this type of work that could siginificantly improve their productivity in their remaining time and, potentially, result in new products for your company.

I can tell you that you're not alone in your quest to develop a technical career path. I've been with two large technical consulting firms (20K employees+) who struggled with the same thing.

You've got a lot of good answers already but I figured I'd still give you my 2 cents:

"new and exciting" & "routine and maintenance" are very tricky. There happens to be a lot of money in sustainment and anyone who has worked for a big firm will tell you that a lot of the work isn't new or exciting. Someone at Google might be an exception. So something you may wish to do is let your employees know that you're on the look out for more exciting or involving work but the company still has to make money, especially in this economic climate, and you can't be expected to pass over work because it's "routine".

You may want to look at setting up one of more career paths which define the position's responsibilities and what it takes to reach that level or the next level. You may want to have a path that branches at a certain position with one path going more technical and one into business development. This would allow experienced and senior team members to do more client facing work and see a "new and exciting" part of the business. As individuals venture further into the business development path their technical roles would diminish.

Clearly defining what it takes to go from Position A to Position B is extremely important. I can't tell you how frustrating it is when transition seems to be dependent on a superior's personal judgment. Have quantitative and obtainable goals that are reasonable for that level of experience and skill set are extremely important.

Sr. Developer: Obtain 2 technical certifications. Complete 40 hours of training annually.

Asst. Technical Architect: Author or contribute to at least 4 white papers. Obtain an additional technical certification. Complete 40 hours of training annually. Provide mentoring for junior team members.

Business Adviser: Prepare or contribute to one proposal. Participate in client meetings. Manage one project from proposal to delivery. Complete writing, presentation, or speaking training.

                   Jr. Developer
                       |
                   Sr. Developer
                       |
             Asst. Technical Architect
                    /     \
    Technical Architect  Business Adviser
              |                  |
 Sr. Technical Architect  Sr. Business Adviser

Education is something I always look for in a company and I'm not suggesting tuition reimbursement but access to conferences and training as long as it supports current or potential work efforts.

Also, it's important to remember to include goals and tasks that support team work and participation. As employees climb the ladder they should have a portion of their time dedicated to billable work, training, management/peer activities, and business development. The ratios of these would be dependent on position obviously.

If you're interested in more information let me know and I'd be glad to tell you more about my experiences with technical career paths, what worked and what didn't work.

Hope this helps!

Well, we are a small company also with 4 developers including myself. I am the lead of the department and I also have exactly the same problem. Some of the things I am trying to do include:

1. I don't take ownership of produced code
2. I go one step further and whenever I have the opportunity I promote the work of every developer to the management and at the same time I inform my fellow programmers the fact that I did that
3. I try to create the best environment for a programmer. That way everyone has a higher tolerance when we need to do maintenance work for a long period.
4. I encourage developers to spend time on their ideas and on improving existing code
5. I encourage developers to handle their projects on their own without me filtering out the communications. That way they feel they have an advanced role in the project. For example they talk directly with the stakeholders.
6. I give them more responsibilities and try not to micromanage.

Some of the things I want to do:

1. Have once a week presentations from every developer on subjects they really like.
2. Have them present to the rest of the team some smart code they wrote during the week.
3. Create a system like SO for internal use, where developers earn reputation and badges and this system is visible to the whole company. The result is satisfied developers because their value is communicated.

Not exactly a career path, but...

If you can, start treating releases or presales preparations as individual 'projects'. Let the developers rotate on & off these projects. Have them function as lead/coordinator for the project, development lead, manager etc in rotation.

My company assigns one of the developers as a "release coordinator" - it's part of their job (and they have the time and authority needed) to coordinate & schedule all activities related to the release.

I've been through this at my last two employers. Where I work now sounds similar to your company - just over 50 people, 9 developers - and every developer who's had the chance liked it.

Maybe try a variation on Google's "do your own thing 20% of the time". Get ideas from the developers as to what they might like to do, that still pertains to your business. Then let them pursue those ideas for a half-day (10%) or even a couple half days (20%) a week, other issues permitting. Try to give them as much leeway as possible when it comes to technology to be used and such.

You can't satisfy the old timers' wishes (by promoting them above the other programmers) without making the others less happy (by putting their peers above them), so I think you're better off looking for some other way to make them happy.

Better pay? A spiffier job title that reflects their real expertise? Flexi hours. A "senior developer" title that really doesn't imply management?

Help fund the cost for new training, conferences, seminars, etc. You could even implement a tuition reimbursement program so that your developers can go back to school (if necessary), get a degree, or complete a masters program.

Do you have some management hierarchy in your development team? You can let 2 or 3 experienced developers to become team leaders, if the leadership and management skills are the ones that they would like to develop.

If you have an experienced developer who isn't interested in team leader role, but is interested in professional development - he can grow to become a technology specialist (possibly shifting to work with the CTO of your company). You can define that an important part of his job specification will be looking for new technologies, ideas, improvements, etc.

That's really tricky - we struggle with the exact same thing. I think the key here is to first determine what kind of career path your individual developers are interested in. Are some of them interested in helping out with sales? Are some of them interested in project management or product management? Are some of them capable of leading development teams? Do you have developers who really shine when developing new code and the architecture of your applications, or developers who really shine at interfacing with your users and finding and fixing their problems?

More importantly - are the developers who want to go these path particularly talented therein?

In the end, I think you're probably better served trying to work with developers and link up where they want to go career-wise with the value that they can deliver to your company. There are going to be problems going through this path - this entire discussion is, after all, intricately linked to issues of status and money (even if everyone insists its not).

The simple alternative would be to just throw together some sort of job titles that establish some sort of fixed hierarchy - but I think you'd be poorly served by this. You don't need hierarchy, you need talent development.

I think the answer has to lie in where the developer would like to see their skills develop, not everyone is interested in going in the same direction. Some developers may be more interested in systems administration, some in project management or various other areas. I think the solution is to sit down with each developer, map where they would like to progress and allow the to 'shadow' someone with those skills in the organisation.

This means that domain specific skills get shared around, individuals get a sense of personal growth and the business has mutiple people who can cover similar tasks.

Do you fund and provide paid time for activities outside of work that encourage groth? Examples:

1) Pay for employees to take college classes?

2) Encourage employees to attend conferences where they present sessions?

3) Spend some paid time doing work for approved not for profits?

What about paying for their additional training courses maybe in the area of soft skills?

Or some other field they could be interested in?

For exampe, a web developer could be interested in a serious graphical design course...

I think that, like every developer, they love to learn, so give them books, ask them to pass certifications (very useful because it keeps you motivated to reach a concrete goal)in what they would like to work or what they would like to learn.

I have worked in large and small companies. The key to keeping people at small companies is to keep the workplace interesting and involve staff in planning as much as possible. In a large company most people are happy to accept that the bosses decide everything (even if they grumble privately) but in a small company small mistakes can change their work environment or put them out in the street.

The easiest way to keep on top of things is to organise regular outings and Friday drinks (you don't have to pay for everything, just make sure there's beer). A bit of time away from work but among colleagues builds bonds which are harder to break. Furthermore you're more likely to hear about issues that are bothering people.

Your staff know that there are less opportunities for financial growth at a small firm. If they came in the first place and stayed as long as they did then it probably isn't just the money or the work but the community they are there for. You have to keep that community healthy and happy to keep the staff.

Finally the pull towards big companies in IT is usually about getting to play with better toys. Be prepared to spend a little on fancy gadgets (cisco's for the net guys, new macs for the artists, etc...). My boss got me a 30" screen and I've been happy as punch ever since. A raise would have cost him more but I think the screen has given me more satisfaction (I'm more of a cautious spender myself). Toys have a similar effect, leave soft rubber balls, "bullshit buttons" and other interesting and geeky gizmos around the office that a large company would never tolerate. This gives the feeling of having a better workplace than some large stuffy corporation.

This is a very interesting question. The company I work for is much smaller than it appears from the outside. I can quickly see that the career path at this company is title-based. Employees get promoted to a new title, but there aren't really any new responsibilities for them. I think that is the wrong way to go about it.

I would agree with trying the Google approach to development, where employees are given an X percentage of time each week for personal projects. It is a good way to allow employees to continue to gain knowledge in new areas, while maintaining the current applications. I know I would like this.

Another thing you could do is create some architect positions. Your employees that have been there from the beginning should have a good grasp of the application and could help guide the product into the future.