Tag: soft skills

  • Lateral Skills Are Core Skills

    Lateral Skills Are Core Skills

    We can consider so many things both in our professional and personal lives as value exchange. The most obvious case: I exchange 40 hours of my time each week for a set amount of money that lands in my bank account each month.

    As a business, we do the same thing. We commit our engineers to spend their time on whatever our clients need them for, and in exchange, we receive an agreed-upon rate for each hour of that effort.

    In fact, I often use that frame when describing how we perceive our contributions. We aspire our clients to be happy with the value we deliver for the price they pay for the whole team.

    What Is Value?

    Now, the tricky part in these examples is value. While we can easily assess how many hours anyone spends on a task, the time doesn’t automatically translate to value. What’s more, it’s not even purely a matter of how one will spend that hour.

    I can work on an activity that has only certain odds of success. If the outcome ultimately emerges as a failure, no value will have been delivered. The reasons for that may be entirely outside my sphere of control.

    As an example, think of all the effort I invest into helping a potential client improve how they will approach building their new product just to see them choose a different partner. In this case, my work has not yielded any value for Lunar.

    However, even if I work on something that we assume to have intrinsic value, it’s still tricky. Let’s look at adding a feature to a product. (And yes, I know that not every feature is value-adding. In fact, there are some whose net value would be negative.)

    Assuming the feature I’m building will have a positive effect, the big question is how big of an impact and how much our client values it. That question is almost universally highly challenging.

    Most of the time, we can’t know the answer upfront. We need to build the thing to be able to validate the outcome. Most of the time, however, we don’t try to check that anyway. Even if we did, most of the time, the early validation will now give the complete picture.

    Think of The Shawshank Redemption. Its theatrical release was largely a flop. And yet, over the years, it gathered a strong fanbase, still keeps the #1 position as the best movie ever at IMDB, and eventually, it at least paid off production costs. Not a bad outcome for a flop, eh?

    While there obviously is a correlation between the opening weekend box office and the eventual financial success of a movie, we can’t precisely know the financial success/failure just after the first few days.

    The same goes for value assessment in most of the knowledge work. You could just as easily consider whether paying an employee any specific salary yields a valuable (enough) outcome. And the smaller chunk of work you look at, the more the mileage will vary.

    Making Value Exchange Work

    We use two basic coping mechanisms to work around uncertainty about value.

    The first one is ignoring the actual value altogether and sticking with our early assumptions of what we expected it to be. It’s like deciding to build that feature because “it will bring us so many new subscribers” and never looking back. Sure, before committing to the development, we might have asked for an estimate. If it was acceptable enough (and the work didn’t take much longer), it was the last time we did any assessment of the work.

    We thought it would bring us a ton of subscribers, and it was a sound decision to pay $10k for that. Oh, and since we already paid for that work, who cares whether it actually brought a single new soul to our solution?

    Well, I’d say this means giving up on a ton of learning here, and that’s of huge value by itself, but I clearly must be wrong, as very few product organizations do any post-release validation.

    The second way to dodge the uncertainty of value is by looking at a bigger whole. I don’t try to assess whether an engineer has been productive during every single hour or day. Heck, I’d be perfectly fine with a slower week, too. However, I want to know whether their long-term performance justifies their salary.

    By the same token, I want the whole team working for a client to deliver good value for money in the long run. So, if we look at the weeks or months of work of the whole group, we are happy with the value of everything they deliver (of course, in the context of what that effort costs, again, in total).

    In extreme cases, you could look at movie studios or VCs investing in startups. They are happy to weather plenty of bad investments as long as that one movie or that one startup yields a 100x or more return.

    Lateral Skillsets

    We all make one subconscious assumption here. That is, even though we exchange different things, they are of similar value for both parties. If we ask for $90 an hour for our developers, that hour would be priced roughly a similar way, whether by Lunar’s client or me. Or rather, we would price the skills our client rents for that hour similarly.

    This assumption, though, often doesn’t hold true.

    To stick with the engineering/software development context. When our potential clients want to assess our team’s skill set, it will almost always be heavily skewed toward technical skills. After all, when you hire developers, they will do development, right?

    But let me redefine the situation here. Imagine you seek someone to turn your idea into an MVP. You have two candidates with very similar technical skills. However, one builds their experience by working on many different small engagements, including several very early-stage products. The other spent big chunks of their time working on very few large and complex solutions.

    Which one would you choose?

    I bet most of us would go with the former over the latter, as we’d deem their experience more relevant. This relevancy, however, stems from a lateral skillset. It’s not an ultimate value. It’s value in the context.

    Product management skills may actually emerge as the most crucial for that role, even if we don’t consider it so upfront. At the early stage of product development, building the wrong thing is rarely salvageable. Building the thing wrongly, on the other hand, can typically be saved.

    If we had considered a different gig, we might have chosen differently.

    This is but one example of lateral skills that may make or break any endeavor. A broad range of people skills, project management savvy, business context understanding, and more may be similar game-changers here.

    And yet, without the specific context, the broad market would largely ignore those traits. Even within the context, they are most often omitted.

    Asymmetric Value Exchange

    The lateral skills are what change the economy of the whole value exchange. The job market would value two similarly technically skilled developers, well, similarly. After all, across a wide variety of challenges, they will provide comparable value.

    However, within the early stage product development context, the first one will deliver something extra. They wouldn’t be working extra hours, their code wouldn’t objectively be better quality, they wouldn’t be faster.

    Yet something that costs nothing extra to that developer–their lateral early product management skills–would be highly beneficial for the product company.

    That’s what breaks the simple economy of value exchange. I add to the mix something that’s of little to no cost for me but gives the other party a big upside.

    In other words, I give up nothing while they gain a lot.

    Suddenly, the whole deal has so much more wiggle room, which can be used to make it more attractive for both parties.

    Not only that, though. It also generates additional options for value delivery. Our developer may use their time building a feature that ultimately will not help. However, thanks to their experience, they can also suggest (in)validating the whole part of an app prior to committing to development. That, in turn, may lead to much more significant savings.

    In this case, exploiting lateral skills makes the value exchange asymmetric. Why is it important? It’s because whenever you can find a partnership with an asymmetric value exchange, it’s a plain win-win scenario for both parties.

    Since lateral skills typically create these scenarios, we should pay much attention to them.

    Side Skills Are Core Skills

    If I looked for a technical partner to help me with an early-stage product, I would primarily be looking for stories about discovery work, building MVPs, validation, etc.

    As a matter of fact, I’d be explicitly asking for failure stories. I mean, we know the data. New products do fail. So, if the only thing someone has to show is a neat streak of successes, you can be sure they’re in a fantastic realm.

    One of my mantras is, “Many of our past clients paid us to fail, so you don’t have to. You get all the experience we got from that as a part of the package.”

    These lessons do not fall into what’s commonly perceived as “core skills” for software development teams. And yet, we do consider them core. We shine most when we’re able to utilize those side skills.

    So, go figure out what constitutes those lateral skillsets in your context. These are the core traits you should be looking for, whether hiring or choosing a partner in your endeavors.

  • Hiring for Cultural Fit

    I definitely don’t keep the count but I believe that throughout my career I run more than a thousand interviews and hired way more than a hundred people. I have a confession to make: vast majority of these interviews were run poorly and many of those hires, even the right ones, were made on wrong premises.

    I started hiring when I worked in a 150+ big company. Not much later we were absorbed by our big brother – a 3000 big organization. The hiring model I’ve seen there is something that you would have easily guessed. A set of questions aimed to verify technical skills, occasionally augmented by a couple of puzzles to show how the candidate thinks. That’s exactly the pattern I followed when I started running interviews myself.

    I think it took me a couple of completely wrong hiring decisions till I started paying much more attention to non-technical traits. I mean, stuff like communication skills seem obvious. The question is how much weight you attach to the fact that a candidate is a good or a poor communicator. And of course communication is only one of a numerous so called soft skills.

    Experimentation with the interview process made me focusing on tech skills less and less over time. I could still name hires, who eventually didn’t fit.

    It took more than ten years and a bunch of people who I considered good fit in one organization but not in another to realize one crucial thing. There is such a thing as fit between an individual and an organization. The easier part of this equation is the former. We all can be described by our traits. At the same time, which is less intuitive, a company can be described in a similar manner. So what would we get it we written down all the company traits?

    A company culture.

    If there’s a mismatch between individual’s traits and a company culture there will be friction. You can tell that verifying past hiring decisions. You can tell that looking at people already functioning within the company as well.

    OK, so again, what are we typically focusing on when recruiting? Technical skills. Does it help to figure out whether a candidate would cohabit well with the rest of a team / a company? Would “very little if at all” be a good guess?

    It may be easier with a couple of examples. Imagine a small company where people are pretty open in front of others, rather outgoing, ready to help each other on the slightest signal that such help is needed. Imagine that an extremely skilled developer joins such a group. The guy is closed, not very sociable and feels that his contributions are best when he’s left to work alone without interruptions. Is the company well-suited to leverage the guy’s technical skills?

    Imagine a team working on a kind of a death march project. No matter how miserable the future looks like the whole team feels they are in it together. They work after hours to save as much of the project as possible. Well, almost. There’s one guy who isn’t that much into this whole engagement thing and basically just punches his clock every day. He may even be the most skilled person in the team. Would he be valued by other team members? Would his contributions be really worth that much as his skills would suggest?

    If we looked for a root cause of the problems in either case we wouldn’t discuss the guys’ technical skills. It’s the fact they’re misfits. What makes them misfits though? It isn’t a comparison to any single person. It is about how the whole group behaves, what values they share and how they interact with each other. It is about how the guys are perceived on this background.

    These are parts you should focus on if you care about how the whole group performs. In fact there’s more into this. Hiring a misfit cripples performance of both the misfit and the group.

    Unsurprisingly hiring for technical skills and technical skills only is a good way to hire a misfit.

    My challenge for you here is to answer the question how you actually verify traits that go beyond technical skills. Feel free to share them in a comment.

    There’s one thing I hear very frequently when I talk on this subject. It goes along the line: yeah, sure, go hire people who fit your company culture and know nothing about coding whatsoever and good luck with that. Of course I don’t advice hiring lumberjacks as software developers because of a simple fact of a cultural fit. I simply point how much we overestimate value of pure technical skills.

    Most of the time there is some sort of a base technical skill set that makes a candidate acceptable. I also believe that the bar is significantly lower than we think. In other words there is a good enough level beyond which a hiring decision should be made basing on very different premises.

    I don’t try to discredit tech skills here. Actually, I value them highly. I simply believe that it is way easier to develop one’s programming skills that to change their attitude. That’s why the latter is so important during recruitment.

    That’s why I see so much value in hiring for cultural fit.

    An interesting side discussion is how the existing culture influences individual’s behavior and attitude and how the individual affects the culture. This is something company leaders can use to steer (to some point) culture changes or to form (to some point) new hires. It works though only as far as the mismatch isn’t too big. Anyway, it’s a side discussion worth its own post.

  • The Role of Manager

    I took part in a very interesting discussion today. We were talking about criteria we should use to appraise leaders and managers in the organization. The most surprising part, at least for me, was discussion about notion of line manager among disputants.

    It came out that we considered average functional manager as anything between pure-manager to person who does 90% of engineering work mixed with 10% of managerial tasks. That’s a variety of options, isn’t it? As you may guess I supported rather the former than the latter.

    Well, if I’m such an opponent of letting people do what they used to do before they were promoted to management, likely coding if we talk about software teams, what I think they should do all day long? In other words what is, or should be, the role of manager.

    Leader

    This vague term describes first and most important trait most managers should have and only few have. If I’m a team member I expect my manager will show leadership and charisma. I want to be ignited to follow his ideas. I need to be sure he knows why and where we are heading. I have to see him around when problems arise. I eager to be managed by someone I’d like to follow even if no one told me so. A good manager is also a good leader but these two are not the same. What a pity it isn’t common mixture.

    Coach

    Help newcomers with learning the organization. Help inexperienced with gaining experience. Help everyone with growing. Help those with problems with fixing them. Easy? No, not at all. First, you need to know who needs what. Then, you need to know how to reach people so your helping hand won’t be rejected. Finally, you need to work carefully and patiently sharing your knowledge in experience in a way which doesn’t frustrate or dishearten people. Repeat when finished.

    Shield

    As a line manager you have some senior management over your head. This is a bad news. Actually there’s usually a lot of crap flying over there and, because of the gravity, it’s going to land down on heads of your team. There will be blame games. There will be pointing fingers. It is your time. Be a shield. Take enough bullets on your chest for the team. You’ll earn respect. You’ll earn a bunch of loyal followers. And that’s how you earn your spurs.

    Advocate

    As a manager you’re also an advocate. Devil’s advocate to be precise. You have to present and defend different decisions made up there, in the place where only C-level execs are allowed. Sometimes these decisions you won’t like. But for your people you’re still the face of the company so don’t play the angry boy and act like a man. We don’t always do what we want. After all, they pay you for this, remember?

    Motivator

    Sometimes everyone needs a kick in the butt to get back to work at full speed. It would be quite a pleasant task but unfortunately kicking butts is used as a metaphor here. It’s all about motivation. And I have a bad news here, there’s no easy answer for a question what motivates people. You have to learn each of your people individually. Oh, forgot to mention, it takes quite a lot of time to learn what drives all these people.

    Adviser

    Yes, an adviser. Not a decision-maker. At least not unless you really have to make a decision by yourself. People will come to you asking different things. Well, they will if they think your opinion may add some value and you’re capable to understand what the hell they are talking about. Of course you can guess or shoot or use magic 8 ball but you better learn (oh no! more learning) what the problem really is and help your team to solve it. Note: it is different than solving it for them, even if you know the answer. If an association which comes to your mind is delegation I must praise your reasoning.

    Now if you are done with those and still have enough time to keep up your outstanding engineering skills, please do Mr. Anderson. Unfortunately chances are good it is enough to fill more than a full working day so you’d have to choose between focusing on your management or technical skills.

    And if you happen to spend two third of your day coding, well, I dare to say you aren’t a manager I’d like to work for. Your people would say the same, but you don’t talk with them so you don’t even know. After all there’s no time to chit chat, you have to code, right?