Many companies depend on strong cross-functional teamwork and relationships to build a product that delivers real value to their customers. Interlock is no exception.

What is cross-functional teamwork?

The phrase “cross-functional” is most commonly used to describe a team made up of people with different functions or skills.

At Interlock for example, our product teams include designers, programmers, and product managers, unique roles working together as one. Or you might hear the term used when teams from different parts of a business work together on a big project, like the launch of a new product or release.

The phrase “cross-functional” is most commonly used to describe a team made up of people with different functions or skills.

“For organizations to be truly effective, every team needs to consider itself as working cross-functionally all the time, not just on a project by project basis”

In both of these situations, a program or product manager takes the lead, operating as a kind of conductor, making sure all the instruments are in harmony and ensuring everyone knows their role,  timing, and goal.

The journey towards effective automation begins with a clear assessment of current workflows. Pinpointing the bottlenecks and time drains is essential. Companies that have embraced automation find that it's not about replacing the human element, but rather enhancing it, allowing staff to focus on strategic tasks that require a human touch — thus optimizing the overall workflow.

Implementing automation does not come without its challenges. It requires a thoughtful approach that considers the potential for disruption and the learning curve for employees. However, the payoff can be substantial. Businesses that successfully automate experience not only a boost in productivity but also often see an increase in employee satisfaction as staff are relieved of mundane tasks and are able to engage in more meaningful work.

I came to Interlock from a company with a culture of heavyweight engineering processes. It was a well-oiled machine with battle-tested and often updated procedures.

From an engineering perspective, it successfully kept you focused on coding. Tasks were always well-described in Jira, and included clearly defined expectations. Designs came in and were exported to HTML so you didn’t have to worry about using Sketch. You did your job, then moved the task to QA. If something came back, it was always with a good description of what wasn’t working.

When I started at InterLock, however, I was surprised at how lightweight the weekly engineering processes felt compared to my previous company. No estimations. No Jira. No separate QA team. Initially, I felt overwhelmed. I wondered why it looked this way, why everyone just aligned and no one tried to structure the processes as I was used to.

“Processes have to serve the development of the product”

The main reason is that in both of these companies, there were different problems to solve, even though it looked similar on the surface. Interlock is very much a product-first company, and very heavyweight processes can be too much of a constraint in a product-first company. In this sort of environment, the processes have to serve the development of the product, rather than the product developing out of predetermined processes.

At Interlock, we have a very strong culture of solving the right problems. We are ruthless in defining what the true problem is, how we solve it using a small, well-scoped project (or a cupcake, as we like to call them), and how it might eventually look like if the cupcake proves to be successful.

In short, we ask what is the problem and how will you measure that it’s solved. And we don’t just use this approach when working on our products – we try to apply the same approach whenever we want to add new or adjust existing engineering processes.

The subconscious benefit of processes

In any organization, processes are important and beneficial. They streamline the workflows, help people make fewer mistakes and bring some degree of comfort – having a good set of processes can create the sense that work has already begun to proceed.

Onboarding is critical to the success of your product

At Interlock, we aim to deliver outcomes. Without an accessible onboarding process, customers may never reach the stage where they can use the game-changing features your team has worked so hard to build, making outcomes difficult to achieve.

Focusing on the onboarding process at the beginning of new product development is critical to overcoming this. This is especially true when you’re building for mid-market and enterprise customers. Businesses use buying committees to make the decision to use a new product. These committees are essential, even if the product is free, because every new product necessitates a process change.

“As companies get larger, process changes impact more people, and the buying committee tends to grow”

In a small startup, the “committee” could be a single person. But as companies get larger, process changes impact more people, and the buying committee tends to grow. Larger buying committees mean more people and steps involved.

It’s easy for customers to stop onboarding at any hurdle the buying committee experiences. At best, poorly thought out onboarding could mean customers take weeks or months to start using a new product. At worst, a poor onboarding experience could prevent them from ever getting started.

We experienced this first-hand while building our WhatsApp integration. In the early days of the beta, we realized it was taking a long time for customers to get started – with no clear answers as to why.

“We had spent the majority of our time focusing on day-to-day features customers would love, but not the processes they would need to go through”