I don’t actually remember how I found this book. It somehow got onto my Amazon wish list one day, and it was one of those things I bought because I needed to top up an order above $25 to qualify for free shipping. I don’t remember what it was that I bought with this book, but I doubt it was as impressive as The Nomadic Developer.
It’s funny, because I tell people that I got into the consulting world back in 2008. After reading this book, I realized that I actually started in consulting back in 1994. My very first job in IT was technically at a consulting firm, albeit a very large one, (the one started by Ross Perot back in the sixties and famous for making everyone wear blue suits everywhere they went). I worked on a couple of very large accounts, so it seemed like I was just a developer in Corporate IT, but in reality, I was a consultant. I left that company in 1999, and moved on to real Corporate IT, working for an airline maintaining their revenue management systems, and later on to building and maintaining the fight operations systems. We owned those systems from cradle to grave, twenty four hours a day, seven days a week. They were horribly difficult to change. There was a tremendous amount of tribal knowledge in every subsystem, and many were already five or six years old when I started, and rewrites were impossible. By the end of my 8.5 years there, my technological skills were atrophied to the point where another year or two, and I would have been completely unmarketable outside of that industry vertical.
I jumped (back) into consulting in 2008 with little idea of what true consulting was. I wish I had had this book at my disposal back then. Not that I would change my decision – the leap into consulting has done wonders for my skills and my career. I have no doubt that making the move, when I did, was absolutely the right decision for both me and my family, and I’d like to think it was the right decision for the company I work for as well.
But in The Nomadic Developer, Aaron Erickson goes into wonderful detail of what to really expect from technology consulting, how to identify good (and bad) companies, how to survive, and how to thrive in the consulting world. He talks about how to maintain both your position and your passion during both good and bad times in the economy, and how to avoid career limiting moves. At the very least, had I read this book while still working for the airline, I could have avoided a couple of interviews that would have led to positions that I was not right for. My trouble-radar kicked in on those before I accepted, and I count myself lucky. By the time I had finished chapter two of The Nomadic Developer, I had already identified those firms as being one of the ‘Seven Deadly Firms’, and hiring on there likely would have tainted my consulting experience for the rest of my career.
The Nomadic Developer is not only for people who are thinking of becoming consultants. It’s also for consultants who are fairly new to the game, and will help you to stay out of trouble as the economy changes. I think it should also be read by owners/senior management of consulting firms, if only to avoid uncomfortable moments brought on during interviews by people who have read the book and are asking some of the hard questions Erickson suggests. Most of those questions I would be a little uncomfortable asking during a interview, but I see the value in at least trying to ask them. It’s not always the response that is important, it’s the way the response is said that will tell you if the employer is going to treat you as a partner / investment or a warm body / cost.
Here are some of the questions he suggests:
- What is your annual revenue?
- What is your (target) profit margin?
- What is your exit strategy?
- What’s the value of the sales pipeline?
- What is the sales process?
I’ve done a lot of interviews of candidates in the last few years, and even though I have been on the technical side, I’ve never been asked questions like that. I’m actually pretty horrible at technical interviews because I hate trivia questions. I prefer to ask about experiences and expectations and to evaluate the personality of the interviewee. If someone was to ask questions like that, and I hadn’t read Erickson’s book, I would perceive them as intelligent but aggressive. But after reading his book, I would think that the candidate truly is trying to find the right fit. If I’m a consulting company senior management, I’m reading this book to make sure I’ve got my crap together so I don’t lose out on good consultants because I look like an amateur. I’m also doing an honest assessment of my company to see if I am making any of the mistakes Erikson lists in the Deadly Firms chapter. Unless my goal is to build an unsuccessful company, I want to be active in fixing these situations, even if it is just an employee perception. I don’t think too many people want to be unsuccessful at running their own company.
Another point Erickson makes is about passion for work, and how to maintain that during hard times, especially when the client you are working for is not in an industry you find appealing. I spent three years working for a client that did direct marketing… sending out junk mail and running those annoying call centers that call you during dinner. I slept on my office floor multiple nights while doing system upgrades, and let me tell you, that was really hard to justify to myself after a while. That experience left me quite cynical when it comes to working on projects I don’t fully believe have societal value. In the long run, that cynicism can be a career killer in consulting. It can kill your passion for software development, and once you’ve lost that, it can be very difficult to get it back. Employers, and especially co-workers, notice when your passion withers. In tough markets, not every job will be life-fulfilling, but Erickson suggests that taking pride in the work you do on each project will preserve the passion, and from there, passion will generate positive results and better opportunities in the future. It takes a while to build up the resume, and there is something to learn on just about every project.
I’m giving this book a big, big thumbs up, and making sure that my wife, who is a project management consultant, also reads this book. Very little of the book is specific to programming, and those bits can be read and parallels drawn with most other industries and job types.
Do yourself a favor, and read this book, and then get your coworkers, and your boss to read it too. If the suggestion is negatively received, you may already be working at one of the ‘Seven Deadly Firms’, and its time to find your exit strategy.