The mission of Off-Grid Electric isn’t modest or obtuse. Simply put, they’re trying to power the underpowered world. Through a distributed solar model (based on next-generation lithium batteries), they are attempting to provide clean, affordable energy to homes off the electrical grid. While they are currently focused on Rwanda and Tanzania, they intend to light the whole world.
We spoke with CIO Thor Muller about their logistics, challenges, and how Tracker helps with both.
The nature of our product is different. I used to describe what we do as solar as a service for markets that have either no grid, or a very poor grid. In the case of East Africa, 70–80% of the population has no access to the grid, either because it’s too expensive or because it hasn’t reached their part of the world. Those are the two main reasons. For those who do have the grid, it goes down all the time. They’re grid poor. The question is—because this is the sunniest part of the globe—why don’t they use solar? Especially now that solar has come down in price. The answer is that these are people who are largely unbanked, and they look at this as risky. The poor are the most risk-averse people in the world, because they are often a few dollars away from not being able to eat.
Their parents use kerosene, their neighbors use kerosene, they heard about somebody who used solar, but it broke. You’re coming in and trying to get them to leapfrog this dirty technology, which really kills people and isn’t all that cheap, and you have to do it in a way that actually reduces risk but gives them not just equivalent value, but 50x or more value. That’s what we have to do. That’s why when we came into market, we focused on providing solar as a service.
We do this in a way in which they could essentially put very little money down, essentially the amount of money they pay for a month’s worth of kerosene and then they make monthly payments against that.
It’s a solar panel you put on the roof. You put cables down to a box that has a lithium-ion battery designed to last a long time, and a controller in it with a key pad and then, of course, all the jacks for plugging things in—the appliances and phones and all that. The controller locks access to the battery and thus the power generation. For an additional cost, we send them back an unlock code, which they then type in that unlocks it for another month. It’s very similar to how they use their pay-as-you-go phones. It covers all of their lighting needs, giving them much more light than they ever had with their kerosene lanterns, but also allowing for phone charging and now radio and television.
Right, exactly, so they can use more energy, which allows them to think differently about how they use their products, how they use their phone—which is, frankly, the most important thing, the most transformative device in the world today, not just because we have lots of fun apps, but because for this part of the world they’re now able to connect and engage in the economy in a way they couldn’t before.
Oh, yeah. We have to be careful to not get ahead of ourselves because, internally, we see all these opportunities, and externally, people come to us and say, “Hey, we want to participate in the developing world or in Africa, and you’re the foundation for that.” It’d be very easy to do partnerships all day and get nowhere with our business. We’ve tended to be relentlessly execution focused. Right now we have about 900 employees in the East Africa area, primarily Tanzania, but also Rwanda, and we’re expanding beyond that. They are primarily doing things like sales, service, in-home service, installations, and logistics.
There’s no logistics networks there; we have to build our own, which brings us to where software comes in. The business has to coordinate the activities of a large distributed workforce, and that distributed workforce includes everyone from the managers who are defining the playbooks, to the salespeople who are engaging with people in these communities, to the installation agents who are being guided through the installation process, to the service agents who are doing troubleshooting. On top of that, the boxes can communicate more or less directly with us.
I do think there’s something about internalizing the principles of Agile organizationally. For us, the Agile mentality is an interesting challenge. This company was a startup with a much smaller number of people and customers 18 months ago. Honestly, you could make a change and it would spread through the organization in a couple of days. Not everybody would be happy about it, but it was possible. Today, when you have regional operations with well-educated regional managers all the way down to contractors who have never used a smartphone before, the implications of every change are very different, and it requires a choreography to make all that work. At the same time, at the speed these markets are changing, you have to be Agile.
On the software side, we do continuous deployment, so we’ve had to create multiple levels of abstraction to enable us to move at the speed that we want to move. For instance, we’re now pushing changes in the continuous deployment way as quickly as we can queue in your code. That’s only visible, of course, to a limited number of people who then have certain checks and balances that allow them to make sure the people are trained, all the way down. Then there are certain groups—let’s call them alpha users within our system—who are those same contractors, but they are interested in being part of the change, and we roll things out to them at the pace that we can push. The Agile architecture that we’ve had to build is very different than I’ve experienced, but it’s interesting to play in the sandbox and see if we can do it.
Always the question. Our cadence is pretty close to a Pivotal Labs cadence in that it’s a backlog model, where it’s rolling. We have an IPM on Monday mornings, and to get there we have several other process points that are designed to enable us to be Agile. We have what I call the “blood and bone” meeting. Blood and bone is designed to interface product management with operational counterparts—people in sales and services and logistics. They always have their hair-on-fire issues, and they always want to know where the initiatives are standing. You can do this with email or Slack, but it’s not the same, so we instituted the “blood and bone” meeting, standing for “software and data.”
This basically connects the road map, but also creates space for emergent needs, triage, bugs, and just things that have happened. Then we get in sync; it’s really a synchronization meeting, and a place to service issues with operations. We also talk about deploys, so if we’re in the final stages, we’re about to deploy a bunch of stuff. We talk about how we might operationalize those things, so that’s an important point. That directly plays into the planning for the IPM, and the PMs have their own sessions to work through that. Then they go through Tracker to get that organized. We have several Tracker projects: one for mobile, one for the data infrastructure team, one for all the other software, plus we’ll probably break another project or two out, but right now everything else is in there and it works remarkably well.
Yeah. In prior companies, there’s always an issue between business people who have a deadline they want you to hit, to which I always say, “Have you ever renovated a house?” I walk them through the uncertainty principle and whether or not they want to be lied to. They always get that, but when it comes down to it, they want a timeline, they want commitments, and I want commitments, too, frankly. I want my team to aim for something and do what it takes to get there, but understand there are tradeoffs along the way. Something’s got to give if you discover that, “Oh, this is a lot more work,” which you usually do.
It’s the right form for managing stories with developers. Asana is not good—it’s too noisy and it doesn’t have the innate development focus. We also trigger a lot of things we could have and so forth. Secondly, for us, iteration planning using velocity is really useful. We don’t take points too seriously, though it’s a good rough guesstimate.
We have had difficulty, though I’ve done that with other groups and they’re usually doing it during IPM if it’s unpointed. We usually point ahead of time. Here we made a mandate that the stories had to be pointed at least a few weeks out in order for the PMs to be able to do their prep work for the IPMs, which we asked the developers to collaborate on.
The thing about Tracker is that it’s as simple as moving around story cards, but way better because you have all this other functionality. I pretty much looked at everything that I could look at. At the time, we were integrating Asana and I looked at that and thought, “What if we just consolidated on Asana?” At the end it was an easy choice to make. It’s the right tool for the development culture we wanted, and it allowed us to provide transparency to other people to see it. The other thing is that some of these tools like Fabricator have a lot of functionality, but they don’t provide much in the way of helpful structure. I’ve found that one of the great benefits of Tracker is that even if you don’t agree with every little thing that Tracker does, the structural guidance it provides really amplifies good behavior and clarity. I haven’t found anything that matches that especially now that I have Analytics.
I honestly don’t know what I would do without Tracker because no other tool feels like it moves at this speed with which we move, or tightness of coordination.