Bryan Dove, Senior Vice-President of Engineering at Skyscanner, talked about how to do change in organizations from within and how developers and managers can work together to understand and adopt modern software engineering practices at the GOTO Berlin 2015 conference.
InfoQ interviewed him about the major technology developments from the last 10 years and the impact these have had on the way that we are creating software products. InfoQ also asked him what managers and developers can do to explore and find better ways of working together and how they can support each other, making themselves and the company more successful.
InfoQ: What are the major new technology developments that we have seen in the last 10 years?
Dove: The last 10 years have seen tremendous advancements in commoditizing technology that was previously available only to the largest software companies in the world. This commoditization makes it cheaper and easier for new companies to quickly deliver value and have technologies that easily scale to consumer internet demands. Virtually every standard component of the software stack a brand new startup would rely upon today has been created in the last 10 years and as an open source project. Hadoop / MapReduce were inspired by Google's Map-Reduce paper and then Yahoo's implementation and subsequent open sourcing. NoSQL engines inspired by Amazon's Dynamo paper, such as Cassandra that was built and open sourced by Facebook. Other common building blocks such as Docker, Mesos, MongoDB, etc... All of these have been created and released in the last 10 years and have reduced the effort to create and scale a technology platform by an order of magnitude or more.
In addition to software, we've seen the emergence of the public cloud, starting with the AWS launch in 2006. This sea change has brought at-scale economics to the masses and shift the deployment of capital from expensive data centers and hardware to focus almost exclusively on employees to fund IP creation and pay as you go economics of hardware in the public cloud.
InfoQ: What's the impact of these developments on the way that we are creating software products?
Dove: Similar to what I've mentioned above, the net impact is that's it's easier and faster than ever before to create products that deliver value to users. Previously, companies had to build all of their technology from scratch and building for Internet scale from scratch is really tough. Today, any company can pick up a suite of open source technologies and gain massive scale with minimal effort. At Skyscanner, where I’m SVP of Engineering, we offer up our API for start-ups with a free starter tier, open sourced a number of our internal projects on github.com/skyscanner, and we use a number of open source technologies internally.
InfoQ: In your talk you gave an example where you were working on great stuff but didn't tell your manager about it. Can you elaborate what happened? What did you learn?
Dove: The scenario I mentioned is that I was doing what I thought was best for the company. Working at Microsoft, I forged an internal partnership with the SQL Server leadership team to work together on building some new analytics software that operated on consumer internet scale big data systems. I felt as though I was doing the right thing for my team, my business, and the company.
The mistake I made was that I didn't think about the position I was putting my managers in. They did not have the details of our progress or the partnership with the SQL leadership as I was managing this directly. This created a risk for them that they could be asked about how our businesses were working together and they wouldn't have the details.
In terms of learning, I had two key takeaways that have shaped my thinking going forward. One is to opt for over communication and radical transparency. I had previously done this with my team, but now I operate this way in all directions in an organization (e.g. Manager, peers, team). Second is that I now focus a lot on simplifying my communications for my peers and my manager. Since my peers and managers are receiving a ton of information from many sources on a daily basis, I try to get them the bite sized headline of what’s critical and then look for them to ask for more information if they want it. If they ask for every detail, I’ll certainly share that, but I wait for the ask instead of share it by default to help them focus on what’s critical first. If you give people the headline, conclusion, and recommendation, they will always ask for more detail if they need it. At Skyscanner, we use snippets as a mechanism to share information while preventing information overload.
InfoQ: You showed how developers can create a managers backlog where they can put stuff for which they want their manager to help them with. Can you give some examples of things that were on your backlog? How did your manager help you?
Dove: A good example here is when I was leading the data efforts at Skype, we had a need to build a modern experimentation system. While it was easy to communicate the ideas to those that had worked with modern experimentation systems in the past, I was struggling to get the broader organizational support to get the effort funded and moving ahead. My manager and I agreed that it was the right thing to do so I asked my manager to take over getting the right support and getting the new team and service approved. For example, my manager took the time to connect with independent organizations elsewhere in Microsoft and use those teams’ experiences as external validation. External validation is always helpful in justifying new work since that group doesn’t have a vested interest in your team’s outcome one way or the other. Fast forward to today, the system that we envisioned has been built and is the primary experimentation engine for a large set of teams across the business.
InfoQ: How can managers help developers to do a better job?
Dove: I think as a manager, your responsibility to your engineering team revolves around a handful of principles. First, I find the 3 principles from Daniel Pink’s book “Drive" are very applicable to engineers — Autonomy, Mastery, and Purpose. I think about these three nearly every day and challenge myself to further empower my team and provide them with more autonomy than may be initially comfortable for me. In my opinion, distributed autonomy is the most important element to scaling a large team and something that is prized at Skyscanner.
The next principle is extreme transparency. One of the constant logical struggles with distributed autonomy is that there is fear that individuals won’t make the right decision. Starting from a belief that everyone on my team is smart, capable, and rational, then my job is to provide them with all of the information they need to make the best decision for the business. Any signs that I’m worried someone won’t make the right decision should be an instant trigger that I haven’t given them enough information to make the best decision. I personally opt for extreme transparency (e.g. Share everything that’s not illegal and is my information to share) because it’s one less set of decisions I need to apply of how to filter the information I share with my team. Now my team is armed with the same context I have and is much better positioned to make the best business decisions without needing to check for approval.
The next principle is understanding details and appreciating complexity. Engineers need to believe that their manager understands what they’re doing and understands how hard it is. Investing the time and effort to gain this knowledge gives a manager a better handle on what’s going on with their team and builds credibility with their engineers to trust that the manager is equipped to properly value their contribution.
The last principle I believe is critical for managers is to make mistakes in public. It’s well cited and repeated that we learn from failure far more than success. However, as a leader, you need to create an environment where mistakes are welcomed as learning opportunities instead of something to be ashamed of. One technique I’ve found is particularly helpful for doing this is to take a mistake that I’ve made as a leader and describe them as publicly as I can for my team. And then repeat every time I make a mistake. As a leader, this takes a lot of courage to show that level of vulnerability, but if you aren’t willing to do it, how can you expect your team to do so? I’ll typically do this either through an email update, a blog post, or talk through it at a staff meeting and share the mistake I made, why it was a mistake, what I learned, and what I’m working on to avoid making the same mistake again. By doing this over and over again, it reinforces the concept that mistakes are just learning opportunities and that it’s safe to be vulnerable, to make mistakes, and to learn from them.
At Skyscanner, we have programs that recognize failures and share learnings across our entire business. This has helped to create a company culture that is open and honest about what’s worked, what hasn’t worked, and how we learn from our mistakes and move forward. We call this ‘failing forward’, and the concept is based around the idea that without failure we cannot learn, and thus we cannot progress. The idea of failing can be uncomfortable for some – let alone the idea of sharing our experiences when we do encounter failure. However at Skyscanner we believe that we need to be comfortable with failure, if we are to continue to succeed. Such examples of failures provide us with key learnings that take us one step closer to success; they are the result of risks, tests and experiments that inform vital decisions that push us forward towards further success.
InfoQ: What can developers do to help their boss succeed? How would that help them?
Dove: There are a few things that an engineer can do to help their boss success. To start, it’s important to understand what are your boss’s goals. Just as you have your goals as an engineer, your boss has a set of goals that she’ll be measured against. Next, be willing to share credit. Harry Truman said "It is amazing what you can accomplish if you do not care who gets the credit” and this is especially true when you’re working as part of a team. If you focus on what you’ve delivered and the value you bring to your users, then it doesn’t matter who gets the credit. An example of how an engineer can help their boss with these items in mind would be teaching their boss the details of something new the engineer has built and asking their boss to give the briefing in public or sending out their email. Their manager gets recognized for delivering value to the business aligned with their goals, and the team as a whole is able to celebrate in the success.
At Skyscanner, we use an Objectives and Key Results (OKR) process to ensure that our goals are coordinated across the company and are published in a way that’s easily discovered by anyone in the company. This is important to ensure that we maintain total transparency of what we’re all working on across the company.
About the Interviewee
Bryan Dove is Senior Vice President of Engineering at Skyscanner. His role includes leading and growing Skyscanner’s engineering teams at an accelerated scale across ten global offices. Bryan brings to Skyscanner more than 15 years of engineering leadership experience. Prior to joining Skyscanner, Bryan was a Director of Engineering at Amazon Web Service’s S3, where he led his team to launch a number of new customer features including S3 event notifications and S3 cross-region replication. Previously, Bryan held multiple roles at Microsoft and was the Head of Data Engineering at Skype where he founded and led a globally distributed team to build Skype's real-time big data architecture.