Management problem for a small ISV

I own a small software company. We are a 3 people company, myself included.

I don't have management experience, but I have lots of programming experience.

I usually let the programmers write modules for our product, and then I test the modules, and integrate them. I also test the product and do bug-fixing.

The problem is, these tasks are now a lot more than I can handle. I have to do a lot of work - a lot more than I can do, actually. :-(

I am extremely overworked and depressed.

I could give the whole source to one of the programmers to fix bugs, but I am afraid of him stealing my source code and creating a competing product.

I know of at least 2 cases where this happened.

Our company is virtual, so I don't have my 2 developers in a hall, and I can't see how they really spend their time.

I guess this is why virtual companies never took off - you can't really supervise the employees.

There is also another large problem - my programmers can't design very good user interfaces. They just design average user interfaces, and for our product, this is not enough.

So I have to make all decisions regarding user interface changes because I understand user psychology and user interfaces.

This is one more reason why I can't have them work on fixing bugs - some of the bugs are related to the user interface, and I can't let the programmers make any decision regarding the UI - what dialogs to show, etc.

So, let's say that I employ another super-developer who knows how to design excellent user interfaces, and I let him have the source and write the programs.

In this case, what will stop him from stealing the source, modifiying all the UI text and colors, and creating a competitor of my program?

I'm very overworked. :-( Wish there was a way out of this, a solution.

Entrepreneur
Friday, January 30, 2004

It's called a Non-compete agreement and Copyright.  That's all you need.  If you have 2 employees, I'm guessing you can afford to have a lawyer handle any potential cases of theft/copyright infringement/etc.

GiorgioG
Friday, January 30, 2004

Blank, I tried very hard to have them do GUI design very well. They simply can't. :-(

Entrepreneur
Friday, January 30, 2004

If your current employees can't do UI, hire some who can.  If you really want to have your hands in it (and it sounds like do) then hire someone to handle the business.

Either way, you're going to have to give up some kind of control to someone else.

As for stealing code, a non-compete AND a strong employment contract should keep that from happening.

Almost Anonymous
Friday, January 30, 2004

Well, if they can't do good UI, then teach them how to. Or find other people who can.

A concept you might chew on:

Delegating - v. 1 (often foll. by to) a commit (power etc.) to an agent or deputy. b entrust (a task) to another. 2 send or authorize (a person) as a representative. [Latin: related to *legate]

My interpretation: Find good people(hardest part), train them well (not so hard after the first part), give them with some work, leave it to them and trust them to do it properly.

This isn't an overnite process, so don't expect instant results. Work on it, and in the long run it will *definitely* pay off.

T-90
Friday, January 30, 2004

http://www.entrepreneur.com/article/0,4621,288573,00.html

http://ollie.dcccd.edu/mgmt1374/book_contents/3organizing/deleg/delegate.htm

T-90
Friday, January 30, 2004

What GiorgioG wrote. Also, you might want to think about doing something like embedding your company's name somewhere within your source code where it would be difficult to detect.

One Programmer's Opinion
Friday, January 30, 2004

" I tried very hard to have them do GUI design very well. They simply can't"

Very often a GUI that's considered bad by one person is good to someone else. There's also the possibility that you had a design in mind but you didn't tell them what you wanted, then you got mad because they didn't read your mind.

OTOH, if they made a good faith effort to do what you asked and in the opinion of several people (not just you ), they failed, then you need to give that work to someone else (I suspect that's the case, since most inexperienced codes tend to write terrible user interfaces).

Tom H
Friday, January 30, 2004

This kind of problem is pretty common, and the issue goes beyond delegating or finding super programmers.

When you write that the programmers cannot design user interfaces, I assume you mean that you understand how you want to approach the marketing and sales of the product. You are communicating your vision by constructing the user interface, and having the programmers construct the internals. That can work well, especially if the programmers like focusing on technical issues rather than dealing with customer issues.

I see the same approach in a lot of businesses. For example, small general contractors for residential construction seem to usually be structured with one person, the owner of the company, who meets with customers and organizes projects. A crew of people do the work, in combination with subcontractors. For example, the general contractor's crew might do the framing, while contracting out electrical, plumbing, and foundation.

The arrangement can easily break down, and I think you may be running into this.

One problem you mention is technical people (the workers) going out and competing with you. This is easier solved in software than building, because you can be careful about copyright and non-compete.

A more common problem I've seen runs the other way: the technical people don't want to have anything to do with customers, and this throws more project management burden on the person in the center. What do you do if the customer has agreed to pay for a certain number of hours of work to tile a deck, and the worker surprises you by spending three times that amount of time, saying that he is an artist, and it has to be done right? This sort of thing really happens. The customer refuses to pay, saying that if he had known it would be three times the price, he would not have chosen tile.

Another problem is that the person in the center gets interrupted a lot, and can't get technical work done. I'm facing that right now with a brilliant builder who hired in-laws as his job site supervisors. The builder has a wonderful family, but they can't keep the subcontractors in line, so nothing gets done unless the builder himself is involved.

Finally, there is the problem that in a company doing substantial amounts of business, engineering is a tiny portion of the overall effort. It doesn't work to have the public face of the company doing substantial technical work. Marketing and sales take more time.

Some suggestions would be:

- If you are selling a lot of product, cut back on the engineering. A lot of technically-oriented companies start out as vehicles to sell the products built by the founders. However, there is no long-term need to have the company oriented around engineering. I've seen successful companies driven into the ground by the founders doing engineering instead of marketing and sales.

- Find another way to communicate your vision. For example, you could write specifications or do sketches. If you have programmers who don't do good work from these kinds of documents, you need to find programmers who focus on creating a product, rather than writing code.

- Find ways to buy more of the components of your product, so the engineering effort can be more focused. Most of our customers buy our products specifically for that purpose. Of course, whether or not that is possible depends on your product.

- Find a distribution channel that requires less of your time. I wish I had good advice about how to do this. I've seen other people do this, and I'm jealous. I'm finding that I need to spend more time on the distribution channel, even though we have wonderful customers and great distribution arrangements.

Dan Brown
Friday, January 30, 2004

Copyright, NDAs and non-compete agreements (although make sure these don't unreasonably restrict your employees) are all excellent tools that would help protect you in case one of your employees did "swipe your code" and use it to write a competing product.  They're the stick.

But try using the carrot too:  make sure your employees are doing well enough (in terms of both finance *and* morale) by working with you that it's just not worth it to them to defect.  Everyone will have different thresholds for what's worth it, but at the very least you can pay them as well as you can and treat them like you actually respect them (though this may be hard for you, since it could be argued that you don't).

And get over yourself:  they don't actually need your source code.  Anything can be reverse-engineered with enough time, and the more time anyone spends learning how your program works while they're *on* your dime reduces the time they'd need to rewrite their own app from scratch... which you couldn't do anything about anyway.

Sam Livingston-Gray
Friday, January 30, 2004

If you can't trust them not to 'steal' the code why do you trust them to write the code?

Also, its always irrelevant that someone stole code, created a rival product and 'stole' the customers.  What is relevant is that in all such cases (I'd bet on without exception), that the original company just wasn't delivering what people wanted, or was too expensive, not sufficiently responsive or in some other way failed in its marketing.

So, if you're confident in your product confident in your market, confident in your ability to innovate don't worry about people stealing the code.

A final thought, if the other two developers are key to your endeavours and to the success of the product why not make them partners?

Simon Lucy
Friday, January 30, 2004

"A final thought, if the other two developers are key to your endeavours and to the success of the product why not make them partners? "

Because I'm the BOSS, and there is no way I'm letting some 2nd rate coders think they are on the same level as me. Jeez.

Entrepreneur
Friday, January 30, 2004

Actually, I've never really understood the 'don't trust your programmers' philosophy. People resent being mistrusted, and if you'll give a minimum wage sales clerk the keys to your store for opening and closing, then you shouldn't have a problem with me seeing your source code.

If you're doing things right, there's a lot more involved in becoming a competitor than just taking some source code home.

Ron Porter
Friday, January 30, 2004

>> "Because I'm the BOSS, and there is no way I'm letting some 2nd rate coders think they are on the same level as me. Jeez."

You sir are a fucking jerk.

Friday, January 30, 2004

Sounds like you need to bring in a UI designer and a QA person.

You could fairly easily get them on contract for a short term engagement.

Chris Tavares
Friday, January 30, 2004

"Because I'm the BOSS, and there is no way I'm letting some 2nd rate coders think they are on the same level as me. Jeez."

Wow,  you sound like a boss I had once.  Needless to say he's bankrupt and unemployed now.

You may want to look at pulling your head from your ass.

Koz
Friday, January 30, 2004

>> no way I'm letting some 2nd rate coders think

Maybe that's why you're not getting work done?

Why economize on 2nd rate coders? You should have gone for 1st rate. And they would know GUI too.

Alex.ro
Friday, January 30, 2004

I would say this is a very clever troll but ....

The Artist Formerly Known as Prince
Friday, January 30, 2004

To date you've hired low grade people who essentially work as your assistants, under instruction.

To expand, you need a new class of staffer who you can trust as a partner and delegate responsibility to.

I think your answer is that you need to go out and try to attract someone more with more rounded development skills, and then make the offer attractive to them. If you're growing, then give them a part of it.

By the way, you are dead right about the risk of source code being purloined. It's a bigger risk for a small company because it's harder to discover until too late. It can happen in many ways. For example, a staffer might take the code to his next job, possibly without even realising the significance, and a consulting firm working at the new site might steal it. No-one even knows there's been a theft.

me
Friday, January 30, 2004

your right about good programmers stealing your code.  If you want to keep it secure, you should fire your current guys, outsource to the cheapest indian programmers you can find, and you shouldn't have any problems.

Friday, January 30, 2004

I think the answer actually is that Entrepreneur needs to hire  a manager.  If he allows that manager to manage him and his time then he will succeed if not its a slow burn to failure.

Simon Lucy
Saturday, January 31, 2004

You think you're depressed?

There's 2 guys who're working for someone who doesn't trust them and who thinks they're second rate programmers, with obvious contempt for their abilities.


"So I have to make all decisions regarding user interface changes because I understand user psychology and user interfaces"

Really? If you're so smart, how come you're overworked, depressed, and treating your staff like crap?


"I'm very overworked. :-( Wish there was a way out of this, a solution."

Oh, there is a solution, but it requires acknowledging that "paranoia" is not generally considered a critical trait of successful business owners.

Saturday, January 31, 2004

"If you're doing things right, there's a lot more involved in becoming a competitor than just taking some source code home."

On second thoughts, maybe he actually should be paranoid about having his source code stolen.

Assuming that his coding skills are significantly better than his management skills, of course.  :)

Saturday, January 31, 2004

I respect the developers who work for me.

They do wonderful tech stuff. I mean, if I ask them to code an algorithm, I get excellent code for the algorithm.

The programs are well designed (from a software design point of view), they work well, don't crash, run fast, etc.

They have solved very difficult problems.

But, somehow, they don't understand GUIs. :-(

They are excellent at program internals, and very bad at GUI design.

:-(

Entrepreneur
Saturday, January 31, 2004

"I respect the developers who work for me"

"Because I'm the BOSS, and there is no way I'm letting some 2nd rate coders think they are on the same level as me. Jeez"

Clearly these statements are either from two separate people, one of whom is trying to make the other look insane, or they're from one person with a really strange idea of what the word 'respect' means.

As the original poster has made it quite clear that he considers these employees of his to be untrustworthy and a serious threat to his business (despite the fact that he also made it as difficult as possible to supervise them as he could), I really can't see how he can also claim to respect them.

No, seriously, how can you describe someone as "a skilled and talented developer and untrustworthy serious threat to my business who I respect" ? That just doesn't make sense to me.

Hell, "I insist on doing work myself and not allowing my untrustworthy enemies/employees near my amazing code and I wish there was some way I could stop being so overworked without letting anyone else do the work" doesn't sound like something that a competent business manager would say, either.

How's your hairstyle? Keeping the points nice and sharp? Remember, if people don't lose an eye when looking over your shoulder you need sharper hair.

Saturday, January 31, 2004

>  If you want to keep (your code) secure, you should ... outsource to the cheapest indian programmers you can find

It's the Indian guys who'll nick your source code. No hangups about intellectual property in the sub-continent.

me
Monday, February 2, 2004

  Recent Topics

  Fog Creek Home