How do you write a case study in a language understandable to the client — without losing expertise? How do you leverage open source to highlight your niche skills? How do you create a tech digest that will collect 10,000+ subscribers?
To learn the answers to these questions, as well as other aspects of IT company positioning, I interviewed Daniel Lasko, the sales director at the
The Interview
Daniel: We specialize in website and application development, design, and technical consulting. Now, Singula is focused on domains such as fintech, e-learning, business automation, blockchain, e-commerce, and medicine. Our typical customers are CTOs (if it is a large company) and CEOs (if it is a startup). The former is often focused on managing IT development, while the latter may not understand it at all, which is why they are looking for a team that “speaks the same language as them.”
If your development team is in a similar situation, then it makes no sense to write complex technical articles — ordinary people simply won’t read them. They need to read a project success scenario that they can try on for themselves, not raw development progress data.
We have found a golden mean — you need to create content that will be understandable to potential customers, but at the same time, will show the level of your niche expertise.
Your editors should collect information from the project team, write the text, and coordinate it internally and then with the client (with the help of the project manager).
But don't forget about your internal development team. Because, through the content, potential team members can evaluate the company as an employer — whether modern technologies are used, what can be learned from future colleagues, and how to grow.
This can be shown through technical digests and articles about your open-source projects.
Elizabeth:And how do you present niche expertise so that the client understands you?
Daniel: Let's look at a structure that can help give customers the information they need.
Do not lock yourself in the “task-solution-result” scheme.
If you look at content creation guides, then, most likely, you will see this advice there: “Write short stories in the format of task - solution - result and show the numbers.”
But I would say do not be shy about writing long case studies. If they need 13 scrolls, it’s okay. But to control the reader's attention, you need to divide up the content with clear headings.
Clients are interested in what you did, how quickly, and what results it brought.
Unfortunately, we are not always able to speak openly about the metrics of the products we develop. In this case, you need to try to show qualitatively what your help changed. Is the product better than it was before you joined?
The choice of frameworks and tools needs to be highlighted in terms of what benefits they provide. There is absolutely no need to dive into technical details where the client will get lost in the terminology. There are other formats for this.
Write case studies in a language understandable to ordinary people.
For example: “We developed a CRM system for company N. Employees could not quickly complete their tasks because there was no single design of internal systems, and the technological base was a mess.”
Don't be afraid to write about failures.
If you try some solutions, but they don’t work out well or don’t work out at all, this is also expertise. After all, you understand that if you go this way next time, you can lose a year of development.
By talking about failures, you show the client that you will not step on this path again. And they will not either, because thanks to you, they will know about the potential problems.
Often, such experience does not come as a result of erroneous decisions, but through experiments.
If you have been working with the same clients for many years, developing an MVP can take up to a year or two. In such conditions, it is possible to try different tools and find the best one.
Outline the tech stack, but don't go into details.
If you develop a lot in Ruby, Go, and Rust, always indicate this in your cases. Why? There are three reasons.
- It may so happen that your potential client's CRM is written in one of these languages. This is an indicator by which they can identify if your team suits them.
- Some technologies allow you to save several months of work, which can be indicated in the case. For example, Ruby reduces development times by 40%.
- Sometimes executives might like you, but then they will ask for an opinion from their technical experts. And tech experts will understand your information without any problems.
The best way to talk about the results is to show them.
To show the results of your work, you can describe the main modules of the CRM system you have developed.
If you want to show that you plan to work on the project for a long time, write about your plans.
If a case study is written either at the time of completion of the project or at the time of a significant release, to add perspective, it's worth adding a "What's next?" section. In it, you can talk about your development plans (if you will continue cooperation) or your client’s development plans (if the client will proceed by themselves).
In fact, working longer and more productively is interesting. Naturally, publishing case studies that end with the phrase “and then the startup closed” is not very cool.
Make the case approval process as simple as possible.
It is one thing to write a case, but it’s another thing to get approval from the client. That is why you should write 15-20 cases in parallel, in order to publish at least one every month. Large international companies like to hire lawyers to clean up the material as much as possible.
If, at the stage of collecting information, the project manager says that some part of the project is still private or the client has their own plans for its promotion, of course, you should not write about it.
Because of this attention to detail, your editors may spend more time preparing articles because they delve deeper into the material. But you can control this. And deliberately leaving something that complicates the coordination is not worth it.
Elizabeth: So how do you demonstrate expertise if your target audience includes experts?
Daniel: By writing about your open-source projects.
Development is always the process of inventing things. If some tool is missing, you can create it yourself. And then talk about it on your website.
Articles about open-source are texts that ordinary people will not understand. They are for developers. And by publishing them, you share your expertise, which is very important in the developer community.
Collect news from the development world in a digest.
Another format exclusively for developers is tech digests. Every month, you can write a short review on the technologies you work with: Ruby, Rust, Python, Go, Frontend, DevOps. The digest can be made available as a mailing list, as well as separately on the website, where there will be more details and valuable explanations.
It will be difficult for a non-specialist to find such projects. The Internet is full of all sorts of ratings and top open projects from GitHub. But you can try to talk about things that you actually use in your work.
In general, every developer has a folder with saved links to interesting repositories that they plan to implement.
What do we read to stay current and on topic? The list is not final, but it is worth it to start digging from here:
Develop expert games and quizzes.
You can create various quizzes, with tasks composed by your developers. Inside, there can be 7-15 questions and several answers, of which only one is correct. Small snippets of code can be taken even from real projects.
To take the quiz, participants fill out a form with their email, name, and city. This provides additional warm contacts of those who may be interested in your events, newsletters, and free tools.
Participants who answer all questions correctly can win prizes: wireless headphones, smart speakers, air humidifiers, etc.
Here, you will kill two birds with one stone: show your expertise and study the labor market.
Conclusion
I would like to thank Daniel for such an in-depth interview and for sharing his knowledge on IT promotion with the community. I am sure that IT companies & individual specialists should be dedicated to giving back to the developer community through open-source projects, meet-ups and conferences, and informative interviews with experts like Daniel. I hope this interview will help you develop new strategies for promoting your IT team!