You may have heard me explain my philosophy for building teams before. If you haven't, it's fairly simple.
Identify the resources I need, define & allocate roles and then hire people that are better than me to fill those roles.
As a startup entrepreneur I know that at the beginning, I need to fill multiple roles and show competence, heck even some degree of excellence, at more than one of them at a time. This applies to design, sales, marketing, finance or product development - all of which I have done myself or recruited/outsourced for.
I also have a clear understanding of where my abilities do not come up to scratch and I am very cognisant of my shortcomings. So, hiring for some roles has been easy, such as in engineering for example, as the benchmark I set was pretty low.
It was only 4 years ago that I didn't have a clue how to create a website. I shudder at my lack of knowledge as I blindly blundered my way into building a social network with only my passion for adventure sports and ability to learn quickly to guide me.
It wasn't hard to find someone better than me then, in fact anyone was better than me.
But since that time, I've progressed. I've built things. I've built teams that have built things. I've learned so much that has helped me understand the difference between a good developer and a great developer. Who can build products, who can do tasks, who can create and manage infrastructure. These are all potentially different people.
So, I have tried to be a better non-technical founder. I've tried to be interested in technical issues and understand the background processes to making technical decisions. I've been trying to learn to code. I've experimented with lots of different languages, markups, libraries and frameworks. I am still a master of none, and I don't intend that to necessarily change (at least currently).
If I am working with clients, I want the solution to fit the need, not to fit my own limited abilities. If I'm working on an internal project, I want the project to further my understanding of different technologies, not labour on perhaps my outdated and under utilised knowledge of a specific technology.
But, whilst many techies may believe a little knowledge to be more dangerous than beneficial, I have certainly found that a broad understanding of technical principles, scripting languages, markups, processes and methodologies has helped me in a few key ways.
- Raising the benchmark for team members - as I improve, so does my team and knowledge of building teams and recruiting specialist talent.
- Embracing new technologies - my naivety has proved successful in opening up new pathways that may not have been obvious before, rather than the (often frustrating levels of) fear that more established devs may have of new tech (I've seen it).
- Building relationships - The improvement in my knowledge has had a direct correlation to my improved ability to establish and maintain positive relationships with my technical teams. A better understanding of the issues, the challenges, the motivations of my developments teams helps foster a much more dynamic and mutually beneficial working culture.
Resources that have helped me
I will shortly publish a very full and extensive list of resources that I use, but I find that blog posts really aren't conducive to doing that in a way that is truly useful, so I will avoid it for now. Needless to say, I am working to solve that with my latest project. and you'll be the first to hear about it.