When I first joined Axial, the product and engineering side of things was pretty broken, and there was a serious absence of trust. The team didn’t trust leadership, and leadership didn’t trust the team. The rest of the business — actually, even worse, customers — didn’t trust product/engineering.
The culprits may sound familiar to some of you:
- Features took months to ship, if they shipped at all.
- Customers had been hearing certain promises for years that never came to fruition.
- The customer success team felt like they were having to carry all the weight to compensate for a broken product.
- The engineering team was pushed to honor time-based estimates, leading to a feeling of constantly being thrown under the bus and an unhappy on/off cycle of burnout-level effort and low effort.
- Feature ideas were good but the details were often wrong because the team didn’t invest in building deep domain knowledge. There wasn’t enough qualitative research, let alone experiments.
- The team didn’t follow feature releases with incremental iteration to correct any mistaken assumptions.
- The company, let alone customers, felt disconnected to what was being worked on or why. If anything, they were cynical based on hearing about big, shiny new features that would be the new savior, but really just were bloated designs that didn’t move the needle.
- Product, design and engineering were not truly in sync. Engineering wasn’t getting involved early enough, and wasn’t pairing with design late enough. We had rough cross-functional teams, but they didn’t have clear, outcome-focused goals.
- Bugs were popping up too frequently.
- Morale across the board was low (how shocking!).
It took a painful year, and we’re not done by a long shot, but we’ve fixed a lot of those problems. The company now trusts the team significantly more because they’ve seen months of continuous improvement. We’ve worked hard to over-communicate, and to make the rest of the organization feel heard. And while it is a multi-month process, customers are also starting to believe in the changes we are making.
- We ship multiple times a day (even if some efforts do still run for weeks).
- Rather than thinking in sprints, we think of software as a continuous process. We shifted to weekly iterations and dropped any pretense of calling things in or out of a sprint.
- We hunt for find the right balance of minimal and viable, but we manage scope aggressively because we know truth lies outside of the building.
- We don’t abandon our features but iterate them to fix our major mistakes. (Jeff Gothelf once joked that “phase 2 was the biggest lie in corporate America,” and we’ve worked hard to make that not so.)
- We externalize our roadmap with a Trello board, monthly presentations, and a weekly summary on Jotto, our internal blog.
- We run our own qualitative research and also try to stay close to the member success teams.
- We run experiments against risky assumptions for major feature ideas (and have indeed pulled the plug on some ideas). We also externalize the results of our experiments on our internal blog.
To get here, we had to invest in some big changes:
- We paid down some major technical debt (albeit not without some painful mistakes and lost time) and continue to take tech debt seriously.
- We took some risks and attacked the core of the product, which the company had been delaying for several years.
- We had to part ways with some talented people who either weren’t ready to make changes or had too much mental “water under the bridge” and couldn’t reset.
- We invested in code reviews, got disciplined about code test coverage, and continued our investment in dev-ops.
- While not scalable for the long term, to be very frank, it helped consolidating product, design and engineering under one executive.
We set values for ourselves and worked to live by them. Morale has risen across the board. Our pace is up. We’ve even gotten to the point where our cross-functional teams are owning their own goals and OKR quadrants (see Wodtke) rather than having that be top-down. We still need to get better at road-mapping and running qualitative research with folks who aren’t yet customers. We want to see even more aggressive lift in our metrics, but our execution capability has been transformed.
It’s important to walk the talk.
Last week, we were expecting to ship a new feature that was going to improve the initial user experience for paying members. On that Monday, I had told the entire company that it would be going out. By mid-week, it became clear that, due to some unexpected re-factoring (issues that became clear becausewe no longer shortcut test coverage), the release was going to push into this week.
Six months ago, resetting expectations would have felt painful because we were trying so hard to rebuild credibility. These days a change in plan is no longer viewed with cynicism, but taken with more of an attitude of “thanks for telling us, we know you’re doing your best.”
People removed from the development process will always struggle to understand the truly hairy complexities of software, but that is ok if you can build up a bank of trust. It takes time, a lot of communication, and the consistent effort of putting one foot in front of the other.
Cover image credit: Larisa Birta, Unsplash