Monday, June 25, 2012

Too much work, too little done


I remember asking someone a few months back how he was doing and his answer: too much work, but too little gets done. That got stuck with me, as I had had similar thoughts at the time and have had them since then.
One of the measures of satisfaction to me is simply a good answer to the question “have I been doing any meaningful work recently?” When it gets to a point when I see that I spent a substantial amount of time without doing anything meaningful, then it’s time to reevaluate. I think this becomes particularly worrisome when you are working very hard, but still getting little done.
I’ve had good discussions with friends about that and would like to share some thoughts out of these discussions.
The main question about getting work done is: what’s actually getting in the way? From my experience I can see some explanations that stand out:
  • Multiple people involved: the more the organization has a structure that involves multiple people in decisions, the more effort will be spent communicating, bring people up to speed, and trying to achieve any minimum consensus. Although bringing more people to the discussion typically improves the outcome with more perspectives looking at the problem, there’s a sweet spot on the number of people and who is brought into the discussion. At some point, more people don’t add too much value and actually introduce great cost.
  • Hierarchy, lack of autonomy: in companies where there’s more hierarchy, more people are responsible for the outcome of certain decisions. If all these people in the hierarchy want to be involved, any decision is simply very hard to be made as it requires blessing from all the people that are ultimately responsible for that work up the management chain. Therefore, autonomy is definitely limited (as I understand autonomy).
Ultimately, the consequences of having these things in the way of getting things done are:
  • Pace is just much slower than it could have been, as it went through all the “red tape” to get projects approved, resources allowed, etc.
  • Decisions can end up being hasty and incomplete simply because a substantial portion of the the process was spent in communication, talking to peers and managing up.
However, when I come to think about this, it’s natural to some extent to expect this behavior in an organization. If you on the top, you will need to make sure that orgs under you are doing something reasonable. You want to make that people are not signing up for something not realistic that will become a liability in the future. You don’t want to see them handwaving and setting up for failure. Of course that is true for anything that really matters – if you’re working on something that doesn’t really have that much value to the business, you may not go through the same things.
How to improve the organization in a way that makes it more agile and more streamlined?
  • Startup environment: in all places I’ve seen or heard of, it seems that nothing beats a startup environment, either at a startup company or within a big company. This reduces the amount of communication, doesn’t have the big hierarchies, and the side-effect is to end up with something that may not properly align with the org or that duplicates some other effort. A fair price to pay for agility, as long a minimum consistency bar with other company products/services is met.
  • Owners: another point is to turn hands-on employees (engineers) into owners. Get them vested into the product, get them to think of how to improve the project, to deal with customers, to operate services, to help decide features, to pick what features they want to work on. Then you will have engineers that, rather than spending a 100% on engineering, will become owners.
The counter argument to ownership, from the functional org perspective, are
  • Discipline is not really focused on its area and getting that much accomplished: ownership makes sense even in comparison with functional orgs and the allegedly focus that each discipline has. The reason is that it’s a fallacy this focus that engineers have. They end up not really getting that much done anyway due to the overhead in communication and due to the lack of freedom for them to get things done.
  • Ownership not clearly defined (or others are the owners): on the functional org topic, ownership may not be clearly defined and, if any, it belongs to Program/Project Managers. Other disciplines, not being owners of the project, may tend to back off and not be that much vested. After all, they don’t have autonomy to improve the project without going through the hierarchy ranks and getting the respective approvals.
Can such big functional orgs work and prosper? I am sure they can work once trust is established and they get into a rhythm, but how thriving such orgs can be for passionate individuals? How innovate can such orgs be if it’s not natural to individuals to feel owners?
Post a Comment