Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Surefire Ways to Boost Team Morale

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, talks about effective ways to boost team morale when stepping in as a new manager in the team.

Motivation
Team Processes
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

Managing Team Collaboration After an Acquisition

10 November

Han Wang, Director of Engineering at Sonder Inc., shares the ins and outs of working successfully with the other half of the team after a merger.

Acquisition / Integration
Large Number Of Reports
Company Culture
Performance
Han Wang

Han Wang

Director of Engineering at Sonder Inc

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.