7 Principles for Cross-Functional Product Development Excellence at Teachable
Part One: The Principles
Want to join our team? We’re hiring for several different positions.
The Problem
Teachable has been on a wild growth spurt for the past couple of years. That’s obviously great when it comes to things like revenue, number of customers, and all that fun stuff.
But there are real challenges associated with growth. The subset of our Product and Engineering organizations that focuses on building and maintaining our platform (Product Engineering) has gone from a dozen engineers organically self-organizing to today being 6 fully-loaded “product pods” — cross-functional teams consisting of all capabilities needed to build customer value end-to-end: Product Management, Product Design, and different subsets of Engineering.
This adds up to almost 50 people with very diverse skills, backgrounds, experiences, and motivations.
I’m going to toot our own horn a bit and say that we’ve done great at hiring incredible talent. As a mission-driven company, Teachable attracts really high class talent, we’ve got an amazing in-house Talent Acquisition team and we’ve gotten remarkably good at finding the best of the best.
But, as larger scale starts creeping in, it’s not enough to just hire great people. You also have to set them up for success by providing an environment that enables amazing teams to replace groups of talented individuals.
Just like a sports team or a band needs to learn to play together, individuals in a cross-functional team need to find a way to fit their talents to the mission of the team.
Our industry is pretty good at having best practices (org structures, role descriptions, processes, paradigms, vocabulary, systems) in place to facilitate this. The only problem is that a lot of those practices need to be adapted to the context of the company.
As a result, a lot of the smart people we’ve hired all come in with a slightly differing view of how cross-functional teams operate. The differences are small enough that it’s hard to detect them, but big enough that when the going gets tough, cracks start appearing.
Our Product Engineering leadership identified solving this problem as a task with very high cumulative returns. Not only will it help our existing 50 people be happier, more motivated and ultimately create better solutions for our customers, but it will further help in finding the best talent for our organization and keep scaling our organization in the future as well.
The Solution
It would be very tempting to just dump a set of rigid processes, job descriptions, and guidelines on our team. Do this, then do that and then the other thing — handoffs, over-engineered Jira workflows, role descriptions that leave nothing to imagination, etc.
That would be terrible for a number of reasons:
- System homogeneity makes for brittle systems. We currently have 6 teams working on very different types of problems on different parts of the product. Expecting them all to work in the exact same manner would be madness.
- Humans are individuals. What works for one set of humans doesn’t directly translate to another.
- We hire really smart people and want them to solve problems. Telling them exactly what to do would be an absolute waste.
Because of this, we decided against coming up with a specific “Teachable Way” of working. No top-down prescriptions of daily schedules, one-size-fits-all SDLC processes, or complicated project workflows.
Instead, we offer a higher level of abstraction — a set of principles we expect all individuals, pods, and managers to strive for coupled with recommendations for how to work and expectations on reasonable uniformity of inputs and outputs.
Within these guardrails we allow for the pods to figure out what works for them — as individuals, as a team, and for the problem they are working on.
We gave this set of 7 principles the name P.E.O.P.L.E. — The Teachable Product Engineering Operating Principles (Lit Edition). Yes, the last two words only exist to round out the acronym, but all cheekiness aside, it does reinforce that this is all about people. About unleashing the talent, creativity, and problem solving of all the people on our team.
7 Product Engineering Operating Principles
Principle 1: Pods Win Together, Persevere Together
The first thing we addressed was removing functional boundaries within product pods.
You all know and love the antipattern: Product Managers running around “gathering spec” or figuring out what customers need. Then that gets dumped on designers who do their thing that ends up in high definition visual spec. This then gets dumped on engineers that shrug their shoulders, think “if only someone had asked me earlier I could’ve found a dozen ways to make this easier” and more dysfunctional product gets built. Everybody is just a step on the conveyor belt. Even if the pod does “scrum” and chops this into mini-waterfalls.
This happens when deep functional lines and stiff role descriptions force people into working for functional local maximum.
Just like in a musical band where nobody cares about how great the drummer is if the music sucks, nobody cares about the great design of the product if the whole aggregate isn’t right.
The ultimate outcome of this principle is elevating the role of the pod as a team that’s held accountable for their collective output. Individuals’ stats are secondary.
It also encourages pod members to consider their “T-shapedness”: Going beyond their deep core specialty and always asking themselves “what is the best action at this time to ensure the success of the team?” Even if that’s a Product Manager doing visual QA, a back-end engineer popping over to a customer interview, or a designer running comms during a production incident. If that’s the best way to help your team succeed at the current point in time, it’s the right thing to do.
Principle 2: Invest in Trust
To be honest, this might ultimately deserve to be the first principle. All the other values more or less build on this one.
The shortest possible summary of our principles is “excellence in human-to-human interactions in a group setting.”
The dynamics of how groups of people work together have been researched and written about a whole lot. Especially in environments of heuristics-based, problem-solving work. Including the often shared 2015 Google study on the characteristics of high-performing teams.
The most powerful and understandable framework for the layers needed for a group of people to excel is the 5-layer pyramid in the book The Five Dysfunctions of a Team.
What’s common across the board in findings is the importance of a real and deep sense of trust between members of a team that begets the type of psychological safety needed for efficient disagreement.
Too often product development teams hide behind roles, processes and other rituals in order to remove the necessity of investing in meeting the human behind the job spec. But in these situations a real sense of belonging doesn’t emerge, diverse voices are left unheard and solutions start biasing towards the mediocre. Creativity fails to thrive. Loud voices reign supreme.
To combat this, we want to give explicit permission to take the time required to build this trust. Or to call out trust eroding behavior, whether the culprit is a pod member, a manager, or leadership.
We also want to make sure we truly walk the walk of diversity and inclusion. Not just in how we staff our teams, but how we make space for everyone to be creative and leave their mark on our product.
NOTE: We do make it very clear that this doesn’t mean we’re a cult or family. Building trust requires a sense of vulnerability and openness, but we’re a place of business. Everyone gets to choose the level of “their full self” they bring to their teams. As long as their behavior creates space for trust to emerge.
Principle 3: Stop the Line
Quality. That’s the hardest mindset shift as a company goes from the hunt mode of early stage startups to the sustainability of the growth stage.
We wanted to be explicit about the fact that Teachable has found clear product-market fit in its core product. We’ve had remarkable success in getting to serve tens of thousands of paying customers who will make almost half a billion dollars in total revenue this year.
We owe them a product that is reliable, resilient, fast, secure, and overall a joy to use.
We also owe ourselves a product we can be proud to call our own and that is enjoyable to work on.
This can only happen if our pods are empowered to stop what they are doing when issues in quality arise and go several “why’s” deep into root causes, instead of just applying whatever quick fix is needed to make the problem go away (today).
Principle 4: Strive for Continuous Improvement
We don’t ever want to forget that building software is a creative process. Solving a puzzle. Dealing with endless “unknown unknowns”.
The only way to approach an environment of constant change is to always assume you know more tomorrow than you do today: as an individual, as a team, and as a product.
We learn about our customers, we learn about our product, we learn about new technologies, we get hit with a worldwide pandemic. Things change. Our excellence is measured by how well we adapt to new challenges and how fast we leverage new information.
That applies to individuals too. You’ll (hopefully) always be dumber than your tomorrow self. Approaching everything with a sense of humility and with a willingness to have your ideas challenged is a tell-tale sign of a growth mindset.
We’re in the business of knowledge sharing and helping people grow. We should all be lifelong learners as well.
Principle 5: Be a little embarrassed
A close relative to principle #4: The only way to learn and challenge your thoughts is to get them exposed early and often.
This cuts across all stages. Thinking of changing a shared system? Get an RFC in front of other engineers to solicit feedback right away! Want to try a new UX paradigm? Get a prototype in front of people! Adding a new feature? Test with real customers early! Struggling to decide between options? Experiment!
NOTE: We’ve had a lot of internal conversations around the balance between principles #3 (quality) and #5 (experimentation). This is not a hard binary with the right answer, but generally we understand #3 to be the overall long-term state of the product (high quality) vs. #5 pertaining to being willing to jeopardize quality temporarily with appropriate groups of people in the interest of learning. #5 is not an open pass to hack stuff together, ship and forget.
Principle 6: Solve customer problems
We’re an organization of people whose skills are focused on one thing: building custom software. This kind of makes sense as we’re a company that sells a software platform.
But this incredible strength can also be a powerful adversary. When you’ve got a hammer, the world looks like a nail.
We need to constantly remind ourselves that building more software isn’t a value in and of itself. Ultimately, we exist to solve our customers’ problems and empower them to capture their opportunities.
Sometimes — most of the time — we do that by building more custom software into the world. But we can never lose sight of why we do our thing in the first place.
We want this value to remind us that there are always options to consider. Building more software is a powerful solution, but also an expensive one. Every line of code is a liability. More software = more complexity. The things you own end up owning you.
Especially paired with principle #4, this becomes an important guide: We can’t anticipate future needs and requirements, so any decision to build something should assume a huge need for ongoing maintenance and development. V1 is just the beginning.
Important caveat: This doesn’t mean “just do whatever customers ask you to build.” We need to go beyond that and understand what their real needs are and solve them in a way that truly makes our product better for them — now and in the future.
Principle 7: Be a Trusted Partner
Our principles focus a lot on how pods work within themselves. We truly believe that all great things start from small groups of humans learning to work together seamlessly.
But there’s a bigger world out there and the first 6 principles have a danger of pods becoming myopic entities that optimize to their own benefit.
Whether we’re talking pod-to-pod interactions, pods interacting with the rest of the Technology organization, other functions at Teachable, or most importantly our customers, there are a lot of people relying on our work. And as mission-driven as we are, we’re also a for-profit business, so the P&L and shareholders should be considered as well.
This principle is an invitation for pods to familiarize themselves with all the groups that their work impacts and seek to build trusted relationships with them. For example, if you truly understand how the Teachable fraud team works and what their challenges are, you will start viewing them as more than just requirements generating “stakeholders.” Understanding how the Teachable business works helps you make significantly better decisions on what to prioritize and why.
Additionally, showing you understand a function’s work will help them view you as a valuable partner instead of a ticket machine cranking out work on spec.
But trust isn’t given, it has to be earned. Reid Hoffman’s formula for trust is consistency x time and that holds very well. This means we need to minimize the amount of (negative) surprises on an ongoing basis.
That doesn’t mean “hit fixed scope deadlines at all costs”. The other principles still hold. Software development is an exercise of solving puzzles, learning and change. What this principle asks is to be diligent and proactive in communicating what we learn, and how that changes our forecasts. As early as possible.
Now What?
That concludes the first part of this two-post series. For more information on how we intend to roll out and keep our principles actionable, click through to the next part:
