Twenty years ago, I was a platoon commander in a classified unit in the army (that is no longer classified). Back then, making decisions and applying authority was straightforward. Officers were to make most decisions, pushing them down the command chain through non-officer commanders all the way to the soldiers. Decision enforcement in that ecosystem was called "a command."
There was no place for discussion once a decision (command) was made, and the expectation was that it would get fulfilled right away, or else…
This thick layer of "simple" soldiers who are untrained in the military decision-making process and unaware of much of the intel requires a top-down and highly hierarchical management approach. Add to that combat conditions where soldiers put their life at risk, and the need for such a hierarchy with high discipline only intensifies.
Fast forward to a year ago. As I approached building my R&D team at Artlist - my first position as a team leader in the tech industry - I was trying to define my approach to managing and leading such a team. Obviously, there are many differences between leading an infantry team and a team of software developers, so you can already understand that much of the conclusion would be very different from what I described above.
In this article, I'll try to lay out some of the dilemmas I had and insights I gained regarding decision-making and authority as a team leader in R&D.
Before I dive in, I think some context is needed about the company I work for, my position, and my personal history.
In 2016, Artlist was founded as a bootstrap to enable video creators to find high-quality music for their videos with a revolutionary licensing subscription. Since then, it has grown tremendously, acquiring two companies and reaching 300 employees at the beginning of 2022. It has also changed its goal to support the whole content creator economy, not only video creators.
As for my position, my team is in charge of two of the company's web applications, artlist.io and artgrid.io, and while writing this article, we are shifting into a group-of-teams structure, so my title is changing from team lead to group manager :-)
Now here's an abridged version of my personal history to give you the whole picture. Besides being in the army, before becoming a software developer, I had a pretty enjoyable career in the food & beverages industry, mainly in management positions such as managing a bar, leading the on-trade market in one of the biggest wine & spirits importers in my country while managing 12 employees and a few million dollars of sales per year, running my own restaurant (and losing all my money), and finally establishing and leading a new online wine & spirits e-commerce site.
Now that we've set the context, let's discuss the key factors that have impacted my approach to management. I'll also star* the insights I have derived from these factors and will try to construct from them my holistic culture and attitude as a manager.
Team = Leverage
The basic idea of a team is leverage. Yes, I can write code, but I'm limited by my own velocity, knowledge and experience. Leading a team enables you to accomplish more, thanks to an increased workforce and, more importantly, the increased shared knowledge and expertise. As such, the team's ability is not only defined by its members' velocity but also by the type of knowledge each member might hold.
There are a few key factors to maximizing your team's leverage.
When you have a diverse team, each member's added value holds great significance. Conversely, when all team members are the same, the added value of a single team member is lost.
Of course, there are many other benefits of having a diverse team, but since this is not the main topic of this article, I'll leave it aside and perhaps address it more in-depth in the future. I'll also leave aside the option of growing your team's size, as it is more of an external solution.
Another vital factor in optimizing your team's leverage is increasing each team member's velocity, and I find that two main actions increase an individual's production capability:
- A personal development plan* focusing on areas that simultaneously benefit the employee and the company. Such a plan should be defined and owned by the team member with the full support of their manager, and I will take the story of one of my team members to illustrate this point. Parish is a great front-end developer and has worked at Artlist for several years. However, despite his experience, Parish lacked ownership skills, resulting in a tendency to push things to production with insufficient quality, thus introducing new bugs that required him to go back to his developments repeatedly. When one of our QA engineers told me that he needs to run some QA on the site every time Parish deploys to production, the severity of the situation became clear to me. Once I had Parish understand the problem and its impact on the company, we raised some suggestions for improving the quality of his work and avoiding future issues. Long story short, a month and a half later, the feedback I got from external stakeholders was how satisfied they were with Parish's work, and he had reduced his QA cycles to almost zero. While this example might seem simplistic, I find it to be the general case in most PDPs, both for technical and soft skills.
Frequent candid feedback* - This is quite a big topic on which many books have been written, so I'll try to avoid going deep into this rabbit hole and simplify it by stating the following: When we receive frequent, ongoing candid feedback, we can alter our behavior and actions in a way that helps us grow at a faster pace. And the compound interest of this growth holds tremendous value to us and our surroundings. I'll just add a few tips for increasing feedback loops in your team:
a. Start with the why - Show them the benefits they can reap from it.
b. Do it gradually and through a controlled process until you are 100% sure you can expand it.
c. Teach the team how to give feedback and how to receive it.
d. Practice a lot with the team. For example, when someone gave another team member some feedback, I asked someone else to give feedback on how the feedback was given. Then I asked for feedback on the feedback's feedback and so on. It was excellent practice for providing feedback.
While Artlist has just grown to more than 300 employees, it still has a dominant start-up approach, focusing on innovation and our ability to react to changes and decisions as fast as possible. This point is crucial in defining the culture of my team as it's a key factor in the success or failure of any start-up. To emphasize this point, we can look at the last year from my team's point of view. Product-wise, we started by taking ownership of three websites - artlist.io, artgrid.io and the Artlist jobs site. But since then, we ended up rebuilding Artlist's primary site (artlist.io), are now working on a significant product change, and are starting to build a new product from scratch.
But the product side of things is only one part of the story. Agility is required from an HR perspective. In fast-paced start-ups, the need to adjust the organizational structure is an ongoing process. For example, only a year ago, I had zero team members, while today, my team consists of 16 members and is about to break into several groups and add more team/group members.
So what does this all mean to our forming culture? First and foremost, team members must be flexible and adjust quickly to any new initiative or structure. To enable this, they need to have a good understanding of the high-level plan and goals. They also have to be connected to the "why" at all times and understand the reasons for each task and what we aim to achieve.
I found that there are two things I can do to support this behavior - high transparency* and high ownership*. While the former is relatively straightforward and means that team members are familiar with the decisions as well as the decision-making process, the latter is very significant and not always obvious. Perhaps explaining how I give tasks to a team member will shed some light here. Here's the basic rule: Provide enough information to enable your team member to make their own decisions on how to complete the task. Then, understanding the big picture, why this task is needed and how it helps us, they will make wiser decisions and take ownership of the mission along the way.
Start-ups are highly reliant on continuous innovation, which is synonymous with creativity. But how does one create an environment that increases a team's creativity or, at least, its creative results?
These questions have already been answered in the highly recommended book 'No Rules Rules' by Erin Meyer and Reed Hastings, in which they describe how much of this can be achieved by reducing the rules* you apply to your employees, increasing their responsibility, ownership, decision-making, and problem-solving. This isn't an easy solution, and I'll address it later on in this article.
Increasing each member's part in the whole team's decision-making, transparency, and putting more power and influence in their hands* will also increase the creativity and inspire them to question and criticize anything we do.
Unlike most of my prior management experience - leading soldiers, sales representatives, bartenders, and so on - which didn't require any formal education or high analytical skills of my subordinates, software developers tend to be pretty damn smart. Some have completed a demanding degree in CS, while others are more autodidacts, but they all have high knowledge and skills in software development. Such workers require a specific management approach to get the most out of them. And by "getting the most out of them," I mean not only from the company's point of view but also the workers' perspective, as they tend to focus on self-growth and learning. This brings me back to several points I've already discussed before in this article, such as having a personal development plan* and ownership* . It also means that the team members can have a highly active part in the team's decision-making process*. Such decisions can vary from mission-oriented to prioritization to the culture itself.
So let's take a quick look at the key points we have gathered so far regarding team building and management:
- Personal development plan
- Frequent candid feedback
- Rules Reduction
- Putting more power and influence in the individual hands
- Make them an active part of the team decision-making process
Trying to connect the dots, I think the first thing that jumped into my mind was that many of these points are focused on empowering each member. Some even overlap, and others were considered for management only in my low-tech experience.
That made me rethink what it meant to lead such a team. How much should the leading approach be egalitarian vs. hierarchical? If my team consists of such intelligent people, how much of the decision-making should I make?
Here are my conclusions:
The team as a whole is smarter than any single member, including me.
This doesn't mean that I, as team leader, won't be making decisions. But it does mean that in many cases, my role should be enabling the team to make decisions in a healthy manner, rather than making them on my own.
Such an approach can result in better decisions and empower the team simultaneously.
Much of my focus should be on establishing good communication within the team.
This point, which is far from easy to achieve, serves many aspects of a team.
It helps the team reach better decisions.
It creates better alignment, which reduces problems and time waste, thus increasing velocity.
It enables frequent candid feedback between team members, which helps each of them improve and grow, thus increasing the team's leverage.
Looking at these two conclusions places the manager in a new position. If back in the day, I would have thought that the leader's place was on top of the pyramid, making the decisions and controlling everything; nowadays, I believe the leader's best spot is actually between the team members, forming the "glue" that connects all the members and guides them in the right direction.
A year forward, looking at my team, I have to say that we are on the right track.
Our team is highly diverse and comprises 15 members from Israel, the UK, Russia, Belarus, Bangladesh and one newcomer from Ukraine (celebrating a year in Israel now).
Many of the team's decisions are made by its members, from prioritization through processes to culture. Evidence for that was my recent three-and-a-half week-long vacation, during which the team performed amazingly well as if I was not needed at all (note to self: take long vacations more often).
Open, candid feedback between all members is taking place, much is still to be done in this area, but we are heading in the right direction.
There are still many challenges ahead of us in implementing this culture, and most of this thought process is taken with the team, and soon probably with my new team leads. It seems that each of the factors of this approach requires more analysis as you grow with it. For example, diversity requires more thought about adjusting each member's culture to the team culture.
But I am sure that with the current state of mind combined with the super talent of each team member, we as a team will achieve all that and more.
Top comments (0)