Ah, the exit interview. If you’ve had this experience, the first one probably arose in confusing fashion. You put in your notice and the team scheduled your goodbye lunch. At someone point, HR put a meeting request on your calendar that prompted you to say, “an exit what — what is this?” And then you had an exit interview.
Or, maybe you’ve never had this awkward experience at all so far in your career.
Whether you’re an exit interview veteran or googling it for the first time, though, I’ve got some pointers for how to handle this. I’ve given general advice on whether to quit a job and how to quit a job before, but this will be specific to the exit interview portion of quitting.
What Is an Exit Interview?
First things first. What actually is an exit interview? It’s not the most naturally intuitive concept, but you can probably infer what it involves from its name. Still, you might wonder, “what’s the point?”
An exit interview is a meeting that someone, usually the HR department at a decent sized company, schedules with you. It’ll generally happen the day of or the day before your departure, and it’ll take half an hour or maybe an hour if they really want to cover a lot of ground.
They’ll ask you a lot of questions, effectively looking for a private, Glassdoor-style review of the company. For instance, here are some blue chip exit interview questions.
Why are you leaving?
What did you like most about working here? Least?
How was it working with your manager and your coworkers?
Did you have what you needed to do your job effectively?
How could your manager improve? How could the company?
You get the idea. The exit interview is a standard practice for the company to collect and, hopefully, incorporate feedback from departing employees. Theoretically, it offers them a unique window into people’s real thoughts about the company, since they can speak freely and without consequence. Theoretically.
Another Monday and another successful Reader Question Monday. Usually I go with kind of a FIFO model for reader questions, but I bumped one that I’d just logged because it seems interesting. It concerns how to politely say no and how to know when to say no with clients and prospects. I’ve excerpted some of the question here.
I have a problem I have run into and it has to do with when to say “no” to work.
I have the chance to work on a project where my gut says I should not, not only is the project at least two months, it is at a rate that is too low for 1099. There are also many issues with current infrastructure and architecture which the owner wants to bypass. I guess my point is how do I turn down the work gracefully. In the past I have taken on this type of project and worked 12 hour days for 9 months to get it done, obviously, I don’t want to do that again.
I guess my point is, it is really hard to say “no” but it would be easier if there was a way to vet possible work with others [who] are knowledgeable about architecture so perhaps a way to audit upcoming work to see if taking on the work makes sense. How do you weigh the pros and cons? How do you get second opinions that are good, not random?
Extracting Themes Around No
This is a common situation for an independent. But it could just easily apply to anyone reading in the midst of a job search. Or even in even less dramatic fashion — maybe your boss pitches you working with a different group for a time.
Some common, recognizable themes emerge.
Saying no to things is hard, professionally. Our very wiring tells us to please, as illustrated by the phrase “the customer is always right.”
Saying no to things has real downsides. For employees it can mean lost capital and for free agents, lost revenue and belt tightening.
We see red flags, but have a predisposition to proceed anyway and hope for the best.
It’d be nice if we could get some insider information to tell us whether to heed the red flags.
In general, a framework for sizing up work would be good.
How to Politely Say No
I should note that I did dedicate a chapter entitled “The Art of No” to this subject in Developer Hegemony. That was more about how aspiring opportunists should steer themselves away from politically perilous situations, but some of the techniques certainly apply.
You never really want to just say a blunt “no” outright to a client prospect. Even if you think working with them makes for a terrible fit or they’ve rubbed you wrong during discovery, you’re running a business. You want a reputation for playing nice and being professional. Here are some general ways to demur on a prospective gig.
Say no, but offer to help them find someone who will say yes. In a sense, this isn’t “no” at all. You could almost think of it as steering them toward a lower tier offering. “This isn’t a great fit for me, but let me put you in touch with Steve, who…”
It’s not you, it’s me. “Given the budget you’ve allocated for this and your engagement model, I don’t think I’d be a fit. I usually direct projects like this and am used to incremental value delivery, and it appears you’re looking for an app dev staff augmentation.” I suggest doing what I did here — subtly phrase it in a way that positions what they want as a budget offering. This will prompt them to start making concessions if they really want you.
Say that your calendar presents a conflict for the work.
You can be direct and honest and just say that you don’t think the work is a fit for what you offer. Careful here, though. Direct and honest sounds like the best (and to some, only) option, but it puts a lot of clients and prospects in a defensive posture. It may leave them with a bad taste in their mouths.
Or, finally, you can get them to say no instead. More on this later.
It occurs to me that I spend a good bit of time weaving narrative into my posts. I tell personal anecdotes to ground stories, and I add in a good bit of figurative language. But it’s always fairly superficial. I don’t generally get heavily into my own story. As an introvert, this makes sense, since talking extensively about myself or receiving compliments feels awkward.
But I’ve received a number of requests over the years like today’s reader questions. So today, for reader question Monday, I’ll talk about this subject. Here’s the reader question.
I’m interested in how you’d describe what a week, month or a single engagement in your shoes is like. I know a couple of people who are consultants and see them going out to coffee shops, meeting with clients to socialize and making pretty good money. I’d like to read an article about what your routine is like. Nothing where you give away client specifics or anything. I just think others who read your blog are taking in what you write about, putting what they find is useful into practice but are left wondering in their head ‘I wonder what work is like for Erik?’.
Before I dive in, it’s worth noting a couple of things. First, I have to address this at different times because my life has changed a lot. And, secondly, it really depends on what kind of consultant you are, so I’ll speak a bit to experiences other than mine as well.
I’m predicting a fairly long post on this one, so buckle up. I’ve always found that it’s the absolute most difficult to be brief when I’m trying to explain myself, as if I’m constantly mounting a legal defense or something. Anyway, here we go.
Modern, Reclusive Erik, A Day in the Life
For the last six months, most of my days look pretty similar, weekday or weekend. I usually wake up around 9 and shuffle to the kitchen for some coffee, preparing to sit at my computer. Morning time is usually writing time. This isn’t for my personal edification or for my books, but for my growing content marketing business. That typically carries me through lunch and a little after.
In the afternoon, I’ll spend some time handling emails, corresponding with clients, and working on the businesses, but that usually stops at some point. For the last six months, I’ve been living in a house on a lake, featuring usually great weather, great scenery, and generally great marrow waiting to be sucked out of life. So I go outside. I jog, I kayak, I do a bit of yard work, I fish, or I make a fire in the fire pit and just enjoy my surroundings. The weather is getting a little suspect for that here in late October, but we’re getting ready to head south for the winter. So I expect this routine to continue.
After enjoying life a bit, I eat dinner and then either call it a day or go back to work, depending on how I feel. This is typically non-writing “deep work.” Minimal distractions after 8 PM, so I can get in a solid block of concentration until I go to bed around 2 or 3 AM. Sometimes I also write during this time window. Other times, I’ll work on software for my codebase assessment practice or my own longer form content marketing.
Why Does This Matter?
You’ll notice what I don’t really talk much about here: consulting.
That’s because I don’t honestly do much of it anymore. And that’s by design. I have engineered and hacked my life deliberately and specifically to look like this.
When I do consult these days, the clients seek me out, and I agree only after a heavy round of disqualification.
Is it a short term engagement (a few weeks or less)?
Will it pay enough really to be worth it?
Can I do it from anywhere?
Is it a high value, high leverage engagement for the client?
A “no” to any of these questions and many more results in a “no thanks” from me.
I give you this vision of my life, mostly “retired” from serial consulting in order to set the stage for the rest of the post. Consulting is fun, rewarding, interesting, and lucrative when you do it well. But it’s also a treadmill unless you specifically make it not one. It’s the career equivalent of an interest only loan unless you’re careful.
Happy Monday, everybody. To help prolong your procrastination over morning coffee just a little bit longer, I’ll offer you the latest installment of reader question Monday. Today, I answer a question that many reading my blog probably have: should I incorporate?
Here’s the actual question, as I recorded it.
What is the cost/benefit of incorporating? Should I just keep paying for domain/hosting through my [credit card], or would it be worth the hassle to move to a real business?
As you can see, I’ve generalized a bit in order to make it more broadly applicable. But I’ll speak to all salient points through the post.
Should I Incorporate?
Yes. Alright, post over.
Just kidding. At least, I’m kidding about the “post over” part. I do think that you should incorporate.
“But you don’t know anything about my situation, my job, or my life!” you protest. And, while that’s true, I’d argue that I don’t need to know anything about it, assuming you’re a knowledge worker. To make my case, let me now speak explicitly to costs and benefits, as requested.
Another Monday, another successful reader question Monday. Today’s question is about learning on the job. Let’s take a look.
This is more of an app dev shop question than a consulting question, but here goes.
Say you’re consulting for a client and the client has a specific need for some app dev work which they ask you to do. That work requires you to use a technology that’s either completely new to you, not quite in your line of specialty, or you haven’t used in several years, but you’re constrained in some way to use this technology and to do the project you would need to “ramp-up”.
The question is: do you bill the client for this “ramp-up” time or do you take the hit against your own personal time to come up to speed? Does it make a difference in the response if it’s a legacy technology that you may never use again (FORTRAN) vs. a “hot” language that it would benefit you to learn (Python)?
First of all, for everyone else, here’s what the reader is referring to about consulting vs. app dev. I’ve written a good bit about how writing software for someone else isn’t “consulting” no matter what people might call it. So the question concerns either app dev shops or app dev freelancers.
Learning on the Job: The Quick Answer
I’ll start by answering the question at the tactical level. Should you bill for this ramp-up time? Absolutely, as long as you can negotiate it and you do so in good faith.
The last time I agreed to app dev work, I dealt with something like this. I’d worked with the client before, and they liked my work. I had domain knowledge and we had a good rapport, so they engaged me for some work. I told them that I had to learn an important technology as I went, and they were fine with this added cost. They viewed it as worth it.
Contrast this with a different situation. Imagine you’re a Ruby on Rails developer and you need some work. So you answer an RFP for help with an ASP MVC site, knowing nothing about ASP MVC but claiming you’re competent. That’s pretty much the opposite end of the spectrum, and obviously problematic.
So start with the requirement that you’ll be frank about anything you need to learn to execute on an engagement. The matter of who bears the cost of that learning then becomes a matter of negotiation as part of the contract. And, that should make sense, since you’ll always have to learn something to help a client. If you need the gig more than they need you, you might need to spend unpaid evenings learning a framework. If they really need you and you’re on the fence, you can require that they include your onboarding as part of the deal.