Contract: Intrmodl a intermodal shipping company

26599BC8-76E6-444E-AB29-F16486B90457.JPG

Push to start

So the project started off for me when my friend Brandon Stewart at gnar.io needed some help with a new project he’d been working on. The company provides an intermodal shipping service, which basically handles the loading, unloading, and temporary storage of cargo shipping containers from cargo ships to trains and trucks. He was putting together an IOT solution to help the managers track what was going on in the yard by adding GPS-enabled Android devices to the vehicles and then feeding the information into a manager side terminal application.

mael-balland-p1u0pMSweb0-unsplash.jpg

Making Smart choices

It was a scrappy operation at the start with just me, an android developer, and a designer for a relatively large project, and I immediately recognized the need to outsource and hire additional help.

One of the key choices we had to make early on was infrastructure, where do we host our services (AWS, Google Cloud, or may haps Heroku)? Now conventional wisdom may say that AWS is the obvious choice in terms of price and market share, but the answer is more complicated than that. AWS is far cheaper, but then we need to deal with all the dev ops or infrastructure configuration/setup. Now I’m no expert in DevOps, I can get it done, but only after a decent bit of looking through documentation and googling. Alternatively we could hire a DevOps engineer but unfortunately like any good engineer they’d be hard to find. But by using Heroku we are essentially getting Experts in DevOps to help us handle the infrastructure, therefore freeing us up to focus on the application code. But what about the cost? Not a problem and totally worth it. The thing is using Heroku costs less than the development time cost from either spending the additional time figuring out the DevOps side ourselves or hiring an additional engineer. It keeps our application simpler, more secure, and more robust by knowing we’re relying on an employee called Heroku to get things done. Ultimately yes the running application cost on AWS would be a fraction of the cost of Heroku, but for RMS that’s the difference between a handful of additional employees vs a fraction of a handful of additional employees. The cost difference just doesn’t matter.

Responsibility to the team

Now of course we do need to weave together the custom code for our application and as skilled as I may be, I can’t do everything myself, we needed to hire on additional people. This involved a lot of additional steps from setting up the interview process to code reviews (particularly during the initial weeks) to keeping people motivated. And it’s this last point that I want to focus on. There’s a particular quote I read that I’ve always kept in mind:

If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

When you keep this in mind, you think the right way. For instance, I remember having thoughts like:

  • I think this task would be interesting for them

  • I think they’d learn something cool from this

  • This would be a nice easy task for a breather

  • This would be a nice hard challenging task for them

  • They should take time off to relax

  • I need to keep morale up

  • I want to make sure they feel like they’re opinion is heard

  • I want to make sure they feel like they’re part of a team

These are all parts that keep people motivated to want to do the work, just paying people isn’t enough of a motivator if you want to bring out the very best from the people on your team. It’s when they love what they’re doing that’s when you see the very best of their ability. That’s the responsibility I had being in a leadership position.

miguel-henriques-RfiBK6Y_upQ-unsplash.jpg

Responsibility to the world

But responsibility extends further than that, the impact this software has on the world. Because ultimately this project involved reporting metrics on workers, something that the managers will need to trust is accurate and features of which we will often suggest, design, and present. All of this has a huge influence on decisions for managers and workers. First off, if we have bugs in our code, we can get incorrect metrics, which is bad for obvious reasons. But let’s look at a subtler problem, how do we measure performance?

One simple way may be to just rank everybody by some parameter and the top X number of people are highlighted and awarded, but this creates problems. First off, it creates competition within the team, because only the best get rewarded. Secondly, it creates animosity, because people can feel like the high performers are making the rest of them look like low performers. Thirdly, they wouldn’t be exactly wrong, because managers could be looking at a chart and only see the top X performers highlighted and wonder to themselves why can’t everybody be like them? And this is all just because we subconsciously suggested this way, an Extremely easy mistake to make. An important thing to realize about building things is that inherently it involves designing things too, because unless they specify every little thing about what we’re building, ultimately we fill in the gaps ourselves, and as we’ve explained something as simple as highlighting/colors can have a huge impact.

In contrast, a better approach for this situation would’ve been non-acceptable, acceptable, and exemplary levels of performance with the dividing lines set by the yard managers on a per site level. This way it’s recognized that going well above and beyond is going well above and beyond and not the accepted norm. It avoids instigating competition and keeps expectations from the managers at a steady level regardless of worker performance. But again let’s keep in mind something I didn’t specify, should the non-acceptable performers be greyed out or highlighted red?

chris-liverani-dBI_My696Rk-unsplash.jpg

To good friends 🍻

And the final take away is about having good friends you can count on. Brandon needed help and called on me, I needed help (like A Lot of help) and I called on Gabriel Marques (shoutout to CTO of CareLuLu 😉), he needed help and called on a couple of friends he knew from back in the day in Brazil, and suddenly the Justice League was formed. It was a crazy and awesome adventure together and at the end of the day together we created something useful for one of America’s largest intermodal shipping companies.

timelab-pro-sWOvgOOFk1g-unsplash.jpg