Install Old Versions of Ruby Gems

I am setting up a new machine that has some old software requirements for my project this week. A quick tip if you need gems to be installed at an older version (if they are still available).

Use the -v version flag to specify which version you want.
sudo gem install capistrano -v 1.4.1

If you’ve got the newer versions of the capistrano gem, no need to fret. You can specify the version you want to use on the command line like this:
cap _1.4.1_ deploy

You can alias that to something else in your bash profile by adding something like this:
alias cap1=’cap _1.4.1_’

Executive Tech Summaries

Is anyone out there interested in some one page tech summaries? I had several occasions where they would have been useful this week and I am ready to write some if they don’t already exist.

They would have basic terminology and usage info as well as pros and cons for an organization.

Comment with what tech you would like covered in the comments.

Books For Business Analysts

I was involved in a discussion recently about books that were good for Business Analysts. Here’s a list to get people started.

The Inmates Are Running The Asylum by Alan Cooper

About Face 3: The Essentials of Interaction Design by Alan Cooper

Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition by Steve Krug

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

The Visual Display of Quantitative Information, 2nd edition by Edward R Tufte

Writing Effective Use Cases by Alistair Cockburn

Patterns for Effective Use Cases by Alistair Cockburn & Others

The Responsibility Virus by Roger Martin

You’ll notice that most of these are design books. As an analyst, it’s often the case that you are going to have to look at an old business process or application interface and design something new. It helps to know the limits of the technologies you are working in, but it is better to get a general understanding of design principles in general so that you’ll never be caught off guard.

Note: All Amazon link proceeds go to charity. If this turns out to be popular, I’ll write up some more book lists my colleagues and I think are good to have on your bookshelf as an Analyst, Dev, QA, PM and consulting in general.

On Agile And Backend Integration Projects

Another consultant recently told me that she doesn’t believe Agile works for backend-type projects. She said that Agile just introduces too much change and she can’t keep up with the process. She also mentioned that there were studies emerging that said as much, but when pressed, she couldn’t find any.

Now, I’m all for Agile taking criticism. It’s about People over Process, so if there’s some process hurting people in that equation, then it needs to be examined and possibly fixed. I also believe that building working code iteratively is vastly better than talking about it for months and then sitting down to write code.

Our client, like all clients, likes to change their mind about what features they want in the application we are building. This other consultant and I are on two different teams within the project and she’s doing legacy integration work and we’re doing essentially greenfield development that will have to hook into her systems. As our client changes their mind, it’s pretty easy for us to keep up while she struggles to make changes to database models, ETL processes, and other bits of code in her work.

Thinking about what’s going on, I think I’ve come to the reason why it’s hard for her to change and easy for us. We’re using tools and processes that allow us to change rapidly. Her tools are hindering her from making rapid and iterative change and her processes might be too rigid.

Notice that I’m not telling what tools each of us is using. I don’t want to get into a debate about what tool is better, only the type of tool that allows people to be empowered to change at a moment’s notice and then change their minds back again. My hypothesis is that her tools are hindering her from keeping up with our clients. She’s certainly capable of doing the work, but I feel like processes that her tools make her go through are getting in her way.

What advice can I give to someone in that position? I’ve mentioned stronger scope control to her, greater communication between our teams, and getting another analyst to help with the workload of deciphering the legacy systems she has to integrate with. These are all people processes because I’ve seen other consultants use the same tools in my Agile projects and fit in with the process relatively comfortably.

Agile may not work for all types of projects, but I believe it can work here. It may just be that we need better tools.

Marc Andreessen on Innovation

I’ve been reading Marc Andreessen since I heard about his blog from Fred Wilson. There was a great post about retaining good people a few weeks ago that has stuck in my mind ever since.

Things not to do when trying to retain great people:

Now we’re getting into personal opinion, but for what it’s worth…

Don’t create a new group or organization within your company whose job is “innovation”. This takes various forms, but it happens reasonably often when a big company gets into product trouble, and it’s hugely damaging.

Here’s why:

First, you send the terrible message to the rest of the organization that they’re not supposed to innovate.

Second, you send the terrible message to the rest of the organization that you think they’re the B team.

That’s a one-two punch that will seriously screw things up.

Instead, focus on boosting the innovation culture of the entire company.

There are a ton of other tips in there, some of which we used to tell our client companies at NeoTactix. It’s always nice to be reminded of great advice, particularly about what to do with great people that want to make the move to a startup.

Make Your Process Lean, Not Your Workforce

I was reading an article by Robert X. Cringely today called Lean and Mean noting that IBM Global Services is laying off thousands of workers and possibly up to 150,000 in the US.

Go ahead and read the article. It makes me really glad that I work for a company that extols virtue and taking care of their people before making money. At ThoughtWorks, we don’t have this level of employee count, so I can’t say what would happen if we did.

We’re also trying to become more lean, but we are doing it in a different way. We’ve already adopted agile as core to the way we work a long time ago. This time, we’re applying lean to our processes and tools, not to our people. That’s the important point. When you treat your employees like family, you do things differently.

Hundreds of thousands is a big family and I’m sure that the execs at IBM GS don’t know the large majority of them. I guess that makes it easy to cast them aside in the name of pleasing Wall Street.

Lifeguarding and Firefighting

I took a kayaking trip this weekend on a lake near my house and an old lesson popped into my head. While I was working at NeoTactix, we had little firemen bobble-heads with our pictures on them. It was an allusion to the fact that we were always fighting fires in our client companies. I remember asking for a new bobble-head in addition to my fireman. I asked for a lifeguard.

I was a lifeguard when I was younger and the lessons that I learned training there were unforgettable. As a lifeguard, you don’t just react to problems, you scan your water and look for potential problems. You are taught all sorts of strategies to minimize mistakes and keep everyone safe. While at work, I applied the skills I learned as a lifeguard to protect our clients from things I could see on the horizon.

Lifeguards overlap the areas they are watching so that there’s always a second pair of eyes on any given situation. This worked very well for us when we adopted this strategy. For example, if I had a press release I was working on, I made sure to always run it by the managing partners to ensure I got everything right before publishing it. Another example was to watch companies in our portfolio that could indicate problems for the other companies that were our clients. Because each of our clients were minding their daily business like they were supposed to, they couldn’t always look up and see trends that could affect them. Part of our job was to see these things coming and warn (or save) them if needed.

Lifeguards constantly scan the waters without focusing on one particular area. When you are sitting up in the tower, it can be easy to focus on just one person or a group of people. It’s called tunnel vision. The safest thing to do is to look for typical problem signs, make a quick head count, and move on to the next group of people. This lesson translates to business really well. As a CEO, you have a bunch of things you have to worry about. Payroll, internal initiatives, investors, competition, and growing the company are just some of the huge tasks you have to take on. Making sure you give each their due attention is important or you become reactionary and will never get to focus on looking forward for your business.

Lifeguards ignore unneeded distractions and maintain constant focus. If you’ve ever seen a lifeguard at the beach, they always have their eyes on the water. They will walk up their towers backwards to stay facing the water. People will come up to talk to them and they’ll rarely look at them, instead focusing on watching the water. It’s not that they are trying to be rude, but that they are focusing on their job, not someone who just wants to chat about Baywatch. In business life, there is plenty to keep you distracted from doing your real job. Surfing the internet can waste whole days of productivity. Worse yet, spending your whole day on something that _seems_ productive like rearranging the office furniture can make you feel like you are doing something good, but is usually just a way to procrastinate on something more important that could be done. When you learn to control the time you spend on unneeded activities, all sorts of time opens up and you’ll find much more time to run your business.

Lifeguards cover each other’s water when an emergency comes up. Emergencies happen; it’s a fact of lifeguarding as well as business. This is a hard lesson for some businesses to learn, especially in cyclical situations like cashflow or business development. Lifeguards typically have a phone they pick up or button they push to signal the other lifeguards that an emergency is happening in their water and they are taking care of it. The other lifeguards immediately respond by calling for backup and covering the lifeguard’s water while they are making a save. Some businesses will see emergency situations and rally their employees to help fight the fire. While this is good, they often leave other parts of the business unattended. That’s a quick way to becoming a firefighter and only reacting to your business instead of acting to control your business.

Lifeguards and firefighters have their place in business. Both serve useful functions, but if you have more lifeguards, hopefully you won’t need so many firefighers.

How To Interview With Me

I have been doing a bunch of interviews lately. My second one this week (thanks recruiting!) was tonight and it didn’t go as well as it should have.

Here’s my typical interview strategy for when I am interviewing Business Analysts for ThoughtWorks and some tips to help you if I ever get picked to interview you.

1. Show Up On Time And Be Ready

I know that you are busy, but this isn’t college. You’re such a hot shot Analyst that you could land a job anywhere, right? Well, first you are going to have to show me that you want _this_ job. Our recruiting department sends out a confirmation to you usually 3 days in advance of my call. I also get a confirmation sent to me. If I can’t reach you on the phone number you give on the day of the call, I’ll usually try again about 15 minutes later. If I can’t reach you, I’ll send a note back to recruiting to reschedule the call. However, if I reach you and you are not ready to take my call and don’t have a good explanation (I’ll understand if the house is on fire or something), that’s an automatic *No Hire*. My reasoning for this is simple: it takes nearly an hour to do an interview with you and you know about it in advance, so you should have that time blocked off. If you don’t treat that time as important, it means you won’t treat our clients that way.

2. Prepare

Do your homework on ThoughtWorks. Find out how we like to work; our company culture. Read our website, learn about agile, visit some blogs, talk to us at conferences. I’m going to ask you some questions about what you know about the company, so show me that you did a little bit of work and I’ll be happy.

On the flip side, I do almost no preparation for my interview with you. All I know is your name, phone number, and what position we are hiring you for (that determines my questions, more on that later). I get all of your information like your resume and notes from other interviews you’ve had with us, but I don’t look at a single bit of it before the interview. This is by design. I don’t want to know anything about you that will influence my decision to hire you.

3. The Interview

I have a pretty consistent interviewing style that helps me be more objective about your skills. ThoughtWorks has a set of questions that they like me to ask and I also mix in some of my own. Here’s how the interview typically goes:

  1. Ice Breaker
  2. ThoughtWorks Questions
  3. Domain Question From Your Most Recent Position
  4. Random Domain Question
  5. Questions For Me
  6. Wrap Up

Ice Breaker
I start off by letting you know how the interview is going to go. I care more about your thinking process than you getting everything 100% right on my questions. By this time, I still haven’t looked at anything about you.

ThoughtWorks Questions
The ThoughtWorks questions are mostly softball questions so that I can go over some logistical things about the job. Are you alright with lots (and lots) of travel? Have you worked with Agile professionally? Why do you want to be a BA? There are a bunch of questions, but they give me an idea of what to ask you further. I’ll go into something in detail if I get the sense that you are stretching the truth. While you are answering my questions, I’ll pop open your resume and look at your most recent job and title.

Domain Question From Your Most Recent Position
By now, you should be warmed up and I have a good sense of what I am going to ask you. From your most recent position, I’ll ask you something about the business domain. This way, I get a sense of how well you can understand what a business does. If you’re a TWU candidate, meaning you are just out of college, this question changes to ask about some of your classes. I’m looking for a deep understanding of what you are talking about. I’ll dive into small details to make sure you really know your stuff.

I may also ask you about some things you have done for your previous job (or school). Special projects, clubs, whatever. I want to see that you haven’t simply gone to work or school and taken the minimum to get by. It’s for your own good because you’ll get burned out quickly at ThoughtWorks if you aren’t into the work.

Random Domain Question
This is my favorite part of the interview. I’ll ask you about a domain that has nothing to do with business and run through a few exercises with you to see how well you can understand what I am talking about. It’s always something off the wall and will have nothing to do with what you have done before, but that is the point. I’m looking to see how well you can adapt to a new situation and think on your feet. I’ll play customer roles and ask you to elicit questions about things I want to do. I’ll try to trip you up and see how you recover. This way, I can get an idea of how you will do with our clients.

Questions For Me
This is the part of the interview where you get to ask me anything you want about ThoughtWorks. Some people trip up here because they think the interview is over. If you are really serious, you will have some questions about how we do our work, what our people are like to work with, etc. I also get to sell you a little bit on what it’s like to work here.

Wrap Up
The whole process takes 45 minutes to an hour. I let you know about the next phase in the interview process and that our recruiting department will be getting back to you within a week or so. After that, I hang up and write the last of my notes about you and read them over again. I make them readable by someone other than myself and then I make a decision about whether or not to pass or pursue.

4. Pass Or Pursue?

After the interview, I have a pretty good idea of how I am going to recommend you. I ask myself lots of questions like: Is this person smart and do they get things done? Would I want to work with them? If the answer is no, it’s a pass. If I wouldn’t work with you, then I wouldn’t expect anyone else at ThoughtWorks to. If I feel like you aren’t smart enough to walk into a client and immediately start to figure out what is going on, that’s also a pass. If I have a good feeling about you, I’ll mark you as a pursue and send you on up the chain for our intense face-to-face interview process.

I hope this was helpful to future candidates. I’m looking for aptitude and attitude in the way that you present yourself to me. If you’ve got both, you’ll have no problem being a ThoughtWorker. Good luck.

UPDATE: If you are looking for a referral, please email me at jhoms at thoughtworks dot com and I’ll point you to the right people.

Make A Name Map

This is an article that I have seen go past in my RSS reader a few times lately: Meeting Tip: Learning Names. It is something that I have used for years, but this is a great writeup of what to do. Simply stated, make a little “map” of the meeting table you are at and write everyone’s name along with any other information you might need next to them.

I’ve taken it further a few times and actually written notes under each person’s name so that I knew who came up with the idea. It was a common practice for me at NeoTactix where we would meet a ton of new companies all the time and I could _never_ keep their names straight in my head. I find it equally important in my consulting life at ThoughtWorks, but rely on it less when I see the people that I meet every day and their name eventually starts to stick in my head.

Wink is Great

I used the awesome tutorial and presentation software Wink today and it worked surprisingly well.

I was testing out the newest version of SIFR (also awesome software) and found a few bugs. Screenshots weren’t going to be enough to show the problem, so I created a simple screencast with Wink.

You can see the results here.

I can definitely see myself using this more in my work on client projects for ThoughtWorks.

← Previous PageNext Page →