Exploring Optimistic Governance with James Ross

James Ross is CTO at Envato where he manages a distributed team of 150 technical staff. His experience has ranged from building packaged products to large enterprise systems to research into compilers and languages. James has been around in agile circles long enough to remember when suggesting working in an agile way was a career-limiting move. Now that it’s a career-limiting move if you don’t profess unwavering loyalty to everything agile, James finds himself frequently spending the opportunities he gets to use a microphone to call out some of the many ways we might be getting agility wrong. Here is a transcript of the interview with him, edited for brevity.

Tell us about your role and what Envato does?

Envato is in the business of helping people get creative projects done, and we have a whole portfolio of eCommerce websites to help with that. One of the reasons people might not know what Envato does is because we have a lot of domain names other than Envato. “ThemeForest” is one of the popular ones; it is in the top 500 sites by traffic on Alexa. We also have one of the biggest licensers of royalty-free audio in the world, through Audiojungle.net. I head the technology function here.

Tell us a little bit about your team. How big is the team, and where are these people structured into functions?

Envato is about 500 folks worldwide. Our two most significant locations are Australia and Mexico, and then we have a bunch of people scattered around the world working from home.

We have about 150 in the technology team which spans Software developers, Technical leaders/managers, Architects, Security and DevOps

We also have product, design and program teams that support cross-functional initiatives.

Our development culture is built around approaches that go back to extreme programming, with a big investment in automation that allows us to ship multiple times a day and we don’t have a manual testing team.

Are most of the Tech and Product teams centrally located in these two offices or are these teams distributed?

The Mexican team is office-based. The Australian team is very flexible and remote. Of the 150 people, about 100 people work in Melbourne and they probably only come to the office about half the time. Another 40 or so who live outside of Melbourne, and they work from home.

We have a remote culture that we’ve evolved in recent years with most of the communication happening via Trello, Slack, Zoom and other tools. We are quite widely distributed, but not entirely distributed, as many of the team still choose to work from head office.

You are a big believer in Agile, I am curious to know how you make Agile and Distributed team (not co-located or remote) fit together?

We’ve probably picked it up from the open-source community, where the work is defined in small enough chunks that an individual can do and it’s done in a very transparent manner. I think transparency is super important because when you have a distributed team, you can't see what they're doing, because they're not sitting next to you. So, How do you tell what's happening?

Adopting Open source norms of pull requests indicates that you have a culture where feedback is welcomed, and actually expected. We don't have people with special roles like a release manager. I think you have to have a lot of fairness in the privileges that people have so that they're not blocked all the time.

We have developers who work in a different timezone, supporting our systems overnight, and there's nothing stopping that developer releasing software if they feel they need to. It wouldn't work without the people having a lot of autonomy so that they can do the fix, and actually deploy the code into production, without waiting for approval from leadership or head office.

I also think we are not hugely distributed in time zones, though. The folks in Mexico own their products completely and they release it just as fast as the releases we make in Melbourne.

Part of the answer is not distributing it too much. We haven't got many teams that are spanning a 12-hour gap. The Mexican team is mainly in their timezone, and the teams working on the products that are developed in Australia are within a three-hour timezone.

We have consciously chosen not to make the timezone difference too much for an individual or a team.

One of your latest passions seems to be systems thinking, tell us a bit about that?

I’ll start by making a book recommendation - Thinking in Systems: A Primer by Donella Meadows. It’s a fantastic book and I don’t think I knew what it meant until I read that book.

The belief is that everything's connected and there are no side effects, only effects. To design a system, you have to own and take responsibility for the side effects.

An example would be companies in the economy should not be allowed to take the profits without dealing with pollution. Everything is connected. You can't run a business without having things happen that you wish didn't happen, and it's about seeing the whole picture, and not just keeping the good bits, and letting someone else deal with the bad bit.

Envato culture heavily emphasizes autonomy. we like our teams to be able to make their own decisions, release software quickly, make the technology choices that are best for them, so even though I'm the CTO, I don't decide what technology we use in every product, because we want the team to take as much responsibility as possible.

The problem is you don't just get to, in my view, the systems thinking view is that you don't just get to keep the best bits of autonomy without dealing with the bad bits of autonomy. What I mean by that is if all you have is autonomous teams, then it's very hard to have any kind of consistency.

When I apply systems thinking to Envato, I love the autonomy, and I push hard on the autonomy, but I don't forget that I'm going to accidentally create inconsistency. That means I have to create mechanisms to mitigate the worst effects of the inconsistency. Looking at it as an entire system, I can't just turn all the autonomy dials up and call it done. I have to turn those dials, and then put some balancing structures in place, so that the autonomy isn't just chaos.

At some level, it's actually autonomy with some governance, right?

Yeah. Internally we call it “optimistic governance”, akin to optimistic locking.

During my research I found a statement made by you - A Good Programmer Cares, what did you mean by that?

The source of that was that somebody in Envato decided to do a blog post where we shared our view of what a good programmer is. You've obviously seen that, and most of the team had their answers on aspects like good design, good testing etc, I gave my one-word answer, and the reason is that if you care about what you do, then all those other things will just happen. If you care about what you do, the first thing I want from a developer who works for Envato is that they care about Envato. That's the first thing I want because we're not actually here just to write code. We're here to help Envato do what it's trying to do. The caring about the company you work for and what it's trying to do provides like a compass reading for you.

I think of it as an emotional compass. What's best for the company? It's not what's best for me, it's what's best for the company. And then if I care about my craft as a programmer, if I care about programming, as a profession, and as a skill, as a craft, if I care, then I'm going to be a lifelong learner.

You just can't be a good programmer unless you're just constantly learning, constantly trying things, constantly taking risks in what you do. That comes from caring about the profession. By saying, "I care about what people think is a better way to do things. I read blog posts about some new language, or I'll read about some approach that is not the way we do things." We're predominantly a Ruby shop. We've historically got a lot of Ruby and Rails, but we've got certain subsystems built in Elixir, and others in Go, and others using an event sourcing architecture.

If you care, you'll constantly look for a better way to do things, and that is just, in my view, essential. If you care about the people you're working with, if you care about your team, you will be a better colleague, you will be a better collaborator, you'll be a better team member. That's what I want from a person who works in the technology team, not just Envato, anywhere that I work, I want someone who cares about the company they're working for, they care about what they're doing, they care about the people in their team, and they care about their profession.

What are your top three priorities as a technology leader of Envato?

Some of these would change year to year, the ones that would be fairly stable are - Are we balancing the short-term with the long-term well? Are we balancing doing new things, taking technical risk while delivering value? Are we providing opportunities for people with getting stuff done?

I feel like I'm always looking at the whole system, bringing it back to systems thinking, and looking for where it's out of balance.

I'll give you an example. Several years ago, like everybody else, we migrated to AWS. We were on a hardware vendor, like everyone else in the last couple of years, we've moved to the cloud. And one of the things that become apparent when you first move to AWS is that developers suddenly can accidentally spend a whole lot of money. A whole lot of money, because they have API credentials in there, and they can just run an API command, and spin up instances and forget that they left them running. That was one particular financial year where I didn't think we were in balance with our autonomy and our financial control. During that year, I introduced some more mechanisms to balance autonomy with some transparency and accountability.

In another year, we didn’t seem to be consistent with security baselines. The bar was higher for teams that were being led by people who are just truly passionate about security when compared to other teams being led by people who are commercially driven i.e they are focused on delivering features that generate revenue and never really had much exposure to security.

I feel like every year, there's a couple of things where I'm saying, "I think we're out of balance here, and I want to pull this back in."

Have you ever felt that there are 8-10 product lines to manage and maybe should we pull back on some of these? Have you thought about it from a business or from a technology perspective that some of these are probably not giving me enough value back to us?

Envato is like a mini Y-combinator, There are lots of little ideas. A little amount of money across lots of ideas, and every now and then you get a Dropbox, Airbnb, and everybody's happy.

Given the autonomous nature of the teams - they move fast, start/stop things and pursue the ones that work. In the past our teams had the option to choose their own brand, marketing, manage P&L, etc.

Some of them had massive commercial success, some medium and some small successes and some failures. So it’s a valid strategy to just get rid of the ones that are unsuccessful and just focus on the bigger ones.

And we've certainly killed lots of unsuccessful ones. What we realized was that nobody in our competitive environment had the breadth we had, Shutterstock has photos, and Pond5 has video, and someone else has something else, but nobody had all of it. So, we decided that, strategically, we wanted to pull everything together, make Envato the brand, and put it all together under a subscription. And that's Envato Elements.

That was the strategic path we took to not just get rid of the weaker ones but to bundle everything under one subscription.

Envato has a very, really high-quality educational property called Tuts+. You can learn all sorts of skills. But, in terms of competitors as an individual product, competing with Lynda.com, I remember thinking, "Oh, dear." Tuts isn't going to be able to compete with that.

But, it's fantastic. The quality is really, really good. What we've done is make Tuts part of the Elements bundle. So as part of the one and half million items you can download, you can also learn JavaScript, and React, WordPress, and all that stuff, which might mean you don't need the Lynda subscription. So if we pull it all together, as opposed to sending Tuts out on its own to compete with Lynda, and this site out on its own to compete with that other site, that's the strategic decision we made.

If you had to go back in time when you took the first job as an engineer or as an engineering leader, what advice would you give yourself?

Buy, Bitcoin, Just kidding.

What I would want to have learned sooner was that it's much more important to be building the right things than to be building the thing, right. You learn certain things and you think that's the way it's done when really it's just a way to do it.

I'd probably want to learn faster to be more ready to change my mind. I would encourage myself to have strong opinions but weakly held. It would probably amount to being more collaborative, open-minded, and more focused on the why, I think.

One last question - How would you characterize your leadership style?

You should probably ask some people who work for me; you might get a different answer.

I do believe in trusting people, giving them a lot of responsibility and autonomy, but not in the dark. I have opinions, but I'm ready to change them by having an open mind.

Lastly, I make people laugh pretty regularly.

It was wonderful chatting with James Ross to get his views on diverse topics as well as experiences from the Envato journey, we thank him for this time.

---