Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about management lessons for founders. This episode is geared towards how to manage a team of people and discusses the two extremes of a highly involved micro-manager versus allowing people to work independently.
Items mentioned in this episode:
Transcript
Mike [00:00]: In this episode of ‘Startups for the Rest of Us,’ Rob and I are going to be talking about management lessons for founders. This is ‘Startups for the Rest of Us,’ episode 314.
Welcome to ‘Startups for the Rest of Us,’ the podcast that helps developers, designers and entrepreneurs be awesome at building, launching and growing software products whether you’ve built your first product or you’re just thinking about it. I’m Mike.
Rob [00:26]: And I’m Rob.
Mike [00:26]: We’re here to share experiences to help you avoid the same mistakes we’ve made. What’s going on this week Rob?
Rob [00:30]: Things are pretty good. Getting some positive feedback about episode 311 where I interviewed Derek about what it’s like selling a $128,000 side project. Did you hear that episode yet?
Mike [00:40]: I actually have not. It’s on my list. I haven’t gone to the gym in a couple of weeks, so.
Rob [00:45]: Totally. Now everyone knows that we don’t preplan these intros. That was a genuine so, you know, you have to circle back and let me know if you liked it. But I’ve gotten several emails and I think there’s a comment on the post itself of people who just really liked the inside look of what that was like.
Mike [00:58]: I’ll read the transcript. How’s that?
Rob [01:01]: Yeah, do that. That’s how you always approach it. Cool. And the other thing is MicroConf tickets are on sale which has been kind of fun. And this year – you know, for folks who follow the podcasts – we have two MicroConfs now in Vegas. And they’re back to back in early April. And we went with a starter addition and a growth addition because what we found is that it was hard to build a conference that catered to both ends of these spectrums, right. Of someone looking for an idea, vetting an idea; trying to get to launch; trying to get to fulltime revenue. For everyone to be able to live off it.
And that’s where starter addition basically ends. It’s all the stuff that you do in the early stage. And then growth addition is for folks who are already living off of it and are looking to grow it. And it’s been pretty cool to see kind of the distribution of folks who’ve gone to growth versus starter. And to see a lot of people are going to both of them.
But there are still tickets available which was kind of the goal of doing this, right. We’ve typically sold out. By the time we launch to the public, we sell out in what, five minutes, three minutes. I mean it’s been kind of ridiculous the past few years and this gives a lot more folks the opportunity to come and learn from the speakers and, of course, the other attendees in the hallway tracks.
So, if you’re interested go to MicroConf.com and by the time this airs you’ll either be able to still signup for the list or, perhaps, even just click right through and buy a ticket.
How about you? What’s going on?
Mike [02:11]: Well, I’m planning on casting an early vote for the election tomorrow. But I hate myself already, so, I don’t know. It’s kind of a mixed bag I guess.
Rob [02:20]: You know like; can you take a shower?
Mike [02:21]: Yeah, I don’t know. I almost wish that I could vote for nobody for the next four years and just be done with it. But whatever.
Rob [02:27]: Yeah. So I actually purchased a shirt and it’s got Cthulhu on it. And it’s says ‘Cthulhu 2016, why vote for a lesser evil.’ And so I think that should be our write in.
Mike [02:37]: I think that there’s other ones that have been out there like ‘Pedro for President.’ So –
Rob [02:40]: Right. I also have another one that’s ‘Underwood Underwood 2016.’
Mike [02:43]: Yes. I like that one too.
Rob [02:46]: Cool. What else? What’s going on with BlueTick?
Mike [02:48]: Well, I’m currently mired in support tickets and bug fixes. But I also added two paying subscribers this past week. So, things are going well. It’s just a matter of kind of going through those and – the unfortunate thing is that when there are certain things that go wrong, they create more support tickets than the actual problems that are causing those things. So, sometimes there’s this cascade effect where one thing that goes wrong or needs to be fixed will create like four or five support tickets and they’re all related to the same thing. Which kind of sucks to have to go through each of those and try and figure out are they related or are they not.
But the issue we ran into was there was data that was being displayed incorrectly and come to find out we had to go back through and regenerate some of the data because it just didn’t exist at one point. So we were tracking some information and we didn’t start tracking that information until several months in. And we got to a certain point where we’re showing all these statistics and things like that. And there’s some things that are included and then there’s historical data which doesn’t exist because it wasn’t included until then. So all the numbers looked off. We had to go back through and figure out, “Okay, well, is our logic wrong? Yes, actually logic is fine but this data is actually missing.” So we had to go through and regenerate all that data.
And then when doing that, it caused some other things because we’d fixed the data and then we had to modify how it was displayed but they were out of sync. It was just kind of a nightmare. But we’re at the tail end of that at the moment. I’m onboarding somebody else new tomorrow. I don’t know.
Things are looking up. Things are going in the right direction. It’s just still a lot of work to be done.
Rob [04:12]: Yeah, there always is, isn’t there? But you made it through and you’ve added a couple of new customers, which I think is probably the important takeaway from all of that.
Mike [04:19]: Yeah. So that’s a good feeling to see that I can talk to somebody about the product and walk them through it. And, actually, one of them was sight unseen. They just said, “Yeah, this sounds like it solves my problem. I’m in.”
So, yeah, it’s going well so far, I think.
Rob [04:31]: Cool. One other thing I wanted to mention is I was interviewed on Mixergy again. I was trying to think, this might be my – I think including the time I was on – you know, he did like his 1,000th episode and there was like Seth Godin and Tim Ferriss and a handful of people. And he invited me on for that. I think including that this is my sixth time of going on Mixergy.
So it was fun to talk to Andrew. I had just seen him a week or two ago. I’d converted to then see him again and be able to do it. So, it’s about the Drip acquisition, in essence. About growing and selling Drip. So, if you want to check it out, it’s on the front page of Mixergy as of now. So it’s still freely available.
And, if you do head there, I’d appreciate – there’s like a ‘Like’ button in the upper left. I’d appreciate if you’d click that because it kind of increases my cred in the whole Mixergy ecosystem.
So what are we talking about today?
Mike [05:13]: Well, today we’re going to be talking a little bit about some management lessons for founders. And we’ve had some previous discussions about this dating back all the way to episode 68 where we talked about how to hire and manage virtual assistants. But then we’ve also talked in episode 116 about how to move a team from good to great. And then seven tips for being a better manager in episode 129. And then in episode 193, we talked about distributed team collaboration for startups.
But one thing we’ve never really discussed directly was how to generally manage teams of people. And I think there are two different extremes that you could end up falling between when you’re managing people. One of them is the highly involved micromanager who wants to be involved in all the intimate details of everything. And then there’s the other extreme where the manager doesn’t want to do any sort of management tasks, or the founder doesn’t want to do any of those management tasks and they expect everyone to work completely independently of one another. And, obviously, when you trend towards either of those two extremes, you start running into friction where either people are not doing the right things or their work is overlapping so you end up with all those inefficiencies that kind of come out among those conflicts.
And I think that one of the goals of management is really to move the business in the right direction. And, per Joel Spolsky’s advice a long time ago, he said that the job of management is to essentially get the furniture out of the way so that people can do their jobs. And I think that that’s great in theory if all you do is manage people. But I really think that that starts to fall apart when you need to switch between a work mode and manager mode because, in the early days of your business, you’re still working on a lot of things. And then there are times when you need to manage people and you need to manage either the project or the future road map or working with customers or the support team. So you need to kind of alternate between these different management tasks.
And then at the end of all that, you still need to go back and be productive on the things that you’re doing. Whether that’s coding or marketing or what-have-you. What are the other things that you are regularly working on?
So, when you get into that situation where you have to alternate, I think that it becomes very difficult to follow that mantra of just moving the furniture out of the way for people. And I think that there’s some guidance that we can kind of shed some light on for people to help make them better managers.
Rob [07:15]: Switching between maker-mode and manager-mode, which is what you were just talking about there – very, very difficult. And it’s actually not something I recommend. I’ve found that trying to be productive as a maker, as a creator, whether that’s writing code or putting out blog content, writing, talks, that kind of stuff that really takes the deep glucose – first is interacting with people, being willing and able to be interrupted so that you can keep other people going. Trying to merge those two is extremely difficult. And I’ve found that times in my life when I’ve done it – and I did it the City of Pasadena; I did it as a tech lead for a credit card company in LA; and then I did it kind of coming up into Drip. In fact, a big decision I made moving into Drip as we started and that I’ve never regretted was moving out of the maker-mode and out of the maker role, I should say. Because I didn’t write any code on Drip.
It was a tough decision for me because my identity for a long time has been caught up as a software developer, you know. That’s how I introduce myself to people. And to not write code for the past few years was an identity issue. As well as you kind of lose your technical chops. But with that said, it has been a lot easier for me just to feel calm on a day to day basis because I don’t feel like I need to produce as well as managed people.
Now something interesting is that I should probably reference back – because if you’re listening to this, you might be thinking, “Well, I never want to manage people,” right. “So this episode isn’t applicable to me.” But there was a blog post I wrote in September of 2010 and the title was ’10 things I will never have to do again.’ And I’m talking about being a Micropreneur and how I just didn’t like politics of big companies. And so now that I’m on my own and I’m never going to hire employees, I have 10 things and I said I will never again number one, read a book about leadership. Number two, worry about building a company culture. Number three, get someone’s buy in. Number four, participate in a performance review on either side of the table. And I go one to talk about other things. But it’s all implying that the beauty of being out on your own and doing stuff.
And at the time I thought that’s what I was going to do forever. And, as it turns out, that’s actually A: kind of lonely. B: kind of boring and C – you can do some big interesting things but you couldn’t do the big interesting things that I wanted to do without having people onboard.
So, that’s where I would say like at one point I thought I would never ever higher, manage, and build culture and do all that stuff. I think there’s value there. And even if you’re not going to hire employees, if you’re running a team of contractors – which, in essence, I wound up doing just a couple years after that. I think I had eight contractors working for me. All remote so I didn’t have to go into an office. And they were all hourly so I didn’t have the payroll and the W-2. But still there was – I did have to be a decent manager. And I had to learn how to do that. So that’s where this isn’t just for someone working at a big company going to manage this team of 10 fulltime employees. I think there’s a lot of lessons we can take away from this episode that apply to anyone who start a business even if you don’t plan to hire employees.
Mike [09:57]: So, I think before we even dive into the different lessons, I think the first thing to point out here is that, as you had mentioned, not everyone really wants to be a manager but people aren’t necessarily always good at it either. It’s very rare to find somebody who is just a good manager from day one. It’s essentially a learned skill. And I think that that is very important to keep in mind as you’re listening to this episode or you get into managing different people. So, you will get better at it over time but it does take practice and it can be uncomfortable when you’re first getting started.
So, let’s dive into the lessons. And the first lesson is that information is power, but having too much information can kill productivity. Really what I’m talking about here is over-communication. And I’ll be perfectly honest about this, I am brutally awful when it comes to this. My emails tend to be longwinded and I tend to try and consider or talk about different edge cases that I’ve kind of considered when I’m replying to emails. I’ve actually made this point to the people that I’ve talked to. Like, “Hey, look, if my emails are too long, just feel free to let me know that they’re getting too long and you don’t need as much information.”
And it’s important to know what your limitations are, what your shortcomings are when you’re dealing with people. You have to let them know how they can interact with you and how they can provide feedback to you; and what is okay; and what isn’t. And one of those things that I let people know is, “Hey, if my emails start to get too long or it’s inappropriate to continue that conversation in email because of that, just let me know and we’ll take it in some other mode of communication.”
But the real point of this is that you need to provide enough context about the tasks or the jobs that need to be done. But not so much detail that you’re getting in the way and your communication is getting in the way of what people are trying to accomplish.
Rob [11:35]: Yeah. I think as I’ve gotten better at this skill of managing, I’ve learned to be a lot more succinct and to try to filter in only give people the amount of information that they need because anything else is just noise. And they don’t need the whole back story of how we got here. They often don’t need nearly as much detail as you have in your head. And so I’ve found that this works both ways. In retrospect, when I was a developer reporting to managers, I remember telling them all the technical details of a decision and they really didn’t need to know that. A lot of times I should have just boiled it down to something that was just simpler to understand.
So, yeah, I think this is a really good learned skill in all walks of your life, like all aspects. Whether you’re talking to your kids, talking to your spouse, talking to a manager, talking to someone whom you’re managing. Just being able to sit and filter and to put something in terms that others understand and think about it from their perspective I think is something that all of us should focus on. I think, to be honest, the world would probably be a better place if we could all do this a little better.
Mike [12:31]: I think like that point about it does work both ways. So, when you’re talking to somebody who is higher up than you or you’re being managed by them, that filter should also be in place. That you’re distilling it down to just the important things that they need to know. And you’re right, I think that it comes down to making sure that you’re contextually aware of what sorts of things they are interested in or are important to them.
The second lesson here is when you’re managing a team, at least provide people with a high level idea of what the business objectives are, what plans you’re trying to execute. And that can really just be a simple one-page document that’s updated on a semi-regular basis that just indicates kind of what your key priorities for the business are. You need to let them know what’s important to you today and why it’s important and what the different objectives that you’re trying to reach are and kind of leave it at that. Let them interpret that information and apply it at the micro level to what it is that they’re doing. You don’t really want to be in that position of the micromanager where you are getting into their workday and saying, “Okay, when you do this task make sure you remember this. Remember that over there.”
If there are certain things that you’ve run into in the past that you know that they’re probably going to run into, then it’s appropriate to bring those things up. But you also don’t want to be overbearing or over-communicated all of the different pieces that will go into it because one: they’re going to figure it out and two: that’s what you’re paying them for.
So, you want to make sure that you are spending your time wisely and you’re not deluging them with all this irrelevant stuff that, quite frankly, may not even be relevant to the problem.
Rob [13:57]: What’s nice about giving folks a high level overview is that then if there are small decisions day-to-day, you don’t have to be the single point of contact. You don’t have to be the single bottleneck to make every little decision. The more context people have around it and the more context you build over time in their heads folks working for you can just make better decisions. You don’t want to dump it all once like we said in the first part. But over time giving folks a broader business objective rather than having people just be focused on exactly what they do day-to-day so that they understand what role it plays in the business is a good thing to do. And in the past, if you’re in person – we used to do it with a weekly lunch at the Drip office where we’d all get together and just sit around the table and share what we were up to and where we were headed. And people would share what they were working on and then I would talk about kind of where I thought we were going next. I would often lay out, “Here’s what I think the next 30 days are. Here’s what I think the next 90 days are.” And that’s about as far out as we would go.
But I think if you’re remote, this could probably be accomplished – I don’t know if it could be accomplished with IDoneThis.com, which is kind of an email thing that lets everybody know what everybody’s working on. Or if you might need a 30-minute weekly video all hands where everybody’s on there and you just chat through some stuff. You don’t want to do an hour video all hands. Like it’s just too painful and people are going to think it’s a waste of time. But being in person I think is ideal to do this. But I also think that it’s possible to still keep people apprised of what’s going on.
And you have to think, high level plans and business objectives they change frequently, especially in the early days of a startup. I mean they might change every week or two until things start to iron themselves out and you start to get a more repeatable development and marketing approach.
Mike [15:29]: One of the things that you just pointed out was kind of a key difference between an in-person team where everybody is in the same office versus a distributed team where people may very well be in different time zones when they’re trying to communicate. So typically in those two situations, you have the synchronous communication for the in-office people. And then you have asynchronous for people that are around the world. And that’s generally how the business itself operates. I would think that a video call or something that is probably going to be very constraining for those distributed or remote teams. And what you’ll probably want to tend towards is like a summary email or just a document that you can keep updated.
I think the document tends to fall apart just because it’s not in front of people. If it’s sitting in somebody’s email box they’re probably going to read it. But if it’s like Google Doc that gets updated on occasion, even if you send them a link to it, they may not necessarily read it. You really kind of need to imbed that text in someplace where it’s going to be right in front of them so they are, I’ll say, encouraged to read it as opposed to, “Oh, I got this link. I could go click on that but I’ve got all these 30 other emails in here that I’m going to go deal with at this point.”
So I think that you do have to keep in mind whether or not your team is in person or not when you’re deciding how to communicate effectively across the entire team.
The next lesson has to do more with how do you communicate with individuals on the team. And I think when you’re working with individuals you have to set those short term goals and objectives for them. Obviously, you let everybody know what the long term objectives for the business and for the company are but, with individuals, each person tends to be working on different things. And maybe you group a couple of people together when you’re putting together these short term goals. But you need to know what it is that they’re supposed to be doing and they need to know what it is that you expect them to be doing during a short term timeframe. And that could be a week, it could be two weeks, it could be four weeks. But you don’t want to go for extended periods of time without some sort of communication feedback.
So, really the matter at hand here is how you communicate with them to get information to them that they need and you know that they’re working on these certain priorities and how they return information to you to give you status updates to let them know what’s going on. I’ve had managers in the past who’ve had me send out weekly emails to them with three different sets of information. The first one is what did you accomplish this week. What is on deck for next week? And then the third set was what are any outstanding issues or upcoming issues that you can foresee happening that you may need help with or that I may need to be aware of.
And I think that that works generally pretty well. Other systems – I think you’d mentioned IDoneThis. I’ve also used Status Hero in the past for individual updates which you can use either for daily or weekly updates. It depends on how many people you have on your team and the frequency of communication that you need. If you have a lot of people who are working for you, you’d mentioned that you had eight contractors working for you. I would imagine that eight daily updates emails telling me what people are working on would just be too much. It’s just too much communication overhead so, I’d probably lean towards weekly at that point.
But you really have to dial it up or tone it down depending on what your team looks like; how many there are; people fulltime versus only working once or twice a week. All those things factor into it but really it’s a matter of establishing the communication back and forth between you and the individuals.
Rob [18:39]: Yeah and this is where I’m going to go off on my rant about remote teams versus all being at the same location. I believe that a hybrid approach is the best, to be honest. I’ve tried working with completely remote teams; I’ve tried working five days in an office. And neither one is ideal if you’re working especially with developers. I think if you’re doing marketing and sales and you need a lot of communication, customer success, that kind of stuff. I do think being in the office three, four, five days a week is perhaps kind of more conducive to moving forward. But I think as developers, designers and more of the makers who need their quiet time and the maker time, I think that a half and half approach is the best that I’ve ever experienced. And, again, I’ve done the entire gamut of completely remote, completely in the office and then these mixes. And what we’ve found with Drip when I was left to my own devices to figure out what to make work, we essentially arrived at I was in the office about two and a half days a week. The developers were in two days a week. And some the other folks with customer success were doing calls, some of them were in five days a week, four days a week. It was up to them. Really nice to all be in the office Tuesday and Thursday and we would do a lunch on one day and that was the perfect time to get this kind of stuff done to talk about short term goals and objectives and to get everybody else on the same page.
And then if we needed to talk day-to-day, there were often these little short hallway conversations that could even be five minutes of, “What are you up to today? Do you need any guidance? Do you need any help?” Boom, it’s done. So, again, this can all be accomplished with IDoneThis or with daily stand-ups via phone. I know people do all that stuff but to me it all plays second fiddle to sitting and being in a room with a person.
With that said, in terms of providing people with short term goals and objectives, I think it depends on who you’re managing here. If you’re managing developers, then it’s typically going to be features or bug fixes or here’s the next thing we’re doing. If you’re working with sales, customer success marketing, then it’s like here’s kind of a growth sprint or the next growth thing we want to talk about doing. And they’ll go off and do it. And if it’s customer success, it’s probably like we’re finding processes, how to touch base with people more often or do a better job of that.
There’s just things that you need to be thinking about as a high level. And this is where being a manager, if you are really managing all these facets of it, it can make your brain spin. It’s sitting there every day and not being able to focus on anything works for some people and it doesn’t for others.
Mike [20:46]: The third lesson is to set expectations for how people should work with you and what their expectations of you as a manager are. And you want to do this as early as you possibly can and the reason for doing it early is so that you can identify what the deficiencies in that method of working for you is so that you can get those things corrected. If you don’t correct those things early, what can happen is that you end up in a situation where you have these expectations of somebody but you haven’t really communicated them very effectively. So then you start to get resentful or angry that they’re not doing what you expect of them but you haven’t really told them what it is that you expect. So you have to establish those lines of communication very early and what those expectations are. Whether it is, “Hey, I expect that if you’re working on a daily basis you have to” – this is for developers – “you have to have at least one commit at the end of every single day.”
And if you start letting those things go, then that will not only eat away at the relationship that you have with that developer, but it will also start to undercut the credibility and the overall relationship because you can’ read their mind and they can’t read yours. So if you don’t tell them, how are they possibly going to know?
And if you don’t correct those early it will tend to create a cycle that is very detrimental later on. You can get around these things by having some weekly updates where you start discussing those things. Maybe set aside some specific time when you meet up with people during one-on-ones whether that’s a weekly basis or monthly basis or even a quarterly basis. But if issues start to arise you need to address them early.
Rob [22:19]: This is where hiring people who you think you can work with and who you think can work with you is a big deal. You can’t just hire anyone and expect their work style to match yours or their work style to match your management style or your interaction style. We were extremely slow at hiring at Drip because we were just waiting for the right people. We didn’t want to get people on who would disturb the culture even though we were small. We were two people and then we were four and then we were six and eight. But we really hired people we felt could get along. And part of that was me thinking, “Do I want to interact with this person? When they’re frustrated, how are they going to be? When I’m frustrated, how are they going to react?” And kind of weighing that in your mind.
Something that I talk with folks during the interview process is, “Look, we’re a small team and as such, we’re pretty hands off. We try to hire really smart people and we try to give them really challenging tasks because that’s what we like to do and what keeps us interested. And then we’ll kind of touch base with you now and again, but if you think that you need daily check-ins or weekly check-ins in order to keep things going and you want monthly feedback and you want this kind of stuff, that’s not really how we work. That’s just not how we set up the culture. And I’m not saying that any of those are bad things, but it’s a different culture than what we built.” And I think there’s logic to that, right. There’s a reason that we did that. It’s because Derek and I are both software developers and we know that as a maker you want to get in, you want to do your stuff, you don’t want to be reporting to someone every day about everything you’re doing. You don’t necessarily want to break your maker time and have to have conversations and meetings are often the death of your maker time. And that is what we setup.
So as a result, we set expectations, not even after someone started with us, but we set it during the interview process. And tried to suss out do we think this person can work given our working style and our management style and basically the company culture that we wanted to build. And so, you have to think about that yourself as well. Like how is it that you want to work? And this isn’t an excuse to basically delegate stuff to people and then just walk away and expect it to get done right every time because that’s not how we work either. For the first few weeks, give advice to people and help them work through it and then offer feedback. And then they’d show it to us and we didn’t expect it to be right the first time so we’d iterate on it. But then over time, people just become more and more autonomous. Good people. They learn and they become more and more autonomous in their role. And so you just don’t have to touch base with them nearly as often. I think it’s figuring out what your style is and learning over time how to find other people who can work with that style.
Mike [24:38]: One of the things that I’ve found helpful, which is kind of the next lesson, is to establish the terminology around the feedback loops that you use with people. One thing that I recently did with the developer that’s working with me is that we kind of established some key words or phrases that are helpful for me to determine whether or not the updates that I’m getting from him are things that he needs me to pay attention to or if it’s just something like, “Hey, I just wanted to let you know.” Because there, in the past, had been some tendency for an update to come through and he’s like, “Oh, you know, this is a problem and here are all the different issues with it.” And I’d look at that and, without any real context because it’s just coming through slack, is that I look at that and say, “Oh, well, he’s got a problem and I know generally how to solve that or I know what some of the work arounds are given my history with the code base.” And I can go find some of the information for him.
But there was a lot of miscommunication there just because I didn’t realize the context of that because there wasn’t really anything there. It didn’t say, “I just wanted to let you know.” It was just, “Hey, there’s a problem with this and I think that this is probably how we need to do.” So what we did was to setup a couple of different key phrases where one of them is just more of, “This is an FYI.” So, obviously, you can just put little snippets of text in there. One of them is an FYI. Another one is, “When you get a chance” which means, “Hey, take a look at this, but I don’t need you to look at it right away.” And then there’s other ones that you can use like, “Hey, I need help with this,” which is kind of a, “I need help right now and it’s blocking my progress from me doing anything else.”
And I think that just little key phrases like that can really help, especially when you have a distributed team or when you’re not in an office. If things are coming through email or chat or text, any of those situations where you don’t get that voice intonation that goes along with it, those types of things can be helpful.
In addition, you can communicate time estimates with people very, very easily but you really just need to set up what those expectations are. And, honestly, all it takes is like a five-minute conversation. “Hey, if you tell me this, include this little information so that I know how important it is or if it can wait or if I need to drop everything that I’m doing and respond to it immediately.” Those things will help you and it will help them so that that way you’re both on the same page in terms of the communication.
Rob [26:40]: Yeah, and what I’ve found over the years is certain people prefer certain communication channels. And for a lot of more introverted folks, we’ve had support people who really prefer email and even with big announcements. We’ve had Andy who’s done support for us for – I’ve working with him five or six years now. When I told him about Drip being acquired by Leadpages, I emailed him which is crazy because that’s a big deal. And I wrote him a really long email but it’s because in the past we have done a couple of video calls over the years and he just said, “Yeah, this just isn’t my thing. I’d prefer just to do text.” And he’s really good over email. He had done all the email support for Drip since day one, he’d done all the email support for HitTail, he does it for the academy. He really works well and I know his style and when he said that he’d prefer to do email even with kind of big tricky things I will put them in email. Whereas other folks really prefer to see your face, they’d prefer to hear your voice, they’d prefer to be in person. You just kind of need to learn over time what they’re going to prefer.
When I was developing and when I was consulting, I always prefer text meaning email at the time when there wasn’t much else.
Mike [27:41]: You’re dating yourself here, man.
Rob [27:42]: I am. I am. But, yeah, I didn’t mean sending me an SMS. I meant sending me an email because it wouldn’t interrupt my flow, it was a synchronous and it was something that I could sit there and think about and mull over and then respond to. Rather than you’re put on the spot with this phone call and somebody springs something on you and you don’t know how to react and then it feels awkward and stuff. I have less of that these days now that I, I don’t know, I have more experience with it. But think about each individual on your team likes to be communicated with.
Mike [28:09]: And the last lesson on our list of ‘Management Lessons for Founders’ is to dedicate time to management. As you said early on in this episode, alternating back and forth between that maker-mode and management-mode is extremely difficult. It’s hard to do just outright but in addition it kills your productivity for anything that you’re trying to build or make. And all those interruptions, even if they’re just little things, even if it’s just a question of, “Hey, how do you think I should approach this?” If those things can be pushed to certain days of the week or certain blocks of time, then it will help you out tremendously in terms of your productivity. And the time that you dedicate to managing people does not need to be every day. You can intentionally revisit those management tasks maybe once every couple days or once a week depending on how big your team is and how much communication needs to be had between you and individuals. You can schedule that. And as long as people know that there is that dedicated time for you to communicate with them, they will put those things aside or they at least have the capability to. And you can redirect them if those communications start to come up in the middle of the day. And you have those scheduled calls or communications where you can level set those expectations. You can tell them, “Hey, this could have waited until such-and-such time. Or if this comes up in the future just do this instead.” What that does is it puts you in a position of being able to perform those management tasks without interfering with what they’re doing.
Rob [29:30]: Well, I think once a week is a good rhythm to at least be thinking about it and then you’re going to have to do stuff every day is the bottom line. It depends on your situation. If you’re doing this on the side and everybody’s remote, then maybe it doesn’t need to be once a day. But if you do have folks in an office you can be actively thinking on your drive in, “Who’s doing what? Does anybody need any help? Do I need to check in with people?” That was always kind of a mental thing for me on the drive in and then on the drive home to make a note, “All right, I’ve got to check with so-and-so tomorrow.” But then really, like I said, get maybe that weekly lunch in or the weekly – even if it’s a three-minute, five-minute check-in with people saying, “How are things going? Do you need anything? Everything going well?”
I, again, don’t like the 30-minute formalized or the one hour formalized conversations where you’re trying to figure out what’s going on them and feel like you just have to sit in a meeting. But to take a few minutes and even just ask a question, “How are things going?”, and it might take two or three minutes and you’ll hear some short things and you don’t feel like you have to sit in a conference room together. I always liked that approach.
And, again, I don’t know if that would scale to a huge team. You know, if you had 100 people at a company does that approach work? I don’t know. But I never really had the goal of doing that. And I think folks listening to this podcast, you’re probably thinking more about having a small, remote team perhaps one in an office. And I do think that this is a really good way to go about it.
And that brings up the point of like we often have only seen teams managed at large scale because a lot of us have worked for larger companies. Don’t think you have to do it that way when you only have four people because you don’t. You can have a different approach that’s perhaps more authentic to yourself and more authentic to the people around you because you can do things that don’t scale at this small stage. And you can just handle things as they come up rather than having a lot of formal processes. Then once you get bigger, you probably do need to switch that up and perhaps follow some of the more standard marketing wisdom that you might read in the books or read in the MBA programs because those are often talking about much larger organizations.
That’s our episode for today. If you have a question for us, call our voicemail at 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from ‘We’re Outta Control’ by MoOt used under creative comments. Subscribe to us in iTunes by searching for ‘startups’ and visit startupsfortherestofus.com for a full transcript of each episode.
Thanks for listening. We’ll see you next time.
Great insight & timely as I’m about to make our first 2 hires. I’ve been spoiled with the 1st employee being remote (after moving away), someone I knew already & needing little-to-no oversight while hitting milestones. Still fighting it a bit, but with growth it’s inevitable.
Useful information. It will be nice to know how both you learned the 10 things. Websites, books, podcast or just life experience.