>>>I see this myself at some of my small business clients with whom I've worked for years, and know well. Sometimes the owner will ask my opinion about some aspect of their business *completely* unrelated to IT, because they feel a need for an outsider's take.
>>>
>>>One thing I'd be wary of is labeling people "business stiffs" and "geeks". Fellow geeks are fun to work with, but you've got to keep touch with how you add value, and fundamentally you can only do that by working with the business people. It pays to be the "big-picture" guy in a group of geeks.
>>
>>Actually, I think it's part of our job to learn how a business works - how else does one write code for bizobjects :). You need to understand the thing before you can code it well. Doesn't mean you can't start right away, but you'll have to learn how it breathes. Sooner or later, going from project to project, we gain some insight into things in general. That may be at intuitive level (I know but can't explain) or just at verbal level (I can talk about it but don't act on it), but most of the time we just see how things work, or can make an educated guess, ask the right questions and, yes, sometimes have that outsider's look into our own affairs.
>
>I agree completely if we're building or talking about business software; a lot of Fox developers work in that space so it's very natural. I get nervous if I can't see the big picture - if someone gives me a very narrow spec or task and isn't able or willing to discuss how that fits into the business as a whole. I find it more interesting and satisfying to see the big picture.
>
>In larger companies you sometimes see people labeled as "business analysts". Often, their job is to analyze the business (no surprise there), and develop software specs. These specs are then handed off to programmers who actually write the code. With a division of labour like that, it's not an absolute requirement that the programmers have any real grasp of the realities of the business. They can just be code monkeys.
>
>Foxers tend to work in smaller shops where the business analyst and programmer roles are combined - we call ourselves "developers".
>
>One thing that good managers do, and subordinates really appreciate, is shield them from cr*p raining down from above. The more specialized the subordinate/code monkey, the more important it is to let them concentrate on what they do well. OTOH, the more specialized you are as an employee, the more important it is that you be aware of, and be able to articulate, your value to the organization. So, there's something of a conflict there.
>
>A lot of techies have no interest in business or management, and rightfully so, IMO. But, most people still have to make a living. As a bare minimum I believe any employee should know enough about their company's operations to be able to predict the chances of their own layoff. Maybe even more importantly, they should be able to identify opportunities for promotion, new learning, extra responsibilities etc. - whatever matches their desired mix of management and tech - so they can increase the value they add, their job satisfaction, and hopefully $$$.

One of the great ironies of software development as a line of work is that the skills to be a good developer and the skills to be a good manager are so different. Yet what do corporate IT departments often do with the developers in their shop who excel? "Promote" them to manager! It would almost be funny if so many people didn't wind up reporting to managers who are in jobs they are unsuited for.

That happened to me personally, actually. I got a series of promotions and was a VP before finally realizing how little I enjoyed it and that I was a much better developer than manager. In terms of peace of mind I have never regretted returning to the dark side ;-)

Some good techies do turn out to be good managers. But they are in the minority IMO. Completely different skill set.