In the world of career progression in the software development industry, the historical tendency has been that ambitious individual contributors (ICs) chased the managerial path seeking higher compensation. Predictably, this led to said ICs having to deal with issues in areas such as staff performance and engagement, project management, hiring, stakeholder communication, and budgeting, amongst others. Of course, some thrived in such positions, but plenty didn’t.
The Rise of the IC Career Path
The industry then started to realise that a career path where ICs remained ICs was necessary. At the same time, the industry started to rethink what are the right skills to look for in prospective managers, and what level of technical skills they need to be successful.
Varying Expectations of Engineering Managers
The expectations that companies have of their EMs can be quite different. Some expect them to simply be people managers and to not be heavily involved in any technical conversations in their team. On the other hand, ComplyAdvantage’s culture in Engineering (and to some extent in Product too) is that both ICs and Managers are deeply technical individuals. That said, there are some nuances that I discuss below.
Problem-Solving Skills for Managers and ICs
First of all, managers and ICs alike need to be proficient problem solvers. Managers, however, need to be able to give direction even when ICs imply that a problem does not have a feasible solution. Similarly, managers need to be able to challenge ICs should they suggest a problem has only one specific solution, which may be particularly expensive, have a high long-term ownership cost, or are not aligned with the company strategy.
Business Deliverables and Technical Tradeoffs
Along the same lines, managers need to be able to commit to business deliverables that have concrete timelines and budgetary constraints. This often requires having detailed technical conversations about tradeoffs being made with respect to non-functional requirements such as scalability, performance, security and architecture. Managers need to be able to understand such tradeoffs and to ask key questions when those conversations happen. Additionally, managers need to be in the position to articulate what those tradeoffs are, why they’re being made, and what they mean for the business. The audiences will include highly technical people, as well as high-level business stakeholders.
Handling Production Issues
Moreover, when (not if) things go wrong in Production, managers ultimately need to be able to answer to the business: Why did this happen and how do we prevent it going forward? In my experience, this requires a deep dive into the underlying technical issue and subsequently articulating it coherently for stakeholders who are deeply technical, and others who aren’t.
Technical Conversations in Recruitment and Performance Management
Other crucial areas where managers are exposed to technical conversations are recruitment and performance management. Managers are responsible for hiring, rewarding and retaining key talent. Inevitably, managers need to be able to understand and assess what are the technical achievements of their reports and of candidates.
Evolving Technical Responsibilities of Managers
As Managers grow in their career path, their technical responsibilities will evolve to include having a technical vision and putting technical governance in place. What are the technologies that as a business we want to adopt, try or abandon? Which technologies are best suited to deliver the customer experience and developer experience that we’re after? Will the use (or disuse) of a particular technology unlock a new market opportunity or perhaps enable us to attract better talent?
Conclusion: Technical Skills for Managers and ICs
In conclusion, managers need to be highly technical, however, technical ability comes in different forms. The types of technical skills that managers need to be successful are different, though not mutually exclusive, from those needed by ICs. Evaluating trade-offs, challenging solutions and sizings, communicating complex concepts, assessing technical achievements, and formulating a technical vision, to name a few, all require a skill set that is perhaps different but complementary to for example debugging and resolving a deadlock in a multithreaded system or knowing what is the most idiomatic way to iterate over a collection.
Author: Alfredo Fernandez Acuna