Connecting your daily work to intent & vision

One of the problems that I’ve been thinking in the recent months was the disconnect between what we should be doing, the vision, or the thing that feels right, but may be really hard to do because of different things of reality, which is really interesting; an interesting concept. What we actually do, day in and day out, and what we say we do. So how do we connect all these three things? You know, like when you report, you tie them all together, they kind of don’t add up, and you don’t know why. These are some of my thoughts which I’ve been having when I have first learned about EchoesHQ, and I knew that I had to talk to Arnaud and find out more, because there was something there.

The demo was great, thank you very much, Arnaud. I really enjoyed it. And now, after a few months, I would like to know about your Y Combinator demo. How did that go?

Yeah, so the Y Combinator demo was probably the most stressful minute of my life. I’m not really sure if you’re aware of the setup, but it’s actually just a one-minute speech, with a single slide, in front of hundreds of investors. So trying to condense the message into 60 seconds, trying to condense the message into a single slide is actually extremely hard. there are necessarily things you are not gonna say, and that are extremely important to you, but you will have to omit… And this is an interesting exercise in getting the message as clear as you can.

[04:11] I would love to see that slide, and I would also love to see those 60 seconds. Do you have them recorded somewhere?

No, we don’t. It was not actually recorded.

Okay. So if I asked you to do those 60 seconds for us, would you be able to?

I don’t think I have them in mind anymore, and to be fully honest, it’s not exactly the same pitch you do to an investor than you would do to potential customers or people who understand the field… You know, it’s deliberately devoid of any jargon or anything like this, which makes it a bit bland… So I don’t know if it would be very valuable to the audience.

It would be interesting to me… So if you would like to do that, I would be very curious to hear what that even sounds like. As close as you can get it - the 60 seconds sounds perfect. No jargon. I’d love that.

So let me try and do it again then. The 60-second pitch at Y Combinator sounded something like this… Hi, I’m Arnaud, and I’m the founder of Echoes. I’ve been an engineering leader for over a decade, I have worked as a deputy CTO at VeePee before that. I was running the core team and the open source project at Docker. One problem I have consistently encountered throughout my experiences is how organizations are held back by a lack of alignment and a lack of focus.

By measuring how engineering work contributes to business goals, Echoes helps bridge the gap between technical and business teams. For example, Echoes can show you how much time we’re currently spending on each of our OKRs, which helps engineering managers make the right decisions, and communicate the activity to their CEO or business partners. That’s pretty much it.

Okay… So let me go and get my checkbook. Is a blank check okay? [laughter] Because that sounded really, really good. Okay, that was really good.

Thank you.

So I would love to see, again, that slide, and if we can, I would like to include it in the show notes, if that’s okay with you, so that people, as they listen to those 60 seconds, they can look at the slides and they can, on the slide (the one slide) they can decide whether they wanna bring their checkbook.

So while doing a bit of research in Echoes - that was only recent - I noticed that you also appeared on Product Hunt.

Yes.

I think that came before Y Combinator.

Yeah, that was during the Y Combinator batch. It’s one of the things that Y Combinator really pushes you to do, it’s to be public and to launch as fast as you can. That includes Product Hunt, that includes Hacker News, any other medium you can think of. And I think it’s one of the most important lessons I got out of Y Combinator, actually. For some reason, the instinct of a founder is often to be stealth, to work in the shadows until something is ready… One of the lessons of Y Combinator is that it’s never gonna be ready and it’s never gonna be good enough for you… So you have to put it out and to see what potential customers think of it, because that is the only signal that really matters. And it’s very uncomfortable at first, but I totally agree that it was the right thing to do.

So in my mind, that translates to “Ship it, and let’s see what happens.”

Yes.

Literally, that.

It is exactly that. It is shipping early, shipping often, and - you know, I had this conversation very early with one of the partners at YC about “I don’t feel that I’m necessarily ready to launch”, and what he responded I think was absolutely great. He asked “Do you remember the day that Airbnb launched?” No, obviously, I don’t remember. And nobody does. And it doesn’t matter, because the truth is there’s not a single day that Airbnb actually launched. They launched a hundred times during several years, and that’s the reality of any business.

That is a really good story. I’m gonna ask Adam to see if he managed to talk to the founders of Airbnb, and if he didn’t, I would love to hear that… Because you’re right - getting it out there, getting the feedback will change everything, many times over. So with that in mind, how did Echoes change since you’ve launched at Y Combinator, which was 2-3 weeks ago? …very recently. September 1st, I think.

[08:17] We launched during July, actually… And of course, yeah, a lot of things change, because you get to talk to a lot of customers, you get to talk to a lot of potential users, and to see – I would say you can test the messages that work and the messages that don’t, you can see what is truly hitting a nerve for your potential users, and what are the pains that they are experiencing the most… And of course, as a business, it also helps you refine what is the prototype customer, what is the ideal customer, who are the people that you should be talking to more etc.

In this regard, I would say the clear thing that I have learned is that the problem we’re trying to solve is absolutely universal. Any company that has, I would say, above 20 engineers, is struggling with too much to do, and a lack of visibility, especially in companies where the leadership is not necessarily technical, or doesn’t necessarily have an engineering background, and for whom engineering work easily boils down to a black box when it’s not very clear what is everybody working on, why is there so many engineers etc.

So why is connecting our daily work as engineers to intent important? Why is that important?

Because I think that ultimately, the only thing that any employees within a company share is that they’re putting efforts for the success of the company. And my strong belief is that if there was a way to express that simply, and to represent simply how our allocation of efforts actually maps to company’s success and to our different intents, it would create this shared understanding of what everybody is doing that would help with conversations.

I’m really passionate about the boundary between technical problems and human problems, and I often feel that some of the biggest technical achievements are really solutions that have changed the relationship between different groups.

With my background, working on Docker, there’s been a lot of debate about what was the true value of Docker - is it the image format? Is it the container runtime? Is it the API? But when I look back at what we did at Docker, for me the biggest success and the biggest takeaway is that we got groups that beforehand were not sharing so much together, the dev on the one side and the ops on the other, and we brought this shared understanding and this common artifact that actually made all discussions way smoother… And I think this is really the key value of Docker. This is the same thing that we’re trying to reproduce with Echoes, with a whole different group, which is engineering on one hand, and I would say business stakeholders on the other… And yeah, that’s creating this shared understanding and then seeing how we are collectively going in the right direction.

So let me see if I understood this correctly… What you’re saying is that getting people to share more in a safe way, in both directions, from top to bottom and from bottom to top, is the key to success for Echoes.

I think it’s one of the keys of success, and it’s doing so by sharing the right level of information. Because you know, the thing we have with our industry is that we’re doing tech, and tech is easily measurable, in that there’s a lot of things we can instrument; there’s a lot of things we can measure and we can put numbers on a lot of things. This doesn’t make all numbers good to share, for multiple reasons. The first one is that not everything is actionable to the audience.

One of the numbers that we have talked a lot, and that obviously at this point I think everybody knows is a bad idea, but just to illustrate as an example, is the number of lines of code. Everybody knows at this point that sharing the number of lines of code written is not a good proxy for anything meaningful. But I think it’s also true for tons of other things that we’re measuring on a daily basis that are not necessarily actionable to a CTO, to a CFO, or even to your PM. And I think we have to be very thoughtful in drawing the line between the things that are the operational details of a team, and that should belong to the team and only to the team, and the things that are about our direction, our success, our impact, which are of course the things that we are being challenged on, and that we are ultimately responsible for.

[12:24] So this is really interesting, and I know that many people agree with that, and many people, when it comes to visualizing work, this is one of the things which they fear the most - fearing that they will be judged on the number of lines written - or deleted, because that happens as well - or PRs closed, PRs merged, issues answered and closed… But it doesn’t say anything about the quality of the response; like, if you can do it in one line, why would you write ten lines? And if deleting more lines and adding lines makes the thing - whatever that may be, project, product, utility, tool, service - better, why wouldn’t you do that?

So it’s almost like the things that we are measuring - they are wrong, and maybe the way we think about measuring from a technical perspective just doesn’t work at these levels. So what does?

Yeah, so that’s really the bulk of the reflection behind Echoes, is to say that there’s a lot of things we could be measuring, but the only thing that truly matters is whether we are actually creating value for our business in a sustainable way. And this is why we believe that measuring the intent is so important, because everything starts with the intent. You cannot say anything about success if you don’t know why you were doing things in the first place. And interestingly, why we’re doing things in the first place is not something that is easily captured in a structured way in any of the systems that we’re using today… And that’s the difference that we’re trying to make as a starting point, on which we want to build a lot of things that are going to give visibility and actionable insights into the activity of the teams. Yeah, sorry, I lost my thought…

That’s okay… I have a follow-up question, which maybe we’ll juggle the important part… How do you measure intent?

Well, what we’re doing with Echoes is to give you a central way to define what are the things that we are working toward as an organization; what are the things that you value and that you are working for as an organization. By default, what we suggest is just a set of three outcomes that are extremely generic and applicable to pretty much any organization out there, which is to say that as an engineering organization, there’s probably things that you’re doing to create customer value, things you’re doing to mitigate risk, and things you’re doing to maintain your own throughput, which is your own ability to deliver software repeatedly and safely in the foreseeable future.

And then, this is entirely up for customization by the user. It’s up to you to figure out whether you wanna map your OKRs, whether you wanna capture the word that is planned vs the word that is not planned… There’s no good or bad answer here; it’s really depending on what you value as an organization and what is it that you want to capture. Then we’re gonna publish those outcomes to different systems and give an easy way for engineers to express why they’re doing what they’re doing in the first place.

So in the very simplest case, this is just gonna be materialized as labels in GitHub, and for engineers it means that they can add a label to their pull request with why they’re doing things… Because we’re using this central definition of intent, that is applicable across teams, regardless of the operational details of each and every team.

There’s a trend today that I think is here to stay, which is that individual teams are getting more and more autonomous, and they want flexibility and autonomy in the tools they use, and in the way they operate on a day to day basis. The reality at this point is that most organizations that are beyond 50 engineers - they have a diversity of tools and processes; you’re gonna have one team using JIRA, you’re gonna have one team using Linear, and you’re gonna have one team using GitHub issues, and that’s perfectly fine. But of course, this is a challenge for management, because then how do you get a consolidated view on what is everybody working on, and on the activity? That’s what we’re trying to overcome by having the central definition of intent, and then giving an easy way for engineers to express the intent behind work.

[16:06] And then, regardless of the operational details, the operational diversity of the teams, you keep having a central view of exactly in which direction we’re going and what is it that we’re executing against.

So capturing the Why - very important, and we’ll come back to that. Is it true that an issue or a ticket or whatever the unit of work may be, is a step towards a specific Why? Is that how you think about it?

Yeah, absolutely.

Okay.

And you know, when we’re talking about managing two outcomes, it’s usually open-ended, in that, you know, when you’re trying to influence – let’s say an onboarding time, a transformation rate, a number of active users, whatever… There’s no ending to this; it’s not time-bound, it’s not scoped. You may have an objective that goes with it to reach a certain threshold, but in general, those are pretty much the North Stars of the company, and it’s not gonna change on a daily basis… And there’s no end to it.

So I see intent as a direction towards which we agree to head towards. In my mind, the destination is the vision. Something that we’ll never reach, by the way, but we will do our best to get as close as possible to it. If this sounds familiar to you - you being the listener - it’s because Simon Sinek talks about this a lot. He’s one of my favorite authors… And I’m wondering, how does this definition or mental model about intent and vision match yours, Arnaud?

Oh, it’s actually a great point. I’m also a big fan of Simon Sinek, and of course, one of his major books is called “Start with Why”, which is exactly what we’re trying to do. There is an interesting point about this in how we designed Echoes. When I started with this product, I got feedback from people who told me “You shouldn’t ask engineers to label pull requests with why they’re doing things. You should have some kind of machine learning thingy that is going to guess why we’re doing the things we’re doing, so that we don’t require extra action.” I think this is a mistake for two reasons. The first one is that I don’t think we can infer from code why we’re doing what we’re doing. Ultimately, we’re just gonna do guesswork on the file name, or the habits of the developer, and I don’t think this is gonna be relevant, and I don’t think this is gonna be a reflection of the reality.

[19:53] The other thing is - I think it’s actually great to ask people why they’re doing what they’re doing in the first place, as long, of course, as it doesn’t take ten minutes for then on an hourly basis to respond to the question. But I think it’s a good forcing function to make sure that both on the managers’ part you make it clear enough that this is the set of objectives that matter, and that it’s well-communicated enough, and then there’s little ambiguity about why we’re doing what we’re doing… And then I think it’s a good forcing function for engineers to also put their work into context and to remember that yeah, what they’re doing is actually a part of a bigger whole, and that is the big picture that matters.

I do strongly believe, actually, that the best engineers that I’ve worked with - and to be fair, most of the engineers - they deeply care about the impact that they are having on their business. And I think it’s a good thing to make this relationship between their work and the business goals explicit, rather than implicit.

That makes a lot of sense to me… And I wanna ask you why do you do what you do. I’m pretty sure you’ve already answered it, but I wanna make it explicit. So why do you do what you do?

I do what I do because I’m passionate about developer empowerment. This is what drove me into engineering management in the first place, this is naturally what got me to work at Docker and to contribute to open source… And when I started thinking about what is the next thing that I could do for developer empowerment, for me the answer was not to try and build a developer productivity tool. For me, the answer is to try to help companies outside the one that I’m working at try and have a better context for an engineer to deliver their best work. And I strongly believe today that most organizations are dysfunctional in some way, and that engineers often deserve a better context… And I hope that I will help with Echoes in this way.

That is a great answer. It makes perfect sense to me, and I’m rooting for you; I really am. That was before I knew that you’re a Simon Sinek fan; now that you’re a Simon Sinek fan - oh, yes. Go, Arnaud, all the way! It’s super-powerful, the Why.

Okay, so I’m thinking… What happens when you disagree about the Why? There’s a fundamental difference of opinions about why we do what we do. What do you do in that case? What would you recommend?

I think this is an important point, because the truth is most of the organizations that we’re talking to that started to adopt Echoes, the starting point to using it is to actually agree on capturing the Why and agree on why are we doing what we’re doing. It’s interestingly not always an easy discussion in all companies.

But I think here, again, is a great forcing function. If as a management team you cannot agree on the objectives that are actually important for the company, how do you expect that anybody is gonna execute properly? Then when there’s a mismatch between the Why as it was defined as a company vision, and the people executing on that vision - well, naturally, this is the kind of mismatch that mean that either there’s a disconnect and potentially a wrong fit between the employees and the vision… But I think this is probably a way deeper problem that needs to be addressed, and that of course is not gonna be addressed by any tool.

We don’t have the pretention that we’re gonna help companies build a vision. What we promise is that we’re gonna help them close the feedback loop between the vision they have and what is actually happening on the field with the teams, and how the efforts are actually being invested.

In my experience, usually when people disagree about the Why, it’s when some number of people think about making money, and it’s an example of Why which in my opinion is very poor… Because that’s almost like a side effect, if you’re doing it right. Or for example getting more followers. You shouldn’t be focusing on getting more followers. That should be a by-product of you doing the right thing.

So in your experience, Arnaud, what are good examples of good Why’s, the right Why’s, which are the opposite of the examples that I just gave?

[24:02] As long as you’re working for a company, the ultimate goal and the ultimate Why is always to make money. However, of course, there is hopefully a deeper mission and something that people believe in, and believe they’re doing for the greater good.

On a daily basis, you’re not gonna motivate anybody by telling them that what they’re doing is strictly to create shareholder value. This is not a motivational engine for any employee I’ve ever known. Thankfully, there’s way more proxies to this that are actually actionable by engineers, and that are actually related not so much to making money, than to customer satisfaction. And I think one of the trends that we’re seeing right now that I think is extremely positive is with a product team organization model, with this idea that teams should be autonomous and should have a complete control over a vertical of the business, and complete control on one aspect of the business - that helps put engineers closer to their customers, which I think is absolutely key. And this is true whether the customer is external or internal. And I think this is the major Why. In my mind, what should be the most important engine to any engineering team is truly the empathy and the customer satisfaction.

I 100% agree with that. 100%. Honestly. If this was a bull’s eye, you’ve hit it. So I can see how shipping, getting it out there, whatever “out there” means, by the way - whether it’s a product, whether it’s a service, whether it’s a utility, it doesn’t really matter… Getting it in front of customers, hopefully paying - that’s what we all want; nobody wants to work for free, because things aren’t free… So typically what happens is you get all types of layers between the engineers, the ones that are getting it out there, the actual code, the value, hopefully, the business value… It’s not just code; there is some value being delivered. The customer is using it, and then the customer is feeding back what is not working, or what could be improved, or stuff like that.

So how can teams and companies resolve this tension between having the different layers, like sales, marketing, product management, or just product, engineering, and the customer? Because the bigger you are, the more complicated these interactions become, the slower the information flows, and the more difficult it is to do anything. It can take many months, many years, and it’s just a function of the number of people involved. Too many actors, too much chatter… Everything moves slowly.

Autonomous teams - I can see how that would help, but what does an autonomous team mean? Does it mean like a group of ten people, one of them being a salesperson, a manager, a product person, a designer? What does that mean? What does an autonomous team mean to you?

In my mind, the autonomous team is really the definition from Marty Cagan, the author of “Inspired” and other great books… It’s really about having full autonomy on the delivery of value to the customers. So in a sense, you’re right that it’s not all-encompassing. It’s not a small company that has its own marketing, its own sales team, or its own customer support… But the truth is, it could. It could, in some way. The problem is that, of course, there’s economies at scale, and there’s organization challenges that make this extremely hard.

Still, when we see modern engineering organizations adopt the product team model in its simplest form, which is to say that at least in a single team you’re gonna find frontend expertise, backend expertise, QA expertise, potentially SRE expertise, a product owner etc. then you’re gonna get something that at least is autonomous in how it delivers value to the customer. Then the feedback loop, of course, is gonna get more complex as the organizations get bigger… But I think this really a matter then of making sure that – you talked about layer… Well, making sure that it’s not so much layers, and that there’s actually verticals within those layers, with easy access to the other functions within the organization.

[28:08] I’ve never had the chance to work at one of the highly scalable engineering organizations such as Amazon or Microsoft or others, but they seem to have figured this out, in a way.

Okay, okay… I know that many good books came out of different orgs, on different topics, including management… But it always comes down to the fact that what people report on or what they paint - it’s usually not the reality. The reality is slightly more skewed, and it’s very contextual. Maybe for this person it was, but for the company as a whole - not really. And we all have good intent, but then the reality kicks in, all the reporting, you realize you actually can’t talk to customers. In some companies you just can’t. Unless they have a problem you can’t talk to them… Because why would you? You know, the customer doesn’t pay you… And this is – we talked about this with Ian Miell it’s just basically how money flows. In big companies, money flows differently. And money flows kind of rules what needs to happen; you have budgeting, and that’s different, allocations, and so on and so forth. So things are really complicated.

But I do like that Echoes is trying to simplify some of this. It’s going to maybe drive some uncomfortable truths and get people to have some uncomfortable discussions, and make them realize what is important, and more importantly, why those things are important. And as you mentioned, making money - well, that is almost like breathing… Like, sure, you have to breathe… But what else? What else is there?

This reminds me – I’m not sure whether you’ve read this book, “Drive” by Daniel Pink.

Nope.

I started reading it, I haven’t finished it, but he touches on this aspect of what drives us - hence, Drive. Money? Yes. I mean, there’s a couple of basic needs, and some maybe a bit more sophisticated, depending on where you are in life, and what your reality looks like… But there always has to be more. What is the thing that I’m working towards? Can I see it, first of all? Do I agree with it? And then the intent, we’re going that direction, and how do we measure whether we’re making progress in the right direction. I think that’s where Echoes comes in. That’s the way I understand it.

Yeah, absolutely. That’s correct. And to your point also about how money flows, and the complexity of the relationship with the business - what we’re seeing also today is that the most successful companies don’t make a distinction between business and tech, and are starting to understand that actually this is the same thing more and more, as companies become software-powered. And this is also what we’re trying to do - trying to get those two groups closer, helping… You know, I hate this word, but this mythical digital transformation that is all about bringing those two groups together, but never actually succeeds in doing so… Why? Because usually, it’s somebody pointing a finger toward tech and saying they have to change.

But no, collectively we have to change. It’s not tech that has to change. And that’s also what we’re trying to get to with Echoes - trying to get both engineers to take a step towards business by making sure that their work is well connected with the intents of the company, and separately, helping the business take a step toward engineering by understanding and also having empathy with their day-to-day, the reality of their work, the complexity of keeping the lights on besides the 10,000 other projects that we have to do… And yeah, again, creating this shared understanding that hopefully we’ll make everybody come closer and make better decisions together as a group.

That is a good one. I can see how intent is very closely related to communication. You can have the best of intent if you don’t communicate it, or if you don’t communicate it well… It doesn’t really matter, or it matters very little. So how may we structure information differently, for different layers? Because as information travels, it has to be more condensed, or more compressed, so that it makes sense… Because lines of code, or small changes because of X, Y and Z means very little to our CTOs or CEOs, especially the more layers there are.

[32:04] So how may we structure this information so it’s more efficient as it travels up the top… And then obviously, the inverse is true - how do make it clearer? Because it’s fuzzy at the top. The intent, it’s meant to be vague on purpose, so that people can just fill in the dots? You don’t wanna dictate, “Now we have to do this.” If we’re going in that direction, and how do we make it happen - well, it’s up to us all to define that.

So what are your thoughts about communicating this information, structuring it in a way that makes sense, and then expanding it or compressing it based on which layer it’s at?

Yeah, I think there’s inspiration to take into the OKR model, and basically accepting the fact that organizations kind of have a fractal structure, when you can consistently zoom in and see more details appearing. But that doesn’t change the fact that you can always zoom out and abstract away the details to see the bigger picture… And that’s basically the approach that we’re following, is to say that ultimately, this is a deep tree of proxies that contributes to company success, from this individual feature that we’re shipping, contributing to that bigger picture about the segment that we’re trying to please, contributing to the fact that we’re gonna have a better retention, contributing to the fact that we’re gonna make more revenue at the end of the month. But ultimately, it’s really this level of zooms that you have to look into, and make sure that you capture each of those proxy metrics and each of those actionable things that are the things that we’re working on in our day-to-day.

How did your experience with Docker influence Echoes?

A lot, in a ton of different ways. The first thing is that Docker was obviously about developer experience… And it made me realize a lot about how to build products developers love… And also about building a community, and creating enthusiasm about tech in a way that hopefully was positive, was human, and was friendly. I’m very proud, I think we’ve built a very welcoming and friendly community with the Docker project.

[36:01] The other thing is I was running the core team and the open source project for many years, and of course, the activity on the project was so high, and the number of maintainers comparatively was so low… We needed some tooling. And this is where I started building some analytics and some dashboards about the activity, about the health of the open source project, purely to help us manage the flow. At the peak of the project, we probably were, I would say, 20 maintainers working on the project, with more than 400 contributors on a weekly basis. So the asymmetry is really extremely high… And you know, the tools that we’re using on a daily basis, such as GitHub, they’re just not built for this, which is totally fair… But that means that there was a gap we needed to fill, and this is what really got me into building reports, getting data about how the activity was evolving, and how we could be better as a group… And it’s, of course, a very strong inspiration behind Echoes.

So are those tools that you’ve built - I imagine they were proprietary, internal to Docker, that you’d never made public. Is that right? that’s my assumption.

No. Actually, one of them was open source… And it’s probably still on GitHub, but of course, I’m not maintaining it anymore… But you know, to run an open source community, you wanna look at things that are significantly different than for running a company.

Okay.

In the case of an open source community you care about things such as being welcoming to new contributors, you care about things like fairness… For example, making sure that every contributor has somehow an equal chance of getting their pull request merged within the project, regardless of the fact that they are members of the broader community, or a friend company, or an employee of Docker itself. This was the kind of things that we were looking for to make sure that we were actually fair, and that you were not advantaged in any way by your employer, your position or your reputation.

And how did you do that? That sounds like a hard problem, by the way.

It is a hard problem, but it’s super-interesting, and it’s a lot about just measuring, for example, how many review comments we’re gonna get on a pull request, how fast it’s gonna get merged, what is the likelihood of a pull request getting merged based on its size, and making sure that, for different groups of a community, it’s not actually biased toward any particular group, especially not the employees, not the maintainers, not the broader contributors etc.

That is really interesting. So how does this differ from a company, from a product which is commercial?

The biggest difference is that the intent of an open source project cannot be easily captured. A company has a vision, a company has a mission, and ultimately, of course, a company’s goal is to make money. An open source project, depending of course on the nature of the governance, doesn’t have this kind of shape. It is typically gonna have a vision, it is typically gonna have a purpose, but even when it does, it is possible that the community will pull it in a different direction. And then, depending on the governance model, depending whether you have a BDFL, depending whether you have a company backing the project, you may have some constraint with regards to what is gonna be considered acceptable or not for the project. But the reality is that you cannot really plan for what direction it’s gonna take. And even more important than this, with the people coming in on the project and contributing to the project, you don’t necessarily know what are their intents; you don’t know whether they’re contributing as a hobby. You don’t know whether they’re contributing as passionate users that are excited about the project. Or perhaps they’re contributing because there’s a commercial interest from their employer on this particular project, and they have a roadmap or an idea in mind that is not necessarily transparent… And that’s also fine; this is what open source is about.

Okay. Fascinating. How do you reconcile a company that is built on open source, has an open source project, and also has a commercial product which is built on top of the open source project? How do you reconcile that? How did Docker reconcile that, by the way? …which I know is a very hard question.

[40:08] That’s the question that everybody is trying to answer, basically… It is an extremely tricky question. Did Docker figure it out? I’m afraid to say it didn’t, because the truth is the commercial success of Docker didn’t match the community success of the project, and the industry-wide adoption of the project. I wish I knew the answer, but I don’t think there is a clear one. A lot of it is about making sure that, as a company, your intent in doing open source is very clear, and that you’re doing it for a very deliberate reason, not for the sake of saying that you are open source. You have to be very clear, whether you’re trying to build a marketing channel, whether you’re trying to build a community, whether perhaps it’s also just a requirement of your segment, because all the alternatives are open source, and it wouldn’t make sense commercially to try and go to market with a closed source product. And you know, that’s all questions that are very business-specific.

To be fully transparent, at this point, when I’m discussing with startup founders and people who consider having bits of their product being open source, I tend to potentially push back more to ask “Are you really sure you need this? Are you really sure you know why you’re doing it?” Because doing it for the wrong reason can be extremely detrimental to the business. And that’s not to say that I’m not pro open source, of course. I’m very much pro open source. But I think it has to be done for the right reason, and it has to be understood that it’s a significant challenge, and it’s a significant challenge to do right.

So is Echoes open source?

No, in our case there’s literally no good reason to make it open source.

Interesting. Okay… Of course, this is a deliberate decision, based on what you’ve just said… Do you imagine yourselves going open source? Is that even an option that you may want to go back to? Or are you pretty set that it’s just going to be closed source?

No, nothing is set… Especially not for a company our stage. You never know, but again, we would need a good reason for having bits of the product be open source… And even when it is, it’s never gonna be 100% open source. Again, you need to have a commercial strategy around this, and it begs the question of where do you draw the line, what is the commercial value of the product, where does a project make sense, and being clear about this distinction. At this point, I don’t see a reason why we should… But you know, time will tell whether –

Things change all the time, yeah. Of course. You always learn something new, then it stops making sense, and then you just do the right thing, whatever that may be. Okay.

Yeah. In the case of Docker, Docker would not be as successful as it is today if it hadn’t been open source in the first place, obviously. What I think is extremely interesting with Docker - I think the open source model of distribution here worked so well that we got all caught into how successful it became, and how fast it became successful.

There was a situation where the project was so successful that companies would call to ask how they could buy, but we didn’t have anything yet to sell… And that is the whole paradox about this thing.

Yeah, that’s an interesting one. So I know that there is this InfoWorld article written by Scott Carey titled “How Docker broke in half.” And you wrote “Docker was a life-changing experience for me, and I wish things turned out differently.” Is this something that you’d like to expand on?

It ties back to what I was answering before - of course, I would have hoped that the commercial success of Docker would have matched the success in terms of the impact it had on the industry. What can I say on this…? There’s so much emotional aspect to the Docker story that it’s always complicated to be very clear about my thoughts there… But it was a fascinating experience, because we were really caught in the middle of a tornado where the project was massively successful, but you have to imagine that internally this was a startup that was extremely young. We had literally 50 engineers when I joined, we were getting pulled in every direction…

[44:08] Just to give you an example, the week that I joined Docker was my first week in the U.S. I moved from Europe to San Francisco to join Docker. On my first day I was told “We’re leaving for Redmond tomorrow. We have to meet with Microsoft for a partnership.”

Wow.

That was the unreal situation in which we worked in…

Your first day… Wow.

Yeah, that was my first week - flying out to Redmond to talk to Microsoft employees about Docker… Which I had literally joined two days ago. The whole thing was a tornado. And of course, you start thinking “Yeah, this might actually be a significant business. This might actually make a significant and durable impact on our industry…” Which it had. But the commercial success was not there, because we were probably not there fast enough compared to the adoption of the project… And yeah, of course, I wish that things turned out differently, because it was a very intense human experience; probably one of the best of my career’s, because I don’t see myself having this kind of impact again in my lifetime. I can hope for, of course, but it’s still a pretty unique opportunity.

It’s too bad that it didn’t get the commercial success it deserved. But that’s what it is. And again, I also said that this is not the end of the story. The company still exists, there are still good people working in this company, and for whom I wish, of course, the best possible success. They have a better focus now than we had, also because somehow the hype is gone, and that is not necessarily a bad thing. That means that they can focus on their customers, without the heat of the spotlight, without the heat of getting all the industry attention, and all the competitors, and all the cloud providers being super-interested about what you’re doing… So that might actually be still a good opportunity.

I know this is impossible for our listener to see, to experience. I’m going to try and do the best job I can of conveying this… But I could see the spark in your eye when you were talking about Docker. I could see a shift in the body language… And this is, again, impossible to capture. But I can tell that it meant a lot to you, and I can tell that there were some great moments, maybe some unique moments which were created, which will be impossible to redo… But it was special. It was special, and you cherish it as such, which is great to see.

I’m wondering, what would you have done differently? Do you wish you would have done something differently?

I don’t wish I would have done anything differently. I’ve done my best, and that’s absolutely the best I could do, and that’s pretty much it. The only thing I could regret - but of course, that would have been a different world - is having joined Docker at a time where I had more experience, and maybe more weight in the organizations, to try and influence it in a different way. But you know, that’s just wishful thinking, assuming that I would have done better, which is of course not proven, and that we’ll never know.

I think at this point truly the only thing that I care about is hoping to make an impact on our industry with Echoes in the same way that we managed to make an impact on our industry with Docker. And I know that may seem like a stretch, given that we’re talking about two wholly different topics, but the truth is I think the underlying motivation is not so far, and I think the underlying point is really the same when you look at it.

So what makes Echoes special, in your mind?

I think what makes it special is the fact that we’re actually trying to do something that is virtuous for everyone - virtuous for companies and virtuous for the engineers. And I think this is really the key here - not all tools are positives. And you know, there’s this motto that the tools is not gonna define your culture; I don’t actually really agree with this. I think that the tools you choose say a lot about your culture, and I deeply care about doing something that is positive, that is positive for everyone who is exposed to it. Of course, the engineers, but not only…

[48:05] And that I think is really why I’m putting my soul into this project, is to make sure that yes, we’re actually gonna be able to do something that improves somehow the quality of life of our peers working in this industry that is fascinating, that is challenging. I’m really attached to all those people, whom I know are extremely talented, and sometimes deserve that their organization would be better for them to deliver value.

So how would you like the world to help you with Echoes? In what way would you like to receive that help, and what sort of help would you need right now to make Echoes a success?

We’re super-early. We’re at a point where any feedback is good to take. Clearly, what I would love is for people to check our website and send over any questions, feedback, doubts they may have. I’m of course happy to give as many demos as I can, and get people started on the product if they wanna give it a try… But yeah, I’m deeply convinced that we have built something special; we’re extremely early on the journey, so it’s of course extremely hard for me to tell if this is gonna be a success or not. What I can tell for sure is that, again, doing my best, putting my soul into this, trying to have a positive impact on our industry… And yeah, time will tell if I’m correct or not.

Those are very good reasons, and I’m sure that there are many like-minded people which would like to contribute to that vision in some shape or form. So that’s what I’m thinking about.

Who would you recommend Echoes for? And by the way, it’s Echoeshq.com, not Echoes.com. I checked. There’s a great story behind that… Do you wanna share the story behind Echoes.com and Echoeshq.com?

I don’t know about the story…

Okay, okay. So I did a bit of research, and I was typing Echoes.com… Apparently, Adam Stanley is the owner of that domain. And that domain is registered in early January, 1995.

Yeah, I saw it was a pretty old website. At some point, if the company is successful, probably we’ll try and buy the .com. This is not my priority right now.

Of course.

I haven’t told you, by the way, about the reasoning behind the name, but… I’m a big Pink Floyd fan, so a lot of the projects that I’ve worked on are actually named after Pink Floyd songs or Pink Floyd albums. This is what brought the name Echoes. There’s actually an Easter Egg in the logo that refers to Pink Floyd, but this one is pretty well hidden… So far, only one person has figured it out.

Wow, okay. Challenge accepted. Anyone else that’s listening, if you wanna get into this… Okay. I like this game. I like riddles like these. Which is your favorite Pink Floyd song, by the way?

I think it’s Dogs, but Echoes is not far behind. Naming the company Dogs would not have been great, so… Echoes was a better fit.

[laughs] Yeah, I would agree with that. Even though it’s D and Docker, I can see the resemblance… But Echoes, I like it. And the signal, right? The signals that you’re trying to send - I think it fits really well. That’s fascinating, how things just kind of make sense in weird and wonderful ways… And you wonder if there’s more than just a coincidence. I always do that - is there something more? Am I meant to do this? It just feels like so – it just fits.

It feels the same in software. You know when things are on the right track. There is a magical thing, it’s the foresight that just happens when pieces fit together, and you can tell that it all makes sense and you’re actually on the right path.

That’s something which I’m constantly looking for… Like, when does it make sense? And you know it. It’s like a gut instinct. And when it feels right, and there’s so many – you have the signals, you have the echoes… But maybe you’re not picking up on them, or you don’t even know where to look. But we all know it when it happens, and we’re trying to do it again and again… And sometimes it’s elusive, but it’s so worth going for that. Totally, totally behind that.

Who would you recommend Echoes for, by the way?

[51:49] Honestly, pretty much any engineering organization that I would say is above 20 engineers, and needs to have visibility into how they operate. I don’t think there is a bigger discriminant behind this. What’s very clear in our conversations is that we’re not a good fit for engineering managers who are looking for surveillance. If you’re looking to see if people are busy, that’s not gonna help. We’re not gonna show you if people are busy; we’re actually not gonna show you anything about individuals. We’re only looking at things on a team level.

I actually think that users of Echoes have to be comfortable about the fact that this is gonna show transparency about how engineering is operating, and also about the quality of the management itself. Because you know, it tells more about the quality of the management organization than it says about the quality of the engineers themselves… Which I think is well overdue.

That’s the one thing which I really liked. Actually, one of the many things which I liked. First of all, Echoes never accesses the code.

Yes.

It can never count lines of code contributed or deleted, and that’s done on purpose… And I think that’s a great, great thing. The other great thing is about making this a shared field, where we all meet, and we can see how well the different orgs, groups, units interact between themselves. You’re trying to capture the interactions, which is really valuable, and I haven’t seen it done before. Performance reviews, and grading managers, and grading employees - that’s totally not what you do. How well do the different parts interact? Very valuable.

And I like how you combine all the things, the Why, the What is happening, the day to day… You’re literally solving, I think, a problem which I had, and that’s why when I reached out to you, I thought “Well, this may be it. This just may be it.”

So even though at Changelog there’s just a handful of people, would you still recommend Echoes for small teams? Three, four, five people.

Yeah, of course.

Okay.

We’re using Echoes internally, of course, to manage our own roadmap. You know, there’s this thing that if you’re very small, you are extremely resource-constrained, and that means that you have to be laser-focused. And one very easy way to be laser-focused is to challenge yourself and to measure how you’re spending your time, to make sure that you’re actually spending it on the right things. That’s what we’re doing internally at Echoes, that’s what other small companies are doing with the product…

I would say it’s somehow a different use case, because in this case you don’t have this very high level of certainty as a larger group what everybody is doing. But still, you get this data-driven aspect of your work that helps you reflect about how you’re truly allocating your efforts. And again, there’s only 24 hours in a day, and we’re all doing our best.

At the end of the day, the best thing you can do is just be deliberate about the things you do and the things you don’t, and this is how we can help.

Intent. Coming back to that - intent, vision, impact. All those important things; very good ones. I don’t know if this is possible, but I would love to see a screenshot of Echoes for Echoes. I would love to see that.

Yeah, I think we could do it. I don’t think there’s anything really hidden there.

Yes, please. That would be amazing - to see that, to have that visibility into how Echoes is using Echoes, to see what is important to you, what is the progress that you’re making towards that… Because I remember the screenshot that you had; I think this was in – actually, it was one of your tweets, photo 2, it’s a recent one, i’ll link it in the show notes. But to see the real one day, what it looks like - that would be fascinating.

So what comes next for Echoes? The next six months, what are like the big items on your list? I think list is a poor word, but you know what I mean.

I mean, there’s literally an infinite number of things I have in mind. Again, we’re trying to be focused, and that means we’re trying to listen to our users more than we listen to ourselves.

The most important bits right now are things such as being able to tie outcomes to metrics. We’ve talked a lot about how we allocate our efforts and the Why behind work, but if you want to measure impact, then you have to tie this back to observable results. That’s what we’re working on right now, to make sure that you can bind those intents to actual measurable things, and observe whether your team is having an impact.

[56:05] Other things that we’re working on are the very greedy, boring details of any early company; things like integrating with HR systems. Super-fancy, super-shiny… They’re the thing that every engineer is dreaming of doing… But still, it has to be done, because this is what the life of a company is.

And then where we’re gonna go from there in the future - again, tons of ideas; where the market is actually gonna take us is up to be seen, but we’re collecting a data that didn’t exist anywhere else, which is why we’re doing things in the first place, and I think there’s a lot of potential in this in a variety of different contexts. And the future will tell if there’s a market for it or not.

I’m really excited about Echoes itself - about the idea, about the person, now that I got to know you a little bit more… I can see so many similarities and so many challenges, and so many lessons learned… But also, I see the intent behind Echoes, and that attracts me. I wanna see what happens next. Six months from now, twelve months from now, where will Echoes be? Because the direction - it’s amazing. I love it. It has all the right ingredients… So what will actually happen? What delights will we have from you and your team? That’s what I’m looking forward to.

Well, me too.

I really want you to be part of Changelog. I would like to use Echoes within Changelog, so that we can gain visibility into how we do things, and what we do… Because as you mentioned, our time is super-constrained, and then my time is the most constrained on… I can count the hours that I can dedicate on Changelog infrastructure, on Changelog code in a month, so I have to be super-super focused. And what does that mean? What does my hour, when I spend one hour - what did I spend it on? And it’s not like the units… It’s whenever I did something, what did it contribute towards? Was it throughput, was it customer values, outcomes, whatever…? I forget the exact namings, but I’m sure that you’ll help me define them, and there are good examples to understand what is important and why those things are important.

And as a listener, if I had to take away one thing from this conversation, what would you like them to take away?

I think the biggest takeaway for me, and the thing that I hope listeners will agree on is that - I think engineering management overall is still in its infancy. Our industry is young, we’re still trying to figure out what are the recipes that work and the recipes that don’t. The one thing we know for sure is that as engineers, we’re working within companies to make them successful, and we care about having an impact. And this is way more important than those five minutes of developer productivity we can gain with this or that tool, or this or that thing.

And yeah, truly, I hope that the takeaway is really that the future of most businesses depends on us, and it’s up to us now to make it more efficient, and more pleasant for our industry.

I’m really looking forward to that. I’m really looking forward to what you do next, Arnaud. Seriously.

Cool.

And on that node, thank you very much. It has been a pleasure, and I’m looking forward to next time. Thank you.

Thank you very much for having me.