From developing apps to evangelizing about them
What was your career like before joining Quipper?
My first job was with a major foreign-backed system integration firm. I was assigned to the group developing internal Web applications and frameworks for the company, and I developed those frameworks, peripheral tools, and code generators and editor plugins. Just creating an app is no good: you have to have a userbase. So I took part as a specialist in the teams that would actually be using these tools throughout the organization, customized them for their needs, and conducted training. I then gradually became involved in the development and launch of one of the company’s services, as well as its ongoing refinement. This process gave me the experience I needed to transition to a job at a company developing portal sites for the healthcare industry.
What was it like after changing jobs?
In terms of scope, I went from a company of 20,000 people to one with 100. At a system integrator, there’s a design phase, a consulting phase, and a coding phase, with each step handled by someone else. At my new job, everything from defining requirements to development and launch was handled by the same person, so the way I worked changed considerably.
What made you join Quipper?
The work I did at the second company was all on-premises at that time. I had started to take an interest in the cloud and was experimenting with it, but the company wasn’t too keen on it, so I wanted a new challenge. I happened to see a Facebook ad for a startup doing interesting things with education in the cloud space, so I contacted them.
A desire to take on greater challenges
This was before there was a branch in Japan, right?
It was just as they were thinking about launching one. To be honest, I didn’t know what lay ahead for me. Maybe the company would go under. On the other hand, if I worked hard, maybe I could help the company succeed. In terms of what an engineer can do, it’s creating a system, and running it in a stable fashion – whether or not the business comes to fruition after that is somewhat up to chance. So I decided I would fulfill my role as an engineer and focus on making good systems. Being able to do that in the context of the cloud, which I had just happened to have an interest in, felt like a new challenge, so I wanted to give it a try.
What did you work on after joining the company?
The Japanese branch originally went live as part of a tie-in project with a certain company. Unfortunately, that project did not see the light of day. I actually felt like my job was on the line. I decided to think about what to do and turned to a range of issues around me. I proposed implementing new tools, created a platform for data analysis, and so on. In so doing, I slowly transitioned to DevOps.
DevOps: solving internal issues and optimizing workflows
What is DevOps’ role?
In a word, it’s about “engineering” the company as a whole. We use new tools and techniques to improve company systems, infrastructure, monitoring, reporting, et cetera and make them better. As for why this is necessary, when you are working strictly on a project basis, you tend to focus on only what’s immediately in front of you and lose sight of the big picture. By looking ahead to optimizing company processes as a whole, we can plan for the future.
What does that involve?
For instance, we implemented Google’s BigQuery to make analysis and reporting easier. We originally intended it as a development tool, but we held workshops and promoted how using SQL queries in this fashion made work easier. We set it up so that both engineers and the business team could set KPIs and use it. Reporting eats up time and hinders mutual understanding among members, so getting everyone onboard represented a major improvement. The general process we employ is one of finding latent issues in the company, then seeking out or building tools to remedy that and making them relevant to the business by propagating them throughout the organization.
Considering near-term issues independently and taking the initiative
What kind of engineers do you look for?
With Quipper as a whole, we’re providing our own service, not doing work for others, so we want people who have a specific interest in what kind of work they want to do, a technical background, and an ability to state their mind on things. We work on a daily basis on GitHub with engineers in the UK and Philippines, so the candidate should at least be able to read and write in English. We have engineers of many nationalities, and they have strong opinions, they’re young, and they’re full of vitality, so Japanese engineers will have to have the same mettle.
What about in terms of DevOps?
Not being afraid of change. While systems and services need stability, you shouldn’t get complacent – you need to have the motivation to continually make things better. While there’s the idea of working within a budget of what’s available, you are given the right to choose what you do within that matrix. Put differently, being passive is no good. You have to take the initiative, consider near-term goals and decide what course to take. For instance, you might consider if the userbase grows threefold in the next six months – what would you have to do then? That kind of future forecasting is a must. If you’re the kind of person who likes to make a lot of suggestions about what can be done to stabilize and improve a company and company’s systems, you’ll feel very motivated here.