The 160x Engineering Effect: Why Elite Talent Is Your Ultimate Competitive Advantage
The goal of early-stage products is to:
- Get real user feedback and analytics, in order to:
- Make informed pivots, until you:
- Achieve product-market fit (including pricing) or run out of pivots (i.e., capital).
The faster you can iterate and release testable features and functionality - that have been prioritized based on feedback and analytics - the better your chances of finding product-market fit before exhausting your runway.
The ability to iterate and release quickly depends on the talent and motivation of your engineering team. Note: I used the word "talent" deliberately because it's distinct from "experience."
Where does the 160x come from? Throughout my career, I've repeatedly seen a single talented engineer complete the same epic(s) of work in a few days that a four or five-person team struggled with for six months or longer. Do the math yourself if you like.
The Important Part
If you and I are building competing products, and your team takes six months to release a single feature - or some critical functionality - you're at an insurmountable disadvantage.
Why? Because during that same six-month period, my team will release new testable and marketable features every single week; sometimes, every day.
Our product's users will receive a steady stream of features, updates, and [oftentimes] incremental value. We'll gather valuable feedback and analytics that enable us to prioritize, pivot, and refine our messaging. Plus, our rapid and consistent release cadence will provide our Product Marketing person with a continuous pipeline of impactful content to engage users and convert visitors.
Let me illustrate this point with a concrete example and some graphics. Consider two teams:
- Team Sara: single-person team, just Sara, who is a stellar engineer.
- Scrum Squad: five-person engineering team that's basically going through the motions.
Sara begins Epic A on April 1st. It's a massive undertaking including all the foundational infrastructure needed to launch v0 of the app. She completes it that same week.
Scrum Squad also starts Epic A on April 1st, but they continue working on it until the end of September. That's a reasonable timeline given the scope of work required.
Now, for the main point: what you see in the roadmap above is that Team Sara keeps moving forward and completes epic after epic, releasing incremental value (user stories) every single week that Scrum Squad is working on Epic A.
Imagine how much difference this makes to your users, not to mention the ability to launch vBeta of your project before some other startup or product team with an engineer like Sara does.
Quick Note: my 160 number doesn't include all the other features and functionality that Sara actually delivers over the same six-month timeline... I'm only using a raw comparison of the resource input that Epic A requires.
Let's compare the cumulative value delivery between the two teams.
Why Not Hire the Best?
I doubt there's many hiring managers or recruiters thinking "No! We DON'T want to hire the best... mediocre will do." Obviously, the largest constraint is your budget. I come across positions all the time that unwittingly contain a job description that encompasses the roles and scope of several engineers or product managers, and they're offering only a subsistence living. You will NOT be able to attract talented people with low pay and outlandish expectations.
If your budget isn't sufficient to attract and hire the best, then increase your budget or reconsider moving forward with your product. If you're not able to increase your budget, that's a strong sign that you're lacking sufficient executive-level buy-in, which usually leads to larger problems ahead. Thus, save everybody the time, pain, and money; end it now.
Value Engineering
Still not convinced? Let's frame the example above from an internal value delivery angle.
In six months, Scrum Squad delivered 13 story points (at the end of September). Assuming that we pay each engineer on Scrum Squad a salary of 150 coins/year...
[(4 engineers)*(150 coins/yr)(6mo)(1yr/12mo)] / 13 story points =
23 coins / story point
Now consider Team Sara who continued releasing new features for the same six months, and delivered 248 story points in total. Assuming that we paid Sara 200 coins/year, a whopping 33% more than we pay each of the engineers on Scrum Squad...
[(1engineer)*(200coins/yr)(6mo)(1hr/12mo)]/248storypoints =
0.40 coins / story point
Our talented engineer, Sara, was clearly much more cost effective than Scrum Squad. But, the real value comes in the non-quantifiable benefit: our product has a much better chance of succeeding. The probability of success increases remarkably when we launch and test quickly; thus, the Expected Value of the project overall is much higher.
Conclusion
Hire the very best engineers you can find. Pay them as much as you can possibly afford, and recognize that you're getting an excellent deal. You'll thank me (and them) later.
Detailed Timeline
If you're curious about a detailed, play-by-play version of how those six months unfold for each of the two teams, continue reading below.
Week 1 (Monday)
- Sara starts working on Epic A (infrastructure) immediately based on a conversation she had with her Product Manager on Friday afternoon. The PM creates a single Jira ticket with no content in the description - it isn't necessary because they already share a clear understanding of the desired outcome.
- Scrum Squad, the team of five, begins the morning with a Sprint Planning meeting. Their PM worked all weekend (and all of last week) to assemble a comprehensive backlog consisting of multiple epics, hundreds of bite-sized user stories (with no story exceeding 13 story points, of course), all spec'd out with painstakingly detailed acceptance criteria.
- During planning, Scrum Squad decides they can't commit to any of the tickets the PM created without more information; thus, their next two-week sprint will be entirely dedicated to "scoping" and "de-risking" activities, for which they've had their IT Admin create a special type of Jira issue called a "Spike."
Week 1 (Tuesday)
- Sara deploys a functional prototype to her Dev environment for UAT.
- Scrum Squad enjoys a morale-boosting lunch at Habit Burger.
Week 1 (Thursday)
- After making a few adjustments and adding integration testing, Sara deploys to Prod. This Epic (and all user stories within it) is now complete.
- Scrum Squad realizes this will be a MASSIVE project for them. They begin breaking down the PM's stories into sub-tasks, tallying hundreds upon hundreds of story points—possibly thousands. Nevertheless, they roll up their sleeves, determined to complete this scoping and de-risking work.
Week 2
- Sara releases three awesome new features with event-tracking so her PM can monitor usage. Two features resonate strongly with users; the third falls flat.
- Scrum Squad completes their scoping sprint and conducts a retrospective. They prepare to inform the PM on Monday that the project will likely take six months to complete, though they've provided a tight estimate range of 4-9 months—assuming nothing major goes wrong and Auth0's API doesn't change significantly enough to require immediate refactoring.
Week 3
- Sara releases two major features and three smaller UX improvements. Users enthusiastically embrace the newest additions—evident in both usage analytics and Discord feedback. The PM gains valuable insights to guide future direction.
- Scrum Squad begins another two-week sprint. For the next four sprints (two months), the team lead will create architectural and UML diagrams, while the rest of the team familiarizes themselves with Auth0's API.
Week 4
- Sara hits her stride, deploying another awesome feature and refining the UX of previous features. This latest addition proves to be the breakthrough—Pinnacle's users love it so much they mention it in every conversation they can.
- Scrum Squad continues chipping away at Epic A. Under pressure from above, their PM (an experienced backend engineer) must now contribute as an individual developer for up to 50% of her time—while still performing 100% of her full-time PM responsibilities.
Month 2
- Sara and her PM continue zeroing in on their beachhead segment by releasing new value-added features.
- Scrum Squad continues their methodical approach.
Month 3-5
- Sara's product has grown to reach a thousand users (early adopters), with 150 of them becoming devout evangelists.
- Scrum Squad's Marketing team begins working on a press release to announce the upcoming release of Epic A's features next month.
Month 6
- Sara and her PM continue releasing cool new features, leaning into their product's value proposition, and refining their positioning. They add another 500 users this month thanks to an unsolicited mention from a popular publication.
- Scrum Squad successfully releases Epic A, though they accumulated some technical debt to meet their deployment milestone.
Cover photo by Christina @ wocintechchat.com on Unsplash