Why WiX: Controlled Crash of Centralized Setup
Yesterday, I introduced the model but there's still more to the problem that needs solving.
Introduction to the Controlled Crash
As described yesterday, most managers choose to defer setup as long as possible and then hire unskilled and temporary workers to bring it in in the hottest part of the product cycle. While the product eventually ships (yeah! ship party!), what's left after the product ships? Shifted workers go back to their official jobs and maybe even get credit for taking one for the team to ship the product. Contractors disappear, taking their skills and knowledge with them. After the product ships, the managers is faced with shell shocked new hires and an experienced core team in shambles.
A core team in shambles: how'd that happen?
First, the core team starts to disintegrate when managers have to figure out how to make the influx of new, unskilled workers productive. The first thing managers do is they ask (demand?) the core teams skilled individual contributors ramp up the new bodies in addition to their existing work. Time's too precious for training, rather new bodies are simply given the work and told "go talk to so-and-so" to be told what you need to do. Core folks end up waling the troubleshooting and triage with these new bodies a dozen times without ever getting the satisfaction of solving problems. The meaty parts of the work have been drained away in the interest of maximizing the throughput.
Second, there's no time to solve the interesting problems correctly. Other technologies start the cycle planning to do cool things. Once cool things are approved, design, implementation, and testing ensue. After the cool things works in the developers Petri dish, they throw it over the wall to setup, usually very late. One out of ten of these items is an opportunity to do some cool setup work but time is against you and there is no time to do it right. Due to time constraints, the business is less interested in seeing the right work done and besides they'll provide folks the chance to do it over later after shipping (yeah! party time!).
Third, the lights go on toward the business real, root motivations. For a while the increased load and tough resource trade-offs are invigorating, that engineering and personal challenge shipping software is meant to be. After a while, one starts to notice the pattern: shortcuts are the norm and meaty problems are deferred for low hanging fruit. Eventually you pick a battle that your engineering experience tells you've got to fight for but all too often these battles are lost for non-engineering reasons. You start to wonder does anyone really want to fix this?
Forth, rewards commensurate with the exercise do not materialize. If the product was entirely dependent on your expertise to ship, and you've been working two and three times others loads to execute, shouldn't there be rewards at the end of this march? For many, the answer is no rather you notice the folks that came in and were pitching temporarily get considerable portions of the rewards. Justifications vary but usually center around they shipped some cool product features and worked on setup while you just worked on setup so "clearly their contribution was greater".
Returning to the model, the damaging effects of this approach on the setup domain are represented in the orange and yellow zones. In the Yellow Zone, the waterfall starts with the above four factors resulting in, first bullet: low morale. The end of a product cycle often results in open doors to other parts of the product as people shuffle around which results in the second bullet: high turnover. While the setup team has slots to fill there is only a few slots available to experienced folks so the majority of the core team needs to move on which results in the third bullet: brain drain. The cumulative affect on the setup domain is worst in the Orange Zone where late, high risk work was solved with quick fix solutions that leave a messy legacy. Combine the messy legacy of the Orange zone with the flight of experienced people of the Yellow Zone and you have a formula to make setup worse and worse cycle over cycle.
Given the business has communicated to the senior people don't stay here if you want to be rewarded the new cycle starts with almost all shell shocked new hires.
Now, consider what the end game for setup taught the new hires. First, there's a premium on time, so take shortcuts where ever possible. Second, the business is not really interested high quality engineering solutions to fix the problems permanently. Third, don't invest here rather plot the shortest escape route you can find, preferably that gets you out before the next end game.
Over a number of product cycles, the disintegration and degradation becomes self-sustaining and no one, not even the business folks that originally thought centralized setup was a good idea, finds the multi-cycle result palatable.
That's going to have to be it for tonight. More tomorrow.
