BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Hannah Mittelstaedt on Restructuring Mobile Dev Teams

Hannah Mittelstaedt on Restructuring Mobile Dev Teams

Bookmarks
   

1. Hi. My name is Ralph Winzinger. I am a software architect and editor for InfoQ and I am here at QCon New York 2015. I am here with Hannah Mittelstaedt. Hannah, would you please introduce yourself to our readers and watchers?

Yes. I am Hannah and I am a developer at Etsy. I mainly do Android development and I have been working on their mobile teams for two years now, here in Brooklyn.

   

2. Usually, companies have some kind of specialized mobile team to produce their apps or maybe they even outsource mobile development and just do their usual web development and back-end development. Etsy does it quite differently now. So, could you tell us a little bit about this?

Until recently, we did it that way. We had a core mobile team of Android and iOS developers who built the apps, but after a while, we realized that we wanted to get the whole company involved. So, we did keep some things. We kept the app core to the infrastructure and the up-growth team. But, keeping mobile separate from everyone else building products made it feel like mobile was just one of many products and we did not want to be a web company that had apps, we wanted to be an App company and bake it into everything. So, we made the product teams all work on the apps themselves.

   

3. Do you still have native development for iOS and Android or did you also move to a, maybe, easier to handle, hybrid approach?

We are staying pretty much totally native. We are not letting the web teams sort of cheat and go back to web. I am not personally against hybrid and web views in all cases, but we felt that in order to give users the best quality experience. In the mobile space right now, we had to stay native. So, we have been teaching people native development.

   

4. Merging the mobile development and the rest of the product development – it reminds of Conway’s law to tear down organizational boundaries where they do not need to be, to get a better, integrated technical solution. Was this part of the reason?

Yes, totally. I think that actually, Conway’s law super describes what we are trying to do. So, before, when we were just the mobile team, I would be responsible for a lot of things that had been built on the web and what I would normally do is to look at what the web was doing and might poke around at it and then see what the API did and build something based on what I saw. But I did not know all of the edge cases and all of the user research that we do, that the team that built it knew. You can try to get around that, you can have a lot of meetings, but it is hard to keep up with those things in meetings. You are just never going to have the same bandwidth communicating with another teams, that you have within a team. We are just basically what Conway’s law says.

Ralph: You mentioned you had a look at the stuff that a web team was doing and you tried to realize something similar to that in an app. What about “mobile first”? It is very popular right now and I do not know how important is mobile first for your company.

Yes, it is totally important. It is like the big cliché right now, like you said, but that is for a reason, because a lot of the traffic these days seems to be coming from phones. So, it is definitely important at Etsy and that was another thing we were trying to get, to move towards, not this “web builds it and the apps build it, after the web throws it over the wall”, but shipping both mobile first, or at least mobile at the same time as the web, instead of this “mobile soonish” that ends up happening. So, that is important at Etsy right now as well.

   

5. How much traffic do you have on the mobile channels compared to the web channels?

Over 50%. So it is pretty important.

Ralph: That is right. Let’s talk a little bit about the benefits and the drawbacks of your transformation of your mobile development. I, personally, would expect that you should experience some increased efficiency and some quality in mobile development, maybe, because it is now closer to service teams or service development.

Yes. That is definitely true. Actually even before we broke up the mobile team, we sort of started on that path with API first, where we built the API to be used, not just for the apps, but also for the web teams. And that made a big difference because the people building the APIs are also consuming them, then it makes them a lot better. If everyone is using the API, then it makes a lot of sense to work on how fast it is and tune the performance. So, that has been like a big benefit of pushing everyone to think about the apps more and that has been carried forward as all these teams build the API and then they can do the front-end across all the platforms.

Ralph: That sounds pretty straightforward. I guess my next question is already answered because sometimes I stumble across APIs and you just look at them and then you think “Well, I could use it for mobile, but it is not designed with mobile in the mind.” But that was not a problem at Etsy anymore.

Right. But it definitely was before and it was a pretty recent change. When I first started, the mobile team could but heads with the API team sometimes because they were working on cashing and the API team wants features that mean that they do not have to make as many round trip requests for every page load and the current API just did not work well with everybody’s desires. So this new “API first” thing also meant that we built a whole new API platform, the V3 API for Etsy. So there is a lot of work, but it is making everybody’s job better now, I think.

Ralph: Who was involved in that API? I guess members of the different teams.

Yes. Early on, mobile was working sort of separate and there was the core infrastructure team that was working on the APIs. They were doing really great, but things were definitely better once we started communicating more about each other’s needs. So, I went and sat with them for a little while, while we worked on the early version of the API and integrating it in the Android and seeing how smoothly that went and if anything, you did tweaking. And then they were great about hearing any feedback we had.

   

6. Are there any additional benefits that one might not expect?

Yes. Those are mainly benefits from the infrastructure side. We could have done API first without doing this big reorganization of mobile. The reorganization of mobile was really for the product teams. So, the products we are getting – built on web, later on mobile – the benefits now are that you have more consistency in what is getting built across the platforms and that has been really great.

Ralph: You have that end-to-end responsibility of the team for the whole product and not part of the product and another team is doing some kind of channel

Right. And then the users are not just confused when they see some features on one platform and not on another. Things like that.

   

7. That is right. What about the drawbacks? I do not believe that there are just benefits there. For example, is it harder to recruit for a product team now that you also need mobile expertise?

Yes. That is a good point. Recruiting is really hard. Despite the best efforts of our recruiters, there seems to be a real shortage in mobile developers right now. So, our plan was just to skip the recruiting all together and we actually have two mobile trainers in-house and we are just training our current web developers in native development and that has been really cool. We did not want to force people to do native development so we trained lots of people and we have people who have an affinity for it start contributing to the Apps. So, that mainly sounds all good. It is really hard, though and it takes time and these people have to get up to speed. But it is nice to invest in your own people and then you do not have to get new recruits trained up on how Etsy does things. So there are some benefits on that end, I guess.

   

8. How long does it take to train people to really be ready for taking work packages from the mobile space?

It takes a lot of time and it is going to depend on the person. You can do a couple weeks of training and that does not mean that you are ready for mobile development. But a lot of it is just sort of diving in. So, it has been 6 months since we made these changes and I do not know that there is any new people that really feel super comfortable yet. Even the people that I think are doing really well – they will come later and tell me how frustrated they are with how slow they are going. And I say “My God, you have been writing great stuff!” So, it feels kind of bad for a while, that you are going slowly in learning a new thing, but we have shipped a lot of new stuff on different teams this year and I think that by the end of the year, it is going to feel a lot better. There is going to be a lot more expertise around.

Ralph: I think so. I remember I was working with a colleague on a mobile prototype and he is in this Apple ecosystem now for, I guess, 15 years so he just knows the tools, he knows the classes and it was really frustrating to see how fast he was and how slow I was. But, we have to get over this.

I have the same thing on the other side. I am terrible front-end developer, but I have been pushing through it. So, I know how they feel.

   

9. Are there any other disadvantages you have encountered?

Other disadvantages – yes. Like I said, there are some benefits to having the product teams build the platform for consistency of the product, but on the other side of that, you are splitting up a team that was working on Android. So, the consistency across the App is going to suffer a little bit, because we used to have people working very tightly together and now they are on different teams and it is harder to communicate about design decisions and product decisions and keeping them consistent and also write new code – things like that. So, that is harder, but I think it is the right direction to go in. It is sort of like how on the web teams, we do not have a team of front-end developers that do all the front-end work. All the teams do their own front-end work. But we do have mailing lists and the weekly “front-end” lunch. So, mobile is moving more towards that. We are not working next to each other all the time anymore, but we are doing more communication over e-mail and in specialty meetings.

   

10. Do you still have some kind of special, mobile task force for, I would say, for the not day-to-day jobs, like “we have to dive into Apple Pay” or whatever?

Yes. We do have App Core which works on infrastructure. Right now they are doing a lot of stuff on the analytics stack for the Apps. We have App Growth, which is a special team just for cool App things that would not necessarily fit into other teams, as well as growing installations, but they just did the Apple Watch. That was something that other teams were not thinking about. We also did just integrate Apple Pay, but that was the payments team, so it kind of fitted under product. But the payment team took that on themselves.

Ralph: Did your development process get more complex because of that merge? At least the iOS tool chain is quite different from a normal Java tool chain. So, it is hard for me to imagine how this could be well integrated in one development process.

So, I would say that for the most part, it is not one development process and for the most part, the new people that are learning mobile, they are not learning both platforms. They are usually just picking one because they are so different. The Android and iOS teams have always worked pretty closely together and we tried to keep the tools similar where we can and we would do things like have the same Git workflow and decide on that. But, they are pretty different. That has always been the case. There have been some new things that are more different than they used to be or are more the same then they used to be different for me which is we used to just release independently. Whenever we had done like a big chunk of work on a feature on Android, we would ship it ourselves an hour on a release cycle and that has been a lot to get used to. Being on like a set release cycle, both Android and iOS shipping at the same time.

   

11. When you started the transformation to bring mobile development to the service teams, how confident have you been that you would really succeed? And was it some kind of global rollback potential the scenario?

That is a funny question. I did not really go around to ask everyone to rate their confidence. I definitely have some misgivings. I had actually gone with my co-worker Mike to do the Facebook mobile forum and we asked a bunch of different App companies what they had done to scale their mobile apps and we talked to quite a few of them who said that they had tried something like this, and then abandoned it because it did not work. So, that was really scary. But we decided to move ahead anyway, because every company is different. I do not know that we really had a plan B, though I trust that Etsy would be flexible if things weren’t really working. So far they are working pretty well though and I have been surprised by how well it is going in a lot of senses.

Ralph: Great. Congratulations.

I do not know if I would say that this is the right thing to do for every company. Every company has a different situation, different sizes, will have different solutions, but it has been working for us, I think.

Ralph: True. Also, I think it is a kind of a cultural aspect that you happen to have the right people to really learn and want to learn mobile development, for example.

Yes, I do think that that is a big part of it. Etsy has always been really good at having developers sit on other teams and learn from them and do rotations in other teams and cultural learning, in general, and just openness. I think that if Etsy was less open between the teams, it would be worse, because sometimes they see a team and say “What are you doing? That is not what Android looks like” and they are like “Oh, that is great feedback. Thank you” If they were not like that, or if they were not really eager to get code review feedback from the Android developers that came before - I have been code viewing a lot of new people and they really respond well to feedback, they are eager to change things – if that were not the case, then it would be hard to have a bunch of new people contributing without having things get shaky.

Ralph: OK. So, well prepared in the mindset.

Yes. It is mainly a battle of the mind, I think.

Ralph: OK. So, thank you very much for your insights and congratulation for the transformation. It seems to be successful.

Thank you. It is still work in progress, but yes.

Ralph: It sounds successful. Thank you and have fun at QCon.

Thank you.

Aug 30, 2015

BT