DEV Community: Mikhail Asavkin

6 steps to get your starship off the ground

Mikhail Asavkin — Tue, 08 Jun 2021 08:06:09 +0000

If you are a person of action rather than a person of words, I advise you to jump to the action points below and then come back here for the hints on how you can convince your team and your boss to make a radical change for success.

As engineers, we need to make sure we constantly increase the value we provide to the business.

We are uniquely positioned in our companies to champion change and make decisions that have a critical impact on the value our products deliver to the market. From the economic perspective, we exchange our time, the hours of effort delivering solutions for financial benefits, be it salary/bonuses, share dividends or a combination of the above. Business, on the other hand, exchanges your hours of effort into the increased value provided to the clients. The value that then is exchanged by our companies into money feeds back into our salaries, bonuses, etc. But hours of effort are not born equal, by making better decisions on how to use them, by mastering cutting edge technologies we can dramatically increase the value output of these hours and thus increase our own value for the business and inevitably our financial outcomes.

As we are on the quest of increasing the value of our time investment, we need to understand our products and businesses very well to make sure our decisions are always aligned with the value for the end customers.
But this is only the first step, there are many areas in our day to day processes that can be significantly improved if we think about them critically.

There is inertia in the industry making us do things in a certain way not because it makes sense in our particular case, but because it’s the ‘best practice’. Let’s look at a few traditional approaches and how they can be transformed.

Actions

0. From layer engineers to full-stack engineers

Many traditional technology stacks assume you have teams of narrow specialists, each working within their own domain, honing their skills in particular application layers like database design, backend or frontend, DevOps, etc. In order to deliver a change for your product in this setting, you need to involve multiple people even for a small feature, as mostly it will touch all layers. Involving them all increases the management overhead, communication hurdle, as they all need to agree, who does what, and this is a terribly cost-inefficient and frustrating experience for engineers. Today, we can no longer afford this, instead, we should all become full-stack engineers capable of delivering a feature independently, taking full responsibility and credit for its future success. Not only it greatly increases the efficiency but also serves as a huge morale boost, greater engineer’s involvement in the business value creation, improving the quality of decisions they make. It’s also much easier to track the cost per feature, and good product tracking allows you to finally do a proper ROI analysis on a feature level.

1. Full-stack friendly technologies

In the past, only a few could become full-stack engineers because it was notoriously difficult to equally master all aspects of the stack. Today, we have great technologies, like GraphQL, that allows us to work with data more easily from the frontend, eliminating the need for backend changes for every feature. Even better, GraphQL-powered BAAS services like Hasura or AWS AppSync now allow us to skip writing that glue code between data storage and the API, finally automating this boring process.

2. One language to rule them all

With the growing popularity of Node.js as an engine of choice for traditional and serverless backends alike in the last decade and JavaScript being the only language to build web frontend, it’s no coincidence that many teams decided to adopt JavaScript as the only language for their entire stack. And of course, they quickly realised that it doesn’t work on big scale projects and so TypeScript was designed to address that and delivered a huge efficiency boost (in terms of hours of effort and code quality).
It’s for this reason that we at Skychute use TypeScript throughout our famous Proptech stack.

3. Your user journey is the only thing worth testing 40 times a day

We’ve all been taught the value of TDD, unit and integration tests, however, your clients don’t care if the components of your product work in isolation. The value is in the user journeys, and this is what you should be focusing on. So stop caring about your code coverage and unit tests and spend all this energy on automated end to end tests mimicking your users’ behaviour as close as possible. When the QA is concerned, that is the place you should invest at least 90% of your code-driven testing budget.

4. Development experience matters

Engineers being your most precious asset, you need to make sure they have everything they need to work as efficiently as possible. Things like continuous deployment that runs all your e2e tests, automatic provisioning of the cloud environments for every branch that are exact copies of your production, project-wide automated linting and formatting rules are no longer luxuries that only big companies can afford, they are bare necessities today.

5. Culture of decision-makers

The designer’s adage recently popularised by Elon Musk says ‘best part is no part’. We’ve been trained throughout our careers to solve problems with code, but as engineers, our goal is to find the best solution, and often the best one doesn’t involve us coding something. Empower your engineers to make decisions on a bigger scale, encourage them to consider using readily-available blocks instead of building bespoke systems, or get rid of the system components altogether, thus reducing the cost of ownership.

And remember, you are not alone, and, whatever you do, the challenges you are facing are not unique. We have a great vibrant community of talented engineers who are always glad to help each other. Don’t hesitate to seek advice and help outside of your organisation and, most importantly, tell your stories of both successes and failures, so that everyone could learn from them.

Here to help

Whether you are an engineer looking for advice on how to increase the value you create for your company, or a manager looking to bridge the gap between the business and technology, I’m always happy to chat.

The evolution of the engineer

Mikhail Asavkin — Sat, 29 May 2021 03:50:57 +0000

In the Proptech world, we prefer the term “engineer” over “developer”. Initially, we had made this adjustment to avoid confusion with property developers and to build a context bridge for property people who are dealing with the construction and civil engineers every day.

For me personally, the engineer has an additional meaning, deeply ingrained from an early childhood spent in the USSR. My parents were engineers spearheading the country’s transformation towards the clean energy generation, and my grandfather worked on the majority of the Soviet space missions from launching the first human into space to designing humanity’s first space rovers that flew to the Moon the first Venus probe and later on building the first long term human habitat in LEO.

Soviet post stamp depicting the achievements of the robotic lunar exploration

Engineering is all about finding solutions in a very constrained and volatile environment, under time and capacity pressure.

We often take less travelled paths and go where nobody else has ever been. As software engineers, we need to make sure the solutions we bring and implement align with overall business goals.

Today, you can not afford to have engineers in your team who do not understand your business well

It’s too easy to fall into a trap of developing technology for technology’s sake, increasing the complexity of the systems you operate without any real increase in the value you generate for your customers as a business.

A couple of decades ago, a software developer could afford to learn just one technology stack and stay within that stack for the rest of their lavish career. They would be given very detailed technical-level instructions on what to implement and how, the majority of the decisions would have already been made for them.

Remember, they used to call themselves with these niche and now-obsolete terms like ‘Backend engineer’ or ‘iOS developer’? These days have long gone, my friends.

In the 2020s engineering teams around the world are responsible for the decisions that will shape future products billions of people will depend on. The work of software engineers should be aligned as closely as possible with the value our companies create.

Knowing one tool is no longer enough, we need to master a multitude of tools to pick the right one for a particular solution. And that goes beyond mastering multiple languages and frameworks: we need to become creative, finding solutions outside of our direct area of expertise.

Not every problem needs to be solved with code

Quite often the best solution would be in writing no code at all, but those solutions will only be visible for the engineers who understand the business, and we need to evolve or risk becoming deprecated.

What radical change can you bring to your company today to ensure you are delivering value?

If you are a business owner, you should find a way to invest in bridging the gap between the business and technology, that investment will future-proof your organisation, allowing it to thrive in the constantly changing world we live in.

As an engineer, you should spend more time understanding what your business does, what is the value that you create for your customers.

You should learn new technologies that would allow you to radically reduce the complexity of your solutions. One should always challenge the status quo.

Here is a couple of questions you can ask yourself today:

If your users are only interacting with the UI, can you re-architect your technology stack in a way that would allow you to focus 90% of the effort on the UI and UX? And specifically, you should focus on what makes up your unique value proposition.

Users don’t care about how RESTful your API is or what database you are using, they care about UX though. A lot.

What value does reinventing the wheel all over again bring to your customers? There are so many great building blocks out there so it’s much better to save your team some time by just adopting those and reinvesting this time to that one unique thing that makes your product great for the users.

There is no silver bullet

You will need to come up with your own creative solutions. But if you are looking for the place to start, at Skychute we found that by adopting technologies such as GraphQL-powered backend as a service (Hasura), we could spend 90% less time on the backend boilerplate and instead focus this energy back on making the great UX, putting our effort where our money comes from, launching products that users love.

Here to help

Put the effort where your value is

Mikhail Asavkin — Sun, 23 May 2021 03:06:59 +0000

Whether you are building your own products as a company, or build them for your clients as an agency, inevitably there are parts of the software that are considered to be ‘just necessary’ and another part that brings value to the end-users. In this piece, I’d like to talk about the differences between the two and look at some real-world examples where we can concentrate on doing what’s valuable versus what’s considered necessary.

First, why do I care? As a product manager, I want to make sure my products are as profitable as possible. In order to achieve that, I need to be able to project and control both the cost of change and the value that change brings to the end-user.

Having spent the last decade in this role, I have seen many instances where the change would only result in additional costs, but not in the value created for the end-user. Now, it’s one thing to pursue a product hypothesis, invest in a feature that has a negative ROI after implementation.
This is perfectly normal behaviour for a company that constantly tries to innovate, run ahead of the market and competition. Experiments are necessary and through those experiments, we will find very successful changes to our products at a cost of launching a few that are less successful and learn from our mistakes. However, often companies spend effort on changes that have no direct influence on the value for the end-users at all.

Your product, for example, may have a complex multi-layered architecture that has a high maintenance cost and a high cost of change. Every new feature you want to launch requires several kinds of engineers to be involved, each responsible for their own domain or an implementation layer. Every time you change something you pay this complexity tax.

But let me tell you something

Your users don’t care how many databases, caching layers you have, and whether your API responds within 15ms or 155ms. What your users do care about is how much value they receive from using your product, how great their user journey and overall experience is. Therefore, as a business, you need to focus all your efforts on what makes a difference for your customers, the end-users of your product. In most cases, the improvements affecting the UI and UX would have much better ROI.

Think about it

With a good UX improvement, you can influence the conversion rate, or expand your offering that affects the average order value or simply make the user journey so great that they never leave you reducing the churn rate, all of these are the multipliers in the LTV (user’s lifetime value).

You should find a way to invest as much as possible in the areas that increase the LTV and as little as possible in the rest and significantly reduce the cost of change.

Quite often it will mean radically changing the way you build products internally, covering all aspects from technologies you use to the business mindset and the kind of talent you retain in your teams. I’m not going to lie to you: the transformation is not going to be easy, but I promise it will bring great ROI and allow you to rise above the competition. As the first step on this path, you should check whether you are currently investing in things your users don’t care about, here are few examples to get you started:

Complex, over-generic architecture

Your users don’t care if you could survive the next 3 decades without changing the underlying architecture of your product, they do care about their monthly fee, which includes the complexity tax they don’t want to pay.

Solution: reduce the complexity by eliminating as many layers you have to work on as possible, ideally leaving on the frontend which is what your customers use every day.

Unit tests and integration tests

The users couldn’t care less if the building blocks are working in isolation or how well each of them plays with 3rd party service. Instead, they will leave you the moment they meet an obstacle in their journey in your product.

Solution: spend the testing budget on automated e2e tests which mimic your users’ journey as close as possible. Read more about testing what matters.

Time and the number of engineers it takes to implement a feature

Your users won’t pay you more for a change in the product because it’s more expensive for you to deliver it. They will pay you exactly what it’s worth for them and not a penny more.

Solution: move to a full-stack engineering approach where every engineer in your team can deliver any feature by herself independently. Read more about what talent you should invest in.

Expensive infrastructure

I don’t care how many different servers you run across the globe, I care about my data and your service being available to me when I need it.

Solution: move your infrastructure cost curve to closely match your usage curve with pay as you go models that serverless infrastructure offers. Avoid paying for server hours as much as possible.

Fancy development practices

Your users don’t care how agile, ISOXXX or CMMI- compliant you are, and what ceremonies you follow, but they will always abandon you for a competitor who delivers a better value faster.

Solution: focus on compressing the calendar time to deliver a feature and build your development process around it.

Here to help

Whether you are starting a new technology business, or struggle to grow an existing one, I’m always happy to chat.