Tayfun USTA’s Post

Ever wondered what makes a high-performing software engineering team? It starts with clear, role-specific objectives. Software Engineers (Day-to-Day) • Complete tasks on time. • Maintain code quality. • Debug and fix issues quickly. • Ensure robust testing. • Collaborate with team members. • Keep learning new tech. Lead Engineers (Medium to Long-term) • Oversee project timelines. • Provide technical guidance. • Ensure scalable architecture. • Enforce coding standards. • Align with business goals. • Optimize performance. Managers (Long-term) • Develop and train the team. • Align efforts with company goals. • Manage resources effectively. • Improve development processes. • Communicate with stakeholders. • Manage budgets. • Mitigate risks. • Track performance metrics. Clear objectives ensure everyone knows their role and contributes effectively. #SoftwareEngineering #TeamGoals #Leadership #EngineeringManagement #DevTeam #TechLeadership #ProjectManagement #CodeQuality

Are you a software engineering manager or aspiring to become one? This role demands more than technical expertise. You also need strong soft skills like communication, collaboration, problem-solving, and leadership. Here are five important skills every software engineering manager should have: 👉You need to know the latest trends, tools, and best practices in software development. 👉 You should know the languages, frameworks, and standards your team uses and be able to find mistakes and make improvements. 👉 Encourage innovation and creativity within your team. 👉 Communicate effectively with team members, stakeholders, and customers. 👉 Manage projects efficiently, ensuring they meet quality, scope, time, and budget requirements. What other skills do you think are essential? #unbeatableagency #softwareengineering #techtrends #innovationintech #projectmanagement

Software architects are best-positioned informal leaders to massively impact the software engineering function. Whether a chief architect, principal or staff engineer, these types of roles can often be more impactful than any other in terms of how competitive your product development is. They impact the tone. They impact the culture. They impact the overall approach. Respected by both the teams and non-technical managers they are in the midst of it all. Business and product needs, long-term architectural decisions, technology strategy, team leadership, technical practices, teaching, processes. They are right there to take you from software production to serious product engineering. How can you as a manager help them? 1) Do not waste their time. Do help them with finding focus and keeping a sustainable pace. 2) Help them become the flag-bearers of disciplined software *engineering*. These roles can be the multiplicator of your product engineering proficiency. They might not know what that means yet, so help them figure that stuff out. If YOU don't know what that means, ping me. It's free. -- 🔔 Liked this? Why not follow me and you'll get more of this directly in your feed! #softwareengineering #engineeringmanagement #productdevelopment

Should Companies Ask Their Engineering Managers to Write Code? Long story short, NO! (Okay, okay, with some exceptions 😁 – like if the company is too small to afford dedicated developers.) Let’s consider a typical software engineering team comprising junior, mid, and senior-level engineers. Senior engineers are expected to handle technical research and bottlenecks, follow best practices, uphold high standards, mentor juniors, and more. Mid-level engineers share similar responsibilities but with a narrower, less ambiguous scope. Additionally, we have Staff-level engineers who primarily focus on reading, reviewing documents, and designing, though they code when needed. Given this structure, if a company (especially in Pakistan's “one-man show” culture) expects Engineering Managers to code, I’d ask, "For what reason?" 😊 Engineering Managers should be responsible for: Mentoring team members Setting project priorities Hiring the best talent Resolving conflicts Assigning the right projects to the right engineers, balancing expectations when opportunities are limited Ensuring the team aligns with the product and understands the business domain Handling promotions Identifying and addressing weaknesses in team members Increasing team visibility Keeping individuals motivated Managing performance Communicating effectively Ensuring team efficiency (tracking performance, resolving bottlenecks, addressing conflicts, etc.) Estimating project timelines technically, understanding granular and overall technical challenges Listening to individuals' problems, even those unrelated to work Managing parental leaves, vacations, and sickness And much more... Companies expecting their Engineering Managers to code likely hired a Software Engineer who transitioned into management. This means they missed out on leveraging managerial experience to improve systems—they effectively hired a developer with a managerial title. This indicates confusion during hiring or a strategic misrepresentation. If you find yourself in this situation, hire a Developer, not a Manager! What do you think? #softwareengineering #management

It’s interesting how software engineers say, "I don't want a manager telling me how to do my job!" but then turn around and insist that managers need to code to make technical decisions. I don't buy it. Coding skills aren’t what make a great software engineering manager. I like to compare a software team to a football team. Depending on the level of management, a manager needs to be more technical or not. Take a tech leads, they’re like the team captain. They’re right there with the players, getting their hands dirty and helping direct the game. In this case, they need hands-on experience with the tools and frameworks. But an engineering manager is more like the team coach. Maybe they used to play, or maybe they didn’t, but they know strategy and how to build a team that works well together and delivers great results. They don't need to be in peak physical condition or able to play a full game. The thing is, the team should make the technical calls since they’re the experts. A manager's role is to create an environment where the team can succeed. They build a solid team, get the right resources, and make sure everyone has the info they need. They should focus on being the support system, not the hero swooping in to save the day. By fostering a good environment and backing up their team, managers can lead more effectively without diving into the code themselves. To me, it all has to do with teamwork and trust, not with the manager's coding skills.

With this program software engineers, tech leaders and project manages can develop the following people skills to be successful in their careers: 𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧: Effective communication is essential for software engineers to convey technical information to non-technical stakeholders, collaborate with team members, and present their ideas clearly. 𝐓𝐞𝐚𝐦𝐰𝐨𝐫𝐤: Software development is often a collaborative effort, and the ability to work well in a team is crucial for success. 𝐄𝐦𝐩𝐚𝐭𝐡𝐲: Understanding the needs and perspectives of users, clients, and team members can help software engineers build better products and work more effectively with others. 𝐀𝐝𝐚𝐩𝐭𝐚𝐛𝐢𝐥𝐢𝐭𝐲: The tech industry is constantly evolving, and software engineers must be able to adapt to new technologies, methodologies, and work environments. 𝐋𝐞𝐚𝐝𝐞𝐫𝐬𝐡𝐢𝐩: Software engineers who can lead and motivate others, delegate tasks effectively, and make sound decisions can help drive their teams and projects to success. These skills are important because they enable software engineers to work effectively with others, build better products, and advance in their careers.

Hey recruitiers / hiring managers... adding this kind of info to your posts sure would be swell for everyone involved since "engineering manager" and "software manager" mean such different things in different organizations. Even with descriptions and required skills this info clarifies what matters and how much. A job requires Java for example. If you say technical is 5 stars someone that isn't strong in code isn't (or shouldn't) apply. If you say technical is 1 star, someone that wants to stay in code while managing isn't going to apply. And importantly for both visa versa. More context can only help you be more likely to get candidates that match your expectations. Take a look at the 5 different types of Engineering Manager and then specify it and mention the blog (no clue who the blog poster is btw, no affiliation) or use the idea of the different areas to stress. eg: The Delivery Engineering Manager Technical 🌟 Team 🌟🌟 Process 🌟🌟🌟🌟🌟 Product 🌟 https://lnkd.in/eSj2i9yj

As a team lead and currently as an engineering manager, I've noticed a common tendency among developers, especially juniors and mid-level engineers (though seniors aren't exempt to this), to dive straight into coding without fully grasping the scope or addressing lingering questions. This often leads to suboptimal decisions and implementations. Reflecting on my college years, I recall when we had to code on a piece of A4 sheet. Initially, I found it absurd. However, during the process of writing the code, which was marked by multiple strikes and revisions, underscored a crucial lesson: thorough preparation and understanding is crucial. A professor once emphasised that 80% of any task involves preparation and planning, with the remaining 20% dedicated to execution, be it coding or actually creating something. In our company, we implemented a structured development plan. The feature owner (usually a developer or engineer) breaks down larger tasks into manageable chunks to gain a comprehensive understanding. Weekly milestones and sync meetings, which are owned and managed by owner of the feature, ensure alignment on progress, address emerging questions, and tackle unforeseen issues. In one of the previous companies, we adopted Technical Planning Meetings (TPMs) where a predefined template helped dissect complex features into manageable deliverables. While we avoid excessive documentation to prevent time drain, we maintain a concise overview of tasks, responsible parties (QAs, PMs etc.), and estimated timelines. Additionally, we establish a testing strategy early in the development phase. Ensuring appropriate handling of significant features requires clarity, transparency, and contingency planning. We prioritise eliminating ambiguities, establishing clear timelines, and fostering an environment where ownership, in case of absence, can seamlessly transition to another person. How does your team ensure the smooth execution of major features, clarity in responsibilities, and continuity in ownership? Or which delivery strategies do you apply, if any? #development #planning #engineering #transparency #ownership #clarity #FeaturePlanning #DevelopmentPlan #milestones

Job titles can be a minefield! One thing I've found on my journey from Front-end Development to Developer Management is that the role of Development Leads/Technical Leads/Engineering Managers can be so varied! I think that job titles are so tricky because they try to sum up a role in a few words, when the actual responsibilities of these roles can vary so much depending on the organisation and the structure of a team. Perhaps from being a bit of a gamer, I often like to think about teams as "parties" such as those in RPGs. 🤓 The party consists of different character classes with different roles - you might have characters that focus on attack (those who focus on coding), as well as having support roles - like healers! These people make sure the team is topped up on health and ready to go, but they are still very much part of the team (they can even attack if needed!). The main thing is that the party - or team - doesn't have "rock stars". There is no one person or job role that is better or worse, but rather it is the structure of the team and the blending of skills and talents working in collaboration that makes it a success. I recently found this article by Pat Kua discussing Engineering Manager Archetypes, and was delighted to see somebody else comparing technical roles to character archetypes! I especially like how he demonstrates the allocation of XP (experience points) and how the balance of technical, team, process and product "XP" can vary so much in different engineering manager roles. There can be so much variation in specialisms and skill areas that I think can be hard to sum up in a single job title - I'm sure this applies for many jobs, not just tech management! Perhaps we can start advertising job roles with the assignment of XP points? 🤓 (or maybe I just finally need to go and play Baldur's Gate 3...). I'm currently available for work, so if you need a Healer/Support class on your team, do give me a shout! 🪄