"In many ways, I feel like my job as CEO and Founder is to absorb all of the insane parts of running a business so my team can focus on building, learning and enjoying their jobs."
This is spot on. I would extend to senior leadership in general.
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.
beautiful metaphor. anyway, I quasi-agree, though I've become suspicious of managers who claims to be an umbrella protecting their team from the rain. Half the time, they're really just trying to make sure their team doesn't see the forecast and quit.
Unfortunately, in my experience, I've had my fair share of "shit funnels" or "shit multipliers." That applies to any manager role, really.
As a former product manager, I think of it as being at the bottom of a canyon and shit rolling in from both edges of the canyon (business and technical). It's a hard job to do well and keep everyone happy.
such good PM/managers/leaders are very rare. Instead it is usually this way https://cheezburger.com/4626943488/corporate-ladder , just with even more levels in real life and resulting amplification of the signal.
I strongly disagree with this. You and everyone in your company are on a journey together, a leader who thinks that it’s their job to curate that journey inevitably fails. People know when you’re stressed or when things are tough... when you try to hide these things or deflect them away you erode trust and ultimately performance.
The role of a good leader is contextualize hard information and provide support for the team as they internalize it and then act upon it...
I'd be more specific and state that they should be consciously building systems to manage these things, even if it's done manually by them. This provides clarity about what and how things are being done, and let's them more easily scale (or kill) the process.
The kill part is important because when you are thinking systematically you're more likely to be able to communicate the details, or other people can observe it and make recommendations. It's hard to kill things that leaders are effectively doing in secret and stealing time and attention from an org.
> You and everyone in your company are on a journey together
Perhaps your comment was intended very narrowly, but this strikes me ... so not the way the 99.999% of people who are not in the founder/Valley/HN bubble think about their job. Chances are you employ these people, even at a small startup.
This is spot on. I would extend to senior leadership in general.