News

Visual Studio Live! Keynote: Building Effective Development Teams the Hard Way

• By David Ramel
• 08/15/2018

Expert advice often explains how to do things easier, but sometimes that advice resonates more when it details hard lessons learned.

That's the approach Phil Haack, Director of Engineering, Client Apps, GitHub, took in yesterday's keynote address at the Visual Studio Live! conference held at Microsoft Headquarters in Redmond, WA.

Haack shared some of the hard lessons learned in building effective development teams that he gained from experience at GitHub, which he joined some six years ago when the open source development platform boasted only 50 employees -- and no managers.

To impart what he learned, Haack drew upon his own personal history at GitHub in the hope that others could map their own journey to his and accelerate learning what makes teams effective. In his journey, he started as a developer, moved to a manager, and then director -- a manager of managers.

Fittingly, his presentation was titled "Building Effective Development Teams the Hard Way."

"If there was an easy way, unfortunately I didn't get the memo," Haack said to the audience packed into Microsoft headquarters.

Haack organized his presentation under several main topics, and following are some of the highlights.

Effective Teams Examine Root Causes
One of the main reasons he left Microsoft, Haack said, was because of the endless meetings he had to endure, and he recounted the familiar problems with meetings that everyone in the crowd was familiar with. That was encapsulated in this quote from a Wailin Wong in a "Signal v Noise" blog post: "Meetings are one of the worst kinds of workplace interruptions. They're held too frequently, run too long, and involve more people than necessary."

Haack didn't say all meetings should be eliminated, "but we do need to change our mind-set towards them."

"Rather than accepting meetings as a de-facto necessity, meetings should have to justify themselves," Haack said.

Haack used a meeting request example to illustrate one of his favorite team-building techniques, called the "five whys," developed at Toyota before it became an auto-maker. It basically says that to get to the heart of a matter, ask the question "why?" about five times after being presented with the issue. His meeting request scenario went like this:

"Hey, we should have a meeting."

"Why?"

"Well, we need to talk about the schedule."

"OK, why should we talk about the schedule?"

"Well, my boss is concerned."

"OK, why is your boss concerned?"

"Well, it looks like things are falling behind."

"OK, why do they think that?"

"Because we haven't created a project board."

"All right, maybe I should go create a project board."

"Yeah, go do that."

Haack acknowledged that was an oversimplified example of the technique, which actually comes with an entire methodology behind it that might include branching diagramming or writing tables to examine multiple root causes.

Even oversimplified (and featuring only four "whys"), he said, the example illustrated a better approach to take rather than what people often do, which is just go with the first idea presented.

"If you simply just start adding 'why' to your process, you start to get good at root cause analysis and start to get good at annoying your colleagues," he said. "So feel free to use this technique to eliminate waste, solve hard problems and channel your inner toddler."

Effective Teams Are Intrinsically Motivated
"Never underestimate the power of intrinsic motivation," Haack said. Motivation presented a special challenge because of the special nature of the early GitHub, where there were no managers, no set work hours, no deadlines and people could take vacations whenever they needed.

In recalling the search to find a source of motivation, Haack related the quote from Antoine de Saint-Exupery: "If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea."

Haack said, "What motivated us was the sea, in this case being the sea of developers out there -- that we could build better tools. Tools that were aesthetic and were pleasing you, but also powerful and helping get their work done."

What helped motivate him, he said, was the book Drive by Dan Pink, which details these three concepts:

• Autonomy
• Mastery
• Purpose

Pink cites extensive research that finds after a certain point, money doesn't really motivate people for better performance, Haack said, advising people who don't have time to read the book to check out an RSA YouTube video ("Drive: the surprising truth about what motivates us") to get the gist.

Haack acknowledged that at GitHub he didn't work for free, receiving pay and other compensation, "but the point of compensation isn't to motivate better performance. It's an exchange of money for services. It may have motivational effect, and that is to motivate someone not to leave."

Also, he said, compensation relieves people from worrying about a lot of other things that might intrude on their day-to-day work.

"But what motivates them to perform well and to do good work is the intrinsic part," he said, such as caring about the customers affected by the good work being performed.

"I believe effective teams are intrinsically motivated."

Effective Teams Are Composed from All Over
Getting the best talent onboard basically means diverse teams composed from people all over. Haack noted that GitHub uses such a distributed system, as its headquarters is in San Francisco but perhaps 60 percent of the staffers work remotely. He himself works out of Bellevue, WA, a short distance from Microsoft.

He said it's important to realize that a lot of companies want workers to relocate, such as to San Francisco in the development world, but he valued the quote from Leila Janah: "Talent is equally distributed, but opportunity is not."

Companies that allow distributed, asynchronous teams have a leg up in finding great talent, Haack said, concluding "effective teams are composed from all over."

Effective Teams Foster Trust
Haack used a personal example to illustrate the issue of trust. It happened when, as a developer working on the GitHub for Windows desktop app, using C# and WPF, he was promoted to manage that team and the team doing a GitHub for Mac app, using Objective-C, Cocoa, and Swift when it came out.

The teams started to diverge and the company decided they needed to converge instead, rebranding both to be called GitHub Desktop. While the two different teams would remain, they would aim for parity in UI design and feature sets, resulting in the first iteration of GitHub Desktop, the team he took over. So he went from being a developer on the Windows team to managing both teams.

"I wish I could say it went smoothly," he said.

Instead, the CEO came buy and noted someone's idea to investigate using the company's Electron technology, which allows for writing desktop apps with Web tech. So instead of building everything twice, it could be built using HTML, JavaScript, CSS and so on to build one app for both platforms. Haack thought that would entail a lot of problematic issues, but was worth investigating. So he broached the idea with his team.

"Oh how naive I was. Oh how naive I was," Haack said. "Half the team was like, 'Oh that's interesting, we should discuss it.' The other half was, 'How dare you betray us? How dare you go behind our backs and try to sabotage the work that we're doing.' And I was like, 'whoa, whoa, whoa, where's this coming from?'"

Haack said the audience could guess which of his two teams thought the idea had merit and which didn't. The Windows team felt it worthwhile to investigate, he said, because it had worked with him and trusted him. The Mac team had no such trust yet, so he couldn't just go and drop such a bombshell on them.

The desktop team did eventually move to Electron, and that move did cause some of the Mac devs to leave.

"What I realized then is that -- the hard lesson I took away from that -- is that 'the major problems in our work are not so much technological as sociological in nature,'" he said, quoting Timothy Lister and Tom DeMarco in the book Peopleware.

Effective Teams Know How to Hold Difficult Conversations
While instituting one-on-one conversations with his team members to help build trust -- and learning to handle difficult conversations -- Haack said he still needed to learn more about the latter, for which found the book, Difficult Conversations by Douglas Stone, Bruce Patton and Sheila Heen, helpful.

"What I learned was, if there's one key takeaway from that book, it's that 'people almost never change without first feeling understood,'" he said, quoting from the book.

To illustrate how he learned that himself, he recounted another painful episode in his journey at GitHub.

It involved talking to people in the user research group, as the company was interested in learning how users leveraged their products and what problems they were trying to solve. In the discussion, he said to some research group staffers something along the lines of, "you all are going to provide a service to us and we'll go from there." Both people came back and said they were really offended by what he said and didn't think they wanted to work with him on the project. Blindsided, he dug into the issue with the leader of the research group and found it resulted from different interpretations of the word "service."

"In her mind, it was like dropping off a garment at dry cleaner's, right, you just dropped it off, and you leave and you don't interact with them much and you come back and you expect it to be done. But my years as a consultant in service of clients gave me a whole different perspective of the word 'service.' To me, a service is something where we tightly collaborate, work together to make something good. And so we both heard the same word, but they had different meanings because ... words on their own don't have like a pure meaning. The meaning adds what you bring to it, right."

So Haack said he learned that the sum of one's life experiences affects how you interpret different words. "There's no such thing as a purely rational conversation."

He highly recommends the book, which he found helpful in many different roles, including manager, parent and "general human."

Effective Teams Give Candid, Concrete and Constructive Feedback
In explaining the value of feedback, Haack brought up the example of test-driven development (TDD) and its tight feedback loops that provide immediate guidance.

If you don't receive good feedback, he said, you don't know if you're going in the right direction. He related the story of a new Ford CEO who regularly received status reports from his lieutenants, color-coded green, yellow and red to indicate whether company units were doing well, having a few issues or facing major problems.

When all the reports kept coming in green, he challenged the team, as the company was losing a lot of money, saying something was wrong. When a manager subsequently provided a red report and indicated the division was having big problems, instead of being scolded, he was praised by the CEO. That resulted in a "rainbow" of colors in subsequent reports as the managers realized the CEO actually wanted real feedback.

Another side of the issue, Haack said, in addition to wanting truthful feedback, is to have the right motivations providing feedback. "You don't want to damn with praise or give feedback out of anger," he said.

The type of feedback is also important, he said, relating how the new breed of NFL coaches never provide negative feedback like the old days, but instead give constructive feedback, like telling a receiver, when he reaches a certain break point, to take a sharper turn.

Haack said that reminded him of good parental advice, in which you don't tell a child "No" but rather provide other options to try instead. He said several studies have indicated "negative feedback actually sinks people's motivations," at least temporarily, but "constructive feedback, feedback that's actually corrective, is often welcomed, like, 'oh, here's a way that you could be more effective.'" That results in a response like, "Thank you. I want to be more effective."

Effective Teams Provide Psychological Safety
This topic, Haack said, relates to an individual's perception of the consequences of taking an interpersonal risk.

"If I tell you what I really think, do I really need to brace myself and worry about the impact on my career, or am I going to get punished?" he said. "Can I be my true self within this group without getting teased or bullied or just having my prospects limited in growth?"

He pointed to Google research -- where HR has been rebranded "People R" -- that indicated "what really mattered was less about who is on the team, and more about how the team worked together."

He likened psychological safety to candid feedback, which is only effective when people feel safe in receiving it and delivering it.

Effective Teams Are Diverse and Inclusive
Diversity and inclusion is a "charged" topic, Haack said, so he liked to start off with a less-charged example.

That is research related by Malcolm Gladwell's book Blink that said: "In the U.S. population, about 14.5 percent of all men are six feet or over. Among CEOs of Fortune 500 companies, that number is 58 percent."

Obviously there's nothing inherent in tall people that make them better leaders, he said, so that research rather speaks to how tall people are treated by others, encouraged and so forth, and thus helped along to achieve high positions.

Haack also touched upon unconscious bias, illustrated in a study that showed randomized résumés sent in response to help-wanted ads revealed significant discrimination against résumés with African-American names. White-sounding names received 50 percent more callbacks for interviews.

Another study revealed bias toward female lab assistant résumés sent to faculty members, and, remarkably, "The gender of the faculty participants did not affect responses, such that female and male faculty were equally likely to exhibit bias against the female student."

Haack said such bias affects all of us to some degree, and he invited audience members to check out a Harvard.edu Web site that features an implicit bias test (Project Implicit).

He took it and was surprised at what he learned about himself, but it didn't make him feel bad about himself, rather motivating him to work on his bias. He likened it to receiving constructive feedback: "Now that I know, I can do something about it."

Furthermore, Haack pointed to studies that diversity and inclusion in the workforce actually gives organizations a measurable competitive advantage. "Diversity is good for the bottom line," he concluded.

Effective Teams Are Aligned
Haack satirically compared his rise at GitHub to the Peter Principle, which "is a concept in management which observes that people in a hierarchy tend to rise to their 'level of incompetence.'"

While satirical, it did point out something about how people are promoted in hierarchical organizations, which can result from a static mind-set.

"I believe a growth mind-set is important for individuals and teams to be effective," Haack said. "And so this is where I spend a lot of my time as a director, trying to encourage a growth mind-set, I focus a lot on coaching managers, I focus a lot on strategy alignment and vision. And this isn't always easy. At GitHub we had a problem getting alignment."

Getting people aligned at GitHub worked well for small projects, because it basically just involved putting your idea forward and gauging the response to see whether it was a good idea or not -- an approach that didn't work well when trying to align several teams, or the whole company.

That resulted in the company adopting OKR (Objectives and Key Results).

Haack said that OKR by itself is not what's important, but rather "It's important as a tool for understanding, and getting a deep understanding, of what we're trying to do around here."

He explained that "Objectives are memorable, qualitative descriptions of what you want to achieve. Objectives should be short, inspirational and engaging. An Objective should motivate and challenge the team." Likewise, "Key results are a set of metrics (typically 2 to 5) that measure your progress towards the Objective."

He illustrated an example OKR, and reminded the audience that he wasn't trying to sell them on any one approach. "What matters is that they're an alignment tool." What also matters is to have some approach that gets groups of people aligned, and that this approach isn't used as a performance management tool. "That's a big mistake," he said.

Effective Teams Are Valuable
In speaking about the value of getting the right team members, Haack joked that he didn't have the hubris to suggest that Microsoft was paying $8.5 billion to get him back in the company folds by acquiring GitHub.

He would let someone at Microsoft make that suggestion, he said.

Stay tuned for more to come from the Visual Studio Live! conference in Chicago, Sept. 17-20 at Renaissance.