Culture Through Tension: Leading Interdisciplinary Teams with Nick Gillian

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I’m sitting down with Nick Gillian. Nick, welcome. Thanks for taking the time to talk to us today.

Nick Gillian: Thank you, Shane. Great to be here.

Shane Hastie: My normal starting point for these conversations is, who’s Nick?

Introductions [00:38]

Nick Gillian: Great question. I’m Nick Gillian. I am the co-founder and CTO of Archetype. We are a physical AI company based in Palo Alto in California, although we have teams all throughout the US and Europe. I am at heart someone who has been working on machine learning and sensing my whole career. I really love working with machine learning and AI and solving deep sensor problems. I’ve been at Archetype for the last few years since we founded the company. Before that, I was at Google for almost a decade where I was running AI machine learning teams, doing a lot of on-device sensing.

Before that, I worked at Samsung Research and ran my own consulting company. Then before that, I was in academia for a long time. I did my PhD in machine learning and real-time sensing way back in the early 2000s before machine learning was cool and everyone was working on it. Then I was at MIT for multiple years where I did a postdoc there. So, for almost 20 years now, I’ve been working on machine learning and sensing. Yeah, I’ve really loved that life.

Shane Hastie: What’s special about physical AI?

Defining physical AI [01:38]

Nick Gillian: The way we would define it as a company is we really think about any use case where you have some form of sensor in the world and you want to make sense of it. So, you want the intelligence to take data from those sensors. It could be cameras, it could be microphones, it could be more temperature and electrical sensors and not a large industrial machine, for example. It could be really complex sensors like radar and LIDAR. Even you can use WiFi, for example, as a sensor. You can actually turn that into a sensing mechanism.

Taking in all of those different sensors, having a large intelligence that can fuse that together and perceive, reason, and act, and then be able to control that in some output form. That could be through robotics to control and actuate a system. It could be to alert a user, for example, in a safety use case that one of their team has climbed up the roof of the building to power-hose it and the person managing the building should pay more attention for safety reasons, or it could be at the end of every day generating an automatic report to say how productive your factory was, for example, so any use case where you want to take sensing data and you want to make sense of it. That’s really what we’re working on at Archetype, and I’ve worked on many versions of this throughout my career.

Shane Hastie: This is the Engineering Culture Podcast. What makes a good culture?

Building Culture Through Productive Tension [02:53]

Nick Gillian: Oh, that’s a great question. For me, I think the thing that makes a positive culture, and at least the teams that I really enjoy to work in, is when there’s a positive tension in the team between a couple of different aspects. For example, I really like working and building and growing teams where there’s some form of highly ambiguous novel form of research or innovation that you’re then trying to pull into an actual product. Not just do research for research’s sake and write a paper and go to a conference, but how do you actually take that technology and bring it zero to one, but then actually make it into a real piece of technology that can go into a product and then actually make that product into hopefully multiple products. A lot of the things I’ve done in the past is taking that stuff and platformatize it, for example.

There’s one example there where you have the tension between building a team that can do really innovative research and a team that has the rigor and the kind of methodology to turn that into a robust product. There’s a friction between these two things. Because normally the type of person that can do really zero-to-one inventions, some of the skills you need to be really good at that are the inverse of the skills you need to be an engineer that can build a system that has five nines of support and the speed at which you work and the rigor at which you work. There’s always a friction between those. So I really like that type of tension. I really like teams where you can build a tension between having, for example, engineers and designers that are in the same team or software engineers and hardware engineers that work really closely together to actually co-design the hardware. So I really like these teams where you can actually build that type of expertise and tension in the same team.

A lot of companies, the way they do this is those different components, they sometimes live in physically different buildings or physically different parts of the world, and it’s a bit more waterfall. The hardware team will build some hardware and spec it, and they’ll hand it off to a software team, which will build it and spec it, and they’ll hand it off to a design team, which will then put some nice layer on top of it. That works for some companies. But I actually really like companies that try to put everyone in the same sub-team and build these full-stack teams. It brings in some interesting challenges in terms of, how do you handle those different personalities and everything else? But I fundamentally think it leads to better innovation, better products, more exciting teams to work in, because I can learn a bunch of things from a hardware expert or the way a designer thinks about how to communicate ideas. Sometimes I really love to absorb that. So that’s the type of culture and team I like to work in and build and be surrounded by.

Shane Hastie: How do you keep that cross-functional tension productive?

Keeping Cross-Functional Tension Productive [05:39]

Nick Gillian: Well, I think there’s not one answer to this because I think as different projects go through different phases, like the different lifecycle of an invention, for example, or the different lifecycle of a product, from the initial whiteboarding and sketching to maybe the early prototype to maybe the pre-production system to the thing you’ve launched to then the thing you’re going to maintain and continually update, I think how that tension, how that team building, how the dynamics work is very different.

As the team naturally grows over those stages as well, how do you clearly communicate across those teams? How do you set it up so that in a two-week sprint, for example, you can actually clearly define a goal that a designer and a hardware engineer can work at the same speeds, because it takes a lot longer to build a chip than to draw a chip, for example. So naturally of the progression of a project, I think these things will actually change and evolve. There’s not one solution. There’s maybe five or six different phases of that lifecycle.

Shane Hastie: As the team evolves through that lifecycle, what’s happening to the team membership? You mentioned the person who’s great at zero to one is not necessarily great at the hundred to one million, but we don’t want to lose them.

Managing Team Evolution Through the Product Lifecycle [06:56]

Nick Gillian: Yeah, yeah, for sure. I think typically you’re going to start out with ideally one key representative of each of those functions. You’re going to have your engineering representative, maybe someone who’s going to do more of the R&D work, maybe a person who’s more driving things from more of the design perspective, and you want to have ideally the smallest footprint of the team possible, because that’s when you can move fastest. Ideally, you want to go through lots of ideas quickly and throw away most of them. I’m a big believer that some of this innovative work, it’s very hard to sit down and think of what the thing is first and then go and build it. You kind of have to get a very rough, foggy idea of the concept. Then actually by building it, you learn what it is.

Particularly for some of the things we’re doing at the company now involves a lot of multimodal output in these models, and there’s not a lot of work in that space. So even to us, it’s unclear what’s possible, what the model can possibly do. The only way we can really work that out is by building small prototypes and ideas and moving very quickly. Only then when we’re all standing around this box on a Friday to do the review of, “Here’s the current demo”, only then will someone say something and be like, “Oh, that’s really good. We never caught that detail”. Then we can build on that. If you do that for many, many weeks and months, you remove that ambiguity, and then you actually realize what this thing is that you’ve been building for six months. Then at that point it becomes very obvious what it is and very simple to define it, but it was not simple to define it maybe six months or 12 months before when you start. So only by the process of building this can you do it.

So, as you go through that process, the team will naturally grow from maybe those three or four key people at the start to, like, “Okay, well, now we need this real-time latency reduced as much as possible. Well, let’s bring in an expert in system optimization or in streaming or in distributed computation or something”. Then you’re going to start to maybe then build up a team and a sub-team, and these people will start to work together. So as we go through that process, the team will naturally grow in scope.

Then at some point, you’re going to have to have… not everyone can be in the room at the same time. So maybe now you have the lead of the team or the manager of the team as the person that’s representative, and then you have to deal with all these communication things of, like, well, how do you take that information and communicate that back to the rest of the team who can’t be there maybe either because they’re physically in a different time zone or maybe just they’re working on another project at the same time and they can’t be in both meetings at once, for example? How do you then capture that communication of this is where we’re going?

There’s typically these step functions where you build a process, and that process really starts to work. It works for a certain point up to, say, 20 people. Then you just get to the point where you just can’t communicate anymore with that process, and you have to then bring in a little bit more process and go to a new step. That maybe brings you to, say, 50 people. Then at some point you just find that that fundamentally breaks very quickly. Then for you to go from 50 to 100, it’s a very different process. You need a lot more rigor. You need a lot more structure. You need a lot more independent Slack channels and documents and gates to review things. As you go through this, you naturally hit these scaling barriers. At each scaling barrier, you have to say, “Okay, it’s time now to go to the next level of process or the next level of detail to make this start to work again because we’ve got too big”. That will work for X number of weeks, months, years. Then you’ll hit that scaling limit, and you’ll have to go back and review it again.

Shane Hastie: While that’s going on in parallel, how do you get the next idea at the zero-to-one stage?

Prioritizing Ideas and Breaking Down Hard Problems [10:44]

Nick Gillian: Part of this is maybe not even getting the next idea. Coming up with lots of ideas is typically not the problem. Particularly for people who work in a zero-to-one area and are comfortable working there, ideas are a dime a dozen. One of the problems is actually having too many ideas. How do you either start to group them together to actually come up with the theme that unites all of those ideas, and then you can start to work on that abstract theme as opposed to a very specific instance of it? Or the other one is, just frankly, being able to look at those ideas and then say, “Which is the idea we should prioritize first? Which is going to move the needle the most?”

Typically there, at least in my current company… I should mention that I co-founded it with four other co-founders. We all worked at Google together for almost 10 years, so we’ve worked together for a long time, and we’re kind of a full-stack team. We have myself in the ML, and we have Jaime who does more of this kind of sensing work. We have Leo, who’s our key designer, and we have Brandon, who’s really good at driving forward teams and making sure things can actually ship. Then we have Ivan, our CEO, is really the glue to unite all those things together. So we have this full-stack team.

When we have all these ideas we could pick, it takes a little bit of courage to try and pick the hardest idea because that’s normally the one that will move the needle the most, even if it’s the most difficult. Then you have to be like, “Okay, well, there’s no way we can do this in one step. How do we break this down into a few smaller steps and then maybe in one month be able to actually make progress on that?” as opposed to taking the most obvious, easiest thing, but that’s probably the thing that everybody else is going to try first. Sometimes you try that, and you maybe get to the second or the third step of this. You actually then realize there’s a better idea that was there all along and you can pivot, and you can then go 180 degrees in a slightly more interesting direction or maybe a direction that you actually realize, “Oh, actually if we did this, the customer market is much bigger or our ability to execute this and get it into a product, we could do this way faster. Let’s go this direction instead”.

Shane Hastie: Culture is the combination of all the behaviours that happen. How do you keep culture not necessarily consistent, but aligned as the organization is growing?

Culture as Amplified and Tolerated Behaviours [13:08]

Nick Gillian: The way I typically like to think about culture is culture is an everyday thing in a company as opposed to some slide deck with three words written on it. The way I try to think about culture, and I try to actively drive this, is culture is the behaviours you amplify and it’s the behaviours you tolerate. So on the positive side, it’s the things that people do, a certain way of thinking or a certain piece of creativity or a certain ability to be brave and take a big risk. Those are the things you want to amplify in a company.

On the flip side of that, there’s the bad behaviours which you’re going to tolerate. If someone oversteps that line, ideally what you want to do is call them out on that or maybe pull them aside in a smaller meeting or a one-to-one and say, “The way you spoke to that person is not how we think about things at this company, or the point you made was really good, but actually the way you expressed it, you completely lost the point. People didn’t capture it because they got caught up too much in how you brought it up. So actually, why don’t next time you try to do it this way? Instead of saying, ‘Person X didn’t do this,’ you bring it up as, ‘We as a company are not great at X. Wouldn’t it be good if we tried to do Y instead?'” for example.

I typically find people will listen a lot more and it’s a lot more of an inclusive and a supportive culture if you do that type of thing. That’s how I think about culture. It’s that everyday behaviors that are happening in the company. It naturally then flows to everybody else in the company, and you have to keep an eye on it.

Shane Hastie: I know from our conversation earlier before we started is that you do quite a lot of mentoring for folks within your own organization and outside. What’s it take to be a good mentor?

Becoming a Good Mentor [14:57]

Nick Gillian: One thing is perhaps making a lot of mistakes yourself and putting them in some memory bank so if someone talks to you, you can recall that and they don’t necessarily have to live that mistake. That’s maybe one thing.

Another one is starting to see, as people go through their career journey, I think this goes back to that scaling pipeline I talked about as well, they have a certain process that maybe works well for them that brings them from a low performing senior engineer to a high performing senior engineer, for example. But the thing I realized is that some engineers don’t realize that to go from a high performing senior engineer to a high performing staff engineer or a principal or to go to a director at least, you don’t just keep continuing that same behaviour as a linear function. There’s actually specific things at each of those stages that you need to change or you need to really be aware of.

The way I normally phrase this to engineers that I’m trying to mentor and grow is, “As you go through your career growth, it’s about going from doing a good job to having high impact”. For example, for a junior engineer who’s starting, for them to be good at their job, they just need to come in and take a task and execute the task well and complete the tasks on time. That’s the bare minimum. Then as they grow in their career, as they start to move up to a more senior engineer, it’s like, “Well, instead of someone else setting the task, you should be able to own the project and work out what the tasks are yourself and make sure the tasks get done so the project is a good project. But then as you grow beyond that, it’s not just completing the project, but can you actually come out with some specific key result in that project? Maybe you’re getting state-of-the-art compression results, or you’re able to get some business impact that reduced costs by 10X or grew customers by 30X or whatever that might be”.

But then the thing I see where folks struggle to maybe go from that senior to staff or staff to senior staff is going from having good results to actually having impact of those results, to be able to communicate those results and actually get that out across a business or communicate those results, for example, to your customers. Maybe you have reduced customer costs by 10X, for example, and that’s a great internal engineering result. But do your customers know that if they come to you, they’re going to get a 10X reduction in saving? So the difference between going from results to impact, for example, I see people getting stuck on that.

Typically to get good results, you need really good engineering skills and product management skills and all these things. But to go from good results to good impact, that’s normally where you actually need a lot of strong soft skills as well. So it’s not just being the best engineer on the team or the ability to be a very strong manager and pull together four or five people or 20 people. It’s like, how do you actually take that and then have the soft skills to be able to go and share that with your stakeholders or your leadership or your customers or go and work with a person that updates the website and put that, “We can save you 10X in GPU costs”, for example, and actually having that as one of the key business ROIs?

The Journey from Execution to Influence [18:09]

Then I think one of the most challenging steps is to go from having high impact to having high influence. That’s probably one of the most difficult things as either a very senior engineer or a principal engineer, for example, or a very senior leader, like a director or a VP. It’s like, can you actually implement an entire team or an entire org of people to go in a certain direction with you before you even have any results yourself? They kind of have to believe in you. You have to be able to articulate a vision to them or a clear goal that is exciting or motivating for the team or the company. Can you actually help guide all these people that may not even report to you? They may not be in your reporting team. They may be in different teams or different orgs, maybe even different companies in some case. Can you have enough influence over these teams to actually motivate them and get them to want to come and work on this project with you to then go through all those steps again to actually get high impact?

So I think going from being good at these kind of micro tasks to owning projects to getting results to having impact to having influence, I think this step function is something I typically help a lot of engineers, first of all, just see that step function. Maybe they don’t even think about the difference between doing a good job on a project and actually having a key business result coming out of it, or it’s like, “This is really good work, but you haven’t had impact on it, so you’re missing that impact”.

Shane Hastie: That’s a very, very clear journey that you’ve laid out for the individual contributor. What are the bumps in the road that they’re going to most likely come across?

Overcoming Engineering and Social Bumps [19:51]

Nick Gillian: I think this is going to really depend on which of those stages they’re at. Because some of those bumps in the road are going to be engineering challenges that require maybe a single IC or a manager who’s managing a small team of four or five engineers to be able to sit down and say, “Okay, we’re not getting the throughput we need for this system, for example. We need to completely redesign IO infrastructure or move from pump-sub to some other architecture design to be able to remove this bottleneck and go and execute it”. They can control their own destiny of like, “Okay, well, let’s come up with this better design. We can go and execute it, and I can go and solve this problem”.

But at a certain point, the ability to solve that bump in the road gets beyond your own control to solve it. That’s where the soft skills come in, where you need to be able to go and work with, for example, the database team who maybe don’t report to you or maybe are not even in your manager’s manager’s org path, and you need to be able to go and work with them and say, “We have this really important project, our customer over here, and we need to reduce latency by X. For that, we need your team to go and implement this new protocol or this new design to allow us to do that because you’re the owners of that part of the system”.

So I think that the bumps in the road will depend on, are they engineering bumps or are they more cultural bumps across the company in terms of how the speed or the process or how people think about value, for example, or priorities? Or they could be more of these more team soft skills where you either have to work closely with a customer or another stakeholder or another part of the company to convince them and motivate them to help you do your job so you can push through that bump.

I think as folks go through those step functions, as you mentioned, the natural curve of this is things go from hard engineering problems to hard social problems. That’s really as a more senior manager or as a more senior IC where you have to really start to bring on those other skills to be able to balance that.

Shane Hastie: What’s the really important question I haven’t asked you?

Nick Gillian: Well, the first question people always ask me is where’s my accent from. But that’s maybe more of a sideline. As a New Zealander, can you guess? I’m not sure. Maybe you read my bio, so maybe you can already guess that.

Shane Hastie: I didn’t actually look at where you’re from, but I’m going to guess Ireland.

Nick Gillian: You’re very, very close. Yes, I grew up in Northern Ireland in the UK with almost 15 years here in the US, so it’s a little bit of a mix. I guess one question you didn’t ask me is maybe on the building new products, how to handle that ambiguity. Maybe that’s a good question, so maybe we could discuss that a little bit.

Shane Hastie: Let’s dig into that ambiguity.

Handling Ambiguity in Product Development [22:33]

Nick Gillian: There’s two ways I think about handling ambiguity. One is from more of an engineering architectural team design perspective, and one is a lot more from a team composition perspective. We could briefly talk about each of those because I think they also support each other.

To talk about the team cultural perspective first, I mentioned earlier that one of the teams I really like to work in and the type of teams and orgs and companies I really like to build are interdisciplinary teams where you have a designer and an engineer and a researcher and a hardware person, for example. You’re probably familiar with the concept of a T-shaped person, a team of four or five people who are all T in nature where they’re experts in one specific area, but they can also spill out into other key areas and communicate clearly with someone that is not an expert in their area. The way a hardware engineer, for example, thinks about solving a problem versus a designer versus a machine learning engineer versus someone who’s coming more from a signal space is, the way they look at the same problem is normally from very different lenses.

One of the best approaches I’ve seen over many, many products and projects is to get those three or four or 10 or 20, how many people it is, voices in the same room to really start to try and look at that problem from different angles. Normally, there’s never one angle that solves a problem. It’s normally actually to take the through-line between two or three of them and have some form of bottoms-up engineering solution and then top-down design solution that you kind of meet in the middle. It’s like, how far can we push the engineering to solve this problem? Then how much constraints can we put on this from a user interaction perspective, for instance, where it actually makes the engineering problem solvable? Then normally there’s a very small interaction points between how far you can stretch the engineering and the limits of the constraints where that’s actually where the solution space lives. It can take some time, as we’ve talked about, to explore that space and really see what the angle is.

Normally, the only way I’ve been able to ship a lot of these very new R&D type of things and get them into production is to work very closely with designers to help put those constraints on the system so you can actually ship it. In other companies I’ve worked in, this is typically where I see a lot of really good innovative R&D. It never ships because normally the R&D is done in one part of the company, and then it’s physically handed off to another team, and there’s a big gap of depth in between that handoff. Then that team is normally a pre-production team, and then maybe they hand it off again to the actual team that will ship it. Again, there’s another gap of depth there. If you don’t have all those teams work together from the start, it normally doesn’t work. So that’s one aspect.

The other aspect is, and this is maybe thinking more of an engineer, is as a software engineer, I like abstraction a lot. I like clear block diagrams a lot. They really help me think about how to design a system or solve a problem. One of the things that I find, particularly with building block diagrams, not to design the architecture of a system, but actually to help structure the whole team or the project or the company is, can you break that down into maybe three, four, five major components and then say, “Okay, well, the IO of each of these components is going to be X and Y”?

The Steel Cable Approach to Architecture [26:06]

That actually means that, well, not only can we define the whole steel cable of this product, for example, or this project or this feature, but now it’s going to work on this first section can actually now separate that from the second section, for example. It doesn’t really matter how you’re going to go and solve part A versus part B. We can kind of treat those as black boxes for now. As long as we can say, “Well, the output of box A is going to be X, and then that means the input to box B is going to be X. Just assume you’re going to get that. Now can you go and solve your problem there?”

One of the tools I liked a lot that we used to use back at Google and we pulled it through now to Archetype is this concept we used to call it building a steel cable. When you build a bridge, for example, across a river, the first thing you’re going to do is put in those major pillars in the middle of the river, for example. I typically think of those as the API definitions, for example, or the function calls to your class or something like this here. Then what you want to do next is you want to thread this steel cable from one side of the river through those pillars to the other. Now you can actually start to move buckets of concrete and nails and other things from one side of the river to the other and start to build the bridge around this steel cable.

So from a product perspective, it’s like, can you get that initial data packet that would come from a client to go to your software server that then goes to some AI model, for example, that then goes into some interface, that then goes back to the client as a response, can you think about what those kind of key areas are and then mock each of those components? So already from early in the project, you can get data in and data out, even if it’s garbage, but you can actually have the team start to build these different components around it. As you do that, the ambiguity of what the product is and how it’s going to work and how you’re going to solve these components, the fog of war starts to be removed.

I used it a lot in my early IC work to design systems. But I find it’s really helpful to actually structure teams and how to lead and guide projects is to build it into these layers of abstraction and then allow one part of the team to go and tackle area A and one part to tackle area B, and they would come back every day or every couple of days and say, “Here’s the progress we’ve made”. That’s a great way to decouple those dependencies and allow people to work in parallel.

Shane Hastie: Well, Nick, a lot of interesting stuff there. If people want to continue the conversation, where can they find you?

Nick Gillian: The best place to reach out to me is on LinkedIn. If you just search for Nick Gillian on LinkedIn, you’ll see me. I should be one of the first names that pops up.

Shane Hastie: I’ll make sure your LinkedIn profile is in the show notes.

Nick Gillian: Wonderful.

Shane Hastie: Thanks so much for taking the time to talk to us today.

Nick Gillian: Thank you very much, Shane. I enjoyed the conversation.

Mentioned: