Throughout the years that I’ve been doing freelance development for startups, I’ve had the opportunity to work in various different roles and experience developing startups from different perspectives. Keep in mind that the different areas of a startup (business, dev management, development) require different skills and experience that not everyone is suited for, so these situations could be limited depending on your personal strengths and skill-sets.
- Sole founder you’re in charge of everything from the business to the development
- Developing Manager if you have stake in the startup, you’ll be called the Technical Co-founder. If you don’t have stake, you could very well be everyone’s hero.
- Part manager, part developer you are the contact between the business and the development, but you also have your share of the development tasks.
- Just a developer you are responsible for developing the tasks that are given to you.
Let’s go through these different situations and discuss the pros and cons of each of them.
The first situation is something that is not too common, because one person has to come up with a business idea, manage the project, and perform the development. I have the luxury of being fairly versed in these 3 areas, however I’ve found some areas are stronger than others. This is something that I have done a handful of times to varying degrees of effort, but through time I’ve learned that it’s difficult to have success with these projects for me personally. When it comes to marketing and growth, I really don’t have much interest.
That’s not to say that these projects have been a complete failure, they have turned out to be valuable learning experiences and portfolio builders. I think any freelancer who is starting out should first work on a portfolio, but the problem in the beginning is getting clients. So what to do if you can’t land clients yet? Make the projects yourself, that’s what I did.
I still do some projects like this, but usually my goal is to learn a new framework or technology and very rarely I plan to have actual growth with the project.
This setup could arguable be called “Managing Developer” as well, depending on how you look at it. This is when the business idea is separated out from the developer, but there’s one person handling the entirety of development. For small-scale startup projects this has been the best option from my experience, however it’s not always the right choice.
With this structure, you have complete control of all the development side to satisfy the business needs. I’d say the most advantageous part of this is that the communication chain is very short. It gives you direct contact with the person who has the ideas for which you’re developing, which considerably increases productivity.
There is a fairly large caveat with this structure - if the person is a good developer but a bad manager, there will be issues as the project progresses. I find it interesting the amount of times a developer is acting the role of a manager, but how many times does a manager act the role of the developer? I suppose this is because of different skill-sets that are required for a developer, which often times the manager won’t have. However, a solo developer can usually get by pretending to be a manager.
Another drawback that can arise in this situation, and the reason why as the project grows the team needs to as well, is that there are many different areas the developer needs to be comfortable with such as backend, frontend, mobile, devops. Those might just be four words, but as you might know, there are many different facets of each of these areas which require a lot of knowledge and experience.
As the needs for the project grows, the developer might be able to learn things on the fly, however the productivity will take a large hit. I remember my first project I put onto Amazon Web Services (AWS) - I absolutely hated that part. Seemingly simple tasks would take me 40 hours, which on Heroku I would do in about 2 hours. Now as my AWS experience has blossomed, all those tasks that I got stuck on before now have become simple tasks.
Part developer, part manager
Under this structure, one person will be managing the development side of things, but also developing a portion of the project. Usually the project would be divided into sections such as backend, frontend, and mobile. This tends to spawn off of the Developing Manager structure as the bandwidth has grown to be too much for one person to handle.
This is the phase where the project starts to get interesting because it really highlights your ability to manage a project and less about your ability to develop a project. If you have project managerial flaws, they will really come out to shine. But it’s a great learning opportunity, right?
Having this structure can also improve productivity because developers are able to focus on their areas of specialty or interest. In the “Developing Manager” section I talked about simple tasks on AWS taking me 40 hours the first time doing them - this might have not happened if I weren’t in charge of DevOps. However… if you’re a developer who takes pride on having broad knowledge, you’d need to learn that at some point.
Just a developer
These projects have been arguably the most enjoyable for me. I get to work in my area of specialty (API development or frontend development) and I don’t have to worry about anything except building beautiful code. As a developer, you only have to worry about tasks that a manager has given you to work on, and nothing else. It’s quite refreshing.
However, a significant problem can arise from this depending on the size of the startup. Even though I always enjoy this as a developer, if the startup is still at a small stage, I always think how much more efficient things could be if I were the one conversing with the client and handling the tasks. Of course, that option depends on your ability to manage the project with a small team.
There is also potential for serious drawbacks by adding in an extra layer of communication, especially if the middle layer isn’t great at managing the work. Sometimes the tasks can get convoluted and the developer might not understand the business requirements correctly due to the extra layer of communication.
The benefits and drawbacks of this structure is highly dependent upon the size of the startup. Even when one person has the skill-set to handle all the development work, sometimes there is just too much work to be done. In this case, it’s required that other developers are acquired to help on the project.
The four different roles of a developer are highly dependent upon a few factors
- size of startup
- ability for developer to manage
- development skill-sets
Choosing a structure that doesn’t fit the size of your startup can lead to be a costly error due to extra payroll and also lower efficiency. It’s important to evaluate what your current needs are, and where you plan to be in the next couple months.
Not all developers can manage, and not all managers can manage. Having someone who can do both roles effectively is an enormous asset to have on your team and provides advantages that would not otherwise be seen.
Having developers that are well rounded is more beneficial for smaller startups, but as the startup grows, you’ll find that more specialized developers might be the better choice.