Having success in a small company as a software engineer is very challenging for everyone that is used to working for middle-size or big companies.
One big difference that you might expect is that in a small company, you will have to wear many hats. You will do the work of a developer, DevOps, and tester and more importantly, you will be a software engineer. Meaning that you will need to know or research what tool/technology will solve your problem.
Another big challenge to expect is that product solutions won’t be as clear and refined as it is in a big company. A lot more documents will have to be written and you will be much closer to the CEO whereas, in a big company, you will rarely see him or her.
Also, be sure to expect highly skilled software engineers to work with you. Other than that, you will also have a bigger salary since you will need to do the work from other roles.
Ownership Culture
Ownership is a very important characteristic of a small company. It’s strongly valued and if you don’t understand this concept things will be very difficult for you. I wrote a full article with a lot of details regarding what is ownership for a software engineer.
In short, in a small company, it’s much preferable that you use more “I” than “we” since more is expected from you. Also, competition in a small company might be more severe depending on the culture and people will do everything to get attention in meetings or public chats.
Also, if the team you are working with becomes or is toxic for any reason, you don’t have many options to change teams as in a big company. This means that if things become really bad and your mental health is being affected, then it might be time to leave the company.
Of course, it will depend on the context of the situation but if you have the challenge to face, yes face the challenge, and don’t give up right away. But if you notice that your health is being severely harmed for a long time and you really see no point in continuing work for the company, for sure, the best move is to leave it.
Work Organization
The work in a small company is more disorganized than in a big structured company. It will be even more disorganized if the leadership doesn’t know what they are doing…
Therefore, you will see many and many tasks on the Kanban board but usually lack perspective or focus. Therefore, you are also responsible to try to direct things to the side where the company will get the most benefits which are not easy at all.
If things were built in a rush to get the product to the market quickly, chances are that you will see poorly written code and no documentation. Things get even more challenging when you are working with global teams because then you have to collect business requirements in a time zone totally different from yours…
When there is a lack of perspective in a small company, you can be sure that you will be impacted as well. Chances are that a work of 1 year or more will be thrown away.
Bureoucracy
It’s obviously less bureaucratic to work for a small company rather than a big company. In a small company you can, for example, send a message to the CEO and you will probably talk to him or her.
Other than that, using new technology is easier than in a big company. There are still political barriers but they are much easier to break than a big company. It’s much easier to change the programming language in an existing service or use a new programming language for a new Microservice.
You have more autonomy depending on what small company you are working for but remember that there will be probably political barriers. So, expect some work to convince whoever is in charge of technologies.
Meetings
Since there are many unknowns in a small company, you can be sure to expect tons of meetings. Meetings that you will have to discuss product requirements, technical requirements, API contracts…
I particularly don’t like meetings very much because they tend to go into the weeds very quickly and have low value most times. Most meetings could be solved with an email or even by chat message but instead many useless meetings are scheduled.
People take advantage of those meetings sometimes to talk and boast about their work so they get promoted or fill their egos. Considering that managers are most times in those meetings, the meetings become a selling place which I really dislike.
There are obviously also valuable and necessary meetings where important information has to be shared or collected. Therefore, we have to do our best to have only valuable meetings and not meetings where bozos have a great time.
Technologies Barriers
Even though it’s easier to use new technologies in a small company, there are also political barriers. If someone in charge of technology didn’t do the homework to get up to date with technologies and there is also no trust with developers, it will be an incredible pain to use new technologies.
Therefore, working for a small company doesn’t necessarily mean developers will use the latest technologies, there might be a lot of pushback.
Development Work
In most small companies, the development work is not as structured and organized as in mid or big companies. Meaning that there isn’t a quarter planning with all the tasks that must be worked on. That’s because usually there will be a Kanban with a bunch of tasks and developers can get as many tasks as they want for each Scrum sprint (2 weeks of work).
Usually, that becomes chaos because developers tend to work on many tasks at the same time even if they are not sure if they are delivering real value to the company.
When business requirements are not clear, developers will build a fortress around the software. Meaning that all kinds of automation, security, and tests will be implemented for the application. The only thing to remember is that all that work might be completely useless because if there isn’t business value, it doesn’t matter how fancy the technologies are.
Architecture Work
Since usually in a small company there is no architect, software engineers have to do the work of an architect. This means that there will be lots of documentation with the pros and cons of technologies and meetings to reach a consensus with the team.
The skill of writing good code is not so valuable for small companies, it doesn’t mean that developers write bad code in small companies but still, usually, people won’t care much. The skill that is the most valuable is being a software engineer, this means knowing and implementing a technology solution that will solve a problem.
Testing Work
In a small company, not always there will be tests but when business requirements are not clear and developers have time, there will be all tests you can imagine.
So, as a software engineer in a small company, you will be also a tester. You will implement unit tests, component tests, end-to-end tests, canary tests, load testing, performance test, smoke test, and the list goes on.
Product Owner Work
Since there are fewer people to take care of business requirements, you might be in charge of also collecting requirements. This means that you will have to do meetings usually with people out of your time zone to clarify requirements in a quick meeting which might be challenging and annoying at the same time.
Many people will be willing to help you and others not. So, you need to figure out points of contact on your own. Chances are that there isn’t a document pointing to all people that handle specific tasks in the company.
Finding responsible people will be a pain because it might take time and while there isn’t clarification of the requirements development work can’t be done.
Also, even when you find the responsible person, you will have to create a document with the business requirements which is something that no software engineer likes to do.
Leadership
As mentioned before if the leadership doesn’t know what they are doing, chances are that developers will do throwaway work. That’s true in any kind of company.
Sometimes developers know that what is being done doesn’t make sense and try to communicate to the leadership but the leadership might not listen.
If the leadership, on the other hand, knows what they are doing, you might have a great experience in a small company. That’s because developers want to deliver real value, also, developers hate to work for a long period of time and learn that their work was thrown away. Developers want to create an impact in the company and grow technically, otherwise, there is no point in the developer’s work and for the company.
How to be Successful in a Small Company as a Software Engineer?
Ownership is the key. You don’t need to be excellent technically (of course that helps) but you need to know how to tackle problems and work on that from the start to the end.
As mentioned before in a small company it’s far more important to be a software engineer generalist who will be able to solve a vast range of problems (it doesn’t matter if it’s not the best way) rather than being more specialist with a few technologies. So, if you had a lot of exposure to different technologies in the past this won’t be so difficult for you. However, if you never worked with a vast range of technologies then things will be hard.
That doesn’t mean you need to know it all, remember that you can always use the just-in-time learning technique. This technique is that you learn a technology when necessary and doesn’t try to learn everything because this is impossible.
You also need to know how to show your work. If your work is not so visible, people and your manager won’t know exactly what is being done and you might be negatively judged. Therefore, you can use the stand-up meeting to let people know what value you are delivering, no need to oversell, just be clear.
In some situations, you will also have to be more forward and take charge of the situation and your tasks. Otherwise, other people might take on the tasks that you are responsible for. This will go completely against the ownership culture that is much valued in a small company, so be careful with that.
You must finish your task, this doesn’t mean that you can’t ask for help, you totally need to do that sometimes since the range of problems you must solve is very wide. However, you must assure that YOU will start and deliver the task, you are the owner, remember that.
Pros and Cons of a Small Company
Working for a small company has their advantages and disadvantages. You can be sure that you will do more work in a small company rather than a mid or big company. Let’s see what are the pros and cons then:
Pros
- You will work with highly skilled software engineers.
- Usually the salary is higher.
- Learning is usually great.
- Easier to be promoted to the C level (CTO, CEO, CIO).
- Less bureaucracy.
- Easier to use new technologies and usually more autonomy.
- IPO might happen and you have options, you might get a great amount of money.
- Usually too many responsibilities and roles to work on.
- Usually there is an excessive amount of meetings many of them have no value.
- Many documents to write, therefore, coding might not be that much.
- More difficult to change to another team or project since the company is small.
- There is more pressure on you to deliver value.
Cons
Conclusion
Working for a small company is a good experience because you will do the work from the ground up, therefore, there will be a lot of learning. However, if the leadership doesn’t have clear goals the odds are that you will have a bad experience.
If the small company, on the other hand, has good leadership, the odds are that you will have a good experience and the amount of work won’t be so overwhelming giving you great chances of growing more quickly and enjoying your workplace.
Working for a small company at least once is a good move for experience and growth.
