Ask HN: CTO with no experience, how do I make my first technical hire?
40 comments
In my opinion you shouldn't be a CTO but a founder. I don't think any serious tech team can respect a technically inexperienced or poor CTO for long and this will cause problems later.
It might be a better idea for you to go for a Chief Product Officer or just Founder and hire someone experienced to do the CTO role.
If you think you can lead from the front without being competent in a subject - you have another thing coming.
It might be a better idea for you to go for a Chief Product Officer or just Founder and hire someone experienced to do the CTO role.
If you think you can lead from the front without being competent in a subject - you have another thing coming.
+1 hire an experienced CTO/Sr. Tech Leader first and then all your problems will be solved.
I hope you are hearing the chorus - just don't call yourself a CTO. Bestowing upon yourself a fancy title doesn't make you one.
What you have done so far is great! You've written a prototype, possibly even a MVP. And that is very good. It has gotten your biz to this point.
Now is the time to hand over the reins to somebody who is technically competent, somebody who can select capable development team members and manage them.
If you can manage this transition well, you will gain far more respect than by clinging onto a fancy title.
Of course, that doesn't say that you should stop programming. In fact, you could learn a great deal from the new hires.
What you have done so far is great! You've written a prototype, possibly even a MVP. And that is very good. It has gotten your biz to this point.
Now is the time to hand over the reins to somebody who is technically competent, somebody who can select capable development team members and manage them.
If you can manage this transition well, you will gain far more respect than by clinging onto a fancy title.
Of course, that doesn't say that you should stop programming. In fact, you could learn a great deal from the new hires.
yep.
Hire a Lead Dev before you hire engineers/programmers. You'll save SO much time and headaches.
I summarize here what I expect from Lead Devs:
- A lead knows how to architect solutions. Not just code them.
- A lead talks higher level than programmers/engineers. You don't want to hear code, you want to hear solutions/implications + pros/cons.
- A lead is interested in the interconnections with other systems, and doesn't overlook them.
- A lead has experienced a range of advanced problems (optimization, weirdest bugs, scale)
- A lead is able to recognise and be interested in the problems he hasn't come across yet, and has the will to tackle them asap if they are a priority for business.
- A lead has a quite deep understanding about the full range of solutions available to solve a problem on his platform. And he spends time on this daily, ideally because he's passionate about it (never seen it other way)
- When you ask a lead how to solve a fairly open engineering problem he'll come up with 1) A good range of approaches 2) Pros/Cons for each of them 3) For each pro/con advise based on his experience.
- A lead has confidence when taking a decision on architecture, he investigates the impacts beforehand. If he's wrong he recognises it.
- Ultimately a lead should be able to come up with a plan to help you refactor any mess with the lowest impact possible in the product. Ideally building the new on new refactored structure, and re-factoring the old by bits when maintenance is needed on those sections (low-budget approach..)
A lead will help you spot other good devs, including other platforms leads. From there, hire engineers who follow the Lead!
I summarize here what I expect from Lead Devs:
- A lead knows how to architect solutions. Not just code them.
- A lead talks higher level than programmers/engineers. You don't want to hear code, you want to hear solutions/implications + pros/cons.
- A lead is interested in the interconnections with other systems, and doesn't overlook them.
- A lead has experienced a range of advanced problems (optimization, weirdest bugs, scale)
- A lead is able to recognise and be interested in the problems he hasn't come across yet, and has the will to tackle them asap if they are a priority for business.
- A lead has a quite deep understanding about the full range of solutions available to solve a problem on his platform. And he spends time on this daily, ideally because he's passionate about it (never seen it other way)
- When you ask a lead how to solve a fairly open engineering problem he'll come up with 1) A good range of approaches 2) Pros/Cons for each of them 3) For each pro/con advise based on his experience.
- A lead has confidence when taking a decision on architecture, he investigates the impacts beforehand. If he's wrong he recognises it.
- Ultimately a lead should be able to come up with a plan to help you refactor any mess with the lowest impact possible in the product. Ideally building the new on new refactored structure, and re-factoring the old by bits when maintenance is needed on those sections (low-budget approach..)
A lead will help you spot other good devs, including other platforms leads. From there, hire engineers who follow the Lead!
These are all things any engineer should be able to/ does do. The title "lead dev" sounds like marketing.
Based in London, where Lead Dev corresponds to those attitudes/skills.
Personally: I'm afraid in a world with current growth of almost-free online programming courses/degrees, high demand, high rates and low competition, we're going to have to accept raising the "Engineer" skills to "Lead Developer / Architect" title.
If you compare with companies with big budget, yes those attitudes are what you find on the average engineer. In the London start-up world where budget is tight and VC's think short term that's normally not the case. It's hard to find solid architectural thinkers with experience who don't call themselves Leads, Architects and so on.
Are these skills and attitudes found in your area as just "engineers"?
If you compare with companies with big budget, yes those attitudes are what you find on the average engineer. In the London start-up world where budget is tight and VC's think short term that's normally not the case. It's hard to find solid architectural thinkers with experience who don't call themselves Leads, Architects and so on.
Are these skills and attitudes found in your area as just "engineers"?
Self taught people with low/no experience should be called 'programmers' at best. In almost all industries, people who specialize in one or two things would be called a technician or programmer, i.e. Angular programmer or web tech. Software Engineer implies someone with a degree that does far more and involves all aspects including project management and financial work. Lead developer is a title for managers to use when they want to designate someone as a developer that gets final say in decisions. The startup world is ridiculous and half the people in startups should not even be called programmers. Startups are just hiring people to look like they have lots of talent for investors.
Calling us "engineers" instead of "developers" is also marketing. That's not the point.
Yeah, well I went to engineering school and I do software engineering. Not everyone is in the same boat.
As a lead dev this is spot on. A lead might seem more expensive at first, but when you factor every advantage you come out much better.
Very good list of attributes for a lead dev.
The best mix I've ever seen in practice had a non technical CTO who hired an uber bright coder as Technical Authority. The Technical Authority had a written mandate, signed off by the CTO and CEO, that his technical suggestions were to be given the same authority as a board level member of staff.
The reason why it was successful is that the CTO is no longer a developer, but a board director, and as such should focus on enabling the business through its use of technology, and enabling the techology department by cheerleading its needs to the business - you'll need to learn enough of the other business functions so that you can do that job properly, and you'll need to be able to give business cases of why you need those extra servers etc.
In addition, the Technical Authority wasn't disrupted by board level meetings and politics, and could spend more time evaluating technologies, practices, processes, setting standards etc. and they were not really suited to dealing with the non technical stuff a CTO has to.
Another big benefit was that it enabled the Technical Authority to keep coding because they loved doing it, and they were very good at it too. The team liked this.
The team had a lot of respect for the CTO because they realised that he was pragmatic and knew when to hire to cover his weakness, and when to take a step back and accept that the Technical Authority and the team had collectively made a decision, and that they were in a better position than him to do so.
As a general rule though, if you hire someone who disrespects you then you get rid of them. There are very few domains where you'd have to put up with assholery like that because there are no alternatives. Chances are that if they've got the balls to disrespect the CTO then they're likely to be unbearable to the people below and to the side of them.
The reason why it was successful is that the CTO is no longer a developer, but a board director, and as such should focus on enabling the business through its use of technology, and enabling the techology department by cheerleading its needs to the business - you'll need to learn enough of the other business functions so that you can do that job properly, and you'll need to be able to give business cases of why you need those extra servers etc.
In addition, the Technical Authority wasn't disrupted by board level meetings and politics, and could spend more time evaluating technologies, practices, processes, setting standards etc. and they were not really suited to dealing with the non technical stuff a CTO has to.
Another big benefit was that it enabled the Technical Authority to keep coding because they loved doing it, and they were very good at it too. The team liked this.
The team had a lot of respect for the CTO because they realised that he was pragmatic and knew when to hire to cover his weakness, and when to take a step back and accept that the Technical Authority and the team had collectively made a decision, and that they were in a better position than him to do so.
As a general rule though, if you hire someone who disrespects you then you get rid of them. There are very few domains where you'd have to put up with assholery like that because there are no alternatives. Chances are that if they've got the balls to disrespect the CTO then they're likely to be unbearable to the people below and to the side of them.
It sounds like you don't actually think that someone ought to respect the work you did as a programmer; you had little training, little time, and weren't following good coding practices.
I think it would be healthy to approach it from an attitude of communicating that you did what you needed to to get traction, but now you're ready to learn about how to write code that scales while meeting deadlines, and you need their help and experience to do that. It is possible.
Respecting you as a person is a prerequisite, and that'll come from your sincerity to improve as a programmer and build a team that trusts each other and keeps getting better. Respecting your code isn't a prerequisite. Your code is bad. It's okay. It would happen to anyone in your situation. Rewriting a startup's codebase from scratch after a seed round is not uncommon!
Hope that helps and isn't condescending; I'm writing this comment quickly.
I think it would be healthy to approach it from an attitude of communicating that you did what you needed to to get traction, but now you're ready to learn about how to write code that scales while meeting deadlines, and you need their help and experience to do that. It is possible.
Respecting you as a person is a prerequisite, and that'll come from your sincerity to improve as a programmer and build a team that trusts each other and keeps getting better. Respecting your code isn't a prerequisite. Your code is bad. It's okay. It would happen to anyone in your situation. Rewriting a startup's codebase from scratch after a seed round is not uncommon!
Hope that helps and isn't condescending; I'm writing this comment quickly.
This is actually a good thing. You've got something working, it doesn't matter if it's pretty. I've seen a lot of successful things that started out as ugly code. The ones that start out pretty and "architected" always collapse under their own weight before they ship.
We've all written crufty legacy code, at least if anyone is any good they've written bales of it. I would respect that ugly code, because it shipped. What I don't respect is someone who claims code is great and doesn't need fixing.
Now you need someone who can come in and turn it into something beautiful and scalable and whatever. So when you interview them, just lay out the situation. "How would you turn a terrible codebase into something great?" "Give me some examples of legacy code that you cleaned up 'in-flight', without starting over or disrupting operations or putting things on hold for six months". "What are some difficult bugs you had to deal with in a messy pipeline, and how did you fix them"? Ask about how they would improve real pain points in your current pipeline.
If their answers are broad, ask them to be specific. You don't have to know what they are talking about, but if they can talk about specific steps and strategies, it will be clear they've done this kind of work before. If they are hand-waving about best practices and generalizations, and can't drill down any further, move on. Make sure they can actually write code, too, there's plenty of people out there who can talk about code but don't sit down and write it every day. If it's going well, take them out to lunch, tell them about this post. You need someone who you can trust and be honest with, someone who will give you honest feedback on technical decisions. You don't want someone who resents that you have less technical experience and are in a more senior role.
We've all written crufty legacy code, at least if anyone is any good they've written bales of it. I would respect that ugly code, because it shipped. What I don't respect is someone who claims code is great and doesn't need fixing.
Now you need someone who can come in and turn it into something beautiful and scalable and whatever. So when you interview them, just lay out the situation. "How would you turn a terrible codebase into something great?" "Give me some examples of legacy code that you cleaned up 'in-flight', without starting over or disrupting operations or putting things on hold for six months". "What are some difficult bugs you had to deal with in a messy pipeline, and how did you fix them"? Ask about how they would improve real pain points in your current pipeline.
If their answers are broad, ask them to be specific. You don't have to know what they are talking about, but if they can talk about specific steps and strategies, it will be clear they've done this kind of work before. If they are hand-waving about best practices and generalizations, and can't drill down any further, move on. Make sure they can actually write code, too, there's plenty of people out there who can talk about code but don't sit down and write it every day. If it's going well, take them out to lunch, tell them about this post. You need someone who you can trust and be honest with, someone who will give you honest feedback on technical decisions. You don't want someone who resents that you have less technical experience and are in a more senior role.
Hire someone way more talented than yourself. Be upfront, that you want them to write good code where that is consistent with the goals of the business and that they will have to live with the pain of the existing code base until there is a good business case for radically changing the code base. The hope is that the good business case will be such strong growth that it all has to be thrown away to make room for the wheel barrows full of money coming through the front door.
Be an example for your hire. Don't own the code. Emphasize that the hire should not own the code either. Emphasize the business goals are the goals and code is only a means of pursuing those goals. The code is not an end in itself.
It will be tough to hire. It will be tough to deal with the existing code for the person who is hired. The goal is that the right person will get it and the wrong candidates will filter themselves out.
Good luck.
Be an example for your hire. Don't own the code. Emphasize that the hire should not own the code either. Emphasize the business goals are the goals and code is only a means of pursuing those goals. The code is not an end in itself.
It will be tough to hire. It will be tough to deal with the existing code for the person who is hired. The goal is that the right person will get it and the wrong candidates will filter themselves out.
Good luck.
As a CTO you will hopefully ALWAYS have better developers than you working for you, that's the point, the CTO role is not to be the best tech guy in the room. Its the guy that sets the vision, talks to investors, sets high level tech strategy (with a lot of team involvement), hires, fires, keep sales guys away from dev's etc
Eg. sort out everything that would distract your developers from building.
Eg. sort out everything that would distract your developers from building.
I'd Hire the full stack guys first, but spend a lot of time talking with them, the first hire is always the hardest but the most important. Its also hard not to hire people like yourself so take it slow, some of the best guys I have ever worked with are mid 30 with wife and kids that just know how to get stuff done.
The programmers-are-male assumptions in your comments are disturbing.
Sorry about that, I was using "guys" as a generic term, but it got me thinking that in 18 years of development, I have worked with over 200 Dev Guys and only 2 Dev Girls.
That's absurd.
Most programers are male? You can actually make that assumption factually.
How do you feel about the phrase "MIDWIFE's are in demand"? Is it appropriate or do you feel that people should have to say "Midwifes, both the females that practice midwifery and the males in in this profession, are in demand"? Can we just assume that the majority of midwifes are women and the majority of programmers are men without that being offensive?
Most programers are male? You can actually make that assumption factually.
How do you feel about the phrase "MIDWIFE's are in demand"? Is it appropriate or do you feel that people should have to say "Midwifes, both the females that practice midwifery and the males in in this profession, are in demand"? Can we just assume that the majority of midwifes are women and the majority of programmers are men without that being offensive?
> How do you feel about the phrase "MIDWIFE's are in demand"?
Well, for me, bad, but mostly for reasons unrelated to the main issue in the discussion -- because it uses an apostrophe improperly for "look out, here comes an 's'", and because the plural of "midwife" is "midwives". ("midwifes", without the gratuitous apostrophe, is a word, but its the third person present of the verb "midwife", not the plural of the noun "midwife".)
Well, for me, bad, but mostly for reasons unrelated to the main issue in the discussion -- because it uses an apostrophe improperly for "look out, here comes an 's'", and because the plural of "midwife" is "midwives". ("midwifes", without the gratuitous apostrophe, is a word, but its the third person present of the verb "midwife", not the plural of the noun "midwife".)
Funny
What you achieved is actually pretty impressive. Teaching yourself programming and build a product with traction and worth of investment. Use this at your advantage, the kind of developer that you want to hire first will respect that.
Hire a Senior full-stack developer and communicate very well that the state of the platform (and the code) is at "junior" level. Use this argument to motivate him, many developers like the challenge to set standards and lead technical decisions early on in a project.
Hire a Senior full-stack developer and communicate very well that the state of the platform (and the code) is at "junior" level. Use this argument to motivate him, many developers like the challenge to set standards and lead technical decisions early on in a project.
Well, I'd ask for a portfolio, and if you do have some programmer friends that do have the experience, I'd ask them if they can sit in an interview with you. If a portfolio is not possible, I'd ask for some technologies that they've worked with, and try to find a project which uses those technologies. I'd ask for a work sample using whatever they are comfortable with, such as the 'TodoMVC' implementation, something small that can be finished in 4 hours that shows their skill. This isn't like you are hiring just a programmer, this is going to be one of the first programmers you hire, the one likely to set the standards. Yes, he may not respect your programming skill, but that's to be expected, programmers are prideful of their work. However they can be respectful of you while giving you the rundown of why what you wrote was wrong. You want to hire someone who is better than you at programming. At the same time you don't want someone who is an ass, that should be pretty easy to figure out.
Get out of the business of being a CTO if you don't know technology. A CTO knows what the tech does and how to code, they are super technical. You could be a CEO or a CMO instead without being technical. CTO with no technical experience is a train wreck in progress.
I would hire the absolute best most experienced developer you can. Hire someone with startup experience that can do the hands on work needed now, but also manage and scale the development quickly.
I would say use the title VP of Engineering for the new hire. IF they are a rockstar, then you can promote them to CTO. If not, you could hire a CTO.
I would move yourself into another C-level title such as Chief Product Officer. CTO really means deep experience with tech which you don't have.....and that's ok because you are a founder that kicked ass on the initial version. Now you can bring in the talent to really scale the tech side of the company.
I would say use the title VP of Engineering for the new hire. IF they are a rockstar, then you can promote them to CTO. If not, you could hire a CTO.
I would move yourself into another C-level title such as Chief Product Officer. CTO really means deep experience with tech which you don't have.....and that's ok because you are a founder that kicked ass on the initial version. Now you can bring in the talent to really scale the tech side of the company.
It can be hard to let go of the work you have done to let someone else pick up the torch.
And It will be tough because this is your first experience being a programmer and your code confidence will be easily shattered. But the best thing you can do to improve your product, code, and knowledge is to hire someone with more experience than you. A good CTO hires knowledgeable programmers and listens to their opinions so he can make informed decisions. If you try to protect the code you have written by hiring less experienced programmers, your product will ultimately suffer and you will eventually be let go.
And It will be tough because this is your first experience being a programmer and your code confidence will be easily shattered. But the best thing you can do to improve your product, code, and knowledge is to hire someone with more experience than you. A good CTO hires knowledgeable programmers and listens to their opinions so he can make informed decisions. If you try to protect the code you have written by hiring less experienced programmers, your product will ultimately suffer and you will eventually be let go.
You're not the CTO of your company, so give yourself a different title.
how do I "manage" that individual if they don't respect the work I've done as a programmer?
By giving yourself a position that you can live up to.
Do you need a board-level technical person? If you do, you've already said you're not qualified to be it. Do you NOT need a board-level technical person? Have the them report to whatever your not-CTO role is.
how do I "manage" that individual if they don't respect the work I've done as a programmer?
By giving yourself a position that you can live up to.
Do you need a board-level technical person? If you do, you've already said you're not qualified to be it. Do you NOT need a board-level technical person? Have the them report to whatever your not-CTO role is.
I'll agree with most folks here that you aren't a CTO.
You don't NEED a CTO, today, and at this point it might even be counter productive. Your either going to hire what you can afford, or pay a lot of money for little code return.
Do you need an architect/director/VP/tech-lead? Probably.
What you have already done in "reducing the time to goto market and cost- quality has taken a hit" is make a sound business decision. Without knowing what your road map, funding level, growth projections and anything about the existing codebase we are being asked to give advice in a vacuum.
Your real issue (and why I would say you ARENT a CTO, or VP or any of those other titles) is that you lack a network. If I need advice, a sounding board, an outside opinion or a shoulder to cry on, I have a list of folks I can call 24/7 who I trust and have worked with in the past. Sometimes it isn't wise or possible to get this kind of support within your current company, and as a manager outsiders who understand may be your ONLY outlet.
Your a founder, you just got some cash, set aside 2-3 hours every day to just TALK to new people. You want to buy me lunch and pick my brain for 2 hours, thats a fair deal, and its easier for me to be objective about YOUR issues, and YOUR drama (its going to happen). If we got along and started to get together regularly, I'm going to get insight and continuity that you just can't create in a form post. If I'm willing to listen to you for lunch (and I have do so for others) I'm sure a lot of other folks are as well. There was a story a while back that there were folks willing to give up their passwords for a snickers bar, just imagine what you can get from sandwiches, cheeseburgers and the occasional beer.
You don't NEED a CTO, today, and at this point it might even be counter productive. Your either going to hire what you can afford, or pay a lot of money for little code return.
Do you need an architect/director/VP/tech-lead? Probably.
What you have already done in "reducing the time to goto market and cost- quality has taken a hit" is make a sound business decision. Without knowing what your road map, funding level, growth projections and anything about the existing codebase we are being asked to give advice in a vacuum.
Your real issue (and why I would say you ARENT a CTO, or VP or any of those other titles) is that you lack a network. If I need advice, a sounding board, an outside opinion or a shoulder to cry on, I have a list of folks I can call 24/7 who I trust and have worked with in the past. Sometimes it isn't wise or possible to get this kind of support within your current company, and as a manager outsiders who understand may be your ONLY outlet.
Your a founder, you just got some cash, set aside 2-3 hours every day to just TALK to new people. You want to buy me lunch and pick my brain for 2 hours, thats a fair deal, and its easier for me to be objective about YOUR issues, and YOUR drama (its going to happen). If we got along and started to get together regularly, I'm going to get insight and continuity that you just can't create in a form post. If I'm willing to listen to you for lunch (and I have do so for others) I'm sure a lot of other folks are as well. There was a story a while back that there were folks willing to give up their passwords for a snickers bar, just imagine what you can get from sandwiches, cheeseburgers and the occasional beer.
I'm in the same position with similar circumstances. You did what you had to do - instead of going back to school and learning the theory, you decided to focus on the problem and build practical solutions in the form of prototypes/mvps. There's no shame in that.
My approach will be to stay humble and eager to learn. I want to hire people smarter than me so that I can grow by working with them.
My approach will be to stay humble and eager to learn. I want to hire people smarter than me so that I can grow by working with them.
With regards to your concern, it's important for any leader to know their own weaknesses. Given that you know you're not a superstar developer so if you'll be hiring one as part of the technical team, make sure you pay attention to what he/she says. Listening to others will help you gain respect. The CTO's role will be enable the technology to fuel the business. It doesn't necessarily mean that you have to be the best developer but it means that you have to help your technical team to achieve it. Give them the tools, ask for their expertise, let them make it happen and communicate the business strategy to them.
At such an early stage, you'll probably need someone who is a self-starter who can play multiple roles rather than someone you will have to "manage". However, given that you don't have a solid technical background, it will be tough to make a lot of decisions without consulting your technical team. Find someone who is a technical expert but is also willing to help you, not overtake you.
At such an early stage, you'll probably need someone who is a self-starter who can play multiple roles rather than someone you will have to "manage". However, given that you don't have a solid technical background, it will be tough to make a lot of decisions without consulting your technical team. Find someone who is a technical expert but is also willing to help you, not overtake you.
> As a CTO with no computer science background and no previous experience programming at another company
Why are you the CTO?
Why are you the CTO?
I programmed in my spare time because I was curious. After a few months I started building little applications to make my life easier. My co-founder and I then had an idea and we wanted to bring it to market. I continued teaching myself until we got to our beta complete.
I figured we're a two person startup and I'm writing code and building the beta, I guess that makes me the CTO?
I figured we're a two person startup and I'm writing code and building the beta, I guess that makes me the CTO?
Note: you can't say you have no experience, because you demonstrably have some!
One thing to decide is if you want to continue down the technical path. In that case, you might want to hire a CTO (I agree with those that say you should move to "founder") who has as one of his explicit missions helping you to gain more experience. As part of finding such a person, you might ask for book recommendations in interviews.
But as others have noted, you'll have to check your ego at the door; back in 1971 Jerry Weinberg formulated the concept in his still excellent The Psychology of Computer Programming. If you can't do that, or completely turn it over to the technical people you hire, your venture is in serious jeopardy.
That said, you do need to find someone who doesn't gratuitously insult you or your work.
One thing to decide is if you want to continue down the technical path. In that case, you might want to hire a CTO (I agree with those that say you should move to "founder") who has as one of his explicit missions helping you to gain more experience. As part of finding such a person, you might ask for book recommendations in interviews.
But as others have noted, you'll have to check your ego at the door; back in 1971 Jerry Weinberg formulated the concept in his still excellent The Psychology of Computer Programming. If you can't do that, or completely turn it over to the technical people you hire, your venture is in serious jeopardy.
That said, you do need to find someone who doesn't gratuitously insult you or your work.
[deleted]
Hire a CTO to replace yourself. Be a founder.
The only other thing I would add other than hire someone more talented than yourself is to ask a friend you really really trust who has good tech skills to help vet the candidate. You can do the behavioral questions, but you should have at least one representative who can ask the right questions.
Do yourself a favor and don't call yourself a CTO. It makes you sound silly in front of your customers. Call yourself a Founder.
[deleted]
We're launching our beta in several weeks and are about to close our seed round. I've relied heavily on SO, tutorials and gems to get our application to where it is today. I've never had anyone review my code. I've taught myself how to use a continuous deployment flow, write tests, design and integrate REST APIs like Salesforce and Docusign.
With our funding, I need to begin building a technical team. One thing I'm concerned with is bringing on a developer (senior, full stack, or backend) that won't respect me as a programmer. The work I've done to this point has had the aim of reducing the time to goto market and cost- quality has taken a hit to meet those two goals.
As a CTO with no computer science background and no previous experience programming at another company, what role should I hire for first? And when I do, how do I "manage" that individual if they don't respect the work I've done as a programmer?