Worlds Apart: A Critical Look at Company Size and Work Culture
Why the size of a company can be a big differentiator for a job seeker
The size of a company can be a big differentiator for a job seeker to decide whether to work for the company or not. Having the experience of working in an organization as big as Google and in a start-up with only dozens of employees, I would like to share my observations for those who are having difficulties making this decision.
The Background
Gogolook is a start-up software company based in Taipei, Taiwan with about 50 full-time employees. Gogolook’s main product is Whoscall, which is a mobile app that identifies unknown callers for users. I worked at Gogolook as a full-time product planner for two years before I came to the US to undertake my master’s degree. My position was a combination of project manager and UX designer. I established business goals and user goals for each project, defined metrics, create wireframes and user flows, and collaborated with visual designers, developers, and other roles to ship the product.
This summer, I interned as a UX designer with the Shopping UX team at Google. Products in Google Shopping are consumer-facing, like Google Express and other operation tools that Google designs for merchants to manage orders. During my time as an intern on the team, I worked on an end-to-end project to design a new feature for one of the operation tools. I did everything from conducting field research, creating the wireframe, iterating in medium and high fidelity to conducting usability testing and building design specs for developers.
A quick caveat: The working culture varies between the different teams at Google. This article is written based on my experience in the Shopping team.
The difference in the development process and team setting
At Gogolook, we ran scrums across cross-functional teams. Each cross-functional team was assigned with a high-level goal — for example, user engagement — and we shipped a new version of our product every two weeks to move toward our goal. The idea was to fail fast and iterate constantly. To achieve our goal, we made hypotheses, built and shipped the feature, and had it validated with real users by tracking the impact it had on the metrics. The cross-functional team worked together very closely. In addition to weekly meetings, we also had daily stand-ups to share any updates and track our progress toward the goal. The team collectively decided what to build next.
At Google Shopping — while there’s the practice of cross-functional teams — the team isn’t so closely tied in, so some roles function in multiple cross-functional teams for different products. The development process is closer to the waterfall style: The project manager defines the product spec, the designers work on the flow, interface, and interactions, and then hand it off to the developers. In most cases, there isn’t a hard deadline. The launch of an improvement, feature, or product depends on the time and effort estimated by the roles assigned to the various tasks.
The difference in design focus and research methods
When I was working at Gogolook, I focused a lot more on the business perspective of the product. While I also did user research, my goal was to find out possible ways to increase user engagement to impact the revenue. The projects that I worked on mostly focused on increasing in-app traffic, DAU/MAU, and user retention. This is because, for a start-up company, the most important goal is to prove the product’s ability to generate revenue. We did tons of A/B testing and watched the changes to the metrics closely. For a certain design, if the team had diverse opinions, we would build and ship different versions by A/B testing and see which worked best (i.e. generates better results on metrics) and go with that option.
On the other hand, at Google Shopping, the product that I worked on was enterprise-facing. Thus user engagement wasn’t the main focus because the users had to use the product to perform their work —increasing user engagement wasn’t a concern. So during my internship, I learned how to focus on my users’ perspective and advocate for best usability. I was doing mostly qualitative research — including field studies, contextual inquiry, and usability testing — to understand how to design the new feature in a way that could help the users do better at their work.
Conclusion
I wouldn’t say one working culture is better than the other, both approaches have pros and cons. In a start-up running agile development — whether seeing your own work’s impact or gathering feedback from users — results are seen quickly. However, given the short timeline, there’s rarely the chance to conduct user studies like in a larger organization. Thus start-up teams tend to go with short-term solutions when the hypotheses don’t prove effective in the metrics. On the other hand, since the speed of a larger company is slower, it can take a long time, even up to years, for a project to move from idea to launch. In the end, it really depends on the working style and values of an individual and what working methodology they think will create the most advantageous conditions for developing their career.
See more about my internship at Google
How I interact and collaborate with other roles as a UX design intern at Google
