Staying tuned to the context

I participated once on a project that stemmed from a startup but was in a very advanced state when I joined. I was tasked with advancing some functionality, and when I started it turned out that the previous version was built by a great engineer, with a track record of “great job”. Obviously I was happy and was sure that it’s going to be easy peasy. First glance at the code destroyed my peace, the solution was oversimplified, not tested, not documented and to put it gently; not easy to read . I couldn’t wrap my head around how a person with such a reputation could do such a thing. Very quickly I discarded the idea that he is just a fraud, but the annoying thought remained.

The “aha” moment happened when I talked over a beer at some integration party with other engineers who were working on this project for ages. I heard a number of monster slaying stories from the time the team was struggling to stay afloat and sell the product to anybody. Then it hit me (and I don’t mean booze :) ), the company was in a very different situation back then (when the aforementioned feature was initially built), then it was when I joined it. I had the luxury of working on a financially stable project, with well defined (and stable) requirements and pressure put on quality rather than time to market.

Thanks to this situation I started looking at other people’s work with more respect, because I learned that if I don’t understand something, it’s probably because I do not have the full picture. Even If I claim I do, the picture could have been different a year ago, when the company was struggling to stay alive, to get investors, hire engineers, or reach product market fit.

There is one more lesson here: an engineer must understand the context! When it is the first engineer in the team, it’s first priority is to deliver good enough solutions as soon as possible, or in other words get shit done. One might be great with cloud, algorithms, SOLID etc and still make or break the startup if she/he decides to put a delivery on hold, until there is a continuous deployment pipeline in place, for a feature that can close the first sale. One can be tempted to try this new shiny tech that everyone is talking about, just to realize it requires a week to learn and set up the thing, while no actual development is done. A week that could be used to finish the solution using the tech known to the team. Just to make sure, I am not making a case to not use any new technologies at all, but to be conscious about tradeoffs. From my experience if your project stays afloat, there will be time to upgrade it (when the context changes).

Staying tuned to the context can help avoiding mistakes, but it can also be a driver for innovation and efficiency improvements. In startups there are always problems that could be solved with technology, new software, or a fresh pair of eyes. For example in a B2B startup, with a long sales/delivery process a form of automation can speed up the process, thus allowing the sales team to reach more prospects and close more sales. Wouldn’t that be nice? :)

A final caveat is that engineer’s job is to MAKE STUFF. To understand the context, one practices active listening, connects with team members (not only from his department) and brings ideas. This is great, but it can backfire if such practices take over the actual work.