DEV Community: Alex

How to choose tech stack for your new startup?

Alex — Tue, 17 Oct 2023 12:12:45 +0000

Why do you have a .NET system?

In Dodo, often when I talked about the tech, the question was asked - why is everything written on .NET? The answer was as if every time they were waiting for a story about comparison, objective reasons, performance, people, etc. And the answer was extremely simple and prosaic. The first 2 developers who believed in the project, knew .NET. That's the whole reason.

Now for me the question "What kind of stack to take in a startup" is relevant. What will be the scale? What kind of experience (domain and technical) would I be interested in bringing developers to the company? What scale of team would I even need to assemble potentially? And in what regions?

These are all relevant questions. However, they are relevant for the scaling phase. They lose weight when they start thinking about what they have "here and now". Launching a startup is a situation when you need to launch something as quickly as possible, test the product's fit as quickly as possible, to make 1-2-3 pivots to find something to scale. And so we look at the here and now.

You make a financial product, 99.99% of fintech startups are launched on Java/Kotlin (well, I think so, maybe the statistics are a bit different, but the vast majority are on them). But if a technical co-founder does not work with Java, but knows .NET, you can build fintech on .NET, at least the first versions, some services, but scaling and launching new products inside the company on Kotlin.

You make a corporate product for B2B, and it is clear how to make it on .NET, easy integrations, reliability, and security, but the technical co-founder knows Python. So launch the first version in Python and develop it. And then decide whether it makes sense to change the stack at all.

Cloud

But in the context of Google Cloud / AWS / Azure, everything is not quite the same. Everything depends not on your skills in working with a particular cloud, but on prices, the features of your product (and, accordingly, the resources you need), as well as the geography of data centers. While you are at an early stage and the product is small, changing the cloud solution may be easy, but at the stage of primary growth you will not think about it and will be hooked on one of the providers for a long time.

They all have their own startup programs for different amounts and when you get your first investment and connect to one of the programs - that's when you make your choice. Price, geography, and focus of your product are key criteria. For example, you are doing a startup and you will work with language models, compare the capabilities of providers in the LLM area and choose. Or you want to do a service for the Middle East, it's important to store data in the region, look at the geography.

AWS geography

Azure Geography

GCP Geography

Free Tier

In addition to choosing a stack and a cloud, there's another very interesting challenge. You are a startup, you don't have any money, and even if you do, you don't have much and it would be good to save money. Almost all services provide Free Tier, you can actually build a full-fledged product under Free Tier. The only thing is that it is easy to get confused in them and they are very different. Big kudos to the guys who prepared a great guide with information about Free Tier of different services, categorized.

Database on Aiven, message queue on cloudAMQP, Sentry for error logging, Grafana Cloud for monitoring, Mixpanel for analytics, and GCP for hosting with the first $2,000 credits before we even raise the first startup investment. Running a demo/mvp of the product, and spending $0 on services is more than realistic.

4.14.40.140. How Engineering Management changes based on team size?

Alex — Sun, 15 Oct 2023 06:38:32 +0000

It's not an IP address. It's not a random set of numbers. It's not longitude and latitude coordinates.

This is the logic behind the growth of leaders in Tech, which I see in my experience, the number of people he works with. At each new stage, the leader realizes that it is necessary to act differently, fundamentally different, and not just continue to do what was done before.

Stage 4

You have between 4 and 13 people on your team, including yourself. You can hold the context of each person's work history, and performance, know his emotional state, and notice any changes. You can easily help him to solve some problems, and make a development plan. This is the stage of a "team as a family". The main task of a leader at this stage is to be able to see problems for every individual and help to solve them. Manually.

You are like the captain of a soccer club, playing directly on the field. A mistake in your decisions can cost the team a match.

Stage 14

There are between 14 and 39 people on the team. Someone will face this stage earlier. This is where you realize that you can't keep all the context from every individual and you need to switch more to processes. You are bound to forget something, catch something at the wrong time, miss something.

First, you need help from your team members. People who know how to work with a small group, whom the team trusts as much as you. And teach that person to work 1:1 with people. Put him on stage 4.

Also, you start to think differently about systematization, and processes. I'm talking not only about development lifecycle processes but people management as well.

Communication. How to convey all the information to the whole team so that they understand it correctly so that they can ask questions, and influence the choice of movement. Do it through peer managers? Information can be distorted, it's difficult. You still need to be able to communicate directly with everyone but rarely.

We need to strengthen horizontal communications, to do more events where people can communicate with each other. For us, for example, DevForum is such an option. It is a weekly tech meetup where developers share anything they want with a team.

Interaction and processes. It needs to be systematized, there are enough people, and some of them may not know what the other one is doing. You start thinking about how to make everything work as one big mechanism.

HR. There are going to be HR complexities. You need a system again, so that everyone understands where to grow, what the company, the teams, and the product needs. You don't work individually anymore. You still feel the direct impact of your actions on the product and other people. You are working from above, looking at the situation from the outside.

You're a coach. You look from the outside, you see the process, you watch all the players and their interactions. A mistake in your decisions can cost a team a lost title in a season.

Stage 40

Oh, boy. It's a different world, folks. You've got 40 to 99 people and sometimes you catch yourself forgetting the name of that one developer. Heck, it's scary, like I'm going to lose contact with people (I seriously caught myself 3 times thinking I forgot the name).

More and more HR. Salaries, growth, everyone's problems, you already need a people management structure (did you notice we already have 3 management jobs on the opportunity list?). Most likely at this stage you will start building a performance review process in order to promote the best people.

Hiring. You start to realize that hiring isn't just hiring. It's a way to grow competencies for your team. Lack of SRE competence – OK, it is easier to hire than teach.

Leaders. They grow, and you get people who can work at level 14. And you might not be able to count the people at level 4 anymore. They're the ones who manage communications.

Decision Making. You teach others to make decisions as much as possible and put them in a position where they need to make a decision themselves, without your participation. You can review but not decide. You feel detached from them, even sometimes you don't realize that your actions led to something right, because they were done a long time ago and there is no emotional connection.

You still influence the global development of the product, but your influence is different. You need to give people the opportunity to grow as much as possible. You know you would do better, but you can't because your guys have to grow.

You're the general manager of a soccer club. You manage the strategy, you handle the transfers. A mistake will cost you a few lost years and a wrong strategy if you choose the wrong coach.

Stage 140

Vision and communications
The two are together for a reason. Vision and company and team strategy are always there, the question is how they are discussed. At the 140-person level, communications change. One word you say is interpreted in a dozen different ways, so I am constantly choosing words and wording, only now a mistake in them is even more painful.
Vision has to be delivered 10 times to make it fit. We did Q&A sessions talking about changes in IT, more about structure, and long-term vision and strategy. Often everyone already knows about them, and at the event, I draw some kind of line, to describe the current situation and where we are going.
And then on to Q&A questions. Any, the most acute, anything that is of concern. Openly, without secrecy. We have 180+ people openly discussing ANY problems and influencing the way we build the company. The most recent example - a couple of questions on organizational and salary grid structure and we change them immediately.

Decision Making
More and more things let go that I used to be involved in. This includes hiring, reshuffling, team splits, and partly structural issues. Structure, by the way, it seemed like you could never let go of it, but no. If there is a strategy, if there is an understanding of how to productize the interaction, many details are already solved by the teams independently. Where there are contradictions, we change the top-level structure. I am still involved in these issues, but much less. It's cool, it's a testament to the growth of people, they can now make their own decisions and are increasingly moving to the 14 -> 40 level.

Hiring
I am only involved in spot hiring where I have to look for leads not at the team level but at the big product level.

Is there anything that didn't change?
By the way, yes, there are things that stay the same. Two approaches:

Be where the problem is or where you need to grow. This is the best way to prioritize work.
If you don't know who needs to do the work, stick it in yourself. A good way, to help you find holes in the structure, and areas of responsibility and articulate where new hiring is needed.

Building a platform is not the same as a product

Alex — Tue, 19 Sep 2023 14:40:05 +0000

What software products do you use in your company? GMail for mail and Google Docs for documents, use Jira or another task tracker, Slack for messaging, Zoom or Google Meet for online calls, Miro for online whiteboards, Notion for internal documentation, github or gitlab for working with code, figma for design. Lots of different products and not always easy to integrate with each other. And it would be cool to draw a design in Figma and snap it right into Notion and write it into the team's working channel in slack.

There's a very cool article from HubSpot on how platforms differ from products. Here I'll give some basic thoughts on the difference between products and platforms with my reasoning and examples on Dodo IS.

A product is a set of tools from one company that comes in one generic package, solves 1-2-3 specific problems. When you have a large business, you probably have a lot of different products integrated with each other somehow. Sometimes a product has no integration with others at all and can only work "on its own," solving specific problems.

The key definition of a platform in the article is that a Platform is a set of software, an ecosystem of resources that works for business growth. A platform enables that growth by connecting third-party products and resources. The value of a platform grows as its capabilities and the ability to use a particular product within the platform grows.

Connecting External Resources

There is one important detail in this definition. It's not just about connected products, but resources in general. It can be outsourced or outstaffed, temporary or permanent, for a specific small project or a big job for years. A good platform is distinguished from a bad platform by the simplicity of this connection, the ability to work independently in your environment, interacting with the platform via APIs.

I'll explain with the example of Dodo IS, a long-implemented example with cash register plugins. Every time we go to a new country, we integrate with local check printers, cash registers, tax office. For the PoS terminal does not matter what country it is in, a check is a check in Africa. But the details of how this check is printed, what information is on it is different. We have created a system of plug-ins and now any such integration can be done independently of Dodo IS, interacting with it through the API contract. We can outsource any number of teams to implement country specific integration. This is how the platform works.

External product connectivity and flexibility

If the platform is the foundation of your business ecosystem, you don't need to be limited to one set of products - you can add and remove new applications and tools as your business grows and changes, without having to start from scratch or deal with complex migrations.

You're not limited to who develops the specific end products. You can do something yourself today and take a ready-made tool from the marketplace tomorrow. Or vice versa, start growing with a tool that is ready and available on the market, and then gradually move into creating your own product, which is better adapted directly to your business.

Dodo has examples of both approaches. The heart of the Dodo IS system is tracking. A system that tells pizza makers what pizzas to make, what ingredients should be removed or added. Tracking we have always developed ourselves, customizing it for Coffee and Doner, but it should be treated as a separate final product. Today it's part of the Dodo IS platform, but it's also a separate end product in the platform that can look like this today and change tomorrow or be replaced by another.

What does it take to make that flexibility work?

In order for it to really work, it's important to keep two key focuses in platform development:

API everywhere. Any interaction between platform products is done through APIs.
Data availability. Decision-making is built on data, the data that one product generates can be used by a dozen other products within the platform. Whether you give this access through the data platform or just expose the API with the data outward is your choice.

Three interview questions for developers. Soft skills.

Alex — Sat, 03 Aug 2019 17:10:22 +0000

I won’t talk about technical skills, I want to focus on soft skills and share 3 questions I’m using on the final interview with developers. It is not a typical question as I need to deeply understand the candidate, his emotions and the true reason for his decisions.

I selected 3 fundamental aspects:

motivation
how widely he can look at things
discipline

With the proper level of motivation, constant refill of his personal energy and discipline, the rest is already a matter of technology. The most difficult part of the interview is to find the right question to make sure the candidate will answer sincerely

Motivation
Question about 5 offers. It can additionally be made closer to reality if you find out how many companies the candidate is interviewing. No matter what, quantity is important.

So imagine the situation. All 5 companies have made a job offer. They are all different - in terms of money, team, scale, tasks, legacy code, technology, etc. Basically, you understand that they are good and you are satisfied. You need to choose from. And then…you call on all 5 offers and refuse. You call your current company and say: “Guys, I realized that I want to spend the next 5 years with you, I do not want to leave. " What happened to the company or you that you decided to change your mind?

The first reaction to this question is usually this: “Oh, wow. An interesting question, let me think”. The candidate plunges into deep thought for a few minutes. It is directly visible how the brain works.

Typically, developers work for 2-3 years in one place, rarely more, so the remark about 5 years is very powerful. The candidate focuses on those details that are critically important to him, those that are the root cause of dismissal. Correction of them should lead to the fact that a person does not want to quit. That’s how you can find the true motivation why he wants to leave the company and realize if your company has the same problems or not.

Widely
I have always considered it crucial that a person has hobbies. Not only in development, but this is also insanely fascinating activity, but also in other areas. Everyone has them. Even the most introvert developer has hobbies (plays computer games, watches particular TV shows, goes to the gym, maybe something else).

Here is the question to find it.

I ask how many years of experience in IT. For example, 7 years. Let's imagine that the developers have disappeared and are no longer needed in the world. Robots can write code and develop complex products. Moreover, everything, absolutely all other professions remained. What would you do? Or you can describe in a slightly different way that you have the opportunity to exchange your 7 years of experience in IT for 7 years of experience in any other industry, such as surgery or sales or design. What will be your choice?

The candidate must explain his choice. How did he decide to become a doctor? Why doctor? Often candidates share details about an interesting thing from Medtech, construction building, etc. They read articles about it, learn it just for themselves, it helps them to switch from complex programming questions to something else. It is just interesting, it is fun for many of them. It allows them to restore energy and be more productive.

Discipline
The most important thing. Lack of talent is offset by discipline and performance. Lack of discipline is not compensated by anything. Discipline is the ability to follow the agreements that you gave and agreements you accepted as a team, even if you don’t agree.

In order to understand this aspect, I ask the candidate to tell stories when he did not agree with the team, but made a decision and respected it. Disagree & Commit. Conversely, find cases when he violated his own commits. It happens to everyone, it is important that these cases are not frequent.

But even despite the simple answer to this question, it is necessary to dig the reasons. Even if a person did not comply with the team’s decision, there could be a hundred reasons for this and it’s important to find the only one due to which everything happened. Maybe he did not trust people? Maybe he was sure of his innocence and proved it by deed, working overtime? Maybe he thought it was simply not important? It shows you weaknesses you need to know about the candidate, about his true ability to work with people. Always dig into the reasons to build the whole picture.