“Empower engineers and technical leaders with the tools and mindsets to perform at their highest levels, so that they create the meaningful impact they’re capable of.”

That mission started with me writing and self-publishing The Effective Engineer three years ago. And then recently I co-founded a company Co Leadership (coleadership.com) to focus on leadership development full-time.

To be good at sales copy also involves many factors, like interviewing your prospective customers, understanding what language they use to describe their problems, listening for what dreams they actually have, addressing their concerns by establishing credibility, and having a strong desire to help them achieve their goals.

Good sales copy doesn't aim to "trick" people; it aims to show that the product being sold will achieve the prospective customer's goals.

The reason I'm sharing this perspective is that many engineers do look down on marketing and sales copy as something that's automatically "bad." And that automatic association does them a disservice.

They write awesome code or build awesome products and features that could add so much value to the world, but they then just expect anyone to automatically see that value. They don't take the time to understand what their users' problems might be, to share how what they built might solve those problems, and to "market" their solutions. That mismatch of supply and demand ends up being a missed opportunity, and sadly, this happens all the time.

I understand your perspective about engineers undervaluing marketing and sales skills, but I think it's an example of short term thinking. Credibility is a currency, internet never forgets and I would never build credibility like this because I do not know how this will limit my future possibilities.

Here's a simpler ordering of operations:

1. Start with the most valuable, highest-leverage thing you want to focus on. 2. Figure out what the riskiest bit of that thing is. Focus on de-risking it. 3. When you're de-risking (or more generally whenever you're just doing that thing), start simple. Beware of adding in unnecessary complexity.

Preparedness is what we can train ourselves for, and preparedness also has the effect of making you more able to see and take advantage of opportunities that come your way. And to someone who doesn't know how much you've prepared, it appears that you're just luckier.

I'm currently working on commercialising a pharmaceutical manufacturing monitoring device[1], based on the work from someone's PhD.

[1] https://www.phyllon.at

One of my favorite stories from Drew was that when he first started Dropbox, he created a 4-minute demo video showcasing the product that functioned as an MVP for the product. The video drove hundreds of thousands of people to their site and grew their beta mailing list from 5,000 to 75,000 people overnight.

On the outside looking in, skeptics might have thought that it was nothing new. But the MVP provided validation around what future customers actually thought.

My main takeaway from that story (and that I share in the book) has always been to validate your ideas early and often, so that you can get more signal on whether the assumptions you're using to shape your behavior are accurate.

More about the Dropbox story here: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-pro...

I've actually got a bit more of a personal connection to DropBox - Drew was active on HN before founding it, he posted it here before posting it on Digg [1], and he took me out to lunch right after they'd gotten their Sequoia seed round and asked if he could convince me to be employee #2. At the time, I was working on a casual game creation startup with a friend, and I declined, #1 because I felt I couldn't leave my cofounder and #2 because Drew had a startup, I had a startup, and at the time it wasn't clear which of us was actually more likely to be successful.

Before you laugh, consider the environment in Feb 2008 (when this occurred). My cofounder was a consultant at Monitor Group, where he'd been researching the casual gaming space and had run across multiple reports saying it would be a $200M, $1B, etc. space (market research reports never agree on market size, because they're largely bullshit). Kongregate had just raised a Series A from Reid Hoffman, Jeff Bezos, and other luminaries. Max Levchin had just raised $50M for Slide the month before. Zynga had just been founded but Farmville hadn't come out yet. The Web 2.0 bubble was in full swing, AJAX and Javascript were the new hot buzzwords (I had just ported Arc - PG's pet programming language, which HN is written in - to Javascript, which is what caught Drew's interest in the first place), and as you can see from the first comment on DropBox's "Show HN", anything that required installation of software was considered a non-starter. And our product concept let everyone, from teenagers to retirees, build their own games instead of being at the mercy of a studio & professional developers.

My lesson from how things evolved - learned much later, and I'm probably still grasping the implications - was to preference personal experience over industry zeitgeist and prestigious research reports. Drew's personal experience with the problem domain and his 75,000 beta signups were worth a lot more than the famous people and industry market research reports around the problem domain we were solving. And this insight has actually saved me a lot of time & aggrevation chasing fads that people realize are bad ideas 4 years in.

But this is not obvious to someone just starting their career, probably because they don't actually have all that much personal experience to draw upon, and because it takes a certain amount of chutzpah to hear about all these eminent people saying "This will be the next hot thing, you better get in now!" and think to yourself "Actually, sounds like bullshit to me." Personal experience is also inherently limited because you've only got your own and it takes years to build; it turns out that the set of problems you can viably solve is actually quite small.

[1] https://news.ycombinator.com/item?id=8863

It really hammers home how hard it is to disentangle good & bad advice and how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.

> how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.

“For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.” CVS!!!

When you are working on any idea, there's a temptation to be a visionary about your product's impact. But nothing good comes out of this feel-good bullshit. It's better to focus on solving meaningful problems that exist today, rather than being hopeful that they will become relevant tomorrow.

Really? If you don't have that filter you'll be prey for every investment scam that comes along.

More of a personality thing. If you would pitch Dropbox or Facebook to me today, I would consider it bullshit just like back then. Nice little niche maybe but certainly no Unicorns. Who would put sensitive personal information into the cloud?! Obviously not much of a market.

My buddy wrote a book on VRML.

Otherwise, many top tech companies now open source software that they've written internally, oftentimes with their own websites. And there is also a growing trend for them to actually maintain the software they open source as opposed to just throwing it over the fence.

Think of companies that have a strong engineering brand, and then just search for what open source software they're released. Pick whatever seems most aligned with your interests.

Some examples:

Google: https://opensource.google.com/projects/list/featured?languag... Facebook: https://code.facebook.com/projects/#backend Stripe: https://stripe.com/open-source Airbnb: http://airbnb.io/projects/

A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful:

"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."

Unfortunately, almost all computer science education nowadays focuses on pure technical skills and hiring interviews at most tech companies also focus on the technical skills. The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.

Here's the article: https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...

I have a lot of those soft skills. But no one is going to hire me as an engineer because I don't have the coding skills.

It comes in dead last because you have to have high level coding skills to get your foot in the door. Everyone has that. Getting ahead in that crowd means having others assets on top of being a good coder.

It is a little like saying "Height doesn't matter for success as a basketball player. As long as you are at least 6'6", what matters are these other attributes." Yeah, sure, cool. It isn't a strong differentiator for the in crowd because you can't even join the crowd without it.

This result seems a bit unsurprising. People who work at Google would already be in the top n-th percent in terms of STEM expertise. If everyone you hire is 'above average' then being a bit better than that has marginal gains and other factors would lead to your success. I'd be curious to see how this plays out at smaller firms where they cannot afford to hire the top-end STEM expertise.

A related point, though, also rings true. Soft skills like being a good coach and effective listening are so underinvested in, that even marginal improvements in those skills lead to huge differences in success.

I see this in engineering leadership workshops that I've run with Jean Hsu and Diana Berlin, where even teaching a handful of coaching and listening skills can have a transformative impact on participants.

If you're interested in future workshops, you can sign up to hear about them here: https://effectiveengineer.typeform.com/to/cDMeZu

For experienced hires, we'll do deep dives on technical projects that they've worked on. Sometimes, I'll frame these as "Suppose I'm a new member joining that team. Bring me up to speed." These interviews focus on whether the candidate can clearly articulate concepts, explain the big-picture motivations, defend decisions they've made, understand complex technical problems, and stay humble and share lessons learned.

For manager interviews, we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.

Be careful with this approach. If you're not paying candidates for their interview time, you're not allowed to use their work. Big companies go to great lengths to demonstrate that the entire interview is for the purpose of a hiring decision and nothing more. This is to limit liability. Your approach is very dangerous for your company and if an unhired candidate's idea shows up in your product, even if you arrived at that result independent of the interview, the candidate has a strong case against you in a lawsuit.

If you're doing interviews like this, be sure you've discussed all the nuances with your company's lawyers.

Or do you also want something where all your interviewers will give the same candidate the same score, and that's robust against being gamed?

The former is easy: "Tell me about a time you helped a colleague improve their performance", "What do you think makes for a good coach?" etc etc.

The latter? I've never seen a convincing way of doing it.

It's like conducting an analysis on skills of all F-1 drivers, and what differentiates champions from remaining pilots. I'd expect a lot of mindset-related and soft skills to appear as key indicators, and "driving abilities" to have a minimal gap between drivers.

A dumb example is from cycling, people frequently over-practice the ability to sprint at the end of a race but what is really important is the ability to conserve energy throughout the race... Really dumb example, but I think it is somewhat similar.

I believe promotion committees try to see measurable impact, which at least to me sounds like soft skills unfortunately don't help much..

Additionally, the results that make it to the media get way exaggerated compared to the actual underlying study. This is compounded by the fact that Google picks and chooses what it publicizes, so what you’re seeing has a huge PR/political filter.

Assuming by computer science education you mean the actual classes within that major, I don't see this as a problem. I didn't take CS classes to learn interpersonal relationship skills. Other college classes and the college experience in general does help with that though.

If talking about tech programs, I also think that isn't necessarily something they can or should focus too much on, as that's not their focus. The assumption is you have that part already figured out. If not, go through a course that focuses on that in addition, I'm sure you'll get a better education in that topic that way. It probably is appropriate for them to stress it's important though, even if they don't offer much in the way of rectifying it.

Or, spend a lot of time on self-directed self improvement in one or both those areas. The resources and programs exist for that as well.

> and hiring interviews at most tech companies also focus on the technical skills.

I agree on this. Companies should hire people that will function within their system. Hiring the smartest guy from MIT's class of 2017 sounds all well and good, but if they can't function well with your existing 100 employees and they leave after a year or two (or worse, they cause a few other people at your company to leave every year causing high turnover), the chances of them somehow making up for that are probably extremely low.

Supposedly they added this after receiving feedback from industry that the biggest problem was that their graduating students couldn't properly communicate.

Altogether it felt pretty appropriate, since it was still focused on CS related concepts.

I'm not sure I'd really call that unfortunate. CS education isn't about making you a more well-rounded person: It's about giving you a basic education in Computer Science.

Similarly I don't really lament that CS programs don't have a course in basic financial literacy, even though it would be incredibly useful.

These are really topics that should be addressed much, much earlier (empathy in particular is something we should start teaching children as young as possible) and should be mature ideas by the time people reach college-age.

> The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.

To mirror the other comment, I hate to say it but if you're a software engineer at Google you're likely already a "top" engineer.

You're trying to explain what differentiates the top 0.1% from the top 1%, but I'm not sure it's a super useful distinction for the other 99%. For them, investment in hard skills might actually be considerably more fruitful (and land them that Google job in the first place).

Maybe not, I'll admit I could easily be wrong on that.

I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much.

I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work. And back them, I ended up just avoiding them. Knowing what I know now, even a single lecture on tools for more effective teams or for having hard conversations or giving feedback would have made those projects SO much more valuable in terms of being learning experiences.

Given that effectively using your CS education will involve collaborating with other people to some degree, I do believe that giving more emphasis to the non-technical skills that play a big role in your career would have a hugely positive impact.

I guess my point is more that primary school really should've prepared you for this: Group dynamics and how to handle these "group tensions" is more of a basic learning skill that we should be developing very early on.

I'm not arguing that this is a useless skill to teach, more that it's far more expensive and much less effective for MIT to be teaching you these skills and not MyTown elementary/middle/high school.

One of the fundamental duties of a middle manager is to worry about group dynamics, team effectiveness, group communication, etc.

If the engineers are now doing all of that as well, what's middle management doing?

("Nothing, same as always" is of course the snarky answer)

For example, there's an assumption that what works well at Google would work well for other tech firms. And yet Google is in the rare position of having gained so much from its early golden goose that success in terms of producing viable, valuable products and services has been almost irrelevant among most of its workforce for most of its existence.

There's also an assumption that the staff at a big, famous organisation like Google are generally better than those elsewhere, and therefore that being successful in such an organisation is something to be emulated. Working at one of the Big Five seems like a default aspiration for some parts of the tech world, and there's definitely an element of hero worship for those who have made it. I can't help wondering whether that is simply because of the amount of money they can throw at new starters in the hope that they attract some of the best people among the catch.

What I see here is that if you're in an environment where being good at walking the walk isn't always necessary, talking a good talk becomes the path to recognition and success. While this is almost certainly true, anyone who's ever observed the phenomenon of middle management could have told you that, without reference to any specific industry. What it doesn't tell us is how much being able to walk the walk matters in most other environments where it is necessary for success.

That is describing what it takes for an individual to be successful in a group of men. I think Im safe in saying this is like that since the dawn of men. Specifically here, it happens in organisations big enough so that people's actual productivity is unknown.

Innovation though generally doesn't happen in such environment.

And yet it seems to me that the typical software/technical interview process emphasizes #8 more than the other seven. Maybe like the drunkard searching for lost keys under the lamp post. Quite sobering.

Worth keeping in mind that this is true for the culture/environment within Google, not universally. Different companies have different cultures, and the above actually makes me more cynical about the culture within Google. If two people have competing ideas for a engineering solution/implementation, is the winner going to be the one with the best technical merits, or the one best at office politics? Judging from the above study, it seems like Google's culture is less meritocracy-driven and more politics-driven than people think.

Frankly, it would be surprising if it was. If you've topped out that tech tree, most of your performance variance will come from other areas where there's more, uh, variance.

I was wondering what you do when you don't want to follow a list of good things to do? I assume self-publishing was discouraging at times, wasn't it?

1) It's also important to align your energy levels and what you want to do with your list of high-leverage tasks. When you're really excited about doing something, even if isn't strictly the highest-leverage thing you could do, you can actually end up creating more impact because you do a much better job of it.

2) Sometimes what's needed is just a change in perspective about things you need to do. I play with this a lot in the leadership coaching that I do. For example, I hate responding to emails because processing them all feels like a chore. But if I reframe responding to emails in my mind to be hunting for gems that might lead to new opportunities, I'm much more likely to go through them (at least the ones that are gems).

And oh yes, there were definitely discouraging points. The story about early, negative feedback from my wife (that I posted in another comment) was one.

Another is that ten months into book writing, around the start of 2014, I started feeling a sense of intense FOMO from reading Hacker News. Stripe had raised a valuation round of over $1B, and WhatsApp had been acquired for $16B. That led to moments where I would wonder "What in the world was I doing writing a book?" and "When will I ever finish?". I had just finished a first draft, I wasn't sure how rewarding financially the book would be, and I was feeling like I had removed myself from the startup game.

That led me to start looking for jobs, which quite fortunately, also led me to my current role at Quip. So everything worked out in the end.

Why the word leverage?

Time is our most limited resource. And so the way to really increase our impact (say by 10x) is not to increase the number of hours you work, but to increase your rate of impact, which is how I define leverage in the book.

Another way to think about leverage is in terms of a lever, which lets you apply a little bit of force, have it amplified, and then move large boulders. Many of the stories and strategies from the book talk about these leverage points in engineering, e.g. investing in iterating speed or validating your ideas early and often, where small bits of effort end up having a disproportionate impact.

Less easily communicated ideas often need at least a demo. Dropbox is one example.

I do have a question on your topic on high leverage work; as a startup how would you know what is high leverage work? You have talked about various tooling projects at Quora which turned out to be duds, but how would you know that beforehand without trying? I guess the same applies to your book...

In some sense, it might actually be easier to tell at a startup because what matters at a startup is growth. That can be growth of revenue (if you already have a product to sell) or growth of users (if you need traffic first to sell, e.g. Quora).

The highest-leverage work would then be the things that most directly lead to that growth. Sometimes, this will require talking with product managers or salespeople or users to understand what the biggest accelerators or roadblocks would be. So, for example, at Quip, I looked at data on how the product spread within teams and organizations, developed engagement metrics around it, and then built features to move those metrics.

Working on some projects that end up failing is perfectly normal. What's important is to front-load as much of the risk as possible and to be explicit about the hypotheses required to make a project successful so that you can validate them early and, if necessary, change course.

That's where some of the projects we worked on at Quora failed (e.g. topic groups, an infrastructure rewrite) -- we let ourselves be overly confident about what we knew and didn't invest the time to sanity check our hypotheses.

For my book, validation played a huge role. Even before I started writing my book, I had written engineering-related answers on Quora for over two years and started to get a sense of what resonated with readers. That helped me build confidence that there would be demand for something in this space. Continued feedback and reviews during the writing process built on that confidence more.

In business contexts, your engineering impact generally ties back to the business value you create (i.e. revenue and profit). If there is already some model for translating your area of work to revenue (e.g. increase users -> increase revenue, reduce fraud -> increase revenue) then that can also give another proxy metric to optimize for. So for example, when working on Google Search Quality, we would often just optimize for long clickthrough rates, knowing that strategically, the ads team would take care of turning returning searchers to revenue.

It gets harder when you're working on areas like bigger bets (where you can have high impact but it is unknown for a long time) or in trying to understand an infrastructure investment in terms of its business value to the company. There, it may be sufficient to just know that something is of strategic value and then measure your impact in terms of those strategic goals.

I quit my full-time job at Quora and spent ten months full-time on the book (with bits of traveling). Like any other project, I drastically estimated how long it would take. I estimated one year; it ended up taking almost two. I finished the book while working full-time at Quip.

At times, it was an amazing adventure. I loved going around Silicon Valley and interviewing people like Mike Krieger or Sam Schillace to get their stories and their most valuable lessons.

Other times, there were also intense periods of self-doubt. The first person I shared a chapter draft with was my wife. She's also an engineer and by default can give quite critical feedback. And, wow, did I feel shut down after my first round of feedback. It's confusing! I don't understand the point of this! etc.

I ended up spending two months iterating by myself on my next drafts to build up more confidence before sharing with more engineering friends -- they then really gave me the support I needed to feel confident about writing the book. The experience was a great lesson in how new ideas need to be nurtured, and you need to either find supporters who will nurture that for you, or ask for the type of feedback you want (which is what I now do with my wife). It was also a valuable lesson in getting feedback sooner on your project before you are too emotionally attached to feel comfortable about asking for feedback.

All in all, it's one of my proudest accomplishments in my career.

http://www.effectiveengineer.com/blog/lessons-from-self-publ...