How to Become a Powerless Leader

August 9, 2007

In high school I overheard some adults talk about leadership.  It was repulsive.  The words “power” and “ego” would have fit right in.  In the years since I’ve learned something about true leadership: It’s rare.  Like the demotivator reads:  “Leaders are like Eagles. We don’t have either of them.”  Here are some hints on becoming a *REAL* leader. 

 1) Grab a Vision – It doesn’t have to be original with you, but it has to be significant and you have to believe in it.  Work on it.  Develop it.  Stick with it.  Great leaders use momentum to build their vision.  The clarity of a real leader’s vision grows with time.

 2) Carry the Cost – People won’t follow a leader who doesn’t invest in a vision.  Not just money, but time, energy and commitment.  Great leaders like Dr. Martin Luther King Jr. and Nelson Mandela were willing to rot in jail rather than compromise on their vision.  People don’t want to be “used” by some ego deprived flunky, but they will flock to committed leaders who will pay the cost of leading the charge for change. 

 3) Share the Reward – The reward of leadership is not power, but a fulfilled vision.  Thanking followers can erode power, but popularizes the vision.  Reward followers as often (and publically) as possible.

Following these steps will put you well on the road to becoming a powerless leader.  A leader people follow because they want to, not because they have to. 

The Irony: Powerless leaders are never short of power.


Hints for Self Management

August 6, 2007

In spite of the micromanagement horror stories that regularly appear on the whole IT is very self-managed.  Unfortunately, most of emerge from the university with little more than “Introduction to Management”.  Until the schools start addressing that shortfall here’s a crash course.

Peter Drucker in his classic work The Practice of Management identifies 5 key areas of management*.  Here is that list (minor modifications) with thoughts on application to self-management.

1) Set Objectives

Software systems typically start out a mess—and get worse over time.  One of the reasons is that so much is done for the short term with little long-term focus.  Force yourself out of that mold.  Look ahead 3 to 5 years.  Use designs that anticipate needs for change.  Refactor and fix old code.  Think long horizons.  Daily objectives are fine—but it’s better to think of accomplishments in 3 to 6 month time segments.


2) Organize

If you work in a typical corporate IT shop, you are probably equipped with some sort of automated to-do list.  (They go under a dozen names—ticket system, request system, etc.)  It is tempting to think that the system alone will organize your work.  While useful, it certainly will not organize.

First, users don’t report everything.  At best the system will contain only a slice of your user’s real needs.  Furthermore, if you have much of a backlog, much of that slice may be out of date.  Simply pulling the highest priority request does not mean you’re fulfilling the user’s real needs.  If at all possible, get to know the users and what they are trying to accomplish personally.  Then pick what you work on accordingly.  Every minute spent understanding the world from their perspective will pay back in hours.


Once I spent weeks coding a piece of functionality.  After a few days I began to wonder if it really made sense—but it was requested so I proceeded.  I finished it up and demoed it to the primary user.  She looked up and me and said “You aren’t going to like this”.  Yes—you guessed it–two weeks work, completely thrown out.


In addition to incompleteness, automated systems come up with a random ordering of requests are not technologically related.  (Even if categorized—the categories are the users, not yours)  Technological schizophrenia results in high context switching costs and high costs from lack of learning–you never work at anything long enough to learn it deeply enough to do a quality job.  User requests must be groups into technically logical units and worked on in concert.  However, this must be compatible with the user’s goals—another reason to take the time to get to know the user community and their goals.


3) Motivate and Communicate

Software developers are notoriously poor at documentation.  One of the main problems is so much documentation is so formal.  Formal documentation is no fun to write and rapidly gets out of date.  I’ve found that informal in-code documentation and wiki sites are far more effective. 

When writing documentation—think big picture.  What does this system do?  What does this class do? Etc.  If (when) your code gets into the hands of another programmer they can always figure out the details (by reading your code), but they won’t know the reasons behind your design decisions.  Understanding how a system was shaped can really help in making decisions to modify/extend a system.  In short—don’t document code: document design.


4) Measure/Evaluation

All the great software developers are I know are pretty brutal self evaluators.    We are probably too good at self evaluating and undermine our own (and others) confidence.   Keep in mind mistakes and errors are statistically random.  Some days are going to be worse than others.  If you aren’t creating a few errors—you probably aren’t writing much code.  J

5) Personal Development

Read, read, read.  I spend my lunches reading blogs like Joel Spolsky’s at  Get involved in local user’s groups.  For example–my hometown’s .Net user’s group (  Sometimes bosses will even let you cut back on work time to attend meetings.  J


*The Practice of Management  Page 333, 334

** For a great series on (real—not self) management in Software see Joel Spolsky articles starting with:

Database 501

July 23, 2007

Back in my university days none of us were very enthusiastic about database class.  We were future programmers, not data administrators.  We understood that school is full of pointless challenges set up by “clueless” administrators.  But, most of us persevered and made it though such drivel as database class.  Little did we know!


During my first summer internship I was introduced to data driven web programming.  Two or three properly designed tables with the appropriate data could generate hundreds of web pages.  I was hooked on data.  And I’ve been hooked every since.  During the years I’ve picked up a few basic principles.  Most of these ideas can be found in database classes, but perhaps not described exactly this way.


A)  Make it Easy to Remember Field/Table Names.  (Looking up objects takes a lot of time and can easily derail thought processes)

1)       Use full names unless for everything except for extremely common abbreviations.  (Like ID for identification)   It will take at least a minute every time you need to look up the name of a field you’ve forgotten, but only milliseconds to type in some extra characters.  Optimize for remembering not typing.  (Oracle’s 30 character limit is a sad relic of a previous age)

2)       Use the same name for the same piece of data.  For example, if everyone has used date_added, don’t name your field added_date.

3)       The same applies to work breaks.  If the convention is to use underlines, use underlines.  CustomerNumber may be more “pure” than customer_number, but making everything consistent is more important.


B) Make it Easy to Identify Fields/Tables

1)       Identify keys with the table they belong to.  For example account_id is a good key for the account table.  sequence_key is a really bad field name.

2)       Preface tables with system names.  For example sales_accounts, sales_transactions etc.  However—I’ve seen this one misused.  Don’t go overboard.  Many systems are highly integrated and prefaces can be more confusing that beneficial.  If you will find yourself asking “Now was “items” in manufacturing or sales?” then use the same preface for both systems.


C) Be Prepared for Change

1)       Never believe anyone when they say a field will never change.  Use auto-sequence keys rather than natural keys for foreign key references.  When the natural key changes (notice I use the word when not if) the only thing that will need to change is the natural key’s index. The foreign keys can (and should) remain unchanged.


D) Appropriately Use Normalization

First and foremost–a transactional system should be normalized.  Normalization is not “academic”.  Nothing is more practical than a well designed database structure.  Allowing duplicate data to sprout across a system may seem “easy”, but in the end it will results in hundreds (even thousands) of lines of code merely enforcing data consistency.  There’s no reason  that code should handle what a database was already designed to handle.

However, there is an exception to the normalization rule.  Non-transactional reporting data should not be normalized.  For example, consider a typical transactional system with an inventory table, an item master table and a sales history table.  In a typical environment, when the item master is changed, we would want to see queries against the inventory table reflecting those changes.  (i.e. using a join between inventory and items)  For example, say a price change or minor description correction of a certain part/product.

On the other hand, if we are querying against the sales history table, we do not want to see the changes in the item master.  We want instead to see the sales data at the time it took place.  Even if it’s inside a typical transactional database driven system, the sales history table is actually a data-mart/data-warehousing table.  In data warehousing the rules totally change.  There are still rules—just different rules.  A data warehouse is not normalized.  Instead, you snapshot all the data needed for reporting.  The result is a wonderful (for reporting) set of completely static de-normalized tables.  Unfortunately, most software developers have not had any experience with data warehousing (mine own is extremely shallow) so we often try to apply normalization rules and fail miserably.

This is not revolutionary—data-marts and data-warehouses have de-normalized forever.  What is new is the recognition that even small systems often have data-warehouse style tables mixed into the typical set of “normal” tables.  (A common example of a data-warehousing table would be an event log)  The key to properly designing such tables is recognizing what they are and applying the appropriate design principles.  (And above all don’t try to have one table accomplish both—it won’t work)


E) Leverage the Power of the Database.  These should be obvious. . .

1)       Always define datatypes – varchar aren’t a substitute for any kind of data.  Generic expansion fields (attribute1, attribute2, etc) are equally evil.  (An unavoidable one for those of us working with Oracle applications.  L)

2)       Don’t put comma separated values inside database fields.  (Yes, I’ve known this to actually happen)

3)       Leverage the power of database programming—PL/SQL, T-SQL, etc.


If any of ya’ll have other suggestions please comment below. 

Ps. I reserve the right to delete “religious” arguments if they get out of hand!