Management for Real Life: An Interview with Technical Director Yashar Rassoulli

Tell me about how you like to setup and build teams here at Myplanet.

We try to set up guardrails to make sure people don’t go flying off the tracks. As Erik [Myplanet’s Creative Director] likes to say, we give people autonomy over execution, but we keep them accountable to the outcomes.


How do you do that?

It could be their own commitments. For example, we have the teams do their own estimation, but we hold them accountable to this. It starts all the way from the beginning of the sales process, not just on the development or design teams. And so that gives everyone context from Day 1 — insight into the project, the client’s expectations — and then helps them understand what they’re going to deliver from the client's perspective.

We try to have individuals accountable to their teams and customers, rather than accountable solely to their manager. By this we mean that the team practices agile principles, such as daily scrums, weekly retrospectives, and weekly tech reviews with the team lead to understand their approach. We [as directors] look at things like the quality process — how they’re measuring accessibility, performance, security — and we use that as a way to radiate the information out to us, rather than making it intrusive, like peering over their shoulder and asking for constant updates on a project.

The idea is we trust that you’re doing the things the way we had planned and give us an update on how progress is going towards that.

The other way we do this would be the competency review model. Every quarter, peers review one other, from hard skills like JavaScript and Drupal, to soft skills like motivation and approach to work. We give everyone the chance to review everyone else that they work with.

We roll these up and then we synthesize this back and deliver it back to that person — so the individual doesn’t see the pieces, they get the overall picture. It gives them the ability to see where they can improve based on themes and feedback from the team as a whole.

This helps eliminate one-off cases or problems from one direct person to another, and allows us to focus on giving feedback related to a trend/theme such that the individual has clear goals for their professional development. Although there is value in resolving individual conflict, we value emphasizing feedback trends and areas of strength more in developing individuals.

From these meetings we create OKRs [Objectives and Key Results] to say, based on the perception of your peers on your competency model let’s decide what you want to focus on, set goals and help hold you accountable to achieving those.

We have a format that we follow, so that everyone across the organization gets the same experience.

Why is that better? Or why do you believe that method is better?

I think it allows the organization to be flexible, especially in a company that experiences fast growth. We can’t commit to anything too long-term as the market is yet to be determined. We don’t have any significant market share, and the future of the market can be influenced by a number of different factors. This can be an advantage compared to a large company: by empowering people this can help people become more innovative and not have to go through the chains of command that can traditionally disempower them. It can also help speed things up, which is a key competitive advantage.

For example, we try to leave it to the individuals to identify the right technology choice based on past precedent and company wide debates we call “tech strategy conversations” where other company experts have shared their opinions.

This flexible approach to technology decisions allows us to onboard people with how we do things much faster than a traditional organizational, but also allows people to understand that they can change things if necessary.

Things here aren’t written in stone. One of the key values we distill during onboarding is that nothing is sacred and that there may be good, bad or no particular reason for decisions we’ve made but that discourse is necessary to clarify that.

How does this influence clients?

All of this leads up to a team that’s empowered to put their best foot forward. Naturally, that’s best for the client because individuals can feel ownership of the results. They take it more personally and more passionately. They have a stronger connection to the work that they’re doing and this allows them to empathize with our clients. This all leads to better results.

Are there any pitfalls with this approach?

Sometimes there’s “less documentation and more human interaction”, as you might say in an agile process. The downside is that if the interactions fail to happen, then people can fail to understand how things are done. So you have to make sure that you have enough touch-points. You have to make sure that when people are on-boarding they’re getting all the touchpoints they need. You’ve got to meet with the directors, all the different team players, others in the organization, so that you know what’s going on today, and what’s going to happen tomorrow based on a vision and strategy.

The other downfall is that sometimes people thrive in environments where you’ve got all your tasks laid out. You’ve got to be more entrepreneurial here. Really entrepreneurial. We put our focus on the direction that individuals are interested in, from a technology perspective yes, but also from a business perspective. We’re not going to use technology that our team is not interested in working with, and we’re not going to go into markets that our teams are not interested in working in.

On a different note, what are some of the technologies that people are interested in?

Although we have experience with a number of proprietary platforms, our teams love open source. Some examples of open source projects we work with include, React, React Native, AngularJS, Node, PHP, PhoneGap, and Drupal. The teams are wanting to use these technologies to provide solutions to clients and problems that they’re seeing in the field, but also to make the collective experience of themselves and their peers better by contributing back to the open source communities.

OK, going back to team structures. Is there a framework that you’ve based these ideas off of?

One of the founding principles early on in the development of Myplanet was Dan Pink’s TED talk on 21st century incentives for knowledge workers. The principles that he mentions there are simple to understand but difficult to implement. Giving people autonomy, mastery, and purpose. When you think about all of your operating principles, core values, reward/recognition mechanisms, and your organizational structure, you need to ask yourself if you’re living true to those principles.

Are there any other points you think are worth mentioning?

One thing that I learned early in my career as a technologist was to take a moment and think about a company that you’re joining and try to understand the value they place on the opinions of the makers, the engineers, designers, etc. in the business process.

How do you tell? See if they have the same amount of decision making authority. For example, if you think about the traditional West Coast vs East Coast business stereotypes, on the West Coast, the engineers and designers of a successful company are the ones who are defining the purpose, the process, and what the sales and marketing teams ultimately sell, whereas on the East Coast, on Wall Street, the developers and designers are there to fulfill the needs of the trader. Neither one is better than the other, but they’ll be different companies in terms of management styles, values, and importance they place on the well-being of the engineering and design teams.

Here we try to have a balance. Our sales and marketing team will influence what we engineer and design, but the makers also strongly influence what we can do, the solutions we create, and even who we sell too.

Written by

Cahill Puil

Cahill Puil

Sign up for our newsletter