#291 Mark Herschberg from ballroom dancing to managing information flow
Resources
Highlights
The tech industry is an ever-evolving landscape that requires more than just technical prowess. Mark Herschberg's journey from a physics enthusiast to a seasoned Chief Technology Officer (CTO) is a testament to the diverse skill set needed for leadership in the technology sector. In this latest podcast episode, Mark shares his insights on mastering the art of tech leadership, emphasizing the importance of capabilities that extend beyond engineering.
Mark's own career trajectory began with a strong foundation in computer science and physics at MIT, but it was his early recognition of the need for a broader skill set that set him apart. He understood that leadership, networking, and effective communication are indispensable in the tech world, and he discusses how these skills are not reserved for those at the top but are beneficial for everyone in the industry. His narrative reveals how an early interest in politics and a penchant for diverse interests have contributed to a well-rounded career in technology.
A pivotal moment in Mark's career came with his transition from the trenches of coding to the strategic horizons of management during the tech boom of 1999. He likens this shift to outgrowing childhood Lego structures in search of more enriching challenges. Mark candidly shares his experiences leading teams and shaping business strategies, highlighting the crucial role of adapting communication styles to foster robust team dynamics, especially in remote work environments.
The episode delves deep into the innovative strides made by MIT's skills training program, a collaboration where Mark played a pivotal role. He illuminates how the combination of industry experience and academic rigor prepares professionals for success. The narrative sheds light on the interplay between evolving educational methods and the real-world demands of the tech industry, from classroom to boardroom.
Listeners are taken on a journey through the intricacies of tech leadership, where Mark provides anecdotes and lessons learned from the front lines. The episode also explores the importance of understanding the bigger picture of company-wide goals and the significance of individual roles within those objectives.
As we navigate through the episode, Mark's reflections on the challenges of moving from coding to management reveal a candid perspective on the realities of the tech industry. He touches on the necessity of recognizing the human element in software projects and the sociological factors that often dictate the success of such endeavors.
The episode concludes with a detailed exploration of the role-playing methodologies employed by MIT's skills training program and the continuous effort to adapt teaching techniques to maximize student development. This comprehensive look at the journey of professional efficacy from the classroom to the boardroom encapsulates the full spectrum of skills required for a successful career in technology.
Enjoyed the Podcast?
If you did, make sure to subscribe and share it with your friends!Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.
Become a supporter of the show. Head over to Patreon or on Buzzsprout.
Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.
Thank you for tuning in!
Transcript
⚠ The following transcript was automatically generated. ❤ Help us out, Submit a pull-request to correct potential mistakes
Mark Herschberg: 0:00
I wanted to become a CTO and I recognized it wasn't just about being the best engineer. It wasn't that I could code better or faster than others. There were all these other skills I would need Leadership, networking, negotiating, communication, hiring, team building. But no one ever taught them to me, so I began to work to upskill myself. We didn't have great podcasts like this back then. It was a lot harder and as I did, I realized these skills will help everyone. They are not just for leaders, not just for managers. Everyone down to your summer interns can benefit from these skills. So I began to upskill my team.
Tim Bourguignon: 0:39
Hello and welcome to Developers Journey, the podcast bringing you the making of stories of successful software developers to help you on your upcoming journey. I'm your host, Tim Boulgigno. On this episode, I receive Marc Hirschberg. Marc has launched and developed new ventures at startups, Fortune 500 and Academia. He's the author of the book the Career Toolkit Essential Skills for Success that no One Told you, and helped to start the undergraduate practice opportunities program, dubbed MIT's Career Success Accelerator, where he still teaches annually Formerly, a top ranked ballroom dancer and among many other activities. He also works with many nonprofits, currently serving on the board of the Plant A Million Corals Foundation. Marc, a warm welcome to everyone.
Mark Herschberg: 1:33
Well, thank you for having me. It is my pleasure to be here.
Tim Bourguignon: 1:36
Oh, and it's our pleasure to have you here. But before we come to your story, I want to thank the terrific listeners who support the show. Every month, you are keeping the DevJourney light up. If you would like to join this fine crew and help me spend more time on finding phenomenal guests than editing audio tracks, please go to our website, devjourneyinfo and click on the Support Me on Patreon button. Even the smallest contributions are giant steps toward a sustainable DevJourney journey. Thank you, and now back to today's guest. So, marc, as you know, the show exists to help the listeners understand what your story looked like and imagine how to shape their own future. So, as is usual on the show, let's go back to your beginnings. Where would you place the start of your DevJourney?
Mark Herschberg: 2:29
The start of my development journey probably began at the end of eighth grade. I was going into high school. I already knew that I wanted to study physics in college and go into politics. So when we're trying to decide what elective for me to take, I'm sitting with my guidance counselor and I'm looking and saying well, I want to take justice. Justice, that sounds like law. That seems very appropriate for where I wanted to go. And my guidance counselor looked at me and said oh yeah, we're not offering that. Next year, pick something else. I was caught off guard. I didn't have a bad. What do you mean? The class was listed in the catalog. I didn't know what to do and my guidance counselor, who didn't really provide much value other than this one critical moment, said why don't I sign you up for computer programming one? I didn't really want to do that, but I had no other options. I thought, well, I'll come up with something. Maybe over the summer I can switch. I'll find something else. But never saw anything else I wanted, and so I showed up to the class. Now I had done a little. I had a programming book. I think a few years prior I did some things in basic. But we did this class and they're teaching us basic, more advanced stuff and I'm loving it. I would get a programming assignment and I would go home and right away do the assignment. We had a computer at home this was in the 80s and I'd code it up and say wait, I'm done, I want to do more, I can't wait for an extra assignment. So that really got me excited. And when I went off to MIT I decided to double major in physics and in computer science. And even though I also minored in political science, still thinking I wanted to go into politics, I very quickly got turned off from politics. So I didn't go further down that path. And then as I graduated the 90s, physics was, funding was declining, it was the end of the Cold War, but software was really taking off. This is now the mid 90s, and so that put me on that path.
Tim Bourguignon: 4:27
Did you look back at any any time at the beginning of this CS 101 classes saying, well, but I still want to go there. I was really love at first sight and you never looked back.
Mark Herschberg: 4:39
It was both because I do love computer science, Even though I was not the best of students freshman year at MIT and definitely got beat up a bit by some of the classes but then at the same time I love the other stuff. I am so glad I studied physics. I wish I had more time to do physics. So it was love at first sight, but I have a harem of interests and I tried to spend as much time as I can with each of them.
Tim Bourguignon: 5:08
So how did you choose your path, first at MIT, into going into this, this computer science major, and then doubling major in physics? How did you decide which path to take? I suppose MIT, mit's offering is absolutely humongous and really huge and you can go anywhere. How did you find your path in there?
Mark Herschberg: 5:27
Well, going in I knew I wanted all three of those areas. I knew I wanted physics. I knew I wanted CS and I knew I was interested in politics. I didn't think I could fit a third major in, but I was able to get that as a minor and through some clever planning that actually laid the foundation for some of what I now teach, I was able to fit all three of those into my time at MIT.
Tim Bourguignon: 5:51
Wow, is that normal to have two majors and a minor in undergrad?
Mark Herschberg: 5:57
It was not very common back then. Normally you'd have a major, maybe a major and a minor. Double majors were pretty rare. I believe these days it's become a lot more common for people to dual major or do a major with multiple minors. So it's become the trend and in fact, one thing we saw at MIT and I suspect is true at other schools we would have students that'll past maybe 10, 20 years would study computer science but also biology because they were interested in biotech, and MIT would see these trends and then would create these special subdivisions within, for example, in computer science. You can now subspecialize in biotech, you're still getting a CS degree or EECS, but with a biotech focus, and so they were recognizing this Interesting. Call it maybe not an overlap so much as a conjunction, and when I really think about where opportunity lies, this was true in the 90s. I think it's still true today. It's not necessarily within a discipline, but when you go cross discipline, usually that's much more virgin territory and leads to a lot more opportunity.
Tim Bourguignon: 7:09
Much more conjunctions or synergies than adding to think that I have nothing to do with one another and falling into a crack. It's really adding up in the middle. There's something new that emerges and where there's way less, let's say, offering in terms of demand and offering, there's way less people that have the skills to really strive in there, and so you can have your niche there. Well, very cool. What did you have in mind for the mark that was coming out of his MIT degree as double major and minor? What did you picture your first and second and third jobs would be?
Mark Herschberg: 7:50
Once I recognized I wasn't going to go into physics, I said, okay, I'm doing computer science. I thought I'd be a software engineer. Well, I first spent a year doing research at MIT for a professor. I do like academia, I do like pure research. But then I just said, okay, I'll be a computer programmer. And I found a job. At this time I didn't have a lot of direction. I knew I didn't want to work for big tech, and back then big tech was Microsoft and IBM. Modern big tech mostly didn't exist. I knew I didn't want to work for Wall Street. I knew I didn't want to go into consulting. Those were three big industries that pulled from MIT and I wound up at this tiny company. They called it a startup. I hadn't heard that term before. I said, okay, fine, small tech company, let me do this. And I was very lucky that I had a really good manager and some really good peers from whom I learned a lot, because I thought, well, I've got a degree from MIT, I know a lot, I'm a smart guy, and I didn't know how much. I didn't know. But it was during that time they started to grow and I had a very pivotal moment a couple years into that job. My CTO called me into his office one day and said listen, this might come as a surprise to you or maybe not, but I'm leaving the company and I'm going to start my own. I'm taking some people with me and you should come too. Now, this was a surprise to me. It should not have been, because I noticed a lot more closed door meetings with the senior team, not just there once a week meeting. There is definitely something going on and I didn't have the mindfulness to think, hey, what's going on? I should figure out. Could this impact me? I just sat there and happily coded and when he offered me this new job, all of a sudden I had a choice, because I thought, well, I'm at this job, I'm happy, I like the people, I'm making good money I never even thought should I consider something else? So once he gave me this new job offer so well, now I have two choices. I need to figure out what is the right next step. So I have to prepare the jobs and then quickly start to think about my long term future. I was a competitive chess player as a kid, so I never think one move ahead, I think multiple moves ahead. It's not just this next job? What's this setting me up for? Five, 10, 20 years down the road, I realized I had more than two job offers, because this was a dot com era in Boston, so I'm not limited to just these two. Let me look around, and that's when I really started to be more proactive in my career. Where am I trying to go and how am I going to get there?
Tim Bourguignon: 10:30
I want to come back to that situation, or awareness, understanding what's happening around you, because I've seen that a couple times already, people who are so in their work, in the tasks that they were given, they don't realize first and foremost and I'm not thinking about about next steps and everything they don't realize how what they're creating fits in the big picture. They don't realize how the big picture is constructing around them and how sometimes people go around them to to get something and and and understand how they fit into this. And this is this has been one of the key areas I poke at during interviews is understanding. Did you get the whole picture? Did you get why you were there and why you were doing this and how it fit in the whole picture? And then that would, of course, as you said, fit as well in understanding what's happening around you. Is there a meeting you're not invited to where there seems to be something important happening? And maybe you should pay attention to that, and it really pays to becoming more senior to start understanding this understanding or the situation around you. I have no better word to put that.
Mark Herschberg: 11:41
It's funny you struggle with the words because this is all covered in chapter two of my book, titled working effect, and that's probably my least favorite title. I could not come up with a better title for that chapter because it encompasses all the things you're talking about. It's not your work itself, it's not writing code or if you're an accounting doing financial reports, it's all the other stuff. Now that includes corporate culture and corporate politics, which we get caught up in whether we want to be or not. It's understanding. How are you delivering value? Most people couldn't tell you who their customers are. They might have a list, but they couldn't say well, our customers tend to be mid-market industrial supply companies. They don't know who their customers' customers are. They don't understand how to add value, and I always teach my students and in all the other work I do If you don't know how you're adding value, then it's harder to add more value, which is how you get ahead, how you get raises and promotions by delivering more value. But you're doing it without a map. So understand the business that you're in. Understand who are your customers. Now, it might be an internal customer, it might be the other groups. Adding this button helps the sales team. Okay, how does it help the sales team? It could be an external customer, but understand your customer's customer, how doing this creates value for them. To create value to their customers, understand your industry. When I do monthly meetings with my team, we'll go over, okay, what's happening and let's do some big picture updates. But I will make sure to talk about here's what's happening in other departments. People often bring in another department head the CFO, head of sales, cmo say can you come talk to my team? We're going to spend 20 minutes of this meeting. You give updates from your department. Help them understand what's happening. But even if your manager doesn't do this, here's something that kills me. Most people cannot name the coworkers around them. Oh, there's some woman. She sits 30 feet from me. I think she's in finance. I think her name is Sarah, but that's about all I know in finance. I guess I don't know. She does stuff with checks. They don't know. You're saying 30 feet from this person for a year. So go out, meet your coworkers, talk to them, meet them for coffee to say, hey, I'm trying to learn more about the different aspects of the company. Can we just grab coffee? Tell me about your job? What do you do here, you're going to learn so much and you will be much more effective because you have a better understanding of your role and how it fits into the business and your industry.
Tim Bourguignon: 14:26
And I'm cringing because I'm in a 100% remote company and so there's no really way to see this person 30 feet away from you. She is somewhere on Slack and you just don't see her. And so you have to be explicit about this. You have to be poking at different, different persons you don't know and say, hey, random person, I have never met you, let's talk.
Mark Herschberg: 14:49
I'm going to recommend. I rarely recommend third party tools, but I'm going to recommend two. There was a company called Donutai. I remember when they were pitching they were looking for angel funding. I saw the pitch. I liked the idea. I just didn't believe in the size of the market. It didn't seem defensible. And it's not because a friend of mine wrote a competitor called SUP. Sup, as in what's up, they are both plugins to Slack which, given the technical audience, I suspect most people are using Slack and what it does. It just creates these random pairings. So this week I'm going to get noticed that, hey, you and I are supposed to get together for coffee. It can be done in person, it can be done virtually, and it just says, Okay, you're gonna meet and mark, you take the initiative and I'll just Slack. You say, Okay, hey, we're supposed to meet, Let me know when you're free. And that's a good way to really just create some of that water cooler conversation that you don't always get when you're virtual.
Tim Bourguignon: 15:46
Absolutely, and smiling because we're using Donut. It's exactly this. It's really exactly creating those, those serendipitous, serendipitous meetings, just because you don't have the opportunity otherwise. That's very important. Okay, let's, let's go back to that CTO grabbing you and telling you hey, common born and shit. Did you say yes?
Mark Herschberg: 16:11
I looked at his company, I looked at my current company and, as I mentioned, I realized there were more than two options, because this was the end of this was 1999 in Boston, the end of the dot com error. We didn't know was the end of it, but there were so many opportunities and I realized where I wanted to go. I wanted to become a CTO, and it wasn't just about being a better developer. Both of these companies were going to continue me, primarily in my individual contributor skills. I'd be doing more coding and maybe more advanced coding, but I wanted to get more into project management and start working on other skills. So I looked for an opportunity that would take me down that path and that's where I went. Did you feel?
Tim Bourguignon: 16:54
ready for leaving IC behind you and going for something else?
Mark Herschberg: 17:01
It depends on when you're asking me that, because at the time I would have said yes. Today I would have said maybe. And what I mean is there's a famous expression in the land of the blind the one I'd man as king. I currently did not have more than one eye open, but that was one more than most of the other people, because at this time we were so desperate for coders If you just knew how to use a computer. I remember I had a. There was a recruiter who tried to pitch me a QA person, and I asked about her background. I said, well, she knows how to turn on and use a computer. Now, my standard was a little higher than that, but yeah, that was a level when he could pitch people, because in 1999, such demand and such a shortage that you could sell people that way. So, having even a few more years of experience, I had a lot more to offer. For the record, I was also a competitive ballroom dancer and I know a lot about the ballroom dancing world. If you go into a ballroom dance studio and you say, oh hi, we're here to take some classes or learn for a wedding, chances are, the person teaching you is not some world class champion. It's someone who may have only learned to dance six or 12 months before me and the other competitors. We could I and the other competitors we could run circles around this person, but this person was sufficiently ahead of the wedding couple that he was fine teaching them Absolutely. So really, you just need someone who's just a little bit better than you and you are adding value. So I think I still had a long way to go, but I was still. I had enough to add value at the time.
Tim Bourguignon: 18:47
Okay, I want to flip it around and and wrongly reformulate it, just to see how you react when you say back then yes, maybe now maybe I'm also hearing the naivety of the youth saying, yes, of course, I'm ready for that and now, in hindsight, thinking, well, actually wasn't, but it was sufficient.
Mark Herschberg: 19:11
I still didn't know all the things I didn't know. I remember, for example, I was talking with one of the founders and we're talking about the project we had. Most of our developers were either just to have college or some of them had dropped out to do a startup. And I remember we're talking about timelines and one of the founders said well, we're just going to ask them to give their estimates, because if they give an estimate then of course they have to hold themselves accountable towards it. I get like we as managers can't tell them what to do because we might not get it right. But if they say it, well, then they've got to complete it. And I remember thinking that doesn't sound right, like there's still some problems by couldn't articulate. Estimates are hard and even if you ask them to do it, it doesn't magically mean they can complete it by then, yet have the vocabulary, the mental models sufficiently fleshed out to articulate it. My gut was going in the right direction, but I still didn't have as much experience as I would have liked if I had hired me in that role.
Tim Bourguignon: 20:15
I hear you. I hear you. So how did that work out? Did you find a CTO position? Did you manage to get some experience on your belt and really step into this direction?
Mark Herschberg: 20:25
Well, in that job. Now we technically had a CTO who is the 22 year old college dropout co-founder, who to this day I don't know what exactly he did. I had the entire engineering team reporting to me. I then had I don't know if you'd call it foresight or not quite sure what term I said. You know, at a certain point I am realizing I might be not the best person for this. I think I'm doing a good job, but there must be better people, more experienced people, and if we bring in one of those, I could learn from him. We brought in a guy who had decades of experience at IBM and I watched him make a whole bunch of just dumb mistakes. He probably knew more about business than me. He knew a lot less about managing people than I did, and I looked back at the time and think I should not have brought this guy in because he did not know more than me and it became very frustrating watching him make some dumb decisions that he knew. You know, this is how big companies work and this is how I've done it for years, and it was very frustrating watching that, causing me to eventually leave. But after that I then started going into other senior positions, vp level positions and then CTO positions.
Tim Bourguignon: 21:43
And regretted any of that compared to staying in IC, I mean.
Mark Herschberg: 21:50
No, I think I went down the right path. I do miss some IC work. The analogy I always use is Legos, something that I suspect nearly every one of your audience has played with at some point. So ask yourself this question why did you stop playing with Legos? And if you need to pause the podcast, take a minute before you hear my answer. Think about why you may have stopped playing with Legos. The answer for myself and for many people is that it gets repetitive. I had built a number of spaceships. I fly them around the room and I take them apart. I build another spaceship, but spaceship 63 looks a lot like spaceships one to 62. And at a certain point you want different challenges. I like coding, but I was getting tired of okay and we're going to build another user system. Make sure users have these attributes on, don't forget the logging and build all this, and back then we didn't even have the libraries we have today. But still, if you think about your code, we know it's that 80-20 rule 20% is the core code and the 80% is the defensive coding around it, and that gets very repetitive. What I like about the people side of the business and that's managing people or the business strategy. It's always going to be different and every rule has an exception, so it's a harder set of problems. Just as I moved on from the Legos to a more complex type of play activity, I wanted to move on to a more complex set of challenges, because that's right for me. That's not right for everyone. So I'm glad I am where I am. I do wish I had X hours a week to keep coding. The bigger challenge it's not that I can't carve out the time, but it's that I can't always keep up with the latest software.
Tim Bourguignon: 23:40
I know that problem. I'm trying to cover Legos hidden behind me.
Mark Herschberg: 23:46
I have some as well on other shelves, but I don't spend a lot of time taking them apart and putting them back together to play with them. Many of us have on our shelves but we're not actually playing with them.
Tim Bourguignon: 23:55
You don't know what you're missing. Yeah, I totally agree. The people problem is really what attracted me at some point as well, saying, well, I did a lot of consultancy and saw the same patterns and say, ok, that's where we are on the journey. Ok, now we're going to have this problem, and now we're going to have that problem. Now we're going to start scaling and we're going to have that problem. And again and again and again, you see the same patterns and the same problem. On the technical side, at some point it becomes a bit dull and says, hey, let's see what's happening on the people side, and every case is different, and this podcast is an example as well. This is Joe 280, and no story has been twice the same. It's always different, there's always something different, and so throw a bunch of people in the same room and you have a synergy that you've never seen before and you have something that's completely unique again, and I love this puzzle. I really love this puzzle as well.
Mark Herschberg: 24:49
Before we start recording, you and I were talking and you mentioned the book the Mythical man Month, which is a fantastic book. Now, half of the book is gold, like the Mythical man Month, and if you haven't read it, you probably find the article online. The article that's the title of the book. Half of it is very dated. He talks about documentation by Grafiche. Just go, okay, that's. It's interesting from a historical perspective but very out of date. But another book I would put at that level is People Wear by Tom DeMarco and Timothy Lister, and the thesis of People Wear is that most software projects fail not due to technological reasons but sociological reasons. It's that we didn't communicate well. It's that we had too many changes during the thing. It's not that, oh, we needed more PhDs to get this done. It wasn't technically too complex, it was all the people issues that made it really hard. There's not a line of code in the book. It is still one of the best books on software or management in general that I've read.
Tim Bourguignon: 25:54
Indeed, indeed, and that's actually been the way I describe my job to non-technical people. It's basically well, throw 200 engineers in a room and make them work together, and I'm here to help. That Usually it's enough for people to say, oh, I see, and that's indeed a People Wear is fantastic. I really recommend it as well. And that's what we've seen recently with Conway's Law and Reverse Conway's Law, with books talking about one or the other meaning how do you design your software to influence the organizational structures and vice versa, how the organizational structures influence the way your software is built, and this is really a balance you have to keep, and both of them are going to influence the other, and if you veer too hard on one, then the other one is going to become a problem, and then vice versa. So really you cannot leave this out. This is so important.
Mark Herschberg: 26:52
I would actually very actively think about who is sitting where. Back when we were in physical offices five days a week, we'd move into new office. I think, how do I want to lay out this office, these teams? Because you have your organizational structure, but even just physically, who is near whom impacts your communication flow and what happens. And in fact, I encourage managers really, when you think about modern management, it is about managing information flow. It's about making sure the right people have the right conversations at the right time. If you can do that, then you're going to be an effective manager. Now that might happen because we have a weekly check-in meeting or after this happens you need to send an email to the team. But also happens because you put these people near each other whether they're physically near each other or their teams that have regular coordination meetings. You're going to enhance the chances of having those right conversations with the right people at the right time.
Tim Bourguignon: 27:56
And add the remote variable on top of that, that becomes an interesting puzzle.
Mark Herschberg: 28:02
Well, that's where you have to be more explicit, because we don't have that water cooler conversation. We're not both getting coffee at the same time. We can use tools like Donut to facilitate that. Or we can just be more explicit and just say we're going to have maybe more check-in meetings, or it's more important that you send this email when this happens to give an update. As long as we think about and manage that information flow, we can do it formally or informally. And when you think about a team that might be four people saying in a room together, you don't need a lot of formal meetings because the information flow is natural when you have 40 people. That's where we need the structure. Likewise, when we're even just four people, but in different time zones, we just need to add a little more structure to foster that communications.
Tim Bourguignon: 28:49
Mm-hmm, I like the way you're putting it. You're not advocating for more or not advocating for faster, but you're just saying adding structure, which really is dependent on the context. I, for instance, have a base camp in mind which we've heard a lot, and they really advocate for slower communication, more thoughtful communication, probably not answering like a chat, but really answering. Let's answer tomorrow with all the information and not on an article, but almost really with the thinking process, as if the person afterwards won't be able to reach me, to reach out and add some or ask some more question, and really will have only this article to work with. And this really brings a different way of working and for them that is the right thing. For a different company it would be a different set of constraints and maybe it would need some faster communication, but really have to find out what this chemistry for your organization is and really tell you that structure for what you need.
Mark Herschberg: 29:50
That's exactly right. When we think about processes and we can think about waterfall versus agile and agile is great in many cases there are also certain cases where you do want waterfall. I remember reading for the US Space Shuttle, which is now retired, it would take them six months to change a line of code. Any of our businesses would die. But you think about and say literally billions of dollars and lives at stake. I'm okay with them going really slow and being very careful in a very unforgiving environment, so that flow is right for them. And when you think about what these project management techniques are, they're really about the information flow, whether it's we can't move to the next stage until this one has had all the checks, or just we need to rapidly communicate information in a daily standup and then do quick changes to get quick feedback in a scrum. So really it's saying what is that information flow and flexibility that we need? Is it slow, steady, fully thought out, accurate information versus the other extreme, quick, dynamic information? And of course there's all sorts of in between and it's not just that one dimension.
Tim Bourguignon: 31:06
No, it is not, and that's what makes the work of organization crafting so hard. You have to understand the right levers and not pull them all at the same time, and understand how one maybe feeds into the other and you can get a reinforcing loop at some point and get too much of the goodness you wanted to have and break stuff. So this is a fun puzzle. I'd like to twist the discussion a little bit. So obviously, as a manager, or as a manager of manager, as somebody in the leadership of a company, you probably accompanied a lot of people and really did some mentoring I wouldn't say teaching, but mentoring and really guiding people. At what time did you decide to formalize this and go back to MIT and teach for real?
Mark Herschberg: 31:57
Pretty early on, so early in my career, I mentioned how I knew I wanted to get into more of the people side. I wanted to become a CTO and I recognized it wasn't just about being the best engineer. It wasn't that I could code better or faster than others. There were all these other skills I would need leadership, networking, negotiating, communication, hiring, team building, team building but no one ever taught them to me. So I began to work to upscale myself. We didn't have great podcasts like this back then. It was a lot harder and as I did, I realized these skills will help everyone. They are not just for leaders, not just for managers. Everyone, down to your summer interns can benefit from these skills. So I began to upscale my team and as I was doing that, mit had gotten similar feedback. Companies were saying these are the skills we want to see, not just in engineers, not just in college grads. Universally we look for these skills and they're very hard to find. So MIT was pointing together a program to address this. When I heard about it through my network, I said, okay, well, maybe MIT could use some of what I've built. I reached out to the person who was starting up this program. I said I've got some content, I'm happy to give it to you. I thought that would be it One and done, here you go, best of luck. But instead he said hold on, can you stay and maybe help us build a little more content? Okay, sure, spend some time, this could be fun. So we were building out some additional training and as we were doing it, what he told me years later is he recognized. I brought a different dimension. Now we have a number of amazing professors school of engineering, sloan, school of Management. These are literally the top people in the world, but they're very academic. They don't spend a lot of time in industry. They said you're bringing this industry perspective. That I think is unique. We should bring in more people like you to bring in that perspective. So we went out. We found a bunch of other folks and created this program that's co-taught. We have the professors, because we need to get academic credit and that requires professors, but then also practitioners like myself co-teaching the students. And this was 2001,. 2002 is what we heard. So I have been teaching there for decades and it was only the last few years where I said I know this is helpful to not just engineers, to everyone. How can we reach a larger audience? I was trying to push MIT to put this stuff online. For various reasons that didn't happen, so I thought I'd write up notes, and what I thought was going to be 10 or 20 pages of notes expanded and suddenly became a 270 page book.
Tim Bourguignon: 34:46
Which is great for you, I guess.
Mark Herschberg: 34:48
Hopefully helpful to the world, because that's my goal is trying to help more people develop these skills. I really want to see people maximize their professional efficacy Indeed indeed.
Tim Bourguignon: 35:00
Way better way to put it. How have you seen this program evolve in those 20 years?
Mark Herschberg: 35:09
It's. We've evolved, we've learned a lot about teaching these skills. It's very interesting because this is not first of all these skills. It's not how we learn programming or other skills when you think back to what you're learning. You learned history by having a professor say here are the important dates. You learn coding by okay, here's how memory works, here's computer architecture, here's one. If then statement does Right, then I say okay, I get, and then we just go and regurgitate the answer. But that's not how these skills work. These skills are more akin to learning sports. I can teach you the rules to a game in 30 minutes, but it's going to take you years to get good at. It requires drills and scrimmage games and coaching and reflection, and that's the approach that we take here. So we start off doing that. But even coaching if you ask, for example, a soccer coach or a football coach, what they're coaching was like year one versus year 10 of their career. Like I say, I've learned a lot more about how to be a coach and I think over the past few decades we learned a lot about how best to engage the students, what type of activities work. We've tweaked the activities to make them more likely to get the educational goals we're trying to achieve, and so we've done. I'd say the core still works, but we've definitely done a lot of tweaks along the way and we've added modules and taken modules out, based on a number of factors.
Tim Bourguignon: 36:41
Again, wrong reformulation. To be sure I understood what you described is it's basically tweaking the form but not really tweaking the content. It's saying, well, this form didn't really fit that context, or maybe we discovered a different way to bring it out, but the content remained the same over 20 years. Is it what you meant?
Mark Herschberg: 37:02
Yes and no. The content has changed in that we've said we're going to drop this module and that content and we're going to add a different module with different content, just because, if you think about the skills we're trying to teach these skills, you can do a semester-long class on just one skill, yeah, and we're trying to cram it all into a reduced program. So we're just giving them a little sample of each and just at times you might say let's do this, not that, but any given module whether this is a leadership module, this is a negotiation module how we structure it, the way we approach it, the actual exercise itself might change up based on our experience and feedback. For example, in certain activities we want students to fail. They do better, they learn better once they fail. There's another activity where we try to get a 50-50 split. These are a lot of role-playing activities and at the end we want half the students to make one choice and have to make the other. If they're all making one choice, whether it's right or wrong, it feels like, ok, we push them too much in that direction. When we get that 50-50 split, then we can have a real discussion before we tell them how this all plays out. Why did you think that way? Oh, I never thought about the point you're bringing up and that brings out a richer experience. So those are types of tweaks that we do.
Tim Bourguignon: 38:30
What is the target audience of this class? Is this really a freshman, 18 years old, coming just out of high school, or more, at the end of their undergraduate studies?
Mark Herschberg: 38:42
The class I've been teaching is for MIT sophomores. We have created sister programs that go into the junior and senior year for typically a smaller cohort of students. We hit a wide range of hundreds of students each year. Those then get down into the tens of students and now we're looking at expanding. I've been asking for years to expand to graduate students, which I think we're finally starting to do this academic year, 2023, 2024, possibly next year.
Tim Bourguignon: 39:13
Did you expect a difference in maturity and life experience and that this different, this life experience would affect the way people embrace the content or maybe react to the content?
Mark Herschberg: 39:28
I don't think life experience from a few years, from college versus college and grad school or sophomore to senior I don't think it impacts them that much. What I'm finding is a bigger causality of how people engage with this content. First it's just some natural inclination. We just see the bell curve of some students say I really want to learn this. Others show up and well, I hear you give free food so I'm doing it. A friend told me to do it. Some just like well, I guess I'm here and I'm getting credit, but they're not really engaged. And you just see people, their level of engagement, of interest and how well they take to it. Standard bell curve. I will say, having now taught for a few decades, I have definitely seen generational trends in how people approach this and their interest to certain things. So that's probably a bigger macro factor than just are you 19 versus 21 when you're doing this?
Tim Bourguignon: 40:31
OK, that could be an episode in itself, just talking about that bell curve and how it devolved over years. But unfortunately we're at the end of our time box and I want to go back to one of the things, or one key moment I think in the interview is when you describe leaving individual contribution and going into management. This hell, yeah, I'm ready for that. If you had an advice for people exactly at that stage of their career saying, well, I've seen those problems and I see again and again and again, I think I'm ready for the rest. How do I step into this direction? How do I really make the right moves to be on the right track into going there? Do you have an advice for them?
Mark Herschberg: 41:16
I mean you have two pieces of advice. The first is that you have to embrace these other skills, Because when you're an individual contributor, you start out, you solve a certain type of problem and when you do well, they say we're advancing you and now you solve a bigger version of that problem and yet an even bigger version, and you're typically doubling down on your technical skills. I'm using technical, not necessarily coding. Again, it could be marketing or finance, but it's that domain skill that you are using over and over. You're just wielding a bigger hammer To get to those higher levels. It's not about that domain skill, it's about all the other skills. It is about negotiating and hiring and team building and managing and leading. And the big challenge you have to rely more on those skills. And the big challenge is you've probably succeeded by just being bigger, better, faster, but now that you're a manager you can't do it and we see a lot of managers burn out from that hero. Ok, the team's flowing, I'm just going to jump in, I'm going to pull the all nighter, I'm going to get it done. And you might be able to do that in your first role or do it from time to time, but as you get more and more people. You can't just pick up more load. Your ability to complete, to achieve, to deliver value is no longer what you can carry in your hands. It's your ability to get the team to do that, and that's a very different type of challenge than what you've had before. So we've basically been rewarding you for a certain type of activity and all of a sudden we just change the rules of the game when you become a manager, and so that's where you often get tripped up and that's where you have to say it's no longer my technical skills, yes, you're going to need those, but all of a sudden these other skills really come into play a lot more.
Tim Bourguignon: 43:11
Amen to that. This is so important to realize and understand, otherwise, you're going for the wall directly. Mark, this has been a fantastic discussion. Thank you so much. It was really enjoyable.
Mark Herschberg: 43:23
Well, thanks again for having me on the show.
Tim Bourguignon: 43:25
It was my pleasure. Where could the listeners reach out and could use this question with you?
Mark Herschberg: 43:31
I'm going to give you two websites. The first is my book's website, thecareertoolkitbookcom, and there you can learn more about the book. You can follow me on social media. You can get in touch with me if you have questions. I put out new articles every week and I have a whole page of free resources. I have nothing to sell. Technically, you have to buy the book for if you want the book, but everything else it's free. I don't even care about getting your email because I'm not trying to sell you anything else. We have the career questions. You should be asking yourself Questions to ask during an interview to figure out is this the right company fit for you? We have questions to ask when you're hiring to make sure you're thinking the right way about hiring. We've got links to all sorts of other resources, again all free, and all of this at thecareertoolkitbookcom. The second website is because so often you read a book like mine, say this is great, but then you forget. Where do you read those networking tips? Sitting at home? Where do you need them Two months later at the conference? We want to put those tips in your pocket and again, it's all completely free. We created the BrainBump app, so if you go to brainbumpappcom. You can follow links to the app stores to download the free app. It has all the tips for my book. If you went through with a highlighter, this is what you would highlight. We don't even check that you bought the book. You get this all for free. But you also have tips from other books, career books, management books, sales books, tips from podcasts, tips from blogs, tips from other sources, with an ever-growing list. So you have them all right in your pocket and you can either pull it up as you need it as you're going into that conference, pull up those networking tips, or you can set for a daily reminder. If you're a new manager, 9 AM each day, just get one of those tips. You don't have to open the app, just pops up. You say, all right, I remember we're supposed to do this Great swipe, but that's going to help you remember it and have it in the forefront of your mind as you go through your day. So that's the BrainBump app, completely free. Brainbumpappcom.
Tim Bourguignon: 45:37
And if you didn't get that scroll down, it will be in the show notes. Just click on it. Goodness, I can promise you Anything else.
Mark Herschberg: 45:46
That's everything, Marc. Thank you so much.
Tim Bourguignon: 45:49
Thanks again, and this has been another episode of Dev. First Journey with each other next week Bye-bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share, rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on on our website devjourneyinfo. Subscribe. Talk to you soon.