Confusing what you’re good at with what needs to be done

January 25, 2013 4 minute read

When you work at a big company, your role is specialized. On a day-to-day basis, you don’t have to venture far from your ‘comfort zone’ of core skills to accomplish your tasks (I know there are exceptions — I’m making a generalization). When you work at a small company, your role can still be specialized, but you have to cover a much broader area of tasks / skills. Your company has limited human resources to cover everything, and is best suited hiring people who are experts at their core responsibilities, yet are comfortable being generalists.

At my 10-person company, I do Engineering — but this means a variety of things depending on the day. This could mean writing back-end code one day, writing front-end code the next, writing deployment scripts, deploying infrastructure, doing customer support, fixing a computer, etc. The fact is, you have to cover a much broader area than you would cover at a big company — and you are certain to encounter tasks or problems which require a skill-set that you do not have. This is normally not an issue because of the following:

When something needs doing at a small company, it’s usually clear who should ‘do the doing’. For example, if a computer breaks, me or a member of my team will figure out how to fix it. Am I good at or trained in fixing computers? No. Is it my ‘job’? Yes – because my broad set of skills (debugging, problem solving, critical thinking, etc.) overlap the most with the skills required to learn how to fix the computer. Usually, these problems get figured out by the employee with the closest set of skills. However, when a task or problem requires skills which don’t tie closely enough with the existing skills of any employee, bad things can happen. In my experience, this results in one of a few actions:

You are completely ignorant to the fact that the task or problem exists in the first place - You have trouble identifying it, therefore it never gets fixed or worked on. If the task or problem is important enough, or the symptoms of not fixing it are painful enough, it will be identified — either by someone in your company or perhaps by an outsider / advisor. Symptoms of important problems bubble to the surface of a small company, and you have to find a way to diagnose the problem and fix it — it may just take you a bit of time to identify it.

The above isn’t so bad. You may waste time identifying the problem, and it may be difficult to find the right resources to fix it, but if it’s important enough it will bubble to the top — and if you’re disciplined, you may solve the problem (or at least move the needle in the right direction). A far worse scenario is the following

You identify symptoms of a problem, and without identifying the core issue or problem, you use employees’ existing skill-sets and ‘project’ them onto the symptoms - Your lizard brain doesn’t deal well with uncertain situations — in this case, you know something is wrong but you don’t know what it is, or you know that you do not have the relevant skill-set to fix it. This is an uncomfortable feeling. Here are some classic examples:

Your new software product isn’t resonating with the users. You are great at writing code, and not so good at talking to people. Instead of talking to potential customers about what problems they are trying to solve with your software, you write code to produce more features, hoping that the new features cause the users to like the software.
Your new product isn’t selling well. You are great at talking to people. You’ve talked to some potential customers at company ABC. They are seemingly excited, but not buying, so you decide to try to go up the ‘food chain’ in the organization, and talk to employees with more power. Instead, you might be better served re-evaluating the market segment or target customer if the buying signals from ABC are not there (requiring market research / analysis skills versus people skills)

This habit / pattern is hard to break. Using your existing tools and skills may not end up solving the problem, but will most likely quell your immediate feelings of being anxious and uncomfortable. Most of the time, the pain will come back — you are just deferring it, and the problem may be more urgent when it comes back. I am certainly not immune to this, and have to take conscious steps to recognize when it’s happening and avoid it — it’s an ongoing effort. I’m hoping to share some of my tactics for doing this in a follow-up post.