I've heard this too, except it got really annoying to be working crazy hours doing annoying crap while you have a team of devs working 40 hrs working on interesting tech with not much pressure. I burnt out, now I delegate lots of crap work and it works better for me and I think the team as well as they get a wider perspective.
> I burnt out, now I delegate lots of crap work and it works better for me and I think the team as well as they get a wider perspective.
I think this is an underrated (but very accurate) opinion.
While I'm not the founder of a company, I do have the tendency to shield my team from much of the insanity I deal with on a daily basis.
I've made active, conscious efforts to stop doing this.
When you shield your team from the harder, more hectic parts of the job, several things happen:
(1) You burn out. A burned out leader is not an effective one. You're not doing your team any favors by forcing yourself into an impossible position.
(2) Your team won't understand the pressures that are driving the business. Having a nice, relaxed work-week is great, but employees should at least be aware of high-pressure situations in the business.
(3) Your team will get bored. Great teams like to work on challenging issues, and high-impact engineers like to work on high-impact problems. They want to grow. Exposing people to issues outside of their direct control and comfort zones will actually help make them more satisfied at work, even if it does come with a little added stress.
These are issues that I've been working on, personally, for years. The gut reaction of "protecting" teams is often times not the best one for anyone involved.
I've never experienced a manager who seemed really in tune with how I think one should treat people. They usually intend well, but effusive over the top praise makes me uncomfortable for several reasons;* the only thing worse than that is demanding contradictory or impossible things.
It seems to me that a leader needs to be a like a coach. I haven't even ever played team sports, but it seems intuitively obvious to me that you reward people by gradually trusting them more as they prove themselves, and continually stretching what is asked of them to find limits and what fits them best. And you shape everything around the good people you can find, rather than trying to get people who are plug and play for a pre-existing approach.
The hard part I think is that it is so easy to ask far less of someone than they are capable in one area, and more than they are capable of in another. Both can lead to demoralization or even disaster.
*If you're continually praising me, it starts to seem as though you had low expectations and you're not raising them fast enough. Or you think I'm easily manipulated.
Regarding 1st point: If you manage people-this is inevitable. I had plenty of situations where you know way more than you can tell anyone,yet you neet to put a face on just so could people carry on working. In most cases it's better for one person to be worried rather than the entire team.
Are we talking about business decisions? My experience is, that developers are only interested in taking that risk, if they also get a share in the company and get access to internals. "Your house, your decision, your money. We are just the hired gun to do the carpenting."
However, granting visibility to decisions (and the information that leads to them), when possible, is a great tool.
A generic example might be that a major client will sign onboard if a new API feature is implemented. Just asking a development team to build the feature will get it done, but in my experience, teams will feel significantly more included (and important) if they have the context of why it needs to be built.
The decision to pull resources off of already-planned tasks to build the new feature shouldn't be made by the developers, but understanding that they're helping the business in a major way can really help cohesion, inclusion, and perceived impact. Those are things that make people feel fulfilled and important at work.
Some do, some don’t. If a developer wants to start their own company or move into leadership in a larger company then they need to start thinking this way. There is a vanishingly small number of senior ICs/researchers who get paid the big bucks to work on purely self-determined technical problems. It’s much easier to just learn a bit about business.
