Over the course of my career I've been fortunate to have able to develop as an engineer and sysadmin, and did very well at tackling the projects and tasks that came with those roles. With success in those roles, I found pleasure in managing people and technology, and worked to get promoted to manager, and later director and VP roles in my organizations. The challenge I have faced the further up in the org I go is in changing my work style, tactics and approaches to be more effective. I often find myself overwhelmed with tasks, while projects also need attention. The question for HN is: How do senior level technology managers, directors and VP's manage their time, projects and tasks to be effective at those levels?
You need to stop doing your old job and start doing your new job. That sounds obvious, but I see a lot of people get promoted and keep doing their old job, the one that they were so good at it and came so naturally. Even if the new person in your old job is only 25% as good as you are at, let/make them do it.<p>Related, if you can see a better way to do it, strongly consider <i>keeping your mouth shut</i> 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.<p>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).
I'll steal a quote from Pittsburgh Penguins (American professional hockey) head coach Mike Sullivan: "Play the game the right way".<p>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.<p>Once you start doing that, all the other BS melts away.<p>A few personal thoughts of what "the right way" means in IT:<p><pre><code> - 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.</code></pre>
This is not about time management at all. Many new execs mess this up -- it's not that you need to get more organized (or mostly not); you need to build a system that doesn't require you to intervene all the time.<p>What this requires is<p>- people you can trust<p>- you actually trusting them<p>- being able to identify relatively self-contained tasks you can delegate<p>- being able to accept that you'll get less competent in things you're delegating<p>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.
I highly recommend reading "The Manager's Path" by Camille Fournier. It's a great overview of the different things to consider while working your way up the ladder (specifically in engineering management).<p><a href="http://shop.oreilly.com/product/0636920056843.do" rel="nofollow">http://shop.oreilly.com/product/0636920056843.do</a>
I’ve watched many people in these roles, and had them at various times.<p>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.<p>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.<p>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.<p>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.
More meetings seems like a bad cliché, but it's really the most impactful activity.<p>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<p>Meetings with team.
1:1 with each member at least once every 2 weeks.<p>Make sure to understand their personal situation. SO's name, kids, anything going on that might risk churn.<p>Make sure they are aligned with customers needs.
Empower them to meet with customers directly and form their own solutions.<p>Follow-up on their concerns and "surprise" them with actions that show you were really listening.<p>Pipeline
Always be recruiting, refining job descriptions, interviewing, and hiring.<p>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.<p>Note that I don't mention <i>politics</i> in any of the above. If you gain the trust of customers and employees in 1:1 meetings above, this should preemptively mitigate politics.
Check out Will Larson's post on time management.<p><a href="https://lethain.com/time-management/" rel="nofollow">https://lethain.com/time-management/</a><p>He has a lot of great posts on leadership and management; here's a collection of some of them- <a href="https://lethain.com/rails-for-engineering-leadership/" rel="nofollow">https://lethain.com/rails-for-engineering-leadership/</a>
You can’t directly manage more than a half dozen people, up or down. If you’re in a place with heavy management, that’s something you need to work with.<p>Your key objective is to get people in place to operate independently. You need empower your people so they are managing the projects.<p>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.
That's a conundrum that most developers who climb the chain face and the best article I've read so far that comes close to answer it is this one:<p><a href="http://www.paulgraham.com/makersschedule.html" rel="nofollow">http://www.paulgraham.com/makersschedule.html</a><p>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.
Here's a lens I use to think about my job that might make sense to someone with an engineering background:<p>- I'm in charge of architecting and building the team. the team is a system, of people and processes<p>- the team has various functional and nonfunctional requirements which i product manage<p>- I surface how the team works in general to our stakeholders, and our team strategy mainly deals with adjusting our "interface" and performance<p>- 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<p>- I don't do any tasks other than those that relate to the above<p>- 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.
My job changed from doing all the things to (a) picking which things should be done and (b) making sure that all those things get done.<p>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.<p>We keep in close contact with our chat system, email, and in-person meetings when people feel like they need them.<p>Every morning I review:<p>- tickets generated by alerts. Did they get handled properly?<p>- new tickets from users. Have they been picked up?<p>- master project list. Does anything need <i>my</i> expertise?<p>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.<p>Another chunk of my time is spent in diplomacy with other people in the company and sometimes with customers.
The path towards management means less coding, especially the higher you are. VP/CTO/Director shouldn't be coding at all. Your job is managing the people and tech, guiding, mentoring, hiring...<p>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.
Are the people who work for you busy as well? I'm great at taking in all the extra work and not delegating. Often its because the people under me dont know how to do something - they should be able to figure it out, I'm just not good at forcing them do it.<p>If they are busy you should focus on getting more resources - as well as improving the productivity of the team.
Would you classify someone like Linus Torvalds as a manager <i>and</i> an individual contributor? I see a lot of obsession with pigeonholing and defining roles with zero degrees of freedom. "A manager needs to stop doing ____ and needs to start doing ___". Who's making these definitions? I know plenty of small business owners who are quite successful at wearing both hats. I personally don't have a problem if someone out there decided that in order to be an effective leader they have to abandon their previous responsibilities entirely, but I don't see how that becomes a universal rule. Just because everyone else is doing it doesn't make it right and no longer worth looking at.
What made you successful in the past may not make you successful today.<p>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.<p>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.<p>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.
Delegate is the keyword. You have to trust and not worry about the details. You can't be solving all the problems. I've had my reporting team come to me seeking a solution, I tell them to go solve it and come with the solution. I can review the solution and give a fast feedback if they still have concerns. More often than not, when they think about it, they come up with what works. The more responsibility I give to them, they more they step up to the plate and start filling in those big shoes. Just 1on1s, business partner, vendor meetings & daily status update is enough to fill my entire week.
Cool question.<p>Basically, you don't manage your time. You use it. What are you trying to accomplish, how many resources do you have?<p>There are goals, you set, and there are bottom-up driven innovations.<p>The feeling of being overwhelmed is a good one as long as drowning in ideas not trouble. ;)<p>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.<p>Enjoy your career, learn and have fun with the people!
I think the Peter principle, the idea that people are promoted to until they are incompetent in their roles, comes into play.<p>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.
1. Your calendar is your new todo list, if it doesn't fit, get rid of it. You're negotiating about your time. Review your calendar at the end of the week to ensure you're putting in time on the projects you need to.<p>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.<p>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.
It sounds like you're not delegating enough. This is key when you're managing, especially at a senior level. And not just technology-related stuff.<p>Pick two thresholds:<p>- 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.<p>- 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.<p>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.<p>Also:<p>- 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.)<p>- 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.<p>- 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.)<p>- 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.)<p>- 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.
Your tasks and projects are now high level politics and people management. Give up thinking of technology, at all, you now have to maximise the value of Your department to the business and the perception of your VP counterparts. I found similar issues rising thru management and (I’m mid-career) have changed roles to focus on what I enjoy rather than politics.
Thanks to everyone who took the time to add something to this thread. Lots of valuable stuff in here, and I've got some rearranging to do with my perspective, and how I think about my time and tasks. I'm sure I'll have more questions, but for now I've got work to do to get better at this.
Delegate ruthlessly. Get a 2IC/COO to deal with running operations, concentrate on strategy, people, ensuring your organisation is the right shape, value add.