The self-defeating effects of micro-management

I started drafting a blog post about the self-defeating effects of micro-management when I came across this interview response (from Yahoo CEO Carol Bartz) which sums it up perfectly:

What classic mistakes do you see managers making over and over?

“Setting a goal is one thing. Telling people how to do it step-by-step is another thing. That’s what happens especially with new managers. They not only tell the result that’s supposed to happen but they also tell them how to do it, which is such an insult. People just friggin’ shut down–I guess I’m not going to do it well enough. I’ll just wait to have you tell me how to do it.”

(via Yahoo CEO Carol Bartz: “I’m Just a Manager”.)

I’ve seen teams “shut down” for this exact reason, and the result is a loss for everyone.

When faced with continual “managerial vetoes” and micro-management, teams stop delivering the value they are capable of. They no longer seek the best solutions — they no longer listen to their customers. By not delegating and trusting their team, these managers have created more work for themselves! And the odds are pretty good that whatever comes out of this process will be sub-par.

The idea raises an interesting perspective on the evaluation of new products and services: If the solution is sub-par, was it for lack of ability on the part of the implementation team? Or was it lack of ability on the part of their management?

On a related note, I highly recommend
The Effective Executive” by Peter Drucker if you happen to be new to management (or, in this case, have under-performing teams.) “Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself” by Watts Humphrey has some nice views on this issue as well.

“Fun example of programming language sc…

“Fun example of programming language scope” is only “fun” for a certain type of geek; But I like programming examples that help explain how your code is interpreted, particularly if the lesson can help prevent a certain class of bug.

Now that you’re expecting a scope puzzle, what will the following JavaScript print? (Ignoring the line numbers, of course, which are here to aid in discussion.)

 1:  var foo = 1;
 3:  function bar1() {
 4:   print("A: " + foo );
 5:  }
 7:  function bar2() {
 8:   print("B: " + foo );
 9:   var foo = 2;
10:   print("C: " + foo );
11:  }
13:  function bar3() {
14:    print("D: " + foo );
15:    eval("var foo = 2;")
16:    print("E: " + foo );
17:  }
19:  bar1();
20:  bar2();
21:  bar3();


No peeking…



A: 1
B: undefined
C: 2
D: 1
E: 2


“A” is easy. Since foo is a “free variable” (i.e., not defined within function bar1), the interpreter goes up the scope chain, and finds the global foo, defined on line 1.

For bar2, “C: 2” is obvious — it’s “B: undefined” that lets you in on the magic under the hood. You sort of expect to see “B: 1” (or a compiler error.) However, JavaScript interpreters scan-ahead, searching for variable definitions (e.g., var statements) when parsing a code block. The interpreter sees/re-writes bar2 like this:

 1:  function bar2() {
 2:    var foo;
 3:    print("B: " + foo );
 4:    foo = 2;
 5:    print("C: " + foo );
 6:  }

With that definition, “B: undefined” makes perfect sense.

To short-circuit the magic, bar3 uses eval() to do it’s trickery. At line 14, foo still points to the global foo, much like in bar1; However, the eval statement on line 15 modifies the local scope, introducing a new, local foo. By line 16, “E: 2” is using the newly introduced foo.


The lesson: Even though JavaScript allows you to declare variables at any point within a block, putting your var statements at the beginning of the block can help eliminate scope confusion around whether an inner- or outer-closure contains the correct value.


Bonus Question

Is JavaScript’s var a let or let*? It’s easy to find out using the following:

 1:  var x = 2, y = 3, z = x + y;
 2:  print(z);

Is this legal? Will it print ‘5’?

[Update: 2010/09/21: If you liked this, you’ll also enjoy “JavaScript Scoping and Hoisting“.]

Great quote on the value of being a good client

“Clients who are easy to work with … don’t just get our best work. They also get the lowest invoices, because we can work efficiently and don’t have to fight our way through the process.”

The article is about working with Graphic Designers, but it applies equally well to technology or strategy engagements.

via “10 Secret Code Phrases to Get What You Want from Your Graphic Designer“.

Nielsen finds that Senior Management is often what blocks innovation

The findings from this Nielsen report, “Secret to Successful New Product Innovation: Keep the Boss Out of It“, ring all too true, and are worth considering if your company creates, wants to create, or is struggling to create products.

Two key points from the report:

  • Get the innovation centers out of the corporate headquarters
  • Let Senior Management focus on the process, not the ideas

Why would this be the case? There are numerous possibilities, but many will likely involve corporate politics, “group-think”, “power and control” issues, and people focused on the wrong areas. Remember, your Senior Management should be very knowledgeable of the field in which you do business, but are generally tasked with operational responsibilities — not directly on R&D, market research, customer support, etc. Furthermore, without a clear process for product proposals, funding, and re-investment, good ideas might be battling for funding against lesser ideas from someone with more political power.

So how do you solve it? You’ll have to look at the operational shortcomings of your own organization; But the solution likely involves a proper Product Management group, and an open product proposal, review, and funding process. It may come as a surprise to many, but the role of Product Management is to focus development (and product creation) on the right products, based on market needs (identified via market research.) They uncover opportunities, evaluate fit, and get solutions to your customers.

Too often, Product Management is run incorrectly (or non-existent), which might be behind the findings of the Nielsen report. If anyone in the company (Product Managers included) is basing product strategies on their gut feel — you’re gambling. If you’re in the Invention Business, that’s fine. Just acknowledge that you’re guessing.

Having a clear, open process for product proposals is equally, if not more important. This is how you suppress favoritism and personal agendas. It also allows you to leverage the wisdom of your full organization (e.g., internal crowd-sourcing and peer-review.) In my experience, transparency in product funding is a major area of contention since it “takes away” power from Senior Management (even though having this power hurts the organization.)

If you’re expecting new product innovation and your organizational operations aren’t specifically designed to foster it, it’s time to get serious or quit kidding yourself.

  • Give people the time and tools they need to innovate
  • Get the politics and “devil’s advocates” out of the ideation process
  • Establish an open process for reviewing and selecting the products to be funded
  • Understand your metrics for success
  • Adopt formal Product Management methodologies
  • Listen to the market (your customers and non-customers)
  • Allow customer and market research to trump seniority
  • Be willing to fail quickly and move-on
  • Accept that good ideas can come from anywhere
  • Ensure that Senior Management (and everyone, for that matter) understands their role, and what’s expected of them


Related reading: “Innovation and Entrepreneurship” by Peter F. Drucker (or at least my review of the book.)

JavaScript on the Server, and conversations at TXJS

We’ve seen various attempts at using JavaScript on the server over the last decade. Mozilla’s Rhino (Java) engine fueled most of it. However, with the release of Google’s V8 (C++) engine (and the networking performance example set by Node.js), the conversation is gaining traction.

The motivation for a 100% JavaScript stack, per conversations at Texas JavaScript Conference (TXJS) last weekend, is the desire to use a single programming language when developing web applications, rather than the mix of technologies we use today. It’s not so much that JavaScript is the best language for application development (contrary to the JS fanboys), but since it’s what we’re stuck with on the client-side, it’s worth considering on the server-side. With a single language, business logic can be reused on the client and the server (think form validation), and you avoid bugs caused by frequent language switching (i.e., using, or forgetting semi-colons, putting commas after the last item in an array, using the wrong comment delimiter, etc.)

The wrinkle in the 100% JavaScript argument, is whether JavaScript is actually the language you want to write your back-end in. The language lacks package management standards (though CommonJS is working to change that); It lacks the standard libraries and tools that the incumbents offer (i.e., no batteries included); Maybe people who use it don’t actually know the language very well; And it suffers from the multitude of bad examples and advice freely available online.

There have been some interesting Node-based applications developed already (i.e., Hummingbird), and the JavaScript on App Engine efforts (i.e., AppEngineJS) will be interesting to watch as well. (I expect both to foster more mature development patterns for large applications written in JavaScript.) However, in the near term, the 100% JavaScript stack will likely remain as niche as the Erlang, Haskel, Lisp, etc. web frameworks (as interesting as they may be.)

The question for you (Mr./Mrs. web developer/web-savvy business person), is whether JavaScript on the back-end offers a competitive advantage. Can you execute on an idea faster/better/cheaper than your competition because of your technology stack?

Book: “Reflections on Management”

Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself wasn’t the best written/edited book, but has some tasty bits scattered within the random acronyms. It reads like the storytellings of a retiring, experienced, software manager at a large corporation. Someone telling the inside story in a blunt, matter-of-fact approach. Personally, I like that style. It gets to the point without dancing around the subject. The only caveat with this book though, is that some of the advice is a little too specific to the author’s previous corporate environments. Still, if you’re stuck at an airport and this is what the local bookstore has, it’s not a bad choice.

A few quotes:

“Quality work is not done by mistake.”

“When developers are simultaneously assigned to several projects, they have split loyalties and their teammates cannot rely on them for support and assistance.”

“It is hard for someone to feel committed to a project when management is unwilling to make it their principal job.”

“Discipline, in fact, is what separates the experts from the amateurs in any professional field.”

“The team leader must motivate, coach, drive, and urge the members to perform to the best of their abilities.”

“If you don’t change the engineers’ working practices, you can change the organizational structure and all its procedures, but nothing much will really change. Thus, to have a substantial impact on an organization’s performance, you must change the way the engineers actually work.”

“Even when the result is a total business disaster, if the team provided a rewarding personal experience, the team members will view the project as a success.”

“When people say they are working harder, they actually mean they are working longer hours.”

“Designing, coding, reviewing, inspecting, and testing are intensely difficult tasks. To have any hope of producing quality products, we must occasionally take breaks.”

“Often, teams respond to this pressure by taking shortcuts, using poor methods, or gambling on a new (to them) language, tool, or technique.”

“Every day that you wait to act is a day that you can’t use to solve the problem.”

“The most important single asset a software engineer can have is a reputation for meeting commitments.”

“The most successful teams have energetic, enthusiastic, confident, and hard-driving leaders. If you don’t have the required energy and drive, figure out what to change so that you do. If you can’t see how to do that, either your team has a hopeless job or it needs a new leader.”

“A significant part of your leadership job is to keep the team’s goals clear and well defined and to ensure that every team member knows how his or her current tasks contribute to meeting that goal.”

“It is impossible to be an effective leader without being committed to a cause that animates you and motivates your followers.”