Posts Tagged ‘Joel Spolsky’

Preposterously Unacceptable

October 20, 2012 Leave a comment

Unless they’re cosmetic tweaks, all proposed alternatives to the unassailable and revered Annual Performance Review (APR) will always be auto-stamped as preposterously unacceptable by the powers that be. It has to be that way, cuz expecting the wolf who’s guarding the hen house to voluntarily give up his post is a slam dunk losing proposition. Nevertheless, let’s look at one of these preposterously unacceptable alternatives just for fun.

Sam Culbert, in “Get Rid Of The Performance Review“, proposes deep-sixing the laughable APR ritual and replacing the stinker with the (crappily named) “performance preview” (PP). The first major feature of the PP is that salary actions are severed from the process. They’re independently determined according to a more objective set of criteria (perhaps like how Joel Spolsky does it at Fog Creek Software). Removing the salary sledgehammer from the hand of the formerly omnipotent manager increases the chance that a straight-talking, two-way conversation regarding individual and organizational improvement will occur.

Mr. Culbert’s face-to-face PP, which can be called into being whenever either side “feels” it should happen, is predicated on both sides answering simple questions like these:

  • What have I been doing recently that helps you and the organization perform better?
  • What have I been doing recently that isn’t working for you and the organization?
  • What can I do in the near future to help you and the organization improve?

Notice that thesw are questions to be answered by both sides – as opposed to one way, judgmental assertions made by the boss “on behalf of the borg” to the subordinate. There are also no formal forms or checklists to be signed and squirreled away in Hoover files to be brandished later for compliance coercion.

This blog post barely scratches the surface of Mr. Culbert’s PP process, but hopefully it’ll spur you to buy his book and learn more about this HR anti-christ. On second thought, don’t do it. If you’re a DICkster, it might bum you out since you’ll vividly realize that you’re helpless and you can’t “fight city hall“. If you’re in the hallowed guild of management (especially the unconsciously evil HR echelon), because of its preposterous unacceptability, it might send shivers up your spine and/or piss you off.

Note: Instead of “Performance Preview” (PP), BD00 would’ve called it something like “I Help, You Help” (IHYH).

Secret Salaries

Joel Spolsky is the CEO of Fog Creek Software. In this Inc. magazine article, “Why I Never Let Employees Negotiate a Raise”, Joel spews hearsay on the topic of salaries:

The trouble with keeping salaries a secret is that it’s usually used as a way to avoid paying people fairly. And that’s not good for employees — or the company. – Joel Spolsky

I wanted Fog Creek to have a salary scale that was as objective as possible. A manager would have absolutely no leeway when it came to setting a salary. And there would be only one salary per level. – Joel Spolsky

In this blog post, Joel lays out the details of his compensation system:  “Fog Creek Professional Ladder“.

Your career level at Fog Creek is determined as a function of three things: experience (number of years), the scope of your job (what your current job entails), and your skills (your skill level, regardless of actual responsibility). – Joel Spolsky

In the post, Joel further defines what experience, scope (there are 7 levels), and skills (there are 7 levels) mean. Of course, the criteria are not 100% objective, but at least Mr. Spolsky valiantly tries to remove as much subjectivity and insert as much objective fairness as he can.

How about your org? Is its compensation system still based on the 1920’s FOSTMA, employee-in-a-box, carrot-and-stick mindset? You know, the one where your salary is totally based on how much your anointed “supervisor” likes you?

Taking Stock

Every once in awhile, it’s good to step back and take stock of your team’s accomplishments over a finite stretch of time. I did this recently, and here’s the marketing hype that I concocted:

I like to think of myself  as a pretty open dude, but I don’t think I’m (that) stupid. The product infrastructure features have been redacted just in case one of the three regular readers of this blasphemous blog happens to be an evil competitor who is intent on raping and pillaging my company.

The team that I’m very grateful to be working on did all this “stuff” in X months – starting virtually from scratch. Over the course of those X months, we had an average of M developers working full time on the project. At an average cost of C dollars per developer-month, it cost roughly X * M * C = $ to arrive at this waypoint. Of course, I (roughly) know what X, M, C, and $ are, but as further evidence that I’m not too much of a frigtard (<- kudos to Joel Spolsky for adding this term of endearment to my vocabulary!), I ain’t tellin’.

So, what about you? What has your team accomplished over a finite period of time? What did it cost? If you don’t know, then why not? Does anyone in your group/org know?

Ammunition Depot

In preparation for a debate, both sides usually spend some time amassing evidence that supports their distorted view of the issue. Well, this post is intended to serve as a repository for my distorted side of an ongoing debate.

All the above snippets were strategically and carefully culled from various discussions posted on the wonderful Joel Spolsky and Jeff Atwood site:

Black And White Binary Worlds

November 17, 2009 1 comment

In this interview with the legendary Grady Booch, (InformIT: Grady Booch on Design Patterns, OOP, and Coffee), Larry O’Brien had this exchange with one of the original pioneers of object oriented design and the UML:

Larry: Joel Spolsky said:

“Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all. These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture.”

He also said:

“Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on…And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about,….and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup.”

Spolsky seems to represent a real constituency that is not just dismissive but outright hostile to software development approaches that are not code-centric. What do you say to people who are skeptical about the value of work products that don’t compile?

Grady: You may be surprised to hear that I’m firmly in Joel’s camp. The most important artifact any development team produces is raw, running, naked code. Everything else is secondary or tertiary. However, that is not to say that these other things are inconsequential. Rather, our models, our processes, our design patterns help one to build the right thing at the right time for the right stakeholders.

I think that Grady’s spot on in that both the code-centric camp and the architecture-centric camp tend to throw out what’s good from the other camp. It’s classic binary extremism where things are either black or white to the participants and the color grey doesn’t exist in their minds. Once a rigid and unwavering mindset is firmly established, the blinders are put on and all learning stops. I try to keep this in mind all the time, but the formation of a black/white mindset is hard to detect. It creeps up on you.

Black And White

Decision Making Stalemate

March 12, 2009 Leave a comment

Joel Spolsky is one of my favorite software philosophers. Joel sticks to fundamental principles no matter what the latest flavor of snake oil is being preached at the moment.

In this blog post, Endless Debate, Joel states:

“A terribly common error is having a debate over how something should be designed, and then never resolving the debate“.

He follows that with:

“In too many programming organizations, every time there’s a design debate, nobody ever manages to make a decision, usually for political reasons. So the programmers only work on uncontroversial stuff. As time goes on, all the hard decisions are pushed to the end. These are the most likely projects to fail.”

In addition to political reasons, I’d also like to add fear.  In alpha male dominated corpo cultures, fear drives the non-alpha members of the group. The titled alphas (a.k.a. managers) rule the roost and the non-alphas go silent when an alpha asserts himself – even if the alpha hasn’t got a clue on what the right course of action is.

Yes Master!

Yes Master!

I don’t agree with Joel’s assertion that “all decisions are pushed to the end”.  Because of schedule pressure and the fear of reprisal if the alpha’s instructions aren’t followed, the programmer(s) quietly implement the alpha’s horrendous decision in either code, design, or architecture.

The downstream ramifications of implementing the wrong decision get worse depending at which level of abstraction they are manifest. When the customer: gets the software, discovers the problem, and demands that it be fixed, the alphas are quick to blame the programmers since it’s often impossible, or not politically correct, to trace the problem back to it’s root cause – the bozo alpha’s poor technical decision.

Who said that life was fair?

Categories: management Tags:
<span>%d</span> bloggers like this: