Skip to content

Ask for no, don’t ask for yes

I think it is important to have a bias for action. Like anything else, this is something you can make a habit of. Moving forward allows you to make progress. I don’t know about you, but I’ve frozen up in the past not knowing what the right path was for me. Moving forward, even the smallest possible step, helped break that stasis.

One habit I like is to ask for no, not yes. Note that this is based on my experience at small companies (< 200 employees) where a lot of my experience has been. I’m not sure how it’d work in a big company, non-profit, or government.

When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.

Let’s see how this works.

Suppose I want to set up a new GitHub action that I feel will really improve the quality of our software. This isn’t whimsy, I’ve done some research and tested it locally. I may have even asked a former colleague how they used this GitHub action.

But I’m not quite sure. I want to let my boss know that I’ll be modifying the repository.

I could say “hey, boss, can we install action X? It’ll help with the XYZ problems we’ve been having.”

If you have a busy boss (and most people do), this is going to require a bit of work on their part to say “yes”.

They’ll want to review the XYZ problem, think about how X will solve it and maybe do some thinking or prioritization about how this fits in with other work. Or maybe they’ll want you to share what you know. It may fall off their plate. You will probably have to remind them a few times to get around to saying “yes”. It might be a more pressing issue for you

Now, let’s take the alternative approach.”Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.”

Do you see the change in tone?

You are saying (without being explicit) that you “got it” and are going to handle this issue. The boss can still weigh in if they want to, but they don’t have to. If they forget about it or other issues pop up, you still proceed. This lets you keep moving forward and solving problems while keeping the boss informed and allowing them to add their two cents if it is important enough.

You can also use this approach with a group of people.

By the way, the deadline is critical too. Which would you respond to more quickly, if it was Jan 15, all other things being equal and assuming a response was needed?

  • “I’m going to do task X.”
  • “I’m going to do task X on Jan 17.”
  • “I’m going to do task X on Feb 15.”

I would respond to the second one, which has a deadline in the near future. I think that is the way most folks work.

Again, pursue this approach for problems you feel are in the scope of your role but that you want to inform the boss about. It’s great when you want to offer a chance for feedback, but you are confident enough in the course of action that you don’t need feedback.

What I wish I had known when I was starting out as a developer

As I get older, I wish I could reach back and give myself advice. Some of it is life advice (take that leap, kiss that girl, take that trip) but a lot of it is career advice.

There’s so much about being a software developer that you learn along the way. This includes technical knowledge like how to tune a database query and how to use a text editor. It also includes non technical knowledge, what some people term “soft skills”. I tend to think they are actually pretty hard, to be honest. Things like:

  • How to help your manager help you
  • Why writing code isn’t always the best solution
  • Mistakes and how to handle them
  • How to view other parts of the business

These skills took me a long time to learn (and I am still learning them to this day) but have had a material impact on my happiness as a developer.

I am so passionate about this topic that I’ve written over 150 blog posts. Where are these? They’re over at another site I’ve been updating for a few years.

And then I went and wrote a book. I learned a bunch of lessons during that process, including the fact that it’s an intense effort. I wrote it with three audiences in mind:

  • The new developer, with less than five years of experience. This book will help them level up.
  • The person considering software development. This book will give them a glimpse of what being a software developer is like.
  • The mentor. This book will serve as a discussion guide for many interesting aspects of development with a mentee.

The book arrives in August. I hope you’ll check it out.

Full details, including ordering information, over at the Letters To A New Developer website.

The lifechanging magic of a separate work computer

Man performing magic trickFor a span from 2002 to 2019, I almost never had a work computer. There was one or two times where a contract provided a computer. But primarily my work computer where I did, you know, my work, and my home computer, where I worked on side projects and did my writing and personal internet access, were one and the same.

At Transposit, where I recently started, I have a separate work computer and a personal computer.

This is huge.

Here’s what it means. (I work from home, so boundaries are a bit more fluid.)

  • I’m no longer tempted to work (not even look at Slack) when I pick up my computer to say, write a blog post.
  • I can set down my work computer at end of the day and feel “done”.
  • When I pick up my personal computer to work on a personal project, I’m more focused.

Working is such a endorphin rush sometimes. Having a separate work computer and not installing any work software (not email, not Slack, not nothing) on my personal computer helps me maintain work life balance. This means when I’m working I am working and when I’m not, I am not.

 

What do I do when someone’s doing something wrong?

Driving in the rain
Uh, I think you’re in a little deep

Somewhere, sometime, someone will do something wrong. It happens more often than you think. (That person might even be me.)

When they do, I have an innate desire to correct them, to show them the benefit of my mistakes and to enlighten them. This is, in itself, wrong.

What should I do instead? A couple of things.

  1. Make sure I really understand the issue they are facing. Sometimes I can gain an appreciation for their choice once I have more information about the situation, and sometimes my questioning can cause them to make different decisions or to revise their thinking.
  2. Think about whether I have all the context. (This one’s easy; I don’t.) So remember to consider that from their perspective choices make more sense than from mine.
  3. I consider the ramifications of a poor decision. It’s better to let someone choose an obviously wrong course when the stakes are low. We’ve all made mistakes (I deleted an entire table from a production database!) and that’s the best way to learn. However, if the stakes are high, that means a discussion is more warrented.
  4. Contemplate my role. Is this a peer? An old friend? An ex-colleague? A mentor? A mentee? Someone I’ve just met? Each of these types of people have different tolerance for my opinion.

In short, rather than just explaining to someone why they are wrong, I need to stop and think about the entire context of the situation, including what I’ve missed, what the consequences of the action are, and my role.

Imposter syndrome

This article resonated with me. I became familiar with imposter syndrome when my SO spoke on it several times (she’s available to speak to your group if you’d like).

When you are deep in a discipline, it can be very easy to “know what you don’t know” and downplay your expertise. I often am asked to support desktop computers because I work in software (a la this post). But I know how little I know about the problem.

I think the issue is also exacerbated by the continuous flow of information that we are all offered by the internet. This makes it very easy to compare ourselves with what other folks choose to share (typically, though not always, their best side and successes). This makes me, I will be honest, feel inadequate. Why didn’t I learn more about k8s? Why haven’t I built a successful saas business? Why haven’t I worked at scale like that? Why haven’t I built a react native app? And so on and so on.

And when someone asks me “can you do that?” I always have that moment of fear and have to force myself to say yes.

My answer is to breathe, take chances, remember that failure is an option, and recall that while we see other people’s successes, we rarely see their failures. It isn’t fair to me to compare my “inside” with someone else’s “outside”.

“Someone Else’s Problem”

Fingers pointing at each other
The bad kind of SEP

I remember when I first heard the acronym SEP. It was way back in the dawn of my career, and a grizzled old contractor was talking about some aspect of a project.

“The flurbuz is janky. Welp, SEP.” – him

“What does that mean” – me

“It’s ‘Someone Else’s Problem’ now.” – him

“Oh.” – me

It has stuck with me all my career, but as I think about it a bit more deeply, I realized that there are two different kinds of SEP declarations–one good and one bad.

The bad type of SEP is when a problem doesn’t have an owner and everyone is ducking it. You know, that architectural original sin no one wants to face, or the client who is late but no one wants to cut off. If everyone is saying SEP, then the problem will never be solved. No good. The remedy here (in small cos, at least) is often to have everything “fall up” to the CEO. She can be the utility player who owns everything not otherwise assigned. Of course, tackling all of these orphan problems can prevent her from focusing on her main job, but at least she has the clout to make the problem someone else’s if need be.

The good version of SEP is also known as delegation. This means you’ve handed off the problem to someone else, whether on your team, an external contractor, or a client who wants to take some part of a project in house . And when you say SEP, you are trusting them to take care of the issue. This allows you to focus on other tasks. It does require you to trust that they can do what was agreed to. (They did agree to it before it became their problem, right? If not, this may be an example of the bad type of SEP, or at a minimum a chance for a ball to be dropped.)

For me personally, delegation is a skill I struggle with, even though allows me to be more effective. So saying “SEP” and letting the other party own it is a great way for me to practice that skill.

“Finding your purpose and living a meaningful life”

BatsA friend recently shared a letter from Hunter S. Thompson on finding your purpose. I found it to be quite insightful, especially on how he emphasizes a person should focus on “choos[ing] a path which will let his ABILITIES function at maximum efficiency toward the gratification of his DESIRES.” Choosing a goal is less important than choosing a way of life. I remember when I was chatting with my father about how he chose his career, he stated that in a world of choice you should choose some invariants and evaluate options based on those invariants. They don’t have to be job invariants, though sometimes they are. But if you don’t have a set of fixed standards, you run the risk of chasing after shiny objects again and again, or, worse, contorting yourself to some goal that previous you had settled upon. After some thought during this transition, these are mine:

  • Technology is the most fun and best when it helps people. I remember the joy of this in my first professional software project (mail merging insurance renewal letters). Watching people helped by software I built has been the highlights of my career.
  • No one every wishes they’d worked more on their deathbed. Work to live, don’t live to work.

It’s scary for me to lay out constraints because that means that you are ruling out possibilities. For instance, if a high flying Silicon Valley startup ever read this, they’d probably pass on my application due to my desire to not work 80+ hour weeks for the chance at winning the lottery. But that’s precisely the point. If the opportunity doesn’t meet my invariants, no matter how nice the paycheck or good the perks, it’s not a place that I’ll thrive.

PS Hunter S. Thompson also warns that every person’s advice is drawn from their experience and should be treated as subjecting–as Miles Law states: “where you stand depends a whole lot on where you sit“. Or to use Internet-ese: YMMV.

Leaving well

Bird leaving eggLeaving a company in a way that is fair to both you and your company can be difficult. When employed, we spend a large portion of our waking hours at work. You may be leaving a group of people you loved, a toxic environment, a place you’ve outgrown, or a place you’ve loved and just need to move on from for personal reasons. Because of the amount of time invested and the multiplicity of emotional circumstances, it can be difficult to leave well. Below are some thoughts on this career transition, however, I’m not writing about why you should leave, just how the process should go once you’ve made that decision. (Note that some of these apply to transitioning positions within a company.)

Before you are thinking about leaving

  1. Prepare to leave well before you think about leaving by documenting your decisions, processes and systems. This has the added benefit of letting you do better in your current position. When you write down how you do a task, it gives you the chance to review it and consider optimizations, as well as revisit it in the future and perform the task just as well. Make sure to date all documents. When you revisit a system or process, revisit the document.
  2. Watch how other departing employees are treated. Expect to be treated in a similar manner. Some companies want to usher folks out quickly (to the point of just paying their standard two weeks notice immediately and having them depart) while others will be more flexible. Some managers will treat departing employees with compassion and respect. Others may not.
  3. You won’t be able to effect change at the company once you have publicly decided to depart. If you want to effect change, stay at the company work within the system.

Once you’ve decided to leave

  1. Save and put that money into a liquid savings account. How much? As much as you can. This will make the transition less scary and allow you greater flexibility.
  2. Decide on boundaries and stick to them. Being helpful with the transition doesn’t mean you have to be a doormat.
  3. It’s always easier to find a job when you have a job. Think about reactivating old networks, inviting folks for coffee, and checking out the job market while you are still in your position.
  4. When you decide to leave, give as much notice as possible. Since you’ve been observing how folks are treated and you know your own situation, adjust for those factors. However, I’ve found letting managers know about my departure with plenty of notice ensures a smooth departure. Personally, I’ve given up to two months of notice.
  5. I’ve never had a counteroffer, but I’ve read that accepting them is a poor choice.
  6. Make a plan with your manager. Take point on this, as you are the person who knows your job best. This plan should be your first task after you’ve told your manager you are departing.
  7. Keep a spreadsheet of departure tasks including owner, date to be completed and description. Sometimes important things are overlooked. This is where having documentation (see step 1) is helpful, but also look at your to-do lists, your and calendar entries.

Telling your fellow employees

  1. Let the company control the narrative about when you are leaving, including when to tell the team. However, if you are approaching your departure date and no one on the team knows, push your manager to publicize it.
  2. You will likely have many reasons for your departure. Pick a major, true, banal reason or two and answer with that when team members ask why you are leaving. There’s no need to get into every grievance, reason or issue you had.
  3. Your decisions will have less weight once you announce your departure. This is natural; team members that are staying discount your opinions because you won’t be living with the consequences. Prepare yourself for this.
  4. Consider offering to consulting to the company if it makes sense for you and the timing is right. Charge a fair market rate. Realize that stepping into this role may be difficult emotionally.
  5. Once your exit is public, your focus should be bringing other employees up to speed so they can do your job when you’re gone. It may feel good to bang out one more bugfix or initiative and if you have time to do that, great, but your primary focus should be on documentation and knowledge transfer.
  6. Realize that this transition will feel momentous to you, but that it is far less important to everybody else (both inside and outside the company). A company should have no irreplaceable employees.
  7. Treat everyone as fairly as possible. Remember that you may be working with some of these folks in a few years’ or decades’ time.
  8. Be professional and courteous (I can’t think of a time when this is bad advice, but at moments of transition it is especially important).

Leaving a job is a very personal decision and will impact your career. Spend time thinking about how to leave well, treat everyone with respect and have a plan.

Questions to ask interviewers

Person in suitI’ve been doing a fair amount of interviewing lately (looking for work, not hiring) and there’s always that moment when the interviewer asks “so, do you have any questions for me”. Here are some of my favorite questions:

  • How long have you been working at company YYY? This helps me understand their perspective on the company. If they are new, they’ll have fresh eyes. If they have been at the company for years, it’s interesting to understand why they’ve stayed. This can also lead to a discussion of turnover.
  • What is a typical day like for this position? This helps me understand what the company emphasizes. This can also lead to a discussion of the development cycle (weekly releases, etc).
  • Who are your typical customers? When talking to a company, I always want to know who they sell to. This shows I have an interest in the company beyond just the tech work I’ll be doing. I want to hear words like “wide variety of clients”, “we find most of our customers by referral” or “we’re focused on niche YYY”. Of course I can always do research and see how the company markets itself and see if what I am hearing from the interviewer is consistent with how the company presents itself.
  • What do you do when folks are on the bench (if it is a consulting company)? “The bench” is where consultants who aren’t making money for the company are. What kind of projects are they working on? How often are folks on the bench?
  • Finally, what is the worst part about working at company YYY? This is the inverse of the “what is your biggest weakness” question that is sometimes asked. But every company has its warts. I’m probably going to find out anyway, but it’s good to ask and get the interviewer’s perspective.

What are your favorite questions to ask interviewers?

What is your BATNA?

When you are negotiating, you always want to be thinking about your Best Alternative to a Negotiated Agreement (BATNA). This applies in any negotiation, whether business, personal or even with yourself. When you have a better BATNA, you have more negotiating leverage and are more likely to get what you want out of it.

This is why when I was a contractor, I always had more than one client. Even if I was working with a good client who paid well, on time and was fun to work, I had more freedom if I had another client. Things might go south at the first client and I wouldn’t be out on the street. It’s also why I would always start looking for a contract 6-8 weeks before my current contract was finishing.

It’s why you should always get competing job offers. If you have a job offer and your best alternative is to keep job hunting, that’s not appealing. If, instead, you are choosing between two job offers, you are in a much better position. (No duh!)

It is also why it’s always easier to get a job if you have a job. The BATNA of declining a job offer when you have employment is, well, you remain your current position. Your current job may not be all that awesome (which is why you are looking) but for most folks being employed is a better alternative than being unemployed.

How can you use the concept of BATNA to improve your life?

First, be aware of the concept. Start to look at decisions in your life and think about the BATNA. Even small decisions, like ‘should I get coffee or nothing’? Or ‘what happens if I ask my wife to take out the garbage’? Or ‘should I ask for a raise’? In all of these cases, you can expect some kind of negotiation, and you can think about what the alternative is if that negotiation fails.

Second, take actions to improve your alternatives. If you are unemployed and want more leverage in the job hunt, start consulting. If your wife won’t take out the trash, can you improve your BATNA by making it easier to take out the trash yourself (maybe move the trash can into the garage)? Or building some kind of trash chute?

The concept of a BATNA is key to getting the most out of any negotiation. If you have good alternatives, you have more leverage to leave the negotiation, and if you don’t, you will need the negotiation to complete successfully.

More about BATNAs and salary negotiation here.