Secrets of a Strong Engineering Culture

Transcript

Kua: I'm very excited to share this talk. It's a new one that I built specifically for QCon. Before I start, I want to talk about two significant experiences I had in my career very early on. I've been working in technology for almost 20 years, and so this experience happened just after the dot-com crash. Maybe some of you remember this. I had a job coming out of university, and actually, I lost that job before I even started because they shut their office down. That's how it was where I was growing up in Australia. It was this 2001, 2002 period where things were a little bit uncertain, where the whole dot-com bubble had burst.

I had this experience working for a large company, I'll call it Enterprise A. In Enterprise A I was working on a healthcare platform. This was exciting because health tech is quite important, and it felt like something that we could actually build and release and make changes to hospitals, to governments, to help people get access to a health-tech platform. As an engineer, I was spending three or four months on calls with San Francisco in India, going through 200-page specifications. You can imagine how fun that was as a developer. This healthcare platform had a two-year project plan, so this was constantly being updated. You could imagine this whole plan and these people building this plan of trying to get a healthcare platform early to test, get it regulated. It's a lot of work, but we weren't going to see first customer using this platform for two years.

What was interesting is that everyone had opinions on this. If you've worked in technology, you have lots of people with opinions. There's a saying about hippos, "The highest-paid [inaudible]" perspective. Obviously, this was the age before Agile, and so we had a lot of different handouts, so 200-page specifications written by product managers. We still had a build-and-release team who would frantically put together builds candidates. If you can imagine what that was like, or if you work in that environment, you know what that's like.

Then, of course, that very rigorous QA intense phase where we have relatively stable builds, and intense testing. That was a really interesting life-forming moment that I'm lucky that I experienced very early in my career. Now, a couple of years later after I left the enterprise, I ended up joining a startup. This was interesting because startups, at least in Australia, were quite rare. Here, we were actually practicing a lot of the extreme programming principles and practices.

We actually had a user researcher with us who was actually doing user testing back then trying to test out new types of prototypes to understand what would be a lot more appealing to people. We actually released every two weeks. This is before cloud, we released every two weeks. We prepared a candidate, we got it ready, and actually put this out live. Then we actually tested to see how changes actually performed with users.

We had monthly ideation settings. We didn't have lots of people throwing ideas and backlogs of ideas. We all actually generated ideas or hypotheses about what we think would actually have the biggest movement being on customer signup, or customer conversion, and actually trying to test that out. We, as developers, were doing the full lifecycle thing of actually doing production support as well.

Now, these two contrasting experiences for me were really life-changing. As an engineer, "I'm thinking about what environment do I thrive in the best? Where do I get this full size [inaudible] sure that I'm actually working in the environment I want to have?"

This is the challenge that you will probably face when you're actually working with recruiting people or keeping people employed. Engineers today have the choice of going wherever they like. They're implicitly thinking about, "Is this the culture I want to work in?" Therefore, which of these two choices would you actually go with, or which of the many choices would they go with? You have an ability to influence this if you're a technical leader in your organizations by trying to shape this engineering culture. Over my 20-year journey, I want to share some of those secrets with you.

As Cassy [Shum] mentioned, we have these quests for secrets, and I'll be your guide today. A little bit about my background. I've been working for about 20 years. I did consulting with ThoughtWorks for about 14 years. Then over the last two and a half years, I was CTO and Chief Scientist for challenger bank in N26, where I could put a lot of the principles and practices we helped with a lot of clients into play, growing an organization from 50 people to about 370 over two and a half years. That wasn't by chance because when you build engineering cultures, you have to be really deliberate about it. I have those two life-changing experiences early on in my career, so I understand what developers want, what engineers want to have. Your responsibility as leaders or managers is to think about this environment. You don't need to manage engineers. Your value add is managing the environment so those engineers can do the best things that they can. These are some of the lessons that I want to share. If you're interested, I have a couple of other books. I run a course for tech leadership and also a newsletter for leaders in tech.

Today, I want to talk about the journey that we're going to be going on, and really I want to talk about why this is quite important and why you should actually care. Then we're going to look at these three secrets. We'll look at maybe some of the pitfalls with where companies go wrong, and also what you can do for each of these items, and then also describe some specific things that you can take away and actually put this into practice.

Why?

Let's start with the why. Let's have a talk about why this is actually important. If you've ever had to do your hiring, you know it's really hard. Now, as a startup CTO, in Germany, starting with 50 people and we had to grow really rapidly, I knew that actually engineers have choices wherever they like. Every team that I've talked to in most companies are trying to hire somewhere. Ideas are not the problem in our industry, our problems are actually being able to build something, to sustain it, and also to experiment. Ideas are cheap, implementation is a lot hard. We're all trying to hire, maybe we're trying to grow talent, which is also a great way, but we just don't have enough. There's a big supply and demand problem in our industry for engineering talent.

As I said, ideas are cheap and easy. You can brainstorm hundreds of ideas, but actually, it's only one or two of those things that you'll actually be able to put into production and actually test. Your responsibility is thinking about, "Where does software belong, and how do you help it grow in your company in a sustainable way?" That's where engineering culture matters. This is where all of you as tech leaders have an ability to influence it because your ability to support this is what will matter when you're trying to actually hire people. We have the supply of developers over here, and we have all these vacancies. We're all competing almost with each other, and it's your responsibility to decide what sort of engineering culture you have so that you have the best chance of attracting the developers that you're looking for.

This is one of the exciting things about technical leadership – you get to craft the culture that you want to have to attract similar people or people who want to work in that culture and experience that culture, and you have the ability to influence it. It's a really exciting opportunity to have.

Remember that everyone has not just two choices, but often 10 or 20 different choices about where they'd like to work. We work in a very global connected, easily mobile industry, and it's my experience that if you're not keeping this engineering culture, a competitor will probably hire your engineers away from you. That's why this is one of the biggest, most important things you can think about as you're trying to cultivate the right culture in your area.

Impact

Let's talk about three specific secrets because these are the things that you're here for. We'll look at each of these different elements, and we'll look at each one, one by one. The first secret really is about the secret of making sure that you have impact. What do I mean by impact? If we look at this, I think there's three different elements of impact that I think make a difference to a strong engineering culture. The first one is that as an engineer, I want to have impact with the customers. I want to know that what I do is useful for the people that we're actually selling our products for. I also want to make sure that I see the outcome of what I'm actually achieving, and that I've actually got some satisfaction that I've solved a certain puzzle. We'll talk about each of these elements.

One of the interesting things I've seen with some customer impact stuff is some organizations set up developers to be very far away from customers. Maybe you have an army of user researchers and product people in the middle. In those poor organizations where you still get handed a 200-page specification, an engineer doesn't feel that connection with that customer. This is one big trap that happens in a lot of organizations, and it's hard to unwind because you have to often work through organizational hierarchies and different departments to actually move towards that. It's probably one of the reasons why we've moved towards a lot more of a cross-functional role and really try to put that customer perspective as close as possible to the developers. That's something that you should avoid if you're heading in this way, if you want to build a strong engineering culture.

Another idea is this thing about feature factories. I've seen a lot of organizations where you have backlogs for years. You don't want to be in that world. Engineers definitely don't want to be in that world [inaudible] asked you for. That's the feature factory. Engineers join software because they want to solve problems. They don't want to just implement code. They want to actually have a part in that process of taking a problem, trying to be part of that solution, and really think about what it is, the simplest way to solve that solution through maybe some coding application. If they just have features to implement, that's no fun as an engineer. That's something else to avoid.

Another perspective is sometimes people get too solution-focused. This happens when you have a lot of product managers building lots of ideas about what could be done. You know that there's a customer need, but somebody has come up with that perfect solution about what needs to be done. There's no negotiation around it. Once again, engineers want to be part of this problem-solving perspective.

What about seeing the outcome? What are some pitfalls that a lot of companies go down here? Well, one is there's just too many handoffs. Products people are handing specifications off to developers, developers are handing things off to testers, testers are handing things off to poor SRE or DevOps people, and everyone's just continuing to work. As a developer, I'm not getting to see whether I make good decisions because I don't see the downward implication of where I'm coming from. Once again, this is a really hard thing to solve because you need to have an ability to influence the organizational structure. This is something that you really want to try to remove off too many handoffs.

Another idea is slow feedback loops. This is one of the reasons why I think things like cloud architectures, continuous delivery have really helped to improve that. When I worked in that enterprise with the two-year project plan to get to a release, I was really frustrated as a developer because I want to see the value of what I'm actually doing come to life. When I worked in a startup where we were then releasing every two weeks, that's such a big step change from two years to two weeks because I actually can see this feedback loop, and I can see the things that I do have been adding value. Work on improving these feedback loops and try to remove the slow feedback loops.

Another challenge, which happens when you have an organization with a small set of developers and maybe lots of product people is that people are often allocated to different types of products or projects. Developers are often context switching, one project to another. This happens very much in early-stage startups because you're often very lean in your engineering team. All this context switching means that a person who's working on something probably isn't getting feedback about what they built previously is good quality, actually solved the customer need, and they're maybe not really focusing on what the biggest value is. Be careful of some of these pitfalls.

Then engineers join engineering so that you can solve this really interesting puzzle. Martin Fowler just published an article about outcomes over outputs. I get asked a lot by business people, "How do you measure the productivity of teams?" "Do you use velocity? Do you use points? 'My team is getting more points than your team.'" That's a really bad measure because it's measuring output. A lot of people who haven't been working in software don't really understand that you can come up with a really simple solution. It may take a little bit more time, but it may be less work. The hard bit is in thinking about how you approach the problem and how you solve this problem elegantly.

If your organization is measuring people by the number of tickets they complete, by the number of story points your team delivers, by the number of features you pump out, who knows if those features are actually having an outcome to desired outputs for your company, or the customer growth, or customer engagement? Really, you want to invert this and stop focusing on the outputs. These are just byproducts of our process. They're no real measure of what the outcome is that you have with that output.

I'm one of those people that I actually try to instigate some planning, so I actually don't think all plans are bad. One of the difficult things is when people have put together a plan, they then want to stick to the plan that they've built. Good planning processes mean that you adapt. You know that you're going to get your plan wrong. It gives you a basis of saying, "How far are we off our mark?" I believe in estimation, not because the estimates and the date matter, it's because it gives us a good idea about, "Do we share the same assumptions?" and "What assumptions are changing as we validate our work?" If you have organizations that are just simply saying, "But you promise it by this certain date," you're not going to be building really good to the engineering culture.

One of the things that often happens if you work in a feature factory focused on lots of work is this idea of just lack of celebration of feedback. "Let's move on to the next task. Let's forget that we've actually achieved something really great, and let's just move on to the next feature, the next sprint, the next iteration." These are all things that you can avoid if you're focused on this. The principle I use for this is really cultivating impact by reducing feedback loops. Now, what does that mean? What are some concrete examples of what you can do for this? When I first came into N26, it was interesting because we're a beta seed bank, so all of you could sign up as a customer, and engineers could actually get closer to the customer. This is a little bit more difficult if you're in a B2B platform where you're selling to other companies, who then sell on to end customers. One of the practices I encourage our teams to do is actually go sit next to our customer services people. They weren't actually in the same building, but they were in the same city. It wasn't much effort to go over for an afternoon, listen to some calls, understand what problems that people were actually having.

I remember one time, we have this activity called "get stuffed on days." Every six weeks, two days, people can choose what they do. A team went over to customer services, they sat with customer service people, listened to some calls, and an engineer went, "I didn't realize this was a problem, I can fix this right now," and literally, in an afternoon, fixed the customer issue that was plaguing customer services. The further away you are from customers, the harder it is [inaudible] This is a practice of shadowing CS that you can have to make sure that developers get closer to customers, get quick feedback about how their software is actually progressing.

Another thing, and this is one of the reasons why I think Agile has become really successful, it's not because of big scaling methods like safe or whatever, it's because you get to deliver in small increments. Any large transition or migration project that you've ever worked on and you're not actually delivering value in small increments, it's going to destine to fail. We've learned this through smaller sprints, smaller iterations. Make sure you deliver small outcomes because then we can use that to improve our plans. As developers, you get really good feedback about whether or not you're actually building something that's useful. I've worked on teams that have released something into production, after, say, a month, only to find out users don't use it. They could actually can the whole project rather than continue on with the plan because they've got real feedback around user feedback.

OKRs are a very controversial topic, and this is a whole other talk by itself. One of my pet peeves with how OKRs are used is that they're often used by management through objectives, so management through metrics. If you use OKRs well, what you should be doing is making sure that OKRs are used for aligning the organization and making sure that people understand, "Here's how my work contributes..." Most companies should have some company mission, a goal that they're trying to have. Every probably year or every six months, there's probably large initiatives or themes that your company is focused on to maybe improve. It's either maybe customer growth, stability, or customer conversional activity.

Then when a developer is working on a task, it's hard sometimes to understand how is this linked to the bigger, broader picture. This is where I think an effective use of OKRs is really important, because it's helping connect this feature to some initiative to the company mission. Once again, engineers want to have impact. They want to have purpose. They want to understand why they're working on something. OKRs, when done well, can actually have a very important effect on this.

The other thing is really about accelerating release speed and frequency. How many of you have read the book, "Accelerate?" Very good. If you haven't, I highly recommend it. It comes from the research that has come from the "State of DevOps" report that has been running probably for the last four or five years. They actually come up with some good metrics about how you do measure the productivity of an engineering organization. One of them is really about this speed to release. If you can release every two weeks, if you can release daily, hourly, or on-demand, it's even better.

You can't just simply release really rapidly. You also need some counterbalancing metrics like making sure when you release, you don't break everything. There's also some things like failure change on release so that you're actually developing quality as well. This is one of the biggest lessons learned from both continuous delivery in that book, which is, the quicker that you accelerate this feedback loop, the better it is, and the better your engineering organization will be as a result. If you're looking for big lever, this is probably one of the biggest ones to start with. It's a hard one if you've got really long release cycles, but it's definitely worth it as well.

Choice

We looked at impact as one of the secrets. Let's talk about another one of these secrets. This is really about choice. Engineers love choice, but maybe a little bit too much choice sometimes. When developers disagree, they love arguing over these abstract ideas. Choice is quite an important part because it's part of this problem-solving perspective. Part of it is having some say and being able to say what the solution is, having a say in how I work as an engineer. This is, "I like to have a say about how I conduct my daily business," and then also degrees of freedom. It's interesting because I don't say complete freedom, and we'll come back to this in a bit.

Around solution choice, things to be careful of is when you're a large organization, it's tempting to say, "You have to use x framework," You get this, the larger your organization is, you want to have some consistency across the organization, so it makes sense that everyone has to use this framework. You have to be careful because that can backfire because it's removing choice from developers. Often, people – and you get this if you have a separate to the architecting group – are making decisions and then developers get to just simply implement these decisions. That's really no fun if you're an engineer, and you really want to make sure that engineers are involved early so that they're part of that process of choosing how they build particular solutions. Then if the output is particularly predetermined, so "Here are all the tasks that you have to implement for a particular feature", that's also not very great from an engineering perspective.

In terms of how to work, one of the interesting things after working in Agile environments for a very long time is I'm really non-prescriptive. I'm not going to go to a team and say, "You have to do stand-ups at 9:00." Even though I wrote a book on retrospectives, I'm not going to say, "You have to do a retrospective every Friday." I don't believe in that. If you have a single way of working across your entire organization, that's a big smell you want to watch out for. If you have prescriptive processes, and it's ok to have them at the start, but if you're not actually improving your processes and changing it, you're probably not actually living the Agile values because improving, adapting.

If you're optimizing for an individual, this is really hard because as an individual engineer, I might have my personal preferences. As a leader or manager, you want to optimize for the team and for the organization, not for a particular individual. You have to be careful about boundaries of freedom because one individual's choice might start to impact the productivity of your team. Degrees of freedom is hard because we want to give lots of choice. You hear this term about developer autonomy, giving them lots of power to choose.

You have to be careful about heavyweight rules, and we're seeing a trend away from architecture rules to more principles to help people understand what a good decision looks like in their environment. I think there is something about too much freedom, so to say you can make any choice, whatever you like. I've seen a lot of companies that say you can use whatever programming languages you like and then ended up with 20 programming languages when they have 10 developers. You can imagine how that's going to be maintenance-wise long term.

There's an interesting balance between autonomy and alignment. My autonomy can start to step onto somebody else's autonomy because I'm making a choice that affects more than me. This is where you as a leader are trying to find out the right boundaries of both aligned decision making and autonomous decision making. If you don't really have a clear decision-making process, this is another thing that fuzzies up the boundaries, is that as a person, you have a certain amount of decisions that you can make for yourself. As soon as it starts to impact other people or other departments, your decision-making part starts to become less impactful. You can give input, but you're maybe not the decision-maker. To help improve this, you have to describe what those boundaries are for where you are.

The principle here is really cultivating choice by making the right thing easy to do. If you want people to use a preferred framework, make it easy for them to adopt it, make it valuable. That's the interesting thing. If it's useful, people will come to it. That's one of the principles you can use here. The good thing here is you should automate the basics. This is one of the reasons we're seeing a lot of stuff around developer productivity tools. Internal teams are really focused on building common libraries, not because everyone's going to be forced to use these libraries, but just because they've solved this problem, and my team can benefit from that immediately scripts that automatically bootstrap new environments, new projects, make it easy. These are examples of making the right thing easy to do that then help with then building on the interesting choices.

Using architectural principles overall. The 12 factor architecture is really good example of 12 simple things that you can explain that talk about cloud-native or cloud friendly architectures. That's something we're seeing a lot with different types of companies that are starting to adopt architecture principles. Your company is at a different stage, you're optimizing for a different problem. These are things that you can help articulate. Make sure that you set up the goal, and step out of the way. This is really hard, because we're often, as developers, people who want to maybe come up with a solution for other people. Actually, if we really want to engage with people, what we should really be talking about is, "Here is the problem that needs to be solved. Here are the constraints of how we're trying to solve that problem." You want to give that to the team and give them the ability to actually problem solve that.

Too many places start to take away that choice by actually already predetermining the solution for those teams. The best way that you can engage with developer choice is making sure that you're clear about what it is that needs solving and also by what constraints should that solution be. Then to solve the decision-making boundary, be clear about your decision-making process. For a decision that affects the entire organization, you might decide, rather than everyone has a democratic vote, everyone can give input. Actually, the choice will be made by a smaller group of people who are trying to balance out the needs of all these different teams and groups. This is ok. You don't have to give everyone absolute input or choices for every decision that you make. You just need to be clear about where those boundaries are and what types of decisions you have.

I tend to think in terms of technical decisions about those things that a team affects, the things that affect subpart of a product, and then things that are affecting the whole platform as well. You want different levels of decision-making processes, depending on how irreversible the decision is and how wide that impact will be when you actually make that decision.

Improvement

We looked at impact, we've looked at choice, what is the third secret? Let's have a look. This one is really about improvement. Developers want to continually see things improve. I had a hard time thinking about specifically what this meant to me, but one is definitely about personal improvement. As a developer, one of the common things that probably we all share is we want to learn, we want to grow. That's a key thing. Also, if I'm working for a company, I want to make sure that our company is also improving. if we're working for Tesla, we want to see movement towards automated [inaudible]

Then the other thing is really about the good work environment. Engineers will often complain, and I think one of the good things about a good engineering management group is making sure that people's complaints get addressed. Engineers will often think about the things that they can't control, things that are in their environment. To create a good engineering culture, you want to see improvements in that environment as well. I see that as the core responsibility of management.

Some traps around each of these different areas – if you don't have any growth opportunities, engineers will leave your company. It's an actual part of our process. You see this with startups, and you see this with companies who aren't growing. People will want a bigger role, more responsibility. One of the challenges that you have as a leader is trying to find something that's challenging for this person, and sometimes that will be across the boundaries of your company. They'll have to join another company in order to have that opportunity to really grow.

Being careful about repetitive work – if something is repetitive, invest in automating it. Or, if it's something that needs doing, rotate that role. Be careful about things that are just simply the same thing day in day out because people will get bored, and engineers need new challenges all the time so they feel that they're actually learning. Another thing that happens quite a lot is really a lack of feedback and support. A common thing I hear from engineers is "How have I been doing? Have I been growing?" by the time that you get to an annual performance review of some sort there shouldn't be any surprises. If there are, it's probably an indicator that your environment is not providing the right feedback or support. Make sure that you address each of these things if you really want to help engineers grow.

The other thing that can stop people is really this fear of failure. If somebody makes a mistake, and they get fired for it, how safe do you think that environment is for learning? You need to think about what causes that and how to create safety when people do make mistakes. Very rare it's a person that makes that mistake, it's more about the system that allowed that mistake to happen. That's actually a leadership responsibility. Remember that board people will quit. If you're not actually encouraging them to grow and finding opportunities to grow, they will leave you, and they'll find some other place where they can actually do that.

What about traps to steps to mission? One of them is unclear priorities. It's something that I see a lot in different organizations, is that if you haven't actually gone into an organization and you have clear priorities, this is really confusing because you don't really understand how your work connects to the broader mission. Early on in my time at N26, I actually visited Spotify in New York and talked to one of their senior directors. It was really interesting because they've got six levels of prioritization. That's crazy. Then if you think about it, Spotify is something like 3,000 or 5,000 people.

Once again, it's interesting because you have different hierarchies of prioritization, but it's very clear in the order of those priorities. Me as an individual, I know if I'm working on something, and it's not the topmost priority, I can go point to the common source and say, "I think we should be working on this thing instead," so I know I'm actually helping the company move in a way that it's going. This is something that you can actually influence.

Make sure that you re-emphasize this mission that people are doing, but also make sure that they can understand initiatives. Sometimes a mission can be too broad and abstract. Too much of a big leap. It's like, "How do we know that we're moving to perhaps autonomous vehicles?" Then you can help people understand, "Here's the initiative that's actually helping towards that, and this is why your task is actually helping move towards that task." Try to address this gap.

Another thing that happens a lot is really intransparent information. Maybe you have priorities, but maybe they're stuck in JIRA somewhere. Nobody likes JIRA. One of your tasks is really to make sure that people understand where information is, how to pull that information so they get the best out of it. Traps around the work environment – things to avoid here are these sayings about "That won't work here." You see this in very large organizations that aren't used to lots of change. "We tried that, and it was really painful. No, that won't work here again," You need a supportive environment to try things out. Those things will sometimes fail, they'll be a bit painful, but, actually, you need that environment to say, "We don't know if it's going to work out, but let's see if it actually improves the environment."

If you wait for people to say, "Can I do this," this is a big indicator that people don't feel safe, or they're not encouraged to improve their environment. Asking for permission, you really want people to ask for forgiveness. "I tried out this thing, I'm sorry, I think I stuffed up." You want people to continually improve their environment.

Then, once again, this lack of feedback about what your company is actually doing to take in employee feedback. How many of you do something like Culture Amp, measuring what's going on in your company? It's about a third. Even when those core trend surveys come out, how many of those people are actually taking that feedback in, and people are saying, "We're doing these initiatives based on your feedback." Often, management will be so busy just getting those things done, but they'll forget to connect their initiatives to the feedback that actually happened. Make sure that you take in that feedback, but make sure that you act on it and make that connection to where that feedback comes from because it's going to be longer and people will forget.

The principle here is really cultivating improvements by making small changes easier. This is something that all of you can actually influence, be it in your team, be it with another team member, or across your organization. Some concrete ideas are really making sure that you take actions from retrospectives. "My pet peeve. We talk about this topic. It comes up again and again. Why does it keep coming up? Oh, we didn't do that action from last time." Making sure that people follow up in actions is one of your basic fundamentals, really. Making sure that you improve the system through post-mortems.

I see this with not just incident post mortems, but also from project post mortems. Some large scale projects that maybe didn't go so well, you need to take the time out to actually reflect on what things did go well, so you can amplify those things and what things would you change for the next time your organization takes on a large initiative. This takes time out because rather than working on the next item, you're really trying to focus on improving the system. That's really worthwhile.

Creating forums is an important part. I don't believe in pushing everyone to work in the same way. What I do believe in is creating ways that people can pull advice from other people who faced similar scenarios. Be it your guilds of people with same functional skills, or be it at the end of an initiative, or some brown bag, or lunch-and-learn learning session, you really need to be thinking about what environments you create to amplify these so that people are aware, "Somebody in my organization has already faced this problem, and I know who to reach out to in order to understand how they approached it," These are some of the things that you can actually do.

Also, make sure that you define growth paths. You do this a lot in early-stage startups where people are just doing everything that they need to do to keep the business running. Then people want to ask, "How do I grow? What's my next step? What's my next challenge?" Even in larger organizations, you may have these growth paths, but what you're trying to do is trying to help people find out, how does it apply to them in their environment? What's the next opportunity based on what they want to grow in? Make sure that you talk about different growth paths, and not just a management track, but really a individual contributor track or a technical leadership track where people can stay technical and hands-on. That's a really strong indicator of a good engineering culture.

How

We've looked at these three secrets, let's quickly talk about how you can actually take some action from this. A very simple five-step recipe. First step is make sure that you gather input. You talk to your existing organization. You have engineers in your team, you should listen to why those engineers are still working for you. There's probably some good reasons. Gather some input from those people.

Publish your tech culture. One of the interesting things about this is once you've talked to people, synthesize that information. What makes your environment different? Why do people come to choose to work for your company, rather than somebody like Google or an Amazon. There's lots of great reasons. Maybe you get to work on a product that you'd never get a chance to work in a big giant, perhaps you get to work in a much smaller team so that you know everyone. That can be really important for people as well, but make sure you describe how you describe your tech culture to other people.

Then think about prioritizing key improvement areas. As you talk to people, there'll be definitely pain parts, painful points, which aren't so ideal. Here's what you want to actually talk about, "Ok, these are really good parts of tech culture, but here are some areas where we should definitely improve as part of that." Then decide on actions as a leadership or a management group, and make sure you follow them up.

If it's that people aren't getting feedback on a regular basis, find out a way to make sure that they get feedback from peers on a monthly basis or something like that. Maybe people need feedback training, and so you have to actually decide how you're actually going to fulfill that to improve this engineering culture.

Then, it's as simple as repeating. It's a five-step simple recipe about how you can improve your engineering culture.

We all have metrics, we'll have good questions, so here's some three simple questions you can use to ask yourself, "Are you building a strong engineering culture?" How many handoffs do you have between software engineers and customers? Here's a hint, less is better. Are software engineers involved in how they solve a business problem or are they just simply implementing a business problem? What opportunities do software engineers have to grow? These three simple questions we can link back to simply asking three simple secrets about impact, choice, and improvement.

Conclusion

You all have an ability to improve your engineering culture, regardless of where you are, and where you want to actually get to. I hope that you have a better understanding about where these different elements are that you can influence. Remember that engineers have these choices. You have the ability to steer how they choose this by really focusing on improving your engineering culture, so it becomes the appealing place for the types of people that you actually want to hire.

Questions and Answers

Moderator: I'll start off with one question. One of the second things that you said was publishing your tech culture, and so a tactical question around that is, how do you publish it? Where does that get published? I'm assuming you're taking inputs from the engineers, but what does that look like if I'm going to do that tomorrow?

Kua: What I would say with codifying your tech culture is starting to look at maybe other sources for inspiration. A lot of companies have published their company handbook. You can think about the "Valve Handbook," or Amazon's "12 Principles of Leadership." You can use them as inspiration for thinking about how you want to codify our culture. I don't think there's a single correct place, so you might start by doing an internal blog post or something like that. There are so many different ways that you can implement it, but you have your own choice about how you'd like to do this.

As you start to write your culture, don't write it and then publish it to the world. Publish it internally first. As you talk to people, as you try to work out what elements of your culture are unique, these are things to test out with your engineers. If it doesn't resonate with them, then it won't really fit. They're not going to be supportive of it. This is one interesting thing about when I join a new company, or when I'm helping a new company, is I really try to listen to understand what makes that company unique, and every company is unique for its own reason. I'd start off with something simple like an internal blog post, maybe an internal presentation or info deck, but just a simple way to describe the company culture that is written down. That would be the most important part.

Participant 1: It would be interesting to hear your feedback on how to facilitate to get a culture of learning. Currently, where I'm stuck, there's a lot of, "This is the way we do things because we've always done it that way," and I want to try to attack that and to break it down. People are fearfull of change and of new technology, and I really don't understand why people are fearful of new technology, why they are in tech, in general, because you should probably do something else. It will be interesting to hear of your thoughts on that.

Kua: I think that's a couple of things. I don't believe in making people do things. Think about what stops them from taking part, and also what encourages them. They're the two levers that I tend to think of. In terms of what's stopping them, sometimes it's maybe too much work. That's a common thing; engineers often feeling that they have to have that pressure to building a new feature, to completing the things that their team has been working on or what they've been allocated to. I think one thing is, as leaders, trying to make sure that there's enough Slack time or opportunities that people can take part without feeling pressure from normal work.

I think if everyone's working 100% capacity of functional work, they have no time for learning. As a leader, I'm thinking about, "How do I create some time so that they can actually take part?" That might mean that you start off with lunch-and-learns. You do a learning activity during lunchtime, incentivized by bringing in free food – everyone loves free food – and then maybe try to make sure that you amplify that. This is also the encouraging stuff because I think a lot of it comes down to what people get rewarded by. In most organizations that don't have a strong engineering culture, everyone gets rewarded by the feature or the output that they produce.

The other thing that you should be doing is making sure that you make learning a rewarded part of your culture. When I go into a company or to a team where learning hasn't been a big thing, and I see somebody either trying to do a lunch-and-learn session or to do a book club, I amplify that message. I say, "This is a really great thing. This is important." You as a leader can explicitly focus on those elements and amplify them to say that this is an important thing that you want to cultivate and encourage, and then you might be able to find time to actually explicitly give people that time. Companies do things like hackathons. Google was famous for it's like full day a week so that they had one day for personal projects, but they're the concrete examples I would think of.

Participant 2: You mentioned about using a framework like OKRs for alignment, which imply that they should not perhaps be used for other things. I was wondering whether you could enumerate where you wouldn't use OKRs, or things that you've seen before?

Kua: One of the things I've learned from systems thinking or Theory of Constraints, is the saying "Tell me how you'll measure me, and I'll tell you how I behave." My pet peeve with OKRs is coming from particularly business people. Business people often want a metric, and then they want to manage people by that metric. If I'm a developer, and I'm measured by the amount of code I produce, I can write a lot of code. It may not be the most maintainable, it may not be the easiest to change in the future, but I can definitely play that metric. That's the big pitfall that I would see with a lot of OKRs, is that a lot of people forget that when you talk about OKRs, the first thing to talk about is this objective, what's the purpose? What's the goal? A lot of people too much focus on the key result.

What number are we trying to touch, and how big are we going to get to that number? I think key results don't always have to be a number as well. Key results can be like an initiative. You start a project and you deliver that project, for instance. That might be a key result is that that project is delivered or from a leadership perspective, some key results that I've used in the past, like "We're going to publish a growth framework," It's not really a metric. To help engineers understand how they want to improve and grow, we want to be clear about what their potential growth parts are. Publishing that would be maybe quarterly key result. That's one of the big things that I have pet peeves with OKRs is that they're often used by management through objectives, which is management through numbers and targets, forgetting that the whole purpose of OKRs is really about the objective. Making sure that this objective is contributing to the greater goal, and people forget that.

Participant 3: Excellent talk. Thank you for that. I have a question around processes. How do you decide as a leader which ones we should mandate and which ones you want to give autonomy for? For example, you want to say that these are the principles we will follow for code reviews, and that's just good practice, good engineering culture. Let's say, should we say things like, "This is how we're going to write acceptance criteria across all the 50,60 engineering teams or so on." What is your thought on that?

Kua: This one's a tough one. It's one that I still struggle with. What I think about is, when I make a choice about a process, what I'm trying to think about is optimizing for the entire system. When I think about that, that's my guiding principle about if I make process mandatory, does it improve everyone's lives across the organization by either removing uncertainty, or by making something that is already a common default more explicit? Then I'm very careful about what processes we implement.

N26, for instance, I came in, and we had TypeScript back end, Java back end, Scala back end, I think one more, but the team had defaulted to a thing of, "We don't want another programming language because we just can't maintain another service given that we are all mostly Java programmers." From that side, it was like easy enough to say, "Ok, we're not adding another language into the mix until maybe we remove the mix or until we get a little bit larger," because the operational complexity just became too much.

For that, it was easy because I was able to say, "Ok, this is a pain point for most of the team, and it seems to be the general consensus, so all I'm doing is really making the default sentiment more official." I'm not coming in and saying, "Ok, you have to use .NET because that's my preference." I'm looking at the pain threshold and trying to optimize for the entire system. The way that I'd be doing that is really by just talking to your team. I'd be looking at, "Is this a pain point only for this team, or is it a pain point for this team, and that team, and for every other team?" Then I'd be looking at where that common pain point is across those teams to think about, "Ok, there's maybe misclarity about how we do pull requests across teams." That means that where there's misclarity, there's a chance for improving that process, and so that's where I'd be listening for. That's my general process.

Participant 4: I'd like to ask questions from those of us who work in B2B setups where some of the traps you mentioned are these trade out requirements of our customers. Have you got any hints, tricks, tips how to sell the technical culture to our non-technical partners?

Kua: When you're in a B2B, you're further away from the end customer. Even in a B2B place, I think you can still get access to customers. Even in your portfolio, you probably have a trusted partner who then maybe give you access to customers. The thing that I see with a lot of platform companies or B2B companies is that they either have an internal team that is producing the B2C side and then they have access to the customer. You can either do it through proxy, through another partner, and get access to their customers, or you can create it internally with the team your own. That would be my advice.

See more presentations with transcripts