How DeMarco, Lister, and Cockburn Helped Me Find a Better Job (Part 2)
(Part 1 was posted yesterday.)
After four months of teamicide, Peopleware-style, I was ready to die. And when HR or my manager asked me, I told them the truth.
It felt good to tell the truth. And I did tell the truth, to a point, sort of. I was afraid to tell the whole truth. In my discussions with my manager and with HR, I definitely did not tell the whole truth. There was always some spin on it. You can see my reaction in a poem I wrote during that period:
Living Inside a Top
(With thanks to Tom DeMarco, Timothy Lister, and those whose names are withheld for their own protection.)
I’m not leaving.
But my resume is up to date.I’m just experiencing culture shock.
In a culture of oneupsmanship.But I’m not one of those who wash out.
And go on to bigger and better things.Reasonable hours: The average engineer works 56 a week.
And makes 87 thousand dollars a year.And the payscale is competitive.
With the third world.And fair.
To those rewarded with a cut.I’m proud to be one of the winners hired.
Then told what not to do.Proud to be developing a great product.
With second-class quality standards.Proud of my accomplishments.
Overcoming conjured-up crises.Proud to be one of the team.
That can’t get together on anything.I’m not leaving.
But my resume is up to date.
By August, my enthusiasm and excitement was gone. I had plunged into a deep depression. In retrospect, there are probably better ways I could have used my frustration, to turn it to more constructive uses. I could have networked with more people. I could have tried to get meetings with decision-makers. But at the time, I could only see that I was not where I wanted to be. And every time something happened to make me feel like crap, I vented by sending out another copy of my resume. I sent out a lot of copies of my resume. By the holidays, I was actually getting interviews.
Clear as crystal, black as ash
Caught in a dark depression, I was looking for any way to buoy my spirits. I got a copy of Crystal Clear: A Human-Powered Methodology for Small Teams, by Alistair Cockburn. It was on my wish list. I had read some of Alistair’s writing on his web site and on Ward’s Wiki, and I knew it intrigued me. No, it excited me. Through over a decade of research, he’s refined his approach. It’s not step-by-step, which means I like it. Yes, there are procedures he suggests in his book, but he notes that successful teams don’t follow one particular methodology. Rather, Crystal Clear lays out seven properties that successful software development teams do have. The first three are core; the other four bring a team further into the safety zone, making success even more likely. These properties became so important to me, I memorized them:
- Frequent delivery: Deliver a new release to actual customers at least once every 3 months. Every month is better. Every week even better. Some companies (e.g., MySpace) deploy new functionality every day.
- Reflective improvement: You keep looking back at what you’ve been doing, and keep doing it only if it works.
- Close communication: For small teams, Alistair upgrades this to osmotic communication. Sit close enough together so that you can hear your teammate talking about what he’s working on and the issues he’s facing.
- Personal safety: If something bothers you, you feel free to say something about it.
- Focus: Work on only one thing at a time. Go in only one direction at a time.
- Easy access to expert users: On-site access is best. These are not average customers. Nor are they software developers. These are people who understand the problem space.
- A good technical environment: A source-code repository that does what you need it to. Unit-testing and acceptance-testing frameworks. An adequate bug-tracking database.
I was delivering every other week to my primary customer, the Manufacturing department. (#1) But the rest of the organization delivered every quarter. Similarly, I reflected on the practices I was using, but the organization did nothing of the sort. (#2) Management would ask for feedback and make top-down policy changes, depending on what feedback it got. And this is important, but it isn’t reflective improvement. Reflective improvement is where the people actually doing the work decide which changes to make. And communication was a problem. (#3) Not osmotic. Not even close. The “team” was scattered from one end of the building to the other, separated by a whole ’nother department. It took minutes, literally, to walk the distance.
It gets worse. I already mentioned that I felt uncomfortable telling the frank truth regarding what I was going through and what I felt. (#4) And everyone was expected to be working on two projects and at least one fire. (#5) Now, the manufacturing engineer was my expert user, and he was on my side, and I was on his. (#6) But we used ClearCase for source-code control and ClearQuest to track bugs, both of which are a big-company nightmare. (#7) It took me hours of babysitting to fully check out and build my little project, and I needed to email the ClearCase department to have them label each released version. Yes, I could have had Release Engineering do this using their very elaborate automated tools, but even that was more trouble than its worth. And I also had to have the ClearCase department do things like create projects or branches. I seriously considered setting up a private CVS for small-scale development, but it fortunately didn’t get that bad. ClearQuest was definitely more trouble than it was worth. My manager kept asking me to put my to-do list into ClearQuest. I never got around to it. Sorry, Beth. Once, someone asked me why I was using story cards instead of ClearQuest. Clearly, he had never used story cards, and he may not have been using ClearQuest, either.
A year after the Company Y lay-off, a year almost to the day, someone posted to the ex-Y list that her new employer, Company V, was looking for a software engineer to work on an enterprise video system. I didn’t have the resume skills they were looking for, but she told me to send along my resume anyhow and she’d make sure the hiring manager saw it. So I did. Within a couple weeks, I had an interview.
Around that time, I was also in contact with a recruiter regarding a job working on the Linux kernel. I visited there for a short interview.
Then I got a strange voice-mail message from another recruiter. Now, it was usual for recruiters to call me, and some of them were pretty strange. One guy, for example, called me out of the blue and wanted me to email my resume before 5 that day so he could get me an interview at some company. That struck me as creepy. No one wants to rush an employment decision, neither net employer nor the employee. For him to be in such a hurry screamed desperation. I remember the phone call, but I don’t remember whether I sent my resume. Nothing became of that contact, anyhow.
But this one day, a certain recruiter left me a strange voice-mail. She had found my resume on Monster or Dice or some other web site, and she wanted to arrange an interview. Her message was bizarre, but not creepy. I called her back. What did I have to lose? She worked for Company C, a start-up that had a technology for providing Internet recommendations, like the book and movie recommendations you get on Amazon or NetFlix, only better. And she really did want to schedule a phone interview with the hiring manager. So I talked to him, and then they asked me to come in for a face-to-face interview, and then another face-to-face. Somewhere in there, they had me do a mini software project at home, solving a programming problem and emailing back the solution. I took the opportunity to push my love of Agile practices. I figured this would either disqualify me or endear me, and whichever it was, it was the reaction I wanted.
During these interviews, I paid special attention to the 7 properties of Crystal Clear and the issues in Peopleware. I even asked specific questions designed to give me a sense for how well each company’s process and environment conforms to these success factors.
So I was interviewing at three different companies. And I needed some way to manage all this information. I talked it over with a friend and confidant, and I created a spreadsheet. Across the top, I listed each job I was interviewing for, as well as my current job, and Company Y. Down the side I put factors such as technology, productivity, commute, salary, job stability, and Crystal Clear‘s 7 properties and several parameters from Peopleware. I weighted each factor as to how important it was to me, both in terms of my short-term and long-term goals. Then I graded each company on each factor using a scale of -3 (awful) to +3 (great), with 0 being nominal.
Unsurprisingly, Company Y scored well, 88% of my long-term ideal, 67% short-term. (Nominal is 50%) My then-current job scored 38%/31%. Company V scored 83%/75%. And Company C scored 71%/50%. My gut feeling was that Company V and Company C were about the same overall, and I was willing to fudge a few points here or there in order to believe it.
Then Company V made me an offer. I asked for a day to think about it, a very reasonable request. What I wanted to think about was whether Company C would also make me an offer. The next day, I got a voice-mail message from the recruiter at Company C. They wanted me to come in for the third and final face-to-face interview. I finally understood why they had been so generous with their interviewing policy. It was very easy to get an interview, but you had to spend 20 hours on their interviewing process. I wasn’t prepared to turn down Company V on the hopes that Company C would eventually make me an offer. So I accepted Company V’s offer. Once the paperwork was in-hand, I called back the recruiter at Company C to tell her that I had accepted a position somewhere else.
I’ve already written about how my manager took my resignation, classy. I’m still working at Company V, and I’m not depressed. I sometimes think back with fond memories to where I worked before. There are a few fond memories, but only a few. I learned a lot there, and I don’t regret the experience. But I am glad that it’s over.
[…] 9 back in 1987. That’s what I mean by “modern.” Here’s another one: What 3 characteristics must a software team exhibit in order to have any reasonable chance of success, according to […]