Practical Software Engineering

The 2007 International Engineering Management Conference was held near Austin, at Hyatt Lost Pines Resort from July 30 through August 1. I was a panelist on the Peter Drucker Leadership Panel. I also volunteered to prepare a daily video podcast from the conference. You can watch them on YouTube: day 1, day 2, day 3. The IEEE Central Texas Section and local chapter of the Engineering Management Society with Leslie Martinich in the lead helped make this conference happen. Thank you, Leslie!

Well, Peter Drucker didn’t write about software management, but he did write about management. In his book Managing in a Time of Great Change he has a chapter called The Five Deadly Business Sins. Here is what Drucker has to say:

The third deadly sin is cost-driven pricing. The only thing that works is price-driven costing. Most American and practically all European companies arrive at their prices by adding up costs and then putting a profit margin on the top.

The only sound way to price is to start out with what the market is willing to pay—and thus, it must be assumed, what the competition will charge—and design to that price specification.

How does this apply to software development? Here is how I see the two scenarios in the world of software development:

Cost-Driven Pricing: A Tough Sell

In this scenario the Customer comes with the software product requirements (not quite complete, since they never are). Next the software team goes ahead and figures out how long it is going to take to build it, and tells the Customer what the expected end-date is, thus arriving at a “cost.” The Customer is almost always unhappy with the end-date that the team provides. The Customer is also unhappy with the delivered product, since the software team usually does not manage the scope at a fine-grained level. The team thinks that they know what they need to build, and proceed on building it.

Price-Driven Costing: Problem Solving with Constraints

In this scenario the Customer comes with the requirements (never complete), and a target end date in mind: an end-date that fits into the business scenario that they intend to play out. It is now up to the software team to:

1. Figure out how the product can be built under the given constraints of date and cost, and
2. Figure out how to “slice & dice” the requirements to meet the Customer’s goals.

The software team must deliver to and negotiate with the Customer regularly. To deiver the project the team have to bring their ingenuity to solve the problem.

The Bottom Line

Price-Driven Costing applies to the way software teams work. It means that we need to work back from the price (date) that the Customer is willing to take, and then we have to figure out how to deliver the project on that date. There may be times when we have to say, this cannot be done. And there will be others, many others, when we will successfully deliver the project to a happy Customer.

It seems that all professionals have their tools, but somehow managers were forgotten. No more! There is a great podcast to provide the tools that managers need to do their jobs better called Manager Tools. The podcast is done by Mark Horstman and Mike Auzenne. They publish their podcast weekly and have a website with materials that every manager needs. Check them out and listen weekly!

It must be an inner drive that I like to see things done, and that I have taken up interest in getting things done from an early age. As far as I remember, I have always headed a little group and worked on some sort of project that I wanted to see completed, preferebly sooner, then later. I have a natural inclination toward leadership. Several groups have appointed me to become their leader, and I took up leadership positions on my own. 

The first time I formally started paying attention to management was in early 1991 when I watched Tom Peters in a PBS Special about MCI and other companies that he visited to learn about their work practices. I became a fan of Tom’s and have been following his work ever since, as well as read up on his earlier work (pre 1991). 

Since I didn’t get a formal education in management—and in 1991 had no intent on becoming a manager—I decided to learn about management on my own primarily out of curiosity. I started reading books that would help me understand what should a manager do and, later, how can one go about becoming an excellent manager. I tracked down and read books that I considered would help. You can find most of the books I read on my reading list. 

When one is a manager, then almost invariably the question of “management philosophy” tends to come up. My philosophy, if I should call it such, is to hire the right people and then get out of their way, support them, enable to get their work done. I ask lots of questions, to help my team understand the problem that we have to solve, and to help me understand where do I need to contribute. 

Over the years I came to conclude that pretty much the only way to motivate people is to give them a challenge just a bit bigger then the one they have already conquered. As a result, I am working on understanding where everybody is in the organization, so I can help them select the right problem for them. I believe that it is much better to let people pick the work they are doing then to try to force it on them. Intellectual work is only getting done if the person doing it can fully engage in it. 

Do You Use Your Brain At Work? You probably have to. Knowledge workers today make up over 70% of the working population. Your productivity is your competitive advantage! Take charge of you future! I can assist you in discovering what makes you more productive, and putting you on a trajectory for greater success.

Performance, Performance, Performance! As a Software Engineering Manager, the performance of software developers is on my radar every day. I work with people like you. Call me today to help you understand and improve your or your organization’s software development performance. If you don’t call me, at least think about your performance. Today. And do something about improving it.