Fog Creek Software
Discussion Board

Am i choosing the ladder or the Snake ?

Recently my company is making major restructuring plans, primary decision done for the development department is that every developer will have 2 different career paths (reason being too many team leaders and legacy people issues).
1. Management ladder: Responsibilities on this ladder include Team Monument, Scheduling, Code reviews, Testing, Mentoring, Test case preparation and Development 
2. Technical ladder: Responsibilities on this ladder Architecting, Designing (Preparing technical design documents) and Research activities, (may be a bit of team management and tracking for few top guys).

I’m really in a tricky position as I’m unable to decide on which path to choose (i'm inclined on the technical ladder as of now), even before the decision; the article    scares me by saying:
A common mistake in department-centered organizations is to break software architects into a separate department or group. This can lead to elitism, which is counterproductive for the following reasons:
•    It separates the architects from the developers who do the actual implementation. Architects quickly become out of touch with the latest development methodologies being used.
•    While not every developer wants to be an architect, every developer likes to have some say in the design. If developers are separated from architects, the developers may have a built-in incentive to prove that the architect's design was wrong, by not working their hardest to implement it. When this happens, the architect will most likely blame the problem on developer incompetence rather than any architectural flaws. The whole iterative development process becomes harder to implement smoothly.
Looking forward for suggestions

Thursday, September 11, 2003

Great Architects are not Gods, but bad ones do make life hell.

An architect need to lay out a design and plan and then be able to articulate it to the business people, who will eventually fund the design. 

They need to understand the technology and they MUST MUST MUST realize they don't know everything.  Architects who do not accept input from the team are limited in value.  Architects that believe they know what's best are dangerous.

BAFH (Bastard Architect From Hell) come from companies that believe it is just the "next step in the promotion chain"  Are they the "best" coder?  Yes -- then they must be great architects.  In engineering this would be like saying "can they remodel bathrooms?  Yes -- then they must be able to build stadiums"

Thursday, September 11, 2003


Choose the management ladder unless you are absolutely certain that the technical ladder will keep you current with commercially valuable skills for the forseeable future.

If you go technical and don't, or can't, or aren't allowed to keep up to date with marketable software skills, then you could find yourself in a real bind when the next reorganisation comes round (believe me, they always do), particularly as you get older/more experienced/ more expensive. Management skills, on the other hand, are more generic and transferable to different companies and disciplines.

David Roper
Thursday, September 11, 2003

Recent Development out here is that they are going to create a team just for research with the *cream of the crop* (damn), which means that only option which they provided in the technical ladder to keep updated with the latest technology is also lost.

David, as you said I might have to stick to the management ladder, but again, damn I’m tired and sick of MS project, Re-scheduling rather than Scheduling, killing hell a lot of time in directionless dillydallying meetings and daily/weekly status reports.

I was wondering does the skill in design add some value to my career or only the flashy latest of the latest technology like .net, java things matter to other company

OT: 2 MSHack: My outlook signature reads “The utmost extent of man's knowledge is to know that he knows nothing.”

Thursday, September 11, 2003

It is a false dichotomy.  Take control of your own career by determing your long term goals and then what steps you need to take to get there.

Then if neither one of the choices (including the environment!) presented by your current employer are what you need to accomplish your goals, take the appropriate action.

Thursday, September 11, 2003

If you arent' a software development house but instead an IS department then I'd strongly suggest going into the management track as its much more open and you can move farther and faster.

We have the same two tracks here... technical and managerial.  Now our technical people do get called in to be leads on smaller projects, but our management people always get the interesting ones.

And I can say this, your team will love you if you actually understand most of the technology and you're a manager.  That dualism just doesn't exist most times.

Thursday, September 11, 2003

When I was a newby at AT&T (and later, Bell Labs), I was faced with the same choice. The technical ladder went up to "Distinguished Engineer" and the managerial ladder went up to "CEO". I really admired the "Distinguished" title, but since it was equivalent to a manager spot, I doubted its long-term viability.

Eventually, I worked my way up the food chain and became a manager. The funny thing is that once I got there, I hated it (meetings all day long, etc.). So, I waited for the right opportunity and made a lateral move over to a "Distinguished Engineer" position (BTW, most of this happened at other companies with similar career tracks).

Since that time, I have found that it's equally beneficial to have experience from both tracks. It's also important to know what you want out of life and what makes you happy, especially in the long run. I enjoy managing/leading and I also enjoy designing/building/fixing. I think I have enough experience to do either well and have given up on the CEO dreams for now :-).

Thursday, September 11, 2003

Go management.

Prove your worth by attacking the status quo, and getting rid of all current non-value-adding activity (read pointless meetings).

Learn to manage projects.
Learn to compromise and prioritise.
Learn to manage people.

These are skills that you will need/use in any job you will walk to in the future.

One more reason to go this way is that if you are going to be expected to mentor the juniors, you can't be too removed from the tech side of things.

On a more cynical note, the fact that you are their mentor means that you can endear them to you and your way of thinking .... read Napoleon and the puppies in Animal Farm.

Thursday, September 11, 2003


what was the name of original article, from ?

Thursday, September 11, 2003

2 Dreamcatcher:  original article name

"Organizing for Successful Software Development"

Looks like clicking on the link mentioned does not work please cut and paste the link.

Thanks to all for the nice advice, I think as scot and others suggest I need to Ink down my long term goals and then decide.

Also I need to suggest about the lateral movement to my management so that there is good an exit option from each career paths.

Well, one another other thing I learnt is that on the technical career path the moving up is lot slower and can't get too far.

Am I confused or well mixed

Thursday, September 11, 2003

Like one other person said, it depends on what your long term goals are and what type of shop you are in.

If it's a shop where software is a P&L center, I would stay on the technical track, otherwise I'd opt for management.

Thursday, September 11, 2003

Can't agree more that you don't want to distinguish between "Developers" and "Architects".  That means you're hiring people you think know their stuff, and others that don't.

Instead of hiring two Architects and ten Developers, you're probably better off hiring four Architects and having them all architect and write code.  You'll get more total productivity.  In my experience, if you have a Developer you don't trust to be an Architect, an Architect will probably need to go back in and refactor their code anyway.

If you have bright but inexperienced coders, team them up with an Architect and do something like pair programming for a while.

Jim Rankin
Thursday, September 11, 2003

Some shop's Architects are another shop's Senior Developers or Team Leads or Programmers.  Can't really say anything substantial based off of title alone.

The point is what did you accomplish?  Did you ship?  What role did you play in the shipping? 

I'll take some guy that calls himself a 'programmer' that happens to be able to ship a lot of software over an 'architect' that mainly produces a lot of funny shaped drawings. 

Thursday, September 11, 2003

"Hire four Architects and have them all code"

I knew this would happen. 'Architect' has become the new word for 'Brickie Coder'.

I guess the level above Architect is now Director. But it won't last. In a couple years, coding teams will be comprised of teams of seven "Directors", all coding from spec.

Dennis Atkins
Thursday, September 11, 2003

And making $7/hr.

Really the only way to tell if you are a code monkey or not is by looking at your salary stubs.

Dennis Atkins
Thursday, September 11, 2003

All this talk of the meaning of architects...
Check out
It gave me something to think about...

Thursday, September 11, 2003

*  Recent Topics

*  Fog Creek Home