Skip to content

Comment on 'My team will be able to program circles around everyone else' (2002)parent

Comments

Sometimes I think/know that I'm this person, and it worries me because I see it as squeezing my future to a very narrow path.

My project is "general", "flexible", and what I consider "done right" (time<->quality issues aside), and definitely requires a specific mindset. As you suggest, I often find myself, internally, blaming others for not being able to "see" it or caring enough to understand it, but I can make it dance beautifully when something new/strange needs to be incorporated, often "saving the day".

I know that if I left now, it would swiftly collapse, bringing the whole team to a halt. Management has also realized this, resulting in some nice shiny golden handcuffs.

The new developer we hired (since I did become The bottleneck) isn't the greatest (his performance reviews agree), and is slowly breaking things, but I'm only half stopping him because I'm trying to assume my rigidity in the "correctness" must be flawed, and I don't want to damage the relationship any more than it has been.

Now I'm in the progress of scaling this 10x, and I don't want to be a 10x bottleneck.

The only thing that holds back m imposter syndrome, and makes me think it's my, as you say, qualities, is that, after nearly 3 years, the churn from many of the other teams are finally converging towards the one implementation that I've had working, stably, in that same time span, for all of the same reasons that I implemented it the way I did.

tldr;

It's easy to interpret this as being about your qualities instead of your failings

This is probably me. So, what's the solution? Re-think the whole concept to come up with a different implementation? Simplify?

I've been there. I an built entire deployment/change-management system in very small IT teams (1 other person with different skills from mine). We eventually got the go-ahead to grow the team, including more admins with my skill set. At that point, I had written pretty much the entire thing while the other admin had been focusing on tasks related to their skills.

Whenever a request came in for something regarding the system, I would have to force myself to sit down with one of the other admins and walk them through making the change to close the ticket. It took 3-4 times as long to do the work that way, but after a few weeks, I could start assigning some tickets to them directly and eventually the time savings exceeded the expenditure and I could go back to big-picture planning.

It's a hard lesson to learn the first time, but worth the pain of going through.

Don’t take on straightforward tasks in the name of expediency. That’s the hole you’re already in and you have to stop digging.

A little pair programming or watching someone use the new thing you wrote can go a long way toward informing you on how to close the gap. The tricky bits may not be that tricky for others, and the obvious bits often aren’t.

It’s not all roses, of course. The person who doesn’t understand that you built a ladder for them to climb may complain loudly about how long it took you to get to the top of it. It takes a somewhat special team to be able to do the right thing and not get punished for doing so.

Somewhere in between that and Lord of the Flies is most teams.

Read Good To Great, The Phoenix Project, etc. It's about collaboration, not implementation.

May i suggest working on becoming a teacher / mentor / enabler for your teammates and pitching this plan to managment?

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.