John Gazzini

Direct Business Model


Many software agencies over-manage their mobile application developers, which increases costs and reduces productivity. In many mobile development projects, there is simply not enough management work to justify a full-time manager. I think that individual developers should work directly with clients, partnering with other developers / designers to deliver higher-quality work for a lower price in a shorter time-frame (and make more money doing so).

I’m not trying to make a blanket-statement about the profession of management. I have just noticed, at several mobile app projects at several agencies, that managers eventually become a middle-man between the developers and the client, and that it can become a frustrating game of telephone (especially when the client has a technically competent project manager, which is often the case).

Most of the adult developers I’ve ever met seem more than capable of working with a client to assess their needs (and grasp “the big picture” and all that). I’m just curious as to why more developers don’t do it.

So, for the time being, I’m doing it. We’ll see what happens!


I’m 23. I’m married. I live right outside of DC, in a concrete jungle known as Arlington. My wife and I moved up here immediately after graduating so that she could start her career on Capitol Hill. I’ve worked as a mobile app developer at both small and large agencies, and experienced similar frustrations at each.

During college, I co-founded a software company. When we graduated, the software was good but not great. We had a few solid career options in front of us, and we were both engaged. So, rather than taking the risk and going full-time with our startup, we supported the product on nights/weekends while pursuing stable careers.

Since then, several customers across the country have started depending on our software for their business. It grew to a point where, as part-time co-founders, we could not provide the necessary time/resources to support and grow the product. So, we sold the company. Following the acquisition, I received an offer to continue running customer support, working on the software, and building other apps. This was a fantastic offer, but it was a full-time remote position. I would be working with a tiny team home… or China, or Starbucks, or anywhere. Is that an issue? No. It is not. And here’s why:

It’s 2014

That’s about it. If you want more detailed answers, read this book or this book or this book. Long-distance communication, in a professional sense, is just not a problem these days. So that’s done.

Why is this Position Better?

It’s all about expectations, ownership, and trust. I’m not working for this company, I’m working with them. There’s a huge difference.

At most places I’ve worked, I’ve had to implement specific technical tasks arranged by someone with literally no mobile development experience, and it’s frustrating. It eliminates the creative satisfaction of problem-solving.

I like solving these problems: “We want a more efficient checkout process for our employees.”

Not obeying this instruction: “Implement a NSURLSession subclass that calls this URL and passes the data to another singleton.”

The “advantage” of the second situation is that I am not held accountable, financially or otherwise, if a project fails. As long as I do exactly as I’m told, then my bonus structure is not affected, and I’m not held responsible for failure or success. But, that disconnect is maddening to me. It becomes difficult to take pride in my creative work when I’m not interacting with the users or held responsible for the overall result. There’s lots of employees who really do love that level of simplicity / stability, but I am just not one of them (At least, not yet).

Also, I find it impossibly boring to implement technical tasks for 40 hrs / week… I just can’t do it.

How I Really Feel

warning: Here comes a rant.

The consensus among many people is that developers need a manager to tell them what to build. I think that’s stupid. But it’s not just managers and ignorant people who feel this way; I’ve met other developers who say things like “That’s awesome that your startup was successful. Who set the requirements for you?” I always freak out when other developers ask me this question, because it implies that they aren’t used to doing anything unless they are explicitly told to do so. However, there’s an important distinction to make here: big projects and little projects.

Big projects, like operating systems and smartphones, obviously require a large coordination effort among individual contributors, and that justifies formal management positions. No argument there.

Small projects, like most mobile apps, solve very specific problems and do so by integrating existing technologies in a new way. So, if I want to make an audio-recording app that allows people to share / organize recordings differently, I don’t have to worry about taking audio data from a microphone and storing it in memory; I just call a function written by Apple or Google engineers to do it for me. For small projects, I have difficulty justifying several, if any, layers of management between the user and the person actually typing the code.

In this sense, all of the “small” projects depend on technologies that were implemented by people in “big” projects, which means that, at some point, a manager is necessary. However, my argument is that managers are unnecessary within the scope of small projects.

Everything is Relative

There’s a way to spin this whole argument against me: perhaps I’m just a “middle-man,” and the only value I add is in taking the products of several different engineering teams and combining them in a certain way that makes them more useful to different people. In that sense, I am just a “manager” on a different scale… whatever.

Back to the Point

A decade ago, the available frameworks and software development tools required developers to think at a very low-level and pay attention to lots of detail when making useful software. It was also more popular to make one piece of software that solved lots of problems at once. Therefore, every software project was a “big” undertaking.

However, the mobile revolution has developed a demand for software applications that solve one specific problem (“apps”). Developers also have access to much better software tools, so that the overhead required to create software is significantly lower than it was in the past.

Why Does This Matter?

I think many software development agencies have underestimated this change, and as a result, they over-manage mobile application developers, which reduces productivity and morale. I think they should hire developers who understand real problems and write code. Then, they should allow them work directly with clients. Many mobile agencies are currently operating with just a single manager between their clients and their developers, but the “quantum leap” here is to eliminate that manager completely. However, this eliminates much of the need for the agency itself, so that could cause a problem.

Many agencies bill out developer time at over triple what they actually pay the developers. This is silly when you consider that many of these agencies operate with so few managers. I stipulate that the management is unnecessary, and that individual developers should partner with other developers / designers to deliver higher-quality work for a lower price in a shorter time-frame, and make more money doing so. Lots of product companies already operate this way, such as this one and hundreds more. However, I’m not familiar with many agencies that utilize this model. It obviously doesn’t scale, but why not just stay small? I guess that’s just “bad business,” unless you’re 37Signals (or Basecamp or whatever). However, Basecamp is now a product company, so maybe they don’t count either.

I don’t have all the answers, but it’s a problem-space that I’m constantly exploring.

My Next Steps

I want to stay in the DC area and make useful apps with great people, so that’s what I’m doing. No need to overthink it for the time being.

← Previous


Next →

blog comments powered by Disqus


13 February 2014




About Me