How to save time as a manager

You are a software team lead. You have managerial responsibilities and tasks. Your job is to make sure that the team delivers, not only yourself.

However, you must also work on product tasks in order to bring direct and immediate value.

[Warning: here starts the cynical part]

In these situations, it is advised to utterly stop or to reduce the quality and time spent on the following activities:

Non technical activities:

• 1:1s — better build products than build people. People building takes much longer and what if the employee decides to leave? Then it’s all a big waste. Definitely do not summarize important points for follow up and for annual performance review data, you’ll surely remember them all.
• Growth — similarly, growth ideas and help with personal plans for engineers who want to grow is wasteful. They are adults and they can come up with their own plans. Employee retention can be done by purchasing table tennis equipment anyway.
• Coaching and mentoring — again, they take up time of at least two people each time. Real engineers can learn from the internet.
• Strategy thinking — prefer immediate tactics over longer term strategy. You can’t predict the future.
• Knowledge sharing sessions — they should be discouraged as they waste a lot of time for all engineers involved. If someone has information to share, they can send an email.
• Training and Workshops — ask your reports to pay for online courses and expect them to work on it after work.
• “Friday Lab” /education / experimentation / exploration / learning time — sounds nice in theory, but has no tangible value.
• Conferences —a tremendous time sucker, including trips and hotel expenses. All videos will be online anyway in a month.
• Planning — like the old saying: “weeks of work can save you hours of planning”.
• Plan your day — you will only work on tickets and react to requests, so this is redundant.
• Hiring — coming up with a precise job description, preparing interview questions, checking home challenge and interviewing take a lot of time when done thoroughly. What you can do instead is look at very good GitHub repositories and send messages to the creators.
• Documentation — documentation is obsolete the moment it’s written. Of course it brings zero value, and sometimes partial or even misleading as no one will update it on time.
• All-Hands meetings — better do some real work. The slides will be shared containing mostly partial and non important information.
• Organizing — a big no. You get paid big bucks for working on features. You spending time helping moving tables and chairs, or cleaning up after yourself is a negative ROI.
• Professional and social responsibilities — you might feel like volunteering to take responsibilities, such as fixing the build server, writing a technical blog post for the company, or help organizing the Christmas party. You must remind yourself that these activities will not contribute to the product.
• Diligence — you’re spending too much time preparing for meetings, presentations, knowledge sharing, etc. Try to send bullet points and missing information and only supply it upon a request. See how others come unprepared and the sky doesn’t fall.
• Decision making — postpone any decision, just carry on, in order to not spend time gathering information and analyzing it.
• Team lunch/breakfast — you socialize enough in meetings and through code reviews. You also send memes on Slack, so better save the time.
• Coffee breaks — no real inter-team information and making real connections with colleagues, only gossip, so better avoid.
• Help other teams — how will it be presented in your team’s graphs?
• Optimize for the benefit of the department/company — again, not measured. Only behave according to how you’re measured, and this means tickets done.
• Asking questions to get information about requirements — this only presents you as weak and unprofessional. Better do what you understand quickly and fix later if it’s wrong.
• Communicate blockers and technical trade-offs — same problem — you’re senior, experienced and a leader. Your reputation cannot afford to be blocked or stuck.
• State cost of alternatives — when directed to build something, go ahead and do it. Listing possible cheaper solutions will only insult and imply that they haven’t thought of all possibilities until you showed up to the rescue.
• Meetings — you can always fake a surprise interview or work from home with bad internet, so you can continue to do real work. In case you have no choice, bring your laptop and continue working during the meeting. Only participate when being mentioned more than once.
• Classes — some workplaces offer various classes that have nothing to do with work, like, language class. You’ve got some nerve attending them when there is work to be done.

Technical activities:

• Code reviews — performing thorough code reviews takes a lot of time, but anyway we’ve got linter tools today, and most bugs are not found during it. Who cares how the code looks like if it works?
• Quality code — can the compiler understand you code? It does what it’s supposed to do? So why would you insist on being a perfectionist? All books were written for marketing purposes, don’t take their advice seriously.
• Incidents resolving — only resolve the incident itself, never fix the root cause or share a post mortem. Next time this happens — you already now how to fix!
• Logging — adding good logs in the right places with the right information will trigger a new pull request, code review, running automated and manual tests and a deployment. What a fuss, where you can debug locally instead.
• Monitoring and alerting — even worse than logging, as they require more infrastructure in all environments. Let’s wait for clients to tell us that something is wrong.
• Stable infrastructure — this is real art and also needs constant hand holding as new features and different loads are introduced. Simpler to just terminate that faulty instance once a week.
• Operational improvements and automation — the myth promises that it will save time later, but we care more about the now.
• Refactor — it’s common to refactor code that is being touched, but the code would work also without it, right? And this will be true for each and every case.
• Automated tests — what is more time consuming than covering code with coupled test code? Anyway, we have logging and monitoring to catch problems. Ah, no, we don’t. So, the clients will let us know. It’s the manual QA’s fault if they didn’t find an issue.
• Performance optimization — either speed, memory or CPU — why fix if it ain’t broken? Wait for recurring complaints from several clients.
• Security considerations — we all know that it will hinder testing and will mostly annoy us in the day to day work. What attacker cares enough about our company to attack it?
• Address recurring alerts — just learn which ones to ignore. Removing them from the code will take time.
• Track time, velocity and quality of the team’s output — no need as you anyway work on ticket after ticket, so it won’t make any difference.
• Architectural changes based on near future needs — maybe they will not be necessary after all? Let’s wait for real problems and then address the issues.

It was cynical, and it might happen in one level or another in every organization, depending on the company’s maturity level and the business urgency.

But these are activities that managers should be doing in order to allow for the near future needs and to actively build people.

Effective leadership is learned
To learn more or reach out, visit my website or LinkedIn