I love making software; I’m a techie geek. I’ve also always been interested in running and owning a business — an aspiring businessman. Right now, though, I’m employed. And I’ve learned there is always an infuriating tension between the technical people and the business people — infuriating to everyone on both sides of the divide.
If you’ve ever worked for a company that didn’t consist of only one of the two mindsets — technical or business — all throughout, from worker bee to head honcho, then you know exactly what I’m talking about. Like-minded people gather at happy hours or private meetings spewing all their complaints and frustrations caused by the other side. The business insists we keep adding new features without refactoring. Arrrgh! … or … Software dev just won’t hire enough people. Why?! Others nod their heads in agreement. It’s eventually followed by a few seconds of silence before someone finally says, “well, enough venting…” Everyone pushes on, now with slightly more frustration, slightly more dissatisfaction, and slightly more apathy than before.
This is just the start. These kinds of disagreements go on for years without ever getting resolved. They inevitably increase the amount of politics that come into play when decisions get made, which is detrimental to the organization as a whole. What starts out as a decision about whether or not to start a new project becomes a power struggle between egos. Not to mention the underlying dissatisfaction and eventual misery of the people working there who feel powerless to change anything for the better.
The divide is so bad that two people on either side can’t see eye-to-eye on anything. They even refer to the other group as a separate entity — “the business” or “the board” or “software dev” — as opposed to “Brett and Diane”, the actual team members. Not only is this dehumanizing, promoting the us-against-them mentality, but it doesn’t hold the actual people responsible accountable for their actions. It’s the fault of “the people upstairs” or “the dark side of the building”. Instead of working towards fixing the problem, it blames entire departments, and most of them are just along for the ride when a manager makes a bad decision.
Even though both technical and business people alike are (usually) striving for the same goal, they are divided on their belief of method that will achieve that goal. And this, over anything else, is the reason the divide exists.
This deep-rooted difference in belief is how to achieve passive income.
The Passive Income Mecca
Active income is income based on a per hour or per year rate. Anyone employed to work at an hourly wage or on salary is making active income. Once that person stops working, he or she stops getting paid. Period. In geek terms, I = wh, where I is income, w is income per hour, and h is the number of hours worked. When h is 0, so is income.
Passive income, on the other hand, is income that does not depend on the amount of time you work. A writer like Stephen King can write a book once (a fixed cost), sell it, and collect royalties for each copy sold. The more copies sold, the more income he gets (variable income). Although the amount of income might depend on how good the book is, it does not depend on how much time Stephen King spent writing the book — how much time he actually spent working, h. That’s passive income.
In the world of money-making, everyone is striving for sustainable passive income. If you suddenly become ill or get into an accident that makes you unable to work, and your only income is active, you’re screwed. How will you pay for dinner? How will you buy those 2-hundred-dollar designer-jeans for your teenager? Not to mention the health-care bills accumulating as a result.
The solution: passive income. With passive income, it doesn’t matter if you’re lying in bed, surfing in Hawaii, site-seeing in Europe, or getting a lap-dance in Tokyo. The money keeps rolling in, thanks to the hard work of tens, hundreds, or even thousands of others dependent on active income. (Those suckers!)
Now, the divide between technical-minded and business-minded people is in what they believe is the best way to obtain passive income.
For technical people, they know computers. They know software. Given the right resources, they can make a computer do anything — anywhere, anytime. Their deep-rooted belief is that passive income can be achieved by writing software once (a fixed cost) and distributing it to millions who each pay a fee (variable income).
For business people, they know cashflow. They know the symbiotic relationship between employees and business owners. And in this day and age, there will always be people looking for jobs. Given the right resources, they can employ people to do anything — anywhere, anytime. Their deep-rooted belief is that passive income can be achieved by creating a repeatable business process once (a fixed cost) and teaching it to thousands who each execute the process (bringing in variable income).
What technical-minded and business-minded people are doing is essentially the same. What differs is their belief in what scales.
The differing belief is due to their experiences. Technical people believe they can make computers do anything because there has never been a time when this wasn’t the case for them. Every computer mindlessly executes instructions, so if you can obtain a computer and specify those instructions, it will do whatever you want. If it was a problem with software outside of a technical person’s control, there was always the possibility of re-writing the software in-house, so those situations don’t count.
Business people, on the other hand, believe they can make people do anything because there has never been a time when this wasn’t the case for them. People need money. So if you pay them, the market dictates a fair trade, and they will do whatever you want. If there was ever a problem with an employee not being able to do a job, there was always the possibility of replacing that employee with another more skilled, more teachable person, so those situations don’t count.
Each group grew up with its own viewpoint and believes its method is superior. So neither group bothers to learn the other side’s perspective. The dispute rages on.
Likewise, due to differing experiences, each group believes the other group is mistaken.
In the technical sphere, the amount of overhead (variable cost) of hiring a person — not to mention laying off or firing — is seen as huge compared to the overhead of distributing another copy of software or adding another server. And this alone is reason enough.
But on top of that, 80% of all problems are human error. Someone typed in the wrong command, someone clicked the wrong button, or someone loaded the wrong file. The software was not to blame; a person told the computer to do the wrong thing. And so, technical people — as a direct result of their vast amount of experiences — believe that people do not scale. It doesn’t matter how detailed your process is — someone, at some time, is going to forget a step. They’re going to forget to make a backup copy. They’re going to forget to update 1 of the 13 places to change the current date. They’re human; it’s expected. Computers, on the other hand, if there’s one thing they’re good at, it’s being consistent. Developers can test and debug software ahead of time to make sure it follows the process before going live in a production environment. It doesn’t matter how long a person has been doing something, though. To not expect a person to make mistakes is naive. So people do not scale.
However, in the business realm, not only is development of technology extremely costly, it is extremely costly to maintain. Although the technology may improve productivity in certain use cases, there are inevitably “edge cases” that the technology doesn’t handle. I use quotes because the edge cases actually happen all the time when you’re doing it as often as a big business does (kind of like those race-conditions in multi-threaded software). So you need people to know the business process anyway to handle the cases that the software doesn’t handle. By introducing technology, you’re increasing the number of things a person has to learn before he or she can be productive, thus increasing costs.1
Business people — as a direct result of their vast amount of experiences — believe that software does not scale. Technology systems inevitably become so complex trying to handle all the edge cases that fewer and fewer people are able to effectively maintain them, and that maintenance gets slower and slower as time goes on, experts leave the company, etc., etc. So any software written in-house is a liability. It’s on the business to shell out resources regularly just to stay afloat. On top of all that, there’s no such thing as bug-free software. To expect to write software once and forget about it is naive. So software does not scale.
Employees are effectively a business’s server farm.
A job is shipped out to the server farm, the job owner queries the farm for status from time to time, and the results get shipped back to the job owner. The farm is compensated for the amount of CPU time the job took (via wages), but any and all profits resulting from the computation (the fruit of the actual labor) are owned by the job owner.
That’s right. Business people treat employees the same way technical people treat hardware. The process is written in English or German or Chinese instead of C or Java or Lisp so that the number of people who can interpret/execute the process is maximized. This is also the reason why big businesses will always prefer languages designed for the masses like Java over languages designed for smart people like Lisp. Java coders are more interchangeable and come significantly closer to the theoretical limit of a code-monkey — basically a slave that outputs working software.
Ironically, each group wishes for more of what the other wishes they had less of in terms of smart people who think outside the box versus those who put their head down and follow a process as they are told.
In the technology sphere and with software especially, it’s completely up to your imagination — practically anything that can be coded goes. Non-technical people tend to have a huge misconception that programming is purely methodical and mechanical. This couldn’t be further from the truth. Programming takes a huge amount of creativity, arguably more creativity than what people normally think of when they think of art. Ask any programmer with a passion for the field and he or she will tell you that programming is an art. As a result, the best of the best — giants like Google and Microsoft — are notorious for hiring based on puzzles and brainteasers. People who don’t think outside the box, don’t come up with creative solutions, don’t think abstractly — not only do they make sub-par programmers, but they pull the rest of the team down drastically.
It’s like if the Pittsburgh Steelers have an amazing defense, but they pickup a lousy cornerback. Not only will this position suffer due to his lower skill, but the rest of the team will perform worse because they will constantly have to worry about covering what the cornerback can’t and chasing down the offense that breaks through the cornerback’s defense. The rest of the team tires more quickly, and their attention is spread thin over a larger area, all to make up for the below-average draft. In software, it’s the same. Lower skilled developers introduce bugs that have to be fixed by higher-skilled team members. Time is now spent fixing bugs that could have been spent making new bells and whistles. But it’s actually much much worse than that.
Even poorly-written code that does not have bugs, per sé, can hurt the team in the long-run. Highly skilled developers make development look easy because of foresight. They know what problems will eventually arise, and so, they write code that is easier to extend, easier to change, easier to test, and easier to fix. On the other hand, less skilled developers don’t have the foresight to do such things, and their code becomes a detriment to the entire team, invisibly incurring technical debt. It won’t show, perhaps, until years down the road after they have long quit the company, as other developers must spend valuable time learning and adapting the code. And this is why technical people would rather not hire anyone than hire someone below their standard — in direct opposition to the business-minded idea of scaling.
In the business realm, they see things differently. Although you may need extremely bright people to do R&D, only the richest companies have enough capital to spend on R&D. Your typical company has little need for brilliant (and expensive) people. On top of this, people who are hired to execute the business process are, more times than not, better for the organization when they don’t think too far outside the box. If they do, they end up by-passing the well-thought-out process which has been proven over the years to work (like code that’s been tested), and instead, fly by the seat of their pants, taking unnecessary risk. If the process doesn’t handle something, it should be brought to the attention of upper-management who can modify the process to fit the business needs. Bringing these issues to the attention of management should also be part of the process, so nothing ever strays outside the process.
If one brilliant employee is doing something outside the process, then when he or she gets hit by a bus (or more likely, leaves the company for a startup), the company will fall apart because no one else knows what the brilliant employee was doing, let alone how he or she was doing it. Single points of failure are an absolute no-no when it comes to scaling. And let’s face it, creativity is hard. Not everyone can be creative. An organization is much more likely to survive having a simple, repeatable process that can be taught to anyone, not just your Sergey Brins. If something happens to any one person, the organization as a whole can move on, the same way a biological organism losing a few skin-cells scraping its knee on the sidewalk can just get right up again.
It’s like if one server started ignoring the code a programmer wrote because it discovered a “better” way of doing things. If that way were proven to be correct, like compiler optimizations, fine. But as far as we’re concerned, it hasn’t been proven at all and it can’t be copied to other servers, so we’re better off without the dependency.
So yes, there is actually a reason for those TPS reports, and I wonder what Office Space would look like if it were told from the business people’s perspective.
Basically what this comes down to is that all technical people are creating new processes all the time, usually in the form of software, so those people have to be smart and creative. When technical people gather requirements, what they’re doing is market research, aka marketing. They then architect a process that computers will eventually execute.
On the other hand, only business people in upper-management ever create processes, and they have an entire department to do marketing for them. Those at the “bottom” of the hierarchy are only supposed to execute processes like a machine.
Put another way, software developers in the technical world are doing the same thing that upper-management is in the business world. The only difference is what executes the processes they create — either computers or people. Middle-managers, on the other hand, are only hired to execute processes, and yet, they’re telling software developers who create processes what to do.
It’s as if technical people and business people are at the top of two completely different hierarchies that get connected by middle-managers, allowing each group to abstract away part of a complete sustainable organization. But instead of the two hierarchies being equal peers, the technical hierarchy gets pushed to the bottom because of its lack of understanding of (social) networking and cashflow. They get lumped in with the crops, when they’re really running their own farm.
So when it comes to scaling, which group is really right?
Actually, both groups are right. And at the same time, both groups are wrong.
Both perspectives have really good points that the other group simply doesn’t get, even after recurring time and time again in the industry. At the same time, both groups have huge misconceptions about how fool-proof their method to passive income is.
Technology like software can be extremely costly to maintain. Thus, making technology easy to maintain — i.e. making variable costs as close to zero as possible — is one of the most important jobs of developers creating it. People will always be needed to maintain it. On the flip side, business people need to place more emphasis on hiring and keeping highly-skilled technical people who reduce variable costs, as they are essentially as vital as upper-management. Servers are simply different kinds of employees that don’t ask for benefits.
In the end, I think this is yet another example of one of the re-occurring themes of the Universe: neither one extreme nor its polar opposite is the answer. Instead, the best solution is some kind of hybrid that takes advantage of strengths of both sides.
Just look at the greats. Bill Gates started out on the technical side — like me, an interpreter-writer — but eventually leveraged the business side to build one of the most successful software companies in the world, not to mention one of the richest. Those who can master both sides will rise above the rest.
As for easing the tension between technical and business types… If I had one piece of advice for technical people to work better with business people, I would say, talk to business people in terms they can relate to. They don’t care about how the NullPointerException is triggering deadlocks in parallel at runtime between cache-misses. They care about resources spent or saved, features being shipped, and how fast they can be shipped. At a company whose output isn’t technology, when it comes down to it, you are just a service-provider to them. Instead of thinking of your software as the end product, think of the end product as your service of writing the software.
When you order pizza from Papa John’s and ask them how long it’s going to take, you don’t care about problems they have cooking pizzas in parallel because one oven is broken. You want to know when your pizza will be ready because you’re hungry god damn it! And when it comes to software, it’s no different. If you’re striving to create the best pizza man has ever seen, either keep it to yourself or work at a place that shares your dream.2
If I had one piece of advice for business people to work better with technical people, I would say, ask technical people to explain things in terms you can relate to. They think that once the NullPointerException triggering the deadlocks in parallel at runtime between cache-misses is fixed, everything will be fine. To them, what that mouthful is is obvious, and they can’t imagine it not being obvious. They also think that once all the details are specified, the big picture is immediately clear, and you can’t blame them considering that’s how computers work. They simply don’t know what you don’t know.
Swallow your pride and ask them to explain things in terms you actually care about, and the sensible technical people gladly will. It’s not really a matter of having them come “down” to your level as “up” to the big picture.
Last but not least, learn about technical debt and accept the fact that revisiting working technology is necessary to paying it off. Building software is different than building a car, and it requires different approaches. Technical people only respect merit and ability. If you’re not interested in learning what they do, at least learn how to recognize value when you see it and not fight against them in trying to approach it.
Not everyone is cut out to run a business. It’s a lot of work, and not everyone wants to do that. The majority of people are the worker-bee type who enjoy having a stable income with a regular 9 to 5 schedule to get up and go to the office. From the business perspective, business owners are doing these people a huge favor by providing this environment for them. In return, employees are effectively the business’s server farm.
As I described before, businesses treat people as hardware. They ship employees a job, the employees do the job, and the results get shipped back. Java coders, as opposed to Lisp coders, are more desirable because they are more expendable and come significantly closer to the theoretical limit of a code-monkey — a slave that outputs software. All profit and assets like intellectual property, regardless of who did the work, by law, are owned by the business owner. The employees themselves sign all the necessary papers when they take the job.
This begs the question: is employment slavery?
I think the answer is not so clear. It’s like asking, is it wrong to take something from someone if that person wants to give it to you? Usually we call that a gift. Employees seek out jobs and complain when there are few available; so they must want to be employed, right? Additionally, employees always have the option to quit; they’re not being held captive in any way, and they’re never physically forced to do anything.
But somehow, this doesn’t seem right. If you ask an employee why he gets up so early to commute to work during rush hour, he probably won’t say that he does it because he likes it. He will probably say: because he has to. It is hardly a “gift” to spend all day, every day, working hard, spending time away from family and friends just so that a business owner, who he probably never even met, can get rich. It’s more like exploitation with no hope of ever breaking free. 9 to 5 till 65, as they say.
And as for not being held captive, most employees will tell you how they’ve felt trapped at one point in their career or another. Others will tell you how they’ve feared losing their job. A few describe work life as torture, being confined to a cube where if they fall asleep, they lose their job and thus their home. Even though they’re not being physically forced into labor, it’s effectively the same through indirect blackmail. For most, they depend on the income from their job so much that their employer might as well be their master and they the slave.
It’s obvious to fresh graduates joining the workforce for the first time. But as years go by and responsibilities like supporting a family and paying a mortgage build up, increasing their dependence on their employer, any aspirations of freedom are slowly forgotten.
In a society where 90% of all people are employees who inherit debt from their kin, not assets, the entire concept of financial freedom is alien. All this — in the land of the free.
I’m honestly not blaming business owners for attempting to be slave drivers. In societies where slavery is acceptable — this one — it’s much more desirable to be a master than a slave. We are all at fault for allowing it at all. Employment being comparable to slavery is a much larger issue with society not educating the poor- and middle-classes about cashflow, which, by the way, will eventually lead to a greater and greater divide between the haves and have-nots, until the pressure builds up enough for revolution. You mean history repeat itself? Nah, that couldn’t happen…
Regardless of whether that happens, though, I believe exploitation is wrong. Each worker should own a piece of the fruit of his or her labor and profit from it. Arguably, having small companies like startups where every worker is a partial owner is the only right way of doing things. But this doesn’t seem to scale.
If only there were a way to accurately measure the value a worker was really contributing… Is there a way? What is it?
Investors reading this, looking for a bargain? I’m interested in funding. firstname.lastname@example.org