Startups are hard. And hiring great technical staff members may be the most difficult and important challenge in a startup.
So how do we hire the right people? Start with the end in mind — i.e., have a clear definition of who you’re looking for before you begin. Most hiring managers start by trying to breakdown the technical “do-er” roles in a company (engineering, product, design) into lists of specific knowledge or behavioral requirements. I don’t think it’s enough to just find people who can check the boxes of “knows Cocoa” or “expert with Photoshop” or “wrote Pivotal Tracker stories”. Founders and early-stage startup team members need to have an extra dose of character because they’re not just building a product, they’re forming a culture. Here are four characteristics to look for in each technical role that has a direct hand in building a startup.
(Note: This post is a follow up and extension to https://framethink.wordpress.com/2013/02/25/five-behaviors-of-awesome-engineers/ with many thanks to Laura Klein and George Lee for inspiration and feedback.)
- Craftsman — pride and deep understanding of work
- Goalie — defender of the codebase, uses test-suite as a protective shield
- Macgyver — builds the minimum viable version quickly and then iterates forward
- Coach — mentors others and is coachable
- Artist — weaves beautiful, delightful, enticing designs into and throughout a product
- Literalist — must get ideas/concepts down on paper or screen-pixels in order to understand and discuss them
Eye of Sauron — notices 1px differences in baselines and kerning
- Toolmaker — creates guides, libraries, templates, etc. for other team members to follow
- Shortstop — covers all the gaps, thinks through corner cases and potential dead-ends
- Occam — cuts flows like a razor, down to the most simple path
Empath — guided by deep caring and viscerally feeling the pain of the user problem
- WeebleWobble — absorbs input/feedback; bounces back from any knock, converting it into action
- Guru — customer use-case and domain expert
- Mad Scientist — sees the big world-altering vision, plots experiments to probe the path forward
- MC — confident and persuasive public presenter
- Logician — skillfully works the development process to deliver on-time, on-budget
Answer by Yee Lee:
Of course I regret it, how could you not?!
I was at PayPal pre-IPO and had a chance to work withand . Back then, PayPal's product development process was very Product-driven and as a young PM. I loved that about the place; it was an exhilarating job/experience.
When I was getting ready to leave PayPal in late 2005, I remember having a conversation with Steve about product management positions at YouTube. He said, "Y'know, we didn't really like the way product managers and engineers interacted at PayPal. So here at YouTube, we want engineers to lead product decisions. So we kinda just want PM's to take notes on what the engineers decide and make sure that stuff gets done."
I mulled that over, thought that sounded terrible, shook my head, and told Steve that maybe we should chat again when he was ready to bring on-board a *real* product manager. I WAS (maybe still am) SUCH AN IDIOT! I had an opportunity to talk with the founders of YouTube about being one of the first (if not the first) PM and I didn't even engage in the conversation because I had held precisely one (1) product management role before in my life and therefore assumed I had it all figured out… Sigh.
In hindsight, I think careers in Silicon Valley are so dependent on luck, timing, and who-you-happen-to-know that a lot of us probably have gone through these kinds of near-misses. In fact, I think that's one of the things that makes the Valley special — the business ecosystem is connected enough here that just about everyone knows someone or has a friend-of-a-friend that experienced major personal career success. That proximity to success creates a lot of readily available role models and exemplars that drive the aspirations of the whole Valley. It's not just the top universities, the long tradition of technical innovation, and presence of venture capital or other legal/support functions… Other countries have tried bringing all those factors together into "innovation hubs" and not been able to replicate Silicon Valley. It may be because they're missing the social-connectedness and success role models that we have!
I think the regret of a few missed-opportunities is a small price to pay for working in the greatest innovation center on the planet!
Answer by Yee Lee:
Remember: the purpose of a backlog story is just to cause the right conversations between team members. So, it's difficult for an outsider to gauge the "goodness" of a backlog just by looking at the story headlines.
In some cases, 1-liner story could be all you need to remind team members of a whiteboard conversation they had. Usually, though, you'll see a lot of back and forth interaction between team members while they groom a story as it moves up the backlog. E.g., if you follow a backlog over several sprints, you should see:
- A story starts off in the Icebox or low down in the Backlog as a 1-liner or a very simple description of the desired user experience
- As the story moves up towards the top of the Backlog, you may see, mocks/attachments, implementation notes or sub-tasks get added to the story — indicating that the development team has been grooming the story and thinking about how to implement it
- Ideally, the conversation about "how" will feedback into the "what" of the story and you may notice that stories with broad scopes get broken down into multiple smaller stories that will each get prioritized.
- By the time a story gets close to the top of the Backlog, it should meet a few criteria:
- Granular enough that a single individual can implement, e.g., no intra-team dependencies for a single story.
- Developers have discussed/groomed sufficiently so that they understand exactly what needs to be done, e.g., if you ask multiple team members what the story is about, you'll get identical answers
- Each development team member has a good enough idea of how they would implement the story that they can give a confident estimate. Side note on story estimation: development team members typically are pretty good at estimating story points up to the equivalent of a day's worth of work. Any points estimate that indicates multiple days of work should be taken as a red flag of story uncertainty. High-performing teams will take the time to do multiple rounds of estimation, breaking down stories until they all fit under a low points-ceiling.
Here are a couple public examples of backlogs for on-going, active projects…
The agile backlog used to build the Jira Agile app (how meta):
And if you google around for "public backlog" (in quotes), you'll find other examples.
I loved reading about Kapta’s insightful software service that helps organizations align day-to-day actions with strategic objectives and wanted to revisit the topic of SMART objectives that I wrote about back in 2007.
Kapta’s CEO, Alex Raymond, has some great insights about what makes for a good organizational objective. Specifically, I like his notions of:
- Ambitious — “The goal should be bold and exciting, something for people to rally around. Not impossible to reach, but still aggressive.”
- Inclusive — “Everyone in the company needs to understand how they contribute to each goal. Otherwise, employees can lose motivation and clarity.”
Adding those notions to the SMART framework, one would obtain “AI SMART” objectives:
- Ambitious — aim high
- Inclusive — everyone can contribute
- Specific — concrete, actionable
- Measurable — we’ll know if we hit the mark
- Attainable — realistic to achieve
- Results-oriented — produces a meaningful impact
- Time-bound — by a certain due date
I’m going to start using this framework for assessing goals. It’s the start of a quarter… I hope this is helpful for all of you out there setting quarterly objectives and OKR’s!