(The editor’s note: This post was originally published by Koichiro Sumi, CEO of Sider on our tech blog(http://tech.sideci.com/entry/2016/05/25/110000), and edited and translated from Japanese to English. )
Hi! I’m Koichiro Sumi, the CEO of Sider, Inc. Sider is one of few Japan-based companies which provide automated code review service, Sider, for engineers. It is run by people with programming backgrounds.
In this post, I’m going to show you how I organize and manage my company.
Engineer to CEO: Change of Roles
I get a lot of questions regarding my title as Engineer and CEO of Sider. Here, I have answers for a few of the frequently asked questions.
“Don’t you feel the urge to code as a former engineer?”
Of course, I feel the urge to code sometimes. But I haven’t had time to code. Also, I try not to code.
You can see the difference in my contribution on GitHub in May 2016 and May 2018 below.
“Don’t you miss coding? Do you think your coding skill is getting rusty?”
Sure, I miss coding. I also feel I’m losing my touch.
But this is a choice I made in my life, and I think that not coding is the best choice for my current career path.
“Do you have the urge to give suggestions for what your team is coding?”
Of course, I do. But I no longer interject when the project is in the designing or implementation phase.
It is not my role anymore.
What a Former Engineer Does as the Leader of a Company
1. Let Development Team Make Decisions on Development
We are trying to build an organization where an individual can be independent and actively put our effort to maintain our autonomy. It is necessary to work voluntarily and independently to achieve this goal.
I thought it was not ideal for an organization to have its CEO as the top of the development team. Of course, it is not ideal to have top-down management where an engineer is the top of its development team. I strive to build a flat organizational structure.
What if we have a conflict in design? What if we have disputes in selecting technology? What if we cannot agree on language selection?
If the CEOs interject in those situations, the CEOs, who should be the last one to make decisions, resolves these minor conflicts, and it becomes clear that they are responsible for the decisions.
By having the CEO as the decision-maker and knowing who is responsible, the speed of decision-making and development might get fast temporarily. But the CEO will be the bottleneck of the organization because he is the only one to make decisions for the company.
The bottleneck determines the organization’s throughput as mentioned in The Goal by Eliyahu M. Goldratt several times. Without managing the bottleneck, the overall throughput will not improve. Therefore, it is necessary to remove the bottleneck, having to get CEO’s decision, from the development team.
It is better to let the development team make decisions on development. Even though I am Engineer and CEO, I shouldn’t be involved in development-related decision-making.
2. Secure with Quantification and Structure
As a business management/sales team, we want zero bugs when considering the stability of the system and the rate of bugs. It is not wrong to pursue that.
However, unexpected troubles and bugs happen in the development process. I try not to say “Improve the system stability” or “I feel the system gets buggy quite often. Reduce bugs to as close to zero as possible!”
Instead, we quantify the number of bugs, the stability, and the system downtime. Then, the business team (which is me) and the development team discuss and decide on the permissible number.
An example of Slack’s daily post on the number of errors and other KPIs
By quantifying how much we can permit errors, the engineers don’t have to use too much time on fixing every bug. Also, if the number of bugs increases, the development team will voluntarily solve the problems. This allows the business team to focus on just business.
This also helps to build an independent and flat organization.
First, we create a structure to quantify what we want to secure as a service.
Then, the development team will voluntarily work to maintain the permissible number of errors.
3. Don’t Estimate Person-Hours.
I heard someone was saying “My manager doesn’t know how to estimate person-hours and demands for something ridiculous because he doesn’t have an engineering background.”
Although I’m the CEO of Sider, I was an engineer and was in charge of the initial development of the Sider service. For that reason, I can calculate person-hours to some extent. Maybe, I can figure out more precise estimates.
But I try not to make estimates for person-hours.
I think it is vital for building a flat management structure. If the CEO and the business management team made an estimate, schedule it, and ask the development team what to do, the whole production might get slower than initially planned because the development team would end up fixing and adding different features according to the new schedule. When a schedule is given, people naturally follow that. On the other hand, when the person-hour estimate is too short, it would put pressure on the development team.
Predicting person-hours is quite tricky. Even though I have an engineering background, it is hard to make a precise estimate since I am no longer in the field. It gets harder and harder as time goes by.
By choosing not to calculate the person-hours, I encourage my development team to estimate the person-hours by themselves and adjust the schedule as the work progresses. I value and promote that kind of independent working style.
Should/Will I go back to coding?
To grow the service of Sider, I have many things to do other than coding. We are not in the process of building other teams, so, I am the only one to take care of other tasks and need to prioritize them more than coding. If I could make the organization grow organically, I might start coding again.
Of course, the productivity of someone who had been constantly coding would be way higher than someone who left the engineering field and worked as the CEO of a company for a while.
What’s the Plan?
I wrote this post as if everything was going perfectly, but I will continue to improve Sider.
Also, when I wrote this post back in 2016, Sider team had only a handful of members. Now, in 2018, we hired more staff for design and marketing, and Sider will continue to grow. My goal is to scale up our team while keeping the flat structure of this organization.
For more information about Sider, please go to our website.