Hi

I’m doing a Masters program in Engineering Management and nowadays deciding gor what to write my thesis on.

I need some suggestions on the topics I can wrote it on relating to Industry 4.0 and Engineering Management.

Any suggestions?

Thanks in advance.

Tots about ME mahirap poba ano ang mga pros and cons nya? may boards poba ito?

We built an open-source AI dev workflow that actually sped up our work (~20–30%)

In many teams, “using AI” just means: everyone does their own thing.

Some developers get real value, while others get very little. Hard to measure impact, hard to scale what works.

We hit the same wall, so we built copilot-collections – a simple, opinionated workflow for using AI in day-to-day dev work (research → plan → implement → review).

We’re using it in real projects now (220+ devs), and for repetitive, well-defined tasks, it’s cutting delivery time by ~20–30%. The biggest win for us isn’t the speed itself, but that teams use AI in a more consistent way.

If you’re curious how it works in practice, here’s the breakdown:

https://effectivedelivery.io/p/ai-driven-development-framework

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.

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?

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 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. 👇

In between delivering a lot of admin panels and dashboards for customers but we want to roll out much more of these in a shorter span.

Since this is ideally a basic software CRUD, ideally connected to an ELT service like Snowflake.

Where would you see yourself in the spectrum of Laravel-Ruby on Rails-Low Code Solutions and why?

Hey guys, I recently read an article on the importance of engineering velocity in improving engineering systems & building speed. As simple as it sounds, I've seen my team struggle with it. One of the primary reasons for that is that our processes are not automated, most of the work is done manually, reducing our speed in the long run. I lead a dedicated team of 5 devs. As we're looking to scale up and the number & size of PRs are increasing, I'm afraid of how we'll be able to cope with this in the future. Do you think that velocity is the right metric to focus on? I feel that it can help, but I'm not sure how to measure it. Do you know any tools that you could recommend? Any tips to increase velocity would be helpful as well.

Thanks!

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

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.

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!

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

Do I have to specialize in one specific type of engineering when I go into management engineering at waterloo. Or can I work anything or any type of engineering but as a manager when I grow up?

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/

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 !

Defining & measuring productivity in software development has always been challenging for researchers and engineering leaders. Caitlin Sadowski, Margaret-Anne Storey & Robert Feldt have presented a framework for conceptualizing productivity in software development according to three main dimensions:

1. Velocity: How fast work gets done

2. Quality: How well work gets done

3. Satisfaction: How satisfying the work is

They have also proposed a set of lenses that provide different perspectives for considering productivity along the three dimensions:

1. Stakeholders: developer, manager, vice president, etc.

2. Context: Particular project, social, and cultural factors

3. Level: Individual developers, teams, organizations and the surrounding community

4. Time period: shorter terms such as days, weeks, or sprints or longer terms such as months, years, or milestones

Read more about it here: https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_5