Related, if you can see a better way to do it, strongly consider keeping your mouth shut if that way is only 5% better. If you improve the project by a few percent and sap your report's motivation and confidence by 50%, you're probably not making things better for your company. Save your insights for times where you think your way is 50+% better.
In short, if you are overwhelmed, make sure you're doing your executive job. If you're not, consider still spending more time on reading and thinking rather than defaulting to pitching in on a project deliverable if it isn't written in English prose (feel free to work on a project high level summary, objectives, and key results document).
That's great advice. An experience with a director overruling his engineering staff is one reason I no longer work for him.
As a leader, your most valuable asset is context: big-picture strategy, business priorities, and the like. If you're in an interaction where you find you're not utilizing that asset, you probably should back off and let your reports do their jobs (unless you're mediating a dispute, but even there you should help people work together better—not just pick a side).
This tendency is very common, and it results in the Peter principle: https://en.wikipedia.org/wiki/Peter_principle
This is impacting the team b/c he takes away lower level decision making responsibility, while not spending the time he needs to spend planning out and setting top level vision.
1) Ask him for his deliverables to you frequently. If he's a program manager, presumably part of his job is to fill you in on context and the goings on outside of your group. Ask him for those regularly. Ask him to present the planning and top level vision.
2) Be direct and tell him what you just wrote -- that you expect him to delegate and trust and not dictate now that he's been promoted.
Every manager has different ways to lead, every person has different behaviors that make them more or less likely to follow someone who is leading. The whole team needs to work out the right dynamic and be truthful with each other and managers need to be truthful with their employees as well as with themselves.
It may turn out like it often does, great developers who understand the product and project inside out don't automatically make them great managers
You likely also got very good at your job just by doing it A LOT. Give that person the benefit of the doubt and some time to grow into the role. Just like you will have to for your new role.
Great advice. Thank you!
Just do the right thing. Always. If you're not sure what that is, figure it out however you can, and do it. This time. Every time. Always.
Once you start doing that, all the other BS melts away.
A few personal thoughts of what "the right way" means in IT:
- Treat everyone else like you want to be treated. No "talking down".
- Got Business Requirements? Are they any good? That may be your problem.
- Same thing for Technical Specifications.
- Same thing for Test Plans.
- Is everyone working on their most important thing? Why not?
- Will it affect the annual report? Yes? It's an issue. No? It's a detail.
- Keep the process that's needed. It helps.
- Ditch the process that's not needed. It hurts.
- Go with your gut. That's what got you here.
- If it needs changed, change it. If you don't, it'll change itself some other way.
- Correlation != Causation.
- Know the Critical Path.
- Keep your finger on the pulse of everything you can.
- Programmers produce. Everyone else must support them. (Never forget this!)
- If it's not written down, it's not.
- Relax and have fun. Can't? Find another career.> Treat everyone else like you want to be treated. No "talking down".
> Got Business Requirements? Are they any good? That may be your problem.
> Same thing for Technical Specifications.
> Same thing for Test Plans.
> Is everyone working on their most important thing? Why not?
> Will it affect the annual report? Yes? It's an issue. No? It's a detail.
> Keep the process that's needed. It helps.
> Ditch the process that's not needed. It hurts.
> Go with your gut. That's what got you here.
> If it needs changed, change it. If you don't, it'll change itself some other way. > Correlation != Causation.
> Know the Critical Path.
> Keep your finger on the pulse of everything you can.
> Programmers produce. Everyone else must support them. (Never forget this!)
> If it's not written down, it's not.
> Relax and have fun. Can't? Find another career.
What this requires is
- people you can trust
- you actually trusting them
- being able to identify relatively self-contained tasks you can delegate
- being able to accept that you'll get less competent in things you're delegating
Ofc. there's much more to this, there are plenty of books, courses, schools about leadership and management, but I think the core issue is that you should concentrate of make yourself not required.
From a psychological POV (e.g. ego & identity), this aspect was particularly significant to me as I moved from developer to manager to CTO and then CIO:
> - being able to accept that you'll get less competent in things you're delegating
One of my takeaways was this. Everybody has a system, but it’s not that important what the system is. What is telling is what happens in a “challenging situation”. Is your system what you rely on to get you through it, or is it what you abandon when the chips are down - only to pick up again when things cool down? In my experience, the people in the former category perform much better, with fewer surprises. If that isn’t you, ask why.
I’ve seen people do this well using everything from a fully manual system (engineering notebook/journal) to total commitment to something like omnifocus to a sort of personal wiki to one based on emacs .org mode. I think the key is to find (and customize) a system that is comfortable for you and you trust - and make it very easy to use. Simpler is probably better.
Another thing to note, the first time you have an EA you’ll have to adjust your patterns to make both of your time more effective.
One last thing - how effective do you feel you are at delegating? The bigger the group under you, the more you have to let go of details to keep your focus where it matters. Communication trumps almost everything else.
Meetings with customers (internal and external). They need to trust that you: a) understand their problems b) will commit to a service level agreement c) will convey the needs to your team
Meetings with team. 1:1 with each member at least once every 2 weeks.
Make sure to understand their personal situation. SO's name, kids, anything going on that might risk churn.
Make sure they are aligned with customers needs. Empower them to meet with customers directly and form their own solutions.
Follow-up on their concerns and "surprise" them with actions that show you were really listening.
Pipeline Always be recruiting, refining job descriptions, interviewing, and hiring.
Technical Strategy It's the thing technologists love most. But at Sr Management level you're empowering teams to choose frameworks/languages, building alignment, and helping them make decisions to move forward.
Note that I don't mention politics in any of the above. If you gain the trust of customers and employees in 1:1 meetings above, this should preemptively mitigate politics.
https://lethain.com/time-management/
He has a lot of great posts on leadership and management; here's a collection of some of them- https://lethain.com/rails-for-engineering-leadership/
Your key objective is to get people in place to operate independently. You need empower your people so they are managing the projects.
If you’re doing a lot of heroic tasks, especially in a bigger org, you’re approaching the ceiling in terms of advancement and ultimately doing a disservice to your people.
http://www.paulgraham.com/makersschedule.html
Probably posted a billion times here since y combinator is just one of the things that derived form the work of the master Paul Graham.
- I'm in charge of architecting and building the team. the team is a system, of people and processes
- the team has various functional and nonfunctional requirements which i product manage
- I surface how the team works in general to our stakeholders, and our team strategy mainly deals with adjusting our "interface" and performance
- I also surface our team's current plan and how we're tracking, to the appropriate stakeholders, to give them context if we want to adjust how the "system" works
- I don't do any tasks other than those that relate to the above
- I don't try to heroically post-process or supplement the machine's performance through my personal efforts unless it's just really high leverage in that situation. (would have to be live or die almost, otherwise not worth it in the long run). I spend my efforts on adjusting the characteristics of the machine.
We use a ticketing system that enforces a minimum amount of process and otherwise stays out of our way (RequestTracker, highly recommended). I keep the master project list in a text file. We have a weekly status meeting where the master project list is 80% of the agenda. The meeting usually lasts about 30 minutes unless we have something particularly deep to discuss, design or dispute.
We keep in close contact with our chat system, email, and in-person meetings when people feel like they need them.
Every morning I review:
- tickets generated by alerts. Did they get handled properly?
- new tickets from users. Have they been picked up?
- master project list. Does anything need my expertise?
Throughout the day I look for signs that I should help people with their tickets or projects. Occasionally that means solving the problem for them, but usually it means pointing them to the right documentation or acting as their rubber duck.
Another chunk of my time is spent in diplomacy with other people in the company and sometimes with customers.
Startups, especially early ones, throw this all out of the water of course. But once you hit 100+ employees the "real world management" starts to come into play.
If they are busy you should focus on getting more resources - as well as improving the productivity of the team.
The small business owner very likely has to wear more than one hat due to the size of his staff. This discussion is in the context of an organization likely much bigger than most small businesses of the kind you describe. The organization is inside a company that is in turn bigger. I don't think that a direct comparison useful.
When I started to prioritize, delegate and only focus on key details, it was a big shift in mindset but also a big boost in my effectiveness as a VP.
Know when to say things and when not to say things. Let go and think big picture. You're in the business of delivering through your team and your role is about giving direction to your team so their work is meaningful to them and to the organization.
Not everything will need your attention - you mostly only need to know when the project will be completed, help your team unblock roadblocks (in terms of tech, process, people) and align all projects to the overall strategy.
Basically, you don't manage your time. You use it. What are you trying to accomplish, how many resources do you have?
There are goals, you set, and there are bottom-up driven innovations.
The feeling of being overwhelmed is a good one as long as drowning in ideas not trouble. ;)
I try to have a decent team around me to help me get my goals done. The rest is hard work, there is no happy path to leadership/management. Dealing with VUCA is the price you pay. This is part of accepting being a manager. I read a lot of good business books, talk to trusted colleagues and set timt to focus on strategic topics.
Enjoy your career, learn and have fun with the people!
What worked for you to get to the job isn't necessarily going to work for you to succeed in the job, I agree with others saying that it's not a time management issue, it's a change in perspective that's require, you no longer have the ability to do everything for everyone, you now have to lead people you can trust to fulfill those tasks better than you could, as your responsibilities grow, the rest of your team doesn't stay static, they also grow with you.
2. You'll start to see why GTD got so popular, you need a list of things you can do. GTD's Agendas & WaitingFor lists are for you.
3. If you don't have an ea/admin you trust, you need to get on that. The best chief of staffs I've ever worked with started as EAs. They should be able to grow into HR, Finance, or Program Management, or chief of staff.
Pick two thresholds:
- Maximum amount of time you're willing to allocate to a specific task. (Example: 1h. FYI, David Allen of GTD fame recommends 5min for very senior execs.) Try to delegate anything above that number.
- Amount of time you'll take you to get it done vs amount of time it'll take one of your directs or skips to get something done. (Example: a task that you could do in 1h will require 10 man-hours if done downstream.) Pick a number and try to delegate anything that requires less downstream effort.
When it comes to delegating, remember: back when you were an engineer or a new manager, you sucked at what your boss was delegating to you, but you managed to produce something that was good enough and you became better at it with time. Your directs and your skips will learn too.
Also:
- Learn how to hire. If you're managing managers you absolutely want dependable directs who you trust will get done whatever stuff you delegate to them. And frankly, the same holds when you're managing engineers. (As an aside, a common mistake in early stage startups is to let the founders or HR hire for you; you're going to be the one managing whoever gets hired, so push back if you've no say over who gets hired.)
- Put a weekly 30min 1:1 with all of your directs in your calendar if you're not doing so already. It'll save you lots of interruptions because your directs will know they've some time allocated for less urgent stuff, and it'll allow you to surface incoming problems before they blow up in your face.
- Ax the time you spend on email to free up your calendar. Pick 2 or 3 time slots during your day. (Example: early morning upon arriving, before or after lunch, and before leaving.) Block those slots in your calendar. Only do email during those time slots. (Close your Email client and turn off notifications. If anything's actually urgent, your phone will ring.) Also, create filters to surface what's important and what's not. (Anything cc'd to you or not sent to your email directly probably isn't high priority; stuff sent by your boss or by your directs probably is.)
- Block a few hours in your calendar to actually get your own work done. Part of your job arguably is to be available, but if your calendar is wide open it invites your coworkers to swamp you with meetings. And be picky with meetings. Unless it's coming from your boss, refuse to join meetings that don't have a clear agenda. (Send one of your directs instead.)
- Build good-will and political capital in your organization. At senior levels, I'll scratch your back if you scratch mine tends to count a lot. So don't hesitate to spend a half hour every so often with other managers that deal with stuff your teams have interaction with to catch up. (There's no point in building a new product if the heads of marketing and sales don't both think there's a market.) Don't confuse this with schmoozing, else your weekly or fortnightly meeting will be first to get binned when calendar time is scarce. But work on those relationships.
It’s very easy to overlook relationship building. Even just stopping by, saying a quick hello, and giving a smile to execs in different departments can make a world of a difference in how well your departments can work together. This can make a big difference at whatever level you’re at in your career but is especially impactful the higher you go up the ladder.