Attitude > Skill

The Wattpad team is growing and we’re hiring for many roles. Recently, the team was in the position of having to choose between two highly qualified candidates for a single role (a great problem to have). One applicant had more experience or skill but the other one had a better attitude.

So who did we pick? Well here’s what I told the team:

“All things equal, always choose attitude over skill and experience. Skills can be learned, but it is hard to change one’s attitude.”

Of course, all candidates need to meet certain skill-based criteria, whatever that may be. It’s hard to hire someone in finance if ‘spreadsheet’ is an unfamiliar term. It doesn’t make sense to hire an engineer who has never written a line of code before. These are somewhat facetious examples and IRL the bar would be set much, much higher, but you get the point.

Hiring a person who may be less experienced but possess the right attitude can be a worthwhile investment and a risk worth taking if you believe you can get the candidate 80% up to speed in 3 months and 100% up to speed in 6 months.

With the right attitude one can overcome any obstacles, but when people have the wrong attitude, getting them to fit into the company can be mission impossible because of the inevitable cultural clashes and teamwork disruption. It can drag down the performance of the entire team. People with positive attitudes can solve problems proactively rather than reactively. While it’s hard to quantify, they can greatly increase business velocity and team performance.

Choosing attitude over skill is a guiding principle that I have been using for many years and has served me really well!

The next time a candidate walks through your door and doesn’t exactly have the right skills or experience, ask yourself if they have the right attitude.

It’s Your Decision, Don’t Dodge

When you work at a startup, seeking advice and gaining buy-in from the broader team can help you move faster … until it becomes a crutch.

Recently, I bumped into an entrepreneur I invested in. He’s making some changes to the direction of his company and after explaining them to me I pointed out some of the potential issues. He immediately asked me: “So, do you want me to revert to the old plan?”

It was the wrong question to ask.

I explained to him that it doesn’t matter what I want. As CEO with all the context, he’s the only one who can make the decision. As an investor, I’m not thinking about his business 24/7 but he is. It’s his company and it’s his decision what he does with it (and only his decision). Investors should share their experiences and opinions but they shouldn’t make decisions that affect the business.

Not long after, I had an investor friend contact me about one of his portfolio companies that’s going through a pretty rough patch. My friend said: “The CEO now blames the board of directors for making the wrong decision.” My ears perked up. This was a red flag and I told my friend as much.

A company’s board of directors only has one decision to make: Hire and fire the CEO. Inexperienced CEOs have a tendency to defer difficult decisions to the board or even other people in the company. It’s not uncommon to hear a newbie (or unconfident) CEO say something like “My recommendation to the board is …” This isn’t helpful. All this does is enable inexperienced board members to jump in and make decisions out of context. It’s tragic really.

Obviously, I’m not suggesting that there is no value to be gained from consulting with your board: Every CEO has blind spots and can benefit from another perspective. But in the end, what happens in the business is always the CEOs call.

And it doesn’t always have to be the CEO who holds the ultimate decision making ability (nor should it). I remember speaking with a senior leader at Wattpad and the person said: “I would advise we do this …” I quickly reminded this person that they are the head of the business unit and the only person accountable for it. It was an important decision with huge implications across the company, so of course, I expected this person would engage with the broader team to think through the different scenarios and make sure all the bases were covered, but at the end of the day, the person was the leader, not an advisor.

These three conversations illustrate one critical point. Whether you’re a co-founder, CEO, technical lead, department manager or even individual contributor, you are the presumed expert in your role so don’t dodge making tough decisions. Remember: You are not an advisor to your own job.

Don’t Be a Parasite If You Want To Be A Disruptor

I spoke with an entrepreneur whose company is building a new, disruptive product for the education sector. One of the challenges he’s facing is that none of the company’s co-founders have worked in the education sector before. He wondered if he should hire someone with some relevant experience.

Another entrepreneur friend of mine is building a tool that is catered to the public sector. The company is struggling to scale as a business. The sales process is too slow. The product is becoming too specific for one sector.

In both cases when these entrepreneurs asked for my advice, I told them: Don’t be a parasite if you want to be a disruptor.

There are so many verticals out there that still have not been fully transformed by the Internet — education, public sector, book publishing, the list goes one. But it’s extremely hard to transform any industry if you have a lot of dependencies with the old systems. You can’t think out of the box. Your sales cycle is too long. And often you end up with a product or a service that is incremental at best rather than revolutionary.

Now, there’s nothing wrong with that. In fact, a lot of people have built great businesses by providing incremental solutions like consulting services to the government. But, if you want to build something truly transformative and net-native, then you have to stay as far away from the traditional systems as possible and draw closer to your end users or customers.

If you want to create something truly game-changing and be a disruptor, you can’t begin the journey as a parasite.

Embrace tension to move even faster

As a startup scales, it’s natural for tension to creep up among different teams who are working on disparate objectives. Either of these conversations sound familiar?

Showing users more ads can help generate more revenue, but it could also hurt engagement. Do we optimize for revenue or engagement?

We have a limited budget. If we spend it on A, B, and C we won’t be able to pay for X, Y, Z. What should we choose?

The best way entrepreneurs can embrace and then ease tension among their teams is to establish a set of principles. Principles can help teams avoid indecision and move fast.

In the example above about serving ads at the expense of user engagement for instance, if the team has previously established that ad experiments can’t impact engagement by more than X%, it becomes easier for them to test different combinations of ads to drive the most revenue without negatively impacting engagement.

Establishing principles streamlines decision making, eliminates unnecessary meetings and propels the company forward. Everyone knows what to do and understands how much (or how little) leeway the team has.

Of course, there will be times when you may not have a principle to fall back on. That’s when the teams representing the conflicting priorities need to escalate the matter further and involve an arbitrator. Most times decisions are reversible and having an arbitrator can resolve issues quickly. In the world of startups, a quick decision always trumps a slow decision (or worse, no decision at all).  

Tension is natural and a sign your company is growing. But as your business grows and becomes more complex, decisions aren’t as straightforward as they used to. Creating a set of ground rules that inform your team’s priorities and outcomes can help avoid unnecessary confusion and conflict.

The other thing managers should remember

When I first became a manager, one thing that was extremely difficult for me to get used to was delegation. When an employee gets promoted to manager, and even after they realize they now have a different and distinct role, it can be hard to let go of the day-to-day work.

Why? In many cases, the person who gets promoted to a leadership or a manager position is someone who is an awesome individual contributor. To be an awesome IC, you need to be very good at getting stuff done.

But as a leader or a manager, you need to focus on asking other people to get stuff done.

You need to make sure your team is working on the right stuff to achieve desired outcomes. As a manager, you can’t do the work of other ICs – it no longer in your job description.

This is counter-intuitive and crazy hard because it is the polar opposite of what awesome ICs know so well.

Speaking from experience, when a leader does the work of an IC it can be very demotivating and become counterproductive. On the other hand, when a manager delegates the work and trusts individuals to get the job done it can be very motivating.

As a leader, you should remember that it is far better for you to focus on figuring out what your ICs should do (and why), and let the ICs figure out how to get the job done (and then, do it).

The one thing new managers forget

I first started managing people when I was 26. Four years later, I was managing a team of 30 developers. On paper, I was fantastically successful; in reality I should have fired myself.

At the time, I thought that in order to lead a team of awesome developers, I had to be an even more awesome developer. I worked frantically to write more code than anyone else not realizing that I accepted a new job the moment I was promoted – and writing code wasn’t it.

It’s something that almost all new managers forget. Being a manager isn’t a glorified version of your old job: it’s a brand new and completely different role. It requires a different skill set and attitude. As a manager, your responsibility is to ensure your team works on the right things at the right pace to deliver the right outcomes.

In my 30s, without any management or leadership training under my belt, I didn’t have a clue how to direct such a sizeable team. As a newbie manager I made mistakes and added further complexity to an already chaotic organization. It was only years later when I truly realized how my lack of leadership contributed to the chaos. I still cringe thinking about it.

I’m not proud of those mistakes, but I learned a lot from them. My biggest takeaway was that being a manager isn’t about rolling up your sleeves and working alongside your team (although there are times when this matters); it’s about understanding where your organization wants to go and deploying your team and resources to get you there.

If you’re a new manager who’s still doing the same work as before, step back and delegate. And, congratulations on your new job.

Out with the old (product features)

The new year means a fresh start. With that in mind, I urge product managers, designers, engineers and developers – anyone who helps develop a product, really – to think critically about the features they are designing. Have you thought about what features you’ll say goodbye to in January? Because killing features now means better business velocity for the rest of 2019.

As a product and its codebase grows, it is not uncommon to see an increase in technical debt. This debt may be because usage of a feature has scaled beyond its original design (you can’t expect a Toyota Corolla to reach 300 km/h no matter how many turbochargers you add) or because a feature, and subsequently it’s code, is used in more ways than originally intended (like a lawn mower turned into a snow blower – it works, but it shouldn’t). Often, technical debt accumulates because old or infrequently-used features aren’t retired.

There is a cost of removing these old features, of course, but removing features is significantly cheaper in the long-run than maintaining relic code. When you support outdated or unused features you’re also allowing security, performance and backwards compatibility issues to arise.

I remember reading an article about Evernote that claimed 90% of their features (and they have thousands of them) are used by less than 1% of their users. Eventually, the company’s velocity grounded to a halt because every simple feature update required numerous discussions across the company before the change could be implemented.

So make no mistake, it is desirable and even essential to purge old product features. Here’s how in three steps:  

  1. First identify a feature that you think should be retired. Then measure the usage of that feature. The data won’t lie. If usage is low, proceed to step two.
  2. The numbers may not tell you the whole story. Talk to some of the old-timers who have more context than you and understand why the feature existed in the first place. In many cases, you’ll be surprised by the reasons.
  3. Decide to purge, modernize or maintain the status quo. Make a decision and then execute your action plan.

Years ago, I was part of a team that dedicated six months to find bugs and purge unused features. On the surface, it seemed we were spending an inordinate amount of time and effort ‘looking in the rear-view mirror’ and not working on things that took the product forward. In reality though, those six months pushed the product much, much further ahead. By the end of it the product ran faster, the UI was cleaner because many unused features were gone, and annoying glitches were finally addressed. The app went from 1-star to 5-star in a few months without adding anything new.

It’s a good reminder: Less is more. Simple is good.