How to build a strong team as a business asset while developing the product?

All of this is from my personal experience. I personally executed all of this as a technical lead while working at startups and huge corporations corporations running at billions of $.

I started with tech at a very early age and now counting more than 2 decades. My main interest always was and still is about value delivery with tech as a tool rather then tech itself. What can you do with this magical thing called “internet” ? That is the question.

Enough about me, let’s roll.

First of all — what’s the goal?

Tech development goal is not writing code, it’s about the business around it. Business must resolve real world issue for the user, usually — some human. Everything starts from this, not code, not hiring developers.

Second step is to make a design.

Once goal is clear, it’s design time. In some sense — document through designer what business people have in mind.

Development is much more expensive and time consuming process in comparison to designing on Figma or similar tool. People in the company who preferably are not too technical but who knows best the issue business needs to resolve needs to work with designer, so designer could provide visual representation of the vision business people have.

This will be crucial communication step during software development but it also helps to understand how exactly solution will land. It’s helpful for business people to see what they are about to create and discuss it once more. See details which they possibly missed when were thinking about broad picture of the end product and possibly gather initial feedback from actual users.

3rd step — start from tech lead.

This lead will have to put your devs in line. This is a more broad challenge rather then just writing a code. If you have great technical leader, you will be able to save money on individual developers & create devs team as an asset.

This is someone who has as much experience as possible. Someone who can talk about the software development as a business asset — business goals, devops & infrastructure, backend, api design, database patterns, frontend, user experience, developer experiences.

To get such experience it takes usually more than a decade, so look for someone who has track record of building software for a long long time. Someone who did 4 projects and is in IT for 7 years probably will be a risky bet, even if it sounds “a lot” for many.

4th step — the technical stack.

During this step you talk with tech lead to every detail of your business goals. Understanding why company is trying to build what it is trying to build is key here. If your tech lead doesn’t care and want to go coding immediately, probably you should go back to step 3 of picking the tech lead.

Once tech lead understands how your business runs and what is the vision, priority and goal of it, tech lead will be able to start shaping the technical stack.

Starting from the backend. Backend is the biggest risk factor in software, it’s the place where all your data and access lives. Mess it up and you end up looking at your private data leaked, corrupted data and other bad situations.

Issue on frontend will cause a bad day for acustomer and support team, issue on backend can bring the company down.

Once rough technical stack is established — language, database, infrastructure, main building blocks — broad technical design, now time for technical design step to go a little bit deeper into how all of this will be executed and ensured to be working with highest chances of success.

There are always bottlenecks and risks of things going wrong in software.

It would be foolish to hope you will be able to fix everything upfront, that’s never the case, but what you can do is try understand your shortcomings and identify those, so when you will approach having the bad day, you would know why it’s happening and what needs fixing.

When you know why, it’s much easier to find solution which fits the situation.

This is the moment when your tech lead experience will shine. Target is to find a balance between over-engineering and under-engineering. Between fixing the issues on hands today and fixing something which may happen in a future. Between optimisation and progression.

5th step — the proof of concept boilerplate.

Now your tech lead knows what’s the goal, there are a bunch of ideas how to execute the project. Now it’s time to code. Your tech lead should showcase how all the things may work. This is not full code with perfect everything, but rather some test runs, proof of concepts. Some boilerplate. Developers who you will hire will jump into team and they will have to get training and guidance.

Guide your developers by showing how it’s done. Provide boilerplate, sample. Git repository should be ready during this step, some minimal CI/CD pipe to run at least 1 test or check of some kind, maybe types check or formatting of code. Some basic components of the tech to showcase the code.

6th step — documentation & onboarding material

Hopefully your tech lead has experience onboarding people and training them, if not, you should consider if did a good choice on step 3.

Now it’s docs time. I found it most useful to have “rules” defined as documentation somewhere — how we name things in code, how we structure those, what’s the formatting. All the basics which apply to all the code lands there.

About the conceptual things — like how we do the tasks planning, execution & review. How CI/CD works, what are the recommended tools and software. This usually is better in video format. Your devs already have stuff to read about your code format & naming convetions in documentation, so keep a balance between what content they will have to consume through text and what through video. It depends from project to project.

Pro tip: Default to text where precision is required, default to video where you want to explain concept or provide general guidance.

7th step — the issues tracking & communication

Business people and tech lead — all work together to find out the tools for issues tracking, reporting, metrics. Business people need to be part of this process while they will ask for performance metrics and will want to be able to at least see and overview how project is going.

Probably your tech lead already used things like Jira, Github Issues, Clickup or many other solutions. Pick one, set it up. Make sure your onboarding videos have issues tracking covered. My personal preference — all about the issue should always be kept in track inside the issue. In issue’s comments, sub-tasks, description, state.

Anything what needs to be done can’t be “hey, can you make quick update” on Slack, but rather created an issue, preferably by the tech lead while person who creates issue needs to know business goal and how to communicate to devs.

Congrats, now you have the main things established, let’s jump on interviews.

8th step — finally the interviews

During the interviews you and your tech lead are looking for developers. By now you have onboarding material, you have showcase how you will want to develop the software.

Tip for the tech leads: Go to developers with open mind so they would feel safe to tell their ideas & feedback, yet provide your guidelines with reason to keep all code on the format & naming, so any dev would be able to go into any part of the app and feel home there.

During the interviews ask broad questions, target the reasoning rather the what x function is doing. This should take 10 minutes per person, this will provide general feel if it’s a good fit, if continue — go to live code interview, ask to share the screen and ask to build some things which you will actually be doing with the developer. Allow to use anything, as experienced tech lead you should know technical components which are tricky to build, ask for such and see how person finds the solution. Target here is to watch how person finds solution, doesn’t matter if actually knew the solution immediately. I personally allow developer to use anything during the interview. Including Google, AI or any tools they use.

Salary. Tech lead should not talk about salary with developer. Salary is sensitive topic, someone else should make the talking related to salary. Tech lead in private can give recommendations and key aspects to someone who is talking with developer about salary, yet tech lead should never discuss salary with developer directly. It’s topic which may increase friction later in processes.

Pro tip: before the interview, ask for the 2min video. During this video their goal is to tell a bit about themselves, what they did before and why they want this position. Video content will give you insights of what kind of things person focuses. Provide expectation upfront — tell them to focus on their personal inputs, achievements and goals for the feature rather then project or company they worked at.

9th step — starting to build

First 2 weeks will be onboarding & training. Devs won’t follow all guidelines in documentation you shared during onboarding. Your main goal is to review pull requests and dismiss most of them. Go for details, if anything they doing is not covered in documentation — cover it there, extend onboarding content. Share about updates with all devs, ask to edit the code and update the pull request.

This will be frustrating period for your new devs, so encourage them, make sure they understand you are extremely picky during this time with a goal of having all team on same page, so everything would be easier for everyone down the road and that it will be much easier in couple weeks.

Don’t push them, provide learning material, provide time. They are in new situation, less experienced, they need to learn so much. Provide care, guidance, mentorship and time. Especially during first 2 weeks.

During 3rd week everything should be much more smooth. People who want to learn learn fairly quickly. If you hired someone who don’t want to learn and be a team member of this team, it’s probably a bad fit for this team.

10th step — tasks

Tasks for developers can’t be with blurry descriptions or no description at all. Tech lead must slice project down to 4h size tasks, at max couple days of a task. Tasks must have description, images, videos explaining what you expect from dev. Provide mentorship through the description & video in all tasks.

Pro tip: First tasks must be as small as possible, while main goal of those is to learn code format, naming, structure and issues tracking processes.

Feedback loop

Once task is done, always congrat your developer. They tried their best, make sure if they did a good job, you provide feedback they did a good job. If they did something wrong, provide feedback too. Yet either do it in person or provide feedback to the team w/o identification who actually did a bad move.

When providing positive feedback, also consider doing it on team level maybe even identifying the person, yet make sure to load balance good personalised feedback at team level, so you wouldn’t go into situation where some team members start to feel you have your “favorite” team members.

At team scope all must feel somewhat equal but a little bit challenged, on personal context each should get personal feedback.

Developers team as an asset

Important target is to put systems in place. Guidance through videos, text and samples. CI/CD practices to keep all in quick feedback loop after code changes. Documentation, so team members could go there and avoid blurry guidance.

Good manager can be removed from the team for a week or month and team should continue to run effectively.

If it’s the case, business know team is in a great shape — trained and do not depend on daily things on a manager but rather on systems around them. Always try to avoid single point of failure. Managers do get sick, go on vacation, or leave, though company should not fall apart in any of such cases.

Final words.

There are always things to improve, it’s not perfect and doesn’t have to be perfect, yet it provided good working experience for all around.

My target as a technical leader is to grow people I manage. When they feel safe, accepted and growing, they are happily delivering what business needs. Churn rate of the team is low, which drives more stability, job security and growth overall.

You can find out more about me at https://lukasliesis.com/

Thanks for reading, if you consider it’s worth a clap, please click :)