Tipping the Scales

November 10, 2008
Add Comment

Every organization needs procedures. What needs to happen when I file a bug? How do I notify clients that their feature is in production? Who do I bill this work to? All of these are simplified by procedure. Instead of having to figure out the issue and devise a solution every time the problem arises, procedures allow us to base our actions on past thought and designs.

Procedures can be good but they can also create more problems than they are worth. When procedures reach a point to where you are spending more time trying to find the right procedure than you would if you just figured out the problem from scratch, they are a burden.

A happy medium should be targeted. This middle ground should ultimately save time – otherwise it is a wasteful venture. If you have to spend long amounts of time searching for or through documents just to figure out what is supposed to happen then the system is a failure.

Next time you are going to add a procedure you should stop to ask yourself the following:

1. Does this solve a tough problem?
Does this procedure save people an inordinate amount of time or money? Does this procedure address an issue that is difficult to figure out on a case by case basis? If either of these are true then the procedure is likely to be a good addition.

2. Is this going to simplify things or add undue process?
Will people have to take a lot of extra steps just for the sake of procedure? If any part of the procedure is there just for the sake of it and doesn’t produce a tangible output then the overall process is diminished.

3. How easy will this be to remember?
If a procedure is hard to remember then people will need to look it up each time. This, by itself, doesn’t necessarily negate usefulness. However, if people have to look it up and it is tough to find then the process becomes much less useful and less likely to succeed.

4. How often is this likely to happen and what is the importance when it happens?
If the item in question rarely happens and/or doesn’t have a lot of value associated with it then there is likely not a need for detailed procedures. For example, declaring war doesn’t happen that often but has a high cost so a procedure is needed. Conversely, working showstoppers happens far more frequently but has a relatively low cost.


Over the code

October 17, 2008
Add Comment

I realized a while back that I have grown tired of writing code. I still enjoy the design aspects of software and enjoy being involved in the software creation process. I just no longer care for the implementation aspect of the business. I haven’t written a line of code in probably three months. I haven’t written a significant portion of code in at least six months. And I’m happy.

My parents were both programmers so I got a very early introduction to software. I began by writing little programs, address books and the like, throughout childhood and high school. I then jumped into a data entry job, which I quickly figured out how to write a script to help automate. From there I never had a job where I didn’t write code. Until now.

My parents both ended up in management – my Dad has relatively recently returned to writing code. They both told me the same thing at one point or another: they just got tired of writing code and wanted something new. I believed them and figured that I would follow suit sooner or later.

About five years ago I was still pretty into writing code still but looking to the future I saw myself growing wary in the next five to seven years. My timing ended up being just right. About five years ago I started getting into more leadership roles – leading software teams while still having my hands in the code. Over that span I have slowly become more and more removed from the code until just a few months ago when I decided I was completely done with it. I am now in a role where I don’t write any code but still have a high level of involvement in the design and development processes.

I may still write about code and software practices here and there however, as is obvious by my post trends, they will become less frequent. I imagine that the main focus of my writings will continue to be business of software and economics, with a little bit of software sprinkled in here and there.


Yurtle the Turtle

October 15, 2008
Add Comment

One of my favorite books growing up, and now one of my daughter’s favorite books, is Yurtle the Turtle by Dr. Seuss. The story is of an arrogant turtle king who marvels at how wonderful he is and proclaims that he is the ruler of all that he can see. But things grow stale and Yurtle yearns to rule over more. He orders his turtle subjects to stand on one another’s backs to form a higher throne for him, allowing him to see and rule more. Throughout the story he keeps forcing more and more turtles to add to his throne so that he gets higher and higher. The entire time a single turtle, Mack on the bottom of the stack, keeps complaining that the turtles are all in pain because of Yurtle’s greed. Yurtle repeatedly silences Mack until Mack decides he’s had enough and decides to topple the throne, causing Yurtle to fall into the pond below. The story ends with Yurtle being king of the mud, “because that’s all he can see”.

As a child I vividly remembering this story being a life lesson in not allowing people to boss you around and walk all over you. The message I learned was that people should stand up for themselves and not allow their rights to be violated, no matter who is violating them. As an adult I still see this message but I also see the other side of the equation, especially as it relates to leadership.

As a leader you must keep in mind that people don’t have to follow you for any reason – even in business environments. As with Yurtle’s situation, the lowest person on the team can ultimately bring down the entire structure. Just because someone reports to you on the corporate structure doesn’t mean that they have to follow you. They can undermine your authority, complain to your superiors or HR, or even leave your team or the company. The relationship between leader and follower is a voluntary one. Always. The only benefit that corporate leaders are given is that they have a mandated reporting structure, allowing them more time to sway their potential followers whereas in non corporate situations the potential followers can leave much quicker if not immediately satiated.

As a leader it is natural to strive for personal and professional growth. However, if that growth comes at the sake of your followers it is just a matter of time before you are in for a tumultuous fall and find yourself being king of the mud.