The Clarifier

Meet Joshua Walsky. He was co-founder and CTO of Broadway Technology and came up during the dot com boom. Now he’s a Talentism coach, guiding the next generation of founders.

If you’ve worked in tech, you’ve probably met someone like Joshua. Exceedingly smart, exceedingly talented, and digging an exceedingly big hole for himself...

Like many technical leaders, his views on management have evolved dramatically since his early days as a software engineer. He used to believe that he was the one who should solve the problems so others could focus on execution. Through coaching, he came to understand the unseen cost of failing to create space for emerging engineers to get reps solving problems themselves. By unwittingly under-investing in developing his reports, he “borrowed against the future”.

Joshua devoted nearly 20 years to building Broadway’s offering and a team of 230+ people spanning five continents. He also helped raise $42M in strategic minority funding to accelerate growth and eventually negotiated the sale of Broadway.

In this episode, Joshua describes a painfully common pitfall in management - unknowingly limiting the development of your people - in a way we’d never heard before. Whether you are managing or the one being managed, we hope Joshua’s story unlocks learning for you too.

Note about this episode: 
We love the ideas Joshua shares here. There are parts of this episode, however, where we don’t love the sound quality. In the spirit of not letting perfect be the enemy of good, we wanted to share this episode because Joshua’s words are so powerful.

Learn more about clarity coaching at

What is The Clarifier?

We take a close look at your toughest moments at work and turn the discomfort into advantage. Learn more at

Welcome to The Clarifier.

Where we take a close look at our toughest problems at work and turn that discomfort into advantage.

In this episode, you get to meet Johsua Walsky

He was co-founder and CTO of Broadway Technologies. At heart he is and always will be a software engineer.

I want to solve the hardest problems. And I want to solve them myself. Yeah, I want to do it and feel the feedback from doing it right.

But as his company scaled, he still wanted to be the one who came up with the solution. It got hectic.

I just remember one night, after months of phone calls, I was sitting out in my bedroom and the thought crossed through my mind Ilike, “I have a camping tent in my closet. I could just grab it and go. No more phone calls, throw my cell phone in the water, just gone.” And that was because I was, you know, wearing so much of the risk and had created a situation where, you know I believed I was the one to solve a problem.
Through coaching, he came to understand what felt wise and virtuous actually narrowed what he and his team could achieve together. In order for his team to excel, he needed to revamp his approach as a manager.

I’m so grateful Joshua is sharing his founder journey with us today to explore the hidden costs of failing to delegate and the problem with trying to win by coming up with the answers yourself.
Joshua has worn many hats. But throughout his career, he has always identified first and foremost as software developer + software engineer. Engineering culture makes sense to him.

What drew me to engineering was problem solving. Getting my hands dirty, taking things apart, figuring out how they work, put them back together, dealing with the parts that were now lying on the side that should get put back! But it's something that I really enjoyed.

I had a particular interest in software and computer science and some of that was related to when I was going to college, what was available and what was exciting and new at the time.

Who were some of the people you looked up to? Who were the rock stars or the idols of the tech world at that time?

I hate to date myself but I graduated from college and in the dot-com boom. Computer engineers and future scientists were really coming into their own at that time. I mean already there was this idolization of people like Bill Gates, a software engineer who founded a company. You know geek chic was starting to be a thing. I had classmates that had gone on to found dot-coms that you know went public in the dot-com boom and that was happening right next to me! Not only was there this great excitement around engineering, I personally found it extremely interesting and fulfilling and the kind of problem solving that I liked. I saw, for the first time, engineers could be rock stars. There was this public attention about what was going on with the internet and hardcore engineers were heavily sought after. And the more hardcore, and the better you were at engineering, the more excitement there was around you.

This push to “be the best” was enthralling to him.

The idea that I could solve a problem that was either known to be hard or that other people couldn't solve was just very exciting. And it really was being up for a challenge that was known to be difficult and known to be distinctive. I was drawn to that.
After college, he went to work at Trilogy, a software company. Their tagline was literally: “Only the Best.” Joshua knew he loved tough computer science problems, but Trilogy exposed him to business entrepreneurship for the first time. And he liked it. He worked with a small team to build a new business selling cars online, which at the time, had never been done before.

We were given the opportunity to take business risks and do things that you know. Would be perceived as crazy twenty years ago, you know as literally kids out of school. We were launching a business that had a tremendous need for capital and was spending that capital. We were selling cars. In fact, we were selling cars at a loss. You only need a small fraction of a percentage point before that becomes very meaningful. We took a shot and we worked hard. We raced to reach deadlines. We met some of those deadlines. We were selling cars without really having a complete background in what it would take to run our business. But ultimately we saw it as a challenge and we were going to tenaciously pursue that challenge until we couldn't anymore. There was no giving up.

There was no stopping. This was our goal and we were just going to go as hard as we could until it was done or someone pulled the plug on.

Joshua and his peers are grinding hard,working 80 hour weeks, essentially running a startup inside a larger company. And their work is getting noticed.

We're getting our launch. We're getting customers. We're getting accolades within the organization. We're getting people given to us to like to grow the company we're getting increased funding - that is building both confidence and ability to be able to do it. As well as feedback saying hey it's good to do this. This is how you succeed both as an individual and as an organization. You know, solving these problems yourself hands on figuring it out is a good thing.

But over time, the nature of the work shifted.

So the dot-com boom was followed by the dot-com bust. so it got to live through the dot com bust and actually experience a different side of business and having to make some of those hard decisions saying wait. We don't have the funding. We used to have. All of these you know it gave me a perspective on this run fast, go hard also has you know potential future impacts that you that you need to to manage. So went through the boom, went through the bust. Ultimately the parent company decided they needed to wind down the investment.

Following that I went back to school and got a masters, connected up with one of the other people that I had met through Corridor, Tyler, and we ended up founding Broadway Technology.

It was very much an engineering focused organization. We were going to build some of the hardest software we could think to build and sell it. It was enterprise class.

And what did it do?

Front office software for large scale financial institutions. So I'm sure the audience is like what in the world does that mean!

Is there a “click more” explanation you want to give us or should we leave it at that?

It is the software that is managing for a large scale finance institution like a Barclays or Goldman Sachs or Bank of America. It is what is managing all of the transactions for their trading desks, at enterprise level with large scale customers. It's dealing with compliance. It's dealing with transactional courting. It's dealing with market data. So think you know billions if not trillions of dollars worth of transactions, extremely high frequency. High degree of correctness, high degree of complexity. Some of the most complicated software and complicated engineering we could think to get involved with and we said, “Oh yeah, let's do that one. We can do that.”

Yeah, well I'm sort of hearing a theme here around being able to solve the hardest problems being a source of distinction and value.

And pride quite frankly.

Sure. So you finish your master's degree and you reconnect with Tyler. You craft this idea for Broadway and then tell us a little bit about starting off as a co-founder. Was it similar to what you had been doing inside of Trilogy? Where you just lined up the hardest problems and solved them one by one? Tell us about the experience of that.

I suspect a lot of engineering led organizations early, the focus is to get the products to work. You know, solve the problem. It was very many hours solving problems for these financial institutions.

We're going to work very closely with them and we weren't going to quit until it worked. There were long days on planes. They were actually out in LA so I spent a lot of time commuting between Boston and LA, which is quite a commute.

One of the things that really surprised me is that I wasn't the only crazy person who did that commute every week! I would be there for a 6 am Monday morning flight and there were like 5 or 6 of us and we were there on line every 6am. I was, “You guys are all crazy. We're crazy!” We'd fly back on Friday, same set of people. But it was very much hard charging, you know, “We're going to solve this. We can do it. No one else can. This is a problem that if we can solve, there will be value add and we can build a company.”

While Joshua is building a culture that places a high value on solving the hardest problems, he’s still seeking the thrill of solving those problems himself.

I would hazard a guess that it's like mountain climbers. There's only a few who've climbed the big mountains and they know they've gotten on top of Everest or whatever, when not everybody can do that. They were able to achieve a thing that is distinctive. You can probably hear it in my voice right now, I'm drawn to trying to solve those distinctive problems.

As they earn bigger and more complex problems to solve, Joshua has to build out his team. Which means he has to manage other people.

There's a point in one's career in engineering where there's potentially two paths. There's, “Do I stay an engineer and go left, or do I take the right fork and start
managing?” And look to be a leader of the organization through management. You can obviously lead as an engineer, it's a very different kind of leadership and at some point you can try straddling these two for a while, but at some point you need to decide.
One of the things that as I look back I realize some of those attributes that make one excel as an engineer because it's not just about coding. When I first used to pose this fork in the road, I thought it was about time because it took time to code, right?
You didn't have the time because you need to spend hours and hours debugging and thinking about how things were built. So I thought it was about time.

There are some of those things that make one excel at engineering that actually become problematic when you start trying to manage people. And that's one of the insights or hindsights call it. You know, recognizing those things that I love doing that make me good at engineering actually ended up being, at some point, counterproductive. And I tried to apply those techniques as a manager.

As a fun little game, I’d like for you to guess - right now in your mind - how many direct reports Joshua had at Broadway. Okay, do you have it? 35. The correct answer is 35. At one point in time, he had 35 direct reports. His impact on the organization was pretty profound.

At first, I found my desire to jump in and solve the problem was beneficial. And being part of a team, I had more people. There's more time so it wasn't just about you know in my head it was well, now I can solve the problem and instead of me having to spend three weeks coding the problem I just solved.


There's other people to help with that. So in some ways, it was just a lever on solving the problem. I didn't have to - you know the details are left as an exercise for the reader, right? I got to solve it. That level of analysis was very exciting.
But what I didn't see was that I took away the opportunities for other people to solve the problems. And one of the things that makes someone better at solving problems is practice, just like anything. It's practice. So. As a manager, being one of the key problem solvers prevented those people who are still learning, from getting as many cycles as they needed to really excel at that activity and that was the piece that I didn't see.

What you're saying makes sense, right? If you're the one solving the problem, even if others are involved, you're still getting the practice. You're still getting the learning and it might feel good because, helping others who might be stuck without you. The team's probably getting to an answer faster than if everyone was left to their own devices without.

Folks are probably enjoying spending time with you and getting attention from the boss and so it all kind of feels like it's going well. What was it in that context, where everything seemed to be going well, that kind of had you stop and pause and say, “Wait. What's maybe the second or third order consequence of my implicit - maybe even unconscious - choice to have my hands all over these problems and be the one solving them?”

Yeah, so I think you also are making a great point. It was clearly a positive feedback loop. Everything seemed to be working great. It was not obvious to me or the team or or very many people, the deficiencies with this solution.

It was working and it's not like there was an Icarus moment where this structure got too close to the sun and our wings melted and it all came crashing down. It was more me looking at it in hindsight with a different lens that had been provided to me. What is the potential of the people you will be able to maximize - I absolutely hate when people get called resources, but I'm about to go do it. Were we able to maximize the intellectual resources we had? I think in the short term we were, but in the long term we didn't and I didn't help encourage them to grow (the next set of problem solvers who were going to be as good, if not better than I was) by, in some ways being so involved and getting all of the practice. They didn't get as much practice as they could have if I could have increased their learning faster.

I think managers often face this choice: Should I do it? Should I tell them how to do it? Or should I let them figure out how to do it on their own? And in the short term, doing it and telling them how to do it, usually gets to the required end result taster. How maybe now in retrospect or at the time, you could guide managers to think about that tradeoff right? Because it's not always obvious. I don't know, if you were trying to apply some financial calculus to it, there's probably some discounted cash flow or net present value or something like that!

Yeah, a very complicated optimization problem! I'll write that down on my list of problems to solve one day.

But it's not obvious that the right choice is to step back either. So, you know you're talking about reflecting in hindsight. Do you think you did something wrong or do you think you did what was necessary in the early days of the company to get it off the ground?

I think in the beginning it was probably more necessary for longer than I continued to do it. Does that make sense? Because it's not what is necessary. What are the risks of not doing it this way? And you know the tighter the room to maneuver, the less operating space you have, less margin, less people. You know, the more critical the deadlines probably more important that you leverage all of the experience of the best problem solvers at the moment. But also recognizing that comes at a cost of not giving the new problem solvers the reps to become the better problem solvers in the future. And I didn't think about it that way. I thought about it only as, “Well, this is the problem. We need to attack the problem in front of us as aggressively as possible,” and never thought about what I was borrowing from the future.

And part of it was because I was so excited about the problem, “Oh this is a problem. Let's go attack,” but it wasn't even that I considered it and was like, “Nah. This is more important.”

It wasn't even a thought. So one of the things that I think about in hindsight and then I think you know, makes sense to consider in those decisions is, “Okay, we're doing it this way and these are the tradeoffs. I'm going to make this decision, recognizing that that is going to borrow from the future.

Not just, “Oh, we're going to solve the problem now but purposely intentionally we're going to solve it this way because we want to get these third and fourth order effects”.
This challenge comes up all the time when I’m coaching founders. “How do I deal with the screaming problem in front of me while simultaneously considering the impact my choices will have for me, my team and my organization well beyond this quarter? What makes sense given my short and long-term goals related to the health and resiliency of my organization?

I remember a project that was with a European client. And again you know I had very much taken a lead role in that project and direct hands-on responsibility. You know, being a european client when there were problems they were in european hours. So I'm getting phone calls at 3am in the morning on a routine basis.
You know it's not clear whether or not we're going to get the project done on time. There's big deadlines. There's a lot of pressure and I'm wearing all of this pressure right? And again, there were great people around me but because of not encouraging them years ago and giving them the opportunity to learn as much and then as fast, they were not able to contribute as much at the time I needed, but I also didn't realize that that was my fault: I didn't set them up

It wasn't that I also hadn't given others the opportunity, in my heart of hearts I believed that I was the one to solve it. I'm an engineer. I solved a problem. I was the one to solve it because again, if we go back to that fork in the road - I now realize as an excellent manager, we describe it as “they achieve things through the work of others.” That is exactly opposite from, “I'm the one to solve the problem,” and again I had taken that fork on the road. I'd stopped coding ages ago. But what I hadn't let go of was I’m the one to solve the problem.

Today as a coach, how do you use that experience to help, whether it's founders or engineering leaders, recognize that really implicit belief, “I'm the one to solve the problem,” and maybe a correlated belief, “Other people aren't ready or good enough.” How do you recognize when that's coming up and how do you help them with that?

Working with newer founders is really just exposing this perspective and saying, “Hey, you need to think about this. Those things that made you great may actually be liabilities for you now in this role. Does that mean that you shouldn't do the role?. No not necessarily but you need to be aware of it. Does that mean that maybe someone else should do that role? Maybe. Because if you really love solving problems, you really love coding…

The biggest thing that I learned from having the coach, I think, it’s one of the things I love to pass on is being purposeful and thoughtful and aware. Don't make a decision. Don't make any implicit decision. Every decision should be explicit and that requires a certain set of perspectives. And you know, being aware of blind spots. For me this was a huge blind spot. I didn't know any of this stuff existed.

So I’m back to your question. How do I help people that I’m coaching? It's really trying to expose this question. You need to solve this problem or this problem needs to be solved. You want to solve this problem. And it's not that one answer is wrong or right, it's that the answer just should be purposeful and intentional.

You mentioned that you had a coach. I think it was a Talentism coach, right? It sounds like your coaching journey helped you see some costs and some trade-offs where previously they were hidden that then became part of your explicit decision making. “Oh, do I want to solve the problem myself and get the short-term reward or do I want to let others solve the problem and get the long-term reward of training and evaluating tomorrow's leaders, tomorrow's problem solvers?” So I'm hearing that that's kind of what came out of it. Tell us about the experience of it. How did you start to see that with your Talentism coach?

Yeah, well I think one of the biggest things that the coach brought to me was very much a different perspective. And recognizing that I was interpreting the world through my perspective, through my own narratives. That wasn't the world - that was my view of it. I was in a system. I was contributing to the system. It was perpetuating and it was, you know, very hard for me to recognize that in it. Obviously you know, I was busy. We were succeeding. You just kept going and going right? And you know, having the coach help me step out of the system and say, “Hey, think of yourself as an actor in the system as well as observing the system.”

The only way you can change a system is by your own activity. So you have to observe your activity in the system and the coaching really helped get me that perspective. Then having the responsibilities of being an executive in the organization, I obviously had greater ability to affect the system than others, but even that awareness - we used to say “responsibility is taken not given.” I'm sure you've heard that a thousand times if not more.

Was that an important learning for you about whether you were creating an environment where others could take responsibility?

And the reason I brought this up is I realized one of the things. Well, I would say exactly that, “Hey you want this project? Go take it.” I also realized that I was actually in some way standing in the way of that because taking it also means taking risk.

There's risk associated with it and the other thing that I think is probably more so as a founder, is growing risk aversion as your level of success increases. I've heard it said about an entrepreneur that they’re not really a risk taker. An entrepreneur is someone who takes one risk, and from that point forward they spend the rest of the time protecting that. And you know, whether or not it's true, it definitely spoke to me.

Yeah, yeah.

You know, the company got bigger and people and projects. You know, there was just a growing risk aversion and that, in some ways, stood in the way of making this decision. Because we don't want to put this thing we’ve built at risk. So in some ways, there are compounding factors making that very challenging.

It's one more way your brain tells you, “I am right and justified in being the decision maker here.” That's safer than taking the risk of giving others the chance. So, what happened with Broadway?

In 2020 Broadway went through a series of M&A transactions and had a very successful exit. You know it gave me the opportunity to be in a new context. And that new context really helped me reflect on everything that had gotten to that point and what we had created. And in some ways helped me you know, continue my next journey of trying to figure out how to best help the next set of entrepreneurs.

What’s something that you want to make sure that the founders and technical leaders that you coach, really understand?

Be aware of the shadow you cast and how it contributes to your own perception of the people around you if you think they're not good enough, is it because they're actually not good enough or is it because you're standing in their light? Chances are, it's a little more the latter than the former.

A lot of software engineers are treated as the talent of their company, right? And they perceive them as such and I perceive myself as such. Those then have impacts as you go try and be a leader and build a company and being unaware of those puts you at a disadvantage.

At least be aware. Be aware of the impact. You know you may think you're great and I certainly thought I was great. I still think I'm great! But I also need to recognize that a lot of that was the system that I created. I got the reps I got the chances that made me better. Yeah I was in some ways better at it because I took all the chances, I took all the learning. That wasn't something inherent to me. That was the system and the position I was in. So to be purposeful and understanding about those things - it will give you the opportunity to be able to do more, but it may not be yourself. It may be others.

Oh that last sentiment was so powerful. I just want to sit in it for a minute. Being aware of the system you're creating, that is maybe giving you the preferential treatment when it comes to reps and building expertise and building credibility kind of becomes self-fulfilling, right? If I'm the one with the most expertise in the room, I get the decision, I get to compound on that expertise because I keep making the decisions and learning from my own track record. And then also recognizing, “Oh at a certain point. That's really limiting. That's really limiting in terms of what I'm going to be able to achieve because the only expertise I can deploy is my own.”

Absolutely. Exactly. And it is fundamentally limiting and one of the great things about companies is there doesn't need to be a limit. It's not like professional sports, right? Where there's a closed game and either you're winning or the other person is winning.

When it comes to building an organization and helping people excel, the more the better you know? I can be good at it and this person can be good at. You know, those with the opportunities make space and really make space. Not just say they're making space.

These days, Joshua is building out technology solutions for Talentism - he has to get those engineering thrills somewhere, right?

And as a Talentism coach, he helps leaders spot the unseen risks that could restrict growth.
And be more intentional with their choices around management so they don’t ponder grabbing
their camping tents in the middle of the night and leaving it all behind!

Big thanks to Josuha for sharing part of his founder journey.


If you relate to anything Joshua mentioned in this podcast, or want to learn more about how you can be more effective in managing your team, I invite you to have a chat with someone at Talentism.

Drop us a line at and schedule a 30 min conversation with one of our coaches. We want to hear from you.

You can learn more about how we guide our clients at where we share our insights from serving over 800 companies.

If you have a leader you’d like to see featured on this show, or a topic you’d like us to cover

Email me at

This episode was produced by John Hunter with story editing by Jessi Gormezano. Special thanks to Greg Kim, Rachel Kitto and Rocio Gonzalez.