FAQ 3.03 Why are the managers in charge rather than the developers who understand technology?
Managers are supposed to understand the goals of the organization and to ensure that the goals are achieved, often using technology in one form or another. Their job is to represent the organization, and in many cases they have a fiduciary responsibility (and personal liability) if things go wrong. In their view, developers are transient and are often more interested in technology than the welfare of the organization. This may or may not be true, and the average tenure of CIOs is probably shorter than the average tenure of developers, but what's important is the perception, not the reality.
The message is that developers can increase their influence in the organization by demonstrating that they understand the organization's business objectives and that they are committed to achieving the business objectives rather than being committed to playing around with the coolest techno-gadgets. This means making sure business issues always dominate technology issues. It also means presenting proposals in terms that managers can understand, including staffing, schedules, opportunity costs, risk, and dollars and
FAQ 3.04 How can someone manage something they don't understand?
Should the CEO of IBM know how to configure computers? Or issue expense checks? Or control the building temperature? No. The CEO's job is to understand strategy, directions, and politics; too much knowledge about operational minutiae would
So managers shouldn't try to be technology experts. But how can they manage anyway? Anyone who has ever raised children has
Of course, there are good managers and bad managers. Good managers lead their
FAQ 3.05 What is the most common mistake on C++ and OO projects?
Complexity, like risk, is a fact of life that can't be avoided. Some software systems have to be complex because the business processes they represent are complex. But
Here are a few guidelines.
Avoid the "death by one thousand cuts" syndrome by avoiding unnecessary complexity.