I know it seems a bit like we’re on a samurai theme here… but Ronin is the Japanese word used for Samurai without a master. This is another great must see movie with several startup, entrepreneurial and software agency like lessons, reflections and moments.
WHAT DO YOU USE SCENE
There’s a special kinda language or verbal protocol amongst nerds… what do you use? Everyone trades tools, frameworks and programming languages as a rite of passage, like badges earned thru multiple missions in life. You’re good at x, you can do y, Z is da bomb. In classic response however Sam cares little. The “tools in the toolbox…” sums up my view of it as well. The tools matter less than the what we’re doing and why for the mission at hand.
All too often we get hung up on a technique or way of doing things as if thats the measure of doing things. The trend of agile everything is a great example of this. What you code in matters less than what you manifest as a result.
WHAT’S IN THE CASE SCENE
Sam presses to know what’s in the case. Its a simple question. Not getting an answer sets him off. This scene resonates with me greatly as often we’re asked to build things we don’t exactly understand. Often in software development we are pressed into different roles- the role of a mercenary, we’re asked to care little about the why of something and simply do it, and the role of a partner or product owner or founder, asking us to understand the biz, the biz model and more.
Like any good get’r done team, we’ve done both.
Mercenary work is simple and explicit in many ways but its akin to Sam’s moment of “if its gonna be amateur night..” out burst like moment. Like its simple, you want that goal and you don’t want to explain why, not a problem, pay the price.
I’m not advocating either role really. Most of our clients are partners, we’re part of their teams, we’re part of their startups and product missions and goals. Its rewarding work. Yet over the course of 10 years of doing this, I’ve been the mercenary role many times.
I’ve always been a proponent of clarity. Without it, you never know what is happening or if you’re on the mark or not. But as a biz owner i’ve been pressed to overcome without specific clarity. Which is funny cause you kinda invent clarity needed to press on. In prototyping the only clarity that matters often is the ability to overcome regardless. Like I don’t accept technical or code challenges typically. I view everything as doable, so as a team runs into “we can’t do this” like moments, I simply rewrite the query that got the action started in the first place.
The takeaway here is that these roles will happen often, even in a startup you’ll go from a we have a why and here’s why and this is what we need to do and why, and yet you will experience moments of dude just do this and stop asking me why and do it. Just have to embrace the flow basically, kinda happens with anyone pushing the envelope to do things really.