Back to resources

How to Maintain a Startup Mentality

Company Culture
Team Processes

22 August, 2021

Sven Coppens
Sven Coppens

Sr Product Development Director at Aprimo

Sven Coppens, Sr Product Development Director at Aprimo, discusses what it takes to maintain a startup mentality in the midst of rapid growth where processes are added without much reflection on why and if needed.

Problem

As an organization grows, new processes are being added. People simply need to track, connect, communicate, or audit, and as a result, organizational processes will evolve. Suddenly, everything has to become documented and approved, which erodes the agility that is driving most startups forward. Most people join startups because they enjoy working in a fast-paced environment with agile processes dictating the workflow. As you can imagine, they are not happy about losing their agility, flexibility, and speed to deliver value to their customers.

The problem is that too much administration is being introduced at some point, while empowerment following those same processes is being removed. That starts to slow things down, and once that takes over, it is hard to change it to the previous state because the administration has a tendency to place its roots deep and wide. Therefore, before introducing any new process, one should reflect on why and if it is needed and what is the added value of any new process.

Actions taken

Whenever I would have to introduce any new process, I would ask myself what the goal is or why we are introducing it. I use value-stream mapping, also known as material- and information-flow mapping, to understand if the new process would add value or introduce waste. It allows me to see how much time it would take to arrive from the start to endpoint while visualizing the new process. Frequently, the challenge is not in why we are doing it but if we could do that differently. We would need new processes, and by analyzing data, we could spot their weaknesses and the opportunities they carry along. Moreover, the analysis would allow me to assess if we would still be agile enough after introducing them. If we would be sacrificing some agility, would it be compensated by the value which would be added?

Or in some cases, we would have to question the existing processes given the changing nature of a rapidly growing startup. For example, people would be filing Jira (or any other tracking tool) tickets and then would be perplexed by the existence of some fields. Why do they need to fill those? Those ceased to be relevant a long time ago. This is when we should take a more backward approach to see whether the purpose those processes served would still be relevant today. If not, it just slows things down and should be discarded.

Also, when we set up a new process, people tend to build for the unknown. People project everything that could go wrong or what they might need, building something that is too large for the organization. My experience is that when you are in a growing startup, you should build processes for two times the size you are today. That would create enough room to mature without being stuck but would be still lean enough and adjusted to the size of the organization. That projection would not be large and over-engineered to impede the existing processes. Therefore you should carefully study your growth: the number of people and the number of projects. You are building processes for your next step, not for your CEO’s ultimate dream.

Furthermore, we should understand what purpose new processes serve. Is it to track or to communicate, for example, and what do you expect as a result? I often see in larger organizations that communication happens through work items, which is not the most effective approach. In the past, people would pick up a phone or set up a Zoom meeting, and things would be settled through that one call. Later, people would instead file a ticket and communicate through that ticket rather than picking up the phone. Jira was introduced for tracking, not communication, and introducing a tracking system doesn’t mean that you have to change your communication habits. Every process should have its distinct purpose: it shouldn’t change or replace all other processes by default.

Lessons learned

  • Track value a new process brings. Every process has its ROI, and you should be able to measure it. Oftentimes, processes in scaling organizations are introduced for audits. Things need to be certified and controllable. Indeed, audits and certifications are all about control, but control can be exercised through various mechanisms. Try to keep them close to the people who are working with them.
  • Don’t over-engineer. When you build things, you build them for your size and a slightly bigger size. Engineers get carried away easily, especially when they need to impress their superiors.
  • Know who is working with which processes and who will be impacted by the change. From a management perspective, things often look easy, “Just create this ticket; it’s five minutes of work.” But with a ticket here and a ticket there, a developer will be spending 50 minutes filing tickets and not developing. What do you think a developer prefers to do -- code or do the admin work?
  • Provide the context. People are willing to do some admin work if they can see some value in it. If they don’t understand why they have to fill in a ticket, they will most likely avoid doing it or complain at least. Sending an email announcing that a new ticketing system will be introduced that can do A or B is not enough.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

How to Maximize Employee Retention in Engineering Teams

25 May

Vimal Patel, Founder and CTO at iMORPHr, shares how he retained all of his employees since beginning his software development company in 2019.

Building A Team
Company Culture
Hiring
Retention
Psychological Safety
Vimal Patel

Vimal Patel

Director of Engineering at iMORPHr

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.