i am part of the google for startups - africa mentors program, worked with the 2026 cohort.
the three problems founders keep hitting
- hiring top talent and expecting productivity to follow - they bring in the best, expecting velocity to skyrocket, but it often goes the opposite direction. so how do they actually go about this?
- remote vs in-person - which one works? most of them lean towards in-person.
- micro-managing everything - they hate doing it, but they feel like they have no choice.
real problems, and honestly, very common ones.
my argument - the recipe
here is the thing - most of this is stuff everyone knows. the gap is that nobody actually operationalizes it. that’s where the productivity goes.
a) domain knowledge is key
before anything else, domain knowledge matters. a great hire with zero context on the problem space is not productive on day one - no matter how good they are. so onboard for context first - a quick product walkthrough beats handing someone a task and hoping.
b) internal documentation - how knowledge flows
how is knowledge about the product passed down? and this is not just about one team - it touches everyone. how well is this channelled down across the company?
if the product knowledge lives in a few heads, you will micro-manage forever, because no one else can move without you. write it down - that is how you stop being the bottleneck.
c) match talent the right way
this is the part i find most interesting. with proper documentation and well aligned matching of talent within the company, productivity becomes a no-brainer.
think hybrid - match each skill level deliberately. when pairing teams, consider, in this order:
- domain knowledge
- product knowledge
- then skills
skills alone don’t make a productive team. context does. take engineers as an example - don’t pair two senior ones who’ve never touched the domain. pair one who knows the product with one who knows the stack, and let them level each other up. same logic applies to any team.
d) encourage ownership
encourage product or project ownership - however big or small. when people own something, they stop waiting to be told what to do, and the micro-managing problem starts to dissolve on its own.
e) define roles and what success means
have clearly defined roles, and highlight what success looks like at four levels:
- company
- team
- project
- the individual talent
success for the company might be revenue, for the team - a shipped milestone, for the individual - a skill grown - when everyone knows what winning looks like at their level, you don’t need to hover.
two more came up in hallway chats with founders:
f) invest in your talent
give them the tools they need, and build an environment that encourages experimentation - especially with ai. carve out time for it, reward the people who try things. with ai, what can be done is incredible, so go for it.
g) fix broken feedback loops
feedback should flow vertically and horizontally - up, down, and across. pair that with frequent 1:1s on whatever cadence works for the team. broken loops are where good people quietly stall.
so what about remote vs in-person?
honestly? it doesn’t really matter once everything above is solid.
here is my take - being good at remote is self-taught. it is a skill one needs to develop, and it is mostly out of scope for the company. the discipline this needs is crazy.
so it is less about remote vs in-person, and more about whether the talent has built that muscle - and whether the company has the context, documentation, and ownership that lets remote actually work.
a follow-up write is coming on this one - just my own perspective on remote, from years of working remotely. stay tuned.
hiring top talent is not the recipe. context, documentation, deliberate matching, and ownership are. get those right, and the rest mostly solves itself.
so, what are you building?