Coffee Thoughts

While sipping my coffee this morning I started thinking about some problems many startups face and some of the questions I get while talking to startups. One of the usual questions is, “How do I vet developers when I’m not technical at all?”. Most of the time the concern is more about “how do I know if a developer is bullshitting me or not?” than anything else.

Over the last 15 years I have hired many developers and technical folks and I want to share with you how I go about hiring and managing technical resources.

First off, when interviewing don’t ask specific technology questions and instead talk about a problem that has a technical solution and see how they would go about solving that problem. Do they want to custom develop everything in an obscure language or do they want to utilize open source frameworks, CMS’s, and already defined technologies? No matter what you are developing, using already established tools and frameworks is far better than trying to build something yourself (and will likely be more secure). Lean toward developers that want to use frameworks more than those who want to build it all themselves.

Do your homework. With some quick Google-fu you should be able to find tools and frameworks that fits some portion of your solution, then ask your candidates about these frameworks and gauge their responses. Do they fumble when talking about it? If so, they are bullshitting you.

“How can I manage developers without being technical?” This one is actually easier than most think. As a Certified Scrum Master (CSM) I tend to lean towards agile methodologies and if done right, can make the overall development process easier for everyone. In a nutshell, agile is generally broken into a few separate areas, that even non-technical folks can understand and manage.

Build a backlog. What is a backlog you ask? It is a list where all features, components, aspects of the development work goes. These items are then prioritized by the “product owner”, a.k.a. You! What do you want, need to get done first. You then sit down with your developer (or development team) and discuss what these items are and what they think they can accomplish in a sprint (a defined period of time to do some work, usually two to three weeks). During this discussion you provide a ‘definition of done’, which is just a description of how we know when this item is complete so there is no confusion between you and your developers. Once everyone has agreed to the sprint, you will have daily stand ups (meetings) to quickly talk about progress, issues, etc. Stand-ups should not last more than 15 minutes. There’s a lot more to it, but using this methodology helps with understanding progress and getting the best product you can without having to know how the technical plumbing works.

Just a small glimpse into what I think of first thing in the morning while drinking my coffee. Hope this was helpful to some, and if you would like me to elaborate more on anything let me know and I will work on a followup to this post.

Thanks for reading!