Ask HN: Seeking advice from programmers for non-programmers
35 comments
A problem I've seen from both sides of this fence is that one side tends to over-simplify what the other side needs to do to get something done.
A business guy may say "oh just slap this together and you're done", while a software guy might say "just go get some sales and we're golden".
I think taking a few minutes to find out the actual effort required to make something happen can go a long way; for both business people and software people.
The other thing that I see happen a lot is that business people tend to want to say "yes" to everything, while software people tend to want to say "no". It makes sense in context, business people want to do whatever it takes to make successful sales, while software people generally want to keep a manageable feature set (they also tend to know the full problem domain a little better than most of the business people they deal with; at least from the technology front).
Of course, these are all generalizations, so you have to take them with a grain of salt.
A business guy may say "oh just slap this together and you're done", while a software guy might say "just go get some sales and we're golden".
I think taking a few minutes to find out the actual effort required to make something happen can go a long way; for both business people and software people.
The other thing that I see happen a lot is that business people tend to want to say "yes" to everything, while software people tend to want to say "no". It makes sense in context, business people want to do whatever it takes to make successful sales, while software people generally want to keep a manageable feature set (they also tend to know the full problem domain a little better than most of the business people they deal with; at least from the technology front).
Of course, these are all generalizations, so you have to take them with a grain of salt.
>is that business people tend to want to say "yes" to everything, while software people tend to want to say "no"
That is so true, and i see that every single day. I guess NO is a bad word in marketing/sales, whereas it's actually a pretty good one in the dev world. It usually means, less feature bloat, lesser maintenance.
That is so true, and i see that every single day. I guess NO is a bad word in marketing/sales, whereas it's actually a pretty good one in the dev world. It usually means, less feature bloat, lesser maintenance.
> they also tend to know the full problem domain a little better than most of the business people they deal with
This is too often overlooked.
It is development's job to "re-engineer" this domain in some fashion. Don't neglect the expertise they bring to the table and/or acquire in doing so.
And... if you are dealing with a corresponding "business type" at the client/customer, realize that this applies on the other side, too. When working with/through such contacts, you may not being gaining a full picture of what their end users really need.
Better model: Put the users and developers in closer contact with each other. Use your expertise to mediate this especially from a financial and legal perspective. Scheduling fits somewhere in between, and should have the active participation of both parties -- business and technical on your side, and ideally both business and technical on their side as well.
It can be like a light bulb going off, when e.g.your tech lead finally gets to communicate directly with theirs. An hour -- sometimes 15 minutes -- of direct communication can obviate weeks of "memos" and such. Especially if they are freed to communicate in a forthright manner on an ongoing basis.
Your job is to define the boundaries of communication and to adequately defend property rights and profitability. Don't insert yourself too heavily into nor try to micromanage the rest. Assuming you have good staff.
This is based upon my ad hoc observation of situations that have worked and situations that haven't. I'm not formally an "expert" in this.
This is too often overlooked.
It is development's job to "re-engineer" this domain in some fashion. Don't neglect the expertise they bring to the table and/or acquire in doing so.
And... if you are dealing with a corresponding "business type" at the client/customer, realize that this applies on the other side, too. When working with/through such contacts, you may not being gaining a full picture of what their end users really need.
Better model: Put the users and developers in closer contact with each other. Use your expertise to mediate this especially from a financial and legal perspective. Scheduling fits somewhere in between, and should have the active participation of both parties -- business and technical on your side, and ideally both business and technical on their side as well.
It can be like a light bulb going off, when e.g.your tech lead finally gets to communicate directly with theirs. An hour -- sometimes 15 minutes -- of direct communication can obviate weeks of "memos" and such. Especially if they are freed to communicate in a forthright manner on an ongoing basis.
Your job is to define the boundaries of communication and to adequately defend property rights and profitability. Don't insert yourself too heavily into nor try to micromanage the rest. Assuming you have good staff.
This is based upon my ad hoc observation of situations that have worked and situations that haven't. I'm not formally an "expert" in this.
Dan your points are all valid and your intent clean.
As a programmer turned business person, who (IMHO) has a decent enough grasp of both, I'll say this: you're missing the elephant in the room here.
Your approach to the problem seems to be: I have an idea and a plan, I just need someone to build it. What you should be doing though is seeking out your opposite: Programmers who have built the software, but need someone to sell it!
Programmers by their nature will solve problems that they know about on their own. They don't need any real motivation other than the problem existing for them. Where they tend to fail is extending that into a business: Do enough people share this problem, and will they somehow part with money to solve it?
The proof is all around us - there are so many free or ad-supported tools that are that way simply because the programmers behind the software have no idea how to get people to pay them for their work. (Discounting the blindingly obvious non-starters, of course)
If I were in your shoes, I'd seek out programmers working on solutions in domains that you are familiar with (key, as programmers equate domain knowledge to ability) and approach them about the art of selling their valuable creations to people that need problems solved.
As a programmer turned business person, who (IMHO) has a decent enough grasp of both, I'll say this: you're missing the elephant in the room here.
Your approach to the problem seems to be: I have an idea and a plan, I just need someone to build it. What you should be doing though is seeking out your opposite: Programmers who have built the software, but need someone to sell it!
Programmers by their nature will solve problems that they know about on their own. They don't need any real motivation other than the problem existing for them. Where they tend to fail is extending that into a business: Do enough people share this problem, and will they somehow part with money to solve it?
The proof is all around us - there are so many free or ad-supported tools that are that way simply because the programmers behind the software have no idea how to get people to pay them for their work. (Discounting the blindingly obvious non-starters, of course)
If I were in your shoes, I'd seek out programmers working on solutions in domains that you are familiar with (key, as programmers equate domain knowledge to ability) and approach them about the art of selling their valuable creations to people that need problems solved.
Can't agree with this enough. I'm a programmer, and I solve lots of problems. Build lots of things. But not only do I not know how to sell anything, I don't even know anybody who knows how, or know how to meet anybody who knows how. And there's no way it's just me.
The typical view of a business type by a software engineer is not pretty. It gets pretty close to, we do all the work, they do little but interfere with us, and then they take all the money. So it's an uphill battle to have a good relationship. (The _truth_ of this view varies wildly from company to company, but the perception is always there.)
See the movie "Office Space" for details. :)
Things that are a good idea: * Your technical staff is probably very smart, and not just about their jobs. Listen to them. They're particularly good at working with data. If they say that your market research doesn't sound right, even though that's your job and not theirs, it's worth going through it. Geeks are generally happy to learn things, too, so if you're actually right and can show it, we really like that too.
* Give your geeks the big picture. It really does help, because we're constantly making long-term tradeoffs, and if we know where the company is going, we'll be less likely to need to say, "Uh, we need to do a massive project for that feature, sorry!"
* Try to give clear requirements and make changes early. It's not an easy thing to ask, but a change made in planning phases is cheap. A change made when the project is in beta is expensive if not impossible. A business type giving a list of changes every day late in the project is infuriating.
* As a corollary, ask to see things early. A prototype with partial functionality is good. It's really true that a lot of times a business type just can't reasonably know what they want until they have something to play with (which is fine), so get that sooner, when things can be cheaply redesigned.
* Understand that changes aren't free. Schedules get made based on original requirements. If the requirements change, it will take longer to finish. If the deadline is fixed, you can't ask for something new without giving something up. Business types that understand this are much, much easier to work with than ones that don't, and are by far the exception.
* Programming requires uninterrupted time, like making a painting or writing an essay. If someone asks you a five minute question, it can take half an hour or more to get back in the flow of what you were doing. Try and send not-urgent questions via email, schedule meetings for the beginning or end of days, and if you can take, "Can I get back to you in 15 minutes?" for an answer, that'd help.
* Understand that these guys can, and do, do the math with respect to compensation. When I had a CEO that asked everyone to put in 60 hour weeks, and then we ended up with 3 figure bonuses when he got a 7 figure bonus at the end of the project - none of us ever respected him. If we're giving more than expected, and we will, show us some of the reward, or watch us leave. Even in a down economy, a competent techie can find greener pastures if it turns into us vs. them.
* Techies are not big on hierarchy and authority. After all, especially in a technology company, we know more about what we do than you do, and if that's the core product, there's often conflict between who is in charge and who knows about what actually is the product that pays the bills. We like to think that we work _with_ the business types, not _for_ the business types. If you project the story of doing some useful work that we don't want to do (like find buyers for our product, get us good press, find investors, stuff we want to happen but don't want to do), it'll go a lot better than if you present yourselves as 'leaders' with 'vision' and expect us to do your bidding. It's a team, and while we get that the buck has to stop somewhere and it's going to be the person with the title in the end, prima-donna VPs are just as well liked by us as prima-donna developers by you.
Someone could write an equivalent set of bullets in the other direction - yes, business people are smart, their jobs are hard, and they're often worth the salary they earn too (and certainly a lot of techies are useless.) But I'm probably not that someone. :) Hope that this is somewhat useful to you, though! I certainly have found that some business people treated technical people well and were good to work with, and others, not so much.
See the movie "Office Space" for details. :)
Things that are a good idea: * Your technical staff is probably very smart, and not just about their jobs. Listen to them. They're particularly good at working with data. If they say that your market research doesn't sound right, even though that's your job and not theirs, it's worth going through it. Geeks are generally happy to learn things, too, so if you're actually right and can show it, we really like that too.
* Give your geeks the big picture. It really does help, because we're constantly making long-term tradeoffs, and if we know where the company is going, we'll be less likely to need to say, "Uh, we need to do a massive project for that feature, sorry!"
* Try to give clear requirements and make changes early. It's not an easy thing to ask, but a change made in planning phases is cheap. A change made when the project is in beta is expensive if not impossible. A business type giving a list of changes every day late in the project is infuriating.
* As a corollary, ask to see things early. A prototype with partial functionality is good. It's really true that a lot of times a business type just can't reasonably know what they want until they have something to play with (which is fine), so get that sooner, when things can be cheaply redesigned.
* Understand that changes aren't free. Schedules get made based on original requirements. If the requirements change, it will take longer to finish. If the deadline is fixed, you can't ask for something new without giving something up. Business types that understand this are much, much easier to work with than ones that don't, and are by far the exception.
* Programming requires uninterrupted time, like making a painting or writing an essay. If someone asks you a five minute question, it can take half an hour or more to get back in the flow of what you were doing. Try and send not-urgent questions via email, schedule meetings for the beginning or end of days, and if you can take, "Can I get back to you in 15 minutes?" for an answer, that'd help.
* Understand that these guys can, and do, do the math with respect to compensation. When I had a CEO that asked everyone to put in 60 hour weeks, and then we ended up with 3 figure bonuses when he got a 7 figure bonus at the end of the project - none of us ever respected him. If we're giving more than expected, and we will, show us some of the reward, or watch us leave. Even in a down economy, a competent techie can find greener pastures if it turns into us vs. them.
* Techies are not big on hierarchy and authority. After all, especially in a technology company, we know more about what we do than you do, and if that's the core product, there's often conflict between who is in charge and who knows about what actually is the product that pays the bills. We like to think that we work _with_ the business types, not _for_ the business types. If you project the story of doing some useful work that we don't want to do (like find buyers for our product, get us good press, find investors, stuff we want to happen but don't want to do), it'll go a lot better than if you present yourselves as 'leaders' with 'vision' and expect us to do your bidding. It's a team, and while we get that the buck has to stop somewhere and it's going to be the person with the title in the end, prima-donna VPs are just as well liked by us as prima-donna developers by you.
Someone could write an equivalent set of bullets in the other direction - yes, business people are smart, their jobs are hard, and they're often worth the salary they earn too (and certainly a lot of techies are useless.) But I'm probably not that someone. :) Hope that this is somewhat useful to you, though! I certainly have found that some business people treated technical people well and were good to work with, and others, not so much.
I'm a programmer by trade but I also have my own startup and have a decent amount of business experience. I'm writing this from a programmer's perspective though.
> How do software engineers perceive business types?
The idiots who constantly make bad decisions that cause programmers to work even harder and miss sleep.
> How do they come to respect or disrespect someone in this role?
"We promised we'd implement this feature to a very important client by next week. How hard is it?" Generally for a feature that is esoteric and nearly impossible to implement. And usually for a client that doesn't generate much revenue.
> How can I best approach a software engineer with an idea?
Talk to them. Ask their opinion. Most programmers love to know details, backstory, and to be part of the process.
> What can a business type do to build trust with a programmer?
Talk to them. Programmers hate to be asked or told to do something without knowing why. You'll generally get a better result if they know why the feature needs to be added instead of just telling them to put a button here that does this.
> Horror stories or success stories about these two worlds coming together in startup glory or catastrophe
I was employee #2 at a web startup that was barely in the black (perhaps just solvent) after about 5 years in business. I ran IT. The owners brought in an angel who invested a nominal amount of money for a ridiculous amount of ownership (47.5%). The angel brought in a CEO. The CEO brought in salesmen. I hired a few programmers and a network guy. The salesmen brought in even more salesmen. The CEO brought in someone to oversee me.
The CEO was a "big-bang" kind of guy so he immediately started pitching the product to anyone he could find. The product wasn't ready and hit all sort of problems. Lots of infighting and little political factions starting springing up between the new guys and the old guard. Both sides thought each other were idiots. We knew the market and the new guys had no experience with either web or the industry we were in. We knew how to save money and generate profit and they knew how to spend it.
Within 2 years there were at least 8 VPs in a 40-person company (only about 20 of them worked full-time onsite). By the time I left, the company had 60+ people on payroll, with about 10-15 of them being IT. There were probably a dozen VPs (I lost count and didn't care anymore), and was burning about $7M/yr with no sign of turning a profit. The "business types" are still figuring out how to make money, still over promising and under delivering, and just about everyone there hates the place.
> What motivates programmers? Success? Personal fulfillment? Money?
Challenge and accolade. A good programmer loves to solve puzzles and wants to be acknowledged for his or her work. Very few things are as deflating as busting ass on a feature that someone else gets all credit for. Programmers love toys- this includes fast hardware and good equipment. If your programmers don't have dual screens and a computer built in the past 12 months, something is wrong.
> What do programmers think motivates business types?
Ego. Resume building. Money. Job titles.
> How do software engineers perceive business types?
The idiots who constantly make bad decisions that cause programmers to work even harder and miss sleep.
> How do they come to respect or disrespect someone in this role?
"We promised we'd implement this feature to a very important client by next week. How hard is it?" Generally for a feature that is esoteric and nearly impossible to implement. And usually for a client that doesn't generate much revenue.
> How can I best approach a software engineer with an idea?
Talk to them. Ask their opinion. Most programmers love to know details, backstory, and to be part of the process.
> What can a business type do to build trust with a programmer?
Talk to them. Programmers hate to be asked or told to do something without knowing why. You'll generally get a better result if they know why the feature needs to be added instead of just telling them to put a button here that does this.
> Horror stories or success stories about these two worlds coming together in startup glory or catastrophe
I was employee #2 at a web startup that was barely in the black (perhaps just solvent) after about 5 years in business. I ran IT. The owners brought in an angel who invested a nominal amount of money for a ridiculous amount of ownership (47.5%). The angel brought in a CEO. The CEO brought in salesmen. I hired a few programmers and a network guy. The salesmen brought in even more salesmen. The CEO brought in someone to oversee me.
The CEO was a "big-bang" kind of guy so he immediately started pitching the product to anyone he could find. The product wasn't ready and hit all sort of problems. Lots of infighting and little political factions starting springing up between the new guys and the old guard. Both sides thought each other were idiots. We knew the market and the new guys had no experience with either web or the industry we were in. We knew how to save money and generate profit and they knew how to spend it.
Within 2 years there were at least 8 VPs in a 40-person company (only about 20 of them worked full-time onsite). By the time I left, the company had 60+ people on payroll, with about 10-15 of them being IT. There were probably a dozen VPs (I lost count and didn't care anymore), and was burning about $7M/yr with no sign of turning a profit. The "business types" are still figuring out how to make money, still over promising and under delivering, and just about everyone there hates the place.
> What motivates programmers? Success? Personal fulfillment? Money?
Challenge and accolade. A good programmer loves to solve puzzles and wants to be acknowledged for his or her work. Very few things are as deflating as busting ass on a feature that someone else gets all credit for. Programmers love toys- this includes fast hardware and good equipment. If your programmers don't have dual screens and a computer built in the past 12 months, something is wrong.
> What do programmers think motivates business types?
Ego. Resume building. Money. Job titles.
Having spent time on both sides, I'll offer one pro-tip:
Never comment on how difficult something should be. Just don't do it. Physically restrain yourself if necessary from saying, "but it's only doing X, it shouldn't be that difficult." [1]
If a smart technical person says that it's going to be hard, then it is going to be hard. If it really is a blocking issue for you, you instead need to bring your team into the bigger picture and ask, "At the end of the day, we're trying to solve a problem like X. How can we permute X into something we can solve more easily?"
[1] Only if you are technical can you get away with this. You'll still be wrong if the other person has thought about it quite a bit more than you have, but at least you'll be able to understand and appreciate the explanation they'll throw back at you about what deep complication makes the problem hard.
Never comment on how difficult something should be. Just don't do it. Physically restrain yourself if necessary from saying, "but it's only doing X, it shouldn't be that difficult." [1]
If a smart technical person says that it's going to be hard, then it is going to be hard. If it really is a blocking issue for you, you instead need to bring your team into the bigger picture and ask, "At the end of the day, we're trying to solve a problem like X. How can we permute X into something we can solve more easily?"
[1] Only if you are technical can you get away with this. You'll still be wrong if the other person has thought about it quite a bit more than you have, but at least you'll be able to understand and appreciate the explanation they'll throw back at you about what deep complication makes the problem hard.
Your choice of the word "cog" to represent a programmer and "gear" to represent a team indicates you might be internally (to your mind) objectifying the people involved with your potential projects. I could see such an internal objectification causing various problems with your interactions with the "cogs/gear" in various ways during a project. You can quickly lose someone's respect if he learns that you think of him as a replaceable part of a soulless machine.
A problem for "business types" is that they are trained to think of people as "human resources." This is probably a bad idea on any scale of team/organization. But it's an absolutely horrible idea w.r.t. the small-scale teams of which startup companies are made.
A problem for "business types" is that they are trained to think of people as "human resources." This is probably a bad idea on any scale of team/organization. But it's an absolutely horrible idea w.r.t. the small-scale teams of which startup companies are made.
From my own experience as a confirmed programmer with little interest in business, here's a couple of observations:
Programmers end up knowing a heck of a lot about the business just by virtue of needing to know how it operates in order to turn it into software. Use this knowledge. Include programmers in high-level discussions occasionally to get "buy-in" at an early stage of development (before anything like "requirements gathering" happens). This reduces the possibility for mismatch in expectations between "business people" and "programmers", which is a ready source of unhappiness for programmers and business people alike.
I've always been happiest and most productive in situations where the business people above me shield me from the other business people and let me get on with my job. So many others have observed how detrimental interruptions and rapidly shifting requirements (i.e. more rapid than 1 iteration) can be. Insulate programmers from the kinds of problems which are really no concern of theirs. Be the point of contact for other people who need programming things to happen (either as external or internal stakeholders). That's not to say that a programmer shouldn't be interacting with all areas of a business, rather, they should be able to do it in a structured way, not as a never ending stream of interruptions and fires to extinguish on an ad hoc basis.
Programmers end up knowing a heck of a lot about the business just by virtue of needing to know how it operates in order to turn it into software. Use this knowledge. Include programmers in high-level discussions occasionally to get "buy-in" at an early stage of development (before anything like "requirements gathering" happens). This reduces the possibility for mismatch in expectations between "business people" and "programmers", which is a ready source of unhappiness for programmers and business people alike.
I've always been happiest and most productive in situations where the business people above me shield me from the other business people and let me get on with my job. So many others have observed how detrimental interruptions and rapidly shifting requirements (i.e. more rapid than 1 iteration) can be. Insulate programmers from the kinds of problems which are really no concern of theirs. Be the point of contact for other people who need programming things to happen (either as external or internal stakeholders). That's not to say that a programmer shouldn't be interacting with all areas of a business, rather, they should be able to do it in a structured way, not as a never ending stream of interruptions and fires to extinguish on an ad hoc basis.
I was a non-programmer, and I wanted a program written. Nobody was going to write it, and I didn't have the money to pay someone to write it.
So what did I do?
I learned to program, in order to write that program. It took a while, but it was worth it. And it turned out great. And years later I'm still learning. The learning never stops. That is a good thing, not bad.
I would advise anyone to not think of themselves as a "type" but instead to figure out what you want to do, and do it. It might take some hard work. But again, it is worth it.
So how do I perceive non-programmers? They are just people who either have not discovered the concept of what programming can do for you, or they have discovered it but have given up on their own ability to learn (fallen into the "type" misconception). Kind of sad either way.
So what did I do?
I learned to program, in order to write that program. It took a while, but it was worth it. And it turned out great. And years later I'm still learning. The learning never stops. That is a good thing, not bad.
I would advise anyone to not think of themselves as a "type" but instead to figure out what you want to do, and do it. It might take some hard work. But again, it is worth it.
So how do I perceive non-programmers? They are just people who either have not discovered the concept of what programming can do for you, or they have discovered it but have given up on their own ability to learn (fallen into the "type" misconception). Kind of sad either way.
Also interested in hearing people's thoughts on this, as a "demand side" guy who asks programmers to do stuff.
My advice, FWIW, is that talking to and really trying to understand the problems faced by the engineers/developers working for you goes a VERY long way. Typically, they just want to know that someone is aware of their issues and is working with them, not against them.
Not a unique problem though - that's how all management needs to function. Although the technical barriers in programming can be daunting (as I think the OP notes).
My advice, FWIW, is that talking to and really trying to understand the problems faced by the engineers/developers working for you goes a VERY long way. Typically, they just want to know that someone is aware of their issues and is working with them, not against them.
Not a unique problem though - that's how all management needs to function. Although the technical barriers in programming can be daunting (as I think the OP notes).
You'll get significantly better returns on both your time and your money if you approach a developer with a conversation instead of directions.
In other words, ask questions while you're trying to figure out the best way to do things. The nice thing about most developers is that they have experience in a lot of different problem domains, and they may have solutions available that you hadn't previously considered.
In other words, ask questions while you're trying to figure out the best way to do things. The nice thing about most developers is that they have experience in a lot of different problem domains, and they may have solutions available that you hadn't previously considered.
Dan, I can't speak to all your questions, but I'll try to help out where I can. in my experience the easiest way for a techincal person to respect a "business type" is for the business guy to know a thing or two about coding and software development. This doesn't mean knowing how to build Twitter over a weekend, but you do need to know what they're going through.
With that being said, the best way to pitch an idea to a technical person (again from what I read and experience) is to build something (even tiny) yourself. It's sort of like asking a programming question: doing all of your research and going through the problem before saying "I'm stuck, please help" generates a better response.
This is the process I'm going through now. I don't have a technical background, but I'm trying my damn hardest to build something before I take the time to con some hacker to help me with building out he product :-).
With that being said, the best way to pitch an idea to a technical person (again from what I read and experience) is to build something (even tiny) yourself. It's sort of like asking a programming question: doing all of your research and going through the problem before saying "I'm stuck, please help" generates a better response.
This is the process I'm going through now. I don't have a technical background, but I'm trying my damn hardest to build something before I take the time to con some hacker to help me with building out he product :-).
While I truly applaud you for trying to build at least something yourself, I have to ask why you think you need to do that? I, as a programmer, wouldn't expect you to build a prototype. What I _would_ expect is a very detailed list of use cases that shows you've thought this through.
Sure, that's not something you can simply show in a five minute conversation, but mockups are great for this purpose.
Sure, that's not something you can simply show in a five minute conversation, but mockups are great for this purpose.
As I explained with gdp, I believe you need to know some bit of the technical side of things to succeed in a tech. start-up. To me it just makes sense. I have tried the mock up approach, with not so great results. So right now I'm trying a different approach.
I love solving problems, and I like making things. In my learning I've come to enjoy doing this through coding, but I know that my skills currently won't fly in scaling a startup.
I love solving problems, and I like making things. In my learning I've come to enjoy doing this through coding, but I know that my skills currently won't fly in scaling a startup.
I have enormous respect for business people who have no technical knowledge, and behave accordingly.
Conversely, if you know that you know nothing about parts of what I do, then why do you feel it's necessary to have input into it?
I think knowing your own strengths and weaknesses and allowing others to employ their own strengths is just as valuable a skill as actually learning a bunch of technical stuff.
Conversely, if you know that you know nothing about parts of what I do, then why do you feel it's necessary to have input into it?
I think knowing your own strengths and weaknesses and allowing others to employ their own strengths is just as valuable a skill as actually learning a bunch of technical stuff.
>I have enormous respect for business people who have no technical knowledge, and behave accordingly.
Conversely, if you know that you know nothing about parts of what I do, then why do you feel it's necessary to have input into it?
I agree, I think this ties back to what icey mentioned in his/her parent comment.
I definitely know my strength doesn't lie within the technical side of things, but I do know that a proven model of success for a technology start-up is for the founders to have some sort of technical background. You need to be able to understand the problems that happen which can hamper the growth of the business. That is why learning how to code is important to me.
Conversely, if you know that you know nothing about parts of what I do, then why do you feel it's necessary to have input into it?
I agree, I think this ties back to what icey mentioned in his/her parent comment.
I definitely know my strength doesn't lie within the technical side of things, but I do know that a proven model of success for a technology start-up is for the founders to have some sort of technical background. You need to be able to understand the problems that happen which can hamper the growth of the business. That is why learning how to code is important to me.
I think you're on the right path... Getting a technical background is important to get a feel of the problems that your engineers face and as long as you know that they know better than you and let them decide the technical choices, it's going to work well...
And, learning how to code is a great way to learn that things are sometimes much more complicated than they seem :-)
On the other side, I believe that when you look for a programmer you should look for someone who has a little interest in business and tries to learn... Having both founders trying to understand what the other does goes a long way to having good communication.
On the other side, I believe that when you look for a programmer you should look for someone who has a little interest in business and tries to learn... Having both founders trying to understand what the other does goes a long way to having good communication.
I'll answer the ones I have answers for:
- How do software engineers perceive business types?
The stereotype is that you guys are a bit jockish, and/or that you tend to have good social skills but less hard/technical skills.
- How do they come to respect or disrespect someone in this role?
I'll respect a business person who makes the effort to understand the engineering (and I don't mean humoring me by asking for a one hour programming lesson - it's more important that you understand technical issues on a high level), as well as give comprehensible and straightforward answers to any questions I have about his. A smart programmer has to know when to put business before his sense of engineering elegance or desire to make a cool product, and if you can be sensitive to how hard/frustrating that can sometimes be, so much the better.
- What can a business type do to build trust with a programmer?
Try to understand what I'm doing and what's hard about it, and explain to me the same about what you're doing.
- What motivates programmers? Success? Personal fulfillment? Money?
Depends, but I'd say success and money in a startup are nearly, if not, the same thing. Desire for personal fulfillment is probably a little more common among programmers than business types, but that might be my own stereotype of business types talking (though I knew a lot of business students as an undergrad, and dated one for two years, so it's not totally unjustified).
- What do programmers think motivates business types?
Money.
- How do software engineers perceive business types?
The stereotype is that you guys are a bit jockish, and/or that you tend to have good social skills but less hard/technical skills.
- How do they come to respect or disrespect someone in this role?
I'll respect a business person who makes the effort to understand the engineering (and I don't mean humoring me by asking for a one hour programming lesson - it's more important that you understand technical issues on a high level), as well as give comprehensible and straightforward answers to any questions I have about his. A smart programmer has to know when to put business before his sense of engineering elegance or desire to make a cool product, and if you can be sensitive to how hard/frustrating that can sometimes be, so much the better.
- What can a business type do to build trust with a programmer?
Try to understand what I'm doing and what's hard about it, and explain to me the same about what you're doing.
- What motivates programmers? Success? Personal fulfillment? Money?
Depends, but I'd say success and money in a startup are nearly, if not, the same thing. Desire for personal fulfillment is probably a little more common among programmers than business types, but that might be my own stereotype of business types talking (though I knew a lot of business students as an undergrad, and dated one for two years, so it's not totally unjustified).
- What do programmers think motivates business types?
Money.
- How do they come to respect or disrespect someone in this role?
Earn respect by investing not only in your product, but in your programmers. If you're a carpenter, you'd think your boss was crazy for asking you to drive nails without hammers or a nail-gun; and yet, this is how programming environments sometimes operate, causing consternation.
Earn disrespect by treating programmers like cogs. Do not ever assume that you can simply replace one programmer with another; there is an absolute chasm between the skills of the best and the worst. One way to judge your programmers is in adaptability; do they at least seem willing to tackle anything you throw at them, or do they not really have a clue how to start most of your ideas?
- How can I best approach a software engineer with an idea?
Do not make any assumptions about how simple the implementation could be. There are hard things that sound easy, and vice-versa. At the same time, be prepared to deconstruct your idea to say "well what if we only did X and Y"; you may be surprised how different the answer is.
- What can a business type do to build trust with a programmer?
Be detailed; communicate without filters. There's nothing worse than being asked to drop everything to provide one or two tidbits of information "immediately", only to find out later that the wrong question was being asked and that the priority wasn't really accurate. Heck, if you have to tell the programmer your 3-year plan for the product, do it; that may affect how the implementation proceeds.
Be flexible. Programmers will be productive at the weirdest times. If you see someone who comes in late and works for 12 hours straight, then takes a day off, they could still be the most productive software developer you've ever seen. Even if we aren't actively working on an idea in front of a computer, we are often putting it together in our heads. Perception is not reality in most cases. Having said that, do demand evidence (simple documentation, occasional updates, and definitely prototypes).
- What motivates programmers? Success? Personal fulfillment? Money?
I want to feel like my projects are useful. I want to have the freedom to design, and not feel "stuck" with any bad decisions.
Money is only important enough for me to live comfortably (I don't need a mansion or a yacht). On the other hand, if it became clear that someone who contributed very little was going to be showered with millions from my ideas, I'd definitely want my cut.
- How do software engineers perceive business types?
As a necessary evil. :) Software is relatively easy to distribute, so there isn't much to prevent people from acquiring your product. On the other hand, there is a lot to prevent them from finding products, so marketing is quite important. Not being sued is important. :)
Earn respect by investing not only in your product, but in your programmers. If you're a carpenter, you'd think your boss was crazy for asking you to drive nails without hammers or a nail-gun; and yet, this is how programming environments sometimes operate, causing consternation.
Earn disrespect by treating programmers like cogs. Do not ever assume that you can simply replace one programmer with another; there is an absolute chasm between the skills of the best and the worst. One way to judge your programmers is in adaptability; do they at least seem willing to tackle anything you throw at them, or do they not really have a clue how to start most of your ideas?
- How can I best approach a software engineer with an idea?
Do not make any assumptions about how simple the implementation could be. There are hard things that sound easy, and vice-versa. At the same time, be prepared to deconstruct your idea to say "well what if we only did X and Y"; you may be surprised how different the answer is.
- What can a business type do to build trust with a programmer?
Be detailed; communicate without filters. There's nothing worse than being asked to drop everything to provide one or two tidbits of information "immediately", only to find out later that the wrong question was being asked and that the priority wasn't really accurate. Heck, if you have to tell the programmer your 3-year plan for the product, do it; that may affect how the implementation proceeds.
Be flexible. Programmers will be productive at the weirdest times. If you see someone who comes in late and works for 12 hours straight, then takes a day off, they could still be the most productive software developer you've ever seen. Even if we aren't actively working on an idea in front of a computer, we are often putting it together in our heads. Perception is not reality in most cases. Having said that, do demand evidence (simple documentation, occasional updates, and definitely prototypes).
- What motivates programmers? Success? Personal fulfillment? Money?
I want to feel like my projects are useful. I want to have the freedom to design, and not feel "stuck" with any bad decisions.
Money is only important enough for me to live comfortably (I don't need a mansion or a yacht). On the other hand, if it became clear that someone who contributed very little was going to be showered with millions from my ideas, I'd definitely want my cut.
- How do software engineers perceive business types?
As a necessary evil. :) Software is relatively easy to distribute, so there isn't much to prevent people from acquiring your product. On the other hand, there is a lot to prevent them from finding products, so marketing is quite important. Not being sued is important. :)
I'm an apps developer (I work more "end product" than services) and architect who deals day to day with system engineers (who build the tools we build upon), product managers, project managers and testers. So i'm a few steps down from yourself and also have a step "lower" in regards to system engineers (who are programmers programmers and know more about the system than the requirements, if you get what I mean).
Sorry my world isn't start up world, I work for a big 'ol transport company but I hope this helps.
- How do software engineers perceive business types? - How do they come to respect or disrespect someone in this role?
Depends, but the easy trap to fall into is that they will think that you are making decisions that effect them without understanding their problems. They may not understand the sales process, they may not understand the considered risk you took when you sold that feature YOU KNOW you didn't have even though clinching that deal was strategically essential.
Therefore you really need to ensure that you communicate effectively and listen to them effectively. Most mis-placed anger is just a massive misunderstanding. You can also mitigate this by having a reference in their development-sphere who backs you up if your decisions are brought into doubt (which you need in companies that are so large that you don't have the time to give to them).
- How can I best approach a software engineer with an idea?
Slow the fuck down. I mean sure build it up a bit but don't pile on the features, it needs to be a challenge but business types seem to be very good at talking about a huge number of features which makes projects sound like death marches. Work on the core principles of the project and leave the star-gazing out of the initial conversation.
Oh and have a plan and some work done that looks like work. A lot of devs impressions from such meets are: "he wants me to do all the work". Especially with tech start-ups. Some devs don't appreciate how much work the rest of it is.
- What can a business type do to build trust with a programmer?
Listen, same as with anyone. You may need to poke them a little more than other people to get their "real" opinion sometimes but most coders are the same as everyone else.
- What motivates programmers? Success? Personal fulfillment? Money?
Tech, interesting tech or an exciting sounding project, then money. Sometimes its the other way round.
- What do programmers think motivates business types?
Money and politics (Alpha-malism)
- How do software engineers perceive business types? - How do they come to respect or disrespect someone in this role?
Depends, but the easy trap to fall into is that they will think that you are making decisions that effect them without understanding their problems. They may not understand the sales process, they may not understand the considered risk you took when you sold that feature YOU KNOW you didn't have even though clinching that deal was strategically essential.
Therefore you really need to ensure that you communicate effectively and listen to them effectively. Most mis-placed anger is just a massive misunderstanding. You can also mitigate this by having a reference in their development-sphere who backs you up if your decisions are brought into doubt (which you need in companies that are so large that you don't have the time to give to them).
- How can I best approach a software engineer with an idea?
Slow the fuck down. I mean sure build it up a bit but don't pile on the features, it needs to be a challenge but business types seem to be very good at talking about a huge number of features which makes projects sound like death marches. Work on the core principles of the project and leave the star-gazing out of the initial conversation.
Oh and have a plan and some work done that looks like work. A lot of devs impressions from such meets are: "he wants me to do all the work". Especially with tech start-ups. Some devs don't appreciate how much work the rest of it is.
- What can a business type do to build trust with a programmer?
Listen, same as with anyone. You may need to poke them a little more than other people to get their "real" opinion sometimes but most coders are the same as everyone else.
- What motivates programmers? Success? Personal fulfillment? Money?
Tech, interesting tech or an exciting sounding project, then money. Sometimes its the other way round.
- What do programmers think motivates business types?
Money and politics (Alpha-malism)
[deleted]
> How can I best approach a software engineer with an idea?
Back up a step. Why are you approaching said engineer with that idea? Yes, I know that you want said engineer to build it, but why should anyone build that idea and not some other idea?
I'm sure that you've got good supporting arguments, but if you don't provide them, you're indistinguishable from the vast majority, who have nothing.
It's okay if there are holes in your arguments IF you admit them and talk about them. If we find significant holes that you don't tell us about, our experience tells us that there are additional problems and that you're incompetent and/or deceptive. That's not likely to lead where you'd like to go.
In short, tell us everything. We'll ignore what we don't need to know.
Back up a step. Why are you approaching said engineer with that idea? Yes, I know that you want said engineer to build it, but why should anyone build that idea and not some other idea?
I'm sure that you've got good supporting arguments, but if you don't provide them, you're indistinguishable from the vast majority, who have nothing.
It's okay if there are holes in your arguments IF you admit them and talk about them. If we find significant holes that you don't tell us about, our experience tells us that there are additional problems and that you're incompetent and/or deceptive. That's not likely to lead where you'd like to go.
In short, tell us everything. We'll ignore what we don't need to know.
Your prompts are very broad and a discussion based on them is open to generalizations that may not apply to the people you eventually end up working with.
You are far better off discussing these questions with the people you intend to have around you when you start your new venture.
You are far better off discussing these questions with the people you intend to have around you when you start your new venture.
Be organised as hell and keep things under control. The programmer will appreciate when things are running smoothly, and all he has to do is fill in the correct spots and then get to coding, and does not have to worry about if articles are out, if there are spelling errors on pages or stuff like that.
Be the one that stays calm, keeps the processes running smoothly, keeps on doing analysis to make sure things are running on the right path.
When the programmer feels he is in a smoothly running engine, then he will need you around. When you start discussing things all the time and panicking, he will want to step into your territory to help out, and then he will start worrying and become a lot less productive.
Be the one that stays calm, keeps the processes running smoothly, keeps on doing analysis to make sure things are running on the right path.
When the programmer feels he is in a smoothly running engine, then he will need you around. When you start discussing things all the time and panicking, he will want to step into your territory to help out, and then he will start worrying and become a lot less productive.
Show your tech guy your deliverables; what you're actually adding. He'll be able to point and say, "I did this and this and this and the proof is right there." You should be able to do the same.
If you're talking about compensation, make sure that everything is clear and out in the open and that there is no ambiguity about terms or conditions. This is really just a general rule for not getting in a spat.
Know how to set priorities, keep your scope focused, and explain the business reasons for any change you're driving. Little else is more upsetting than a nightmarish task seeming important but really being inconsequential.
If you're talking about compensation, make sure that everything is clear and out in the open and that there is no ambiguity about terms or conditions. This is really just a general rule for not getting in a spat.
Know how to set priorities, keep your scope focused, and explain the business reasons for any change you're driving. Little else is more upsetting than a nightmarish task seeming important but really being inconsequential.
- How do software engineers perceive business types?
Business types are people. I evaluate on character plus effectiveness. When forming an opinion, I generally look at their past success, their history of screwing people over (or not), and their smarmyness (or not), as well as their ability to communicate.
- How do they come to respect or disrespect someone in this role?
See above.
- How can I best approach a software engineer with an idea?
With a referral and/or some demonstrated way that you've done a ton of homework, and you understand what you're getting into.
Also, please demonstrate respect and partnership. "We need a coder for this", while not overtly disrespectful, implies that you see your technical partners job as one-dimensional.
- What can a business type do to build trust with a programmer?
Good referrals, pay invoices ahead of schedule, don't change scope often or arbitrarily.
- Horror stories or success stories about these two worlds coming together in startup glory or catastrophe
Rather not share right now.
- What motivates programmers? Success? Personal fulfillment? Money?
Some combination. I think most of us need adequate levels of all of the above, with one factor we can point to as being excellent.
- What do programmers think motivates business types?
Money, ego.
Business types are people. I evaluate on character plus effectiveness. When forming an opinion, I generally look at their past success, their history of screwing people over (or not), and their smarmyness (or not), as well as their ability to communicate.
- How do they come to respect or disrespect someone in this role?
See above.
- How can I best approach a software engineer with an idea?
With a referral and/or some demonstrated way that you've done a ton of homework, and you understand what you're getting into.
Also, please demonstrate respect and partnership. "We need a coder for this", while not overtly disrespectful, implies that you see your technical partners job as one-dimensional.
- What can a business type do to build trust with a programmer?
Good referrals, pay invoices ahead of schedule, don't change scope often or arbitrarily.
- Horror stories or success stories about these two worlds coming together in startup glory or catastrophe
Rather not share right now.
- What motivates programmers? Success? Personal fulfillment? Money?
Some combination. I think most of us need adequate levels of all of the above, with one factor we can point to as being excellent.
- What do programmers think motivates business types?
Money, ego.
It may be helpful to remember that programmers look at things logically. That's why I'm no good at sales. I look for direct paths and solutions, and understand yes/no, not negotiations. I tell you this to show how/why I have respect for effective marketers. It's a bit like magic to me because my brain doesn't work that way (so you see how the tables can turn).
As for the questions, think about it in terms of any business relationship. Show that you can and will bring value to the table, and follow through on promises. Programmers do hard work; we would appreciate and respect a "business guy" walking back in the door with tie crooked, hair tousled and perspiring after a day working their marketing magic.
As for the questions, think about it in terms of any business relationship. Show that you can and will bring value to the table, and follow through on promises. Programmers do hard work; we would appreciate and respect a "business guy" walking back in the door with tie crooked, hair tousled and perspiring after a day working their marketing magic.
WARNING: THIS IS MY PERSONAL OPINION
1. Uninformed.
2. By not consulting on "business decisions" which are actually mostly tech decisions.
3. Make sure you have AS MUCH COMPLETE as you POSSIBLY CAN - things like idea/strategy/wireframes/html mockups/product alpha/prototypes/customers who have intent to use product if it exists/realistic 1st year numbers/plan on who is getting merchant account/incorporating/vesting of stock/who is doing accounting/what is the bare minimum for v0.5 of product.
4. Be honest, open & encouraging. Mostly honest & open though.
5. None
6. Money & Recognition
7. Money & Recognition
1. Uninformed.
2. By not consulting on "business decisions" which are actually mostly tech decisions.
3. Make sure you have AS MUCH COMPLETE as you POSSIBLY CAN - things like idea/strategy/wireframes/html mockups/product alpha/prototypes/customers who have intent to use product if it exists/realistic 1st year numbers/plan on who is getting merchant account/incorporating/vesting of stock/who is doing accounting/what is the bare minimum for v0.5 of product.
4. Be honest, open & encouraging. Mostly honest & open though.
5. None
6. Money & Recognition
7. Money & Recognition
learn to program - a bit of lisp, a bit of C [not to do it but to appreciate the mindset]
Mentioning VB, Microsoft or Clearcase are very uncool and will turn away any talented people you might want to learn from, hang out with, hire or become co-founder with.
Can I suggest not use the words 'cog ... gear' - which suggests you have a worldview [shared with most recruiters] who think beautiful work is something that takes no human passion.
Learn a little bit about aspergers... when approaching someone who is creating, perhaps quietly put a post it note such as "lunch @ 2, sushi ?" just within view while saying nothing.
A useful blog to read might be 'Rands in Repose'
If you've worked to launch an app, you must know all this already? Jump in again, find some smart guys and build another startup. Then write a book on the topic and become famous on the talking circuit... you're probably ahead of the game already.
Mentioning VB, Microsoft or Clearcase are very uncool and will turn away any talented people you might want to learn from, hang out with, hire or become co-founder with.
Can I suggest not use the words 'cog ... gear' - which suggests you have a worldview [shared with most recruiters] who think beautiful work is something that takes no human passion.
Learn a little bit about aspergers... when approaching someone who is creating, perhaps quietly put a post it note such as "lunch @ 2, sushi ?" just within view while saying nothing.
A useful blog to read might be 'Rands in Repose'
If you've worked to launch an app, you must know all this already? Jump in again, find some smart guys and build another startup. Then write a book on the topic and become famous on the talking circuit... you're probably ahead of the game already.
You need to develop the ability sell, advertise, publicize, make deals, etc. In short, all the things a programmer may wish to not do.
I'm the very deepest of technical kinds of guy, but on many co-working projects, I'm still the business guy, as I'm very comfortable with talking to customers, selling and negotiating work.
I'm the very deepest of technical kinds of guy, but on many co-working projects, I'm still the business guy, as I'm very comfortable with talking to customers, selling and negotiating work.
Great questions, Dan. Thanks for bringing them here.
An overwhelming majority of the time spent on a software startup is at the terminal, coding. If you're not doing that, then you damn well better be bringing something else of value, a lot of value, to the table. Things I'd be looking for...
- Specific domain knowledge. You gotta be the guy who says, "No, no, no, that's not the way you do <...> in this industry. You do it this way. And you sell it this way."
- Our customers' industry contacts. You gotta be opening doors for us while we're busy coding.
- Analysis, design, testing, implementation. You should be very proficient at all the stuff on the Systems Development Life Cycle that's not coding.
- Operations. You should good at running the business while we code. This could include many things like accounting, marketing, selling, order processing, help desk, legal, etc.
We programmers are not dummies. We are working on the critical path, but we recognize that a whole lot of other stuff has to happen in order to be successful. And we want to be successful, which is a primary driver. Can you do that other stuff? Great. If not, you need to find some way to add value.
And don't forget, ideas != value. We all have a million of them. What else ya got?
An overwhelming majority of the time spent on a software startup is at the terminal, coding. If you're not doing that, then you damn well better be bringing something else of value, a lot of value, to the table. Things I'd be looking for...
- Specific domain knowledge. You gotta be the guy who says, "No, no, no, that's not the way you do <...> in this industry. You do it this way. And you sell it this way."
- Our customers' industry contacts. You gotta be opening doors for us while we're busy coding.
- Analysis, design, testing, implementation. You should be very proficient at all the stuff on the Systems Development Life Cycle that's not coding.
- Operations. You should good at running the business while we code. This could include many things like accounting, marketing, selling, order processing, help desk, legal, etc.
We programmers are not dummies. We are working on the critical path, but we recognize that a whole lot of other stuff has to happen in order to be successful. And we want to be successful, which is a primary driver. Can you do that other stuff? Great. If not, you need to find some way to add value.
And don't forget, ideas != value. We all have a million of them. What else ya got?
I agree with your points and would like to add this:
> "No, no, no, that's not the way you do ... in this industry. You do it this way."
This would be great especially when the next sentence is "And here is why: ..."
> "No, no, no, that's not the way you do ... in this industry. You do it this way."
This would be great especially when the next sentence is "And here is why: ..."
There isn't always a 'why' that makes sense. A lot of ways in which things are done are determined by their history, not by what one would expect to work best. Moreover, business/selling is not an exact science, so you should not expect the salesman to provide reasons that make rational sense.
So, from the other side of the fence, you need to make sure your engineers understand that.
So, from the other side of the fence, you need to make sure your engineers understand that.
I'm a "business/marketing/sales" type who worked with three others (two programmers) to launch an app two years ago. We didn't make millions (or thousands) but I'd never call it a failure. I think the four of us would all say that we learned a lot about working with others, working on a startup, and our individual habits. I'm eager to apply what I learned to another startup - I've never stopped wanting to create things.
I'm not a programmer, so when I have an idea, corresponding wireframes, and a sales and marketing strategy, I'm missing the most vital component. I work a full-time job. I've considered taking classes to learn a programming language, but pragmatically, I face an uphill battle to master a very difficult skill. Moreover, it might not be the most efficient strategy. Two experts working together are more powerful than one attempting to solve for everything.
I see programmers as the most important cog in this gear. I want to improve my ability to work with software engineers, so I'm asking the HN community to contribute stories about working with what I'll call "business types." Maybe that's pejorative. But startups are often a combination of these two actors uniting to create great things. Here a few prompts: feel free to share anything you'd like.
- How do software engineers perceive business types?
- How do they come to respect or disrespect someone in this role?
- How can I best approach a software engineer with an idea?
- What can a business type do to build trust with a programmer?
- Horror stories or success stories about these two worlds coming together in startup glory or catastrophe
- What motivates programmers? Success? Personal fulfillment? Money?
- What do programmers think motivates business types?
And so on. Thanks for your time. Also, feel free to email me if you're in NYC and want to meet up to grab a beer and talk about these things.
Dan
drc617 at gmail dot com