Recently I had a short talk with a colleague from a friendly company about how to challenge, please and get the best out of your top software engineers. He came out with the idea of a secret garden where the top engineers shall be shielded from the outside world to produce brilliant ideas undisturbed by people like average engineers or even worse people owning the requirements (i.e. customers). Feeling somehow uncomfortable I had the increasing wish to comment about this.
Somehow the whole idea felt very known to me – wasn’t it the way how in the good old ninetees (and even before) hundreds of IT integration companies separated their ‘top developers’ into a shielded group to write an incredibly ingenious application framework which the rest of the company should use to implement customer projects in zero time? All efforts I have seen in this way more or less failed and I guess so did the efforts I didn’t see…
Clearly a secret garden seems at the first glimpse as a very cool cure for the common symptom of seeing your geniuses drowning in (constantly changing) requirements. But this adresses not the root cause of the symptoms… Organize your requirements better and you will immediately ease the pain (different story, anyway…)
From my point of view the whole idea of a secret garden fails for various aspects:
- It parts engineers into class A developers and class B developers. Why is this bad? It provides the base for envy and misunderstanding. And it just not works because class A developers have to fix broken code from class B developers anyway
- It also implicitely assumes that there are class A and class B engineering problems. I strongly believe that there are no class B engineering problems. I have often seen this attitude when it comes to GUI programming, even to things like a company web site. I found this a particularly misdirected kind of thinking. Good (long term maintainable) GUIs are complex. And for no reason I want to put things like my <em>company web site</em> into the hands of average people!
- It shields the secret garden from the real life. You are in danger to transform your young geniuses into divas! I think it is well known where this ends.
So what to do:
- Don’t hire class B engineers even if they are cheap. This may seem painful at times but it rescues your engineering in the long term.
- Organize the work environment inside your engineering but let your engineers directly face the requirements. If they are frightened then probably you have to organize the requirements better
- Support your engineers to understand all problems as class A problems and give them freedom to work on problems with this attitude.
This for sure sounds like an ideal world but the whole discussion is about choosing good ideals
Hi, Uwe,
Your thoughts are exactly why I set-up the Innovation Lab at Intuit the way I did… secret gardens divide! For Innovation Lab projects, we had a senior team of folks from the lab work with a diverse group of people from the business unit. Project weren’t done by the lab then tossed over to the business unit, we were like internal consultants to helping them get a job done quickly and effectively — with a high degree of innovation.
I think this set-up works well in general… senior
“A players” are integrated in teams, and play a leadership role in raising the level of the team. And yes, there are issues where A players don’t like this role. I’ve managed that many times. The trick there is to find how they can, and set those goals. It might just be examples that others on the team that are good at teaching use. It might be through specific folks as conduits. But again, the person doesn’t get to be an island, just the channels are directed specifically.
Wow, hope some of those thoughts help anyone else as they think through this idea.
Best of luck with the blog… I’ll be watching and happy to contribute as you continue on.
– Jana
no B. sounds like a great idea.
discipline is key.
excellent, but nicht sicher ob nicht ein deutschsprachiges blog für den anfang nicht die bessere wahl wäre?