How To Build Growth-Focused Product Engineering Teams
Tactics for cultivating growth-minded behavior to build transformative product engineering teams
The best teams consist of growth-minded individuals focused on collaboration and learning. Small teams aligned on these principles can achieve what large-teams are incapable. That is building differentiated products that customers love.
Hiring growth-minded individuals isn’t enough. An organization needs to champion a set of principles and values. These are some of the values I focus on and tactics for implementing them.
Build Relationships Through Support
Everyone does support. Empathize with your customers. Learn from their challenges.
There are organizations that discourage engineers talking to customers. Often layering product or accounts/customer-success as a barrier between engineering and customers. This creates distance. The closer the engineers are to your customers the better.
You should empower your engineers to talk to customers
If you aren’t familiar with The Effortless Experience, it is a great read. It focuses on Customer Loyalty by reducing customer friction in support channels. Engineers that sit on the sidelines aren’t invested. Make championing your customer’s success a priority at all times. Regard your customers as a partner in building your products.
Hire Engineers With GREAT HABITS
When hiring engineers, the industry staple is hire only 10x engineer(s). Individuals with a computer science degree from a top tier-school. They hail from the likes of Google or Facebook. When prompted, this engineer can write graph traversal algorithms on the spot. But even Google found no significant correlations when studying interviewing outcomes to performance.
So, what really matters? Can you write readable code that is well-documented with tests. Are you passionate about this industry. And can you leave your ego at the door. Find those engineers. Avoid engineers that write complicated code with no tests and argue that tests are a waste of time.
There are no great engineers, only engineers with GREAT HABITS.
- Kent Beck
Be a LEARNER via Continuous Learning
Fostering a path of continuous learning is a journey to improving one’s craft. As a technical leader, you should be mindful of how you grow your craft and that of your colleagues. The day-to-day pull requests, architecture review, and design sprints are all opportunities to learn. Make a point to be available to pair with all engineering colleagues — even the interns, to learn and teach.
Measuring For Success
Scorecards — A Critical Measure
I’m a fan of Drucker and Doerr, and Measure What Matters. Host a weekly scorecard review meeting with your team. During the meeting, discuss the metrics collected and organizational learnings.
But it boils down to measuring external customer and internal operational metrics.
External Customer Metrics
Finding the Northstar Metric(s)
A Northstar metric is one that drives successful adoption of the product. Boiled down, these are specific engagement metrics that can act as a signal. The best example is Facebook’s Northstar. They discovered that users that made 10 friends in 14 days converted to life-long users. Figure out what that metric is for your product.
If you aren’t learning from your customers weekly then you are FAILING.
Internal Operational Metrics
Every team should be responsible for tracking some useful internal metrics. If you’ve implemented OKRs, those will give you some metrics to start.
Here is a list of some common metrics to track:
- PRs Merged/Deployed (ENG)
- Feature Points Shipped (ENG)
- Recruiting Funnels (All)
- Support Conversations (Success/ENG)
- Customer Development Meetings (PROD/ENG/Success)
OKRs: the Tie that Binds
Writing effective OKRs comes down to measurable goals that align with the organization. This can be summed up by SMART Goals: Specific, Measurable, Achievable, Relevant, Time-bound. Sounds straight forward, write realistic goals that are measurable. Organize them so they are accessible to everyone in the company. I like to structure my time-bounds around quarters with weekly tracking. Regardless of this advice it can be a challenging. My recommendation is to start simple, 1 OKR for everyone per quarter. Pair with your colleagues to help write these. Make it a homework assignment for a 1:1. If you want examples okrexamples.io is a great place to start.
Remember…
OKR’s are not immutable constructs etched in stone. When markets or priorities change, then update your goal(s).
Encourage Full-Stack Engineering
Not every engineer is full-stack or wants to be full-stack. And that is fine. But the future for full-stack engineers is bright. Encourage cross-training and development of individuals that wish to grow their skills. The benefit of full-stack engineers are their ability to own feature development end-to-end. Hand-offs between developers can and will fail. Untested endpoints handed to front-end teams, and data-warehousing pipelines that jam and never alert anyone. Work divided amongst engineering members weakens the ownership. A small squad of full-stack engineers paired-up should not have hand-offs.
Right Tools — Right Process
We embrace the ideals of creating a system of work. Identify the right tools that allow your team to align their process. Think about their collaboration, data-collection, and continuous-learning.
I’ve lead battles to adopt tools like Github and Slack within an organization. When senior leadership blocks tool adoption this prevents growth and learning.
If there is a tool out there that will improve a team’s process — encourage adoption. Often, as the leader, you should drive forward this adoption. And if a colleague approaches you with a new tool or process, give it an honest look before dismissing.
