61–70 of 296 posts
1- redirect to another engineer.
2- keep track of the convo. If it is going off the rails help the engineer get back on the rails
3- if the engineer cannot help, jump on a call and explain to the engineer how to help. Then let them help.
This is how teams grow. This also let's you, the technical leader, inject yourself and assist the team without being the only source of truth. And also you become trusted.
Win. Win. Win.
I was leading the large project, it was a core system for a financial organization.
Because of a fast pace and because of the fast growth and because of the unexperienced management, it was impossible to quickly train and delegate things to the appropriate people.
I was often getting a call from the devs, asking for help, and I was like “it works so and so, check the X file and find the Y method, that’s where you should apply changes. When you do that don’t forget to do Z.”
I was also getting calls from the top or middle level management. They were asking me things about the product specifications, marketing metrics, etc…
Literally everything “that guy” that knew everything.
The pace didn’t slow down, the opposite, company wanted to grow like crazy. I couldn’t keep up with everything. I remember I had a honeymoon in Thailand and I was literally hanging on a phone to dictate people how things worked and what they should have to do.
Things ended up miserably. The new CEO came and we agreed that I needed help with the delegation: I needed suitable people on-board and time to teach them. The process started. But it was going slow. We still had a fast pace of growth and I was trying to hire and delegate along the way.
After some time, I was accused to be a “ corporate parasite”, keeping all the knowledge to myself to be indispensable and irreplaceable. I left the company soon. Did my best to transfer the knowledge before that.
In the end, it’s been one of the best experiences I had. I grew professionally and mentally, nowadays I easily spot the problems while they become big, know who is who in a glance and so on… I learned a lot along the way.
Several advices someone might find useful:
1) If you cant align with the decision makers you either have to get used to it or move on. Mostly you have no control on the other peoples’ thoughts. If it’s broken, it’s broken. Period. Don’t prolong your decision.
2) Always under-commit and sometimes try to over-deliver. Depended on the quality of your management or organization you might want to over over-deliver and be respected. If you’re in a situation like this then good for you.
3) If you want to grow your organization and the team, you must learn how to delegate tasks and get deliverables, without micro-managing people.
4) In the end, its more about people and less about technologies. Your job is to understand, manage and delight people and solve all the problems along the way.
In the spirit of the old saying, "the two happiest days of a boat owner's life are the day they buy a boat, and the day they sell it." The best advice I got starting out was, "be indispensable." The best advice I got four years later was, "don't be indispensable." In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned…
What's your goal, though? I'd like my company to not absolutely 100% need my constant presence, and I don't want to be in the author's position where he is not doing what he could be most valuable doing. But I do want my company to think "wow, that ivraatiems, we're sure lucky to have him." I would want them to think twice about firing me or laying me off if layoffs were happening. I definitely would not like to have…
In the spirit of the old saying, "the two happiest days of a boat owner's life are the day they buy a boat, and the day they sell it." The best advice I got starting out was, "be indispensable." The best advice I got four years later was, "don't be indispensable." In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned…
Deming sometimes used bus drivers as an example. Some of them might think it's not their job to smile and be nice to passengers. They're hired to drive the bus, and perhaps help out in emergencies, but not much beyond that. However, being nice to passengers (performing "caring labour" as Graeber would have put it) increases the chances that people choose the bus over e.g. the metro or something else. Deming concluded…
Earlier quoted context omitted.
There is something to be said for being indispensible for novel problems, instead of for known problems. Some of the worst behavior I've seen in both myself and others has come when you can hold your company hostage by refusing to do something. Even when you are using it for 'the greater good', that's not a good look and not a great feeling. You shouldn't have to go with the nuclear option to get something done, even…
Maybe companies need some kind of "Chaos Monkey" system [0] in place for regular employees. Not in "terminating" random employee's contracts, but a culture were regular, maybe even some kind of random transferals onto other projects, or onto internal work regularly happens. Everybody knows this and everybody should be prepared to a situation that tomorrow they are not working on the same problem they work on today. H…
This is exactly why companies offer sabbaticals. It forces you to train people up on your five years of knowledge before you leave for 10 weeks. OP could have just taken a long vacation.
This is exactly why companies offer sabbaticals. It forces you to train people up on your five years of knowledge before you leave for 10 weeks. OP could have just taken a long vacation.
Maybe... but not all companies offer sabbaticals / extended leaves of absence with a way to come back.
Earlier quoted context omitted.
There is something to be said for being indispensible for novel problems, instead of for known problems. Some of the worst behavior I've seen in both myself and others has come when you can hold your company hostage by refusing to do something. Even when you are using it for 'the greater good', that's not a good look and not a great feeling. You shouldn't have to go with the nuclear option to get something done, even…
Maybe companies need some kind of "Chaos Monkey" system [0] in place for regular employees. Not in "terminating" random employee's contracts, but a culture were regular, maybe even some kind of random transferals onto other projects, or onto internal work regularly happens. Everybody knows this and everybody should be prepared to a situation that tomorrow they are not working on the same problem they work on today. H…
One hero is bad. Zero heroes is worse. You want lots of heroes.
Trying to create a structure where anyone can jump into anything at a moment's notice just leads to everyone having a superficial level of expertise in everything and no responsibility (or worse, responsibility that they can't possibly fulfill so they just get thrown under the bus if they don't hit impossible delivery targets).
All that does is move you from one hero to zero without waiting for your one hero to quit. It's resigning yourself to the bad outcome just to get it over and done with.
The tricky part is that the 'one hero' structure tends to form pretty naturally, so you have to actively take steps to prevent it. If you put a standard team in place and let it run wild, unless the devs understand this problem initially, then eventually you'll just end up with everyone deferring up the chain of command for both knowledge and responsibility over time until a few years down the track whoever was the technical lead on the project is now your hero.
I much prefer to have an ad-hoc structure where important work is divided up amongst the team and each team member takes total responsibility for their part. More senior staff shouldn't be trying to own more code and more responsibility, they should be providing more support to others.
EDIT: I don't think I actually explained how distributing responsibility solves the bus factor problem, whoops. The idea is that part of that responsibility is for managing the bus factor of your own work. This only works if the code you're responsible for is small enough that you can realistically bring another dev or two into the fold and get them ramped up properly with real understanding of the code.
On one end I learned a ton, and probably the most important, how to deal with responsibility and pressure. But at the same time I can really see myself in this article, I ended up choosing another road, I was bored with the product, but the company didn't want me to switch to a different product or team, and my team itself was treated like dirt, so I ended up leaving.
I really tried knowledge sharing and getting others to be independent on the product, but we didn't have the right people, and the culture of the company simply didn't value that trait in newer hires.
I could have made so much more money if I stayed, but it is still far to early in my career to become an 'ivory tower' architect.