31–40 of 84 posts
I really don't think coining the term 10x did anything to help developers or the state of development, and likewise here.
> The Tech Lead is a “hybrid” role with one foot in management and the other in engineering I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more de…
> The Tech Lead is a “hybrid” role with one foot in management and the other in engineering I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more de…
I wish leads did veto more - often I am "delegated" a task, spend a week on it, then they look at it and tell me to it a different way - a way they could have told me to do at the beginning of the week and not have wasted my time. So then I spend another week re-doing it to the way they want.
I should note this dynamic is at play not just for programmers, but for devops and other groups as well.
As far as the legend of the 10x or 100x developer, technically it does exist in the sense that the smart lead will not even entertain time wasting efforts, so to calculate the value of that you could say is infinite x.
I’m skeptical however that you can transfer your extraordinary abilities to your team members. The most brilliant productive people I cant imagine they can truly transfer that to others. Their ability comes off more like a God given gift, so to speak. Surely they add value individually and add value to each team member by their guidance and mentorship.
The 10x concept though somewhat confuses the truly important question, both to the technical programmer employee and their capitalist business bosses. How much value is really being added and at what cost.
> The Tech Lead is a “hybrid” role with one foot in management and the other in engineering I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more de…
> The Tech Lead is a “hybrid” role with one foot in management and the other in engineering I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more de…
I agree. The most important question for me when looking at a position is whether the team has a lead or manager, if they have a lead it is a bad sign. They are too busy coding to manage, they are territorial and are responsible for the all the important, business critical, high profile pieces. I wish leads did veto more - often I am "delegated" a task, spend a week on it, then they look at it and tell me to it a dif…
It's worthwhile doing even if you wouldn't have ended up with wasted effort - other people can have helpful suggestions of things to look out for, or minor refactorings you might do along the way.
> The Tech Lead is a “hybrid” role with one foot in management and the other in engineering I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more de…
> The type of "management" they do then becomes more defensive/territorial than directing/guiding.
We do our best to limit defensive/territorial attitudes and have an open debate/decision protocol to iron out disagreements as they arise in a healthy and supportive manner. We encourage such heated, albeit respectful, discussions -- these are bound to happen when you hire talented, passionate folks -- while reinforcing team consensus and a need to work together (no winners/losers). Again, the more our leads see leadership behave in such a way, the more they are empowered to behave likewise.
> always end up doing the business critical or challenging pieces themselves
I admit this is tricky. Success here comes down to practice, which is something a lead learns over time. We have a couple ways to handle this. First, we have our rework/defer/abandon model, which provides some breathing room for deadlines and gives our leads a moment to pause and collect themselves, and gives them time to reconsider how best to delegate/mentor. And second, as most leads tend to be perfectionists and can easily fall into the trap of micromanaging, we discourage "prescriptive" advice in code reviews, such as "doing the work for the reviewee," and encourage outlining outcomes (with some supportive materials) so their team members can tackle the problem autonomously.
With all the above said, really it all boils down to the example leadership sets and how they go about supporting their tech leads. I hope that helps!
(fyi, I'm the article's author)
I really don't think coining the term 10x did anything to help developers or the state of development, and likewise here.
> The Tech Lead is a “hybrid” role with one foot in management and the other in engineering I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more de…
I call this being a "dev++", and I think it's an unhealthy mindset for leadership. Moving into leadership means advancing beyond the tasks you used to do. This is true everywhere, and lack of promoting yourself beyond those tasks will drag you down. This goes all the way up to c-suite level, where people fail due to focusing too much on their old group and job, and neglect all the new groups they inherited in the promotion.
I've been an individual tech lead for a few years now, and am about to take on a team while still maintaining the technical leadership role. I'm basically going to be a blended technical lead, project manager, and people manager. The only way I could do this was to stop coding myself. If I'm coding, it's to investigate an issue that has stumped others, or do a proof-of-concept for a particular technology or pattern.
Otherwise, my time is entirely devoted to helping individual developers increase their understanding of our stack or engineering in general. Or, on the other side, sitting with business and understanding requirements so that I can determine how engineering will approach the problem. I then delegate that vision to the engineers to implement, with code review closing the loop.