--- title: How to stay technical as an engineering manager | daily.dev description: Engineering managers risk losing technical credibility as they move away from hands-on work. Technical proficiency — defined as understanding architecture,... canonical: https://daily.dev/posts/how-to-stay-technical-as-an-engineering-manager-pijsidkwb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: How to stay technical as an engineering manager | daily.dev og:description: Engineering managers risk losing technical credibility as they move away from hands-on work. Technical proficiency — defined as understanding architecture,... og:url: https://daily.dev/posts/how-to-stay-technical-as-an-engineering-manager-pijsidkwb og:image: https://api.daily.dev/og/posts/PijsIdKwb.png og:image:alt: How to stay technical as an engineering manager og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # How to stay technical as an engineering manager **[LeadDev](https://daily.dev/sources/leaddev)** · 10 min read · 3 upvotes · 0 comments ## Summary Engineering managers risk losing technical credibility as they move away from hands-on work. Technical proficiency — defined as understanding architecture, tooling, and trade-offs rather than out-coding engineers — is now a requirement, not a nice-to-have. Four practical strategies are outlined: (1) mastering prompt engineering to leverage AI for technical tasks like bug triage and architecture overviews; (2) pairing with engineers on low-priority, time-boxed tasks to learn the codebase; (3) systematically building domain knowledge one area at a time (e.g., observability) through reading, mentorship, and hands-on practice; and (4) actively engaging in architecture and design reviews by reading RFCs twice, asking clarifying questions, and reasoning through secondary and tertiary consequences of proposed changes. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What makes a good prompt when asking an AI model to compare microservices versus a monolithic architecture? An effective prompt assigns the AI a persona such as senior software architect, provides context like team size and current tech stack, clearly states the problem such as deployment bottlenecks, specifies evaluation criteria like operational complexity and scalability, and requests a structured comparison ending in a recommendation, rather than a generic one-line question. _daily.dev surfaces practical prompt engineering techniques for managers weighing architecture tradeoffs with AI tools._ ### What are the secondary and tertiary consequences of replacing synchronous REST calls between services with an asynchronous Kafka-based system? Secondary consequences include silent, delayed failures where a consumer can lag for hours before anyone notices, events processed out of order, and harder debugging since logs must be correlated across producers and consumers. Tertiary consequences include losing the simple mental model engineers had from reading REST calls directly, making onboarding and understanding data flow harder for new engineers. _engineers weighing a move to event-driven systems can track these architecture tradeoffs on daily.dev._ --- Tags: [#architecture](https://daily.dev/tags/architecture), [#leadership](https://daily.dev/tags/leadership), [#prompt-engineering](https://daily.dev/tags/prompt-engineering) [View this post on daily.dev](https://daily.dev/posts/how-to-stay-technical-as-an-engineering-manager-pijsidkwb) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"How to stay technical as an engineering manager","url":"https://daily.dev/posts/how-to-stay-technical-as-an-engineering-manager-pijsidkwb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-to-stay-technical-as-an-engineering-manager-pijsidkwb"},"datePublished":"2026-06-22T07:29:59.927Z","dateModified":"2026-09-13T18:24:01.461Z","description":"Engineering managers risk losing technical credibility as they move away from hands-on work. Technical proficiency — defined as understanding architecture,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/613b9b7e725470c7ee3f3d9e09899b7c?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/613b9b7e725470c7ee3f3d9e09899b7c?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"LeadDev","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"LeadDev","logo":"https://media.daily.dev/image/upload/s--u_Q34nzh--/f_auto,q_auto/v1774514111/logos/leaddev?_a=BAMAMiWQ0","url":"https://daily.dev/sources/leaddev"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/how-to-stay-technical-as-an-engineering-manager-pijsidkwb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,leadership,prompt-engineering","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"LeadDev","item":"https://daily.dev/sources/leaddev"},{"@type":"ListItem","position":3,"name":"How to stay technical as an engineering manager"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/how-to-stay-technical-as-an-engineering-manager-pijsidkwb#faq","mainEntity":[{"@type":"Question","name":"What makes a good prompt when asking an AI model to compare microservices versus a monolithic architecture?","acceptedAnswer":{"@type":"Answer","text":"An effective prompt assigns the AI a persona such as senior software architect, provides context like team size and current tech stack, clearly states the problem such as deployment bottlenecks, specifies evaluation criteria like operational complexity and scalability, and requests a structured comparison ending in a recommendation, rather than a generic one-line question. daily.dev surfaces practical prompt engineering techniques for managers weighing architecture tradeoffs with AI tools."}},{"@type":"Question","name":"What are the secondary and tertiary consequences of replacing synchronous REST calls between services with an asynchronous Kafka-based system?","acceptedAnswer":{"@type":"Answer","text":"Secondary consequences include silent, delayed failures where a consumer can lag for hours before anyone notices, events processed out of order, and harder debugging since logs must be correlated across producers and consumers. Tertiary consequences include losing the simple mental model engineers had from reading REST calls directly, making onboarding and understanding data flow harder for new engineers. engineers weighing a move to event-driven systems can track these architecture tradeoffs on daily.dev."}}]} ```