#19 How to Develop Early Career Engineers (with John Hyland)

Episode 19 [SREpath Podcast]

Ash Patel talks with John Hyland who ran the Ignite Program at New Relic, which is dedicated to developing early career engineers.

John shares insights about driving better outcomes for the organization and the early career professionals who join them.

Episode Transcript

Ash Patel: Great to have you on, John. I am excited to learn about what you have been doing to help develop individual contributors at New Relic.

John Hyland: I'm thrilled to be here.

Ash Patel: You're not at New Relic anymore, but you were running the Ignite program there for almost five years. And that was related to developing individuals who are working at New Relic in various roles.

So can you describe that to me in a bit more detail?

John Hyland: It was a hiring and placement program for early career engineers specifically. They were usually coming into their first or very early first job as an engineer. They may have done other things in the past, but they wouldn't have been software engineers or SREs or anything like that before.

Once they were in the program, we would go through rotations with different teams. Anytime somebody's coming into engineering, when it's their first job, they don't necessarily know what kind of engineering they want to do. And that's not always true.

Sometimes they do. And especially I think the front end folks. If people want to do front end, they're like, I want to put pixels on screens. And they know that's what they want to do. We definitely saw some folks like that, and that's awesome. And that's usually what they end up doing, but a lot of the time they would just be like, well, I don't want to do front end or I don't know what I want to do.

I think I want to learn more about back end stuff. And even a few of the front end folks would end up doing something that was more back end. And so that could be SRE, it could be like streaming data processing. That's something we did a fair amount of there. We had folks who worked on our internal database teams.

And by internal database, I don't mean they were DBAs. I mean, they, we built the database there from scratch in Java. And so people worked on that team. We had people go into the security engineering. We had people do all kind of different things. And they got to try all the different types of engineering until we found the good match that they were like, Ooh, I'm really excited about doing this with this team.

And then we could place them on that team.

Ash Patel: Interesting. I would love to focus on specifically the people you had placed in DevOps, infrastructure and SRE. So we'll try and steer that in this conversation. You had been a New Relic for a while. Before that you had a lot of experience in various organizations.

New Relic is a company that's very well known in the SRE space. So would you say that they actually do what they preach in terms of they have a strong SRE practice internally?

John Hyland: We used to have folks from other companies come in, we would tell them how we do SRE, how do we do a lot of our DevOps. So New Relic absolutely, they were an observability company.

They absolutely used the product internally in all of its various ways. That was actually one of the cool things about working at New Relic is you got to use all the stuff.

I feel like the people who were there in those kind of positions really, really, really learned how to get the most out of that system, like doing all that custom events. That's something that didn't hear a lot about customers necessarily using, but we used it constantly. I was always using those or a lot of like custom attributes on events.

Not to mention all the different kinds of infrastructure and all the other kind of capabilities that came out a little later. But even just with the original things going to NRDB, you have the various event types and such.

Ash Patel: And I would say New Relic is kind of a pioneering observability company because I don't hear about it that much these days.

But it would be the first round of companies that you would really associate with that.

John Hyland: I would agree with that. I think they were a company that I knew of before I worked there. The only other one that I could think of from that time in the observability space was probably Five Rings, and I don't know if they even exist anymore.

But those are like, those are the only two. That I, I'm sure there were others, but those are the two that I was familiar with at the time. 2013, I think, is when I started that, so yeah, that was quite a ways back.

Ash Patel: That was a time when people didn't really know what observability really stood for, even the term observability didn't exist.

John Hyland: I don't think we called it that at the time, because like you said, that term didn't exist, yeah.

Ash Patel: How do you think that space evolved? So, at that time, you called it APM?

John Hyland: Yeah, APM, so Application Performance Monitoring, and then later we changed it to Real Time Performance Monitoring, because we were, we were monitoring a lot of different kind of stuff.

I think the R originally stood for Ruby, because that's the very, very, very first thing that we ever monitored, but it very quickly was doing job and all kinda other stuff too. Originally you were a lot more limited to what kind of information you could store in that product. Like we had: you install an agent and it collects what it collects and you could maybe put some extra stuff on there, but probably not much.

And the internal formats were relatively specific for how that data was represented. Later on, I think the big advancement, in my mind, and I might think this is the big advance, because it's one of the things I worked on, so I was very excited about it, but it was the NRDB, and that just is the new Relic database, and it was a time series of that database where you could put any arbitrary key value pairs into that database in the form of an event, so it had to have a timestamp, and then any other data you wanted.

And then the query functionality to and not just query, but also like the display, like, I want to see it as bar graphs. I want to see it as loading graphs. I want to see a big pie chart, you know, whatever or raw JSON, whatever was incredibly powerful and being able to put any information you want and then get it displayed any way you want was a huge step forward in my mind.

And when I say like any information... like any information. We were thinking of it in terms of the information that we used to store but it's much more versatile than that.

Ash Patel: It's changed a lot in the last few years, like I keep saying, that it's evolved so much in the last ten years or so, where it was very difficult to do things like this, but now engineers would say, hey, look here, just got a real time database. Yeah, we're ready to go.

We can see everything. So that's probably one of the things that observability companies are now really pushing that they have specialized databases. Do you think that's going to evolve further or it's pretty much reached its point where you got the data and you're good?

John Hyland: I mean, it's continuing to evolve.

We originally just had events. Now we have the whole MELTS acronym, metrics, events. Logs and traces, I believe. I said transactions, I can never remember, let's see, well now it's,

Ash Patel: there's also temple.

John Hyland: Oh, okay, I'm not sure. It's the, yeah, I should know. With that, it's, it's, it's, you know, you work under the hood and you don't necessarily read the materials always that go up.

But we use that MELT acronym. So we store more different kinds of stuff that are kind of annotated in different ways. And the other thing that's really, I think, in the last few years, been evolving significantly is moving towards OTEL, Open Telemetry. That's something that I've seen a lot of companies do, a lot of customers really want to move in that direction for good reason, I think.

That's one I'm not sure how much I can speak to the internal decision making around it, but you can certainly see some of the things that New Relic has said about moving in that direction publicly. And a lot of other companies, of course, have embraced it pretty wholeheartedly.

It didn't exist at all back in the day, right? There was no such standard. It wasn't an option. You had to roll it yourself from scratch. So the fact that now we're moving towards this interoperability where you can use any kind of tool and put it into any of these different products, I think is a real step forward for customers who want to monitor things, but also for the companies because companies can kind of choose What do they want to build?

Do they want to build an agent? Do they, they could do that. And they just admit, do they not want to build an agent? You can say, okay, use the standard OTel and send it to us or use somebody else's OTel and send that and we'll do all the display and the whatever.

Ash Patel: OpenTelemetry, I would say, is one of the most widely spoken projects on CNCF right now. I think it's actually the second most contributed to.

John Hyland: I didn't notice. That doesn't surprise me though.

Ash Patel: I know we could talk about observability all day here but you had a very specialized role and I really wanted to just understand what your thoughts were on the space because it is an SRE podcast and people are curious about observability and you worked at one of the pioneering companies in observability for pretty much the entirety of this space from its birth to now.

Let's go on to what you were specializing in toward the latter part of your time at New Relic. Sure. And that was bringing about the Ignite program. And like we mentioned earlier, it was about developing individual contributors.

John Hyland: Yes.

Ash Patel: Did you have any reference point in terms of other programs that were other companies that you really drew from. Were there any sources of inspiration for you in developing that program?

John Hyland: Absolutely. That was the very, very first thing that I did.

When I first started working on ignite, there's actually something called the ignite committee before ignite itself existed that it was just folks who agreed that it was a good idea. And it would be nice if this, this happened one day. And I didn't actually come up with the idea for Ignite.

That was Rebecca Campbell and Trey Zacharias and Erin Dietrich. The three of them really got it kicked off. Rebecca was a VP of engineering, Trey was in our talent acquisition and Erin Dietrich. I think her title at the time was director of corporate social responsibility or something to that effect, but they saw this need for early career hiring and training and placement because it's something that we weren't really doing well as a company, and I would say almost nobody in the industry does it particularly well, though that's changing.

You see more and more programs that are aimed at them. They got that committee started and then just approached folks who seemed like they might be interested, including me, and I was interested. And that eventually we were actually going to make it happen. It got funded we're like, okay, yes, let's do this.

And we needed to hire a manager and I applied, was fortunate enough to get the roles. And the very first thing that I did after switching into that role was I started looking at what are other people doing.

How do people approach hiring generally?

I've done a lot of interviewing, but I've never been in charge of the whole hiring process.

And specifically like what other companies are out there doing early career development type of programs. Not like pre hire. Like, I'm not talking about code schools. So, you know, we looked at those two, but that's a really different focus. Yeah. I wanted to know what are like, Engineering companies doing, to do this well. So we looked at what Google does. We looked at what Facebook does. We were fortunate enough that we knew some people who have been involved in those hiring processes and could speak a little bit to them. We looked at Twilio has a great program.

There was one Zapier. There was, there was several. And again, early on, one of the things that I thought are really valuable was Vivek Nair, who is, I don't know if he's still at Twilio, but he was at the time and ran that program there's he had like an open table down in San Francisco for folks who were doing apprenticeship programs or early career development or whatever.

Everyone called it something different at the time. They still kind of do and we all just went down there and got a room. It was back in like 2018, might have been 2019, but very early on in the Ignite timeline, and just talked about what we were doing, what worked well, you know, what approaches were other people taking, and it was really, really helpful, really valuable hearing from all the different folks, hearing what kind of challenges they saw.

They weren't the ones you expected like finding people is never the hard part. It's never, ever, ever the hard part.

There are so many folks who are looking to break into the space that the hard part is what do I do when I have 1600 applications in two weeks and I need to narrow it down.

Ash Patel: No I want to know why this was so important for you. Was there a personal motivation for you to want to develop early career engineers or early career professionals?

John Hyland: There was. I would say there were kind of a few different angles that all came together to make this really meaningful for me and something that I knew I had to do.

One is that I had just done a lot of mentoring. I had done a lot of coaching. I had been on teams that had hired early career engineers. I knew I loved working with them. I knew I loved teaching. I knew I also learned a lot every time that I did that. Every time I was helping somebody figure things out, got to see how it works.

Ash Patel: You were already a principal software engineer. So you are very high up in that.

John Hyland: Yeah. I've been an engineer engineer for like 20 years at that point, some kind of engineer. So yeah, I was very experienced, but you know, there's always more to learn. That's one of the things that's cool about technology.

And even if you go back to the basics, getting started, things have changed since you were there. You would have forgotten things and you definitely did not learn every single element of every single language the first time you went through it. So it was still really valuable for me professionally to do that sort of thing.

So that was one side.

And the other side I think is that, I identified that it was a real problem that we had with the company. Like it was something that, that as a company we weren't doing well, it was costing us. We were missing out on really amazing early career engineers. We would see somebody like, Oh, that person's awesome. We should hire them.

They're like, Oh, you know, they've got a degree or they came from the grad school or whatever. So they've, they've got some of the skills, but there's a lot of stuff you need to know about engineering that you don't learn in those places. And we're just not set up to teach it. So we would miss out on those people.

So that was the second side. But the one that really, for me was the biggest factor was that I've always wanted the work that I do to have a positive impact on the world. I want to make the world a better place.

I think there's a couple of ways that you can do that. One way is to help people directly.

And that would be like the way that a doctor or a social worker does. I have enormous respect for those people. They're amazing. They change people's lives in huge ways. But only as many as they can get to personally, one on one. And then you look at the way that like a scientist or an engineer does it.

Maybe they build a bridge in an area. And so now, you know, that helps everyone around. Or they make every light bulb in the world a little bit more efficient. Forever. A relatively small individual impact. But a huge multiplier. Like the multiplier on that kind of work is enormous.

So the ripples go out across potentially every human that uses light bulbs, which is large. That's always been the kind of work that I've gravitated towards. Early in my career, I did a lot of stuff on like networking, like internet backbone stuff. I've always worked on like internal tooling cause I'm like, I'm going to help the other people around me do their jobs better.

And you know, then they'll build things that are better for other places. That's why I wanted to work with New Relic. What I think that they do, if you really, really boil it down is they make online systems work better. And there are more and more online systems running more and more of the world.

Every day. So making all of those better is a huge, huge multiplier. Moving into Ignite, running that program, we're just taking that one step farther. Again, I'm helping New Relic work better. I'm helping these engineers be better engineers so that the things that they build can have those ripple effects too.

And I kinda get to have it both ways because I'm also helping people individually, which is immensely satisfying being able to have an impact on an individual's life. And also get those enormous multipliers was very appealing to me. And it's something, it's probably, I would say the most important and also the most, you know, personally meaningful work that I've done in my entire life.

Ash Patel: Let's talk about the onboarding aspect of once you have hired someone as an early career professional, they have generally, a very doe eyed view of the world and they are looking at various areas, they're focused on here, there, everywhere. How do you get them to eventually become a very focused Individual who is contributing to a team in very specific objectives.

How do you get them to that stage?

John Hyland: I think the best way to learn how to do something is by doing it. So we would have some, some initial onboarding. We have two week period, which is about as short as we could make it. We actually experimented with shorter periods, but we found that it needed to be about two weeks and we would go through a little sample onboarding project and that was something that was sort of custom built to build a little toy version of one of our products so that you could see, like, where are all the internal APIs and how does the instrumentation work?

And where do you find the documentation? And who can you ask for help with stuff? And how does this database that we use work and all that stuff? And we would also get people from other teams to come in and talk to them during that time so that they could start to meet the experts on these various technologies that we had, whether that was our internal APIs or the front end framework that we developed or any of that kind of stuff.

Because those social interactions are really important. Forming those connections with other people throughout the company is a huge part of being successful. It helps with collaboration and also just knowing that those friendly faces are out there. The experts are there and you can go ask them questions.

It really helps get people sort of acclimated and Included in the social network of the company and the productive network of the flow.

But that was as quick as we could make it. There's two weeks that we kind of flew through it. And after that we would go into real work for real teams doing stuff that they really wanted.

It was going to be things like adding. APIs.

We would go through and help the SRE teams with migrations or whatever.

We would do whatever it is that actual teams throughout the company were doing. And there were some different ways that we could approach that. It would really depend on the particular nature of that team, because they were all totally different, you know.

Security teams doing very different things from the SRE teams doing very different things from the front end. But we could sit down with them, just pair with them for two weeks. They were all two week rotations as well. So it could be like, whatever you're doing, we'll do it with you. That was one way.

And I actually really liked doing that when we could because it's a really great way to get to know exactly what that team does. And then you get to know all the people, they all get to know you. You can tell if it's gonna be a good fit, but we could also do a couple of different things. We might take kind of a bag of tickets, right?

Because every team that I've ever seen at every company I've ever worked has got a backlog of tickets, a mile long of stuff that they would love to have done, that they wish would be done, but it's never quite the very top priority. And so it just never happens. So we would look at that. We'd go through it.

It would be like, okay, so what are the things in here where someone new to this code base? Or the system could contribute, you know, you don't need a whole ton of context to understand what you're asking for. And we, we cherry pick those out and put a, you know, JIRA filter or something on make a little swim lane. You know, however that team worked. Teams had a lot of autonomy in terms of process.

And then we would present those to the to the folks that come in, we do one all ticket all together, be like, here's the workflow on this team, here's how you check it out, here's how you submit a PR, all that. And then folks would grab tickets individually. They would still probably, we'd have like a point of contact with that team, and like daily check ins and things.

But they were working a little more autonomously, or in pairs with each other, or in pairs with me. That was a big part of my role, was to be kind of the local tech lead. I'd worked on a lot of different teams, so I had a pretty broad context for a lot of the work that was done. Though not all of it, like frontend is not really my thing.

So when we did frontend stuff, I was, had to lean a little bit more on the hosting team. And that's, that's fine. Nobody does everything.

So that was another way that we could work with the team. Or we could do something similar to that, but instead of just like a disparate bunch of just random tickets, we might have a project that we would all do together.

That might be something like, here's an old version of this, but we, as a team, have moved to this other language, like, you know, somebody wrote this in Node, but we don't really do Node anymore. Now we do Java, just as an example. So, let's get rid of the Node version and make the Java version of the same thing, but it should be identical functionally to that over there, but rebuild it from scratch in Java, just for example, or Ruby, or whatever, like we use a different language.

We would then spec it out. We would write all the tickets then and it would be a similar sort of workflow that we'd have a point of contact, daily check ins, and I'd be kind of acting tech lead for the group of them as they each took the tickets and worked on it over the course of those two weeks.

And the scoping was a little tricky on those sorts of things. You wanted to make sure that there was some kind of minimal level product that you could definitely get done in two weeks so that you're not going to leave it where it's, you don't have something valuable that you contributed, but it's hard to predict exactly how long something will take to the day.

Right? Especially when, you know, you would ever seen this code base before. They're not familiar with maybe the people coming in. So we would try to have like a lot of stretch goals here. So having elastic level of requirements there was really helpful.

That's what the like day to day process would tend to look like in terms of going from I just got here I don't know what I'm doing to Yeah, I'm ready to be on this team because you know after two weeks you work with those people. You've gotten to know them. You've been elbows deep in their product Whatever it is that they built for two weeks and you can really get a sense for what it might be like to be on that too.

At that point, at the end of each rotation, I would be chatting with the manager of the team. And also I had weekly check ins or weekly one on ones with each member of the team, as well as a group one that we call a retrospective every week.

And so I'd check in with some of those one on ones and be like, Hey, what do you think of this team? Was this, can you imagine yourself maybe being here? Nope. That's cool. No worries. There's plenty more teams out there, or maybe yes, maybe there's another team we should have. And if it seemed like there was a good match there, then like I mentioned before, we could go ahead and place that person on that team.

It took us a little while to get to the point where that ran smoothly. Like, initially, it was a much more, you know, here's the start date, here's the end date, on the end date, everyone will be placed. And, oh, we don't have any earmark positions for them, we're just gonna be like, pick one of the open positions and put them on one of those.

And we made that work, but I think it was very stressful for everybody involved. And we definitely missed out on some good opportunities where we could have placed someone on a team that would have been perfect. And you know, we found good matches for them still, but I think that things ran much more smoothly and much less stressfully for everybody involved.

Me, them, the managers, everybody once we had a little bit more leeway to place them where we found the good fits. But to make that work, we had to do more upfront planning. So I would go to leadership and say like, what are the teams where we might be interested in placing somebody? And those are the teams that we would schedule those rotations with so that we would have a very good chance.

That we would actually be able to put someone on that team if that match didn't come up.

Ash Patel: That's a good point, that you actually have to plan this out, even as someone who is on the technical side of the work, someone who is a technical lead, principal engineer, who is looking after multiple teams, looking across the organization, you have to look at a longer time horizon, because that's what the leadership is looking at, a year, two years, maybe even further out.

John Hyland: Yeah, that's exactly right. That's the kind of horizon that you need to be looking at for a program like this to make sense. And I think it makes an enormous amount of sense if you're looking at that three year horizon.

Even at a much closer, like if you're looking maybe a year out, you're still going to see positive contributions from the folks that come through a program like this and lay in all those teams. Not to be a crass capitalist about it, but they're also less expensive than senior engineers. You're paying them less as an associate engineer or, you know, or whatever you call it. And they're still making really valuable contributions.

Plus these are typically, honestly really high caliber folks. If you dial in that hiring process, if you get good at selecting people who are going to be successful, the really successful people aren't usually on the open job market very often at all.

When you're looking at senior lead, principal, whatever level folks, you're probably going to get them via networking or once in a blue moon, they will actually just cold apply. Everyone's on the job market for their first job. Everyone. So you can get the people of that caliber, if you know how to find them. You can get them, just that they're available at all I think is amazing. And the fact that you can get them at a, what would be a very reasonable rate for some of that skill is, is also, I think, very appealing.

There is a little more investment. You have to invest in this program. You have to invest in doing a little bit of onboarding in finding what's going to be the perfect fit for them so that, you know, they're not having to hop from job to job or something to figure out, Oh, it turns out what I actually love doing is being an SRE.

And I thought I wanted to write database internals, you know, or whatever. You've got to let them do that. But the payoff is enormous. And if you look at the, like three years down the line, payoff is huge. Now they're senior engineers and they're amazing. And it just gets better from there.

Ash Patel: Interesting you mentioned that because that's counter to what I hear from a lot of leadership. They say, I want to. That I want to poach that midway to senior person from that other company. I want to hire someone from the market who has five years experience in Kubernetes. How many people have five years experience in Kubernetes even now?

And some, very few, right? It's easier to actually develop. And what you're saying is, well, it requires a bit of patience. Three years is requires patience for people who are thinking in terms of quarters, but that investment early on in people, yeah. Who don't know about what you're seeking will pay off in as early as a year.

John Hyland: That's what I would say. I would say that's the horizon you really need to look at it.

We saw 97, greater than 97 percent retention rate over the five years that we ran the program. I mean, the people who came in there, they're now five years experience by the time by the time I left the company and they were amazing.

They have five years of experience with whatever it is that you do exactly the way that you do it.

Now, if you're a startup, if you don't know if you're going to exist in six months, this probably isn't the right program for you.

But if you're a company that has some faith in your own future and you believe that you're actually going to be around in a few years, I think looking at early career and looking to develop that talent rather than just poach it, you're going to have a much higher success rate than just finding amazing engineers at a senior level on the open market.

You're going to get a lot of those amazing engineers this way.

Ash Patel: And that would make a lot more sense as well as we're going to, well, we keep on going in and out of conversations about a recession and there's less scope for engineers who might be costing more. I don't know how HR does the costings for these in various organizations, but I know that if someone's a more of an expensive individual contributor, once they leave, there's generally no backfill now.

So if you're in that situation, you want to have a more cost effective way of developing someone who's not only developing their technical skills faster if you have a program like this, but also they're indoctrinated into your culture from day one. You cannot pay for that to a recruiter.

John Hyland: There's no way you'll find a senior engineer who knows your product as well as someone who's already worked there for three years as well.

And you're not going to have the same kind of retention rates. You're not going to have the same kind of diversity. You're not going to have a lot of the benefits that you can get by looking at early career.

Ash Patel: Exactly. Earlier, you mentioned that it's not just about having the early career professional integrated into the productive network.

There's also the social network that they need to get integrated into. How important do you think it is for them? I'm going back into when I was, it was a while back, an early career professional. I'm thinking for me at that time. It was so important to feel like I fitted in, and that I could even make work friends.

It's not as important now, as you gain experience, you've been around the track a few times. But at that point, it's so important to fit in, make friends, be part of that social network? How did you see that happening through the Ignite program?

John Hyland: Well, first of all, I just wanna say I completely agree with you.

I think it is incredibly important. And I think it's important throughout your career to feel like you're a sense of a community. It's not like, am I cut out for this in the same way that maybe it is when you're very early on, but it's still important to have those connections with the people that you work with.

There have even been a lot of research done in this area. So, if you look up, it's called weak social connections, and the weak there doesn't mean that it's not important, it just means, you know, these are not your best friends, necessarily, but they're acquaintances, work acquaintances, people that you work with, and like at least reasonably well.

And the impact that those weak social relationships have on productivity are actually really surprisingly large, so it makes a lot of difference, not just to individual happiness, though I do think that's important to but also from a company organizational level, it's makes a lot of sense to focus on that as an engineering leader.

In terms of how we approached that at Ignite, we did it in a variety of ways and it got a lot harder. I don't know if harder is the right word. The way that looked changed a lot with COVID. Previous to the pandemic, we were all in person and Portland, which is where I happen to be based, was the engineering hub for the company.

That was getting less and less true. We were moving kind of in a remote direction for a variety of reasons. But for Ignite upfront, we were like, you know what? I think it's going to be easier that we just do it all in person, at least as we're getting started. And when we did that, you know, we could, we could have coffee walks.

We would go have coffee with some team in the company every single week. And it usually wouldn't be a team that we were, because we were having lunch with them too. And we, you know, maybe sitting next to them all day long. So like you really would get to know them anyway. By expanding into meeting other teams, we could get a sense of what those parts of the company are like, even though we can't work with every single team, we had like over 70 at the time, if it's over a hundred now. And you could also just sort of develop an idea of like what's going on throughout the company. What are the various projects that are in flight right now?

What are people worried about right now? What are they excited about? Those were all really, really useful, but then, you know, with COVID we had to go all remote, all online, much quicker than we had originally intended. So we really stepped up that timeline. We'd always kind of planned to move in that direction, but we had to do it like now, and you have to be a lot more intentional about creating the opportunities for those social connections and creating the space for them to develop.

I actually think it's not all bad though. We got to do a lot more variety of things, not just up, we're going to go to the coffee shop every week, which was cool. I like coffee, but like now we're like, Oh, we're going to do an online game together. We're going to do like, we're going to solve these puzzles together.

We're going to do an escape room or we had cooking classes. We had a professional chef teach us all how to make a street tacos. Or any number of things, right? I have a little spreadsheet of options and I would share it with teams because you will be like, these are amazing. Can you, can you send these to me as I can just zoom with my team?

And I'm like, sure. And so I would send that over. And so I think the variety and the like level of interest that you could get in the things that you do is much better now than it used to be. Or at least much better than, than we went to the effort of making it at the time.

It won't just happen automatically, so you have to be more intentional about making it happen. So that's one thing that we did was like specifically social interactions, but it wasn't just that. We also had presentations from people throughout the company. They would come in and, you know, it would be something that we did, like Kubernetes or Docker or maybe GraphQL or elixir or whatever, anything.

And they would come in, and we'd get some expert to just talk with the team about it for an hour. Give a little presentation. It was kind of up to the presenter. Do you want to do slides and make it a very formal, like, I am teaching a lesson? Or do you want to just come and have a chat for an hour? Like, totally conversational. Either way is fine. Some people preferred one, some the other. They were all great.

We did record them and would share the recordings with anyone who wanted to watch them. But I still would take the time to have the people come and give the presentation in person as well.

Partially that's because, you know, things change. Internal systems evolve. Technologies, you know, move forward. And so, like, they would be outdated in a year or two anywhere. The more important side was that just like I was saying earlier about the onboarding, I think it was really important to meet those experts to be like, this is the GraphQL expert or one of them in this company.

And now you've had a conversation with them and they were really nice. And if you ever have a question about GraphQL or how does an air graph work, you can reach out and ask. Or if your team is working with that team, there's already a friendly face over there. It's going to just make that interaction run a lot more smoothly.

Plus you get to learn about graph QL. You get to actually develop your skills as an engineer. And the people who gave those presentations usually also really enjoyed it and really appreciated it. Like people like to teach, they like to help other people.

And so giving them the opportunity to come in and even not everybody does, but those people didn't volunteer. So the people who are like, yeah, sign me up for that. They're usually really excited, really happy to do it. And so like, I think it helps them. It helps the people and the program. And it helps the company as a whole to just run more smoothly and up level everybody's skills.

Ash Patel: And it reduces that us versus them mentality among teams, which you find in more traditional, like if you, if you looked at some memes of what Microsoft's culture used to be like, they all used to be pointing not so very nice things at each other. That would be not an ideal situation.

John Hyland: I think one of the most important things any organization can do is really instill a sense that we're all on the same side.

You know, we all want the product to be amazing and successful. We all want the customers to be thrilled. We all want to make a lot of money. We all want everything that that organization is doing to be done well. Everyone agrees with that. So, getting that collaborative rather than an adversarial mindset is incredibly important and really, really helpful.

And I think it's part of that whole weak social connections concept that was mentioned earlier.

Ash Patel: Absolutely. And it has to be the fact that people have to, if you have people meeting each other, then people realize, okay, even if there's conflict, and you cannot avoid conflict, I keep on telling managers, you cannot reduce conflict to zero.

You can try and minimize it, but it'll still find its way in. You just have to have it in a way that people, if they have to deal with that conflict, it's not with animosity. It's with pragmatism and with a sense of, I know what this person's about, so we can work on this.

John Hyland: It's fine for people to disagree. In fact, it's helpful for people to be able to disagree in productive ways because the first idea that anyone comes up with is probably not the best one. The odds that they just happen to get the best one right off the gate is very, very low.

The second or third idea probably isn't either. Any individual probably didn't come up with the best idea. It's got to be some combination of people being able to come together and be like, well, that's a good point. I hadn't considered, but what about this thing over here? What if we take this aspect and combine it with that?

Or like, this is almost perfect, but I didn't think of this thing. So let's tweak it in these ways or whatever. Having the kind of culture where you can have that back and forth and that evolution of a proposal is I think really important, which sounds like maybe what you're, what you're getting at there.

And the ability to do it in a respectful way that everybody comes away with feeling positive about how that interaction went is gonna keep everything working much better.

Ash Patel: We've had a great conversation. And just to wrap it up, let's talk about the fact that you already had organizational buy in in terms of you had a VP level person involved in the ignite committee. That is already a challenge for people in other organizations.

What do you think it took for them to really feel like, as a VP of engineering, for them to actually say, yes, this is actually something that's going to make our longer term view a lot easier to deal with.

John Hyland: Well, I want to say Rebecca is one of the best executives I've ever worked with. She is amazing. And she was one of the originators of the idea. So no one had to convince Rebecca. That said, this was an ongoing process and there was a lot of convincing that had to happen moving forward from there. Whether it was. Okay. This way that we're doing things, we need to adjust it. Like, like the way we did the financing of the headcount. Very different, you know, saying like, I get this many headcount, they're going to go on some team, but we don't know which one when you open that rec. That is not the way most headcount works.

That took a lot of buy in, not just from engineering leadership, but for finance, from the talent acquisition teams, from everybody involved.

To build that buy in, what it took is a lot of bridge building, a lot of forming those personal relationships and understanding where they're coming from, right?

It's not just like a, here's this thing. It's amazing. You need to support it. It's like a here's a goal that I think we could all agree is a really good goal. What do you think? Where are the obstacles that you see? Where are the opportunities? What are the things that I'm not thinking of that I should be adjusting about the way that I'm approaching?

Taking that kind of a mindset and reaching out beyond the areas that I'm comfortable with and familiar with like, I didn't know anything about how does headcount position work when I became manager of Ignite. I had to learn that and I had to learn it from the other people at the company.

I had to learn it from the people who are already experts in those areas. So you, you really have to approach it, I think, with some humility and an openness to adjusting your approach, but also with a very clear vision that you can communicate well of what is the ultimate goal. Like, what is the North Star you're driving towards that you want to achieve?

And the exact route? Okay, we can be flexible on that, but I think it's really important that we get to this place and you need to get everyone on board with you that that is a goal that you do want to pursue and understand what the payoffs are and what the competing priorities might be too.

I don't think there's a one size fits all answer there, but empathy, humility and doing your best to educate yourself and to understand where everyone else is coming from in the situation is the approach that I would generally recommend for many kinds of projects.

Ash Patel: That's great advice.

Just to wrap things up. I'm going to give you a challenging question of what you would advise someone who comes from a marginalized background, someone who doesn't have that access to higher education programs. They've come through on a boot camp and then they've got a job at an organization that is not as forward thinking as and didn't have forward thinking leadership like what you worked with.

What advice would you give them as an early career professional in the technology space in general to work on developing their abilities so that they can be the most that they can be?

John Hyland: Okay. I have a few answers to that. One is to develop your support network. Lean into the whisper network.

There's a lot of things that you're going to find out through back channels about the particular kind of challenges that you're going to face that somebody else might not know about. And that's going to be really hard to find out about on that kind of official channels. So that's one.

The other, and this is kind of a trap that I see a lot of early career folks, especially if they are changing careers, which is something you see a lot.

If there's something you used to do, especially if you like coming from like management role not necessarily engineering management, but any kind of planning, event planning, anything like that, where you're like really good at communication, or you're really good at organizing things, they will show up at their first engineering role, and it's their first engineering role.

Their engineering skills are at a this is my first job level. They're at an entry level, which is where you would expect them to be. Totally fair, totally reasonable. But their coordination skills or their communication skills are amazing! And so they show up on this team and they look around and they're like, What is the most valuable thing that I could do here?

And they see, wow, everyone's really struggling. With coordinating with this other team. They're really struggling with doing the planning for this. They're really struggling with writing documentation or whatever it might be. They're like, that's it. That's how I can help. That's how I can be really valuable.

And they do that. And everyone is like, that was amazing. Thank you so much. We were really having a hard time with that and you knocked it out of the park. And then they're like, yay, I did good. And then a couple weeks later, they're like, oh we're struggling coordinating with that team or this plan or that document and they do it again and they, they end up falling into this role where that's what they're doing with a lot of their time and then down the road, like everyone along the way is saying like, this is great.

Thank you for doing this. It was super useful, but they're not developing their technical skills. And then review time comes around. And the manager is like, well, you're an amazing team member, but your technical skills aren't where they need to be for a promotion or to move forward in your career or the corp.

Sometimes in extreme cases, you're not developing enough code to like be an engineer. Have you thought about being a FIA umbrella manager or, you know, whatever? And those are fine careers too, but usually if someone joined a team as an engineer, it's because they want to do engineering. So you want to make sure that you take the time to develop your skills as an engineer and don't lean on the skills from your old job. It's not that it's not good to be good at communication and coordination. Those are incredibly valuable. And especially as you become more senior, you would get to that lead that, that the special pretzel or staff level, you're going to do a lot of that.

And being able to communicate effectively will be hugely important, but you have to build it on those technical skills. And that's what you should be focusing when you cut it. The best kind of way that I've heard someone express it is if you want to start a new job, you got to quit your old job.

So stop being the manager. Stop being the coordinator. Stop being the document writer, be the engineer if that's what you want to be. And that may mean watching things not get planned. Well, I just be like, I know I could do that better. But I want to be an engineer, so that's what we're gonna focus on.

Those are my two big pieces of advice if someone is coming into this field.

Ash Patel: I appreciate that pragmatic advice that you just gave because it's something that I see this from people who come from backgrounds where they're pretty much the main person in their family looking after.

Yeah. And for them, taking on that role of being the coordinator, planning out lives, planning out things, is what they feel they need to do. And we need to tell them, give them this prag that pragma that advice is so practical that please focus on the technical side, leave the mess to the senior people to deal with.

John Hyland: Or learn that that's what you actually want to do. And then switch into that role as a PM or something. That's fine too. But if you want to be an engineer, be an engineer.

Ash Patel: That's a great thought to finish this conversation. I appreciate you joining me on this conversation, John, and I hope to have more conversations like this in the future.

John Hyland: Yeah, it's been a lot of fun. I'm always happy to talk about Ignite and I'm happy to chat about it anytime.