Software + Management // by Mike Borozdin

At the center of successful product launch are customers who are happy, excited or relieved that something has been delivered to them.  Given that customers are such a key part of this equation it’s astonishing how often product development teams get so “visionary” that they forget the very people they are trying to serve.  Focusing on real people with real needs has a number of positive side effects, maybe the most important of which is your company survival.  According to CB Insights 42% of startups fail because they are solving a problem that doesn’t have a sufficient market need.  Here are some common fallacies that I have noticed through my 20+ years in software development:


Fallacy #1: No one will understand our vision until they see it!Some people have the belief that in order for someone to understand what they are talking about they have to show a working product.  This is symptomatic of confusing the problem and the solution.  While it is true that sometimes people need to …

About 20 years ago when I started working in technology companies I remember “the best” engineers had similar patterns:
-They worked crazy hours
-They knew the systems no one else knew
-They could react and deliver something faster than anyone else
You could always hear other employees say: “Bob is really smart, no one knows how to get anything done in system X besides him!”

This reinforced optimization around being the only person who knew how to do something in some part of the code.  That in turn reinforced job security and bargaining for those engineers, but also chained them to a particular system.  We had big code bases of C++ or Java code where some “Bob” hacked up features as soon as he possibly could.  “Bob” would have occasional nuclear disasters where he’d sleep in the office or through the weekend and then everyone would thank him for how he “saved the day.”  “Bob” sacrificed his quality of life to get praise when he hacked stuff up quickly and then the second time when n…

At Ethos we are building a distributed mortgage origination system and in mortgage there is a lot of
different user types with processes that vary depending on geography.  One of our ongoing discussions is about how much of the logic resides in code vs. being in a workflow system or configuration.  After researching this topic for a bit, I have arrived at a conclusion that the logic should live outside of code very infrequently, which might come as a surprise to a lot of enterprise software engineers.

Costs of configuration files and workflow engines First thing that I assume is true is that having any logic outside of the code has costs associated with it.  Debugging highly configurable system involves not only getting the appropriate branch from source control, you also need to make sure that the right configuration values or the database.  In most cases this is harder for programmers to deal with.  In many FinTech companies where the production data is not made readily accessible…

Over the past year I have been working on setting up an R&D center in Minsk, Belarus.  Belarus, like Russia has a strong STEM education and produces a good amount of talented software engineers.  It is clear that Belarus recognizes the importance of the technology in their economy but still needs some economic reforms to become a serious technical hub.


I stumbled across Minsk by accident.  While being of Russian heritage, I never had any friends or family in Minsk and have never been there before my visit last year.  The FinTech company I joined last year (Ethos) had a few contractors there who were working on one of the products.  My first goal was to figure out if committing to an engineering center in Minsk was worth the trouble.  The short answer is: yes.

Minsk has a number of universities that produce software, electrical and mechanical engineers.  There have been a number of companies like Viber who have large offices in Minsk and there seems to be a community of software e…

Congrats! You got a job at a promising startup, now you are in a boat with all the good and bad things that come with it.  There are no individual problems, there are just common problems with individual champions.  A tech startup is a band of adventurers that decide to go on a treacherous journey.  Unlike at a big company there is no redundancy in systems or personnel.  There is always more work than time and the infrastructure is nascent.  The phrase “this is someone else’s problem” doesn’t exist in this world.

Goals, people and systems change very rapidly, sometimes too fast to create a formal process.  Andy Grove writes about this type of environment in “High Output Management”

When the environment changes more rapidly than one can change rules, or when a set of circumstances is so ambiguous and unclear that a contract between the parties that attempted to cover all possibilities would be prohibitively complicated, we need another mode of control, which is based on cultural values…