Developer Thinking: Building A Developer Mindset Throughout Your Organisation

Adrian Trenaman at UXDX EMEA. Video: https://youtu.be/pjp59mDFS4w

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From fungible resource to engineers as innovators

[00:00:09] Okay, so my name is Adrian [?], and I'm going to talk about building a developer mindset in an organization. I work on virtually for cooking for [?] Gilt.com, and we are very big in terms of believing in just fabulous user experiences. Three cars the original experience of over at [?] Gilt.com: high-end luxury fashion flash sales. In February [?] of this year we were acquired by a large company that owns brands like Saks [?]. So for me this be something of a jerk [?].

[00:01:22] So yeah, there we go. What are the observations I have over the last two [?]? You might not know this, but around here, for a couple of decades, we have had leadership experience a big change. The engineer has moved from this fungible resource. I remember at the start of my own career you would see these discussions where it's like, "We need to project a club [?]. Okay, let's just take 10 of those engineers and pop them over here, and those over here, and we're done." And that's actually changed over the last two decades. What's happened is a complete change in mindset. The way that an organization will innovate today is through information [?], and the way it will innovate is with engineers. You need the right smart people at an engineering level to make change, and that's been a fundamental change.

[00:02:13] If I look at how that has happened in the last six or seven [?] years, and think of the rise of a company like Gilt, going from a startup with a million dollars of revenue in its first year to, some years later, four hundred million dollars: absolutely stellar growth. Then I think about organizations: how do you build that developer mindset? How do you build a team that works for attacks [?]? How do we build that culture?

Waterfall, business lines and the KPI-driven approach

[00:02:43] It's interesting. The first two years, I think, like any startup, it's just chaos, and that's wonderful; everybody is probably very busy for sure [?]. We then entered, because we started growing, this period of what we call business development [?], and in a sense it was dull, a waterfall pipeline. This guy has an idea, he's going to give it to a product manager, who's going to give it to a designer in a boxcar [?], who's going to give it to development, who will put it into production. We were really that bad in terms of our waterfall. We were in this bizarre situation where we were all structured around the business lines.

[00:03:26] I remember working with an amazing business guy who was leading the home business, and he said to me, "I want to sell furniture. I want to sell sofas. I do not know how to lead a tech team." That was a great realization: maybe we should actually take tech away from the business [?]. So what we did is we explored, in 2011, this KPI-driven approach, where we simply took the teams of engineers and we said, "Take your way to the business [?]. What do you think is the biggest thing that you can do across the entire economy [?]?"

[00:04:07] To do everything now, by a team I mean a full-stack team: a team that has engineers and UX and design, and everybody is working together on one initiative. That's a big part of it, the autonomous team. The second thing, though, is to be delivered [?]: how do we know if you are succeeding? What is the key performance indicator that will tell us whether you're changing things? So we developed this approach, which is a lot like this idea that rather than give somebody a solution, you give the engineers the problem [?].

[00:04:47] So this we tried in 2011, 2013. I think those early days were hard, because it sounds like a great idea: let's clear the board, let's start again. Let's take ourselves from one engineering organization to lots of small engineering teams, each a mini company with its own CTO [?], and you break it down like that. And then everybody has stage fright. I can only compare it to when I got a voucher [?] for a flying lesson once. There comes a point where the instructor gives you the controls of the plane, and the first thing you do is go [?]. You never had that responsibility, and a lot of our teams actually froze up. It took us a while to get it right [?]: how do you make these teams work?

[00:05:42] I think we were nailing it for the last couple of years. Equals 60 60 years in our organization [?]. That's kind of rough sides, very very good stretch [?]. The numbers are important, and the numbers are important personally as well, because now, as part of a larger company, we are counting scale [?]. That's the real challenge for all of these approaches.

Autonomy, mastery and purpose

[00:06:05] So what we did is this concept of autonomy, mastery and purpose, to keep these intact [?]. Creative people are not actually motivated by money or by bonuses. That's not to say that it isn't important; everybody wants money in the bank [?]. But what gets people excited is autonomy, being able to get things done by themselves; mastery, being able to get to the top of their game; and purpose. One of the things I was really interested in is how we can get these three instilled into the organization.

[00:06:45] It's interesting, I just saw this great [?], you know, they mention: "Culture eats strategy for breakfast." All the focus on culture. But I think it's actually kind of wrong, because it reduces [?] it to: the answer is culture, as if you can just whip up a culture. Culture is actually very hard. How do you build that culture? And culture is hard for engineers, because we like to think in a scientific kind of way, in terms of logic [?], so it's hard.

[00:07:39] The other thing as well is that I think "culture eats strategy" is actually less fair [?], which is somewhat controversial. I want to swing the pendulum back a little bit. The industry went from strategic development, strategic thinking, to "just get the right people in the room and they'll figure it out." My problem with that is I think when you get the right people in the room, you still need to set the guardrails and say, "Here's what's important, here's what's actually going on." So no strategy [?]. It's definitely the case that great culture is necessary for a good [?] culture, but it is not sufficient. You need a little bit of both.

[00:08:27] I think culture talks to the autonomy and mastery, the craft, but I think the strategy helps out with the purpose side: what I'm doing. We really need it. I mean, I'm not saying that everybody in the room [?] is helping work out whether their medication is working, that you're saving the world. Helping somebody buy a floral party dress isn't the same, some spiritual game [?]. But it's important to realize why you are doing it: why is it important, for our purposes?

Tips for building developer mindset: hiring and code first

[00:09:02] So, building a developer mindset: what are the tips and tricks we've seen? You'll see [?]. The first thing is hire engineers [?]. Let me handle it, but actually love the face, don't I look orange eaters [?]. In the Gilt organization, roughly 75% of everybody in tech was in engineering, only 25% in product management, UX, design [?], so we over-index [?]. That's actually pretty interesting. It'd be interesting to go figure out how others structure their engineering organization and how you make it work. And yet the numbers are important here.

[00:09:47] The first thing is our engineering philosophy is code first. We're actually not that interested in PowerPoint designs. We're not interested in UML. We're uninterested in a 50-page design document. We don't care about requirements [?]. What we really care about is getting things together, working, early prototypes [?]. Get stuff working.

Team size, departments and coding leaders

[00:10:15] Factually here, think about our teams [?], with an engineering bias. Our team size is usually five plus or minus two, probably more like four, plus two, minus one people. It's very interesting, that team size: the size of a small family, enough people for two pizzas. Ultimately, when you have a team of that size, the actual level of management around it is low [?]. We bundle those teams into departments of 20 plus or minus 4. 20 plus or minus 4 is the number of people you'd get into a room together and say, "Guys, here's the big problem; do we need to change?" To borrow people, we reshape [?]. That's also the size [?]: 20 plus or minus four.

[00:11:03] A big thing that we do as well with this structure is that we don't like to talk about managers [?]. We focus on leaders, technical leaders: people who can really lead people and lead in technology. These are not managers but leaders who are coding. Our team leads code about eighty to ninety percent [?] of the time. Our directors code about sixty percent. The eighty-five percent [?] is started early; directors 35 or 60 [?]. Someone like me maybe totally deep [?]. This builds the idea that code is central, right the way into the whole [?] structure.

Pushing decisions down the hierarchy

[00:11:46] There are a couple of other things there, though. I'll later put up just a blueprint for the organization [?]. Somebody saw this diagram and said that's just hierarchy. The thing is, what we've done is we've pushed as much responsibility and decision-making to the very bottom of the hierarchy. Someone like me makes very few technical decisions these days, because we push so much back down. So the great thing there is [?]: if anyone wants to catch me, I'll give more detail on that.

Two career tracks and the ingredients framework

[00:12:29] So what else is important? One thing you'll realize is incredibly important [?]. The real message on this slide is: some engineers like to lead. Some engineers are really good with people, and they really want to flex their muscles through working with other people. Other engineers don't. I know some incredible engineers who do not want to be a people manager [?]. A lot of what we did [?]: in many organizations the only way to get career advancement, or the only way to get a stronger sense of self [?], is to get promoted to management. That's fundamentally wrong. So, a small thing, but having two clear tracks that allow you to respect [?] great engineers as individual contributors is hugely important. That's our model [?]: having two tracks.

[00:13:32] So we build our tech teams from four, five, one, two [?] engineers. We had this idea about three or four years ago: why don't we just hire everybody as an engineer [?]? And the idea is that it can actually work. You don't ever think of the star [?] people. There are people who are incredibly multi-skilled, and sometimes you find ones who are wonderful at everything.

[00:14:23] What we can do is start off with that team and then look at the ingredients within the team of engineers. Do we have a person who has an incredible sense of UX? We can see great pretenders who are UX geniuses [?] in the making, and if the team already has that, you don't need to add someone. But if you don't have that on your team, that's where we say, "Let's get one of the design team, parachute them in here, and make sure we have that ingredient covered." So we don't let the classic roles, like product management, project management, UX design, dominate [?]. We look at the team: does it have the right ingredients? How do we make sure? All the classic things are there.

[00:15:05] By the way, the language is amazing, because when you think about it, we have these fights: product manager versus tech lead versus project manager, who's in charge, who calls the shots [?], "don't you tell me what to do." It's crazy. Actually, when you have a situation where you're saying to a lead, "Do you really want to be a project manager? Do you want to do that stuff, or code?", all of a sudden the management of the team isn't actually the point of contention. It's actually, "Wow, I'm getting something to complement me." So we built this ingredient framework that basically said: let's look at people, figure out their strengths, and figure out what they can bring to this team at this moment, regardless of their job title [?].

[00:15:55] This is an alternative form [?]. For example, external relationships: who is actually the person who's good at [?] talking about what the team is doing to the rest of the organization? Who's the moment later [?], the one who, when he or she walks into a room, everybody goes [?]? Every team needs this [?], because it's actually a very, very good piece to forget [?].

Strategy, purpose and letting teams set their own goals

[00:16:40] Okay, so now getting to [?] strategy. This is, I think, like motherhood [?]: it looks easy, but it's actually incredibly hard. We talked about getting that purpose. You'll see we get [?] a strategy: what should our company be focusing on right now, for example these initiatives [?]. Here are the challenges [?] you need to do for me. That talk has two parts: why. For example, mobile is huge; more and more people are using our app [?]. You should take your eye [?] to things like average session time.

[00:18:39] So what we do is go to the team and say, what can you get done, and will you sign up for it [?]? Is that funded for the end of something [?]? That's embarrassingly close to a Gantt chart [?]. But it turns out this visibility tells you how tall the flash is in more severe weather, liver-eating elsewhere [?]. Boundaries both house atop just achievement they don't [?]. Knowing that they can be orderly [?] is a huge thing for the teams doing their conference [?].

Measuring team happiness

[00:19:35] I've been doing this with teams [?] for almost three or four years now. They would actually generate eighty percent of [?]. Having the teams give you the client [?] was just, so it's probably good. Measuring happiness is something that we borrowed from friends at Spotify [?] and Google, working on this. We were laughing about it: if your team did this, it seems like a reasonable hypothesis. So we measure their happiness and whether things are working.

[00:20:21] Chris murmur his chart [?]. Take a couple of the areas: here's a team that's reasonably healthy [?]. The team told us how they feel about the various things: deployment, team fun, learning stuff. It's not all rainbows and unicorns: here's an unhealthy team. I find this amazing. This gives us a real view of whether the teams are operating well and what we can do about it over time. We know this should change, so this health check [?] really can start to work with a team to figure out what's actually working for them. This is new to us; we just started doing it. The Spotify thinking, by the way, is just fascinating.

Shrinking the distance from idea to production

[00:21:23] I would say one of the other observations in the last few years, I think, is reducing [?] the distance from commit, from idea, to production. I think we spent a huge amount of time on this: going from a world where, when you start an idea, it takes, say, one to six weeks or months before a customer actually sees it, to something like 45 minutes from committing the code. Getting that reduction is incredibly powerful in tightening that feedback cycle, which makes the team much, much stronger.

[00:22:04] I would put more advice here [?], but I'll move past the details of some of these. Meetings: I do love thinking about whether the meetings are productive or not. General tip: engineers do not like meetings. So have fewer if you possibly can. This is an example of the most riveting slides later [?]; these are the meetings that we know work for us. Unfortunately I'm talking in too much detail, so I'll run through this very quickly.

Values in plain language

[00:22:34] I think it's important to take the world [?] of strategic thinking and understand your values. Values are at the heart of everything [?]. If we must be management consultants and talk about values, the three to five [?] we would like to recite: the customer, and so on. What I do is make sure we talk about values in plain language that actually isn't expecting you away [?]. Another little mention is actually trying to get your friends [?], as if you're actually talking to your mountain club [?].

[00:23:23] So nobody will beat [?] the values of an engineering team. How do you do this? Things that are important to engineers are writing great code, but also impact, continuous [?] deployment, learning new things. Remember, it's important that your organization is structured for that. The situation do compartment being a home for perky brilliant [?]; the first, the third, the fourth one [?]: being honest, even when it's difficult, something that happens quite a lot; making decisions and owning the consequences; and then being respectful [?].

[00:23:58] I think this is actually a very realistic look at the way an engineering team should work. And what you need to do is test it, because what's interesting is that when you're in a difficult decision-making scenario, people are respectful, and somebody stands up and says, "No, let's do whatever is best for our customer." That's when you really know you're true to your core values. All right, thank you very much.