Why Engineering Leadership matters with Sebastian von Conrad

Sebastian von Conrad is the VP of Engineering at Culture Amp. He was one of the founding members of Ruby Australia Association. He has given conference talks on Event Sourcing architecture and CQRS architecture pattern.  

Where are you originally from, and what are you doing these days?

I was born in Sweden and spent my youth there and at about the age of 20 I moved to the US. I spent a couple of years there before making my way over to Australia, and I've been here for well over ten years now. It's home, but I still go back to Sweden now and then to see family and friends.

From a technology perspective, I feel I was pretty lucky to get in very early. In the early days, I had jobs building websites for people. I probably had my first job back when I was 16. From there, it was just going from place to place, being part of some fascinating companies, building amazing things. Now I'm part of Culture Amp, which is an incredibly cool place to work.

What made you pick Culture Amp? Tell us more about the company and the engineering culture there.

One of the reasons why I had picked Culture Amp was that I had just come out of an organization where I'd been a very early employee. I saw the company grow from 40 to about 400 people, and being able to go through that journey was super exciting for me. But that also raised a few questions like, "How does your company culture evolve?", "How does your team evolve?".  

Coming to Culture Amp allowed me to tackle both of those problems at the same time. There were about 170 people at Culture Amp when I started here two years ago. Now we are well over 400. But it was also an opportunity to look at those cultural questions and cultural issues, which is the work that we do. Culture Amp is the leading people and culture platform, where we provide organizations with actionable employee feedback, retention and productivity metrics by combining behavioral science and data analytics. We are also moving towards individual feedback and performance management.

At Culture Amp we have a particular type of role called "people scientist". It's somebody who tends to have a background in industrial-organizational psychology. And just meeting those people throughout the interview process and seeing, how can I take the field of psychology and understanding how to evolve organizations was appealing to me.

How can engineering leaders make the most impact in a fast-growing company like Culture Amp?

Ultimately, I think that comes down to building a culture of high performance. So if we can be the engineering team that delivers again and again on what was promised to the business team, at the same time make sure that a year from now we're moving faster than we are today. I think that is what is the crux of Engineering.

It would have been much more straightforward if all you had to worry about getting stuff out, you could cut every corner and ship the software. On the flip side, if you had to worry about making sure that a year from now everything is fine, you'd spend a bunch of time refactoring and building platforms and libraries and other things that would set you up well for the future. As engineering leaders, we have to build a team that allows us to deliver now and into the future as well.

What would be your top three priorities at Culture Amp as an Engineering lead?

It is always changing. But if I have to step back, I would say my biggest priority is making sure that we are structured in a way that allows us to build now and into the future. Second would be making sure that we have the right leadership in place to be able to execute on that. We are a growing organization, and we need to make sure that we have strong and capable leadership at every level of the organization to be able to execute on the mission.

So I would say that structure and leadership are probably the top two things. As for a third, I think it is to have a strong technology vision and understanding of how we want to evolve our software over time as well.

What motivated you through your journey so far?

Different things motivate different people. Money could be one, solving a particular set of problems could be another or a specific domain or role could be the motivator.

In my whole career, "Impact" has always been the motivator for me. So I like to say, if the company wants me to do a task and that has the most significant impact on the success of Culture Amp, I'm happy to do it. I'm not going to say, "No, that's not my job." or "No, that's not my domain”. I'm always going to say, "Whatever I can do to help."

That mindset has always put me into interesting positions where people come to me and ask, "Hey, do you want to help with this thing?" And I'm like, "Yes. Yes, I want to help. If that's the thing that's going to help the company be successful, I want to be a part of that." And I think just showing up every day, being able to say yes to the highest-impact work, and then delivering on that work, I think that's what's allowed me to climb that ladder. I think you need to have an attitude of, "I'm not here to put myself first or my career first. I am here to put the needs of the business first and have enough trust and faith in myself to be able to see that if I do what's right for the company, and if I work for a company like Culture Amp, that will, in turn, reflect on me later down the track."

So I think that's number one. Secondly, if you do that, if you say, "Yep, I'm happy to help with whatever's most important", you also have to set expectations for everything else. So you're saying, "Yes, I'm happy to do this. But you have to understand that that means I have to drop this other thing that you asked me to do last week. Is that okay?"

Nobody has unlimited bandwidth. I have to prioritize our time by impact and then set clear expectations for all the other things that I am not going to do. Communication of the prioritization is also essential.

Why is "event sourcing" architectural pattern so exciting for you? And what advice would you give someone to get their feet wet with it?

I came across event sourcing at my previous job. My CTO, James Ross, was a massive proponent of the pattern and the paradigm. Just the simple value proposition of not needing to override the data all the time and keeping track of all the things that have happened was a strong selling point. Because what happened is not going to change over time, but it's interpretation will.

There are some significant downsides with the pattern as well, as we've come to learn. And so I would say, in terms of your second question, which is, "How do you get started?" The first one is to determine if this is a paradigm that is for you. It's not a silver bullet. It's not something that you can apply to every single problem. There are different solutions for different types of problems.

So regarding getting started, there are not a lot of great resources out there, unfortunately. It's still a pattern that has eluded the mainstream. There are a couple of books out there. Chris Richardson's Microservices Patterns is one that I can recommend to kind of get started; it covers a slightly different flavour. There are a lot of videos on YouTube. Greg Young is another resource that I would highly recommend. Subscribe to the mailing list, have conversations with people who have done it, particularly as you start to encounter some of the issues. Before everything, I would say find the right use case for using it and then start tinkering.

How do you plan for incorporating architectural changes to tune with the new needs? What's a useful framework or a methodology to plan and execute these changes?

Software architecture only matters in how it helps us serve the needs of the business. So it is crucial to learn about the product and business strategy, understand what we are trying to achieve and use that as a starting point for your architecture.

We are currently going through the exact exercise at Culture Amp. We know that our mission is to positively impact 100 million people through changing the world of work. Just knowing this scale, gives me an idea that everything we do needs to scale.

James introduced me to another concept “light on the hill”. So light on the hill is a vision for a specific piece of our architecture for the future. So saying, rather than trying to create the whole picture, which is hard, we can say, for this particular part of our domain, here's how we see that evolving. The teams must put the time and effort into thinking about their architecture, with guidance and input from other people. I'm a big believer in allowing teams to own their visions and the future of architecture.

I'm a firm believer in having strong engineering principles that help everyone in the team in making decisions. Every day an engineer has to make hundreds of micro-decisions, some decisions have a more significant impact than the others, but at the end of the day, we are still asking every single engineer on our team to make decisions. It is our responsibility to give them support about where we are going to help them make better decisions. We need to provide them with a decision-making framework, which is where the engineering principles come in. We also need to give them tools such as Simon Brown's "C4 model" to help them communicate, visualize and discuss the decisions that they are trying to make.

Another thing that we are doing more and more at Culture Amp & we also did at Envato is "Solutions preview". Solutions preview is a very lightweight document that describes things such as: what's the thing we are about to do, what are we optimizing for, what are we not optimizing for and what does the solution look like. This document is then put out for other teams that might be impacted by the decision to get input from them and other experts in the organization before starting to implement it.

ADR's or architectural design records is also something when done right can have a considerable impact. ADR's is more about documenting decisions that have been made, while solution preview is more about decisions that we are going to take.  

What is the tech stack at Culture Amp?

For the backend perspective, we have Ruby, Java and Elixir. We also use Python for machine learning work and GoLang from some infrastructure work. Frontend we use React and Elm which has been a bit controversial. Usually, you find organizations on one or the other, but we have made a decision in the early days that we want to invest in both. We wanted to allow the teams to decide for themselves on which the right tool for them and that has worked well for us in our hiring and recruitment as well.

What is the reason behind supporting both React & Elm when they both are competing technologies? Wouldn't it have been better to go all-in on one of them as it helps with scaling and go deep on one of them?

I feel there's a spectrum here, at one end of the spectrum it is "Use whatever you want we don't care". At the other end of the spectrum, it is "We will only use one language". I prefer something in between, maybe leaning slightly towards more flexibility and freedom.

I like the idea of having a list of technologies that you are able to pick up and use. We will consider adding or removing technologies from this list if it makes sense for us. But if you want to add new technology to the list, then we should have a conversation to figure out and make a conscious decision on why we would want to add it. One of the key aspects that people forget about when selecting technologies is around the talent pool. The hiring aspect and the talent aspect of choosing a new technology are critical.  

What are your thoughts on trends on distributed teams?

I think it is inevitable. Brilliant people who want to come and work for us might not be in the same city, so we have to figure out how to make it work with them.

At Culture Amp we have generous working from home policy, so on a given day, anyone in the team can be working from home. So I'm in favour of building tools and practices that help us cater to having people work with us from wherever they are. Few of the challenges that come with that are communication overhead and investment into collaboration tools such as Slack. With offices in Melbourne, San Francisco, New York and London, this is a problem we have already had to deal with and so we already had great infrastructure in place. But as we were expanding into remote engineering, the first few remote engineers really helped us define what remote working looks for us even though it might not have been the best experience for them at first. Thanks to that, we are in a much better place now.

What are some excellent books that you would recommend for engineering managers?

The first book would be Camille Fournier's "The Manager's Path", it is a brilliant book it builds the path on how you can be a great individual contributor to how you can be a great executive. It is something I ask a new direct report to read if they haven't already read it.

Second, I would recommend a newer book that has crossed my path recently by Will Larson called "An Elegant Puzzle". The book really takes systems thinking mindset to management, which I think is something that resonates with a lot of engineers as they tend to be system thinkers already.

---