"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.
This is spot on. I would extend to senior leadership in general.
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.
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.
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.
- Good managers are shit umbrellas
- Bad managers are shit funnels
What you need are those clear plastic umbrellas, no rain, but all the sun.
Transparency.
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.
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.
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.
understand enough broader context to set direction, then distill, cut, and communicate what your team needs to know to do the work