S-tier, I defined as:
- the shiny pokemon 🐉
- individuals standing in the top 5% of their field in skill and ability (note that S+, S++ tier exists too)
- the collective ability required to succeed
S-tier people
In Attributes - how to form teams, I cover how Skill is merely one aspect in the holistic measure of a potential teammate.
Sometimes, when I evaluate potential teammates – every now and then, I find an S-tier person. Someone hitting the 2nd definition.
Fundamentally, they are highly skilled and/or accomplished – with strong signals as evidence.
- It could be a technical S-tier, in their speciality of webdev, frontend, backend, mobile, VR/AR, design, hardware…etc
- They might have a portfolio of past work at a high-standard (e.g. built multiple mobile apps with thousands of users each).
- They might have a GitHub green squares activity of >1k per year.
- They might have great taste: responsible for the great UIUX in the most recent thing they worked on. And convey that in their personal website too.
They might be a non-technical S-tier
- In areas of product, GTM, sales, PM…etc
- They might have made something incredibly simple, but highly relevant for a group of users – launched, and grown it to a base of passionate users.
- They might have a platform of thousands of users they understand well.
- They might signal it from Product/GTM roles at great startups or tech companies - where the impact they had was attributable to them rather than simply the scale of the company
Sometimes, they could be an S-tier at hackathons – with a record of just making it work.
Whenever I find these golden gems, and they also are aligned with the other 4 attributes I look for – I make sure to grab them.
These individuals can often be the crucial lynchpin in building product. They perform well as the tech-lead in my teams, providing overall decisioning and guidance on the building aspects. I often enjoy the synergy when I can be the non-technical lead and have a tech-lead who has dug their well deep in the stack we use – where I can jump on building a few features upon the solid skeleton the tech-lead has established.
An S-tier teammate is like an anchor upon which many efforts in the team can build upon. They are essentially a carry and can drive well in their speciality.
No S-tier members?
However, teaming with even a single S-tier is a once in a blue-moon occasion. Finding and teaming with S-tier people is infrequent, with the large majority of my hackathons not the case.
Fortunately, there is still a way to have S-tier power and capability.
Collective S-tier
If there are no S-tier individuals, then the teams’ collective ability and skillsets should cohesively sum to S-tier equivalent.
Fundamentally, I look for two individual carries for this:
- the Non-technical Carry
- the Technical Carry
the requirement for success
Fundamentally, I believe that S-tier capabilities are a fundamental requirement for success.
In hackathons and product building, the endeavour is both technical and non-technical. However, it is even rarer to find an individual that is both S-tier in non-technical and technical (especially for that particular tech stack).
Hence and nevertheless, I define two key drivers required in a team:
- the Non-technical Carry
- the Technical Carry
With, scope of responsibilities:
-
the Non-technical Carry: generally focused on problem, users, product, team
- product management
- establish alignment
- define and scope problem
- get and integrate user feedback
- sell the product
- pitch
- GTM
- define user stories
- …etc
-
the Technical Carry: generally focused on solution, implementation, constraints management
- engineering leadership
- system design
- tech stack expertise
- 10x engineering
- CI/CD
- integration of parts
- …etc
Note: a Technical Carry is usually a carry only in a particular tech-stack/platform/product, e.g. webdev, mobile, machine learning, computer vision, AR, VR, hardware, game dev, React…etc. So while one might be a Technical Carry in one project, they might not be in another.
Ideally, with two individuals carrying and covering each role – success is possible, especially with potential synergy from having two expert drivers bouncing and refining perspectives.
the 3rd Carry - the Design Carry
Even with both carries present – there can often be a critical gap still needing to be filled.
S-tier Design capabilities.
A Technical/Non-technical Carry might not always have strong design-sense and taste. For example, I know when a website is beautiful or not – but I would rarely be able to call out every element which results in that judgement.
An S-tier Designer should have great taste, knowledge and a structured approach towards UI/UX design. They must be able to effectively derive what is required and convey it to engineering.
So ideally, there should be a 3rd Carry – the Design Carry
Caveat – no carries?
Sometimes, you might not even be able to get a single carry (including yourself!).
In those scenarios, you still need to try build a team which can collectively reach S-tier (or at least A-tier).
- perhaps, two people combined are a technical S-tier
- perhaps, one person is a non-technical A-tier
- perhaps, those three collectively have B-tier design sense
You simply need to make the best of it! Remember there is always more than pure skill to win.