Ask HN: IT Directors and VP's – how do you manage your time and projects?
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.
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).
> strongly consider keeping your mouth shut if that way is only 5% better
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).
If the director is smarter and more knowledgeable about the engineering domain, he should overrule. that's what the big-picture strategy is all about, some people make it into leadership because they are really good and capable at engineering. So long as they stay sharp, they can still make technical decisions.
Not really, in my experience. If it’s a real director position rather than in name only you simply don’t have time to get into the details enough to be good at this - if you have enough context you aren’t doing your real job well. This can feel like positive contribution but you are actually slowing down the entire group.
What you should be doing is focusing on making sure the decision making process is working well and that you are all learning from issues. If you have an idea you think is better, by all means hand that off to the team. But you have to let them decide against it (so long as they can articulate why). Absent strong empirical evidence that the path is wrong, you go with their choice and discuss how to validate it.
In all cases except team incompetence you are better off this way in the long run. And if the team is incompetent, you have bigger problems.
That might lead to the best technical outcome (if the director is actually right!). But the message it sends to subordinates is incredibly damaging. If a leader really needs to pull rank because they can't explain why a different approach is worthwhile, either they're not a good communicator, and/or their subordinates are incompetent. And this discussion should only be occurring for major, irreversible decisions in the first place.
Agreed. A leader needs to be capable of indirectly & positively influencing the team's architecture and overall technical outcome while not doing so explicitly (manage down, up and out). The team needs to drive and come to their own conclusions, but a true leader can positively impact the vision and strategic execution.
Everyone thinks they're smarter or more knowledgeable and will then always jump in
> 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.
This tendency is very common, and it results in the Peter principle: https://en.wikipedia.org/wiki/Peter_principle
This is exactly the problem I see with my division's supervisor. He was a developer, and is now a program manager, but he wants to directly influence every single project instead of delegating. What is an effective way to encourage him to do his new job?
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.
Well you have a few options. You'll have to gauge your own situation to see what you can get away with.
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.
I've done #2 a number of times, and #1 is a great idea, too. If I keep him focused on #1, it'll be harder for him to hop the line.
I think that depends on what you think his new job actually is, and if that actually aligns with what they think their new job is.
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.
> Related, if you can see a better way to do it, strongly consider keeping your mouth shut if that way is only 5% better.
Great advice. Thank you!
I'll steal a quote from Pittsburgh Penguins (American professional hockey) head coach Mike Sullivan: "Play the game the right way".
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:
List for mobile:
> 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.
This is a great list; thanks for sharing!
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.
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.
I think this is an excellent way to look at the situation.
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
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).
http://shop.oreilly.com/product/0636920056843.do
I’ve upvoted this, but want to underline that this book is truly excellent.
I’ve watched many people in these roles, and had them at various times.
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.
More meetings seems like a bad cliché, but it's really the most impactful activity.
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.
Check out Will Larson's post on time management.
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/
Huge value here - great to see another tech->mgr telling their story about how they got better.
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.
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.
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:
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.
Here's a lens I use to think about my job that might make sense to someone with an engineering background:
- 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.
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.
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.
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...
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.
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 and 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.
About Linus: no; he's an architect.
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.
Agreed - my situation is currently a team of 20, but previously up to 75 in my org. I work for a mid-sized company that's ~2500 people in total.
What made you successful in the past may not make you successful today.
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.
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.
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!
I think the Peter principle, the idea that people are promoted to until they are incompetent in their roles, comes into play.
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.
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.
Diving in on GTD and have thus far really been converted. Having a system - _any_ system, is critical. It became clear pretty quickly that my "system" was just me using my head and brute-forcing my way through things.
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.
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.
> Build good-will and political capital in your organization.
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.
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.
When I was a direct report for a CIO of a fairly large multinational (40+ countries) my boss spent most of his time on the road travelling - he had a gruelling job. He was completely hands off when to technology - although he was actually fairly technical.