For a long time, we explored and advanced efforts to create an internal development department so that an education company could become an education x internet venture. We have accumulated knowledge through these five years of work, so I decided to summarize it.

As a preface, these efforts were not something I advanced alone. They were tackled by the whole company as a team. I hope you will keep that in mind.

This will be a little long, so here is the outline.

1. Contract development
2. A student engineer training course
3. Training a foreign employee as an engineer
4. Becoming CTO and hiring engineers
5. Changing the organizational structure
6. Introducing 1 on 1s
7. The HackDay effort
8. Hiring the third engineer
9. Moving toward organization building

1. Contract development

Around five years ago, in 2012, I heard from the president about something he wanted to build. At the time I was a beginning freelance engineer, and I accepted immediately. I designed and developed a system to improve the mechanism for providing daily lessons.

The company did not have experience ordering systems as an organization. It had worked with partner companies on website production and marketing, so we could not define requirements strictly. But by using the hearing techniques I had cultivated through my own experience as a director and a freelancer, we were able to release the system successfully.

At the same time, I developed compound problem-solving ability beyond just building the system, including preparing hardware, charging devices, and setting up the internal network. What I kept in mind was not saying that something could not be done. I moved things forward in the form of: it can be done, but these things are necessary.

In internet service development, I had often experienced releasing something and seeing no reaction. I remember being very excited that this system started being used right in front of me from the moment it was released. Even now, I think being able to have this experience is the real pleasure of a hybrid company like “something x internet.”

Looking back, this was a period when the president was the central engine moving the organization, while I struggled alone with development. There were people who gave me advice, but launching was the highest priority in everything.

2. Engineer training course

I continued maintenance and improvements alone, but the president began telling me about a plan to organize engineers. By chance, I was running a programming school through another job, so I received the suggestion that we try training engineers, and we actually started moving.

We still do this effort, and this year is the fifth term. We mainly provide free programming classes for part-time student staff. We have continued improving this course, and it has become quite good.

On the other hand, training engineers is not that easy, and it takes time for someone to become fully capable. Running the course while doing development was hard from the standpoint of balancing both, but as I will write later, I think it was good that we did not give up and kept continuing this long-term effort.

What I consciously did in order to keep going was to build solid consensus that the results of an engineer training course take time.

3. Training a foreign employee as an engineer

This was also proposed by the president as an effort that seemed likely to have immediate effect. Inside the company there was another business unit as a separate organization, and there was a foreign teacher there. He already had a decent background, so perhaps he could be trained. Of course, he also wanted to change roles from teacher to engineer.

As an organization, we were in the period of moving from CakePHP to Ruby on Rails, so we advanced new Rails development, including learning-oriented prototyping. There were difficulties such as language issues and geographic issues, since our offices were different and we did not see each other every day, but we were able to reach release successfully.

For these issues, what I continued doing, though I still do not know whether it was correct, was to keep communicating my own passion for the system we were building. I think it helped that I understood the loneliness of building a system during the contract-development period.

Unfortunately, though I am half happy about it, once he gained engineering ability he wanted to try freelancing. There was also an organizational change to concentrate the business, so we no longer work together.

Today the organization is centered on Japanese, but if we build a global team someday, I would like to reach out to him again. It is still hard to part from someone you worked with for a long time.

The major lessons were the difficulty of management and the importance of business growth. At the time, development tasks were ticketed in Redmine, but I do not think I managed motivation well. There was no mechanism for the ideal state of self-motivation. If we had had that, he might not have left.

More important than that, the business must be growing. If the business is not growing, continuity is impossible. This was an experience that made that severity sink into my bones.

4. Becoming CTO and hiring engineers

Some of this overlaps with the events above, but around four years ago, in April 2013, I received a proposal to become a director. At the same time, hiring an engineer had been decided. So while continuing development, my mission became seriously building a development organization.

My situation was that while advancing the things above, I had started finding them interesting, and I had also run out of time, so I was already almost fully committed. Therefore, I had no resistance to quitting freelance work and committing fully.

There were endless reasons to join the team: the limits of what one person can do, the dynamism of working as a team, the merit of already having a real business, sympathy with the mission and vision of the place I was joining, and so on.

(Whether to freelance or work in an organization ultimately depends greatly on an individual’s values and style, but I think organizations are better for me.)

At this time, organization building had clearly become my mission, but honestly I had no experience and did not know what to do. On the other hand, from previous experience I had learned that even with inexperienced things, trying them moves you forward. So I valued trying things without fearing failure or friction.

5. Changing the organizational structure

The first thing I started working on was changing the organizational structure so engineers could focus on development as much as possible. Even now the organization is not that large, and there are benefits to knowing many kinds of work, so engineers sometimes experience many duties. But we changed the organization so that routine work would be concentrated on development.

The organization was also just starting to grow, so not only engineers but other teams also changed rules to shift away from everyone playing every position. The result still has many incomplete parts and needs continuous improvement, but I think the organizational structure became proper.

This may be obvious in IT companies, but we advanced an environment where work is less likely to be interrupted, while considering the characteristics of the engineering role.

There are reflections here too. One is that the speed was insufficient. Another is that we advanced with systems first. Regarding speed, because this work happened while developing, including launching new services, I treated it as a subproject. But for the people involved, it was something they felt in daily work. I think there was a gap in temperature around that.

During this transition, someone pointed out that they wanted us to proceed culture-first, not system-first. Instead of suddenly creating a system, first permeate the culture and then create the system. Create the accomplished fact first. That often works better. Not knowing this produced unnecessary friction.

6. Introducing 1 on 1s

What I introduced while reflecting on these things was 1 on 1s: opportunities to listen. When I was deeply troubled by the issues above, 1 on 1s were just starting to become a topic around the internet, and I decided to implement them almost as something to cling to.

At the same time, raising engineers from an intermediate level to an advanced level was something I personally wanted to do. As a result, I feel it has been quite effective. If you are wondering whether to implement them, I recommend trying. If they do not fit, you can just stop, so I think there is almost no downside.

Something that was personally positive in a separate way was that repeating 1 on 1s helped me study how to listen. More than anything, I understood as a real feeling that the answer is inside the other person. Because of that, I think I became able to facilitate meetings more efficiently than before.

As a reflection, I think I should also have done the organization-building effort I write about at the end together with this.

7. The HackDay effort

Before organization building, one output of 1 on 1s was HackDay. It was proposed during 1 on 1s. Engineers value daily work, but they do not have opportunities to take inventory.

As a secondary effect, I also thought it could target the improvement of engineer level, which I personally saw as an issue. So once a month, we began an effort where everyone takes about eight hours, starts from brainstorming, and holds a hackathon for inventory work.

This continues to the present, and it is now linked with 1 on 1s as well.

8. Hiring the third engineer

One more inserted topic. Hiring from the engineer training course bore fruit in July 2016. It may have taken too long, but because we had worked together for a long time and trust already existed among the members, it became the best hire.

At that time, I strongly recognized that hiring is my job. While being entrusted with building a product, deciding what kind of people I want to work with and preparing the necessary environment for that are naturally part of the mission.

Now we are looking for a fourth member and beyond. I will be the first to listen, so if you are interested, please feel free to contact us from below.

日本の英語教育を変える✨サービスを作れるエンジニア募集！ by 株式会社キャタル _Career at 株式会社キャタル. キャタルでは日本の英語教育の問題を解決したいエンジニアを募集しています。 エンジニアチームは現在3人ですので、機動的に動くことが求められます。企画や要件定義もエンジニアの業務範囲に入ります。チ…_www.wantedly.com

インターネット❌教育サービスのプロダクトマネージャー募集！ by 株式会社キャタル _Career at 株式会社キャタル. 教育❌インターネットサービスのプロダクトマネージャー募集！ PM職の方にはどのような問題を解決するの定義すること、またその改善を指数化して計測可能にすることが求めれれます。また、実際に物を作る…_www.wantedly.com

プロトタイプ制作からUI/UXデザインまで幅広く活躍するデザイナー募集！ by 株式会社キャタル _Career at 株式会社キャタル. プロトタイプかUIデザインまで幅広く活躍するデザイナー募集！ エンジニアと一体となってサービスの改善を行っていただきます。また、新しく機能を開発する際のプロタイプの製作なども行っていただきたい…_www.wantedly.com

9. Moving toward organization building

We have built the team this way, but I was worrying about the organization every day. I also worry daily about product and strategy, but the questions were whether the team was focused on what it should do and whether performance was being maximized.

Because I had successful experiences with 1 on 1s, I studied and practiced ideas such as what it means for a team to function, psychological safety, and Motivation 3.0. I was trying hard, but I could not feel confident that things were going well.

Recently, however, I realized there was something we should have done before all that: create mechanisms to properly understand the progress of each project, and define expected roles and the outputs expected there.

(The important thing is not to understand projects, but to create a mechanism that allows projects to be understood.)

In the end, facing the product is what matters, but we could not get out of people problems, and we were not doing the obvious things we should have done.

An example of the problems that come from this is that when a new member joins, the discussion becomes which team to put them on, not what to entrust to them. Which team they join is important, but what they do should be even more important.

The reason the discussion does not become that is that there is no definition of expected roles and outputs. If there were definitions, the team they join would be decided naturally, and we should be able to go directly into the discussion of what they will do.

I should have noticed this earlier. Yes.

So recently I have been exploring things like this. Perhaps even things that are going well now may stop going well.

These are days of struggling in every direction, but we are looking for members who will help us build mechanisms and build services together. It may be faster to create an environment that suits you than to search for one. More than anything, it is fun. If you are interested, please do reach out.