From an environment perspective, having solid documentation supports stability and productivity. So let’s tackle a tough question: What makes good documentation?

First off, there's no such thing as perfect documentation—just like there's no perfect code. The key is producing and maintaining it consistently. Documentation requires a different thought process than coding; it's more creative and explanatory.

AI Summary provided by Audiopen.ai, the only AI tool I pay for (affiliate link)

This brings me to the Diataxis framework. It categorizes documentation into four types: how-to guides (practical steps for tasks), tutorials (learning-based steps), references (quick look-ups for APIs), and explanations (theoretical understanding). This framework helps determine what kind of documentation is needed based on its purpose.

Diataxis helps organize information but doesn’t dictate where it should live—that's up to each organization. It’s like agile processes; each team adapts it to their needs.

So does Diataxis provide insight into organizing documentation?

Not directly; it focuses more on categorizing content rather than structuring it within an organization. Each team must figure out their own system based on their dynamics.

You mentioned implementing a documentation council at work. How does that function?

Our council consists of representatives from each feature team who audit existing documentation and handle requests for new docs or updates. We meet periodically to review what we have and what’s needed, creating tickets for updates or new documents as necessary.

When someone requests documentation, how does that process look?

We kick off audits once every quarter or six months, review existing docs for relevance and accuracy, then create tickets for necessary updates or new documents based on feedback from teams.

In fast-paced environments like Dynamit, how would you implement such practices?

It’s challenging but crucial to allocate time for documentation even in fast-paced settings. Managers need to push for this time allocation while developers should embrace professionalism by thinking about future maintainers of their code.

How do you balance code comments versus external documentation?

Consider who will consume your code: API layers need explicit docs while feature teams might need detailed comments within the code itself. Capture feedback during onboarding to continuously improve your process.

If you don’t have a council yet, where do you start?

Start small by identifying passionate individuals who care about clarity in their work. Give them responsibility over documentation as part of their career growth trajectory—it’s low stakes but high impact.

Thanks for sharing these insights, Michael!

It's not something your end user will see, but it provides juniors and mids with tangible tasks to demonstrate leadership abilities. For others, it's an opportunity to improve things, which is a common goal. Junior engineers, curious about the code and still learning, might notice a lack of documentation. They could spend a day or two diving in, understand it, and present their findings to the team.

I've noticed a trend in organizations heavy on Slack or Teams using video for documentation. Tools like Loom allow for recording changes and explanations. Historically, we preferred written documentation as a contract with everyone. However, long documents can be overwhelming. A five-page document feels like a wall of text; even I struggle with comprehension without multiple reads. TLDRs help in understanding the core quickly.

Videos as documentation are great but come with challenges. Tech talks at our organization contain valuable information, but making them accessible and searchable is tough. Tools like Microsoft Stream offer solutions by uploading videos, generating transcripts using AI, allowing comments, and deep linking to specific sections. This makes videos searchable and collaborative.

AI tools are evolving to assist in documentation. Tools that grok APIs and generate documentation or transcribers like Otter that take meeting notes are helpful. AI tools can retrieve information efficiently but should be used cautiously for generating content.

The industry's direction seems to favor tools like Microsoft Stream becoming more available. Properly cultivated video documentation can be as essential as written docs for quick reference and communication.

As for AI tools in documentation, they can create knowledge bases isolated from the public domain. Integrations with platforms like Confluence make information retrieval easier. However, I caution against relying on AI for generating content; it's better suited for retrieval.

While AI can cover up issues instead of fixing them, we must scrutinize its output rigorously. Use AI as a tool without letting it replace human judgment.

Documentation is an investment for the future and those who will replace you eventually. For new engineers, taking extensive notes while learning can form useful documentation later. It's about professionalism and continuous improvement—start small, iterate, and build a documentation culture.

In summary: dedicate time to documentation, use frameworks like Diataxis for guidance, leverage AI as a tool (not a replacement), and focus on continuous improvement.

For further questions on documentation, I'm available on LinkedIn.

Welcome back to Ask Hartley Anything, the podcast where I tackle your questions and share lessons from my journey as an engineering leader. This is episode seven, and today we’re diving into two topics that are close to my heart. First, how do you manage your time and yourself when you're a manager expected to code? Second, sponsorship and recognition in leadership—how do you sponsor and recognize your team members effectively?

Summary provided by AudioPen Prime, the only AI tool I pay for. Goes from audio thoughts to transcribed summaries in whatever style you’re looking for. Love using this for long drives or walks.

Before we jump in, remember you can always go to askhartley.com to submit your questions anonymously or with your name. I love working through these questions because management is something you learn by doing, often impacting those around you. So thinking through these scenarios helps prepare for when they arise.

Let's start with balancing coding and leadership as a manager. Imagine you're a front-end lead managing four people while still expected to contribute to projects. You might think a 50-50 split between management and coding will work, but it's not that simple. The context switching between coding and managing is vastly different. Coding problems are direct—either it works or it doesn’t. People problems are nuanced; solutions may take months to reveal their effectiveness.

So don't expect a strict 50-50 split. Priorities shift weekly; some weeks require more focus on individuals, others on code. The urgency also differs—a critical bug needs immediate attention, while a personal issue with a team member requires empathy and understanding.

Next, consider perception and expectations. Your team expects you to stay technical while leadership wants you focused on strategy. As an individual contributor, your job was to write and deliver code. As a manager, you're expected to see further ahead, strategizing across teams and projects.

Balancing these roles is tough, especially if it’s your first time managing. Strategy and people problems will be new territory, taking longer at first—and that’s okay. Here are some strategies that worked for me:

* Time Blocking: It didn’t work well for me because interruptions are inevitable in management roles. If you try this, be very clear with everyone about your availability during these blocks.

* Prioritize Value: Focus on smaller tasks that add value without becoming bottlenecks for your team. Let them handle complex issues requiring deep thought.

* Delegate and Coach: Shift from execution to coaching. Delegate critical tasks but stay involved through PR reviews and architectural decisions without being the sole decision-maker.

* Set Boundaries: Communicate clearly about when you'll be heads-down coding versus available for team issues.

Remember, as a manager who codes, your role is about multiplying the team’s effectiveness—not just executing tasks yourself.

Now onto our second topic: Sponsorship and recognition in leadership...

Strong sponsorship increases retention, morale, trust, fairness, and encourages diverse leadership growth.

Your success as a leader isn’t just about what you accomplish—it’s about who you elevate along the way.

On sponsorship and recognition, it's about elevating others and strengthening both individuals and the organization. Put them in the spotlight, amplify their voices, and ensure they're heard even if they’re quiet.

Moving on to sponsorship and recognition in leadership: Recognition drives engagement, retention, and career growth because it shows what behaviors are rewarded. Sponsorship helps underrepresented employees advance by putting them in visible positions.

There’s a difference between sponsorship and mentorship—mentorship offers advice; sponsorship actively advocates for someone's career growth by giving them opportunities for visibility.

Here are some practical ways to sponsor as a leader:

* Public Credit: Acknowledge team members' work in meetings or updates without taking credit yourself.

* Create Visibility Opportunities: Pull team members into decision-making meetings or let them present topics they’re experts in.

* Push for Promotions/Raises: Document their impact consistently so it’s easy to advocate for them during promotion cycles.

* Assign Stretch Projects: Give high-potential employees critical projects to build their credibility.

* Celebrate Day-to-Day Wins: Regularly highlight both big achievements and small improvements in team communications.

So, how do you balance leadership and coding? Who has sponsored you, or whom have you sponsored in your career? Share your thoughts at askhartley.com or message me on LinkedIn.

That wraps it up for today. Next week, we'll have Michael Yodiv, a colleague of mine, discussing documentation. If you have questions about documentation in current, previous, or future organizations, drop me a note at AskHarley.com. We'll answer them live in a rapid-fire session—it’s going to be fun! That's all for Episode 8 next week. Thanks for listening. Have a great week!

Welcome back to Ask Hartley Anything, episode six. I'm your host, John Hartley, and every week I take your questions and share insights from my journey as an engineering leader.

Today, we're diving into a topic that's close to my heart: giving yourself grace. This means allowing yourself room to breathe, not being overly critical or pushing yourself too hard. It's something I've struggled with for a long time, and while I'm still working on it, I hope to shed some light on the subject. Maybe you're grappling with this too, and we can work through it together.

Summary provided by AudioPen Prime, the only AI tool I pay for. Goes from audio thoughts to transcribed summaries in whatever style you’re looking for. Love using this for long drives or walks.

Today, we'll explore why we push ourselves so hard, how it affects us, practical strategies for balancing ambition with self-compassion, and the long-term benefits of permitting yourself to rest and recover. If you've ever felt like you're not doing enough, this episode is for you. Even getting this episode out was a struggle for me—I debated whether to push myself or take a break. But I committed to releasing episodes weekly this year, so here we are.

Burnout is an issue we face daily, so let's dive in. Why do we feel this way? Why do we push ourselves too hard? Much of what I'll share comes from my own experience. For instance, I ran a hot sauce company on the side while managing my day job and personal life. It was exhausting and led to burnout.

The culture of overwork is finally starting to fade away, but hustle culture still lingers. Social media often glorifies constant productivity—early mornings, cold plunges, 10-mile runs before breakfast. This lifestyle can make us feel inadequate if we're not doing the same.

This year, I've switched to audiobooks instead of stressing about reading physical books quickly enough. Oddly enough, manga like Berserk keeps my attention better than traditional books.

Why do we push ourselves? Fear of failure and imposter syndrome play a big role. Early in my career at a digital agency, I pushed myself so hard that I got stress-induced shingles twice. The fear of being seen as a failure or unreliable drove me to overwork.

This self-imposed pressure is something I've reflected on for years. We often equate more effort with more success, but sometimes stepping back is the most productive thing we can do.

Think about where you're being hard on yourself and why. Are you pushing too far? In engineering leadership, I promote work-life balance heavily. If someone hasn't taken time off in a while, I encourage them to do so—not because they're doing a bad job but because they need to take care of themselves.

We've created a culture where we're always on, especially in tech. Some colleagues don't even have Slack on their phones—setting boundaries is crucial.

Let's talk strategies for giving yourself grace:

1. Reframe Your Mindset: What does success mean to you? For me, it used to mean climbing the corporate ladder as fast as possible. Titles aren't everything; they don't necessarily equate to impact or satisfaction.

2. Perfectionism: Are you trying to be perfect or good enough? Be okay with 80%. Perfection isn't realistic; aim for progress instead.

3. Set Boundaries: Define clear working hours and stick to them. Use tools like Google Calendar and Slack notifications wisely.

4. Practice Self-Compassion: Talk to yourself like a friend would—replace criticism with kindness and encouragement.

5. Acknowledge Wins: Keep track of your accomplishments, even small victories—they build momentum and positivity.

Lean on your network when you're struggling—having a hype person can make all the difference. And if you're still finding it tough, seeking professional help is okay too.

Understanding your boundaries and relationships is critical as you navigate your career. Reflecting on your progress regularly helps maintain balance and growth.

So think about what makes you happy and gives you joy in life. Give yourself some grace and set boundaries that work for you.

Pushing yourself too hard generally leads to burnout rather than success. Reframe what success means for you—prioritize what matters most.

What's one thing you'll give yourself grace with this week? I'd love to hear your thoughts—reach out at askharley.com or connect with me on LinkedIn.

Thanks for listening! We'll be back next week with episode seven—possibly discussing documentation in engineering organizations with a special guest!

Until next time, take care of yourselves!

Welcome back to Ask Hartley Anything, the podcast where I take your questions and share insights from my experience as an engineering leader. With 15 years in the software industry, eight of which have been in engineering leadership, I’ve learned a thing or two about goal setting.

Summary from Audiopen.ai Prime (affiliate link for the only AI tool I pay for)

I teased this topic a couple of weeks ago, but today, we’re breaking it down. When setting goals, think in three ways: personal growth, team growth, and company growth. Even as an individual contributor, this approach ensures you're always growing and helping your team and company grow too.

Before we dive in, remember you can always ask questions at askhartly.com or find me on LinkedIn. I also have a weekly newsletter every Monday with helpful links on AI, goal setting, leadership, and more. If you’d like to submit a link or learn more, feel free to reach out.

Alright, let’s get into goal setting. Especially at the beginning of the year, it's critical to get this right. The main framework I use is SMART goals—Specific, Measurable, Achievable, Relevant, and Time-bound.

Specific means your goal is clear. Instead of saying I want to get better at this, say I want to improve my one-on-one skills. Measurable means figuring out how to quantify your progress. Achievable means the goal is realistic within the time frame you set. Relevant relates to your role and career growth. Lastly, Time-bound means setting a clear deadline—whether it’s a week, a quarter, or a year.

So how do you set goals for yourself? Focus on how you want to grow as an individual. If you're an engineer, it might be mastering a new technology or taking on more leadership responsibilities. Avoid checkbox goals like complete a React course. Instead, aim for something actionable like complete the course and deliver a presentation on what I've learned.

Personal goals are helpful because they allow you to track your growth over time. Setting goals gives you clarity on what’s important and helps identify obstacles that might be hindering your progress—be it too many meetings or too much busy work.

Now let’s talk about team goals. Even as an individual contributor, you can set goals that impact your team. For instance, improving a process or reducing meeting times can significantly affect team dynamics and outcomes.

From a software perspective, think about team goals as outcome-oriented. For example, logging more bugs should lead to reduced bug resolution time or fewer overall bugs. Aligning team goals with company objectives ensures everyone is moving in the same direction.

Speaking of company goals, these often trickle down from broader objectives like OKRs (Objectives and Key Results) or KPIs (Key Performance Indicators). These should be specific enough to guide teams but flexible enough to adapt as needed.

Setting company-wide goals requires vision and alignment across all teams. For instance, improving customer satisfaction by 10 points in CSAT could involve various teams working on different aspects like UX improvements or technical debt reduction.

Regular updates and transparency are key in tracking progress towards these goals. Using simple metrics like stoplights—red for off track, yellow for at risk, green for good—helps everyone understand where things stand and what needs attention.

In summary, start with yourself by setting clear personal goals using the SMART framework. Expand to collaborative team goals that align with your organization’s vision. And finally, contribute to company-wide goals that act as your North Star.

What goals are you setting for yourself in 2025? What about for your team or company? Let me know at askhartly.com or find me on LinkedIn. This podcast airs every Wednesday morning on Spotify, iTunes, at hartleyshandbook.com—wherever you find your podcasts.

If you have any other goal-setting frameworks or systems that work for you, I'd love to hear about them. Thanks for listening! Until next time, take care and keep setting those meaningful goals!

Summary from Audiopen.ai Prime (affiliate link for the only AI tool I pay for)

Hey everyone, welcome back to Ask Hartley Anything, Episode 4. This is the podcast where I take your questions and share insights from my journey as an engineering leader. Today, we’re diving into mastering decision-making—empowering both your teams and yourself to make faster decisions, along with some mental models to help you do that. We’ll provide frameworks and systems so it’s not as overwhelming.

Before we get into the first question, remember you can go to askhartley.com to submit your questions, anonymously or otherwise. So far, we’ve been able to cover all four episodes with questions from you. I initially started this unsure if folks would actually send anything in, so I'm thrilled you're doing that and appreciate every question.

Today’s topic is helping teams make decisions confidently and using mental models for better, faster decisions. Our question comes from “third place,” possibly referencing a Fantasy football league—I'm not entirely sure. Third place asks:

Hey John, in episode two you briefly mentioned over-democratizing decision making. Could you elaborate more on this topic and how to realign your team so people feel comfortable making decisions? Does a tech lead need to step up as somewhat of a dictator to ensure timely decisions? Is this a superpower bestowed by management or leadership?

Great question! If you haven’t listened to Episode Two, feel free to go back after this one. Over-democratizing decision-making can be a problem in organizations. It’s when every decision is put out for a vote or discussion, dragging on endlessly. While it’s good to get differing opinions, it shouldn’t hinder timely decision-making.

I’ve seen this happen with RFCs (Requests for Comments) in engineering organizations. You put up a proposal for something like a big architectural change, and it either gets stuck in endless comments or no one responds at all. One way to resolve this is by giving tight timelines: say you have a week for comments, then you’ll address them and make a decision.

A key decision-maker can help break the cycle of indecision—whether that’s your VP of Engineering or a group of directors. Sometimes a simple thumbs-up/thumbs-down vote can work too.

Fear of making the wrong decision often paralyzes teams. It’s crucial to foster a culture where failure is acceptable and reversible decisions are encouraged. For instance, in code, you can revert changes or use feature flags to test new implementations.

I prefer POCs (Proofs of Concept) over RFCs because they allow you to test ideas quickly without getting bogged down in endless debate. A POC shows tangible progress and helps move things forward faster.

Now, who makes the final decision? It depends on the size of the decision. Smaller decisions can be made by tech leads or senior engineers within their teams. Larger system changes might need input from staff engineers or even higher up the chain like VPs or CTOs.

For major strategic shifts like re-platforming, involving top leadership makes sense since it aligns with the company's overall strategy.

To avoid micromanagement and promote autonomy, give teams frameworks for decision-making. Document how decisions should be made within your organization so everyone knows the process.

Curious how decisions are made at your company? Writing it out can reveal how democratized your process really is. But don’t let decisions linger; set deadlines for making them.

Switching gears slightly—if you want resources on better decision-making, Daniel Kahneman's Thinking Fast and Slow is excellent. Remember that all decisions are made with partial information; you'll never have every piece of data.

Let’s talk about some mental models:

1. **Eisenhower Matrix**: Prioritize tasks based on urgency and importance.

2. **Opportunity Cost**: Consider what you're giving up by choosing one option over another.

3. **OODA Loop**: Observe, Orient, Decide, Act—a continuous improvement cycle.

4. **Inversion**: Instead of asking how you can succeed, ask how you could fail and mitigate those risks upfront.

These models help create repeatable frameworks for making faster decisions with confidence.

So we've covered decision-making and some mental models today. If you have more questions, visit askhartly.com or find me on LinkedIn. Thanks for listening! Tune in next week for Episode 5.

Welcome back to Ask Hartley Anything, Episode Three, the podcast where I take your questions and share insights from my journey as an engineering leader. Happy New Year! I hope you're off to a great start. Thanks for your patience as we get back into our weekly cycle. The New Year hit me with a bug, so I wanted to make sure I didn't sound too hoarse when talking to you.

Today’s episode is packed. Initially, I planned to cover two topics: measuring the impact of engineering managers and goal setting. But we’ll focus on measuring the impact of engineering managers and introduce an interesting measure called hospitality quotient.

First, a quick plug: You can ask questions for this podcast at askhartley.com or reach out on LinkedIn. Subscribe on Spotify, iTunes, or hartleyshandbook.com.

Note: This text summary was generated from one of the only AI tools I pay for, AudioPen Prime. I leverage it for taking raw audio and turning it into a solid shortened summary.

Our first question today is from Brett, who says he’s a big fan of Adam Grant. If you don’t know Adam Grant, he’s the author of Originals and a professor at Wharton School of the University of Pennsylvania. Brett mentions a podcast where Grant discussed hospitality quotient with a restaurateur and relates it to engineering management. Brett asks for thoughts or metrics on measuring the impact of an engineering manager.

I'm a big fan of Adam Grant. He recently did a podcast with a restaurant owner where the restaurant owner talking about "Hospitality Quotient" and how it's hard to measure. I think of that a lot like Engineering Management. Do you have any thoughts/metrics of measuring the impact of an engineering manager?Here's the transcript

Great question! Measuring the impact of engineering managers can be tough. For engineers, output is clear—you can see their work in repositories and pull requests. But for engineering managers, it’s more nebulous.

Let’s start with the hospitality quotient (HQ). You’ve probably heard of EQ (Emotional Quotient). HQ is similar but focuses on making others feel better when you help them. Danny Meyer defines HQ as the degree to which someone feels better about themselves when they make someone else feel better.

Adam Grant relates HQ to affective presence—the consistent set of habits around emotions you elicit in others. Some people have a positive affective presence; others, not so much. This ties back to empathy and emotional intelligence.

But how do you measure these qualities in an interview? Companies have EQ tests that measure how individuals interpret situations, their empathy, and their attitude. In interviews, asking about recent feedback received and given can be enlightening.

Now, let’s pivot to measuring engineering management. It’s easier for engineers with clear outcomes and outputs but tougher for managers since it tends to be more qualitative than quantitative.

Here are five key areas (the Five Ps) for measuring engineering managers:

1. Personal: How do they show up daily? Are they consistent? Do they display empathy? Are they building systems and ideas effectively?

2. Personnel: Team health metrics like engagement scores and retention rates are crucial. Are team members engaged? Is voluntary attrition low?

3. Projects: Look at delivery metrics like velocity—stability over time is key, not just high numbers. Cycle times and DORA metrics also help gauge project execution.

4. Peers: How do they interact within their peer group? Use 360-degree feedback to understand their role in meetings and collaborations.

5. Process: Challenge them to improve one process annually. Are they proactive in suggesting changes? Do they understand organizational processes deeply?

These measures provide a robust understanding of an engineering manager's performance and readiness for the next level.

Think about hospitality quotient again—how do they make you feel in meetings? Do they inspire confidence or dread? If it's difficult interacting with them, consider performance management steps.

Remember, these insights aren't exhaustive but should give you a solid framework for evaluating engineering managers effectively.

Measuring engineering managers, or any managers for that matter, is a complex task. It becomes even more challenging as you move up the hierarchy. For directors, evaluating strategy effectiveness over the year involves larger time chunks, unlike engineering managers where delivery metrics in two-week cycles provide clearer insights. These time frames expand and complicate the assessment.

Over the years, my approach to this has evolved and become easier with experience. It's crucial to use both quantitative and qualitative data to gauge a manager's performance. How are they performing day-to-day? Sprint-to-sprint? Are they effective? When they are, how do they impact other metrics?

I’m always open to learning new methods for measuring managers. If you have techniques that have worked well—or not—please share them. Let's tackle this challenge together. The more we can quantify performance consistently, the easier it becomes to achieve those targets.

That wraps up this episode of Ask Hartley Anything. Thanks for tuning in. We're back on a consistent schedule—it's you and me on this journey every week. If you have questions, visit askhartly.com to submit them anonymously if you prefer. Just include an email for any follow-up questions and to inform you when your question will be featured.

Thanks again for listening. Have a great week. Until next time, insert tagline here (not a typo, I’ve just not thought of a catchy tagline).

In Episode Two of Ask Hartley Anything, I dive into two thoughtful listener questions.

First, I explore how to help team members detach emotionally from their ideas, focusing on fostering a growth mindset, encouraging collaboration, and coaching them to see the bigger picture. Then, I share actionable advice for maintaining and sharpening management skills when stepping back into an individual contributor (IC) role, such as mentoring, leading by influence, and journaling reflections.

Whether you’re managing a team or growing as an IC, this episode is packed with insights to help you level up.

Links:

* Mindset: The New Psychology of Success - Carol Dweck

* Radical Candor: Fully Revised & Updated Edition: Be a Kick-Ass Boss Without Losing Your Humanity - Kim Scott

* MasterClass

* 9 Books All Engineering Managers Should Read

* 9 More Books All Engineering Managers Should Read

Podcast summary created with Audiopen

Ever had a teammate who takes feedback too personally or wondered how to keep growing as a leader after stepping back into an individual contributor (IC) role? In this episode, I'll share how to help your team detach from their ideas and focus on impact, plus practical tips to sharpen your management skills. Welcome to Episode Two of Ask Hardly Anything, the podcast where I take your questions and offer advice grounded in my experience as an engineering leader. This podcast releases every Wednesday. Feel free to send questions to [email protected] about your engineering journey.

How have you handled direct reports that take things too personally?

Helping someone detach emotionally from their work is challenging. They’re likely passionate about their ideas and feel beat down when those ideas aren’t adopted. The first step is understanding the root cause. Why are they so attached? Maybe past experiences have made them defensive, or perhaps they tie their self-worth to the success of their ideas.

Sometimes, ideas are extensions of identity or expertise, making critiques feel personal. Early-career engineers often equate idea acceptance with validation, while senior engineers might feel irrelevant if their ideas are rejected. This emotional response can erode team trust and productivity.

In these situations, ask them privately, What happened in there? Understand their perspective without making everyone uncomfortable during the meeting. This helps you grasp whether it’s general frustration or something specific.

Here are six strategies to help:

* Growth Mindset: Encourage embracing challenges and learning from criticism.

* Drafts Over Final Products: Present ideas at 60% completion for early feedback.

* Reframe Disagreements: Position debates as collaborative problem-solving.

* Focus on Outcomes: Emphasize team goals over individual ownership.

* One-on-One Coaching: Provide constructive feedback regularly.

* Clarify Decision-Making: Ensure everyone understands how decisions are made.

At the end of the day, helping reports detach emotionally means shifting their mindset from proving their worth to improving the team's outcomes.

After five years in management, how can I maintain and continue developing my management skills while working as an IC?

Stepping back into an IC role allows you to refine technical skills and observe leadership from a new perspective. Whether you're at the same company or a new one, let go of old management habits and be open to new styles.

First, align with your manager about your goals to stay sharp in both IC and leadership skills. Build influence without authority by gaining trust through excellent IC performance. Mentor others informally, facilitate working groups, and set up office hours for questions.

Look for gaps in skill sets within your team and volunteer for leadership-like projects such as leading meetings or coordinating efforts. Journaling can also help you reflect on past management experiences and apply those lessons constructively.

Remember, building influence without a title involves proving your value through actions and collaboration rather than authority.

For more questions about management or engineering leadership, visit askhartley.com or find me on LinkedIn. Keep asking questions—your journey is important!

Journaling can be a powerful tool. It captures your thoughts and feelings at specific moments, offering insights into how you can adjust over time. Imagine putting yourself in your manager's shoes and documenting that perspective. You might think, Why do I need a journal? It's not a diary. But as you transition into management roles, these reflections become invaluable. When faced with situations your manager handles, you'll have a recorded playbook of your thoughts and strategies.

Seek feedback from peers and leaders about your collaboration and influence. Be specific when asking for feedback. Instead of a vague Do you have any feedback for me? try I've been leading this project. How's it going? Is there anything I can improve? This specificity makes it easier for others to provide constructive feedback.

In conversations with your manager, express your desire to continue developing your skills. They can offer insights into areas where you might need improvement or where you're excelling. Regular check-ins about your management skills can be beneficial.

Invest in learning and development. Many tech organizations offer learning stipends. Join communities of practice like Rand's leadership group or CTocraft to understand how others manage effectively. Reading management books like Radical Candor or taking leadership courses on platforms like Masterclass can also be beneficial.

Set clear goals for your management journey. At the end of the year, reflect on your progress in your journal. Identify obstacles and strategize ways to overcome them.

Advocate for others even if you're not officially in a management role. Sponsor and lift up your colleagues, encouraging them and fostering a team-first mindset. Remember, management isn't just about the title; it's about the impact you make on your team.

I believe you can do this. Entering with the intention to build your skill set will make the journey easier. Set goals and track your progress.

Thanks to Anonymous and Kyle for their questions. You can submit yours at askhartly.com, whether anonymously or not—I'll likely use only first names anyway. These questions help me reflect on my own leadership journey.

Next Wednesday is Christmas, so no new episode then, but I'll be back on New Year's Day with fresh content. Looking forward to more questions from you all.

Until next time, have a great week!

Today’s core question from Anonymous:

We've recently been surprised with a change in direction to become an ai first company. Can you share some advice on how to manage the team through these changes?

AI is a major buzzword in business today, possibly the decade, or even this century. For many companies, it's more than hype; it's a new way of working. But what happens when this shift feels sudden? Today, I'll share advice on managing team dynamics, keeping morale high, and adapting to new expectations. Welcome to Ask Hartley Anything, the advice podcast for engineers. I'm John Hartley, tackling your toughest career and leadership questions.

Today's episode is timely as we dive into managing teams during big shifts like becoming an AI-first company. If you have questions, send them to askhartley.com or connect with me on LinkedIn. Each week, I'll focus on one core question from you. Today’s is from Anonymous: We've been surprised with a change to become an AI-first company. Can you share advice on managing the team through these changes?

This situation is common now. One day you're solving usual problems; the next, you're supposed to embrace AI like it was always the plan. It's a big ask emotionally and technically.

Have questions you’d like answered? Let me know in the comments or at https://askhartley.com/

First, breathe and look at the situation objectively. Why is the company making this shift? Is it driving a business goal for 2025? Is it essential for survival? Understanding the context helps you explain it to your team.

My initial reaction to such pivots is often skepticism: Are we just following others out of fear? The market is saturated with AI applications, so understanding the core reason for this shift is crucial. If you don’t understand it, your team won't either.

Work up the ladder to understand why this decision was made. Is it a revenue driver? A retention play? Becoming a leader in your field? Without understanding the context, you can't manage the team effectively.

Acknowledge the disruption upfront with your team. Transparency builds trust. Be honest if you don’t have all the answers but share what you're doing to find them.

Frame AI as an opportunity, not a threat. Share specific ways AI can reduce busy work or open new opportunities for innovation. Highlight that AI enhances work rather than replaces people.

Invest in learning and development. Host workshops and encourage experimentation to build confidence in using AI tools.

Set short-term wins with manageable projects that showcase AI's value. This builds momentum and confidence within your team.

Stay human-centered. Remind everyone that AI is just a tool; their expertise and creativity are still vital.

Keep communication open and frequent. Regular retrospectives help gauge team sentiment and address concerns promptly.

The fact that you're asking these questions shows you care about your team's success during this transition. By understanding the business context, staying human-centered, and building short-term wins, you can guide your team through this change effectively.

Remember these phrases: Here's what we know right now, Here's what this means for you, and Here's how we'll tackle it together. These help maintain transparency and collaboration during any change.

I hope this advice helps as you move into 2024 and beyond with confidence in managing your team through an AI-first pivot. Keep asking questions and stay engaged with your team's journey.

And that's it for today's episode of Ask Hartley Anything. If you have more questions, send them along to askhartley.com or connect with me on LinkedIn. Until next time!

It's not productive to dwell on mistakes. Instead, channel that energy into preventing future issues. Consider the benefits this can bring to you and your fellow engineers. Collaborate on solutions to enhance your processes.

As a manager, staying calm during incidents is crucial. Incidents aren't about yelling or showcasing individual prowess. Managers direct the work, they don't do it. By maintaining composure and working with your team, you can figure out how to prevent repeat occurrences. It's valuable for organizations to adopt a blameless approach to incidents. No one should fear reporting them. If people start hiding issues to avoid angering superiors, it leads to more problems in the background.

Build a culture where it's okay to call out problems and fix them together. Take a cue from Toyota's manufacturing lines, where anyone can press a button to signal an issue, and everyone works together to resolve it. This openness is better than covering up mistakes.

As you move up in an organization, discussing outages with executives can be uncomfortable but necessary. Explain what happened, the impact, and the steps being taken to address it. These conversations can be tough, but they're essential for transparency and improvement.

If incidents are frequent, there's a deeper issue that needs addressing. But if they happen occasionally, continue inspecting tools and processes to understand why and how to prevent future occurrences.

Incidents offer a rare glimpse of teamwork in action, similar to sports coaching. You've prepared your team, and now it's time to see how they perform under pressure. If they do well, praise and encourage them; if not, identify areas for improvement.

Don't fear incidents. Fear stifles progress and delays development. Instead, implement monitoring systems that detect issues early and often.

In conclusion, managing AI involves acknowledging disruptions, framing AI as an opportunity, investing in learning, aiming for quick wins, and keeping communication open. By doing these things, your team will understand the changes and participate actively in the transition.

If you have questions or stories to share, reach out at askheartley.com or on LinkedIn. I'll be back next Wednesday with more answers. Until then, thanks for listening and have a great week!

Summary generated by Audiopen.ai

Links:

* https://www.cio.com/article/190888/5-famous-analytics-and-ai-disasters.html

* https://www.reddit.com/r/ExperiencedDevs/comments/1h86g99/how_do_you_not_beat_yourself_up_over_causing_an/

Tactical guide on how you can start to explore whether engineering management is a path you want to take.

What is your motivation? What are your concerns? Let me know in the comments below!

What would your company look like if you chopped your software engineering interview process down to less than 3 hours total and you could hire someone in a week from their first interaction? 

Today we’ll take a dive deep into how you can streamline your interviewing process. I’ve used the following methods at 4 companies with an 80%+ success rate and you can as well. The ideas are straightforward and save you and your company time and money. 

Primary source

Additional Resources:

* Ask Better Interview Question By Swapping These In

* Woven

* Karat

* ByteBoard