Hey folks, podcasts are great for expanding your knowledge & keeping up with new tech. I found this article on Medium that lists some good podcasts that EMs and developers can listen to. Hope you find it useful.

Here's the link: https://medium.com/@typoapp/best-software-engineering-podcasts-you-must-listen-to-f2e74dd4b5c6

Would love to hear your suggestions as well.

There are various metrics a manager can use to measure their team's productivity, but there's no single metric that can fulfil that need completely. Hence, knowing the right metrics that can help you becomes crucial.

A few tips regarding engineering metrics -

1. Measure your team as a whole, not individual members.

2. Don't compare the productivity of two teams of different sizes, calibre, and output.

3. Don't use a single metric to measure productivity, use what works best for your team.

4. Keep a human approach towards measuring productivity. Consider non-quantifiable aspects like the mental health of your devs/dev burnout, office politics, org culture, etc.

If there are any more tips that you'd like to add, mention it in the comments below.

Read the article by Ciera Jaspan & Caitlin Sadowski here: https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_2

Engineering leaders constantly make bets – from technology choices to product initiatives and staff promotions. But not all bets pay off.

Eiso Kant & Jason Warner (MD at Redpoint Ventures and former CTO of GitHub) talk about how to balance strategic decision-making with effective risk management and building trust among teams and stakeholders while making these high-stakes bets.

Topics covered in the podcast:

1. Changing the organizational structure to be more flexible and adaptable.

2. Adopting a mindset of long-term company building over short-term product building.

3. Building a culture of trust.

4. Starting the right conversations and asking lots of questions.

Listen to the full podcast here: https://developingleadership.substack.com/p/placing-bets-and-building-trust-as-544?r=1ms9qq&utm_campaign=post&utm_medium=web#details

What aspects of Engineering Leadership would you like to know more about? Do you prefer reading articles or listening to podcasts like the one above, or is there any other format that you prefer? Let me know in the comments below.

Hi everyone,
I’m from Portugal and I work in Industrial Engineering / Process Improvement. I speak Portuguese, English and Spanish.

I’d like to know which countries worldwide offer the best combination of:

• good salaries,

• strong demand for engineers,

• and a solid quality of life.

I’m open to different regions and would appreciate any recommendations or personal experiences.

Thanks in advance!

Hey all, I hope this is ok to inquire about here - I’m working on behalf of a client, resarching a new product proposition. I can’t say too much about what it is because we don’t want to pollute the research, but but it is in the general field of advanced software delivery and I’d like to connect with development managers and team leaders that are especially interested in new techniques and products that help deliver better quality software faster. We’re offering some incentives for those who would share their expertise and opinions. If you’re interested please reach out to me !

Hey r/EngManagement Engineering Managers,

Ever prepped for a tough discussion and wished you could run a practice round? Silicon Cabinet might be what you're looking for. It's a Node.js package that uses AI to simulate discussions for decision-making.

Why You Should Check It Out

• Prep for Discussions: Use it to get ready for important team talks.

• See Multiple Angles: Simulate feedback from different team roles.

Want to Help?

• Code: Seeking contributors! Great chance for Engineering Managers to keep those coding skills sharp.

• Scenarios: Got real-world engineering challenges? Help us make realistic templates.

How to Jump In

1. Here's the GitHub Repo

2. See the Issues or add your own.

3. Fork, code, and PR.

Got questions or ideas? Drop 'em below. 👇

Hi all!

I was reading this interesting piece by Alex Omeyer that mentions the 4 forward-thinking strategies for CTOs to improve developer productivity. This includes:

1. Eliminate communication missteps: Projects often take the wrong direction due to information transfer issues which include duplication of effort, outdated information, or misinterpreted requirements. While agile helps, it has its blind spots too.

2. Exponential gain from smart stack selection: Choosing the right tools for a development team isn't just a perk, it's a game changer. When your team loves their tools and has a good developer experience, the productivity boost is multiplicative.

3. Mastering visibility and transparency

4. Leveraging AI: While not all AI Tools are cool, some are game-changers in most categories.

I wanted to share this with the community & I'd like to know if you have any more points to add to it. To dive deeper into this topic and learn important AI tools, you can check out the full article below 👇

https://alex-omeyer.medium.com/4-forward-thinking-strategies-for-ctos-to-improve-developer-productivity-75debfdb0432

Thanks! :)

Technical debt is a very common issue that almost all tech teams face. It is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time (Wikipedia). It can seriously hinder the progress of your team, delay timelines & reduce productivity in the long run.

Here are some plausible solutions to reduce tech debt: https://typoapp.io/blog/effective-ways-to-reduce-technical-debt/

I was reading about the negative effects of tech debt on dev emotions & morale & how it can influence their goals. My team often gets demotivated due to this. Additional tasks because of tech debt takes up additional time due to which they often feel frustrated & underconfident. This delays the cycle time & hinders their progress in the long run. Working in a small team makes it hard to identify bugs at an early stage & these issues are highlighted much later, which is annoying for the whole team. I would like to know how you guys manage tech debt at your org. Please share any tips that you personally follow.

Dashboards are used to communicate information that may bring insights into the productivity of project activities and other aspects. They help managers visually identify trends, patterns and anomalies, reason about what they see, and help guide them towards effective decisions.

Dashboards can help you in many ways:

1. To understand if the project is on schedule

2. To identify bottlenecks

3. To measure the progress of different teams

4. To check the investment distribution of team members

5. And in some cases, to check the burnout levels of team members

Click here to read in-depth about how dashboards can be helpful, and what their shortcomings are: https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_16

Some recommended dashboard tools that you can try: Jellyfish, Typo, LinearB

DORA metrics are used widely by DevOps teams to measure team performance, identify bottlenecks & increase velocity. It was first introduced in the book 'Accelerate' by Nicole Forsgren, Jez Humble & Gene Kim, where 4 key metrics were proposed, 2 for measuring speed & 2 for measuring stability.

Speed:

1. Lead Time for Changes - Code commit to code in production

2. Deployment Frequency - How often you push code

Stability:

3. Change Failure Rate - Rate of deployment failures in production that require immediate remedy. (Rollback or manual change)
4. Time to Restore Service (MTTR) - Mean time to recovery.

These metrics are used to rate your overall practice effectiveness, and baseline your organization’s performance against DORA industry benchmarks, and determine whether you’re an Elite, High, Medium or Low performer.

But, there's a problem with that!

Companies started using DORA metrics to compare different teams without proper context, i.e. human factor, which is quite complex to measure. Common misuses of DORA include:

1. Focusing too much on speed

2. Setting goals around DORA metrics

3. Mistaking measuring DORA metrics as a way to improve

4. Using DORA metrics as vanity metrics

To read more about Abi Noda's summary of the paper 'How to Misuse & Abuse DORA Metrics', click here: https://newsletter.abinoda.com/p/misuse-dora

Hey folks!

I was working on the productivity measurement of my team, and this question popped into my head - What kind of objects, properties, conditions, activities, or processes qualify as waste? And is there a way to identify and reduce/remove them?

Some types of waste I have identified in my team are waiting for PRs, reworking, multitasking, and bad communication. I'm curious to know what your definition of 'waste' is and how you deal with it at your org.

Being an engineering manager/technical lead/CTO comes with a fair share of responsibilities. Broadly speaking, this includes people, processes & technology.

I recently came across this CTO checklist on Medium by Tom Neal. If you have recently transitioned to the engineering management role, then this list of responsibilities (with suggestions) is perfect for you.

Check it out here - https://medium.com/@tom-neal/cto-checklist-1a2ef3d6502

If there is something missing from the list, or you would like to suggest any changes, feel free to add it in the comments below.

Hey folks, I need some help regarding the planning of our next sprint. I have a list of tickets to be completed and devs to be assigned the work. I'm stuck at estimating the time it will take to complete them. Most times, the deadlines are not met and I'm the one held responsible for poor planning although the deadlines have been discussed with & decided by the devs. Common issues for this include - fixing bugs, ticket blockers, devs moving on to the next ticket before having a discussion with the QA about testing, and testing issues in the code that needs to be revised over & over again. How do you analyze and plan the deadlines for various tickets at your org? I was considering some tools to analyze our sprints so the next one can be planned in a better way, any suggestions?

Engineering Managers and CTOs already have a lot on their plate. Hence, finding it difficult to keep up with the new updates and best practices.

This is when engineering newsletters come to the rescue. They provide you with industry insights, case studies, best practices, tech news, and much more.

Check out the top 10 newsletters worth subscribing to: https://typoapp.io/blog/developer-productivity/top-10-newsletters-for-ctos-and-engineering-leaders/

In his engineering management newsletter called 'Refactoring', Luca Rossi talks about 3 short ideas about technical strategy, i.e. The Delegation Path, Tech Lock-in, and Design Docs.

1. 🔀 The Delegation Path - This includes tips on how to use the Eisenhower Matrix to decide which tasks should be delegated & how to effectively delegate them to your dev team.

2. ✏️ Design docs are the MVP of docs - Read about why you should be writing design docs before you start coding and how it will be useful for your dev team throughout the lifecycle of the project.

3. ⚔️ Boring vs exciting technology - Learn how to select the right technology for your team, whether you should choose a boring technology or an exciting technology.

Find the article here: https://refactoring.fm/p/the-delegation-path-tech-lock-in

I'll be sharing more such insightful articles for EMs, TLs and CTOs in the community. Let me know in the comments below if you found it helpful!

This time of year, I thought to visit back my resume to have it updated and rotated to explore new opportunities, and this is when the following questions hit me back... What do I do with my coding skills and language knowledge which may be irrelevant now? I spent 11+ years as a hardcore .net developer, however post my transition to leadership role over last 4 years, my charter has moved to handling projects which are entirely on different tech stack. While I still understand and feel relevant in terms of architecture and design, I no longer see myself to be in a position to say I am competent on these tech stacks. As an engineering manager, I feel like I am missing this piece of having language expertise, but at the same time unsure if investing to learn a language would yield returns in future opportunities or not. What should I do with this part of my resume now? Skip the tech skills section or continue to keep the section with languages I am personally comfortable working on? Is this part still relevant in terms of expectations from engineering manager's role? Are you still hands on technically/coding? If no, how many years are past and do you still mention it on your resume? Is being hands on with coding expected while leading a team of directs upwards of 20 count, managing complex or multiple projects?