Behind the Desk
Musings from the minds of Studio Symposium

Hello, I own a software company, and I want to pay more taxes.

Is your sarcasm detector going off? It shouldn’t be.

The recent political climate here in the United States would have some believe that large corporations need to be protected from high tax rates; if they aren’t, then they’ll simply move more jobs oversees.  The idea of tax protection also comes from what’s called the “Trickle Down” effect; basically stating that if a company has more room to move with their taxes, that they’ll apply those savings in hiring more people.  The sad truth of the matter is that this is simply not the case.

I’m a founding member and owner of this company, and have been for over 2 years.  And while, in the grand scope of all things business, we’re still considered a zygote, I’ve learned a few things along the way.  One of which is that if I don’t have to pay taxes, I’ll try my best not to.  At the end of the year, if I can pay an accountant to make things disappear so I owe Uncle Sam a bit less, than I’m going to do that.  And while I won’t be able to get away with paying zero for long, I have a hunch that I’ll try to keep that momentum going as long as I can.

As we grow larger every day, I’m inclined to go against the grain on the corporate tax issue.  Last I had read, approximately 70% of Americans want corporations and wealthy individuals to pay a larger percentage in taxes vs. regular, middle and lower-class families.  The majority of people seem to now agree with the sentiment that if you’re making over $250k a year, you’ll get by if they take a few more percentage points.  Thirty percent would cripple you if you made $30,000 a year.  If you made $250,000, not so much.

If corporate taxes are not mandated and properly supported, then it’s human (corporate) nature to try and get away with whatever you can.  Don’t believe me? Try this one on for size: Due to loopholes in the tax code, along with a few accounting tricks, General Electric paid $0 in federal taxes during 2010. On $14 billion in income.  If you give an inch, they will take a mile.

I’m writing this as a plea to our elected officials; listen to the American people.  Close corporate tax loopholes, and raise the taxes on those who are most able to afford it.  As a business owner, if I can get away with GE levels of scamming the tax code, I realize that something is very, very wrong.

I want to pay my fair share.  Please take my money.

Studio Symposium is a New Jersey-based mobile software company currently looking for dedicated, hard working individuals for iOS Developers.

Overcoming Obstacles in Business

Recently, Studio Symposium has introduced a salt water fish tank into it’s Point Pleasant, NJ office.  Pictures of it will be available online as the progression continues on.  When I first had the idea to introduce a tank in the office, I did it for a myriad of reasons; the psychological benefits of having something proven to reduce stress in the work environment could only prove beneficial to the already-taxed staff.  The tank serves as a common ground for the employees to share while at work aside from the otherwise mundane details of a particular project; something they could learn about, make decisions about, and try different things for.

After about 3 weeks settled into the office, the members of the team at the office took a lunch with me, drove to my house, and uncovered my old fish tank.  We brought it to the office, and spent a while setting it up after I bought BBQ for everyone who helped.  We ended up solving a few problems that we couldn’t have foreseen, and after about an hour or so it was filled with salt water and ready to go.  A day later, I went to the local fish store and stocked the tank with rock from Fiji called “Live Rock”, the benefits of which will become apparent in time.  Next week, we have a few fish that will be going in the tank, then a few corals, and so on.

The tank in the office could be used as a metaphor for owning a business.  You start small, with an idea that a few people can rally behind, and you build it slowly.  As the time passes, you add things, or subtract them, based on whether or not they work well in the environment you’ve created.  If all goes well (and you keep things fresh), it begins to flourish as a result of the hard work you have put into it.  And, finally, if you see it every day, the changes aren’t immediately apparent.  If you take a step back and look at it as a time-lapse, the amount of growth in your effort may surprise you.

Studio Symposium was founded in March, 2009 by myself and Alex Karpodinis, with the goal largely in line with what we have managed to accomplish.  We have an office, an excellent team, and plenty of work coming in.  However, sometimes in business, just as with the fish tank, you need to shuffle things around a bit to make them work more efficiently.  On July 1, 2011, Alex sadly submitted his resignation.  Moving forward without Alex’s input will prove a challenge, but not one that can’t be overcome.  His contributions to the company helped make Studio Symposium what it is today, and I’m truly sad to see him go.  Perhaps if the environment were different, things would be more conducive to his continual contributions to the company.  However, as Studio Symposium grows moving forward, it will have to do so with one less fish in the tank.

Personally, I look forward to the positive things that this challenge represents, and am excited to see what the Studio Symposium ecosystem is able to accommodate moving forward.

Salut

Connecting with your employees

It’s hard for me to say that I’m anyone’s boss.

The atmosphere of the night club was energetic, and the people were packed in like so many sardines in a can.  As I pulled up, I had thought about the implications that I was about to meet my employee and his girlfriend for a few drinks after a long day at work.  At a dance club.  To say that I have to walk the balance of defining “appropriate behavior” is an understatement.

But, as promised, I walk into the night club and immediately find my coworker and his girlfriend hanging out with a few of their friends.  And then, the phrase finally hit:

“This is my boss, Chris.”

I stumble a bit with figuring out how carry myself in this situation, and confirm that yes, I am indeed the boss in this situation.  As the night goes on, jokes are made at my expense as well as that of my employee (threats to fire him if he didn’t buy me a beer happened at least twice), but I eventually overcame the idea that I was someone’s boss for the night, and had a great time meeting some truly great people.  It inspired a confidence level that likely wouldn’t have been reached otherwise through standard operating procedure at the office.

By all standard definitions, I am a boss to a growing number of software engineers and designers alike, but whenever I am introduced to someone by one of my employees, the word “Boss” makes me cringe slightly.  For me, I suppose, it conjures up images of a stuffy office building, wandering around from cubicle to cubicle and standing over people’s shoulders.  Or, perhaps, calling people into my office to make them sit uncomfortably across from me as I ramble on about maximizing ROI, squeezing peak efficiency out of the employees or, god forbid, hosting a motivational speaker.

But what makes a good boss in the first place?  Does my displeasure in the idea of being a boss stem from the idea that a small team is more manageable?  Certainly, things may be a bit different if I had, say, 150 employees to preside over.  Surely I can’t give individual attention to each of them.  My developers have a philosophy that everyone on a project should have an equal voice over it’s production, and as of yet there haven’t been any problems with this approach; in fact I rather prefer it.  Though at times it’s good to remember that there is a difference between the people who started a company vs the people who help run it.

If it comes down to being the strict type and squeezing a little more work per hour out of my employees, or taking a more relaxed approach and having happier employees, I’ll take the road that leads to the bar at the end of the work day.

The importance of Requirements in Software Development

Software Engineers are a lot of things.

They can be night-owls, they’re intelligent, usually well prepared for most situations, and can be the modern-day equivalent of factory workers; working long hours through the day to get something finished by a deadline.  As much respect as I may have for our development team (and trust me, it’s plenty), there are a few things that I know they are not.

Even though any good technology is virtually indistinguishable from magic, they are not magicians.  They are also not mind readers, invincible, or infallible.  They’re human.  Readers of this blog may be inclined to ask “why are you mentioning this?  Everyone knows that software engineers are just human like you or I”.  To that extent, you may actually be surprised to find out that people often seem to forget the simple notion that communication is key.

I’ve been in this business for over 2 years now.  The one thing that consistently comes up as a point of contention between client and vendor is the requirements game.  Sometimes it seems that if we give an inch, people take a mile, and that’s not fair to anyone involved; neither client nor vendor.  At Studio Symposium, we take each project and break it down into very specific chunks, which each serving it’s own very important purpose.

The first phase of software development can, at times, be the most difficult.  Obtaining the requirements from a client in order to produce an application or website that represents their vision as closely as possible.  For example, if someone says “this is pretty much everything” when giving a run-through of an application idea or concept, a word of advice: it’s usually not, and the things that are left out of that “pretty much” can make a very, very big difference, and can make or break the process.  We recently had a project carry on for an unprecedented amount of time simply because the requirements were never nailed down the way they needed to be.  This can be viewed as a mistake from both sides of the deal, but the percentage of time that was spent by my team to discover the requirements (something they had to largely accomplish by reverse-engineering the clients existing software without so much as a PDF of the processes the app follows) amounted to a whopping 75% of the total time put into the project, which had gone, when all was said and done, about 400% over the original scope in terms of hours.

Having a project go over by 400% because of requirements deficiencies is an extreme case, I’ll admit, but it serves a purpose: get everything you can written in paper, drawn out, sketched on a cocktail napkin, signed, approved, sealed and delivered before you even start the user interface construction.  If you can do that, you’re in a much more advantageous position to make everyone happy, including your team.

As an extension of the requirements game, you also have to make sure that any estimate, contract, proposal, or quote that you may write up serves to protect both the vendor and the client in a manner that both can agree on.  Make sure you take the requirements game very, very seriously in proposals, and let the client sign off on the document knowing full well that any extra work not specifically outlined within the proposal will result in an extra fee.  Else it’ll be a case of the goal post being continuously moved, and that’s not fun for anyone.

It can be a zoo out there, just know that your development team can be the ones who are able to navigate it the best.  Consider taking care of them and what they need before anything else.

- Chris