Alexander Kliotzkin’s Post

Tech Lead and Lead Software Engineers' responsibilities I've been reading the "The Manager's Path" by Camille Fournier, a suggestion by Vyacheslav A., the Head of Engineering of our team. What a book! It is probably the most challenging book of my career because it shows me the many areas I must improve as a leader. A few keywords that I extracted from this chapter reserved for Tech Lead and Lead Software Engineer roles: Delegate, Negotiate, Architect, Strategy, Persistency, Definitions, Facilitate, Directions, 1:1, Feedback, Empathy, Prioritization, Communication, Adaptability, Quality, Flexibility, Fast Decisions, Retrospectives, Lessons learned, Model, Search, Time Management, Results, Light, Unblock. My question is simple! Is your job as Tech Lead or Lead Software Engineer known by these keywords? Let's roll!

If you want to get things done, cut down on the number of online and offline meetings and only invite those who are truly needed. We recently developed a new Software as a Service (SaaS) prototype in a record time of four months, working entirely remotely from different locations in China and Vietnam. Yes, you read that right: we worked remotely without daily, weekly, or monthly online meetings. How is that possible, you might wonder? It is absolutely possible and, in fact, the only way if you want to get things done quickly. I see other teams having daily and weekly meetings and making little progress. We don’t do that. Instead, we break large and complicated projects down into actionable tasks and assign them to the right engineers. If something needs to be explained in a call, we do one-to-one meetings or invite only those necessary. Why should I invite the whole team when the topic is not relevant to everyone? Do you know how much time you waste with these meetings? A daily meeting with six people for 30 minutes is three hours a day, 15 hours a week, and 60 hours a month. Sixty hours from a senior-level software engineer means developing a whole new module and getting things rolling. And one more thing: really good engineers get bored when you waste their time. We don’t want that. We want people to hack and build great solutions. We don’t have time to waste in a world where everything is moving extremely fast. Be brave - start tomorrow! And thank me later :)

This lesson learnt the hard way from a senior engineer at my previous company holds true after so many years... When I was onboarding to the team, I used to ask too many questions, the questions that could have been googled/searched around the team documentation. Earlier, he was very polite and would jump in short 1:1 meetings to help me understand each and every flow, codebase, team documentations etc. After a while, when I used to ping him about any doubts, he would not reply. I would even tag his username using @ but still no reply. This "no-reply" thing went on for a while. One day, I took the courage of asking him, if I have done something wrong that he would not reply to my messages. His response was, I am not trying hard enough to unblock myself. For every doubt, I have acquired a habit of jumping into his DM asking how to do this or why is this not working Being a senior engineer, this time he recommended me to improve the way of asking the help. He told me to ask for help using following questions to the other engineer: 1. What is the issue? 2. What all have you done to fix the problem? To be honest, the second point was missing from my side. I realised I am not working/googling hard enough to get the answers to my questions. I worked on this thing and learnt the right way of asking the help. Providing context that I have done all things possible from my end increased my chances of getting the help in future when actually needed. Moral of the story: "Help is not given where help is asked but given when it's actually needed"

❓Sometimes it’s hard to know what makes a good software engineer great, and what “strong opinions loosely held” means. 👇 💬 Yesterday I got the perfect example of these two in one message (see attached) from no other than Isaac Seymour. Let’s dissect this. 🗣️🙄 Strong opinions loosely held “Having discussed how to do this, I’m no longer convinced that it’s the right choice to build what we originally scoped now: it’s harder than I thought, and involves doing things that will slow down our pace of shipping.” The initial doc was already great but it was clear that different approaches had different levels of risk. Instead of getting too tied to an approach, discussed with another person, realised it wasn’t a great approach and changed course. It also took into account the pace of delivery which is an organisation concern, not just an “engineering” concern. 👌 📈 Good → Great “This has been yeeted out to a separate project in the interest of making sure I can go on holiday without having things in-progress, and because it was the more controversial part implementation-wise.” This is setting the scene for: - actually being able to rest on holidays and not need to worry about leaving things hanging - clear separation of milestones - both for team members and stakeholders - good gating so that it can make progress without causing damage - do the non-controversial bit to move quickly, then discuss the controversial bit. “After a catchup with LoJo (Lawrence Jones) I've written up a short doc with a summary of [..]” This is oftentimes where software engineers fall short. They shout about the problem, they may even change their mind… and then… they stop. In this case, Isaac prepared a new document with the iteration required with content specific to the main stakeholders, in this case Pete Hamilton and I, with clear guidance on expectations and how we can provide feedback. ❤️🔥 If you ever wondered how to level up but may be missing one or many of the above, you can start today, it isn’t complex! It does require doing this a few times - repetition is key (a topic for another time)!

There are times when a Single-Person Army can be used, but most of the time this is just an excuse to massage someone's egos. It can be yours or the high-achiever. I'm a true believer in team work and continuous learning through knowledge sharing, celebration of everyone's achievement and most importantly making safe, small mistakes. #busfactor #team #leadership #management #strategy #engineermanagement #teamwork #agile #scrum

As a software engineer, I am guided by five basic principles: ➡ First, make it work, then make it right ➡ Prioritize simplicity and clarity over complexity ➡ Base architectural decisions on current needs rather than wishful thinking ➡ Foster a culture of collaboration where everyone has their voice, no matter their experience ➡ Be the kind of person you would want to work with These principles are my roadmap. What are yours? 🙂

I remember my first big decision as a CTO. It was overwhelming. Evaluating technical tradeoffs felt like trying to solve a complex puzzle with missing pieces. But it’s crucial. Here are 3 common mistakes I’ve seen many make when evaluating technical tradeoffs. 🌟 Ignoring the Bigger Picture → Focusing too much on immediate technical gains can be shortsighted. ↳ Always consider longterm implications. Example: Choosing a quickfix solution that speeds up development but lacks scalability. Result? → Costs escalate when you outgrow the solution. 🌟 Underestimating Security Needs → Security is often an afterthought. ↳ This is a huge mistake. Example: Implementing a new software without robust security features to meet a deadline. Result? → Vulnerabilities lead to breaches, costing more time and resources to fix later. 🌟 Neglecting Team Input → Decisions made in isolation often miss key insights. ↳ Involve your team. Example: Opting for a tool that isn’t userfriendly for your developers. Result? → Decreased productivity and morale. Remember, every decision has tradeoffs. Evaluate them with a holistic view. Learn from past mistakes. And most importantly, trust your team’s expertise. What challenges have you faced when making technical decisions? Share your experiences in the comments!

Non-technical founders always have this problem: If you are looking to assemble your own technical team, Although you are not technical, it’s possible for you to be the founder and head of a technical product. 3 things to know before assembling your own technical team: 1. You need to bring in a strong technical presence, or maybe learn to be one yourself. This is definitely needed. You need someone who is mature enough to assemble the best talents for you if you don’t have the time and resources to do that yourself. Your job is now left to just find that presence, and sort of, everything will add up so easily. 2. Get people who are product-driven and experienced in product development. Product-driven, meaning they care more about the product being complete and working well than they care about using the latest technology. They are also mature in product development in the sense that they don’t get you into unnecessary technical debt, for example. 3. Lastly, get someone who doesn’t crack under pressure. What I mean by that is: -You will have stakeholders -You will have product and feature requests -Customer feedback You need someone on the technical side to go; no, this is not possible. No, this is going to branch out the product so much. Someone who can make the right decisions on where to move technically when under pressure. How you build your product is as important as how you market it.

Non-technical founders always have this problem: If you are looking to assemble your own technical team, Although you are not technical, it’s possible for you to be the founder and head of a technical product. 3 things to know before assembling your own technical team: 1. You need to bring in a strong technical presence, or maybe learn to be one yourself. This is definitely needed. You need someone who is mature enough to assemble the best talents for you if you don’t have the time and resources to do that yourself. Your job is now left to just find that presence, and sort of, everything will add up so easily. 2. Get people who are product-driven and experienced in product development. Product-driven, meaning they care more about the product being complete and working well than they care about using the latest technology. They are also mature in product development in the sense that they don’t get you into unnecessary technical debt, for example. 3. Lastly, get someone who doesn’t crack under pressure. What I mean by that is: -You will have stakeholders -You will have product and feature requests -Customer feedback You need someone on the technical side to go; no, this is not possible. No, this is going to branch out the product so much. Someone who can make the right decisions on where to move technically when under pressure. How you build your product is as important as how you market it.

A great manager is a blessing to software engineers. If you ask me, what makes a person stick to their current company? It’s not just about the money.  It’s also about the people and culture at work. I have a call with my manager each week to plan for the week. But before we plan anything, I spend 2-3 minutes answering: - how is my family? - how are things at home? - how am I doing? Is there anything he can do to help me do better? There’s no reason to do this from a work standpoint. But this gesture of empathy and care keeps me at peace and allows me to work without pressure. With this, I know if there is a time of need, there’s someone I can rely on and that means a great deal to me.