Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Dysfunctions of output-oriented software teams

Freshness Warning
This blog post is over 1 year old. It's possible that the information you read below isn't current and the links no longer work.

When I see ineffective product teams, it almost always stems from a focus on delivering features instead of delivering value to people. From sales to marketing to product to engineering, they are more focused on output than they are on outcomes. They ask, "did we ship that feature" more than "did we and our customers achieve better outcomes?" No one asks if what the team is doing is really working.

John Cutler calls this a Feature Factory. Melissa Perri calls it the Build Trap. Whatever you call it, the symptom is that you’re measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.

An output-focused team doesn’t measure the actual impact of the work, doesn’t know what metrics are important, and can’t connect the product work to the whatever core metrics they actually do have.

Instead of metrics and objectives, they have deadlines and customer commitments. They can’t cut committed scope to meet these deadlines so they cut quality. They still miss the due date, and now have a product that is both bad and late. Other departments berate the developers for not providing more accurate estimates. No one ever asks why the word "estimate" means "commitment" in this team.

To fit things into the schedules and meet the estimates-turned-commitments, managers come in to assign and track tasks. The output-focused managers are more concerned with "resource utilization" as if the people building the product are machines. They don’t have well-integrated teams, leading to frequent handoffs between people, and siloing of knowledge and responsibility. Those handoffs lead to backups and gaps in the schedule, so they play team Tetris to try and keep developers busy, which makes the problems worse.

When an output focused team tries iterations, they defer important things to "later." Everything is pre-planned months in advance, they’re at full "resource allocation," and they’re always late with every iteration. So later never comes.

The managers try to fix all this by adding more top-down process, bogging down the teams. Things slow down, so the managers add more process to fix it and "hold engineers accountable."

How do you escape this method of working? Take small steps and look to continually improve. Start by defining success through outcomes and deciding up from what measurements will indicate you have reached those outcomes.

Accept that it’s OK if you aren’t always busy. Slack in the schedule is healthy and helps give time to explore and experiment. If you’re not focused on being busy all the time, you’ll be able to think more about creating a flow of value to the customer. Above all, empower people. Trust that the smart, capable people you’ve hired will do the right thing. Try managing through Commander’s Intent: define what success looks like, and then let them figure out how to get there.

Recently Written

How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.
Developer Experience Principle 3: Easy to Build (Oct 5)
A product makes it Easy to Build by focusing on productivity for developers building real-world applications.
How to understand your product and your market (Sep 30)
A customer development question you can ask to find out who your product is best for and why they'll love it.
Developer Experience Principle 2: Easy to Use (Sep 28)
Making it Easy to Use means letting the developer do everything without involving you.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.