There is no trust without delegated authority – Northfork’s CTO on growing self-managed teams

The CTO vs Status Quo series is about drawing attention to how CTOs challenge the current state of affairs in the company to push the business towards new heights … or to save it from doom.

Great changes require evolution — not revolution

One way to challenge the status quo is to give your developers more power to decide how and (even what!) they want to build. There’s a name for that – a self-managed team.

The newly appointed CTO of Northfork, Majid Garmaroudi, believes that when implemented correctly, a self managing team makes for more efficient and creative individuals.

What’s more, a successful self managed team makes for happier employees and leaders.

Majid will reveal:

• how he ensures his entire team is willing and able to come up with their ideas,
• why he lets his developers roast him in retros and one-on-one sessions,
• the questions he asks developers who underperform.

Doing all that seems like a lot, but Majid believes that you can implement the greatest of changes if you go at it one step at a time.

About Majid

Northfork’s Majid Garmaroudi presents the self-driven team model

Jakub Piłucki: Hello Majid. You’ve recently become VP of Technology at Northfork – congrats! You’ve got an interesting product that allows users to buy products easily with the use of shoppable recipe technology for e-commerce sites or culinary blogs. It seems that a product like this is quite volatile in that each new implementation is different (like the one you’re now doing for Coles in Australia) and market trends can affect the adoption.

While I joined recently, Northfork has been growing for 10 years. So it’s not a novelty. We are the engine behind grocery providers such as Coles, but also Walmart or Target.

By running our script on their page, content owners let us get item quantity so we can calculate the price and enable a recipe the user can directly buy products for.

It does seem like a product with a narrow focus, like something that would come and go depending on market trends. At least that’s what I felt at first, moving from a big product. But in reality, it does a very needed job smoothly.

It brings more traffic and sales to the retailer, while also providing something attractive to the customers. Because it’s really fun to buy products for a particular recipe at the click of a button.

Still, there are challenges. Every retailer has their own needs and different customer journeys. Some run recipe-based content of their own.

The case for a self-driven development team

I heard that self-driven teams may be the answer you chose to tackle these challenges.

When I was still at Pocketlaw, I had a chance to build something from scratch for the first time. I tried to come up with a viable vision for the product. Before I get to that, I need to go back even further; back to when I worked on my master’s degree.

At the university, we discussed software quality. A representative from Volvo showed up to talk about how essential it is to work iteratively. Without iteration, you can never be good, he said. You develop your architecture this way, set up a hierarchy like this, he said.

I raised my hand and said that there was this company called Valve and they had a self-driven team and a flat team structure. They didn’t work iteratively – they took five years to develop a product before they showed anything. And yet they were very successful. He couldn’t tell me why it was the case.

I couldn’t replicate Valve’s approach, because we didn’t have enough money. We needed to be more iterative and Agile so that we could release something quickly, to get customers and investors interested.

I wondered if I could combine these approaches – being both self-driven and Agile to make MVPs, release often, and find the product-market fit over time. Our idea was big, but our team was small. If we were to succeed, I needed them to be creative and self-reliant without my constant supervision.

Is this what you mean by a self-driven team?

What I mean is that leaders in self-driven teams are NOT absolute. We are replaceable.

It’s human nature to think: I am needed. That’s the opposite of what I want to do. I want to be sure that if a bus hits me, everything will be fine at the company. There is another person, a plan B, and then a plan C. My team has all the necessary knowledge, login access, and learning materials to keep work going.

In short, the definition of it is that there is no need for constant leadership control to deliver value. There is no need to bring ideas to the team constantly. They can come up with their own ideas and there are processes in place to help overcome any challenge and make sense of everything.

Can you share some stories that could show us how you grow a team like this in practice?

I’ll start with hiring.

The first person I hired became our head of engineering later on. I told him: I want you to come and work with me – not for me. Simple as that. The wording meant that I wanted to rely on him to tell me what I did wrong. I would do the same for him.

I’m a big fan of direct-feedback culture. When a company is established, it’s hard to introduce it – there are already a lot of bad practices and processes in place. But I was able to start from scratch.

For example, I told each new hiree: if you have a conflict with somebody, don’t approach me about it – approach them. From day one, I didn’t try to be a proxy who stopped two adult people from fighting with each other. I extend the same behavior to all processes and product decisions.

In retros, any Agile team will put several columns: things to improve, what has been good, what has been bad, and then a kudos section. I only left the first two columns. I got rid of the emphasis on the bad. I removed the mentality of negativity about work.

By the way, I made all these decisions with the team, not individually. So I never tried to act as a dictator.

Managers or leaders think their teams need a strong leader. No. People need a CTO who is reliable, predictable, and a guide to best practices.

Do you think that people benefit from being part of a self-driven team?

Just about anyone will benefit as long as the manager will take into consideration their personality.

People are different. Some just want to be given a task. Another will say: give me an approximation, I’ll want to discover everything myself. The same shoes don’t fit everyone’s feet. That’s why a good system is self-sufficient rather than dependent on any individual.

Every time we hire, I want the team to understand that each new person who joins the team is going to change it. The new people are going to bring their ideas and they shouldn’t be shut down just because they are new. This approach helps the team stay fresh and change for the better.

Challenges of self-driven teams

I’d like to address some challenges that typically arise for people who try to make the switch to a self-driven team. Perhaps you helped organizations overcome them in the past. 

Let’s start with the idea of letting go of power. The CTO seems to have to share a lot of their decision-making. Isn’t it hard to do for some people?

You know, I’ve been lucky to try all kinds of technologies in my life. I did Pascal and Assembly. Then I learned web technologies, both backend and frontend, some mobile development, infrastructure, and cloud.

But one person can’t know everything. If your knowledge is broad, it’s also shallow. That’s why I wanted to have a system in which I am not the sole decision-maker.

Pink Floyd said: “Together we stand; divided we fall”. I always tell everyone: as an individual, we know little; as a group, we know everything. Together, we have so much knowledge and potential. Let’s use it.

But the challenge was to communicate this outside of the tech department. Sometimes, the work is going great within the tech team, everyone is busy, and then the business comes and says that we need to release it right now. I can’t do it. Everything has to go through the process, be evaluated, and discussed. Everyone needs to express their opinion. We go for it when everyone feels good about it.

Each side, business, and tech, has its language. As a CTO, you’re going to have to speak both. You are kind of in the middle.

This took a lot out of me: to be a shield between the business and the tech, to be a translator of business to tech and tech to business. The latter is especially underestimated by many organizations, I think.

It seems that communication is crucial then. The project knowledge has to flow in all directions rather than from the top down. How to ensure that when there is no constant control or supervision?

During my entire career, I have never seen a team fail for any other reason than communication.

We’ve had our fair share of failures in communication. As much as I tried to communicate from the top to bottom, many times I failed to communicate from the bottom to the top.

Take a big company with a lot of different domain experts. You have salespeople; you have the marketing department; you have the customer success department, then you have a CEO, and the tech team. And then there is the product.

If a tech person talks about upgrading React to version 18 and says: I’ve been working on it for 2 weeks – a salesperson doesn’t understand it and doesn’t see any value in it. They just want the feature to be available so that they can sell it. We all have different skills and different needs. But people can accept these different needs when there are no surprises when they are kept in the loop.

What we did was that we introduced different demo sessions with a very well-prepared agenda and focused a lot on the roadmap.

Let’s say there’s a feature you want to see done. You know that it’s on a roadmap and it’s going to start development in a month and take about two months to complete. That means that it should be done in 3 months. At the same time, we’ll also promise to give updates every two weeks. When the tech team decides that, say, the authentication server has an issue and it will take an additional month to solve, the sooner you know that, the better it is for everyone.

My last argument leads me to accountability. Since self-driven teams work as a single unit, individuals are not as accountable as in traditional teams. Was it ever a problem for you in terms of productivity?

Here in Sweden, we have this six-month provision period when someone starts, during which we can terminate their contract very fast. I take that period very seriously to figure out the skill set of an individual. Once I do commit to someone for the long term, they have my trust. I know that they will do well at that point.

Because if you bring somebody, this person will have to show whether they can survive in these very self-driven teams or not. They have no choice but to work out issues between each other: :”Hey, what happened to that ticket?”. I work a lot in a culture in which nobody takes anything too personally because I let them roast me first.

For a long time, I’ve been the main source of getting roasted in retros. They would come to me and say: why did we release it on that day, we weren’t ready! Or they would tell me: Majid, you should stop asking that! I said: Understood, message received. I’m not going to do that. 

That’s how I make sure that the top management leads by example. Others take notes and do the same.

How to lead a self-driven team?

In a switch to a self-driven team, the CTO that tries to make it happen may end up being their own worst enemy. They might think that it is a good idea, but they might have a problem eliminating that urge to micromanage…

What is micromanaging really? Micromanaging is when somebody goes too deep.

Again, it starts with trust. As a leader, you want to ensure the direction for development is correct, and that features will release on time. But CTOs who micromanage don’t trust their team. They say: “Hey, did you move this ticket? Did you remember to do that? We need to have those things in it”.

If you ask these questions as a leader, it means that you don’t trust your team. Consequently, the team doesn’t trust you.

The mistakes are typical, especially for those who only recently became CTOs and still feel like programmers. When I switched from coding to being a leader, I struggled with that too.

Of course, that doesn’t mean that you should stop looking at the APIs.

You need to know what’s going on, but you should focus on global issues. Do they have a culture fit issue? Do we need to change something? You need to keep tabs on everything, but you don’t need to be everything. You don’t need to talk much. Finding that balance is going to be your job as a new CTO.

You need to take it seriously. Because if you do your LinkedIn research, you will find out that many programmer-to-CTO converts burn out very fast. They do so because they failed to switch their perspective from a low to a high-level overview. They do too much. So they become overwhelmed.

Stephen Covey, the author of many popular self-help books, said that you can’t hold people responsible for results if you supervise their methods. A self-driven team seems to put the idea into action. Speaking of practice, what does it mean to leave methods to the team?

Good question, because I think a leader has to read psychological books.

Salespeople are good at decoding human desire — to get you to sign a contract. But to most tech people, it doesn’t come so naturally. They are interested in technology. It’s the language they speak. But they need to learn how and why people behave the way they do to get past their issues.

We react to and lead because of our style. If we have darker parts of our childhood in the way we’ve been treated, we’re going to pass that down to these people. Because now we are in a power position.

I really like the scene from The Matrix in which Neo enters the room and the architect is sitting there with all the monitors around him. I see myself as him. The person who keeps track of everything but you don’t know he’s there.

I just want to open Slack, the email, and the API, and I see that everything is going well. Then I feel: okay, maybe I can suggest this one thing to my team or maybe I can move these two people between the teams and see if knowhow would be shared better. Perhaps I can do a small experiment, or suggest an idea that came to my mind, without forcing it on them, of course, without trying to control them.

Controlling people has a long history. We have so many industries where the whole purpose is to perpetuate an environment in which people do repetitive tasks without thinking. But I treat developers as artists who are sensitive and protective of their creations. Sometimes they get offended. They may be moody. They are often very sharp talkers, even when they look shy. As a team leader in a self-driven team, instead of controlling them, you’re going to have to face them and challenge them, in a way.

Building a self-driven team – the process

I think by now some people may be interested in building a self-driven team. Let’s help them. What needs to change? What are some processes worth introducing right from the get-go?

You should never introduce something big immediately.

That’s how I do things at Northfork. In the first 3 weeks, I didn’t touch anything, but I was in every meeting, observing or taking notes. I also had several thinking sessions. I sat down and thought: okay, where are the lowest-hanging fruits I can start with? Who should I talk to?

Because any big change means you decided to force something on people. Change is always gradual. The big change is not something you want to implement unless you are doing something very badly. Incremental improvements help people feel they own these changes. They also better understand them and have enough time to reflect on them.

So instead of doing something big, think about entry points, the smallest things. And don’t see it as a process, see it as teaching. No process is a solution because if it was, I think then each team that uses Scrum would be perfect.

Processes are simply about learning and developing good practices. Introduce them at the beginning. But as the team gets used to it, remove them. And then the team will feel they’ve been rewarded, they’ve been trusted since you introduced the processes because you didn’t know if the team could handle itself.

For example: how to make standups self-driven and short? I wanted to make sure that I didn’t need to be there for the standups to go well. First, I led a couple of standups. I said: guys, let’s test something. I’m going to lead this standup. Just ask short questions and if somebody talks too much, I’m going to stop them.

After two weeks, they learned the scheme and then came the second sprint. I said: I no longer lead the standup. Now, whoever comes last should be the first one to talk. The next time I said: now the last person should do the job.

In three sprints, we switched from a traditional meeting centered around the Scrum master to a meeting where everyone tries to come on time and be active on their own.

I was going to ask you if you are still joining standups.

Yes, and I love them. I want people to see that I do. If something is annoying, I’m there to help. If they are working late, I will be there with them. 

It’s a lot of work for me. But I make sure they know that we are in this together. I’m not going to just leave them and go home. Like I said before, you need to lead by example.

Many would also like to know how a self-managed team is structured. Is there even some particular structure?

Again, It depends on what people want it to be

If they want to manage 20 people in a single team, it’s their call. If they want to have five smaller teams, four people each, they are free to go for it. If they want to have teams specialized in specific domains, they can do that. But if they want members to move freely between one project team and another, they can do that too.

I’m just going to ask them: “What can I do to help you?”.

It almost seems like those teams run a company on their own.

Some could say it. But I don’t think it’s a good way of putting this.

Because if they were the entire company, then they would have their product, their cases, their budget, and everything. No, I’m controlling those things, but I let them do their work as they please.

Are there any tools that are especially useful for self-driven teams?

The issue with tools is the same as it is with the structure: what’s the purpose of them?

At Pocketlaw, we used Trello. It was cheap and free. We were a startup, so why not?

But the organization has grown now and we had different boards for different teams. I felt like I didn’t have the best visibility of all the work. Trello is a fairly basic tool. At least it was basic five years ago.

I told the guys: do you want to switch to Jira? They said no. I said: okay if you don’t want to use it, it’s fine.

Then I started to lobby. As a leader, you need to lobby a lot. That’s how democracy works in the Western world.

I lobbied with people who were interested in Jira. They told me: I like Jira. I waited two months and I brought the subject up again to that one specific team that I knew had a lot of Jira supporters.

Then we discussed that further. Because I do not believe in a majority vote. I believe everyone should commit to an idea. 51% is a very wrong way to decide because you have 49% who are not happy.

Even if there is one person unhappy, it’s a good idea to set up an action to make that person happy by reviewing this person’s criticism.

There was also the issue of documentation. Some wanted it to be on Google Drive, but some wanted it on GitHub. We negotiated and agreed that pure tech stuff would be on GitHub, while the rest would be on Google Drive.

What’s next? I assume that introducing such a culture takes some coaching and on-the-job mentoring.

In almost every job I had, my boss or my manager had one-on-ones with me. It was like a performance review. I changed that.

Because a performance review is something you have when you don’t trust somebody. You hired people that shouldn’t be there. And then you want to performance-pressure them.

I set up a one-on-one, two-way feedback meeting. I say: “Hey, you’re doing great things. I hope you can improve on that and that”. My developers need to feedback my performance, which helps them to open up.

When my previous organization grew, I always told the managers that you need to know how coworkers feel. Are they in a good mood? If they aren’t, why is it the case? Do they have a family issue? What’s happening? Is there anything wrong at home? Do you have any challenges at work? Be sure you take care of them. You need to ensure that they are at their best.

Your job is not to make them deliver the most. No, they are going to deliver the most when they are at their best.

We already evaluated them. We know they have the technical skills. They just need to be in the right mindset to perform.

A two-way communication like this seems to require a lot of attention from the leader. I was wondering if all of that can be done in a large organization. Are there some limitations in terms of the company size if you want to do self-managed teams?

To be honest, I have yet to experience a truly large scale. I’ve done this to a maximum of 30 people in a tech department, comprising four teams.

Cross-team communication is challenging. What’s the right way to do it?

For example, if you work on a team level, you know you have two teams. If you want them to continue being self-driven, give them both leaders and let them negotiate how they want to work. I cannot sit there with them all the time. You want to encourage developers to debate and find a solution with your guidance rather than decide for them.

Large organizations in particular need to do a lot of cultural changes. The top management needs to accept the idea of delegating power, not just tasks, and providing the trust their workers need.

At what point can a CTO tell that their self-driven tech department has matured?

You can feel the energy. When you look at the Slack channel or Google Hangout, you can see their energy is different.

In my last job, we had a meme of the day. You know how much fun they have when a person spends time creating a meme about their work. I remember when they used the Star Wars format. They made me Darth Vader and their product manager was Luke Skywalker.

You know they are high energy when they are willing to share their movements with other people in the team.

Another team of mine had sprint planning sessions on Tuesdays. They would tell us that we want to have pre-sprint planning internally with the team the day before. Can we get the epics we want to work on sooner? Great.

They discussed everything, planned their sprint, and talked to each other about how they wanted to approach the sprint and it was completely self-driven. I didn’t need to interfere. When we went to the actual sprint planning, they already had everything ready.

And then, there is also a lot of passion. You see the tickets moving at peak speed. They like writing and documenting stuff. That means they care. And when they care, your job is done. You just can sit back and chill.

Further reading & resources

Can you recommend some books or courses that could save one a lot of time on their journey to an efficient self-driven team?

Find your way. Books are great, but they don’t have ready-made solutions for you.

I’ve always been fascinated with tech leadership.

I started reading the book that the co-founders of Google wrote. I read two chapters of it and I dropped it. That’s because I already knew what they were going to do. I knew how they thought the tech should be. They understood the need for self-driven teams early on.

Their search engine had an issue and instead of going to the search team with it, they just printed out the examples of the issue and put them up on a wall. Then people from other departments, who knew little about programming, looked at them. They spent the whole night on it and eventually implemented an idea that revolutionized a big part of the Google engine.

You never know where the next great idea is going to come from. That’s how I feel you need to think about leadership.

What’s next? 3 actions for CTOs to take

What do you think about Majid’s approach to growing successful self managed teams? Do you want to adapt it to the needs of your organization?

Build self managed teams full of people willing and able to take on any issue by:

1. Be a stable leader – one that serves each team member and uplifts them
2. Think about processes only as a means to an end, which is self management
3. Lead by example – when they see you do something, they will do likewise

Remember, the change is a process, but you need to take the first step.

About Northfork

Northfork makes content shoppable across any platform, simplifying the path to making a purchase and providing engaging content to users at the same time. The solution combines personalized recipe content, translating ingredients to products, and enabling brand promotion.