How the x.ai process evolves | Tech News

One of the things we value most at x.ai is a relentless approach to bettering our product and ourselves.  We’re building technology for which no prior model exists for us to learn from. Because we’re writing the precedents ourselves, we have to leave our egos at the door and constantly question one another.  Are we building the right thing? Are we discussing this from the right perspective? Are our current assumptions still valid?

It’s crucial that we don’t limit this mentality to the code we write and the features we build. This is a value that permeates our team culture. I’d like to talk here about how our development process has evolved over the last year, and the lessons we’ve learned.

The Former Model

About a year ago, our CEO Dennis Mortensen published this post on how we were organizing our team at the time.  The article talks about our desire to retain autonomy and creativity for our developers as we scale our team.  We hire people we think are going to do an amazing job, and we give them space and support to do great work.

But we learned that if you’re not proactive about giving people the context necessary to make good decisions and outlining communication standards, you’ll quickly become overwhelmed.  Context is vital to making good decisions, and if you truly want to build great products, you have to make a concerted effort to make sure your team sees the whole picture.

Previously, we had perhaps too idealistic a view that once our tech team knew what the company’s high level goals were, each individual would be well-equipped to decide what to build.  They could rally around projects that anyone imagined. This approach maintains the spirit that we trust our developers to be amazing and make great decisions, but there was very little in the way of guard rails for decision making.

It was a little naive to expect our developers to be making all of these decisions themselves.  We shied away from roles like product manager, cross-functional partners and tech leads in an effort to give full autonomy to our developers.

Don’t get me wrong, our team is comprised of some of the best technical minds I’ve known.  They can break down tricky problems with a dogged perseverance that is truly inspiring. But if we can’t help point them at the right problems, we’re doing our company and product a disservice.  We saw that work was getting done, but we weren’t having a unified impact in targeted directions, so we made some changes.

Where We Are Now

The first thing we did was introduce some parts of the Agile methodology.  Aligning our team on the same cadences allowed us to get into a rhythm. Our whole team operates on a 1-week sprint cycle with planning on Monday, daily standups and a demo day on Friday.  Cadences and synchronization help limit ad hoc meetings that interrupt developers’ flow, and the weekly demo day encourages our team to ship smaller incremental improvements all the time.

Then we introduced some useful constraints.  It’s vitally important to maintain a balance that allows our team to express themselves and be autonomous in their work, but gives the right amount of direction so they aren’t faced with an entire universe of possibilities.  By giving specific, measurable goals to our teams and pushing some WIP (work in progress) constraints, we get a lot more focus and concerted progress to our company’s most important objectives.

We also organized into cross-functional workstreams.  Each of our workstreams have PM’s and cross-functional partners specific to their team.  Our Enterprise Success team works closely with our Sales team to figure out what the market needs for us to build.  Our Growth team works closely with our Marketing and Customer Success team to figure out the best ways to help our customers find value in our product more quickly.  The workstreams have the right partners in place to gather all the context needed to make great decisions, so each team can autonomously work towards their goals.

In addition to adding the right partners to our workstreams, we made a concerted effort to provide useful data for decision-making.  One of our teams organically spun up an internal Customer Intelligence team whose main focus is to provide insights into customer pain and specific areas where we can improve the product.  It’s been so beneficial that other teams have adopted similar partnerships. Where we don’t have data to inform our work, we try to de-risk projects by working on smaller deliverables in tighter cadences so we get quicker feedback and ineffective projects don’t drag on for a long time.

Importantly, we agreed on some high level principles and things to be aware of, and let each of our teams modify their own process as fits them best.

Has it worked?

In many ways it’s worked really well.  In the past year we’ve made great strides in the quality of our product, and more importantly we’ve built a team that can assess needs and act quickly in most cases.

But we haven’t solved everything yet.  To be frank, one of our teams felt the cross-functional partnerships were too tedious and actually took away much of the autonomy that allowed them to do great work and feel great about it.  So we adjusted things to empower them more by drawing a clearer line of responsibility between the the developers and their non-technical partners, making sure the developers get all of the useful context from them rather than defined solutions, and the developers themselves have more autonomy to scope their projects to address the problem areas their cross-functional partners illuminate for them.

The important thing is that we proactively evolve and don’t become slaves to a rigid process.  We’ve encouraged a culture that invites open challenge and debate, and it’s been great to see the team really scrutinize and evolve how we can best work together to solve problems that are both new and very challenging.

We’re always looking to hire great people, so reach out if you’d like to join!