The New Visionaries: Kris Gale

This is a first. The only direct interaction I have had with Kris is this interview, unlike all the others in the series to date. I originally learned about Kris through discussions with Adam Pisoni, the co-founder and CTO of Yammer, who had shared an insight into Yammer’s engineering approach. Yammer is one of a growing number of tech companies that are adopting what might be called hyperlean practices, like GitHub, Medium, Asana, Valve, and Everest. These build on the lean development approach, but go farther, upending conventional management practices and shifting to across-the-board autonomous work management. Adam suggested that I should directly speak with Kris to better understand how that evolved at Yammer, where he is vice president of engineering. I will be interviewing Adam in a subsequent post in this series, regarding his thoughts on what he is calling The Responsive Organization.

Kris-Gale-Head-ShotAbout Kris Gale

Kris Gale oversees all product development engineering at Yammer. Gale was an original member of Yammer’s engineering team, serving as director of infrastructure, where he focused on performance and scalability from the company’s public launch through its first three years of rapid growth. Gale has 13 years of experience in development, systems engineering and operations.

The Interview

Stowe Boyd: Yammer is one of a growing wave of companies where developers are given unusual latitude in determining how to get work done. Perhaps you could start by describing how Yammer has migrated away from an organizational culture in which managers break up work into manageable tasks and assign that work to specific people. What is the alternative, and why is it better?

Kris Gale: When Yammer began, we were a few engineers with diverse skills working closely together to get things done. Because our tasks weren’t abstracted away from the company’s goals, we had so much more context, and that context allowed us to make the million tiny tradeoffs that make up software engineering more effectively than I was used to in engineering departments of more than a few people. And because we didn’t need a reporting structure yet, we didn’t have to build any assumptions into our org structure that prevented us from changing priorities or direction.

The breakthrough was realizing that we didn’t have to assign work through our reporting hierarchy.As we grew, we began to need reporting structures, and we tried out both of what I think of as the classic engineering team models. We tried horizontal teams that owned layers of technology across the product and vertical teams that owned slices of the product across technology. Both slowed us down in different ways. Horizontal teams created queues of work between teams that slowed us down: for example, the frontend team would need an API change from a backend team, and this request would sit as a request somewhere until the backend team had time to address it. Vertical teams caused us to waste cycles working on things that weren’t always our critical priorities: if we had a messaging team, we’d end up working on messaging features every month, even if it were more strategically important to the business to start work in some new area of the product.

The breakthrough was realizing that we didn’t have to assign work through our reporting hierarchy. Instead of the head of engineering breaking a goal up into what the X team needs to do and what the Y team needs to do, then assigning those things to the managers of the teams to be further broken up into tasks, we said we’d just take an engineer from X team and one from Y team and dedicate them to solving the business problem however they best saw fit, then move on to something else. All of Yammer’s organizational methodology in engineering came from that: How do we build mechanisms to force all of our work to happen in small, temporary, fully-dedicated, autonomous, cross-functional teams? Or: How do we scale engineering so that all problems get solved the way we’d have solved them in the first year of the company?

SB: I’ve read that Github and Asana engineering teams share a similar discipline, that of autonomously pulling tasks or even projects to work on. Were you aware of that, or of other groups, like Valve, when you started your transition to a horizontal work culture?

KG: Not initially, but as we identified that breaking engineering organizational conventions was effective for us, we started looking for new ideas everywhere we could. I’m not naturally someone who likes to network professionally, but my interest in trading ideas about org structure and workflow was what finally got me out there meeting with other engineering leaders regularly. Chris Wanstrath at Github was actually one of the people I had over to the Yammer offices to talk about this stuff. We were running around Yammer screaming “decentralization” and it was nice to have his perspective on just how far we could push that concept.

SB: I will be tracking Chris down soon, to get his story, too. If managers aren’t managing the assignment of people to tasks, what are they supposed to be doing? As Yammer underwent that transition, how did first level managers react?

KG: We’ve all had to readjust our mental models of what management entails. When we say engineers get to solve problems however they want, we really mean it. We don’t want an engineer to say, “This is kind of dumb, but that’s how we do it around here.” This means management drops all of the responsibilities for double-checking or approving technical decisions and picks up a new responsibility for cultivating a team of experts in a particular technical discipline who can be sent out to work on projects autonomously.

We call each other out when it looks like we’re being prescriptive about how problems should be solved. I’ve even been called out on this, and it’s my core management philosophy to never stomp on autonomy. So there are definitely deep-rooted corporate assumptions we have had to fight against. I get a sinking feeling when people justify doing or not doing something by saying “Well, Kris said…” I’m not the one in the code; don’t listen to me!

Stowe Boyd: If managers aren’t managing the assignment of people to tasks, what are they supposed to be doing? As Yammer underwent that transition, how did first level managers react?SB: There’s been a great deal written in recent weeks about forced employee evaluations at Yahoo and Microsoft, and the dangers that technique poses. I wonder if the shift to a very autonomous sort of work regime leads to a radically different approach of worker evaluation, too? How does Yammer do performance evaluations?

KG: It’s my opinion that the big company evaluation systems we all think of have been broken for a very long time. Long before Drive came out, W. Edwards Deming was practically yelling at the world that performance evaluations were a busted idea. This was back in the 60s before automation radically jobs in developed nations from routine work to mostly exception-handling.

Kris Gale: We’ve all had to readjust our mental models of what management entails.Given that the things we can’t automate are necessarily those things we don’t regularly encounter, how can our manager reliably determine that you did better with the exceptions you got than I did with the exceptions I got? Remember that annual bonus money is not free money that comes into existence when a company decides to give bonuses. Bonuses are, effectively, a group of people agreeing to give up a percentage of their salary for their managers to redistribute to the people those managers arbitrarily select. What sane group of people would agree to that?

Bonus-tied reviews by the management layer reduce an organization’s ability to change direction, because it incentivizes people to deliver what they’ve committed to, even as new information suggests different work would be more effective. I spent much of the last year shopping Yammer’s organizational methodology around Microsoft, and it was inevitable that someone would ask something along the lines of the question you asked. Getting rid of that review system is going to help systems like this spread within Microsoft and to better align everyone’s incentives. I’m very happy to see Microsoft taking a step in this direction.

SB: I love your characterization of bonuses, where the workers have agreed to a redistribution model arbitrarily run by managers. So, in your flattened model, how are engineers evaluated? Have you dropped Management By Objectives sorts of evaluations? Do you have 360º reviews where coworkers evaluate each other?

KG: It’s interesting that everyone asks about the evaluation process. I think that’s a really strong signal that most engineers don’t work in structures or environments that provide enough transparency. I’m much more interested in giving engineers a way of working in which feedback is automatic and constant, and one in which there is full context given to them for the work they’re doing.

If the goal of the evaluation process is to provide people feedback on the job they’re doing, I look for ways to build that into how work is assigned and managed. If you’re given a task on which something else off in the distance depends, it’s hard or impossible to know whether you handled it quickly enough, built it robustly enough, or built it in a way that was easy to build off of. If you don’t deploy the code you write, you need someone to take a specific step to give you feedback about whether it had a clean deploy story. If you don’t know when it goes out, or if you don’t have immediate access to the performance metrics, how can you know whether your code was performant in production? All of these problems can either be solved by doing 360 reviews to collect feedback from the impacted parties, or the workflow and organizational structure can be corrected so you have all of the context as you’re doing the work. I prefer focusing on the latter.

Now that’s not to say that I didn’t get a lot of value out of a particular one-off 360 review that Adam collected for me when I was first promoted into the VP of Engineering job; that kind of full perspective, presented all at once and away from my work, was definitely valuable. Getting it up front, rather than bit by bit on the job saved me a lot of experimentation and failure going into a new kind of leadership role. Effective leaders will spot opportunities to provide targeted feedback explicitly collected to fill in organizational feedback blind spots. By making it a tool that managers have access to, rather than a homework assignment everyone has to do, I think you get better results. I think managers should be held accountable for growing their team, not for following a set process.

If the goal of the evaluations is for the management team to figure out who the strong and weak performers, this is even easier to solve through changing structures and workflows. Most organizations build these opaque silos into which tasks go and from which work of varying quality emerges. In order to understand what’s happening inside, the organizations have to build a regular process for opening the silos and shining a light inside, or worse, a process of asking the person in charge of the silo to report back about what’s happening inside. Yammer tries to break down every silo and to replace opacity with transparency. This is a huge discussion in itself, but one point to focus on is our breaking down of ownership of product feature areas or codebases. Nobody owns their own pieces of either in our system, and we assign work to ephemeral, rotationally-assigned teams. We get as close as time allows to a system in which everyone works with everyone else on something. Strong and weak performers are pretty quickly surfaced. It’s almost always the case that all of the dev managers have the same assessment of a particular engineer as his or her manager would have because of all of the rotation and transparency in our system.

We generally know whether someone is an exceptionally effective engineer within that engineer’s first two months. That’s far shorter than would be the case even in the best performance review system I’ve ever seen. Performance reviews are another really good example of something I push the management team to do: build solutions into the way we work, not into processes that exist outside of our workflow.

Yammer tries to break down every silo and to replace opacity with transparency. This is a huge discussion in itself, but one point to focus on is our breaking down of ownership of product feature areas or codebases. Nobody owns their own pieces of either in our system, and we assign work to ephemeral, rotationally-assigned teams. We get as close as time allows to a system in which everyone works with everyone else on something. Strong and weak performers are pretty quickly surfaced.As engineers, we know how to build things such that the main process also drives peripheral results. I’m not into guns, but it really stuck with me when I learned that semi-automatic pistols and rifles use the recoil or exhaust gasses that are side effects of firing a round to then also eject the spent casing, chamber a new round, and reset the action. All of those things used to be done manually, but someone figured out a way to engineer a system in which the peripheral benefits were achieved by using energy already in the system. Or think of how an internal combustion engine has a piston and crankshaft to convert energy from a small explosion into movement, but then also uses the same piston and crankshaft to solve the problem of how to pull in new air and fuel, to compress it prior to combustion, and then to exhaust the spent fuel-air mixture.

Those are great analogies to hold in your head when you’re looking at a complex organization and want to drive some new result. Ask yourself how you can tweak what’s already there without adding something new and get the result you want essentially for free. It usually means skipping over the obvious solution, like annual performance reviews for example, and instead thinking really deeply about all of the existing mechanisms of the system.

SB: I am going to use those examples for years to come. Thanks, Kris!

KG: Thanks, Stowe. I’m really happy to have the opportunity to talk about this stuff. And please keep pushing the world to make better companies. My daughter is about to enter high school, and I’m increasingly optimistic that forward-thinking writers will influence today’s leaders to tear down the awful management constructs of the industrial revolution before she and her generation start their careers.

Relevant Analyst
Stowe Boyd

Stowe Boyd

Lead analyst, future of work Gigaom Research and stoweboyd.com

Do you want to speak with Stowe Boyd about this topic?

Learn More
You must be logged in to post a comment.

No Comments Subscribers to comment

Explore Related Topics

Latest Research

Latest Webinars

Want to conduct your own Webinar?
Learn More

Learn about our services or Contact us: Email / 800-906-8098