Lessons I learned on managing software engineers

- 5 mins Cosmin Rusu

A few months before the pandemic started, I started my side hustle, Duty Labs. In this article, I’d like to lay down some of the things I’ve learned from working with tens of software development engineers and teams. Take everything is here as my observations from my own experience working with Software Engineers primarily based in Romania and United States.

When I started the company, most of the folks I worked with were people I knew from university or high school. It was fairly easy to pitch them to come work side by side with me on the projects I found, because they already knew and trusted me.

This simple hiring process was quite powerful and efficient. However, your network is as big as it is, and most of the strong engineers already have a job, so you can’t easily convince them to come work with you. However, there’s valuable information here because there are probably software engineers in your network that are about to graduate and they know you as well (for example from different University events, your GitHub repository with course material, and so on). So I already have a strong pool of candidates right there. The only problem with this is that I don’t really have hands-on experience working with them. This leads to the classical hiring problem: how do you assess if a candidate is a good candidate for you?

Assessing junior candidates

My solution here was simple: have just a few clear filters:

  1. Attending or graduated with a CS degree or equivalent
  2. Willingness to go through a simple Ruby on Rails tutorial, and then a small test to assert if they really went through it.

With this, I was essentially filtering the people who have a decent CS background (know what a database is, how to debug, how to use the cli, etc), and the people who are fast learners and willing to put in some extra work for the opportunity to work in our team.

I am still amazed at how many people got me very impressed at the end of this process because I simply wasn’t able to predict their outcode based on the initial conversation. Translate: I had some really awesome discussions with folks that did really poor on the tutorial (or some that never finished it), but I was skeptical of candidates that in the end did an amazing work on both the tutorial, and after working with us for a few months/years now (saying hi to whichever team member is reading this).

I was basically looking for a combination of good education background, and learning ability, motivation, a bit of hard-working, determination. In other words, I was hiring for potential (and firing early if needed!).

Growing their Software Development skills

After I hired a few folks, the next problem I had is how should I organize and manage them? Obviously, I have no educational background in management or leadership, but I was a decent software engineer. So, my idea was simple - just help them grow the same way I have grown: by working on different interesting projects that keep increasing in complexity. I was their mentor rather than their manager. I was their manager in the sense that I told them which project they should work on, assigned them tasks, etc.

What’s extraordinary is that I found that some folks were growing at rocket speed. Image a graduate engineer, with three months of working experience with me, some previous internships, and lots of personal projects!! He became my CTO in 6 months. He is one the most talented engineer I ever worked with! There are at least 4 other examples of such pattern, so I’m still amazed at the young talent available out there (which is so much underrated!).

Remote Teams

With recruiting and growing out of the way, let’s switch gears here and talk about project management.

In my world, a Remote Team is a team of a few software engineers (and maybe a QA) that are assigned to work on a specific project. That being said, it’s quite clear that the output of the team is the project itself. The inputs are all the hours they have allocated on a project, and the requirements.

Our process is quite straightforward:

Notice we don’t have any extra meetings. We use Slack for most communication. If all goes well… In case things don’t go as planned, I (or the team lead) usually have to step in and find out what are the problems and why things are delayed, tasks do not get done on time, etc. That’s natural and normal. Sometimes you figure out some folks just have a hard time, or they have an exam coming up, they feel burnout, etc. Either way -> when discussed, the solutions are quite easy: you can either motivate someone, or train them in order to do something. There’s no other way. If things do not get done it’s either because someone lacks motivation, or skill. Try to find which one of the two is the case and fix it!

On the future

That’s pretty much my lean process of working with remote software engineering teams.

In case you’re interested in joining our team, and work remotely with us, reach out to me. I’m currently looking for both junior, mid, and senior engineers.

Moreover, if you’d like to build and grow your own team, reach out to me as well as I can give you a client project, and you can work directly with him with your own team. Based on my experience, I can teach you everything you need to konw to grow and build your team, as well as how to manage the client relationship.

If you’re interested in working with us in the fashion described above, reach out to me on LinkedIn.

comments powered by Disqus
rss facebook twitter github gitlab youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora