Why You May Want to Delegate Management, with Peter Cullen

Welcome to Scaling Software Teams, a weekly podcast to help software leaders navigate fast growth without losing the magic that made that growth possible. I’m your host Wes Winham. Today, we’re joined by Peter Cullen. Peter is the product architect at Dispatch.

They’re a software company that provides an on demand courier service for businesses. Dispatch is based out of Bloomington, Minnesota and, fresh off a nearly $8 million series A, are looking to grow their engineering team substantially in the next year.

Before we get into this, I want to share a little bit about an upcoming conversation I’m really excited for:

In a couple of weeks, we’re going to have Will Larson, the foundation engineering leader at Stripe and the author of An Elegant Puzzle. This is maybe my favorite engineering management book. I’ve been reading Will’s blog for years and he’s one of, he’s an amazing systems thinker. And the way he problem solves engineering management problems for both distributed human systems and distributed infrastructure systems is pretty excellent. I’ve learned a lot and that’s why we’re giving this book away. So if you go to woventeams.com/book we will send you a copy.

‍

“That’s such an important part of being on a team and not just writing code but really like explaining your thoughts to people and really kind of understanding and also being able to articulate complex ideas.”

‍

‍

‍

And now, here’s my conversation with Peter Cullen.

 

Peter Cullen, thank you so much for joining us today on Scaling Software Teams.

Yeah, thanks for having me.

‍

What is the most important inflection point in your career that’s gotten you to where you are today?

So, I’d have to say that it was pivoting over to learning about Ruby on Rails, actually. My first job was working in an enterprise setting, working on Java. It was just, you know, a lot of work. I kind of was wondering, like, what are companies doing these days.

And this was several years ago now, but yeah, it was just a breath of fresh air to kind of see Ruby on Rails and to start working with it. And I worked a lot after hours on it and it actually is what kind of led me into my next job, which was in an agency setting, working with lots of startups to build their ideas for them… it was really cool. That’s kind of what got me to what I’m currently doing now.

‍

When you initially made that switch, what was the breath of fresh air? Was it the community, the productivity, the tools? What kind of like hit you as like, “This is what I want to be doing”?

That I could understand it, mostly. I felt like I needed to architect things in a certain way because there was the right way to do things, and the wrong way to do things. But with Rails, it just made a little bit more sense. So I was able to come up with those ideas on my own and validate them with what I was reading.

‍

So like less cognitive load when it came to like doing things the right way?

Yeah, for sure.

‍

“Convention over configuration” is a powerful idea. I’m a Pythonista myself, so you know, I think there are multiple ways to skin that cat. That’s a very good one.

Yeah.

‍

So a popular topic, at least out in the Twitterverse right now is how much work is too much, work/life balance, work/life harmony. You’ve got Elon Musk as an example of somebody who’s like, “You’ve got to work 100 hours a week, or what are you even doing? You’re basically killing the planet.”

Right. [Laughs] Yeah.

I think there’s a lot of value probably to really putting in those types of hours. Like perhaps there’s some things that you absolutely need to do that with, I’m not really sure. I haven’t found that to be the case at least with my stuff.

First of all, I think it’s kind of dangerous to only be talking about those people, because those are the sexy stories about how you’re changing the world.

‍

We’re not all trying to go to the moon. That’s not everyone. Some of us are building ad tech.

With your team, how have you been able to strike that balance between [on the one hand] you’re a startup, you’ve got deadlines, you’ve got a limited a runway… versus what’s a more sustainable schedule?

We’ve been pretty intentional with making sure people are able to bite off kind of the right amount of work. We’re going to get things done as a group. We’re not really going to be as productive as individuals pulling all nighters working on stuff; it’s been really important to keep our eye on that target and just make sure that we’re all in sync.

It’s a lot more realistic to stay in sync if you’re working reasonable hours together.

‍

And you’re fully remote? Mostly remote?

I’m really the only person on my team that is remote. Everyone else is local.

As we’ve been growing, it’s become more difficult for me to stay in the loop on what’s going on but we’ve still been able to do that. I think, yeah, they benefit from sitting next to each other and being able to chit chat all the time. But we use Slack, we use Google hangouts, we use all sorts of tools to sort of stay in the loop. And I really lean on that a lot.

‍

When you’re in the office, colleagues have, what are some of the best things they’ve done to keep you in the loop?

Really just keeping conversations online. I think we all kind of I think tend to do that because there’s a lot of fun that you can have in a chat room, right?

So yeah, I’d say that’s the biggest thing is keeping the communication online as much as possible. Also being willing to jump on a video quick and make sure that the audio is usable, make sure that the room is not too noisy that they’re in. All those things go a long way and are super important I think.

‍

And do you have a tooling, any tools that have made that easier for y’all when it comes to video chat?

We haven’t really figured it out yet. I found as long as you’re in a quiet room, the MacBook has a great mic, great video, great audio in general. But if you’re in a noisy room, all bets are off.

‍

Yeah. I’ve found the same thing. What went into the decision to hire most of the rest of the team in the office when you’re remote? Can you kind of talk us through what were the trade offs you were discussing there?

I think that a lot of it is the fact that the product team as a smaller team of a bigger company. We have a lot of salespeople, we have a lot more corporate people that are doing marketing and billing and accounting and all those things. So, all of them are really Minneapolis based.

Really, the product team started out with me being remote because I happen to live in LA and I already had a relationship with the founders. So, that’s kind of why we started with that. And we’ve just sort of grown the team locally because a lot of our network is local. I’m actually from Minneapolis, as well, so a lot of my network is over there as well.

‍

So, referral based hiring and that kind of …

Yeah. And it’s kind of happened to be this way. I think, you know, a lot of people at the company are more comfortable with just having everyone in the same office and having that be the kind of culture. But on the product team we’ve really been trying to push for more remote friendly environment. And I think it’s working pretty well. I think there’s always room for improvement with it, especially when it’s really hard for people in the office to understand what it’s like to be remote every day. So, they’re doing a really good job of that I guess for the most part.

We also are flexible with people working from home even though they’re in Minneapolis. So it’s a good level set to just kind of keep everyone on the same page.

‍

So that when they’ve done well, it’s because they’re keeping the conversations in chat, so they’re visible to you and they’re working from home so they’re kind of feeling that same remote pain?

Yup, exactly. And it’s kind of funny… there are times when they’re like, oh, I got to work from home today because I’ve actually got to get things done. There is that too. [Laughs] It’s distracting being in the office sometimes.

So it’s a good thing that we are forced to be remote with me being remote because it keeps those gears greased and it keeps that possibility open.

‍

You have a team structure where you have an engineering manager that’s kind of a people manager and you’re the product architect. How has that relationship evolved and what is easy and difficult about that structure?

So in the early days, I was the only one on the team and I wore all those hats; I basically just had to manage myself. And then we got to a point where we hired a couple of more people and I kind of stayed in this more lead position.

But we have plans to grow quite a bit, hiring several more people in the next year. And we wanted to bring in someone that could focus on that team growth side while I focus on building out the product to where it needs for the business to grow. So, really, the division of responsibility between us is, he’s focused on the career stuff for all the people on the team. He’s focused on kind of just making sure that people are able to devote the time and energy that they need to. He’s also doing a lot of interviewing… He’s having the meetings with other leadership to kind of figure out company priorities.

Meanwhile, I’m working on all the things that I have always been working on. I’m working directly with the rest of the team to figure out what it is that we’re building, how we’re going to build it, how it’s going to be rolled out, kind of, yeah, all those things. So, it’s been pretty rewarding for me to be able to stay in that role. I think there was a bit of a part of me that wanted to be this leader of the department or whatever… but it’s actually a lot different type of work than I really even wanted to do.

I think it’s been really nice to be able to bring someone else in that is really good at that, so that I can be really good at the things that I’m focusing on and also just kind of keep moving forward.

It’s also been really nice to have someone else kind of steer me in a way to make sure that I’m scaling myself. Like I have a tendency to, as probably a lot of engineers do, want to solve problems on my own. I like to really dig in and chew on things and figure them out. But he’s really pushing a lot of our organization around keeping tasks written down so that we can triage them and work on them in the most efficient and planful way. So, it’s helped a lot with really setting things up for us to be able to support a bigger team.

‍

What are some changes you’ve made in that regard recently as far as writing things down and keeping tasks clear in a more scalable way?

So we started using Jira a couple months ago. It’s a bit more heavyweight and it’s more complex than what we were doing before. Before we were just using Asana. It’s helped in a lot of ways because we can have a more custom lay of the land with how we organize our tasks – we just weren’t able to get what we needed out of Asana.

‍

So you found Jira to give you more visibility into what you need to see?

Yeah. It gives us more visibility at the cost of adding some headaches along the way. But I think for us, it’s worked out well so far.

‍

I’d imagine the relationship between [you and your business leadership partner] is pretty important for your team. How do the two of you stay in sync?

We’re working with each other on a daily basis on all sorts of things, but we do have a recurring one-on-one meeting every week where we can really set time aside to have conversations about what direction we want to take things. I’d say the most important part is just keeping each other in the loop on kind of what’s going on.

‍

And do you typically do that in Slack? Do you set up a dailies? Are you jumping in Google hangouts, video chats every day? How do you really keep that line of communication open?

Mostly it’s Slack, but once we cross that threshold of just a few, a minute or so, or maybe even 30 seconds of back and forth rapid fire, then we’ll pretty quickly pivot over to a video call where we can just really actually talk.

‍

That’s a great heuristic: if you’re typing for a minute back and forth, probably a video chat is a better way to get there.

Yeah. There’s times when we’re working on several things and we’re chatting on the side. But yeah, for the most part, we’re going to be able to figure things out better if we just jump on a call.

‍

I heard you listen to a lot of podcasts, a lot of software engineering podcasts. So one of the challenges I ran into when I listened to Software Engineering Daily is there’s a lot of Facebook content and Google content, and we’re an eight person team so a lot of that stuff doesn’t apply. How do you listen to those in a way that you can bring back tidbits that are helpful for your stage?

Some of [the podcast episodes I listen to] are on things that are 100% not our problem; not something that I should even be considering for what we do on a day to day basis. And other episodes are really helpful. It’s just a wide variety.

But I think the interesting thing for me is just staying in the loop about what companies are doing, and what products are out there to help make our lives easier. There was also a really interesting segment recently on Facebook: [they] interviewed several people from all different parts of the organization and they just talked about how that company works. I found that super interesting.

‍

Did you learn anything that you’ve been able to take back to Dispatch and your team?

I don’t think I’ve really taken things back quite yet with it, but one thing that I thought was really interesting and that I’ve been chewing on for a while, is how obsessive they are about just getting things working and shipping things early. Apparently their code base is a mess in a lot of ways, and it’s really hard to comprehend and keep track of. But they also have sort of embraced that and are just really prioritizing getting things done and making the product work well. So I think that’s really interesting.

A lot of times like in my world, I dig into details a little bit too much rather than really shipping things. But I think it’s just something to keep in mind. Like it’s possible to do things without really architecting the heck out of something.

‍

Yeah, yeah. Technical debt is, like zero technical debt is probably the wrong amount of technical debt for a startup. I’m not sure what the right amount of this, but zero seems wrong.

And like, you know, honestly, we’ve got some technical debt for sure. And now I’m in a place where I want to write things in a different way than I wrote them six months ago. Knowing that it’s not a good idea to just like reinvent the wheel every six months is a good thing – it’s good to see companies like Facebook really like living by that. [It reminds] me that I should restrain myself from rewriting the whole app.

‍

Stripe, one of Stripe’s engineers, Will Larson, writes about system migrations being maybe the most important skill in an organization because if you don’t do those well enough, you will eventually do a big rewrite because your stuff will get so bad.

Yeah, that’s really interesting: figuring out how to change the oil while the car’s driving down the road. If you can get used to making those changes on the fly and doing it in a safe way and just kind of making that a part of your rhythm and your regular cadence, then I think can potentially avoid these bigger huge rewrites. So I think that’s really smart.

‍

Bootstrap is the CSS framework that everyone uses as far as I can tell. You’ve been investigating the Tailwind CSS framework. What do you find compelling about Tailwind?

Yeah. I really am intrigued by it. For anyone that’s not familiar with it, it’s a utility-based CSS framework. So that means that you’ve got, rather than creating a class that’s like-

‍

“Bootstrap dash button, [etc.]”…

Yes, “alert panel” or something like that.

You have like all these smaller scoped utility classes like “text red” and “background” and “BG red”… stuff like that. So the thing that frustrated me the most with CSS is just coming up with what are those components, what are the names of those components. How often am I going to reuse them? And then there’s the whole aspect of every new thing that you’re going to build, you’re going to be creating a file for it; you’re going to be creating the CSS file, you’re going to be editing the html, you’re going to be doing some other stuff in JavaScript. If you can co-locate a lot of that stuff or not have to deal with so many files, it’s probably going to make your life a little bit easier.

As far as naming things goes, it just really takes me out of my flow when I’m trying to come up with how to name “alert panel V2 bold important”. If I can just not have to do that, then that’s going to be a big win.

‍

Was it only two hard problems in computer science? Cash invalidation, naming things and off by one errors.

[Laughs] There you go. Yeah.

‍

So you’ve recently built out your team, so that means lots of interviewing. In those interviews and in your interview process, how do you determine technical prowess and who’s going to be capable of doing the work?

We’re still kind of trying to figure that out, and… it depends on the role and on the person you’re interviewing. But the two main pieces I think are important are first, having a conversation about it. And then second, is looking at real code, talking about real code.

I just want to be able to talk about how people do their job on a daily basis – what’s important to them, what tools they use, things like that. And I really like to try to bring out information about what it is that they know about, and how they approach their day to day work.

I also tell them a lot about what we do and how our system works. So they can get a feel for that. But my main goal here is to really gauge, like I said before, whether they are familiar with the topic and whether they really know what they’re talking about.

‍

What are some ways that whenever you’re both looking at code, you can ask a question that’s going to get to that? Do they know what they’re talking about to the level that you need for the position you have available right now?

Yeah. It’s probably a little bit different if you’re looking at code versus if you’re just talking. In the first phase of the interview, it’s mostly just talking. And a lot of times I’ll kind of fall over to those, “tell me about a time when…” questions or “tell me about a system that you’ve built that you are proud of” or “tell me about a system that you built that you want to rewrite”… that type of thing.

Once you’re actually looking at real code, then that all changes a bit because you might be reviewing code that they wrote from a take home exercise or you might be asking them to review some code that is already a part of our system. And in both of those ways, my main goal is to really figure out whether they A, again, know what they’re talking about. And B, whether they really have good ideas that either align or challenge my ideas on what makes a good system.

So again, it’s trying to figure out like their level of comfort with understanding these things and talking about them and trying to gauge whether they’re going to be a good member of the team.

‍

Can you remember a time where you’ve been having that conversation and a candidate challenged your ideas?

In interviewing some front end folks, a common topic of conversation is CSS and JavaScript; whether JavaScript should just be a sort of like the add-on thing that just sprinkles in all of the functionality, or whether you should be writing a single page app. And I really like to find someone that has an informed opinion about that and is able to talk about both sides.

In some of those interviews, people have challenged my tendency to want JavaScript to just live on the surface. So, I think [I’ve been convinced that] there’s a lot of benefits to taking more JavaScript-first approach, but there are some big trade offs with that. So, the most memorable interview where we’ve talked about that is kind of on that topic.

‍

So they came in and pushed back against your, “JavaScript is just the action layer” [stance] and they were like, “Nope, you can do much more than that.” And there were trade offs it kind of sounds like?

Yeah. There’s always trade offs but there’s definitely big trade offs to doing things that way. They just made some good points… it’s a complicated topic.

‍

It is. So Peter, whenever you’re looking at a cover letter, what are you looking for? What really can make a cover letter stand out?

For one, I’d like to just understand whether they know about our company and kind of what we’re doing. I also want to understand what they have been up to and what excites them. I think those are really the two main topics to really think about.

But like on a broader level, I’m also interested to see if people are good communicators when they’re writing. That’s such an important part of being on a team and not just writing code, but really like explaining your thoughts to people and really understanding, and also being able to articulate complex ideas. We can’t really just talk about things all the time on a whim… I think it’s a lot more helpful to be able to sit down and work on some thought, put it into writing, make it solid, and then present it to a group. So yeah, writing skills are hugely important.

‍

So a great cover letter shows that they know your company, they’ve done the research. It shows that they’re excited about something and communicates complex ideas concisely.

Yeah, for sure.

‍

Yeah, that’s a great cover letter. How many of those do you see? If you had to put a number on it, what percentage?

Not many. Although we’re also not asking for them. I was kind of inspired by this, by reading a little bit about how Basecamp approaches their hiring, and they talked about the importance of writing. So, I’m going to steal that idea and I just think it’s a really good one.

‍

I think especially if you have remote hiring. Hiring advice is always conceptual, that’s a hard part and it usually doesn’t come with context when you hear the advice.

Like stuff that works for Google would be just disastrous for most companies because they don’t have two million, they get about two million candidates a year. I don’t get two million candidates a year.

Neither do I, thank God.

‍

Basecamp, they don’t get two million but they probably get a lot more than me, and a lot of people that are at least more excited about Basecamp specifically than they would be excited about our startups.

Right. Yeah, and I don’t expect everyone to know all the details and be like really obsessed about our company and excited about it. It’s just nice to know that they’ve put in the effort to really think about what it is that we do and really think about like how they can contribute uniquely to our team.

‍

It doesn’t actually take that long and it goes a long way.

Yeah, and actually when I’ve done, when I’ve interviewed in the past and done that, like it really helps frame my mind around that idea. Rather than just having a resume with a bunch of bullet points.

‍

So we’re going to move into our rapid fire round. I’m going to ask a series of questions and we’ve got 60 seconds… we’re going to try and get through as many as we can. These are on hiring and getting hired.

What does a six star culture fit look like at Dispatch?

Someone that’s able to really resonate the culture and get other people to rally around it.

‍

What advice do you have for an engineer that’s looking to get hired on your team?

Write a cover letter.

‍

What makes your team uniquely great to work with?

I’d say our flexibility and our ownership of stuff.

‍

What’s the biggest mistake you’ve ever seen a candidate make in an interview that maybe they didn’t realize that they were making?

Sharing the wrong screen.

‍

Yeah, that can get you into trouble.

On the other side, could you walk me through the interview that’s had the most lasting positive impact of your impression of a candidate?

When people are really honest about their needs for their work environment. Like if they have specific needs to work from home on certain days of the week and they’re just like really forthright about that.

‍

If I was applying for a position that you have open today, what can I do to stand out?

Again, I’d say write a cover letter. I just really like to understand where people are coming from and what is unique about them.

‍

My guest today has been Peter Cullen. Peter, thank you for being on Scaling Software Teams.

Yeah, thanks. This was fun.

 

Thanks again to Peter for sharing his experience with us. Here are a few takeaways I had from our chat.

‍

Number one, we need to keep the wheels greased for remote communication. That’s our job as leaders. As teams grow, especially when teams are not fully co-located or fully remote, I call this hybrid remote, things get hard. It’s easy for the in-office team to forget about the remote folks. Our job is to model the behavior, keeping as much communication online and in public as possible. And when it comes to nuance, basically, anytime you see back and forth chatting for more than 60 seconds or so, it’s time to hop on a video chat and then we can paste the results in the Slack, the summary of our conversation.

‍

Number two, it might make sense to hire someone else to run the people side of our engineering organization. This is a pattern I’m seeing more and more. The basic idea is that you have an engineering manager that can oversee 15 people, effectively two teams. And then you have tech leads who are responsible for smaller scope within a team but they’re not doing one-on-ones. It allows the engineering manager to focus on career growth trajectory, salary bands, interviewing, hiring, spreading information around with other stakeholders.

This is something that I’ve seen. I know that Pendo does to great success. It allows you to split the two jobs that are often hard to find someone that gets energy from both, someone that gets energy from being deep in the code, talking architecture, and also gets energy from doing one-on-one and career planning. Peter has taken this route and he’s found it to be very rewarding to stay in the role that he’s most energized by.

‍

Number three, there can be value in cover letters if we know what to look for. This advice I think is mostly for job seekers the next time we’re on the job market. A common pattern is hiring managers look at cover letters and they’re looking to see candidates that did the research. Did they reference anything specific about the company? Are they excited about anything, something, really? And are they a good communicator? So can you explain a complex idea succinctly? If we’re writing cover letters, we should use that framework. Research, excitement and communication.

‍

Thanks again to Peter for coming on the show. Now, I want to hear from you. Please leave us a review on iTunes, Google Play, or wherever you get your podcasts. This will help others find our community. Until next week, keep on scaling.

 

‍

‍