Darragh is currently the VP of Engineering at Intercom. (One of my favorite companies). He joined Intercom in early 2012 as a product engineer and Intercom’s second outside hire. Fast forward to today, and he is Intercom’s VP of Engineering where he has grown and scaled the organization into a world class Engineering team. Prior to Intercom, Darragh worked at numerous other companies including Amazon.com. Darragh is mentor on the Plato network and is passionate about the outdoors and his family.
On today’s show we discuss his path from IC to VP of engineering and tips on how to scale a fast growing engineering team.
[0:02] Good afternoon. You’re welcome to the show.
[0:05] Hey welcome. Great to be here.
[0:07] Yeah absolutely. One of the things I want to talk about today is you’re actually from Ireland but you’re visiting San Francisco. Is that correct?
[0:16] Yeah that’s correct. I’m based in Ireland. With our R&D teams spinning more and more in San Fran I’m over here to get better connected with people in the San Fran office. All while hijacking my kids summer holidays.
[0:40] That’s pretty good timing. I had the pleasure of actually meeting you and some of your team recently in London at the Lead Developer conference. It was certainly nice to put a face to a name for one of the guests that I have on the show. It was great to meet you there.
[0:57] Yes same. It was great. To have the background conversations and get to know you ahead of this chat was super useful for me.
[1:09] Sure yeah. We both have similar positions right so it’s one of the reasons why I do the podcast – to get to talk to people who are in my shoes and how they’ve come to ranks and what they might have done differently and just understand that, and we’ve talked about this in the past on my show but when you get to this level, being the VP of engineering, it gets to be lonely in the sense that the amount of people you can talk to about certain things really really starts to get smaller.
[1:35] Yeah absolutely. I felt the same way for as long as I’ve been in management. Like as an engineer you are so baked into the culture and most companies that like you lean on peers for support & feedback and that’s quite normal and you’re surrounded by other people in the same role. As a manager, you know, you may have peers in your company but the culture isn’t there as much typically of like sharing and giving feedback on problems. You don’t have community groups in the same way you do for technical topics on every single technology or problems remaining under the sun. There are far fewer opportunities or learning opportunity as a manager.
[2:28] Yeah absolutely. I want to go into that point for a minute before I go into my normal pattern of finding out a little bit of your background. Since you’re talking about that subject, what have you found and what are some of the recommendations you might have for other, and this happens when you become a first-time manager too, what resources have you found helped you to chat to your peers about or ask questions to other people. Like is there anything that’s worked the best for you or that you recommend?
[3:00] One of the first steps is overcoming any inhibitions you have about talking about the types of challenges you have with others. Because management can be a kind of behind-closed-doors kind of thing you kind of treat it that way too and in the same way that you might as an engineer have a sense of confidence and pride in your work because you know, you can share it publicly on GitHub, you can get all the right types of feedback loops to give you that validation. The same things don’t exist as a manager,
If you want to go out and learn from others like step one in overcoming any inhibitions you have relating to being comfortable sharing your challenges you’re having because for the most part, they’re not new challenges and frankly they might not be like super glamorous things, just the bread and butter of what you have to do and overcome as a manager.
[4:05] Yeah that’s a good point and I think sometimes the mistakes that first-time managers make is thinking that they’re a manager now so they should have all the answers and that’s certainly not the case.
[4:17] Right for sure.
[4:19] It’s okay I tried actually you know talk to my new manager all this and I’d rather you elect this is a journey on your management past and it’s about coaching.You let’s use any opportunities that you have to come to me with this as learning opportunities, you know how I might do things, ask a little about how you might do things.
but certainly you ask because it’s not like working on code where you quick fix in a change alignment, Git-hub push is a little different then you just going to royally screwed up on your employee’s lives.
[4:49] Right I think that seems like terrific advice to approach new managers, in the same way like dropping your inhibitions to talk about some of your challenges externally, like seeking out peer support outside of your company, I know as a manager, there is nothing, well there are few things I appreciate more than a report than who is also a manager being open about the challenges that they are facing are or any areas of uncertainty. Because if they don’t do that it’s much harder for you to spot and figure out how you can help them.
And I think both of us can agree that if a manager is coming to you saying that everything’s great I don’t have any issues or problems at all or challenges that week that was probably symptoms of communicating incorrectly.
[5:40] Yep for sure.
[5:42] Interesting too that I have used Intercom in the past and, certainly a consumer of a lot of the stuff you produce and I have actually interviewed someone on your team early on in my podcast days, Dave Lynch on an earlier podcast episode.
That was a great episode if any of my listeners want to go back, we talked about 1-1’s, but thank you for I think kind of setting the culture to where your team members are certainly giving back both whether it be podcast, talks, blog posting I think it’s a great testament to the culture at Intercom.
Awesome, excellent job, thank you.
[6:24] Thanks for that’s, like the backstory to where that comes from comes is pretty straightforward and it’s, I could frame it selfishly in that’s its the mechanism to learn by reflecting and sharing how we think about things.
It enables us to better, to sharpen our own opinions and our approach to get feedback from others.
[6:57] Related to that, it’s also been a fantastic way for us to show the world the things we care about, think about.
In many cases has been what’s helped track like-minded folks to use a product or to come and work with us.
[7:20] Yeah, certainly.
The buy products, it’s like it’s a virtuous cycle which is really good, really good,
No I usually get this this point a little earlier in our conversation but I’d like to have conversations and I don’t want you to stay to a script if we are having a good chat about something, but for some of my listeners out there Darragh can you give me just brief background, how you got to be where you are today, give a little context for the people listening, to who is talking and to whom I am talking with today.
[7:51] Okay, sure and jump in if you think I am either abbreviating too much or rambling.
I think fundamentally I’m in a role, in the software industry because I enjoy applying myself creatively to a whole range of different problems, I think there is few industries if any that enable that more so than software in general.
You know when I got into it you know, when I decided to study computer science at a college or whatever, I had no real idea what the career ahead of me was like and you know it kind of just unfolds as you go so I didn’t know a grand plan, or whatever.
But around about the same time, as deciding I wanted to do this in college I had the fortune of an older sibling who was in the industry and who was exposing me to all these like interesting ways of thinking.
I remember distinctly before I even learned to program I was reading the type of books that were super popular and remain popular today like factoring books, design planners book, the early books on extreme programming or the programmatic programming all these different things so from an early days I like I was infected with the, at least the thought process behind a lot of the engineering practises and philosophers remain prevalent today.
So I think that’s like the real like, looking back on the fortunate things that happen to me and then you know through my career I haven’t always work in the what I would describe in my, idea scenario which I have come to understand to be like working on problems I can be excited about.
You know again as I mentioned there is such a wide variety types of problems you can solve as an engineer and you know I guess I discovered that as much as I enjoyed that type of work there are something things I enjoy more than others but early on in my career I didn’t have the luxury realising that or steering towards that and the other things I realised that important are working in a way you are bought into, are excited and you feel enables you are those around you to be most productive and that was a strong team theme throughout all those books I read and i remember my first job, not a particularly glamorous job, it really enabled me to practically cement some of that thinking.
My first job was, my title was like a build engineer and I was working for a company that produced software that they licenced to banks to do online banking and the release cycles you can imagine is kind of pretty scary and required someone relatively junior to spend like a couple days a week assembling everybody else work into something that they hoped would be deployable or whatever.
This is one of these like I know it’s kind of cliche but it was really true and really the case, one of these opportunities for me to engineer myself out of the job and to eliminate all the wasteful manual work and I tremendously enjoyed that despite really me not being bought into the company I was part of or perhaps even knowing how the software work or was or who the customer was.
So you know I simultaneously enjoyed that and identified that I want to be more connected to who I am building software for and be bought into to what I’m building.
And I think from there I like had, trying to get this somewhat accurate but the next hop in my career was to a company that actually made their bread and butter in consulting with bigger companies around software process, they kind of took off around the time that of extreme programming and scorm being popular and had some really fantastic coaches I guess that would deliver, either partner with companies or deliver training to help them like transition to more agile approaches.
But where my focus mainly was within that company was in actual software delivery so where a customer believes that their current approach is to building software was not going to achieve the success they needed and they wanted to try something different and work with us to partner and that was really interesting again seeing both dysfunction and living through an approach that worked better and most importantly I think understanding and agreeing to like problems to solve for a customer rather than being a slave to some unwieldy process.
Anyway I should fast forward a bit.
So I worked in that type of process-oriented consultancy and at some point we had the opportunity, where we like consulted on the delivering 1 or 2 projects and ended up turning into,hey we can actually build a product here that we can licence back to all these clients but for which there is like tens of thousands, or hundreds of thousands of theoretical customers and that was my first exposure to working on a vast type of product.
That’s was exciting, I felt really torn moving on from that, that company was even in 10+ years never going to be massive or atleast transpired not to be massive, I wanted to work in something, bigger,faster growth organisations and deal with an understand process and problems of scale so at the time there were was a reasonably fast growing Irish company that I joined called NewBay and that was eye-opening in terms of, like I joined in the space of a year it went from 40 to 150 people and lots of engineering. For better or worse I ended up quite early in my career in quite a senior role, technical leadership role and so i think I experienced the sort of high level ownership aspect of engineering leadership, like where in terms of partnering with with a client in this case and understanding a problem and owning a plan to solve it and I feel I really developed in that regard, in this role but it helped me realise that again I was missing the pride and ownership of the actual product we were building and we were solving .
I should say that my next step from here was not one that feels proud of in hindsight, but I left that environment and jumped to become to first engineer at a startup like that’s an exciting step for people to take but also one that like.
I would encourage people to not do without being properly informed, that’s was an opportunity for me, ok I can make this move and step beyond any of my problems like, not being kind of proud of the thing we are building by being more directly responsible for that not being good and I guess my naivety here was like, the degree to which success was in anyway achievable in what we are doing and whether the team and the environment were around was sufficient.
I’m going to try and accelerate, from there I worked in a fun consultancy that coincidentally the founders of intercom were my peers of this consultancy and we worked again in a, in a way that I was very proud of with a lot of clients and interesting projects. But this also coincided with me starting a family and looking for something a bit more stable for my career point of view.
Which is why I jumped and took a role at Amazon.
So the motivation there was to see and understand how orders of magnitude of larger scale engineering teams and companies work and in that regard it was super valuable.
But over time it quickly became apparent that for where I was in my careers it wasn’t satisfying all my passions, desire or creativity, and all through this point I should say I had been in like IC roles with a variety of leadership responsibility or expectation. Remaining up to this point in my career was a contributing engineer and when Eoghan, Des and Ciaran and Dave started talking to me about Intercom I just got really excited.
I wasn’t drawn to intercom for the role that I have today, I was drawn for the people and the philosophies and the product we were building how much that aligned with what I wanted and getting to the role that I am in today was more organic than designed. I didn’t set out to have it but I naturally gravitated towards leading from a thought point of view but also from a people point of view how we operated the team.
And you know, it was kind of like a boiling a frog situation after we started hiring people 6 or 9 months later I kind of took on the formal responsibility there.
and as the company has grown more of my responsibilities have grown and I tried to pace with that so.
That’s a pretty long-winded answer to my background.
[20:27] When you entered intercom as an IC and then, did you didn’t did you jump from an IC too kind of VP of engineering or was there a kind of manager, and then director or just had about how did I grow and evolve and obviously the team is small and then kind really grew very quickly. What point did you kind of take into to hey now I’m running engineering
[20:49] Trying to remember this accurately.
People were like early on, we didn’t have, it was the 4 founders + me and 1 other person that joined as engineers we just, we all actually as it happens worked together before and there was this wonderful fluidity in how we worked together and it was only really when we started to hire a good few more people that we realised that we need to like have a proper approach to management structure.
At the time it was more or less myself and then Ciaran who was the CTO kind of co-running a lot of things but we somewhat divided and conquered.
He kept his focus on the infrastructure and operational side and had 1 or 2 people who worked closely with him on that regard and I focused on the product engineer side of things and I think my role like at the early on became the head of product engineering.
I worked closely with whoever, Des at the time and then Paul Adams when he joined in that regard and then it was soon after Paul joined then we started to grow out more of a structure and we had hired someone at a director level and all this kind of stuff we formalised the role that I have today.
And you know I kind of mentioned that split, divide and conquer between myself and Ciaran the CTO at one point when the area of infrastructure and operations grew and we really realised how intertwined it was with the rest of product engineering we folded that all back into 1 org together and freed up Ciaran up to take a similar approach to owning or focusing on like hard engineering problems and for me to focus on the organisational health side of things.
it’s something I asked all my guests and anything you can share, sort of mistakes you look back on as you grew quickly from that IC role into more and more of the team and then running engineering. Anything you look back on and say “oh wow” well, I wish I could have re done that.
[23:33] How long you got.
[23:35] Protect the names to protect the innocent here a little bit but you know I think we all know who it might be and what companies its at but or if not specific antidote or a pattern of things that you saw yourself doing that if you could go back in time and talk to yourself again you would be like “lets try to avoid this”
I’ll share maybe a few general ones that I think probably everybody faces at some point in time, particularly if you’re like growing a company from scratch.
The first,this one we made early on was realising that our hiring process was pretty ad hoc and somewhat amounted to, who do we know that like crazy enough to take a job in a company that they never heard of before or like that no one else has heard of and that kind of looks like finding people in your network with the same appetite for risk as you have, but doesn’t necessarily speak to who they are for role or how successful they might be in the company.
So that early realisation meant we needed to a little bit clearer about what we value or what’s important to us on the team.
I’m probably compressing time here a little bit, because a lot of things evolved over a longer period of time.
2 parts kind of emerged from that, 1 was kind of like reflecting on the types of people, or the types of behaviours the most successful people demonstrated and that aligned or resonated, how we felt about how we wanted the company to be, identifying those things and trying to design and evolve our interview process to surface those things as well.
And just getting that consistency between when we see success and what behaviours lead to that and how we appraise or try to attract people in was really important.
I can jump onto a different example, you know this is kind of reflecting on my journey to the role I had at intercom was pretty fluid and organic, I went from always knowing what I wanted,I expected to have a big part in leading the team as an engineer, to then doing that with a different set of responsibilities I kind of naively felt that without doing a whole bunch of work that a sufficient number of others would follow the same path and enjoy that and any challenges we had like scaling the org would be solved from within.
And I also underestimated the amount of new challenges you face as a manager and the supports on it or knowledge or experience you might want to draw on to or quickly overcome them, so I bet in the early days there was a bunch of stuff we got away with in terms of not being a whole bunch of mature, because that’s where expectations are when you join a company at that stage and they weren’t problems but when you join a company that is 500+ people you have a reasonable exception that they have a joined-up process for performance reviews and whatnot and in the early days that was a lot more organic and if I could change anything relating to that I would have properly considered the challenge of growing management capacity way earlier on and that might not have necessarily been a solved by hiring but it could also have been solved by realising that there are, beyond what I could give are other ways to support and grow managers. You know, even encouraging them to talk to other people in other companies and to draw on what other people were learning. Amd then I think the other bit which was a lesson for us, Intercom, I’m reasonably proud of the way it all transpired, was in the early days, like as in the first 3 or 4 years all of our managers did grow from within and come into that role as first time managers and I think by and large did a terrific job of it,albeit with less supports then I would be proud of it today.
But they did so and realised that after 2 or 3 years it wasn’t what they were passionate about, they had stepped into that because it was the only reasonable means of having higher impact and did a fine job of it but ultimately were you know less happy in that mode so.
I think there is just like a critical thing for both individual and companies to realise is that you want great people that are in a management role that, that you want then there for the right reason and it was never our intention to incentivise people being manager as the way to have higher impact, that’s just not true but the way we evolved kind of lead to that.
What im proud of is that we kind of enabled people to realise that and to promote themselves back to the role of engineer but what I was maybe blind sighted to the fact that this was likely to happen and that it was more if the reactive situations of like how to course correct from there, we realised we needed to invest more in bringing in managers from outside.
[30:26] And if you look back today what do you think your ratio is overall inside of intercom for managers who have risen up to the ranks versus external managers that you’ve brought in with experience.
[30:38] About 50/50
[30:41] 50/50 and you think that that’s about right you have to try to shoot for a ratio to think about 50-50 with more less one way or the other.
[30:50] It feels like about right.
You know we’ve got it 50/50 with a sharp correction.
If it was stable at 50/50 I’d be happy.
I still think through at the early stage I was excited about the type of team we were building and how much that was like 40 engineers and by the engineer.
I’m don’t want to discredit the value or impact of hiring a manager at that time, but so much of what we were doing we were figuring and it was a lot of a lot of the strength of our culture comes from more so engineering practices in the early days then from then from our management practices that were established in the early days so basically what this boils down to is, in the early days your ability to know the right type of manager or manager kind of practise to establish and if you don’t know what you are looking and if you hire a bunch of people you will probably get a random and potentially surprising set of results
[32:22] Sure we are looking kind of creating your values in your core culture first and then making sure you hire managers that will come help to promote that and mature that but really stay true to those kind of values and not come in and and and change the course of the ship.
[32:38] Absolutely and that doesn’t preclude strong managers on your team early you know, I would always encourage that. I think how you articulated it is correct.
[32:52] What do you do in your company ensuring leaders to help make new managers more successful,do you have any formal process in place or any guidelines you put together to help, because ultimately you want, especially if you are promoting from within, you want to set them up for success. So does Intercom do anything special to help guide managers in into that role and be successful
[33:14] Yeah,there are definitely a couple of things,we have the luxury now of having slightly more out people operations, people focused team and within that with have people focusing on L&D and over the last year or so they built out with internal folks and external partners a bunch of learning materials for new or seasoned managers and I think to the last point we talked about we have got better and clearer about articulating about our values and our culture and how we work and our process and there are now a lot of strong role models within that cohort of managers to lean on or emulate or learn from. So you know and of course the, and for any new manager their direct manager is going to focus a lot of a lot of energy on helping set them up for success.
We also do things like encourage people to in the same way that I do or might have done in the past go talk and learn from people in other companies and we have put on events, sponsored Lead Dev, like you mentioned, tried to write about our war stories or strong opinions and all of these in little pieces build upon how we try to grow our managers.
[34:55] Sure sure you know one thing that’s sometimes, people hear that to grow and scale an organisation especially from the early engineers you hear a little bit in the good old days or great when X right, I mean. 1 have you heard that at all and how do you approach them and how do you respond
[35:19] Yeah that’s a great great question.
[35:30] The reality is that,companies do change over time, the challenges that you are facing beyond, the opportunities that you have, the strength of your team, the competitive landscape. Everything changes over time and I always, before Intercom felt that the fault trajectory was that things get worse when you add more people but I believe strongly that does not have to be true, the trade offs change, the communications overheads or the types in which ways you have to coordinate with other people changes but the impact you can have together grow and I think that’s its fine and legitimate for people to have that viewpoint.
Like I’m happiest in companies that are 20/30 people or whatever but I would suggest that it’s also somewhat limiting and part of what I feel like has just kept me excited, challenged and motivated is that constantly changing environment.
You know, in many different directions the challenges are changing or getting harder, or more interesting and simultaneously challenges are getting harder or different the strength of your toolset or team or whatever that you have to solve them is changing and increasing too.
The other kind of thing that I like want to dispel is that like any view of small is better than big is way too one dimensional and all these things are about different trade-offs and different strengths or whatever you have.
So getting back to your original questions it’s going to happen and it’s going to be ok, it should be expected that you will reach various stages that you might articulate as,you, the company has outgrown the person or the person is happier in a smaller company and my kind of base opinion on all of this is that it’s a good thing you realise your in a company where, unless you change substantially yourself or who you are which is a tremendously difficult thing that you are not going to be as happy as you deserve to be.
Identifying that is great as you can suffer it, it’s sometimes sucky for people, but moving on to find where you will be happy is good, I just kind of based on my own experience kind of caution people having such firm kind of binary options about like where they can be happy.
The reason why I’m happy and progressively in a larger company is because I feel like we have a culture empowers me and others and everybody to make us stronger as we grow, no see it like as an unavoidable slippery slope to mediocracy or whatever. You know I think the other path can happen but i’m here because I believe it, it’s not guaranteed.
[39:24] Sure yeah I think as companies scale and grow the priorities tend to shift somewhat and a little bit, sometimes it’s when you are a startup and you don’t have customers. Sometimes that’s a nice green field environment but as you grow and your company becomes more upmarket, maybe it’s more enterprise customers how do you end up blending needs of scaling the company with process, sales needs and customer support and potentially compliance issues while still being innovative and agile like when you started.
What are tips you have or something that Intercom have done to make sure they can balance that agility well growing up and supporting real customers.
[40:09] Yeah I think that’s really interesting and kind to the last question like for me part of what has been really interesting is the kind of surface areas of the things that I and we as a company think about has expanded to include like how we go to market and what kind of compliance issues we have, you know a lot of software engineers are driven by an opportunity to lean and custisory so that has really worked well with me.
In terms of how we have adapted as a company, for those who don’t know the origin of Intercom and the early years of intercom was very much, like all we were was an R&D team, we were a bunch of people building the product together and it didn’t come from free, its wasnt like a fluke or anything but we had this like really lucky streak whereby the audience that the founders had built in the early days itself produced the type of growth that we needed to survive and grow as a company.
But what that did was kind of, almost to a disadvantage, like blind us to the reality that you know that any pieces of software is only successful if it both solves the real problems that customers have and will pay for and also find them and convince them to pay for it. So like in the pure sense, I think what you want is your whole organisation to have an appreciation for the full view of what a business being successful is and you break that down into building a product, going to market with a product supporting customers but its not like one vs the other. It’s not like sales vs product, trying to find ways you can work together to the same outcomes and I think like one interesting way that has happened at Intercom has been you know, we are very much purely like, our origin as a product first or product lead company and maybe in the past we have been proud of that to a fault because the reality is that like, sales teams and support teams in terms of proportion of their time they are actually closer to the customer than our product teams and our product teams job is to like to consume and absorb and simplify all that context into what might be the right decisions.
But amongst the most best and value inputs, are inputs we get from the intelligence our sales org bring and another interesting kind of problem that like I think a lot of companies will face will be the tension between commercial priority or near-term priority vs like long-term or pure product priority and I guess a specific example, like an extreme example might be are you the type of company that, because it will happen, you have a customer who is willing to pay quite a lot of money but will only do so if you build feature X or feature Y, its a valid fine approach to be the company that says yes to those but you should do so know that will reinforce and establish a as the means to how you plan priority in your product, I suggest that might not lead to great outcomes all the time and then on the other side realising the valuable input balancing it all with all those others. Sometimes when you have teams that are not aligned to commercial realities objective to business prioritize things that are great in a vacuum but don’t help the success of the business.
Maybe went a little off topic there but I think in a not help but like abstracted sense, everyone in the business is like a primary job is like to drive long-term success and people just wear different hats in order to do that. At the level of a single team within our product building organisation were you have designers, PM’s and engineers they are all wearing different and all wear different hats and skills but what works really well for us is each of them having a strong curiosity and strong appreciation for what their other disciplines bring, I always just get a little bit allergic when I hear things kind of framed as a us vs them, Pm wants to do this thing and engineers want to do this thing and it’s a fight but that to me is a sign that those two groups of people are aligned around a common objective.
[45:54] Sure yeah and that makes sense and that’s something that through every, company large and small I think I’ve ever worked at has been a you get presented with those situations about but there’s customers money to pay to accelerate development or they’re not going to sign the deal or they going to renew they can get x y and z,
and I think balancing that is no right answer to your point but it’s what you have based your culture on and how you want the company to grow and scale.
And definitely points that I think are probably going to resonate with engineer leaders to sit there and face those sort prioritizations indecision that have to be made so we all go through it and I think that’s one of the reasons why I do this podcast,
to let other engineering leaders know that it we also have both of these struggles we all have some of the same issues,and you know Darragh mentioned before try to reach out to other people to chat about them was their internals of the company or other outside of the company I think it’s very helpful to know that,you’re not alone in dealing with these issues as we all go through it and there’s no I think one right answer think that’s that’s another point I don’t want to make as well.
[47:07] You have had really incredible growth over your your career there your time there in the company, any one last point you think engineering should focus on earlier in helping the organization a scale that it was oh if I would have put this in,You know back at this point in my life would have been easier now or it would I would have had to refactor something and anything specific comes to mind for that.
[47:31] No mentioned re factoring leads me to think on a more technical level.
[47:40] Either one really.
[47:42] On a technical there is this highly debatable or whatever but my my biases are around.Avoiding like premature decision-making, but enabling like fast initration.
I thinks things we didn’t do in the early days of Intercom were like debate weather
[48:09] Things we didn’t do any early days of intercom were like debate whether we should like look at what Facebook and take the same aractiture approach they are doing, we were just happy to do what worked well for us that was simple and fast, effective and we could iterate on. And did not go over aractiting the system and its true that led us over the years we got to various points were decisions that we had taken were no longer helpful for us making progress and we had to kind of correct significantly.
But in every case I’m confident we didn’t know what the right long-term solution would have been , I think like investing in the things that enable you to quickly learn and make changes has been one of the most valuable approaches we have taken.
As you get bigger that gets harder and I can’t claim we have solved that necessarily but it is now its a much harder job to decide if there’s a better way to do some particular thing then have the whole 200 ish engineers align around that, we have some patterns for it but yeah. To kind of close out the point in the same ways that it’s probably conventional wisdom premature optimization in terms of code efficiency, is probably a wasted effort. I would encourage people to like keep things as simple and flexible as possible in the early days because you have so much to learn about what problem you actually want to solve.
If you deferring it, you will have far greater success.
[50:13] Yeah you might expand on that point as I think it’s a good one.
Often when I come into new engineering organizations and for something I would recommend for other managers if they’re coming into other engineering organisation as well even if you’re an individual contributor.Especially is a startups think it’s important to know Chaos Theory Butterfly Effect right if any decision has been changed or code is written differently or you focused on something else even though it might be a challenge to deal with today, having a different Focus early on could have had such a,wide impact on the company the organisation in a minute even exist today right so I think it’s important to go back in and understand the set of the context around decision but certainly don’t go in and, and Bash them or you talk anything bad about them because if things have been done a different way the company might not be around so I think that’s an important thing to make.
[51:09] I like that very like very quickly expand on that.
I think if you theoretical path to optimal success for a company.
I’m pretty sure it’s not one that’s necessarily comfortable or like solves adequately for all the different concerns.
You know, there are trade-offs you need to make and I think what can be difficult can be
For engineers and currently for me at times is your making trade-offs that aren’t easy to swallow even though if they are right. As leaders that sometimes might be the challenge in start up’s is kind of reassuring people that like yes, there might be theoretically perfect way to do X but pragmatically we need to do Y instead because short-term survival or growth of the company will enable us to, actually have that future where we can solve a whole load of other problems.
[52:15] It allows you to solve other more challenging problems, Laura Hogan makes a good point about assuming good intent and I think that also replies to this assume everyone works with the best information ahead of the time and they had the best information they could.
So as a final thing I like to ask all of my guests if there is a book or resource that you have recently read or you consider foundational that really helped you along the way as to growing and scaling as a leader.
Do you have anything you might recommend?
[52:50] Just one that came to mind based on the chat earlier and its not necessarily directly like leadership or management role related but it was very transformative to me in the build-up to me taking a role in Intercom, it was by Ken Robinson, it’s a book called the element, all about understanding and finding the environment you can be happy and thrive in and you know I think the take away for me is I, both it’s our responsibility to ourselves as individuals and as managers to the people on our team to do our darn best to make that true. You can be all things to all people, but at least be clear about the type of environment you’re creating and why that’s a positive thing for the people that are involved and try to find aligned people who join the organisation, make sure that the environment that they can be happy in too. The Metta bit for me on that is, probably like an organisation you as a person are joining are empowered help shape and evolve it. Hopefully, that’s interesting, I would recommend it for a quick read for people.
[54:16] Yeah no that’s awesome, I think getting a real diverse section of these in my one point I’ll post some really big blog post about all the things I guess it recommended but what’s the what’s the best way for people to either reach out to intercom or to you personally with her it’s Twitter or something else that you want to share with my with my listeners
[54:39] So welcome to reach out to me directly either on Twitter or via email and you can reach me at darragh@intercom if it’s about Intercom, in general, our friendly team are always available and present behind messenger on our home site or alternatively I can connect you to the right people.
[55:10] Well excellent, I really appreciate you taking the time, I have enjoyed our conversation today. It’s kind of ironic we are both in San Francisco we are talking virtual, but I am glad we got that chance to meet in London and again thank you very much for your time and I appreciate you coming on the show.
[55:27] Thank you, it was fun