191–200 of 224 posts
Earlier quoted context omitted.
Yep. It doesn't scale well. Technical lead != technical manager. It's also myopic because it's two jobs and two completely different professions.
What is a technical manager?
I guess we could recast the term "technical manager" as "one who attempts to both do and manage."
Earlier quoted context omitted.
Technical leads should be helping ICs. It doesn't always have to be the manager in particular.
I think it depends on how each org or company defines its team structure and the responsibilities of the different roles. We don't have a separate tech lead role in our team. Even so, wouldn't a tech lead be focused only on technical aspects. Say if I want feedback on some customer interaction I had or maybe regarding a meeting I ran, it is not the role of the tech lead to do so I think.
Earlier quoted context omitted.
I replied elsewhere a longer form argument, in the form of concrete examples, why I feel being able to ship code confers benefits to engineering managers. I'm not going to argue about titles. Titles are useful for internal political signalling and are basically minimally-transferable cultural norms, but less useful for determining how to best take care of your responsibilities. For the purposes of this discussion I c…
Then why are you writing? Why are you unable to interact without respect and curiosity but with adversarial hostility? Are you going to escalate to name-calling since you don't have an argument, only rationalizations to reinforce your worldview or the inability to consider approaches outside of your own? Maybe curiosity and self-reflection would help improve the quality of your conversations rather than promoting a r…
If you’re going to accuse me of a lack of curiosity then you need to explain why anything you have written actually does more than repeats the claims in the article I was explicitly rejecting, or why my claim that you leaning on titles to form your argument is just debating over definitions is false.
Earlier quoted context omitted.
> t's not uncommon that, in terms of money anyway, IC tracks tend to cap out at lower levels than management This is pretty natural, at least in a big organization. At some point your IC tracks almost always have less impact. There are weird corner cases sure, but not enough that you can't deal with individually. But that's ok; Almost every manager isn't going to eventually be C-level either. What's important is that…
There are weird corner cases sure, but not enough that you can't deal with individually. I think that's where a lot of organizations fail. Take the "Technical Fellow" I mentioned earlier. This is the "weird corner case" - a technical IC who is capable of contributing strategically but has no interest in management. The people in this role generally have ~20 years in industry and most have advanced degrees. They're so…
Earlier quoted context omitted.
2b) Start coding again because your superiors promote you to management but treat you like you’re still an IC and ask why you haven’t contributed any points to the latest sprint while actively shutting you out of the kinds of discussions and decisions an EM would be making in most other orgs—-while somehow simultaneously asking you to also be the bearer of frequently changing and poorly communicated business prioriti…
I keep seeing this IC term here but never saw it before, is that “Independent Consultant”?
I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…
I've never seen any team where Senior Dev / Tech lead have had any power to make "arch level" decisions. And I have a very hard time imagining a team where the other junior/mid level engineers would accept to have such decisions made over their heads, by a member of the team.
Earlier quoted context omitted.
I seriously question #4. While the popular tools and languages and techniques churn, there are no fundamental revelations in software development that cannot be understood at a higher level by somebody who stopped programming in the 70s. If anything, not being obsessed with the churn helps these managers step back and ask fundamental questions that are often ignored by magpie developers. It is very possible to keep u…
No, I'm not talking about those kinds of skills per se. ("Fundamental revelations.") I'm talking about: - Grokking what actually sucks about the tools, languages, frameworks, etc in use. And grokking what complaints of suckiness are shallow or misplaced. The former is an opportunity to deliver empathy for the team's suffering and propose good solutions, the latter is an opportunity to remind engineers (esp junior one…
If you're not coding 100% of the time on important value add tasks, you're not ever going to be as technical or as current on the details as your team. As a manager being the technical lead IS NOT YOUR JOB. You have people for that. Empower them, listen to them, arbitrate between them, enable them to get their job done.
It is not your job to decide what technology is best, your team is the one with that know how and will offer you choices and tradeoffs; if you need to decide you'll need to trust their information to choose the best set of tradeoffs for the business strategey. Trust them to give you the right data. Nurture the team so they don't lie to you; if they're lying to you, there are much bigger problems to solve than the technical details.
Earlier quoted context omitted.
Do you really enjoy having 3 different managers to report to? All of whom have 3 different projects they’re dealing with? IMO, it’s better to have a 1:1 ratio of managers to teams. A 3:3 ratio is a recipe for endless meetings and communication overhead. 1:1 and 3:3 have the same number of employees, but 1:1 eliminates all of the communication overhead because there’s only 1 manager per team instead of 3. In my experi…
I'm not sure where the 3 managers comes from. Product manager (Product Owner in scrum), Senior Dev / Tech Lead, Dev1, Dev2, QA, and UI/UX Designer all report to Engineering manager. Further, changing the mindset from "as a manager these reports work for me" to "as a manager I work for these reports" improves the feeling of ICs having "multiple managers". The managers job should largely be unblocking the ICs.
Eng Manager Product manager -- UI/UX (same org not direct reports)
QA (Had their own reporting structure)
1. Become an engineering manager 2. Stop coding 3. Do well for a few years until you become out of touch 4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead 5. Watch as your role morphs from a manager…
2b) Start coding again because your superiors promote you to management but treat you like you’re still an IC and ask why you haven’t contributed any points to the latest sprint while actively shutting you out of the kinds of discussions and decisions an EM would be making in most other orgs—-while somehow simultaneously asking you to also be the bearer of frequently changing and poorly communicated business prioriti…
Just as much coding work as before, plus becoming the interface between the developers and the actual management, with no pay raise of course. Not able to change anything, but regularly reminded that I am responsible for the results.
Earlier quoted context omitted.
2b) Start coding again because your superiors promote you to management but treat you like you’re still an IC and ask why you haven’t contributed any points to the latest sprint while actively shutting you out of the kinds of discussions and decisions an EM would be making in most other orgs—-while somehow simultaneously asking you to also be the bearer of frequently changing and poorly communicated business prioriti…
Heh, I also fell into this trap once. (I no longer work there.) Just as much coding work as before, plus becoming the interface between the developers and the actual management, with no pay raise of course. Not able to change anything, but regularly reminded that I am responsible for the results.