So I just finished reading all the books put out by Basecamp/37Signals: "Getting Real", "Rework", "Remote", "It Doesn't Have To Be Crazy At Work", and "Shape Up".
They have a process. It works. It works for them. Beautiful. I learned lots.
And I have been wondering how this might have worked in the world that I formerly inhabited.
Basecamp/37Signals (whichever name the organization has finally settled on these days) has for a long while been a smallish private outfit that sold a few different pieces of software. Mostly that was just one: "Basecamp", a project management system developed in-house and made into their only product.
A couple of years ago they then created "Hey", an email system, so they have two products now.
Me, I worked most of my so-called career in state government. Luckily I escaped with my life but though heavily scarred I am still interested in process, and I have been wondering how the Basecamp approach might work for systems that are still back in the age of stoneheads.
Government work, at best, is severely constrained by laws. Supposed to be, but it's sloppy. But it's supposed to be based on law, so let's go with that. That's one thing.
Another is effectiveness, or not.
There is "10 Principles of Effective Organizations" by Michael O'Malley, as published by the Harvard Business Review.
The principles as defined by that are:
1. Encourage cooperation.
2. Organize for change.
3. Anticipate the future.
4. Remain flexible.
5. Create distinctive spaces.
6. Diversify your workforce - and create an inclusive environment.
7. Promote personal growth.
8. Empower people.
9. Reward high performers.
10. Foster a leadership culture.
Nope. Not where I worked.
Where I worked, the watchword was "wait", and none of the above items applied, or were even known. If "wait" wasn't emphatic enough, then there was "If it ain't broke, don't fix it." That worked too.
An as an extreme edge case, anyone especially daring might have added "Ask your supervisor." But you could never tell how things might turn out if you made a target of yourself, so quiet waiting was always the best plan.
Then there is the "Capability Maturity Model" as another gauge of effectiveness.
Its levels are:
1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process.
2. Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted.
3. Defined - the process is defined/confirmed as a standard business process.
4. Capable - the process is quantitatively managed in accordance with agreed-upon metrics.
5. Efficient - process management includes deliberate process optimization/improvement.
Nope. Again.
There was none of that either. Even level 1. We were never that organized, anywhere I worked, especially the "individual heroics" part, because you were either supposed to ask your supervisor, which could be dangerous (The nail that sticks up soon sees a hammer.), or better yet, "wait". No matter what, something always happened eventually, so waiting was terrific.
Anyway, at Basecamp/37Signals, according to what they've published, they usually let things ride until they see a genuine need to alter/extend/improve their product.
Once there is a clear need, they assign a small team to "shape" a problem/solution set, coming up with a general direction for a design and a general set of requirements. After that, upper management picks what looks most promising (what they call a "bet"), and they go into a six-week development cycle. At the end of that, they either have a finished project or something that they need to abandon, at least for the foreseeable future. Then they spend two weeks cooling down, cleaning up, and ramping up for a new cycle.
What I don't get is how they start on a completely new product. You can't pick a part of that to improve, or a part to add, since there isn't anything there to improve or add to, but they don't cover that part in any of their books.
And since the business is both private and privately held, they don't have the dozens or even hundreds of legal requirements that a state government agency would have, not to mention perennial funding issues.
But it seems to me that one huge problem in government work is that basically no one cares. Some people do, but they're either demoted or fired, or maybe just defined as crazy and ignored. The real problem where I worked, as I see it, is that the legislature would meet, pass a bunch of laws, and then the legislators would all go home again.
The next phase involved the governor turning around and passing the new requirements to all the state agency heads, and going back to posturing and planning for the next election.
The heads of the state agencies would take the directives they got, hand them off in turn to their deputies, and return to posturing and playing politics, and maybe planning their own run for governor.
The rest was a continued cascade of delegation and dilution of responsibility until the directives became so feeble and confused that no one knew anything specific any more, so they waited, listening for any howling and/or bellowing from on high. At that point someone might get to work, but reluctantly and very slowly, because you can never do the wrong thing if you don't do anything, and you can be punished only for doing the wrong thing, which can't happen unless you actually do something. So there.
And a lot of people were just plain incompetent. The branch of the last state agency that I worked for had a head of IT who got the job because she was a friend of the head of that branch and would qualify for higher retirement pay when she retired from that position in a couple of years. At the time of her appointment, she had never used a computer, and though she then got a desktop computer, she didn't even know how to turn it on. Head of IT. True. I was there.
Yes, I'm glad that I finally quit. At least I got that part right.
And another thing.
I've also been thinking about a short conversation I had with a barely post-highschool guy a couple of decades back. He was apparently a real hotshot with MySpace. Could do anything that it was possible to do there. Had a lot of followers. Lived to code. Got angry when I suggested that he should also work feverishly and relentlessly on his communications skills, never forgetting the spell-checker. All as a real leg-up on any competition.
I was trying to helpfully pass on a tip, but he took it personally, like I was his prissy seventh-grade English teacher trying to scold him with a personal putdown, correcting him when he said "cootnt" instead of "coodent" when pronouncing the word "couldn't", or something like that.
But you can't really talk to people who know it all, until they eventually learn the hard way. (MySpace experts —
where are they now?)
So it occurs to me that the essence of getting anything done, formal process or not, especially with software, is covered by three principal ideas:
1. WHAT
2. WHY
3. HOW
The "HOW" part is coding, what the code monkeys and high-testosterone highschool boys think is important.
If my conversation with the young hotshot had been in 1967 instead of 2007, he would have been aiming at a career in either auto-body repair or auto mechanics, and he would have been completely unimpressed by anything else, because of his Mad Buffing Skillz, with which he would soon dominate the world.
Instead, he knew the computer programming equivalent of highschool auto body repair and knew deep in his heart that he was legend, and that masses would soon bow down.
As a former co-worker of mine said, when he became ranked high enough at work to be on hiring teams, he could teach a chicken to code, any chicken, but the important part was being smart, being able to identify problems and think through them. I.e., knowing how to focus on the actual business issues.
"WHAT" is also important, more important than "HOW". The "HOW" part really doesn't matter that much. If it did, then we wouldn't have so many programming languages. Maybe just one. Just one that made all things happen. But there are whole batches of them all over the place, and new ones every week, so if there are hundreds of ways to do "HOW", then "HOW" really ain't that significant.
So the summary judgment on "HOW"? Right behind "WHAT", but way back. Meh.
The crux is "WHY". Why do something, after all? What you do and how you do it come way later. It's the "WHY" part that drives everything. Why this, why that, why not the other, and so on. Without a good "WHY", it's best not to even start.
This is the part that Basecamp/37Signals gets right, and none of my work life did.
They work to improve what they've got, when there is a good business case for it, and they improve what they've got when they realize that a particular improvement is more relevant than anything else.
Simple, direct, effective. Versus endless confused thrashing.
True, Basecamp/37Signals is still private business, privately held, and the whole deal would work a bunch less well in big businesses, let alone the creaking, dark dungeons of government, but me, I'm free now, haven't had to work in years, and am now able to explore the real meaning of excellence and fantasize about the life that could have been.
At least there are some who live glorious, rational lives, knowing which is in a way nearly as nice as if I had been able to do that, so there is that then, and I salute them no matter what.
Refs:
Effective Organizations
Effective Organizations, alt link
Capability Maturity Model
Capability Maturity Model alt link
Books by Basecamp
Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? Slow learner.
Etc...
so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals