In the last ten years, I worked for small to medium-sized businesses both B2C and B2B and also in different countries. Naturally, during that time I picked up some general experience, and I would like to share what I learned with you now. The following are very simplistic; it is a personal summary of what I believe and what works for me.
(1) Break big tasks into smaller pieces. Sometimes tasks, be it legacy code, new feature, or even a business strategy scope - can be complex. Usually, there are layers and layers of complexity that we add because it’s natural to assume that problems come with complex solutions.
In these situations, it’s best to take a step back and see the bigger picture. Just write a line then another one, improve it, refactor if needed, start simple and then grow with it - no need to overthink it at first. Also, most straightforward solutions are usually the best solutions.
Rubber Duck method works.
(2) Take the time for 1:1 with your manager. It might be hard to justify talking to your manager for one-hour weekly. But that is what I did, and it worked. You can discuss issues in-depth, then usually you just feel more valued as an employee. There is no replacement for that.
(3) Just pay for developer tools. Any useful tool that makes you more efficient counts—GitHub Copilot, Cursor, Cline, RooCode. Giving the developer a fast, modern toolset also shows that the company values him/her. There should be no discussion about that. Period.
(4) Meet your customers. In one company I worked for, we had the opportunity to visit our customers regularly. These encounters made an impact on me. It is one thing to exchange emails, but it is an entirely different experience to meet them and hear their pains and successes directly from the horse’s mouth so to speak. It has a lasting effect on the way you think about your users when you are back developing in the office.
(5) Don’t let the build become slow. There is hardly anything more frustrating than having a slow feedback cycle from your software. In one instance we worked with Node.js in the backend and Webpack in the frontend; both were getting slower by the week, and I felt like smashing my head against the wall. Buying faster machines won’t help. Instead, use modern bundlers like Vite, esbuild, or Bun, adopt Rust-based compilers, and structure your code for incremental builds with hot-module reload. There is no magic fix.
(6) Cross-functional teams. Before we had formed cross-functional teams, we were only able to tackle small projects effectively. Once we had a real group consisting of designer plus frontend and backend developer, things took off. It allowed us to work on a much bigger scope, move faster, and of course add more features. It is a challenge at first, but overall it is worth it.
(7) Trello - future scaling problems. In multiple companies we used Trello (or other similar kanban board software) to manage bugs—company-wide or in small teams. I like Trello, but its search and workflows only scale so far. Simplicity fades, and it becomes overwhelming. Today I prefer tools like Linear, Height, or GitHub Projects, which offer keyboard-driven triage, deep search, and analytics out of the box.
(8) Take on responsibility. To be successful at any company you need not be afraid to take on responsibility. In smaller companies (opposed to a corporate environment) you get the opportunity to do so: roles are not set in stone, and it is easy to grab unwanted tasks. You must become the person for something to improve your standing. You need to show and be proactive and shape your image - or others will do it for you. Take on responsibility.
(9) Learn to Adapt or fight if you need to. You might have disagreements with your manager or management in general. In that instance, you need to decide how important these issues are to you. I think it is essential, to take on the challenge and fight for what you believe is right. Often it will be a difficult battle. And if nobody supports you, or even worse, nobody shares your views, then you have to reflect and ask yourself if it is worth it. Or maybe it is time to look for another job.
(10) You can influence the first impression. Whatever you say and do will shape how others perceive you. If you work long hours, you will be deemed “the workaholic”. If you constantly come up with new ideas, you might become “brainiac”. And the thing is - it sticks. I think that early impressions are quite important and that it is much harder to change the perception of you afterward.
(11) You need a strategy for real-time messaging. We use Slack (and sometimes Teams) for instant communication, but real-time chat can kill productivity. Decide what belongs in chat versus email, a shared doc (Notion, Confluence), or face-to-face, and archive decisions so nothing gets lost.
(12) Company benefits that matter. A lot of companies and especially startups boast about their cool benefits. Some take pride in their ping pong tables; some want to impress with an open bar on Friday nights and some show off their selection of candy. It’s a trap! Look for meaningful benefits like lunch, good education budget, health benefits, or best - highest salary.
(13) Balance senior and junior people. I’m not sure why, but the companies I worked for always had many senior developers working on “the backend”. Strangely in the “frontend department” this was the reverse - mostly everyone was at a junior level. Even though junior developers displayed a lot of enthusiasm and creativity, they would often miss the big picture and lack high-level vision. So my point is that there should be a right mix of junior and senior people.
(14) Visual mock helps a lot. Usually, a new feature has many stakeholders—PMs, designers, product owners, executives, developers, and customers. All have expectations. The best way to align is with high-fidelity prototypes in Figma, as close as possible to the final result. This prevents misunderstandings and puts everyone on the same page.
(15) One office per team. It has been shown again and again that an open-plan office is a bad idea. From experience, I can tell you that you need a quiet environment to get work done; it just allows you to focus better. But you still need to be able to communicate easily with your teammates. The ‘one office per team’ plan strikes the right balance if you keep teams small.
(16) Extroverts dominate every discussion. Many technical people are introverts. Extroverts like to talk and write—it’s natural for them. Introverts usually cannot compete in that area; it just takes too much energy. Companies should mitigate that or risk losing out on great ideas and contributions by their ‘silent minority’.
P.S. In case you are wondering: People usually say that I’m quite outgoing and believe that I’m an extrovert, but honestly, I do think that I am more introverted. My energy regenerates when I’m alone with my thoughts.
(17) Developers need to talk about their mindset. Once the team gets bigger, there will be conflicts. We are all unique. That’s why it is important to share your mindset about things like code style, architecture, development and bug process, code reviews, and so on. Just writing down rules on a wiki page does not work. It needs to be lived, understood, and changed if required.
(18) Regular status updates are motivating. For me, knowing that in the next day’s standup my team will listen to what I have worked on motivates me. When the company is still small, it is quite easy to do so. When the company grows, inter-team exchanges or even updates by head managers are harder to schedule, but I always found it motivating and good practice in general.
(19) Don’t kill autonomy. Giving developers the chance to work on side projects can become a powerful source of innovation. When a company supports this practice, great things happen. If it doesn’t, the most dedicated developers will pave the way for the opportunity anyway, which of course can lead to extra stress or even burnout in the long run.
(20) Pair programming works. Pair programming is one of the best tools for knowledge sharing. Modern shared-cursor tools like VS Code Live Share, Tuple, or JetBrains Code-With-Me make remote pairing nearly as effective as in-person, blending learning with the social aspects of coding.
(21) Have a proper release process. I’ve seen features stuck in limbo for months because nobody knew how to progress with a finished branch. Automate builds and deployments with GitHub Actions or Buildkite, use feature flags like LaunchDarkly or Unleash to decouple deploy from release, and assign clear ownership for release coordination.
(22) Measure learning budget in time, not in money. Most companies have a learning budget, but it is hardly ever used for anything other than attending conferences. Learning from blogs, books, and videos is just as good. Give developers dedicated days a year to learn things on their own. It’s what most of us do anyway—often on weekends—but this way, the company can support those efforts directly.
(23) Repetition makes it sticky. If you have an important message or idea you want everyone to understand and remember, you cannot just say it once. Repeat it, repeat it again, and again. It needs to be crystal clear and easily recalled.
(24) Retrospectives are crucial. In most companies I worked for, retrospectives are standard practice. The importance of looking back and evaluating cannot be overstated. Every team member should think about what went well and what didn’t, and improvements needed. Group discussions work best when everyone shares their input.
(25) Focus only on what you can control. In companies, especially smaller ones, you won’t be able to avoid friction. Focus your energy on things you can control and influence. Don’t waste it worrying about things that are out of your hands.
(26) Learn by doing. In a fast-moving environment, you need to learn quickly. Jump right into it. Open a tutorial and implement it. Invite a teammate to join and make it fun.
(27) “No fit” is real. It might happen that you’ll get into a bad team. Trust your instincts and move quickly before it damages your well-being and career.
(28) Attend work parties. This one is simple but true. Even if you are an introvert and hate these types of gatherings, show up for an hour. It demonstrates your commitment to your employer and shows your peers that you’re a team player. Plus, it helps you connect and network.
There’s always more to learn, and every situation is different. Treat these lessons as tools, not strict rules.