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. 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 you are creating. In one instance we have worked with node.js in the backend and Webpack in the frontend. Both were getting slower by the week. In the end, sometimes I felt like smashing my head against the wall. Because of this exponential growth of sluggishness. Buying faster machines won’t help. You need to structure your application code correctly. 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, add 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 have used Trello to manage our bugs, sometimes it was used company wide or just by the team. I like Trello, but I always felt it wasn’t enough. Search is difficult and only scales up to a certain point. The same goes for project management side of things. At a certain end, the simplicity fades away, and it just becomes too overwhelming. I prefer other for that purpose dedicated tools that support and facilitate what you are trying to achieve.
(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 stand up and 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 to 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 is quite harder to change the perception of you afterward.
(11) You need a strategy for real-time messaging. At work, we use real-time messaging systems for communication, i.e., Slack. While in general, it is all good and fun, I think that in certain circumstances it kills a lot of the productivity. I would say that it is important to define what should end up in a chat, what should left to email, face-to-face conversations or the wiki.
(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 or health benefits.
(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 and if there was a senior developer he had his hands full - to keep the code quality high, advise and train juniors. Even though junior developers displayed a lot of enthusiasm and creativity which - while meaning well - 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. There is the project manager, the designer, the product owner, the CEO, the developer, customer - you name it. All of them have their expectations. I find that the best way to communicate is through visual feature representation as close as possible to the final result. This approach helps to prevent misunderstandings and brings everyone on the same page.
(15) One office per team. It has been shown again, 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 a right balance if you keep teams small.
(16) Extroverts dominate every discussion. Speaking from experience, I find that many technical people are introverts. Extroverts like to talk and write - for them, it’s a gentle exercise. Introverts usually cannot compete in that area; it just takes too much energy. Companies should mitigate that or risk of losing out on great ideas and contributions by its ‘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 introvert, 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 all are unique. That is 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 at the next day’s standup my team will listen to what I have worked on, what I have done - 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 is harder to schedule, but like mentioned I always found it to be motivating and good practice in general. It’s better to have more than less.
(19) Don’t kill autonomy. Giving developers the chance to work on side things can become a powerful source of innovation. When a company supports this practice great things happen. If it does not, the most dedicated developers will pave the way for the opportunity anyway (e.g., working overtime or weekends) which of course can lead to extra stress or even burnout in the long run.
(20) Pair programming works. A good “tool” to share knowledge among team members or even across teams is pair programming. I quite often find them even more effective than reviews. The interactions and discussions during coding are invaluable. You are not only learning, but also interacting socially which I think is a big plus. How good it works often depends on how well the two developers can get along.
(21) Have a proper release process. I have seen features stuck in limbo for months because nobody knew how to progress with a finished feature sitting in a branch. It is essential to have a clear understanding of who has which responsibilities or, even better, have someone whose part-time job it is to take care of that.
(22) Measure learning budget in time, not in money. Most companies have a learning budget, but it is hardly ever used for something other than attending conferences. Regards to workshops they can be a hit or miss - often there is not even one with the latest technologies. But like many, I learn new things from blogs, books, and videos just fine. So I find a good idea to allow developers to invest a few dedicated days a year to learn things on their own. It is what most of us do anyways - often on weekends - but this way the company can support these efforts directly.
(23) Repetition makes it sticky. You have an important message or an idea you want everyone to understand, share and remember it. You cannot just say it once. You can’t just put it in bold letters. What you need to do is to - repeat it, repeat it, again and again. It needs to be crystal clear. There should be no doubt about what you say, and it should be eventually easily recalled.
(24) Retrospectives are crucial. In most companies I worked, retrospectives are standard practice, how it works is - we sit all together as a team and reflect on the last development iteration. The importance of looking back and evaluating cannot be overstated. Every team member is required to think about the things that went good or things that went bad and may need improvement. The group discussion starts only after everyone expressed their thoughts. This way, everyone shares and can bring up important issues - and frankly, it is way better than the kind of meeting where the ‘loudest’ dominates the conversation.
(25) Focus only on what you can control. In companies, especially smaller ones, you won’t be able to avoid friction. It’s as easy to get caught up in what you can change and what you can’t. The problem is with the latter - you have zero control over it. The reality is that bad thing will always happen to us that are beyond our control, and getting frustrated or holding grudges is not going to make it disappear, so it’s not worth spending your energy on it. Focus on the things you can.
(26) Learn by doing. In a fast-moving environment things may change real quick, i.e., you need to learn a new programming language, new software tool, etc. - best to jump right into it, open a tutorial and implement it locally. Invite a teammate to join to make it more fun.
Practice makes perfect
(27) “No fit” is real. It might happen that you’ll get into a bad team, and trust me you will know that it is a bad team, ask to be reassigned to another one or even leave. Its unhealthy for you both mentally and career vise. It’s better to jump the gun sooner because if you wait, it will get harder to get out.
(28) Attend work parties. This one is also quite simple but true. Every day you see the people you work with, but how much do you know about your co-workers outside of their work email address and their favorite beverage? Even if you are having a formal party, the get-together is still a more social atmosphere than your cubicle. Even if you are Introvert and hate these types of gatherings, show up just for an hour it demonstrates your commitment to your employer and shows your pears that you are a “team player”. In practice, I found that it helps with - connecting, networking and growing bond. Oh and last and but not the least - don’t get drunk!
No doubt there are more things I could write about and things I still need to learn. But as always there is the thing called “context” so apply what you learn accordingly.