How to build high performing product teams — 4 pillars

If you are building a team to bring a product to the market, joining a team, or are now the leader who is tasked with scaling something that is working to deliver 100s of millions of dollars in revenue — this is for you.

The benefit of building companies, bringing (and failing plenty) products to market, and then working with the greatest companies (Google, Amazon, Microsoft, ++) is the exposure to habits and practices that consistently win, everywhere.

These pillars are best suited for our high deployment, digital world, but work strikingly well in the industrial space too. I currently have hundreds of product teams demonstrating that fact daily at the moment.

In the next four sections I’ll highlight the power of each pillar and then share attributes that I see for high performing teams specifically. My intent is to share with you these pillars, so that you can apply and transform them for your own pursuits. Separately I’ll share deeper dives into each pillar (pragmatic is already published), and will be speaking on this in various conferences in 2019. I engage often online, and would love your insights and enhancements to these ideas based on your experience too.

Culture

First and most important. Funny thing about culture, the structures we build around our company impact it far greater than we realize. It is 100% true that the initial team members establish the culture, and form the essence of the group cohesion. What happens after that small team is established is where I want to focus …

Culture is swayed by many things and if we want to scale (cybersecurity, speed of products to market, empathy, and optimism) we need to set the structures around the team smartly. Here are core attributes:

• Policies and standards that don’t murder creativity
• Policies and standards that don’t coddle
• Policies and standards that show the intent vs the prescriptive activities
• Trust
• In this together, a responsibility that everyone shares
• Contribution and support to result (not task)
• No Audits, No Police

An example: What if you set a policy that didn’t allow the use of specific tools … well, the human reaction (if they need it) is to make it — either engineer it originally or to pay for it again. Either way, it is wasteful and by forcing those that aren’t experts in that tool to deploy/operate it — you open the door for high error rates and failures at the product level. The culture adjustment is to create a team approach where policies and tools are made available. This ensures the strongest operators are involved and creep fails to set in across the business.

Strategy

It all depends on what is your ambition?

This is so important to setting up your product teams and cybersecurity work patterns properly. Knowing if you are building a quick sprint POC that’ll be tossed away after a few weeks vs. you are building a POC that’ll become the foundational code for a giant product matters. The truth doesn’t change the sprint, the speed, or the work patterns. It does change who is involved and how the plans are put down directly.

I’d love to say that every sprint that I have seen in the product space followed a robust process equal to that of every established product, but that isn’t the case. In fact, that isn’t the leading indicator of a successful effort. We need to be scrappy. We need to allow for 2 weeks of work built on spec with minimal interference. We also need to plan that if the technology / product plays … THEN we must all be coordinated to bring the support of the business to bring this POC up to our market requirements!

Key considerations:

• Structure matches ambitions
• POC transition to supported project are known
• Sprints adhere to “lite” SDLC process
• Speed is embraced
• Resources reflect ambitions too

Pragmatic

Be reasonable — you don’t need to solve world hunger in the first week

I can’t express how common the most successful teams and products began with being very sensible in what they deployed and how. Privacy matters, yes … and can be achieved very easily with guidance at the beginning and then enhanced rigor post POC. The same is true with every feature and function.

You must recognize that every “thing” we want takes away from another “thing” being included. There are only so many development hours available. What is powerfully demonstrated by the best is the creation of more levers that feed this truth.

• Create more hours for the team, give a security architect!
• Create more hours for EVERY team, build reusable code elements
• Establish architecture and backbones that can be reused

Empowerment

Give your teams permission

Give your team the tools, knowledge, and resources WHEN they need it

These teams are not robots, treat them accordingly

This is a super hard skill to set in teams. How you create resources for your teams and how they develop merge together in this mature teams. It is less about doing it for them (helicopter parents) and more enabling them and letting them succeed.

It is super important here that we aren’t watching to catch them fail. In fact, if we are ready to pounce like a cobra we are definitely not empowering them. A healthy audit of our own actions is equally important of our teams’ performance.

We are seeking teams to succeed. We want our team members building each other up. Not identifying errors, but instead leading with “I see we did it this way / this is missing, here is what you need to make this ready”.

You matter the most

While there may be four pillars to building these successful product teams, you are the most important element. No matter if you are the leader or any other role. Making a product and actually delivering it in the market is HARD. You matter. You living these pillars and you helping others live it is the fundamental difference between luck and actual happiness and success with your customers.