Startups & Team Friction

Another great review by Abi Noda last week, discussing an article from Rick Kick & Kennedy Collins about how startups run into team-friction when they hit upon success and growth and fail to adapt. Having lived this myself a few times over, it’s an enlightening look at a common problem that destroys startups.

The problems with Success

You’ve all seen the stories: Small startup strikes it big with a novel idea. They manage to remain agile and adapt to market conditions, realizing their idea's potential and monetizing it to huge gains. Big gains means big-company problems and inventor interest, so they start scaling up. Some scaling is to meet growing consumer demand and keep up, and some is looking to other things the company wants to do. More people means more management and more communication problems. Before you know it, deadlines are missed, features are pushed out half-implemented, everyone blames another team, and in short order this golden child startup disappears in a blaze of glory. It sounds like Hollywood but it happens every day in the tech world.

Why does it happen?

There are lots of theories on why this pattern repeats itself. There are even cute names for some of the bigger ones, like “empire building” or “too many chiefs, not enough indians”. Most of them blame the trouble on too many layers of management between operational functions that create opportunities for things to fall through the cracks. Instructions get confused, missed, or misinterpreted, leading to schedule delays or missed targets.

This article, however, brings up a new possibility I’ve not seen discussed before: Lack of a coordinated “Product Team”.

The Product Manager

Most companies eventually wind up with people holding the title of “Product Manager”. But what exactly is a “Product Manager”? I’ve seen companies interpret a few different ways:

The Program Manager: A person that defines the requirements and manages the delivery schedule to see it realized.

User Experience: someone who manages the consumer-facing aspect of the product, defining requirements and working with Customers.

Sales, working with customers to try and identify what missing features would cause them to buy the product, building future roadmaps.

This all kinda works, but I’ve never seen it terribly successful. All of them suffer from a problem that I’ve witnessed and they describe so beautifully:

When product managers pass off features and requirements without reviewing them with the engineers (usually within the constructs of a tool like Jira), critical business and customer context can be lost. If engineers operate without context, then when design or development decisions need to be made, they must pause and track down the product manager, rather than make informed decisions themselves. Or worse, they made the decision anyway and build software based on an incorrect understanding of the product vision, causing time delays or unused software. This friction disrupts flow and introduces undue waste in your delivery value stream

It’s Jira, isn’t it?

Seeing Jira called out, the bane of Engineers and others around the world, was almost comical in the accuracy. The one common characteristic of all the Product Manager options I mentioned above: They collect requirements. If you work in an engineering company, eventually an Engineer is going to expect their requirements in Jira, because that’s how they track work. If you work in a draconian engineering company, they’ll even be logging time against Jiras and using Jira as a replacement for email: Communicating entirely through Jira Statuses and Comments.

Unfortunately, this completely destroys any context that comes from a Feature as an aspect of a Product. Single features are rarely a complete Product, it usually takes a suite of Features to define a real product worthy of discussion. However, in this model of engineering, each developer only sees the details of the one feature or bug they’re responsible for resolving, and their only real communication is in the “Reporter”, who may be someone with real knowledge or could just be a “Jira Jockey” that entered the ticket. Or even worse, it could be an automated faceless system leaving the developer with nobody to ask.

This is where Agile works, right?

So, you may think to yourself: This is why we’re Agile! Developers will bring this up in Refinement for more details, or in Standup to get questions answered. In my experience, that rarely happens once a company gets to this point.

What usually happens in standup is engineers are talking to other engineers, and none of them have the full context of the ask. Maybe one of them had a meeting a few days ago with someone who did have the full context, but only got enough information to generate the ticket. This leads to one of a few scenarios:

Developers proceed at-risk with the limited information they have, just to close the ticket and preserve their KPI’s around open ticket time.

Meetings get scheduled, trying to find someone who has the answers to the questions. This results in a few hours or days of delay while you coordinate schedules and meetings.

Someone posts in a random generic slack channel asking for details. Someone answers, but you’re not really sure if they have the full context or if they’re equally confused just in a slightly different way. This is the worst of all, because you may get even more faulty information resulting in bad deliverables and more wasted time.

The Solution

They propose a solution of “First Team”, constructing cross-discipline product teams that contain members of every relevant vertical, as well as constructing them at every vertical in the company so that there’s a top-to-bottom focus on product.

In this design, the organization remains aligned top to bottom on what the “Product” is, and teams at the bottom maintain a more granular implementation-focused view of exactly what higher-tier groups have, maintaining alignment and allowing teams to move forward faster.

In their own summary:

Functional organizational structures make it easier to manage a company. Forming groups around common skill sets and capabilities with a functional line manager responsible for developing those skills and advancing careers is the foundation of any scaleup. But when team members begin to identify and align themselves with their functional group, tribalism can set in and friction between teams is created.
It’s easier to remove interteam barriers when both teams report up to the same manager or executive. This is why the last barrier to fall in many organizations is the one between Product and Engineering. Operating as a unified Product Team is central to creating intrinsically motivated teams that thrive at delivering business and customer value.