The size of the company we are working for affects the way we should behave as developers. You should adapt to the constrains and advantages that the company's size imposes on you.
Let's see some differences and how they impact the way you work.
The cost of delay
A small company is usually constrained by limited financial resources. That is not good nor bad. It's a fact and you should take it into account.
If a project is delayed the costs of that delay may jeopardise not only the project but the hole company. Small companies do not usually have the financial resources big companies have and therefore any delay is specially harmful for them. Yes, I know, that puts some pressure on you but that is fine as long as you are aware of that. In small companies or startups good enough is better than perfect. Do not strive for perfection, just get things done!.
Small companies should only hire "full-stack" developers. People that can help them ship code. One sprint you focus on backend development and the next sprint you focus on frontend development. Your flexibility, your ability to wear different hats is really beneficial for the company and will help it to achieve their goals.
The cost of change
When you work for a big company with tenths or hundreds of developers you should take into account the cost of change. The way you name variables, best practices, how you review code and how you merge it. All must be know beforehand by everyone involved and that has a cost.
Using a new application to manage your projects can be very costly both in time and money if you have 200 developers. Creating accounts, migrating information, teaching the new tool... That cost is negligible in a small company,
Even small details like how you name variables or how to test your code have a big impact on big companies where all developers should follow the same best practices.
Good thing is that time is not a constraint, sure there are deadlines, but their impact is not as acute as in small companies, A two weeks delay in a 3 months project is not a big deal in a big company and may have a dangerous impact in a small company.
In many cases a small delay is desirable if that helps the project to follow all best practices that the company imposes to itself. Your role as a developer must be to generate very high quality code. Measure twice, cut once. Once some code is merged into the codebase it's exposed to all your colleagues and it won't be easy to modify later on. Your classes and methods will be used by your colleagues and any change to them will probably have deeper implications and side effects.
In big companies roles should be very clear from the very beginning and a separation between backend and frontend roles is really beneficial. It helps you as a developer to focus on a specific part of the application and makes it easier for you to apply and follow the rules and best practices.
The cost of onboarding
This cost is frequently overlooked and underestimated. Having a new person up-to-speed and productive is not easy. In small companies the biggest hurdle is not technical but making the new developer understand the business logic of the company. In a big company you don't have that problem because people work in teams where the business logic is constrained but on the other side there are many rules and best practices that you need to learn so it will also take some time for the new developer to become productive.
I've frequently found that the onboarding process of the companies I've worked for (no matter the size) is focused on technical aspects with a quick view of the company business model. Small companies should pay more attention explaining their business model to new employees because it has a big impact on their productivity.
On the other side the cost of losing talent is bigger in a small company not only because the technical skills but also because losing someone that really knows our company, how it works, its goals and objectives makes it very difficult to replace even knowing that the onboarding process is quicker in a small company. Big companies can afford lose talent without risking as much as small companies but it's something they should avoid as well because knowing the "company's culture" is an important asset.
Agile vs.efficient
We all know a lot of big companies calling themselves "agile" but I've never really seen one that truly is.
Big companies can be efficient but can never be agile. Only small companies can be agile. That is a big advantage for them if they know how to use it.
A startup can (and should) pivot and change its strategy. They can do that in less than one week. That is impossible to do for a big company where you need to coordinate a lot of people. That is the truly definition of agile: The ability of changing your mind and having a team and a process that helps you do that.
You can pivot and change strategy in a big company but you need a lot of planning and that takes time. The more people you have the more time you need to pivot. And you can do all of that change in a very efficient and optimised way but never agile.
Summary
As developers we need to be aware of the constrains and advantages of the different sizes of companies.
We should not work the same way whether we are working for a big or a small company. I think that is a big mistake that can lead to frustration both for the developer and the company. We need to be flexible and agile and adapt the way we work and the way we code to the needs of the company we are working for.
Originally posted here: alvareznavarro.es
Top comments (1)
This isn't taking the realities of limited funds or prolonged job search into consideration. With the proper technical co-founder/CTO/architect in place, software can easily be architected where that person takes a hands-on role coding alongside (and mentoring) junior frontend and/or backend developers (who are easy to ramp up because it was designed with them in mind).