Create a post to help us get to know you better. You can use these sample questions to start with:

• What is your current role?

• Share some of your skills and experience!

• What's your favorite thing about working with communities?

• What are your top 3 goals for your community?

• What have you learned recently about community building/community engagement?

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.

Advancements in data analytics and machine learning have provided the tools necessary to dissect large volumes of customer data, extracting actionable insights. These insights empower businesses to deliver personalized recommendations and solutions, significantly enhancing the customer journey. A customer's interaction with a brand becomes more meaningful when the content they receive is aligned with their past behavior, interests, and predicted needs.

However, with great power comes great responsibility. In the age of personalization, privacy concerns stand at the forefront. Companies are tasked with striking a delicate balance between delivering personalized experiences and maintaining customer trust. Transparency in data usage and giving control back to the users are crucial steps in fostering a relationship where personalization leads to improved customer loyalty and business growth.

As a result, we invest a lot in the reliability of our application. But unpredictable failures are inevitable, and when they happen it’s humans that fix them.

We operate a socio-technical system, and its ability to recover when faced with adversity is called resilience. One of the crucial components of resilience is observability, the steps we take to enable humans to “look” inside the systems they run.

This post will explore the road to building a stronger culture of observability, and the lessons we’ve learned along the way.

What do we mean by observability?

At Interlock

, we ship to learn. Our production environment is where our code, infrastructure, third-party dependencies, and our customers come together to create an objective reality – it’s the only place to learn and validate the impact of our work. We define observability as a continuous process of humans asking questions about production, and getting answers*.

Let’s break that down a little more:

• Continuous process: Successful observability means that folks observe as frequently as possible.

• Questions about production: We wanted our definition to be wide, generic, and representative of the broad scope of workflows we cater for.

• Answers*: Note the asterisk. No tool will give you answers, only offer leads you can follow to find the real answers. You have to use your own mental models and understanding of the systems you run.

Stage 1: Problem and solution

Armed with our own definition of observability, we assessed our existing practices and formulated a problem statement. Until recently, our observability tooling has been primarily based on metrics. A typical workflow involved looking at a dashboard full of charts with metrics sliced and diced by various attribute combinations. Folks would look for correlations but often leave without fulfilling insights.

“Metrics are easy to add and understand, but they are missing high-cardinality attributes (e.g. Customer ID), making it difficult to complete an investigation”

Our engineering principle “shape the solution” allows us to deliver better customer value and maintain a team of highly engaged, aligned and motivated individuals. Shaping the solution means that we never blindly execute on requirements defined by others. We deeply understand the value of our work, and help design solutions which efficiently deliver that value.

This is the sixth post in a series exploring our product principles. Here, Levent discusses our engineering principle “Shape the solution”.

Engineers are involved from the outset

In a lot of companies, the product development process is based around negotiation. A product owner, business analyst, or product manager articulates the customer’s requirements and passes them on to the engineering team. The engineers provide feedback, generally in the form of pushback, and the parties negotiate towards consensus.

“A truly high-performing, self-organizing team would never organize itself into silos”

Not only does this guarantee that, by design, only one person is empathetic towards the customer’s needs – but it’s the opposite of a culture of collaboration. A truly high-performing, self-organizing team would never organize itself into silos in this way.

At Interlock, our engineering team values mark out the qualities that we think make for great engineers. Engineers that shape the solution from beginning to end:

• Truly care about what they’re working on.

• Want a say in the outcomes they work towards.

• Understand the role collaboration plays in building great products.