DEV Community

loading...
Cover image for 6 steps to get your starship off the ground

6 steps to get your starship off the ground

Mikhail Asavkin
Tech entrepreneur, growth hacker and space nerd
Originally published at read.limenutt.me ・4 min read

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.

Discussion (0)