Another aspect of creating leaders in your organization is how assignments for subordinates are designed and managed. I was very lucky in my first management position to be overwhelmed immediately. What happened was that I was managing a group of… Read More »Creating Leaders in your Organization, Part 2: Leadership and Delegation
Emerging leadership in organizations can be developed, suppressed or ignored. Unfortunately, rather than encourage the emergence of leadership, it is often not considered, or even worse, suppressed. Leadership, as distinguished from management, is present when unprecedented results are produced through… Read More »Creating Leaders in Your Organization, Part 1: Talk is Not Cheap
Perhaps the most important shift in the culture of organizations that will enable the emergence of leadership is changing the attitude most organizations have about breakdowns. As noted in the last part of this series, “breakdown” is the term we… Read More »Creating Leaders in your Organization, Part 5: Leading and Organizational Culture
I define team as a group of people with common commitments. In sports, it is obvious that a group of people sharing the commitment to winning a game will at least try to operate in harmony, while the same group… Read More »Creating Leaders in your Organization, Part 4: Leading Teams
Years ago, I ran a large software engineering organization creating the first release of a new operating system for a new line of mini-computers. About six months from the scheduled completion date and three months from entering final system test,… Read More »Creating Leaders in your Organization, Part 3: Leadership and Listening
In most large organizations, leaders can either be developed, ignored, or suppressed. Unfortunately, in many cases, rather than encouraging the emergence of leadership, it is not considered, or, even worse, suppressed.
In my career, I’ve taken over existing organizations several times. In one case, the executive I replaced was the only person in the organization that had the overall picture of what was going on. He was the one that met one-on-one with his boss to present status. His staff meetings consisted of his asking questions and handing out detailed assignments. None of his direct reports had ever been asked to recommend a course of action. Not surprisingly, when he was asked to put together a list of people in the company who could replace him, none of the people in his organization were on the list.
There’s an old joke in the software business that states, “In the past 40 years, we’ve had two years of experience twenty times.” Unfortunately, this joke has more truth to it than most of us would care to admit. Many programmers are under the mistaken impression that the problems that they’re facing are new and haven’t been seen before and/or successfully solved.
None of this would be very important if the overall quality of the software we use was not horrible. If software quality is measured by its reliability (doesn’t crash), being free of errors (bugs), and ease of use, we have been moving backwards. This, coupled with the fact that software plays an ever increasing role in every aspect of our lives, means that we are depending more and more on things that are getting less and less workable.
I was a manager and then executive in IBM software product development from the late ‘60’s through the early ‘90’s. The change in IBM’s organizational culture over that period was dramatic. During the ‘60’s, IBM embarked on a international, multi-product development effort that resulted in the System/360 – a product line with several new software operating systems and at least 8 different hardware systems along with a new line of peripherals. The development of these products spanned the globe and took place in more than 30 groups in approximately 15 different locations from Europe to North America to Japan. There were countless interdependencies among these groups and, as might be expected, rivalries and conflicting priorities among them. But a few, relatively small, central groups in upstate New York were successful in managing the interfaces and interdependencies between the many components of the various hardware and software systems, the schedules and the budgets.
Bob O. Evans was the overall executive in charge of development in those days. He was a man of impeccable integrity – his word was his bond, and he insisted on the same kind of behavior throughout his organizations. Failing to give your word to provide a necessary component on schedule was unacceptable. Not honoring a commitment was inexcusable. The System 360 project was sometimes referred to as a “bet-your-company” effort, and its success set the growth path for IBM for the next 25 years.
A few years later, in the early ‘70’s, when Evans was the president of the product development division, I managed the creation of the first version of the MVS operating system which was, up to that point, the largest single software project IBM had ever attempted. Twenty different groups in 12 locations were involved – a total of nearly 3,000 people at its peak. Each of the groups reported to geographic executives that often had other conflicting priorities – their own pet projects, non-software products that they were also responsible for, budget and headcount constraints, and so on. Even so, it all worked.
When I was on the IBM Corporate Technical Staff, I used to go around to the various locations around the world and “help” them with their projects. I visited with a myriad of project management people at all levels and on all types and sizes of projects. One of questions I would ask each person I spoke to was “what do you look at in your everyday management of your project?” Most people showed me some version of their project plan: tasks, checkpoints, people assignments, and so on. But one day, I was shown something that I had never seen before, something so useful that I have shared it with every project team I have worked with since.
What I saw was a graph with time running left to right and top to bottom. The origin at the top left represents the start date of the project. The scale of both the horizontal and vertical axes is the same. The horizontal axis is labeled “plan dates” and the vertical axis is labeled “actual dates.” The initial plan for the project is represented by checkpoints (or “milestones” if you prefer) on a horizontal line. The vertical position of the horizontal line is the actual date the plan was created or modified.
Here’s what this looks like: