Different Approaches to Managing My Growing Team

I have three new designers showing up in the next few weeks bringing my team at Treasure Data to 7. Generally, I feel that doing 1:1 development of an employee takes time and trying to accomplish that for more than 5 people once is difficult. So I am faced with choices of how to structure the group.

For reference, I managed a diverse team of about a dozen (including PM, UX, Docs, and PMM) at the height of my Marketo tenure and smaller teams throughout my career. I try to maintain some of my time dedicated to design work, but as expected, when you manage alot of people you don’t have large blocks of time to design.

I’ve been thinking about how I want to manage this growing team and what kind of employees to keep adding. Here are some thoughts with pros and cons:

The Detached Guru

I’ve experienced this kind of management myself. I could rise above the fray and just make sure the people are happy and growing. I would give principles and north-stars, but not the details. This gives maximum responsibility to the team to self-organize, prioritize, and execute.

The upside of this approach is that senior people feel that they can run free without constraint. They feel delegated to and that makes them happy. However, it can also feel chaotic, especially if the team members have different visions of the details. This only works if the team is talented AND really get along together. In those cases, it’s actually pretty great.

Junior people will often get themselves into trouble because they just don’t know what they don’t know. Sometimes, being thrown into the deep end builds character. Other times it just creates a losing situation where people feel ineffective and insecure.

I don’t love being in this role because I take such direct responsibility for the design outcomes. I don’t want to say, “Well, I let my team do it and they didn’t do a good job.” Ultimately, I am more hands-on.

The Dictator

On the other side of the spectrum is the micro-manager. This is the opposite of the Guru. In this model, I would descend into the particulars. I would get into the details of every project with every employee. Every interaction could be reviewed. This gives the least amount of power to the team to organize, prioritize, and execute.

I have had CEOs before who worked this way and the truth is that it can be somewhat freeing. It sounds bad at first blush, but a dictator can let you ignore many of the fringe elements of the job and just focus on execution. It’s often the endless exploration that ties up designers. We can explore until the cows come home but sometimes we just need to execute. Additionally, this model can often perform quicker with more unison that other models since there is a singular vision in charge.

However, most people don’t want to work this way all of the time. A dictator takes away your personal agency and doesn’t let you bloom. How are you going to learn if you aren’t able to make decisions and mistakes along the way? We learn by doing and by reviewing what happened. We learn by experience. A dictator really limits team growth, plus it generally doesn’t feel good to most people.

The Architect-Coach

I’ve been trying to think of a phrase that captures what I attempt to do. On the one hand, I want to maintain a single point of approval/sign-off on the specific designs. The reason I want to do this is because I am much more detailed that all of the designers I have ever hired. I think I learned this trait from Phil Fernandez (Marketo CEO) who would find every flaw in a design with incredible accuracy. I honestly don’t do it as well as Phil, but I try. In the end, someone needs to hold the line on quality and consistency. If I meet a designer who does it as well as me, I will gladly delegate. Please email me for a job if you think you are that person.

On the other hand, I need to delegate responsibility and create an environment for people to make mistakes and learn. I don’t want to be the dictator all of the time. So I try to wear the coach/mentor hat whenever possible. I find tremendous enjoyment when I see a designer grow and become better. When I can personally help them on that path, I feel a sense of pride and accomplishment.

The Architect-Coach requires alot of context switching. This is difficult, but well suited to me since I can switch fairly quickly.


I think it all depends on the people you have on the team. Some people are more suited to delegation than others. Some people want specific direction and others want more “north star”. Different people have different skills. I need to adapt and make each person successful in their own way. Generally, I love designing, but building a team/coaching has its own rewards.

One other thought, my success metrics are:

  1. At the 1 year anniversary of each employee, if I could go back in time, would I tell my younger self to hire or not? So far, I am batting about .500. Good for baseball. Not sure for work. What’s your percentage?
  2. Is there tangible evidence that the team is respected and credited with helping the overall mission/vision of the company? Is my team considered essential?
  3. Lastly, regrettable turnover. Do I lose people whom I wanted to keep?

It’s useful to have metrics for yourself as a manager and to think about your style. Feedback welcome.