Answers That Depend: Tech Leadership Q&A, pt 2
More of your questions from the newsletter and podcast
Once again, I’m diving into the mailbag to answer your questions. If you'd like the extended, audio version of these questions and answers, you can listen to the latest episode of the podcast.
Fostering Learning Without Big Resources
From Jamal in Lagos: I'm leading my first team of backend developers for an API optimization project. I want to build a learning culture, but we don't have access to the expensive training programs I see discussed in Silicon Valley tech circles. What are some practical ways to encourage continuous learning without significant financial resources?
Jamal, congratulations on your new leadership role! The good news is that there has never been a better time to be in your situation. The amount of free, high-quality learning resources available today is staggering.
Begin with the treasure trove of conference talks now available for free on YouTube and conference websites. Many engineering conferences post their entire catalogs online, providing you with access to the same insights without the need for travel costs. Pair this with the explosion of technical blogs, podcasts, and newsletters - there's more quality content than your team could ever consume.
If you're using cloud providers like AWS, they often provide training materials at heavily discounted rates or even free for existing customers. They have a vested interest in helping you become more proficient in using their services.
For in-person learning, consider starting a local meetup if one doesn't exist. Your company office, a café, or a library can work as venues. Organizations like Lead Dev often support local meetups, helping you get started and connect with other tech professionals in your area.
As the team lead, you can actively curate learning for your team. Try a weekly practice where everyone shares a blog post, podcast episode, or conference talk on Fridays. This practice builds a shared learning culture and reading list that benefits everyone.
The key is consistency and making learning a visible part of your team culture, not just something people do in their spare time.
Building Your Personal Retrospective Process
From Emma in Portland: I've been expanding into an unofficial leadership role in SRE work and want to implement structured personal retrospectives, similar to our post-incident reviews but focused on my leadership decisions. Do you have practical frameworks for weekly or biweekly personal improvement? Right now, I just dump thoughts in a Google Doc while drinking too much cold brew on Friday afternoons.
Emma, I love that you're thinking about applying engineering practices to personal development! Your cold brew and Google Doc approach isn't actually that bad - the important thing is that you're reflecting regularly.
Let me share my structure, which has evolved over the years. I work on multiple timeframes: a formal six-month process (which I've written about), quarterly check-ins, monthly reviews using bullet journaling, and weekly retrospectives.
For weekly reviews, I have four core questions that I ask myself every week: What is going well? What is not going well? What should I be doing differently this week? What have I learned?
I also perform some practical maintenance each week, including updating my calendar for the upcoming week, reviewing my time allocation tracking from the previous week, reviewing my bullet journal pages for missed tasks, and clearing my email flags.
The monthly process involves reviewing the previous month, checking in on quarterly goals, and utilizing the bullet journal migration process to advance incomplete tasks. I also try to set a monthly goal with a clear plan for achieving it.
Here's the critical part: these processes have evolved constantly over the years. I used to track my daily gratitude and things that brought me joy, but I found that they became less meaningful when forced into a daily task format. You need to see what works for you and be willing to change it when something stops adding value.
The goal isn't to perfectly follow someone else's system; it's to establish a consistent practice of reflection that helps you improve over time. Start simple, be consistent, and evolve the process as you learn what's most valuable for your growth.
When Change Management Gets Stuck
From Daniel: I'm facing persistent challenges with departmental heads who seem reluctant to embrace our new engineering practice standards. They verbally commit in leadership meetings but show limited follow-through. I need to accelerate adoption across four engineering divisions before our Q4 infrastructure consolidation. What strategies work for bringing established middle managers on board?
Daniel, I'm going to give you an answer you might not like, but it's an important one. Sometimes, despite your best efforts at organizational change management, people won't come along for the ride.
First, do the detective work. Are these middle managers actively blocking change from reaching their teams, or are the teams genuinely committed? Understanding whether this is a management layer problem or an organization-wide resistance issue will inform your approach.
If it's truly centered on the middle managers, you need to understand the root cause. Are they scared of the change? Do they not understand it? Do they fundamentally disagree with it? Have one or two influential people convinced the others to resist?
Once you understand the why, you can try targeted approaches, such as finding champion skeptics, working directly with individuals, and providing additional context about business drivers. But here's the hard truth: if these folks have been successful for years doing things a certain way, and you can't convince them that change is necessary, you may need to make difficult decisions.
Sometimes, organizational transformation requires changing the people, not just the processes. If the change is truly necessary for your company's next stage and you can't get buy-in despite reasonable faith efforts, you may need to move people out who aren't aligned with the new direction.
This isn't about being heartless. It's about recognizing that sometimes you can't bring everyone along, and continuing to chase reluctant managers can hold back the entire organization.
Balancing Urgent Fixes and Long-term Architecture
From David in healthcare: I'm caught between implementing quick patches for an imminent release deadline and my architectural vision for a more secure, regulation-compliant data handling system. Our CTO wants immediate results, but I'm concerned about technical debt in our patient records module.
David, your CTO might be right, and I'm not just saying that as a fellow CTO. Make sure you understand why they want immediate results - there might be business factors driving this decision that you're not aware of.
More importantly, make sure your CTO understands your perspective. Put detail and context around what you're advocating for. Explain the specific risks and long-term consequences of the quick fixes.
After this conversation, the CTO might still say, "I hear you, I understand you. We still need to do this now." If that happens, listen to their reasoning. There might be customer demands, regulatory deadlines, or other business pressures that make the short-term approach the right choice, even if it's not ideal.
This is part of the leadership job - sometimes, we have to make decisions we're not happy about because we're responsible for outcomes. Your job is to ensure the decision is made with complete information and then execute the chosen direction.
Starting Out as the First Data Engineer
From Mina: I joined a logistics startup as their first junior data engineer two months ago. I'm feeling overwhelmed with pipeline tasks from different teams while trying to set up analytics infrastructure foundations. How do I balance immediate needs versus long-term architecture work while still learning so much myself?
Mina, first off - being hired as a junior person to be the first in a new function is a tough spot for any company to put you in. Usually, you'd want a senior person to establish the function and mentor junior hires.
Take some pressure off yourself. You're not going to solve the company's long-term data architecture in your first few months, especially while you're still learning the field. That's an unreasonable expectation.
Instead, focus on solving the problems directly in front of you and doing your absolute best to solve them sustainably for now. Use each problem as a learning opportunity. Six months from now, you'll look at today's solutions and think, "I could have done this better," - and that's when you improve them.
The best thing you can do for your career right now is become very competent at this job. Focus on being a good problem-solver and learning to iterate on your solutions. Architectural thinking and long-term planning skills will develop as you gain experience.
If possible, try to find a mentor, either someone else in your company or someone you meet at local meetups who can provide guidance as you navigate these early challenges.
When Product and Engineering Have Separate Roadmaps
From Sophia: I'm leading a cloud migration product team and constantly hit roadblocks from our engineering counterparts, who seem to prioritize their own roadmap items over our initiatives despite strong customer feedback. How do I better navigate this political landscape without appearing territorial?
Sophia, the issue isn't really about politics - it's about your team structure. If engineering has its own roadmap and the product has its own roadmap, that's broken.
Engineering shouldn't have a separate roadmap when it impacts teams with product managers. There should be a single roadmap for the team, negotiated between the product manager and engineering lead, that encompasses both product features and the necessary engineering work.
In a healthy team, the product manager owns the prioritization of the backlog, which contains both product items and engineering items. It's a negotiation - sometimes it'll be product-heavy, sometimes engineering-heavy, depending on current needs.
When you have two separate backlogs, you get exactly what you're experiencing: two teams fighting over what's more important, with critical company work not getting done.
Discuss with your engineering counterparts the benefits of working as a unified team with shared accountability. Ensure they understand the customer feedback that drives your priorities, and ensure you understand why they're advocating for their engineering work. Then, negotiate a single backlog that both teams agree represents the most critical work.
This isn't about politics or stakeholder management tactics - it's about fundamentally changing how your teams collaborate. Without that collaboration, you'll continue to struggle with competing priorities and territorial battles.
Thank you for your questions! Please send me more!
Keep sending your questions to contact@itdependsbook.net or reach out on Blue Sky, Twitter, or LinkedIn. I'm collecting questions for future episodes and newsletters, and I love hearing about your challenges.
Until next time, remember: the best answers usually start with "it depends."
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores