What I've Learned: Reflections on Life, Work, and Growth

There are a few things that I've learned at Swapcard over the years, sometimes the hard way, sometimes by using common sense. Always by being human.

I can sum it up with one simple sentence: "it's all about balance ⚖️." But that's more difficult than you might think.

To get the most from your engineering team, you need to make them feel connected to the company. Don't operate as a black box; explain the company's issues, share the challenges, and always be transparent.

Career path

Create a career path. If you want to prevent turnover and motivate your people, you need to embrace the career path. They need to know how you are going to make the most of their potential. Whether it's an individual contributor or high-level management, they need to understand how they can grow within the company.

Make sure your engineering team knows that they can grow within the company. You need to find the right balance between hiring externally and promoting internally, which can be tricky. Promoting internally will help you create a core team that grows with the company. If you give your people a chance and show that you trust them, your people will follow you almost anywhere.

Becoming a manager is not the only way to grow as an engineer. Don't force people to become managers when that isn't the best use of their skillset. It's better to have a great individual contributor rather than a manager that doesn't like what they are doing. You want to set your people up for success, which means identifying what they do best and putting them in positions to succeed.

Behaviour

Be human. You can use a lot of methodologies in your work, but nothing replaces the human and social elements. You can solve the majority of issues by showing a willingness to listen to people and genuinely take what they say to heart. Think about the yellow rubber duck - externalizing the issue you are facing and talking it out helps to find the problem and address it. Don't sweep your problems under the carpet where they'll collect dust. Tackle them head-on.

We all make decisions based on the information we have available to us at a specific moment. It's important to own up to your past decisions and be humble when you've made a mistake. You can be wrong; mistakes are how we learn and grow. It takes a strong leader to be able to recognize where they went wrong, iterate on it, and fix it.

As a leader, you need to be a problem solver and believe in the company vision. You need to earn respect and legitimacy, you cannot just ask for it. You will earn it by your day-to-day actions, which you are responsible for.

Management

Engineers need to use and understand the product they're working on. This seems pretty basic, but as pure engineers, we sometimes tend to forget this part. Remind yourself that you aren't just developing some engineering solution; you're developing a product. You're the backbone that solves issues or creates new needs for people and companies.

Don't ask people to do things that you don't even understand or have any idea about. Of course, you cannot know everything. But have a willingness to learn and to have an opinion about a product or technology, especially if you need to manage it. This goes back to my earlier point; be curious and humble and ask people to explain to you how things work. Always be willing to learn and respect the knowledge your people bring to your team.

Speaking of team, don't hesitate to talk with other teams and divisions. It's easy to be protective of your people and work, but it doesn't help your engineering team if they feel separate from the rest of the company. By working together with other teams, you can solve the most significant issues and even identify problems before they happen. You will for sure discover many quick wins that you can implement to help the company operate at scale and make everyone's life easier.

When it comes to running a team, accept that things can be chaotic. Chaos management tends to help provide structure, then iterate and find the right balance between agility and processes.

Engineering

The perfect engineering solution doesn't exist; it's all about the pros & cons. Don't over-engineer and try to solve issues that don't exist for today's business or product. It's important to anticipate the future while also balancing current needs in order to develop something that can scale. It's not about being perfect. It's all about finding the right balance. This takes practice, but it's an important point to remember.

Be careful about taking on the famous quest of developing "agnostic" solutions. That's often pretty hard and you cannot develop something agnostic when you only implement one provider at a time. You should be able to easily switch from one provider to another, but this doesn't mean you need to develop an entire system for something that may happen in a few years.

There is no bad technology (well, maybe sometimes), but ultimately it's always about solving problems. I remember how bad PHP's reputation was during my time at engineering school, even though it's actually used by a lot of successful companies and has run at scale for most of them.

Make sure the QA team is part of engineering and don't make them operate as an isolated entity. Continuous delivery is key, and for this, you need to accept that zero risk is a dream (it depends on the product you are working on, of course). However, keep in mind that there are plenty of technologies that can help you remain agile and limit risk (i.e. feature flags, traffic deployment, error reporting, APM, centralized logging, E2E testing, QA review, etc.)

Sometimes you need to break things to make them better. If a policy slows you down, remove it and try to operate without it. You cannot cover 100% of the daily actions by policy and procedures. You might be able to do this if you're Google, but not when you scale and run a new business.

Be careful when it comes to trends regarding technology. You can read articles about how X technology is dying, and 6 months later, read another article about how this technology is spreading all over the engineering world. Stay up-to-date with the technologies that are out there, but be wary when it comes to what's trending.

Choose the right infrastructure tools and adapt them to your needs. Don't run Terraform and Kubernetes if you run a small business with 2 nodes. Instead, use the AWS Console, make an easy deployment pipeline with Github Actions or Gitlab, and then ECS, for example. You might not even need to use a huge cloud provider right away. You can use a dedicated server and run deployment over SSH if the business is just starting. Understand what your system needs and choose the tools best suited for it.

Embrace open-source services. You can start by doing self-hosting if you need to keep costs low. Once you can afford managed services, do it.

Don't copy & paste organization models from famous companies because they're successful. Take inspiration from it and adapt it to your needs, culture, organization, and business. Just because it works at another company doesn't mean that it's going to work for you. All organizations are different, so be sure to embrace what makes you stand apart and put that to work for you.

Others

SLA is all about trust. Don't hide issues. Customers tend to be more understanding when you inform them about an issue right away and then follow up with a detailed post-mortem. Open a public status page that you share with your clients so that they can have easy access to this information.

Security is incredibly important and should be a central consideration from day one. If you want to build a sustainable product and prevent security issues from constantly arising, you need to start training people about security and use the right tools from the beginning.

Run bug bounty programs, there are usually offerings geared towards startups and it can help you gain confidence in your security. You will also learn from the issues reported and can create better guidelines for your engineers.

One day, you will need IT support internally, especially if you are a distributed team. Make sure that you keep this in mind because the need for IT support will arise faster than you might think. They provide help with ordering assets at scale, handling tool access, tool reviews, common IT issues, and more. Be sure to plan for this, you'll be glad that you did.