# Alex Di Mango — Full content > All blog posts on alexdimango.com, in source Markdown form. --- title: Software engineering reset. Most engineering leaders are still managing the old version. url: https://alexdimango.com/blog/software-engineering-reset/ date: 2026-05-16 tags: ai-adoption, leadership --- Two and a half years of writing for Not Just Bits. Career frameworks. Sprint patterns. Hiring playbooks. Sleep and leadership and the first 90 days. I am closing it. Every post is at [alexdimango.com/blog](https://alexdimango.com/blog/) now, and every old link redirects. But that is not why I am writing. I am writing because between 2024 and now, something more important happened than any of the topics I covered. Software engineering reset. The engineering leaders I have been talking to for the last year are managing the old version of the work. ## What reset The artifacts of software work changed first. A junior engineer ships in a day what a mid-level engineer used to ship in a week. A senior engineer reviews three times the surface area. The bottleneck moved from typing code to understanding what needs to be built and whether it works. Then the org chart changed. Teams of five do work that needed twelve. Roles that existed because of routine work disappear. Roles that existed to scope, review, and decide became more valuable, not less. Then the customer changed. Boards that used to ask "how is the team" now ask "how is the team plus the AI." If you cannot answer the second question, you are not answering the first either. ## What did not change The fundamentals. Trust between teammates still takes months. Calibrating estimates still takes practice. Onboarding still takes deliberate work. The career path still needs intentional design. The OKRs still need check-ins someone runs. Everything I have been writing about for two years still applies. It just applies on top of a different substrate. ## The part hard to ignore Every leader I have spoken to in the last six months faces the same question. From the board. From customers. From their own engineers. "Are you getting the AI thing right." Most of them cannot answer it. Not because they are not using AI. They are. License counts in those companies are high. Dashboards show hours of usage per week. They cannot answer it because they have no method to say what changed in the business. License plus dashboard is not an answer. Activity is not the same as impact. ## What I did about it I pulled the method out of advisory engagements and made it open source. It is on GitHub now as the AI Adoption Playbook. Runs inside Claude Code. Two stages, twelve skills. **Stage one. Diagnose.** Where adoption is stuck. Where the workflow changed and where it did not. **Stage two. Defend.** Numbers a board will not roll their eyes at. The structure for a quarterly update with real evidence. It is for you. The engineering leader who has been carrying that question for the last twelve months and has nowhere to put the answer. [github.com/adimango/ai-adoption-playbook](https://github.com/adimango/ai-adoption-playbook) ## If running it yourself is not the call I am turning the quarterly report into a productized service called Talon. Same methodology, packaged. Useful when you have the diagnosis but not the time. [alexdimango.com/talon](/talon/) ## A small ask If the playbook is useful to you or to someone on your team, star it on GitHub. That is the whole ask. It surfaces the work for the next leader who needs it. ## Thank you Two and a half years of an audience that stayed quiet but kept showing up. Every reply. Every conversation that started with "I read your post on...". I noticed. Alex --- title: Why Most Companies Can’t Answer “Is AI Working?” url: https://alexdimango.com/blog/why-most-companies-cant-answer-is/ date: 2026-03-08 tags: ai-adoption, hiring, leadership --- Every quarter, the same conversation happens. A board member asks about AI. The person responsible, could be the CTO, the COO, a VP of Engineering, whoever drew the short straw, says the team is exploring it. The board nods. Next quarter, same question, same answer. I’ve been in that room. I’ve watched this loop across multiple companies now. The problem isn’t the tools. It’s that nobody treats AI adoption the way they’d treat any other organizational change. There’s no diagnosis. No clear owner. No numbers. ## Where It Breaks Down 1. The first gap is between access and adoption. Companies buy licenses, announce the rollout, maybe run a training session. Then they check the dashboard and see logins. But logins aren’t adoption. Adoption means a workflow changed. Someone stopped doing something the old way and started doing it differently, not during a workshop, but on a Tuesday morning when nobody’s watching. Most companies never get past this stage. People try something, it’s interesting, they go back to what they were doing. A license doesn’t change how someone works. That takes more than a rollout email. 2. The second gap is between usage and impact. Even when people use the tools regularly, that doesn’t mean the business got anything from it. “The team is getting comfortable with AI” is not something you say to a board. Impact means you can point at a specific workflow and say: this is different now, and here’s what it saved us. If you can’t do that, you have activity, not results. 3. The third gap is ownership. AI adoption gets treated as a shared responsibility. Engineering is exploring it. Product is curious. Marketing tried it for some copy. Everyone is doing something. Nobody is tracking any of it. Six months pass, nothing has moved, and the whole thing becomes background noise. ## What I Keep Hearing From Other Leaders I moderated a roundtable and ran a webinar on this recently. Two things kept coming up. ROI is hard to measure. Most companies I talked to can’t put a clean number on what AI adoption has done for them. Everyone feels behind on this. Almost nobody has figured it out yet. But the companies making progress all had one thing in common. Someone owned it. Not a working group. Not a Slack channel. One person who tracked what was happening, reported on it, and could answer the question “did anything change?” That came up in almost every conversation. Nothing else was even close. ## The Board Question You Should Prepare For Board questions about AI are getting sharper. It used to be “what’s your AI strategy?” Now it’s closer to “you bought licenses for the whole company, what has the company gotten back for it?” You need numbers for that. You need to show that something changed, not just that people tried things and had opinions about them. If you can’t answer it yet, most people can’t. But start working on it. That gap doesn’t stay invisible for long. ## A Starting Point
Image (01.gif)
I built an open-source framework for this. The [AI Adoption Playbook](https://github.com/adimango/ai-adoption-playbook) runs inside Claude Code and it’s built for anyone responsible for AI adoption, founders, CTOs, CAIOs, VPs of Engineering, COOs. It walks you through a diagnosis: where is adoption stuck, why, and what to do about it. Then it helps you build a 90-day plan with actual owners and milestones. There’s also a board narrative coach that plays the skeptical board member so you can practice before the real thing. It won’t solve everything. But it forces the conversations most teams keep avoiding. And if you’re in this phase and want to think it through with someone who’s seen it a few times, [I’m happy to talk.](https://calendly.com/alex-dimango-consulting/20min) --- title: Your AI-Built MVP Works. Now What? url: https://alexdimango.com/blog/your-ai-built-mvp-works-now-what/ date: 2026-02-22 tags: ai-adoption, hiring, leadership --- You built your product in 6 weeks using AI tools. It works. A few customers are paying. Vibe coding feels real. Then during your first VC pitch they ask how you track your sales pipeline. Your tech co-founder wants to know if customers are using the feature you shipped last month. You don't have good answers. Not because you don't care. Because the product was built to work, not to be watched.
Image (01.jpeg)
This is where most AI-built products hit a wall. Not because they're bad. They usually solve a real problem and users are happy. The issue is that the code that helped you move fast skipped the layer that tells you what's happening inside your own product. I've seen this a few times in the past year. A founder builds with Lovable or Claude. The product looks solid. Customers are onboarding. Revenue is coming in. Then a VC asks a straight question about usage or retention, and the founder spends the weekend digging through a database to find the answer. What's underneath is usually the same three gaps. 1. **No analytics layer,** so you can't tell which features get used. 2. **No dashboard,** so every business question needs a manual database query. 3. **No monitoring,** so you find out about outages from a customer email. None of that is a mistake. Speed was the goal. AI tools are good at building features. They're not good at building the layer around those features. Nobody prompted Lovable to set up error tracking. You were shipping. That was the right call. The problem starts when the business outgrows the code. When investors need numbers you can't produce. When an enterprise prospect asks about data residency and you have to check. When your first engineer opens the repo, reads for ten minutes, and the energy in the room changes. At that point, rewriting everything is rarely the answer. It burns time and kills momentum. The better question is: what needs to exist before someone else starts making changes? In practice, three things. **Visibility into usage.** You need to know what customers are doing inside your product. Not vanity metrics. Basic things. Active users last week. Which features get used daily. Where people drop off. Without this, every product decision is a guess. PostHog or Hotjar gets you there fast. **Deployment that doesn't depend on you.** If releasing a new version relies on your laptop and steps you remember from habit, that's a risk. A simple CI/CD setup that runs basic checks and deploys the same way every time removes you as the single point of failure. Add basic error tracking so you find out when something breaks before your customers do. **A codebase someone else can read.** When your first engineer joins, can they understand how it fits together without you in the room? A clear README explaining how to run the project, how it's structured, and how to deploy it goes a long way. Most AI-built projects skip this because the founder never needed it. When those three things are in place, the code doesn't need to be perfect. It needs to be legible, stable, and observable enough for the business to run on it. The first phase was about proving the idea. The next phase is about making the product something other people can trust and build on. Those are different jobs. If you're in that transition and want a second pair of eyes on what to fix first, [book a free 20-minute call.](https://calendly.com/alex-dimango-consulting/20min) --- title: Your First Engineering Hire Will Make or Break You url: https://alexdimango.com/blog/your-first-engineering-hire-will/ date: 2026-02-14 tags: ai-adoption, hiring, leadership --- You posted a job ad for a senior full-stack developer. Within days, 400 applications landed in your inbox. You spent a weekend reading CVs and you still cannot tell who is good. > That is normal. Hiring engineers is hard even for experienced CTOs. For a founder doing it the first time, it feels like guesswork. Most founders get this hire wrong. Not because they are poor judges of character, **but because they focus on surface signals.** The job description reads like a checklist. Five years of React and TypeScript. PostgreSQL. AWS. Docker. The result is predictable. You either hire someone who matches keywords but struggles in a messy, early product. Or you hire someone familiar who is “good with code” and hope it works out. Your first engineer is not filling a gap. **They are shaping how your company builds software.** The patterns they introduce will be copied. The shortcuts they take will become normal. The way they structure code, handle data, manage errors and deploy changes will define the baseline for everyone who joins after them. That is why “senior full-stack developer” is often the wrong framing. It describes tools. What you need is someone who can own the product and make decisions in uncertainty. I tend to think about engineers in two broad groups. **Builders** and **Optimizers**. - **Optimizers improve existing systems**. They refactor, improve performance, tighten processes. They are strong when there is already structure. - **Builders create structure where none exists**. They are comfortable with ambiguity. They make decisions with incomplete information. They ship something that works, then improve it. They do not wait for perfect requirements. > At an early stage, you usually need a builder. Especially if your current codebase was built fast, possibly with AI tools. You need someone who can step into that reality, understand the intent, and improve it without expecting it to be clean. If you are not technical, you can still evaluate this. Stop focusing on technologies. Start focusing on decisions. - Ask candidates to walk you through a real trade-off they made. - What were the options. What did they choose. Why. - Ask about a project where requirements changed halfway through. What broke. What did they adjust. What would they do differently now. You are not testing whether they know React. **You are testing how they think, how they handle ambiguity, and whether they take ownership.** Listen carefully to how they describe past work. Do they talk about trade-offs. Do they explain constraints. Can they point to decisions they personally made and the consequences of those decisions. Ownership matters more than elegance at this stage. On compensation, this is not the place to optimize for cost. You are asking someone to take responsibility for your entire technical foundation. Paying below market usually means you attract someone who is not yet ready for that responsibility. That becomes expensive later. Set clear expectations for the first 90 days. - By the end of **week one**, they should be able to run the system locally and deploy a small change. - By the end of **month one**, they should understand the architecture well enough to explain it. - By **month three**, they should ship independently and start challenging parts of the system that need improvement. If after 90 days you are still the only person who understands how things work, the hire is not doing what you need. If after 90 days they are raising the bar and pushing the product forward, you hired well. **Do not rush this because you feel behind.** A weak first engineering hire sets you back further than a slow, deliberate search. * * * I help founders design their first engineering hire. If you are about to post that job ad, it might be worth a conversation first. [Book a free 20-min call](https://calendly.com/alex-dimango-consulting/20min) --- title: Are You Supposed to Have a Career in Tech in 2026? url: https://alexdimango.com/blog/are-you-supposed-to-have-a-career/ date: 2026-01-11 tags: ai-adoption, hiring, leadership --- I had the same conversation twice last week. Two different engineers. Two different companies. Same question: “_Is a tech career still worth it in 2026?”_ I understand why people ask. AI writes code. Teams shrink. Roles blur. What used to feel solid now feels temporary. So let me say this upfront. The career is fine. What broke are the old assumptions. ### The tools changed. The job did not. Every cycle brings new tools. New frameworks. New titles. Right now, _AI Engineer_ is the fastest-growing job title on LinkedIn. That tells you how fast the surface is shifting.
source: https://www.linkedin.com/pulse/linkedin-jobs-rise-2026-25-fastest-growing-roles-us-linkedin-news-dlb1c/
source: https://www.linkedin.com/pulse/linkedin-jobs-rise-2026-25-fastest-growing-roles-us-linkedin-news-dlb1c/
You still solve problems for people. You still make decisions with incomplete information. You still own the outcome. Titles change faster than the job itself. ### AI did not remove responsibility AI removes effort. It speeds things up. It fills in gaps. It does not remove ownership. Someone still decides what to build. Someone still approves shipping. Someone still gets the call when it breaks. Most people who fear AI are not afraid of the tech. They are afraid of being accountable for faster decisions. > I see teams confuse output with progress. AI makes it easy to produce code that looks finished. **That is not the same as the work being done.** Trust without understanding is not leverage. It is risk. ### Titles matter less than trust We still talk about titles. Senior. Staff. Principal. Head of. What moves careers now is trust: 1. Who do we trust to make the call. 2. Who do we trust with the messy problem. 3. Who do we trust when things go wrong. That trust builds through clear thinking and ownership. Not through a title change. You can see this shift in how teams now approach technical leadership. ### Tech lead rotation makes this concrete I see this pattern more and more in teams under pressure to move faster. One response is tech lead rotation. Not as a process. As a way to share responsibility. Instead of one fixed tech lead, senior engineers take the role for a limited time. Three or six months is common.
Image (02.jpeg)
They stay hands-on. They also own decisions, direction, and trade-offs during that period. They are not promoted. They are accountable. In practice, the rotating tech lead owns: - Technical direction and constraints, aligned with business goals - Priorities and sequencing, based on impact and risk - Architectural decisions, with long-term cost in mind - Delivery and risk trade-offs, not just velocity - Coordination with product and other teams, to keep decisions grounded Decisions are explicit. Context is written down. Ownership is clear. When the rotation ends, the role moves on. The system does not reset. Teams choose this model because complexity is shared now. AI and automation mean more engineers shape the system. Rotation spreads judgement across the team instead of concentrating it in one person. It also changes behavior. - People learn how hard prioritization is. - They see the cost of trade-offs. - They stop treating decisions as abstract ideas. - Most importantly, it removes the illusion that responsibility can be avoided. ### Careers look like portfolios now Few people follow one clean path anymore. You code. You advise. You mentor. You write. You build something on the side. That is normal. Careers look more like portfolios. A mix of skills, reputation, and network built over time. This is why sharing what you learn matters. Not for reach. For signal. ### What still matters If you want to last in tech, focus on a few things. - Learn how systems fail. - Learn how people decide. - Learn how to explain trade-offs. - Learn how to own outcomes. The stack will change again. It always does. Judgement holds its value. And that is why, in 2026, a tech career still makes sense. Just not for the reasons it used to. --- title: Tiny Teams Aren’t New. We Just Forgot. url: https://alexdimango.com/blog/tiny-teams-arent-new-we-just-forgot/ date: 2025-10-26 tags: ai-adoption, hiring --- Small, high-leverage teams have _always_ built the future. - WhatsApp had about 35 engineers and reached 450 million users. - Instagram? 13 employees, 30 million users. - Waze? Around 100 people, 50 million users. No AI. Just focus, clarity, and smart systems. > So why is everyone suddenly excited about “Tiny Human + AI Teams”? Because AI makes what’s _old_ feel _new again._ It reminds us how powerful small can be. ### The Reality Tiny Human-AI teams run light. No endless meetings. No decks to “align.” No 17-person threads about the roadmap. They don’t talk about output — they produce it. They build. Ship. Adjust. Repeat. You can already see it happening: - **Lovable** → 2.3 million users, under 50 people - **Midjourney** → 20 million users, about 100 people A few humans. Smart systems. outsized results. The pattern isn’t new — it’s returning. ### The Current Setup Is Broken Here’s the number one pain in the 🍑: meetings.
Image (01.png)
Microsoft’s 2025 _Work Trend Index_ found that: - The average employee gets **117 emails a day** - Receives **153 Teams messages** daily - Faces an interruption **every 2 minutes** - And **57% of meetings are ad hoc** — called without notice That’s not collaboration. That’s coordination theater. Continuous updates. Stakeholder check-ins. Three-month roadmaps for three-day projects. It’s noise pretending to be work. ### What Needs to Change If you’re a leader, stop counting people. Start measuring flow. In AI-driven teams, output isn’t about hours or headcount. It’s about how fast ideas move from concept to customer. > You don’t manage tasks anymore. You monitor systems. You watch for: - **Signal quality** → is the AI producing useful insights? - **Decision speed** → how fast can humans act on them? - **Learning loops** → are people and models improving together? The hiring ceiling isn’t the problem anymore. The leverage ceiling is. The teams winning now aren’t the biggest. They’re the ones augmenting every engineer with AI. ### A Word of Caution **Small does not fit everything.** Some problems in healthcare, energy, and climate are too complex for five-person teams. They depend on regulation, infrastructure, and deep coordination. AI will not replace that scale. But it can reshape it. By cutting the coordination tax, AI allows small, focused units inside large systems to move faster without breaking what must stay stable. ### The Truth Tiny teams are not a trend. They are a return to what works. The real shift is not about replacing people with AI. It is about using AI to extend what small, focused teams can do. The future belongs to those who stay small enough to move fast and think clearly. I’m curious what you think. --- title: The Only Metric That Matters When Everything Else Goes to Hell url: https://alexdimango.com/blog/the-only-metric-that-matters-when/ date: 2025-08-03 tags: hiring, measurement --- I’ve been in the room when the site was technically “fine,” but the business was bleeding. Everything green. Everything calm. Everything quietly broken. The team was staring at uptime graphs like they might confess to something. They didn’t. Meanwhile, users couldn’t check out. Or upload. Or click the thing that was supposed to lead to the other thing. This is why you need a heartbeat metric. ### What’s a heartbeat metric? It’s the one signal that tells you: **"People are doing what they came here to do."** Not “servers are responding.” Not “logins are high.” Not “our NPS hasn’t cratered yet.” A **heartbeat metric** tells you the product is _working_, in the way that matters. It’s not fancy. It’s not exciting. But when all hell breaks loose, it’s the number that tells you if you’re still alive. ### Real examples (not theory): - E-comm? **Successful checkouts per minute.** - SaaS? **Users completing a core task.** - Dev tool? **Builds triggered and completed.** - Marketplace? **Orders placed that didn’t bounce.** Don’t overthink it. Pick the one thing that, if it flatlined, you'd hear about it in under ten minutes — because customers would be gone or yelling. ### What makes it a _good_ heartbeat? - **It’s user-facing.** Not backend ops. - **It breaks when value breaks.** Not when a server burps. - **It’s steady.** No big spikes. No vanity. Just pulse. - **It’s uncomfortable.** It’ll show failure faster than you’d like. You can’t hide behind it. That’s the point. ### Why teams ignore this Because uptime is easier. Because dashboards look good in screenshots. Because tracking actual outcomes means admitting where things aren’t working. Heartbeat metrics don’t flatter you. They keep you honest. ### One metric, not fifty Some teams try to build a whole hospital monitor setup — ten dashboards, twenty alerts, custom animations. That’s noise. Start with **one metric** that cuts through the nonsense. The one that forces someone to say: > “If this is down, I don’t care what the infra metrics say — we have a real problem.” You can layer on later. But start there. ### Closing thought (and minor plea) If you don’t know your heartbeat metric, figure it out now — _before_ you’re in crisis mode. Because when the app slows down, users rage-click, and your team’s on its fifth debugging Zoom of the day, your beautiful observability stack won’t tell you the one thing you need to know: **Are people still getting what they came for?** If not, nothing else matters. --- title: AI Strategy for CTOs: A Practical Guide to Getting Started url: https://alexdimango.com/blog/ai-strategy-for-ctos-a-practical/ date: 2025-06-11 tags: ai-adoption, hiring, leadership --- Most AI strategy decks start with definitions. This one starts with fixes. ## AI doesn’t have to be complex to be powerful You don’t need a PhD team. You need: - Clean data - Clear goals - Confidence to ship Use proven tools. Pick hosted models like Claude, GPT-4, or other API-based LLMs. Avoid running your own model unless AI is your product. It adds cost, risk, and complexity without clear upside for most companies. ## Educate your leadership team, not your engineers Your engineers probably already get it. Your commercial leads might not. Run one-hour sessions: - What AI is (in your context) - What it can help with - What it won’t fix - Where it might go wrong AI literacy at the top prevents bad bets and panic later. ## Set up an AI advisory group early You don’t need in-house experts for everything. But you do need people who are already using AI to make real progress. Start small. Form an internal group of people from different teams — ops, product, marketing, support — who are already using AI to improve their work. Pair them with one or two external advisors who’ve shipped AI in production or navigated the legal side. This kind of group gives you: - Fast feedback from real users - Early warnings on risk or scale issues - Credibility when you bring ideas to leadership Build it before you scale your AI effort — not after. ## Use real metrics. Don’t chase “transformation” Your AI strategy should: - Save X hours/month - Cut Y% in cost - Improve Z metric by \[something people already track\] No one cares if it’s AI. They care if it works. Put value over novelty. ## Build boring foundations first Before you get excited: - Clean up your data - Review legal/compliance issues - Have a rollback plan If you wouldn’t let a human do it without oversight, don’t let an AI do it either. ## Use a Simple Matrix to Prioritize AI Work
Image (01.jpeg)
Not every AI idea is worth building. Some are too early. Some don’t matter. Use this 3x3 matrix to cut through the noise: - **X-axis:** Execution readiness: do you have the data, tools, and team to ship a small test fast? - **Y-axis:** Business value, will it improve revenue, reduce cost, or cut risk? Start in the **top-right corner**: ideas that are high-value and easy to try. Timebox everything else. If it takes more than two weeks to prove value, rethink it. Use the matrix to focus your AI effort where it counts. Ignore the rest. Find the Miro template here: [https://miro.com/miroverse/ai-strategy-matrix-for-cxos-6muxpuwch0tcgo83/](https://miro.com/miroverse/ai-strategy-matrix-for-cxos-6muxpuwch0tcgo83/) ## Start now, not perfect The longer you wait, the more catch-up you'll need to do. The best way to learn AI is to try it in production. Start small. Make mistakes. Course-correct. **Set a clear time limit — 1 to 2 weeks max per experiment.** If you can’t see signs of value in that time, stop or adjust. You’re testing usefulness, not building a final product. Keep cost low. Keep scope tight. Learn fast. --- title: Balancing Intuition and Data in Product Decision-Making url: https://alexdimango.com/blog/balancing-intuition-and-data-in-product/ date: 2025-03-30 tags: ai-adoption, hiring, leadership --- In product development, teams often face a choice: rely on intuition or base decisions on data. Both approaches have their merits and challenges. Striking the right balance is key to effective decision-making. ## **The Role of Intuition** Intuition, shaped by experience and expertise, can be valuable, especially when data is scarce or when exploring innovative ideas. Seasoned professionals may detect patterns or foresee trends that data has yet to reveal. However, decisions based solely on intuition can be risky, as they may overlook objective insights that data could provide. ## **The Power of Data** Data-driven decision-making offers objectivity, grounding choices in measurable evidence. Analyzing user behavior, market trends, and performance metrics can highlight opportunities and areas needing improvement. Yet, an overemphasis on data can lead to "analysis paralysis," where the abundance of information hinders timely decisions. Moreover, data may not always capture qualitative factors like user emotions or emerging market shifts. ## **Achieving a Balanced Approach** To navigate between intuition and data: 1. **Integrate Insights:** Use data to inform and validate intuitive judgments. For instance, if intuition suggests a new feature, analyze user data to assess its potential impact. 2. **Be Selectively Data-Driven:** Recognize when data is essential and when it's acceptable to rely on intuition. In fast-changing markets, waiting for comprehensive data might result in missed opportunities. 3. **Foster Collaborative Decision-Making:** Encourage diverse perspectives within the team. Combining analytical minds with creative thinkers can lead to well-rounded decisions. 4. **Embrace Experimentation:** When uncertain, consider running small-scale tests or pilot programs. This approach allows teams to gather data on intuitive ideas before a full-scale rollout. Tools like [PostHog](https://posthog.com/) or [Hotjar](https://www.hotjar.com/) can support A/B testing and user behavior analysis, helping teams test ideas fast and refine based on results.
Image (01.png)
## Investing in Experimentation and AI Wisely AI tools are everywhere now, but that doesn’t mean you need to use all of them. The key is to experiment in smart, simple ways. Start small. Choose one idea e.g. “summarizing user feedback with AI or predicting churn” and test it. Use tools like PostHog, Hotjar, or even internal dashboards to track results. Look for early signals of value before scaling up. **Don’t overbuild.** The first version of an AI feature should be quick, low-cost, and easy to change. Focus on helping users or saving time. Avoid using complex tech just for the sake of it. **How much to invest?** Base it on value and effort. If the idea takes more than “a few days/week” to build and doesn’t solve a real user problem, it’s likely not worth it yet. AI should fit into your product’s goals, not pull attention away from them. ## Conclusion Good product decisions don’t rely on either data or instinct alone. They use both. Combine experience with evidence. Test ideas fast. Use AI where it helps. That’s how teams move forward with clarity and confidence. --- title: Continuous Discovery for Developers url: https://alexdimango.com/blog/continuous-discovery-for-developers/ date: 2025-02-04 tags: ai-adoption, hiring, measurement --- For years, product discovery has been seen as a **PM** and **designer-driven process**, with developers involved but **deprioritizing it in favor of delivery**. However, in modern product development, waiting for final specs is outdated. Developers should be engaged in shaping what gets built — not just how it gets built. This is where **Continuous Discovery** comes in. By integrating **engineering insights early**, teams can validate assumptions faster, reduce waste, and create products that are both **valuable and scalable**. ## **Why Developers Should Be Actively Involved in Discovery** Discovery isn't just about finding the right user problem; it's also about **finding the right technical approach**. Developers can **proactively contribute** to discovery in several ways. ### **1\. Build for Tech Wealth, Not Just Features** In the world of Continuous Discovery, developers aren’t just executors — they’re strategic partners who help shape what gets built and how it evolves. A crucial part of this responsibility is balancing **Tech Wealth vs. Tech Debt**. Instead of accumulating **Tech Debt** that slows progress and turns into a never-ending backlog, **Tech Wealth** is about being proactive. Minimizing Tech Debt doesn’t mean avoiding it entirely, it means managing it wisely. Too often, teams treat **Tech Debt** as just another backlog item, continuously pushing it forward rather than addressing it in ways that lead to better long-term solutions. > This doesn’t mean overengineering — software development isn’t a binary choice. It’s about finding the right balance between speed and sustainability ### **2\. Prototype to Test Feasibility Early (with AI & Automation)** Product teams often rely on **mockups and user tests**, but developers can **go one step further** with rapid technical prototyping. AI and automation tools are making this process even more efficient: 🤖 **[Use Cline](https://cline.bot/faq)** — an **AI coding agent** that builds software components, APIs, and entire features based on high-level prompts. Instead of manually prototyping an idea, developers can **describe the logic**, and Cline will generate working code. This enables rapid **iteration and validation** before investing time in full development. 🤖 **[Leverage Claude](https://www.anthropic.com/) (Anthropic’s AI assistant)** for **rapid code scaffolding** — it can generate proof-of-concept APIs, script automation, and even suggest optimizations before full development. - Suggest **low-cost MVPs** instead of overengineering a full solution. - Use **feature flags or A/B testing** to test features in a live environment. With AI-driven tools like Cline and Claude, teams can prototype faster, reducing uncertainty and accelerating the discovery process. ### **3\. Challenge Assumptions with Data** Developers often have access to **backend analytics, logs, and performance metrics** that reveal hidden user behaviors. They should use this data to **challenge product decisions**: 1. Do we need this new feature, or can we improve an existing one? 2. Can we solve this problem with automation or better defaults? 3. Are we measuring the right success metrics, or are we optimizing for the wrong thing? One way developers can actively contribute to **data-informed discovery** is by leveraging **[Metabase](https://www.metabase.com/)**, a powerful open-source BI tool that allows teams to **explore and visualize product data** minimal effort. ### **4\. Join Discovery Conversations** Developers shouldn't just wait for specs — they should be **involved** when problems are being discussed. Some ways to get involved: 1. **Attend customer interviews** to hear pain points firsthand. Tools like [Chattermill](https://chattermill.com/product-tour) can help analyze customer feedback at scale, making it easier to identify recurring issues. 2. **Co-design solutions** with PMs and designers. 3. **Offer technical perspectives** on what’s viable and scalable. By participating early, engineers can **shape the problem space** rather than just receiving the solution. ### **5\. Think in Systems, Not Just Features** Many product ideas focus on **short-term feature delivery**, but great engineers look at **long-term system impact**: - How does this feature fit into our tech roadmap? - Are we creating a fragmented experience by adding this? - Will this add operational costs or tech complexity we’ll regret later? Bringing a **systems-thinking approach** to discovery helps avoid unnecessary complexity and **improves long-term product stability**. ## **Takeaways** Developers who are involved in discovery don’t just build features — they shape better products. By prioritizing Tech Wealth, rapid prototyping (with AI and automation), data-driven decisions, and cross-functional collaboration, developers can ensure their teams ship not just fast, but smart. The best engineers don’t just write code — they help define what’s worth building in the first place. --- title: Are you planning your next year SaaS strategy? url: https://alexdimango.com/blog/are-you-planning-your-next-year-saas/ date: 2024-12-08 tags: hiring, measurement, career --- In 2025, SaaS companies operate in a challenging environment where the need to innovate, grow, and deliver value while maintaining scalability and efficiency is more demanding than ever. With priorities like retaining customers, improving developer experience, closing larger deals, and increasing revenue, determining what matters most can feel overwhelming. To build a strong business & tech strategy, start by taking stock of where you are now. Are your fundamentals solid? Is your technology stack aligned with your vision? A weak foundation often causes delays and bottlenecks. Cutting corners to achieve a faster go-to-market might seem tempting, but it can lead to a backlog of technical debt and a fragile system that will cost more in the long run. > Quality code doesn’t take longer; it takes focus. Here’s how to structure a strong strategy, along with the essential elements every SaaS company should prioritize. ## **Core Components** ### **1\. Be Business-Aware** Define what success looks like for your SaaS company in the context of business needs. Use measurable goals to track your progress. Examples include: - Increasing annual recurring revenue (ARR) by a specific percentage. - Reducing churn to improve customer lifetime value. - Enhancing revenue per full-time employee (FTE) to boost efficiency. Understand and align with the key business **metrics driving your company’s growth and sustainability**. SaaS companies thrive on a combination of growth and retention metrics, so focus your strategy on the outcomes that deliver meaningful results. **Measure and Align:** Ensure all internal and external stakeholders understand these metrics. Regularly communicate progress and challenges through clear updates and collaborative discussions. This alignment ensures everyone is moving in the same direction. ### **2\. Product Focus** Pinpoint the technical capabilities that will drive progress. This could involve building new features, improving existing ones, or ensuring the stability and scalability of your platform. **Focus on Demand Forecast:** Accurately project feature adoption and resource requirements. Use tools and customer feedback to identify high-impact areas for development. Balancing demand forecasting with infrastructure readiness ensures you can scale without compromising performance. **Measure and Align:** Regularly assess product metrics like feature adoption and user satisfaction. Create shared accountability across teams by tying these metrics to broader company goals. **Pitch the value -** Demonstrate how these product investments directly impact revenue, retention, or growth during internal planning sessions to maintain alignment and support. ### **3\. Target Market** Understand your current and future customers deeply. Who are they, and how are their needs evolving? Evaluate: - Market size and growth potential. - Upselling and cross-selling opportunities within your customer base. - Expansion into new verticals or geographies. Invest in customer research to stay ahead of industry shifts. Use interviews, surveys, and data analytics to align your product with market demands. **Set a budget for it; this is the best-invested money.** ### **4\. Competitive Advantage** Clarify why customers will choose your product over others. Focus on areas where you can sustain an edge, such as: - **User Experience (UX):** Make your software intuitive, fast and enjoyable to use. - **Onboarding and Support:** Provide seamless onboarding experiences. Use self-service resources, live support, and training to help users realize value fast. - **Security and Compliance:** Build trust by exceeding industry standards in security, privacy, and regulatory compliance. SaaS companies that invest in these areas build long-term loyalty and reduce churn. ### **5\. What Not to Do** A strong strategy also defines what you won’t pursue. State which projects, features, or initiatives you will deprioritise. For example: - Avoid spreading resources too thin by chasing every new trend. - Say no to features that don’t directly contribute to customer value or business growth. Being clear about what to avoid helps you focus on initiatives that deliver measurable results. * * * ## Conclusion A clear and focused tech strategy is essential for SaaS success. Build your approach on business awareness, demand-driven product development, and deep customer insights. Start with a strong foundation, align your team with your vision, and prioritize ruthlessly to avoid distractions and achieve meaningful progress. A good place to start? Use the Eisenhower Matrix. This framework helps you categorize tasks and initiatives based on urgency and importance, making it easier to prioritize, delegate, or eliminate them. It’s a simple yet powerful tool to keep your team focused on what matters most. Learn more at [The Eisenhower Matrix](https://www.eisenhower.me/eisenhower-matrix/). --- title: Why keep estimating software development? url: https://alexdimango.com/blog/why-keep-estimating-software-development/ date: 2024-10-28 tags: hiring, career --- My first experience with estimation was about 15 years ago, working with a big bank in a classic waterfall setup. Since then, I’ve worked with digital agencies and high-growth startups, each bringing its own unique challenges and lessons. Through these roles, **I saw that target dates help projects stay on track**, even if the exact timelines are hard to predict. Estimates set a clear focus. Without them, teams can fall into the trap of endless tweaks and refinements — a problem often explained by **Parkinson’s Law**, which suggests that tasks expand to fill the available time​
Copyright: https://asana.com/resources/parkinsons-law
Copyright: https://asana.com/resources/parkinsons-law
Setting target dates lets teams prioritize core functions, deliver value faster, and avoid getting bogged down in non-essential details. Even if a date shifts, the deadline itself helps keep a clear direction, balancing flexibility with the need to move forward. ## Why Target Dates Are Useful 1. **Focus and Urgency** Virtual target dates act as self-imposed deadlines that give the team focus and urgency. These timeframes help avoid endless cycles of improvement by creating a clear endpoint, countering “Parkinson’s Law,” which suggests work will expand to fill the time given​ 2. **Clear Priorities** Deadlines help teams identify which tasks are essential. When time is tight, target dates guide teams to focus on high-priority features and let go of lower-priority items, preventing the project from becoming overloaded. 3. **P&L Alignment** Target dates help tie product work to financial outcomes. They encourage teams to deliver measurable value and support accountability by linking efforts to business results. 4. **Accountability and Trust** Estimates give all stakeholders a shared understanding of what to expect and when. This builds trust and clarity across teams, reducing surprises and miscommunication as everyone works toward the same end goal. 5. **Encourages Consistent Progress** Target dates provide a framework of accountability, helping teams stay on track. Even if timelines shift, these targets keep projects moving and build a reputation for reliability within the team. ### Conclusion Estimates aren’t about guaranteeing exact delivery dates — they’re about creating structure. With target dates, teams can balance flexibility with focus, ensuring steady progress without endless cycles of refinement. --- title: Buy vs Build: How to Make the Right Choice for Your Business url: https://alexdimango.com/blog/buy-vs-build-how-to-make-the-right/ date: 2024-10-11 tags: hiring, leadership --- When your company needs new software or wants to replace an existing solution, you face a key decision: > should you buy a ready-made product or build your own? Both options have **pros** and **cons**, and the right choice depends on your goals, timeline, and resources. Let’s explore both paths and introduce a strategic framework that will help guide your decision-making process. ### Buying Software Buying software means choosing an existing solution that’s ready for use. Many companies provide software solutions designed to fit general needs. Buying is often seen as the quicker and simpler route, especially for standard business operations. #### **Advantages of Buying** 1. **Quick to start**: Off-the-shelf software is usually ready for immediate use, meaning you can get up and running fast. 2. **Lower upfront costs**: Purchasing software is often cheaper at the start, as it avoids the costs of development. 3. **Less risk**: Established products come with support, regular updates, and fewer unknowns, reducing the risk for your business. 4. **Support included**: Most software providers offer help and ongoing maintenance, so you don't have to manage these tasks internally. #### **Disadvantages of Buying** 1. **Less flexibility**: The software may not fully fit your needs, and customisation options are often limited. 2. **Vendor dependence**: You're tied to the vendor’s pricing, updates, and features, limiting your control over the software’s evolution. 3. **Ongoing costs**: Subscriptions, licenses, and additional charges can add up over time, making the solution more expensive in the long run. ### Building Software Building software means creating a custom solution tailored to your exact requirements. This approach takes longer, but it offers full control over the product’s design and functionality. #### **Advantages of Building** 1. **Tailored to your needs**: You can design software that fits your business perfectly, with no unnecessary features or limitations. 2. **Full control**: You decide how the software works, when to update it, and what features to add, without relying on an external vendor. 3. **Competitive edge**: A custom solution can provide unique features that give you an advantage over competitors using standard tools. #### **Disadvantages of Building** 1. **High upfront costs**: Building software requires significant investment in time, money, and resources. 2. **Longer time to launch**: Development can take months or even longer, delaying your ability to start using the solution. 3. **Ongoing maintenance**: Once you build the software, your team must handle updates, bug fixes, and improvements. ### How to Decide: Key Questions 1. **Is this core to your business strategy?** Start by asking if this solution is central to your business. Is it crucial to own the intellectual property in this area? If it’s a core component of your business model, building may give you the control and ownership you need. 2. **How unique are your needs?** If your requirements are highly specific to your business, building may be necessary. If not, a ready-made solution could work just as well. 3. **How fast do you need the solution?** Time-to-market is critical. If you need a solution fast, buying or using no-code platforms is typically the quickest option. 4. **What’s your budget?** Consider not just the upfront costs, but also the long-term costs. Compare the recurring cost of a SaaS subscription to the cost of hiring full-time employees (FTEs) for development and maintenance. While SaaS might seem cheaper initially, FTEs may be more cost-effective over time, especially with high usage or complex requirements. 5. **What level of control do you need?** Full control over the system may be vital if you require customisation or plan to evolve the solution. If control isn’t crucial, a bought solution might suffice. 6. **What level of integration do you need?** Consider the complexity and cost of integrating a bought solution with your existing systems. Will you need customisation, or can you use it as-is? 7. **What are the risks?** Assess the security, compliance, and vendor risks. In a regulated industry, these risks can strongly influence whether to build or buy. 8. **Do you have internal expertise?** If your team has the technical skills, building may align with their expertise. If not, no-code/low-code platforms or buying may be more practical. 9. **Roadmap control and time-to-market** While control over the product’s future is important, consider how long it will take to build versus buy. How crucial is it to get the solution in place fast? ### Balancing Vision with Practicality CTOs with a technical background and those with a business focus often approach the build vs buy decision differently. A CTO who has spent years building software may prefer custom solutions. They see building as a way to tailor systems to the company’s exact needs. But building software comes with challenges. It requires ongoing maintenance, fixing bugs, and long-term costs to keep the software running smoothly. A CTO with a business focus, however, often looks for existing solutions. They ask, “Is building this the best use of our time? Can we solve this with a product already available?” Their goal is to save time and money, making sure resources are used wisely and avoiding the extra costs of custom development when it’s not needed. The best CTOs combine both views. They know when building is essential and when buying makes more sense for the business. ### Using Wardley Mapping to Guide Your Decision One strategic tool that can help make the buy vs build decision easier is **Wardley Mapping**. This framework, developed by Simon Wardley, helps you map out the components of your business, see where they are in their lifecycle, and decide which areas need innovation (build) and which can be satisfied with existing solutions (buy).
Canvas designed by Ben Mosior. Visit https://hiredthought.com/wardley-mapping for more information.
Canvas designed by Ben Mosior. Visit https://hiredthought.com/wardley-mapping for more information.
#### **How Wardley Mapping Works:** 1. **Identify User Needs**: Start by defining what your users (internal or external) need from the software. 2. **Map the Value Chain**: Break the solution into smaller components. Plot each component on a map according to how visible it is to the user and its maturity. - **Visible**: Components that users directly interact with (like user interfaces). - **Invisible**: Hidden components (like back-end infrastructure). 3. **Classify Each Component**: Use the map to classify components into three categories: - **Genesis**: New, innovative technologies (often best to build). - **Custom-built**: Components that add specific business value (build if it differentiates you). - **Commodity/Utility**: Mature, well-understood components (best to buy). 4. **Decide Where to Innovate**: Wardley Mapping helps you decide where to innovate by building custom solutions and where to buy existing tools that meet your needs. #### **Benefits of Wardley Mapping** - **Visual clarity**: You get a clear picture of which parts of the project are critical to your business and which can be handled by standard solutions. - **Focus on value**: This helps you focus resources on the areas that deliver the most value to your business. - **Avoid reinventing the wheel**: The map makes it easy to spot when buying is the smarter choice for mature, standardised components. ### **Balancing Innovation and Cost Control in Software Development** A senior engineer or technical strategist plays a crucial role in maintaining the balance between innovation and cost control. They recognize that while custom software development may seem attractive, it can burn through time and resources if not carefully managed. By using tools like Wardley Mapping, they help the team focus on building solutions that offer genuine competitive advantages, while opting for off-the-shelf tools when appropriate. This strategy helps avoid unnecessary development costs and ensures the team stays aligned with the company’s long-term objectives. ### A Mixed Approach In some cases, a hybrid approach works best. You can buy a core software solution and then build custom add-ons to meet your specific needs. This allows you to leverage the speed and stability of existing products while tailoring certain aspects to fit your business more closely. ### Conclusion When deciding between buying or building software — whether you need a new solution or want to replace an existing one — both junior enthusiasm and senior experience have their place. Junior developers often favor building for the thrill of creating something new, while senior tech leads weigh the long-term costs and benefits. Using frameworks like Wardley Mapping can guide your decision, ensuring that you invest resources in areas that offer real value and competitive advantage. The right choice depends on your business goals, but combining strategic thinking with experience can help you choose wisely. --- title: How I Built a Slack App Using ChatGPT — all without writing a single line of code. url: https://alexdimango.com/blog/how-i-built-a-slack-app-using-chatgpt/ date: 2024-09-30 tags: ai-adoption, hiring, leadership --- As a CTO, you often face the challenge of balancing limited developer resources with the need to ship quality software fast. What if you could build an app without consuming hours of your team’s time? Recently, I created a Slack bot to detect PII in messages — using nothing but AI-driven prompts. No traditional coding required. ### **See It in Action** _Watch the [Loom demo](https://www.loom.com/share/2c2fa124690843248af106cbcbee0e77) to see how this app was built using prompts and AI. It’s a new way of getting things done faster._
Image (01.png)
### **The Numbers:** - **Prompts Used:** 5 - **Time Spent:** 45 minutes - **Tech Stack:** Node.js, TypeScript, Jest - **Developer Code Written:** Zero In under 45 minutes and just five prompts, I had a fully functional Slack app written in TypeScript, complete with automated tests and CI/CD integration through GitHub Actions. **[Check out the code on GitHub](https://github.com/adimango/slack-pii-bot)** ### **Step-by-Step: How It Worked** Here’s how I guided AI to build this Slack bot, one step at a time. #### **1\. Starting with the Basics:** I started with a clear objective: “Create a Slack bot in TypeScript that detects PII in messages according to GDPR standards.” With this, the AI set up the bot, adding logic to detect common PII types like emails, phone numbers, and credit card numbers. #### **2\. Structuring the Code for Scalability:** For any engineering leader, code quality and maintainability are key. So, my next prompt was: “Organize the code using a model-view-service pattern and create a separate utility for PII detection.” This allowed the AI to structure the app in a modular way, making it easier to test, extend, and maintain. #### **3\. Handling Slack Events:** Next, I needed the bot to interact with Slack in real time. I prompted the AI: “Listen for Slack messages, check for PII, and send a warning if found.” The AI then generated the event handling logic, enabling the bot to respond instantly when sensitive information was detected. #### **4\. Automating Testing:** Testing is non-negotiable in any software project. I instructed the AI: “Write tests for European and American phone numbers, credit card numbers, and Slack-formatted email addresses.” Within seconds, I had Jest test cases for various PII scenarios. #### **5\. Preventing Potential Issues:** To avoid a common pitfall where the bot could end up responding to its own messages, I used a straightforward prompt: “Ignore messages sent by the bot itself”. ### **The ROI of Prompt-Driven Development** As a CTO, you know that time and developer resources are the most valuable assets. Here’s a breakdown of how much this approach can save: - **Time Saved:** Building this bot traditionally would take at least half a day. With AI, it took just 45 minutes. - **Cost Efficiency:** Developers spent zero time writing boilerplate code, allowing them to focus on higher-value tasks. - **Scalability:** With a prompt-driven model, you can extend functionality fast. Adding features becomes a matter of instructing AI, not re-architecting code. ### **Key Takeaways for Engineering Leaders** - **Clarity Drives Success:** When using AI, specificity in prompts results in better output. Know what you need, and instruct the AI directly. - **Iterate in Small Steps:** Guide the AI incrementally. Each prompt should tackle a specific problem, allowing you to steer the outcome. - **Use Real Examples:** Including real-world use cases in prompts helps the AI create comprehensive solutions that align with your needs. ### **Conclusion: A Strategic Shift in Development** This experiment proves that you can build functional apps without draining your team's coding hours. With prompt-driven development, AI can handle the tedious setup, freeing up developers for strategic, complex work. The Slack bot was built entirely through prompts. The only human involvement was in defining the requirements and managing the generated files. Imagine what else your team could achieve if they spent less time on boilerplate coding and more time on innovation. **Ready to see how simple it can be? Check out the Loom demo and explore the code on GitHub to see the Slack bot in action.** --- title: Documenting Decisions Through RFCs url: https://alexdimango.com/blog/documenting-decisions-through-rfcs/ date: 2024-06-11 tags: hiring, leadership, career --- Scaling an engineering team is hard. Lines of communication and interactions between teams grow constantly and more than proportionally. Eventually, you may find yourself dealing with problems like technology misalignment, lack of visibility, and team duplicating effort or not following standards. How can you ensure everybody in the team has the necessary visibility and can participate and contribute to technical discussions? > One effective solution is the Request For Comment (RFC) process. * * * ### What is an RFC? The RFC system was first introduced by Steve Crocker in 1969 to help record unofficial notes during the creation of the ARPANET. Later, Internet RFCs became established and are used by the Internet Engineering Task Force as official documents of Internet specifications, communications protocols, procedures, and events. ### Using RFCs Well To streamline decision-making and enhance collaboration, it's important to understand that RFCs are not limited to engineering topics. There's a common misconception that RFCs are only for engineering topics. In reality, RFCs often cover cross-domain topics that involve product management, customer success, and other areas. This inclusive approach ensures comprehensive decision-making across the organization. #### When to Use the RFC Process An RFC should be written when planning to make substantial changes that impact the entire organization. What constitutes a “substantial” change varies but may include: - Major infrastructure changes (e.g., migrating to a new cloud provider) - New security conventions (e.g., implementing company-wide SSO) - Replacing open-source libraries (e.g., switching from one logging library to another) - Refactoring significant parts of the application (e.g., reworking the customer onboarding process) #### When Not to Use the RFC Process While RFCs are powerful, they are not always necessary. Avoid using RFCs for: - Decisions that need to be made fast to resolve an immediate issue - Minor bug fixes or patches - Small, incremental changes that do not affect the overall architecture or team workflows - Routine maintenance tasks ### RFC Instructions #### RFC Owner They support the proposed design, ensure the RFC follows existing design and style rules, help the review committee reach an agreement, and make sure the proposed implementation is prioritized and assigned to teams. #### Feedback The purpose of RFCs is to ensure the community is well represented and served by new changes. Community members should take part in reviewing RFCs where they care about the outcome, provide feedback fast, read RFCs thoroughly, and be polite and constructive. #### Reviewer The goal of the review meeting is to fix minor issues; major issues should be resolved beforehand. The committee makes sure that public feedback has been considered, adds their meeting notes as comments on the PR, and provides reasons for their decisions. #### **Action Points** Once an RFC is approved, it is the owner's responsibility to write the action points to help prioritize and implement the solution. * * * ### Takeaways After introducing an RFC process, you can expect significant improvements in team collaboration and decision-making. Every engineer brings a wealth of experience and knowledge. Participation and collaboration are key to the evolution of any tech team. Creating the conditions for everyone to contribute and participate in the company's growth and service ensures continued success and innovation. By adopting and tailoring an RFC process to your organization's needs, you can foster a more collaborative, transparent, and efficient decision-making environment, ultimately driving better outcomes for your tech team. --- title: Sustainable Software Architecture: 3 Quick Wins url: https://alexdimango.com/blog/sustainable-software-architecture/ date: 2024-04-09 tags: hiring --- Microservices, Docker, Kubernetes and Serverless have certainly transformed the game, injecting unparalleled reliability and scalability into the tech world. Yet, this brings us to a pivotal query: **the hard cost management of software architecture on the downswing.** This is why an increasing number of organizations are evaluating the moving away from the cloud. Easy tooling has reduced complexity and facilitated adoption, yet projecting the overall long-term costs remains challenging. #### Breaking Down Silos: The Role of Developers A common scenario in many organizations is developers focused on features and target dates, often detached from the implications of how their code runs or the costs associated with it. This disconnect can lead to ineffective use of resources, inflated costs, and a larger environmental footprint than necessary. Imagine a scenario where developers design with awareness of the energy consumption and cost implications of their code. This awareness could lead to more efficient coding practices, such as optimizing algorithms for better performance or choosing more energy-efficient software patterns (there's no need for fast queries or indexes with XXXL Postgres instances) Is this science fiction? No. Netflix's commitment to optimizing its content delivery network not only enhances user experience but also cuts bandwidth consumption. This is directly tied to cost savings and environmental sustainability > Netflix invested over $1 billion in developing [Open Connect](https://openconnect.netflix.com/en/), their own content delivery network, which they offer for free to ISPs.
Copyright at https://about.netflix.com/en/news/energy-efficiency-in-streaming
Copyright at https://about.netflix.com/en/news/energy-efficiency-in-streaming
#### The Misconception of DevOps Teams The introduction of DevOps teams in organizations was a game changer, fostering better collaboration between development and operations. However, relegating the responsibility of monitoring resource usage (size, reservations) solely to the DevOps team misses the mark. Sustainable software architecture necessitates a collective effort. Consider how Spotify uses its GCP’s BigQuery to monitor and optimize data storage and processing costs. This is not just a task for the DevOps team but a company-wide strategy that includes developers understanding the cost implications of their data handling practices. #### Quick Wins for a Sustainable Mindset Adopting a sustainable software architecture isn't about making drastic changes overnight but about integrating cost and resource effectiveness into the development lifecycle. This includes: - **Sustainability by Design:** Encouraging a mindset shift towards building software with sustainability as a core principle, not an afterthought. Example: Rewriting a product recommendation algorithm to run 30% faster, thereby reducing CPU usage and energy consumption. - **Cost Visibility:** Making cost data accessible to developers enables them to understand the financial impact of their coding decisions. Maintain a dashboard displaying monthly costs for each DX tool, such as AWS, Datadog, Sentry, CircleCI, etc. - **Predictive Management**_:_ Adopting a forward-thinking approach by using predictive analytics to manage resources efficiently. Transition to a model where resources are not just allocated based on current needs (classic traffic demand) but are predictive, ensuring high availability during critical moments and conservation when possible. * * * #### In Conclusion Embarking on a journey to sustainable software architecture is a team effort. It's about changing our view of tech from just tools to a vital piece of our world, blending business needs with care for the environment. When we make sustainability a core part of building software, we're not just aiming for profit. We're setting up for breakthroughs that go hand in hand with making the Earth a better place. Small steps for a big impact. --- title: Continuous Delivery is not a technical aspect url: https://alexdimango.com/blog/continuous-delivery-is-not-a-technical/ date: 2024-03-14 tags: hiring, measurement --- The true essence of continuous delivery lies not just in **its technical aspects** but in its ability to make businesses nimble, responsive and adaptable. At its core, continuous delivery is about ensuring that all types of changes, including new features, bug fixes, and infrastructure updates, can be introduced into production safely and on demand. This concept, while technically inclined, carries a profound impact on the business as a whole. In fact, it's about transforming the way teams, processes, and organizational structures work and adapt to changes. ### **Why Aim for Continuous Delivery?** In a world where market conditions and consumer expectations shift fast (as we have seen in the past two years), the ability to adapt and respond with minimal delay is invaluable. The benefits extend beyond the realms of efficiency and speed. Consider the difference between teams bogged down by infrequent, large-scale deployments and those who have mastered frequent releases. The latter not only achieve a more streamlined workflow but also cultivate a healthier work environment, demonstrating the broader implications of continuous delivery. ### **The Path to Continuous Delivery** Adopting continuous delivery means embarking on a transformative journey that touches every aspect of your organization. #### Process Optimization Yet, the machinery of continuous delivery runs on more than just technical excellence. It demands lean processes that eliminate bottlenecks and ensure that value flows smoothly from idea to implementation. This means rethinking how user stories are defined, reducing handovers, ensuring clear outcomes and how to measure success. 1. Define clear milestone outcomes 2. Make clear hoe to measure success #### Technical Foundations It begins with solid technical foundations: automation across development, testing, and deployment processes; high-quality, automated testing to ensure reliability; and robust deployability practices to allow for frequent, incremental updates. 1. Avoid postponing test automation. 2. Ensure DX with short build times. 3. Make the release process stress-free. #### Enforce Business Agility This involves fostering a culture that values rapid experimentation, learning from real-world feedback, and adapting strategies in real time. It's about breaking free from the rigid planning cycles of the past and moving towards a more dynamic, iterative approach to innovation. 1. Be ready to be wrong 2. Be ready to change strategy 3. Be ready but avoiding layer of abstraction This agility is not just a technical achievement but a strategic advantage. When an opportunity arises to launch a feature that capitalizes on a trending market need, they're able to roll it out in record time, gaining a competitive edge and delighting customers. > All problems in computer science can be solved by another layer of abstraction… Except for the problem of too many layers of abstraction. > > — Butler Lampson ### **In Conclusion** Continuous delivery is more than a set of practices; it's a philosophy that champions adaptability, efficiency and customer satisfaction. In essence, continuous delivery is about ensuring your business can respond with agility to whatever challenges and opportunities the future holds. It's a commitment to ongoing improvement, learning, and adaptation. By embracing this approach, organizations can ensure they're not just keeping pace with the digital landscape but leading the charge. --- title: Simplifying the Complex: The Secret to a Small/Mid-Size Startup Data Warehouse url: https://alexdimango.com/blog/simplifying-the-complex-the-secret/ date: 2024-02-28 tags: hiring, measurement, career --- You realize it's time to adopt a more analytical approach to decision-making but the question remains: which data sources to use and how to begin? In the following article, I will share some of my key learnings and a solid serverless setup for a data warehouse. > Nowadays, there is an overload of data and many times, less is better. My first lesson learned in building a data warehouse was to initially reduce the data sources and focus on key business metrics. **Choosing the Right Data Sources** For the majority of organizations I've worked with, the main data sources were payments, customer success tickets, and NPS. These sources are not just streams of data; they are the veins through which the lifeblood of the business flows, offering a transparent view into its health and customer perceptions. Once the data sources were finalized, it was time to decide how to connect to them or get notified in real-time. For this, one of the most effective and cost-efficient solutions was leveraging AWS Lambda or, more generally, serverless functions. **Simplifying Data Collection** Transforming how we collected data was a key turning point. By integrating webhooks and employing AWS Lambda for our ETL (Extract, Transform, Load) processes, we streamlined data collection. Webhooks, alerting us in real-time to events like new Stripe transactions or Zendesk tickets, and AWS Lambda, automating the journey of data from source to warehouse, made the process efficient and nearly hands-off. Going with Redshift or even Google BigQuery? Well, do you have large data sets that could make running queries super slow? If not, consider starting with a simpler solution, such as AWS S3 or PostgreSQL, and later move to a more performant service like Redshift. Once the data structure is defined, migrating it to a more performant service shouldn't be a problem. What if someone on your team pushes for a data mesh? Small businesses often start with a more centralized data management approach, which is simpler and more cost-effective to implement and maintain. Do not try starting with it. Once our data was securely stored, the focus shifted to translating this vast information into actionable insights. **Reporting and Insights with AWS QuickSight**
Image (01.jpeg)
AWS QuickSight became the tool of choice, enabling us to create dashboards that were not just visually engaging but also rich with intelligence. It allowed us to effortlessly monitor key business metrics, from monthly revenue streams to customer satisfaction indices, illuminating the path to data-driven decision-making. Defining and focusing on key business metrics was central to our strategy. This step was about distilling the vast ocean of data into the quintessential elements that would inform our strategic and product development decisions. Moving away from reliance on instinct to a more data-oriented approach marked a pivotal shift in our decision-making processes **The Outcome** This straightforward yet strategic approach to data warehousing has been transformative. It has brought hidden trends to light, identified growth opportunities, and preemptively addressed potential challenges. More than just optimizing operations or refining decision-making, it has changed how startups engage with their data, leading to more informed strategies and happier customers. **In Conclusion:** > _Simplifying the Complex_ Building a data warehouse for a mid-sized startup doesn't have to be an overwhelming challenge. By focusing on essential data sources, leveraging automation for ETL processes, and utilizing tools like AWS QuickSight for analytics, startups can unlock the full potential of their data. This approach ensures that data warehousing efforts are not only aligned with business goals but also pave the way for insightful, data-driven growth. --- title: 3 Key Indicators for Better Planning: Impact, Effort, and Risk as Pillars of Shared Understanding url: https://alexdimango.com/blog/building-shared-understanding-of/ date: 2024-02-13 tags: hiring, leadership, career --- Balancing the impact and effort for new feature development with all the rest that arrives daily as a to-do on the engineering department's table is a critical task every CTO faces on their journey. It’s not only about arrenging resources; it’s about strategically directing your efforts to ensure every project, whether aimed at external customers or enhancing internal effectiveness or experience, **drives substantial business value.** Achieving this balance requires a nuanced understanding of impact and alignment with overarching business goals. In the past, I found a simple matrix that scores todos on **impact, effort, and risk** the most useful tool for this, and I would like to show here the approach I used. The **first step** was setting clear objectives for each initiative. This helped me determine whether I was rolling out a new customer feature or upgrading an internal tool; defining what success looks like is the first step. These objectives should align with broader company goals, such as improving customer satisfaction, streamlining operations or accelerating product innovation. I find this also to be a useful exercise for engineers; in fact, it's crucial to ensure that we avoid communicating the classic: > we need to refactor/ we have tech debt but instead focus on explaining what the impact and the risks will be. Is poorly written code risky? When the initiatives are defined, you can start to use the matrix.
Image (01.jpeg)
## **The Impact-Effort-Risk Matrix** This matrix is a tool to visualize and prioritize initiatives by categorizing them according to three critical dimensions: - **Impact**: The potential benefits an initiative will bring to customers, internal processes, or developer experience. This could include improved customer satisfaction, operational efficiencies, or revenue growth. - **Effort**: The amount of resources, time, and manpower required to execute the initiative. This helps in understanding the investment needed for each initiative. - **Risk**: The uncertainties associated with each initiative, including growth risk (how it might affect company growth), market certainty (external factors that could influence success), and implementation risk (technical or operational challenges). Initially, you try to assign effort and impact. I would recommend always starting by focusing on quick wins (low effort/big impact) and then moving toward bigger effort initiatives. - **High Impact, Low Effort, Low Risk**: These projects are “quick wins”. They require minimal effort and carry low risk but promise significant benefits. Prioritizing these projects can lead to immediate improvements in customer satisfaction or internal efficiency. - **High Impact, High Effort, Moderate Risk**: These are “major projects”. They are essential for long-term strategic goals but require substantial resources and carry a higher level of risk. These initiatives need careful planning and risk mitigation strategies. - **Low Impact, Low Effort, Low Risk**: Termed as “fill-ins”, these projects don't offer substantial benefits but are easy to implement. They can be taken up in downtime or when resources are available without detracting from more critical tasks. - **Low Impact, High Effort, High Risk**: These projects are “question marks” and generally should be avoided or re-evaluated. They consume significant resources and carry high risk without promising proportional benefits. While the Impact-Effort-Risk Matrix is a valuable tool for prioritizing projects, it's important to recognize that it is not a one-size-fits-all solution. Like any prioritization tool, its effectiveness is contingent upon the quality and completeness of the information used to fill it out. A critical consideration is that relatively few people in an organization possess the comprehensive insight necessary to accurately assess all three dimensions of the matrix. Impact and Confidence are primarily **business domain**, requiring a deep understanding of market dynamics, customer needs, and strategic objectives. On the other hand the Effort falls within the **technical domain**, demanding a clear understanding of the complexities involved in implementing a given initiative. This division between business and technical domains underscores the necessity for **cross-functional collaboration in the prioritization process**. It's essential that teams bridge this gap, bringing together stakeholders from across the organization to contribute their unique perspectives. By doing so, the organization can ensure that the projects selected for prioritization are not only technically feasible but also aligned with business goals and likely to achieve the desired impact. ## **Takeaways** Try to use the Impact-Effort-Risk Matrix or a similar framework for prioritizing projects by evaluating them against key business dimensions: Impact (the potential benefits), Effort (required resources), and Risk (associated uncertainties). Always review and improve the accuracy of these evaluations, which depends on cross-functional collaboration. Impact and Effort often require insights from both business and technical domains --- title: Building an Engineering Career Path in Startups: My Take on It url: https://alexdimango.com/blog/building-an-engineering-career-path/ date: 2024-01-23 tags: hiring, career --- Creating an engineering career framework in startups is like plotting a journey on a map. It's got to be clear, adaptable, and in line with your startup culture. Here's a straightforward look at how to do this, based on what I've learned along the way. ## **What Your Startup Believes In** Your startup's values are like its heartbeat. The career path you set up should match these values. This means making sure that each step forward in someone’s career helps them and the startup stay true to these beliefs. It's like making sure every step takes you in the right direction. In addition to the overall startup pillars, you should have more engineering-specific pillars. Start defining engineering principles too. In the second part of the following article, you will find some of what we defined when I was at limehome: [Limehome's Engineering Principles](https://medium.com/limehome-engineering/limehome-domain-driven-design-engineering-principles-583c0736d64) See few of them below: - We believe that each domain should have the people and the tools to build/deliver/iterate without dependence on the other teams. - We make changes small — the only way to know if it works is to get feedback from real users and see how they use it - We deeply understand the importance of documenting well our work What a good framework should be is a facilitator in navigating professional growth. It should focus on key competencies, which become more specialized as one progresses in seniority within each role. It's also important to ensure that individuals transitioning from an Individual Contributor (IC) to a People Manager role have a clear understanding of the respective competency pillars. I would suggest interim positions for those who are unsure about their preferences, and make it clear that it is possible to move between tracks along the way, too. Developing people is not for everybody
Image (01.jpeg)
A good framework for Individual Contributors might include competencies in: - Architecture - Code - Delivery For Engineering Managers, the areas of competency could be: - Team Building - Coaching Additionally, it important to be make clear that these areas are not exclusive to each respective role. ## **Keep It Simple and Smart** In a startup, you've got to be smart and iterative with your guidelines. So, start your engineering career framework small. There's no need to make everything from scratch. It's okay to take good bits from other companies’ ways of doing things and then tweak them to fit your startup's style. Here are the resources I found most valuable: - [Engineering Career Development at GitLab](https://handbook.gitlab.com/handbook/engineering/careers/) - [Why We Redesigned Our Engineering Career Framework at CircleCI](https://circleci.com/blog/why-we-re-designed-our-engineering-career-paths-at-circleci/) - [Development Framework at Blinkist](https://miro.com/app/board/uXjVORXNEjg=/) - [Career Progression at CharlyHR](https://4289024.fs1.hubspotusercontent-na1.net/hubfs/4289024/CharlieHR_Career_Progression_Framework.pdf) I find the framework from CharlyHR perfect as a starting point because, from the feedback I received, it's the one that supports managers and reports in understanding responsibilities the most. Something I always use from the CircleCI framework is the quote (at least I think I read it on the CircleCI article): > This is not a checklist but guidance. Engineers tend to be logic-driven, but personal development is a mix of business and personal needs where the person who develops should be the captain. So there's no need to make everything set in stone but clear enough to use during the journey. ## **Linking with Team Growth and Reviews** A good engineering career path should fit snugly with how you manage and grow your team. It should show up in things like performance reviews. It's about making sure the way you plan careers is in tune with how you look at your team's work and progress. Try to list competencies that you are able to track and evaluate at your stage, and cut out boilerplate skills that aren’t needed at this point. > For senior roles, focus on ensuring they can build relationships across the organization. Leverage those relationships for better planning and collaboration. ## **Change as You Grow** Just like a startup changes and grows, your career guide should too. Keep updating it as new roles appear or as the business evolves. This keeps the career path relevant and helpful, even as things shift around. Set a review cycle and try to update it while growing as an organization. People tend to work hard on it and then forget about it, but documents are meant to be adapted and, like any other wiki, need commitment. ## Summing Up: More Than Just a Plan Setting up an engineering career path in a startup is more than just drawing a plan. It's about creating a place where growth and improvement are part of the day-to-day. By ensuring your career path reflects your startup’s values, is simple yet flexible, ties in with how you manage your team, and adapts as you grow, you're building an environment where everyone moves forward together. This not only helps each individual grow but also propels the entire startup towards its larger goals. --- title: Your Team Hits Every Sprint Goal and Nothing Moves Forward url: https://alexdimango.com/blog/every-sprint-goal-nothing-moves/ date: 2023-12-12 tags: hiring, measurement --- Most teams set OKRs once a quarter and forget about them until the review meeting. By then it is too late to change anything. The problem is rarely the OKRs themselves. It is how teams track progress. Check-ins feel like paperwork. Updates happen in spreadsheets nobody opens. By the time someone notices a key result is off track, the quarter is almost over. I have seen this across organizations at every stage of OKR maturity. The pattern is the same: teams struggle to track progress in a way that is lightweight enough to stick. Here are three rules that help. ### Rule 1: Avoid Spreadsheets Using spreadsheets to track OKRs may seem like a simple and cost-effective solution, but it comes with pitfalls. **Clear progress and visuals are also the strengths of OKRs**, and while you might be tempted to start with spreadsheets, this may not be the best visualization option, potentially decreasing the overall engagement with the framework. Collaborating with spreadsheets does happen, but maintaining historical data can be tough. Quite often, you end up reusing the same cells and overwriting old data. I'd recommend trying something like Asana, [Workpath](https://www.workpath.com/), Profit, or [Tability](https://www.tability.io/).
Screenshot of Tability’s Dashboard
Screenshot of Tability’s Dashboard
### Rule 2: Reduce Manual Data Entry By directly extracting the necessary information for updating progress, the tools I discussed earlier can save you time and effort. They offer integrations with popular data sources such as Hubspot, Jira, Asana, or your databases. This means you can concentrate your weekly check-in call on topics of importance. **Minimizing manual data entry not only cuts time spent on updating OKRs but also, through integrations with Microsoft Teams or Slack**, enables you to automatically inform stakeholders when check-ins are complete, or to request additional manual input when fully automated scoring is not achievable.
Screenshot of MS Viva Slack Notifications
Screenshot of MS Viva Slack Notifications
### Rule 3: Standardise Reporting Formulate standard templates for OKR check-ins to ensure consistency and smooth the reporting process. This step reduces the effort needed to manually format and structure information. For measurable Key Results, establish a consistent method of calculating progress. For example, the below formula can be used to calculate the percentage of progression relative to the initial value of your metric for a Key Result (KR):
Image (03.png)
Furthermore, to provide a more context-based evaluation of calculated progress and the remaining time until the end of the quarter, you can assign the following confidence levels: - 🔴 **Off Track:** Shows that progress is less than expected, and action is needed. - 🟡 **At Risk:** Indicates the Key Result is at risk and might need extra monitoring and changes to get back on course. - 🟢 **On Track:** Confirms the Key Result is progressing well towards the target. For me, having a clear, intuitive understanding of the current situation of projects is key. If you prefer, you can also use a numerical confidence level, much like the example below.
Screenshot of Workpath’s Dashboard
Screenshot of Workpath’s Dashboard
### Conclusion The point is not to make OKR tracking perfect. It is to make it cheap enough that people do it. If check-ins feel like admin, your team will avoid them. If progress is visible without effort, conversations shift from “where are we” to “what do we do about it.” Pick a tool that connects to your existing data. Agree on one way to score progress. Run the check-in in 15 minutes. That is it. The goal is not better tracking. It is better decisions, faster. --- title: The First 90 Days in a New Role url: https://alexdimango.com/blog/the-first-90-days-in-a-new-role/ date: 2023-12-01 tags: hiring, career --- Today, we're exploring the topic of bringing people into new jobs or roles. [Monica](https://www.linkedin.com/in/monicagiambitto/), our expert in all things engineering, will share some learnings and frameworks she used in the past. Right now, she's the Head of Engineering at Beyond. But before that, she steered the ship at Kaia Health and Freelectis. She has onboarded many people, and without a doubt, her learnings and past experiences will be helpful stories for all of us.
Meet Monica
Meet Monica
## The First 90 Days As a manager, at some point in your career, you might have to switch to a new organization. When this happens, you won't be able to bring your network or team with you, and you'll have to start afresh. You'll be unable to leverage the political influence you may have built over the years in your previous company. To help managers increase their chances of success when joining a new organization, many people suggest reading "The First 90 Days" by Michael D. Watkins. > The book outlines the necessary steps to take on your first day of work, which can be plotted on a timeline: **Orientation -> Networking -> Multiplying.** The objective of the framework  is to create a positive feedback loop where each action quickens the build-up of influence and impact within the new organization, while also providing you with greater confidence in determining when and where to act. The ultimate goal is to shorten the time for your company to break even on the investment of hiring you.
Image (02.png)
### **What does the framework look like?** The three phases should take 30 days each and each one will have a specific theme. #### Days 1-30: Orienting In the first 30 days, your goal is to establish the foundation of your presence in the company. Before doing any action, you need to **understand the team and the culture**.  Have as many one-on-one meetings and focus on specific questions that can help you assess the situation faster, immerse yourself in team dynamics so as to gain insights into the existing culture. In this phase it’s easy to be overwhelmed by the amount of information and novelty. To act with intention in the next phases, you need to **set expectations for yourself and others**: define short and long-term goals based on the information you are gathering, to make sure you are making progress.  Just as important: communicate your expectations to your peers, manager and reports. You are new in the company and only a few people know you. It is critical to make sure people understand what you are doing, why you are doing it and how you are doing it. #### Days 31-60: Networking This is the phase where you get to know the people in a more personal way and you need to establish communication strategies to be effective in and out of your team. **Build a rapport with stakeholders** that will make you and your team effective and collaborative and start **establishing internal team communication** to be as effective as you can. This means either reinforcing or building a philosophy of communication that encourages openness, timely and relevant messages on the proper channels, clear expectations for the roles involved, and as much as possible soliciting feedback. Just as important: get to know the people that will report to you, to assess who makes up your squad, what are **their strengths and weaknesses and their aspirations.**  This will help you understand what your team can and cannot do and how you can help the people you lead to grow. #### Days 61-90: Multiplying If you have done your homework, at this point you have a fairly good idea of what your objectives are and the problems you’ve been brought in to solve. Make sure to **create an environment where there is space for creativity** so that your team and you, together with your peers, can come up with how to solve them. Implement **multiple feedback mechanisms** to get as soon as possible information as to if you are going in the right direction. Make sure to also **establish a way to resolve conflicts**. There will be some, and a conflict (overt or open) will become more and more dangerous as it goes on. Nip it in the bud. If possible, observe the patterns and create a conflict resolution framework to make the next issue go away faster. For a deeper summary of the framework, you can read the following articles: - [https://www.runn.io/blog/the-first-90-days-summary](https://www.runn.io/blog/the-first-90-days-summary)  - [https://uponleaders.co.uk/wp-content/uploads/2021/05/The-First-90-Days-Michael-Watkins-3.pdf](https://uponleaders.co.uk/wp-content/uploads/2021/05/The-First-90-Days-Michael-Watkins-3.pdf)  - [https://sourcesofinsight.com/book-review-the-first-90-days/](https://sourcesofinsight.com/book-review-the-first-90-days/)  The framework is rich in practical advice, tools and mental models that you should use to make sure what you are observing is factual.  ### **If you were to pick the most memorable concept of the book, what would that be?** When I became a manager in my first company, I had prepared a plan but needed a few weeks to complete it while tapping into the company's knowledge. Unfortunately, reality did not cooperate, and I had to put my plan aside to handle the company's business and take care of my team's well-being. Nevertheless, I found that the following mental models and practices that I had extracted from the framework helped me lead my team well, and my transition was as smooth as it could be.  I have to say two concepts were the most valuable to me and I cannot pick one over the other. **Build a stakeholders map:** Who are the people who will have an influence on your team, your project, your role? Who are your peers? What do they influence? Who are your customers? **The STARS model:** a way to categorize in which phase your company, your division and your team  are. Your strategy for each of those entities will have to adapt to where they are in the life cycle described. If you apply a Turnaround strategy to a Start-up phase, you might succeed but at a much higher cost. Each of these phases comes with its set of challenges and opportunities, things you need to correct and things you need to leverage.  In my case it was extremely useful to understand how to manage the team I was leading and navigating the division my team was in. I had a team that needed to be built up from scratch, set against impossible deadlines with high stakes and a high level of uncertainty. That was the exact picture of an organization in the Startup phase. The division we were operating was in a similar phase, maybe a bit in the Turnaround phase because of the deadlines being set and practices for project management not well established. The company saw itself in a Sustaining Success phase, whilst in my opinion it was instead in a Realignment phase: we had a successful business model in the U.S. but we wanted to go heavy on the EU market and for doing that we had to reassess the priorities, the structure of the whole company and even the communication patterns so to have the EU market team would the resources, the help and understanding it needed to start operating properly
Image (03.png)
### **In which other situations is the framework useful?** It's worth noting that you don't need to be a people manager to use the framework. While there are a few sections dedicated to managing your team, it is still extremely useful in any case. For instance, if you are a product manager or a marketing manager, there is still a team of people you will be working closely with, and they will work for you even if they don't report to you. You don’t need to follow the framework to the exact word. As always, in my opinion, it is important to understand the underlying message and lessons and to apply the Pareto principle: you’ll make a great deal of progress with 20% of the effort. If you don’t, revisit your assumptions because something is bringing in friction. If I were to extract a few principles from it, they would be:: 1. Prepare yourself: take the time to learn about the company's history, objectives, and your motives for joining it. This will help you understand how you can contribute to the company's goals. 2. Establish a plan with your manager: if they take the lead, that's great. But if not, take the initiative and communicate your plan based on what you learned during your preparation. 3. Don't rush into proving yourself: without enough knowledge, you may end up making mistakes that could set you back for months. Take your time to learn and understand how things work before taking any action. 4. Keep your eyes open for easy wins: just because you're not rushing doesn't mean you should be inactive. Look for opportunities with a good tradeoff between risk and improvement. 5. Don't rely solely on what you know: remember that you're in a different environment now. Be open to learning and adapting to the new environment and its challenges. ### **Conclusion** Of course, there are some disadvantages to this approach. It can result in an excessive focus on short-term goals, and it assumes that the company is stable enough not to disrupt your plan while you are carefully implementing it. It is dependent on a particular organizational culture, one where innovation, disruption, clear communication and feedback is appreciated. However, I still believe that this framework is valuable because it helps you to prepare for the challenges that you will for sure face. You might not be able to apply all of the lessons, but you for sure will at least walk into situations with open eyes.  * * * Just to highlight a little more about what the framework suggests regarding taking over a new team in connection to what [Monica](https://www.linkedin.com/in/monicagiambitto/) shared. I personally believe It's crucial to respect the work of those who came before us and understand the reasons behind their decisions, forming a solid foundation. When entering new companies, there's often “curiosity” about why things were done a certain way (why??): > Was it due to time constraints, budget limitations, or a different vision? Try looking for decision-making documents if available or ask this question during your 1-1. **Asking why is key; do not assume.** And do not expect people to tell you where to start: assess, prioritize, make your plan visible and take the risk. Get ready for your first mistakes — that’s fine. --- title: Improving Team Collaboration with Strengths Mapping url: https://alexdimango.com/blog/improving-team-collaboration-with/ date: 2023-11-21 tags: hiring --- Do you know how your coworkers like to receive feedback? Do you know their preferred communication channel (a quick call or Slack message), or if they prefer to be rewarded with a personal message or publicly? Of course, there are company processes to follow, but understanding their preferences better could help in finding the best way to create an inclusive environment and offer opportunities for them to share their thoughts without feeling pressured. There are a lot of simple questions you can use to understand more about your team members and there are also several tools you can use to discover and explore your team's strengths. Have you ever tried the CliftonStrengths assessment? It's like a map of what you're good at “your strengths”. The results show your best strengths (your top 5) from a list of 34 cool themes and it gives a description for each strength so you can check if it matches how you see yourself like the example below: - **Individualization:** You are intrigued with the unique qualities of each person. You have a gift for figuring out how different people can work together productively
Image Copyright: Gallup, Inc. All rights reserved.
Image Copyright: Gallup, Inc. All rights reserved.
But what I find interesting is your team map (image below). The first time I did it, while waiting to discuss the results with our workshop facilitator I was concerned about all the white space and gaps my team was missing. This was because we generally have a natural inclination to focus on what we see as "missing." However, the workshop facilitator finally arrived and clarified how CliftonStrengths works and that we should concentrate on the themes that the team does have, asking our team members how they can better use their talents to create the outcomes we need in our organization. In fact, the philosophy behind CliftonStrengths lies in the belief **that individuals thrive when they concentrate on what they do best.**
Image Copyright: Gallup, Inc. All rights reserved.
Image Copyright: Gallup, Inc. All rights reserved.
### Little Team Strengths Exercise So, how can you use a strengths map ([Online Assessment](https://www.gallup.com/cliftonstrengths/en/home.aspx)) to get to know each other better and improve collaboration? Here, try this exercise with your team: 1. **Find Your Strengths**: Everyone in the team figures out what they're good at using the Strengths Team Grid. 2. **Team Pairs**: People get paired up, making sure each pair has different strengths. 3. **Share About Strengths**: In pairs, team members talk about their best strengths and how they think these strengths help the team goals. 4. **Discover Complementary Strengths**: Pairs figure out where their strengths work well together. They chat about how this teamwork can be good for the team. 5. **Team Challenge**: Give the pairs a team goal. They think about how they can use their strengths together to solve the goal. 6. **Group Talk:** Everyone comes together to talk about their ideas. Each pair tells the team how they plan to work together using their strengths. 7. **Think About It:** Finish the activity with a talk where everyone thinks about what they learned. Each person says one thing they discovered about their partner's strengths and how they want to work together better. This will help your team learn about each other's strengths and how to work together using those strengths for real team success. --- title: Coaching: is now the perfect moment to take that first step? url: https://alexdimango.com/blog/coaching-is-now-the-perfect-moment/ date: 2023-11-10 tags: hiring, leadership, career --- Today, we will be talking about coaching and the remarkable impact it has on your career. There’s nobody better suited for the job than [Stephan](https://www.amazingcto.com/). With over 25 years of experience as a technical manager and executive, he’s been at the forefront of the tech industry. He’s here to tell us how coaching can be a game changer. So let's jump into it and discover how you can change your career too.
Meet Stephan
Meet Stephan
## **The Importance of Career Coaching for Startup Managers** Coaching is the super-weapon of a startup. Unless a startup begins with experienced founders and executives, there is an experience gap between what the company needs and the experience level of the managers. ### What does coaching look like? From my experience coaching CEOs and CTOs, we have an hourly session every second week. Topics range from prioritizing work, delegating work, setting up performance systems, growing organizations with middle management or holding employees accountable. Besides the coaching session, I review pitch decks, culture documents, org charts, job ads and strategies. In a crisis, e.g. the fcc company gets hacked or a key employee leaves, I'm always just a telephone call away. Coaching speeds up personal growth of all managers and reduces execution risks. Having coaching while you competitors have not gives you the edge for successful growth. A coach derisks company growth while at the same time speeds up growth. A coach can help experienced and inexperienced managers to grow faster and fulfill their role at every stage. While coaching can be done by people managers, there is always stuff people will only open up to people who have no influence over their work relationship — e.g., can't fire them. ### Why would a manager choose a coach? There are plenty of reasons. In general a coach speeds up your development and makes your life as a manager much easier. One can discuss things with their manager, their peers or their direct reports. But there is always stuff left that a manager feels they can't discuss with anyone. Here comes the coach. As someone outside the work relationships, they can listen to everything and give opinions, advice and help. Coaches also give an external opinion. While internal knowledge and capabilities are great, there is always the risk of being blind to facts or fall into groupthink. A coach with a wide range of experience can bring external view points and judgments on decisions. You can bounce ideas with your coach before you execute them, before you get your management team on board. The coach helps you prioritize ideas and execute those with the biggest impact from their experience. - A coach is someone who can push you to new capabilities and move you out of your comfort zone. The job is demanding and day-to-day operations keep the managers from thinking about their career and growth. It's easier to just pull through. - A coach keeps you on track thinking about your career and growth and pushes you out of your comfort zone.  - A coach gives you relevant knowledge faster than you could acquire it by learning and experience. A manger's job has tough decisions and pressure. A coach is someone to call and who just listens. A coach can be a pillar of support in the stormy sea of startup life. Coaches and mentors are the secret weapon to startup success. * * * I hope Stephan has given you a better understanding of the importance of coaching and how it can provide support in different challenging situations. > Now, you might be wondering how to find the right coaches? #### 1\. Clarify Objectives: Take a moment and figure out your goals and needs before starting this journey. What do you want to achieve with coaching? Is it personal growth, advancing in your career, or developing specific skills? You need to understand why first before you find someone who can help. Doing this will also help you identify what type of coach and expertise you need. #### 2\. Research Potential Coaches Once you know what you’re aiming for, then it’s time to get messy. Start doing research on potential coaches that meet your needs. Look for ones that have a track record of success and experience within your area of interest. Check reviews and case studies, see if they’re effective or not. In addition, consider their method style and how they approach things. This should be aligned with how you learn best and your personality. #### 3\. Interviews Finally, once everything is checked off start conducting interviews with the coaches on your radar. The conversations should center around their coaching process, prior achievements, and how they plan to push you towards your goals. Also keep an eye out for chemistry between you and the coach. It’s important that you can build a strong bond and feel comfortable with the person in charge of molding you into a better version of yourself. Choose a coach who will allow for open communication and trust. Finding your coach may not be easy but I hope this article helps you decide if now is the right moment. Growing personally and professionally isn't a walk in the park, but you can make it easier by setting clear goals, doing your research and finding a coach you connect with. --- title: The Nine-Box Grid for Talent Management url: https://alexdimango.com/blog/the-nine-box-grid-for-talent-management/ date: 2023-11-02 tags: hiring, leadership, career --- When you're in charge of a team, sooner or later, you'll find yourself in the position of evaluating your team members, discussing promotions, and creating development plans. This typically happens every 6 to 12 months, and depending on your organization, you can choose from a variety of tools for these evaluations, including leader reviews, self-reflection, and peer reviews. Let's break down the differences between these methods: - **Leader Review:** Your team leader or supervisor checks your work and provides feedback. - **Self-Assessment (Self-Reflection):** You take a moment to reflect on your own work, your strengths, and areas where you could improve. - **Peer Review:** Your colleagues share their thoughts on how you work with them — it's like getting feedback from your work buddies. In this article, I'd like to shift our focus to leader reviews and introduce you to the Performance and Potential Matrix: the Nine-Box Grid. It's a great tool for evaluating and categorizing team members based on their job performance and potential for growth within your company. > What I love about this framework is its simplicity and ease of use. After a quick initial introduction, leaders can catch on. Filling in the grid also adds structure to discussions about promotions and salary increases. When I first used it, **I wished for a simple "how to use" guide or some tips**. So, I decided to jot down my recommendations here and provide a user-friendly [Miro board](https://miro.com/miroverse/profile/alexdimango/) with a customizable template. Here's what you'll find: 1. Pre-Matrix Preparation 2. Facilitate The First Round 3. Development Strategies
Image (01.jpeg)
### Pre-Matrix Preparation Just like any framework, it's crucial to clarify how to apply it in your organization. You need to explain how to assess both potential and performance. Evaluating someone's potential can be a bit of a puzzle. To help you out, consider these guiding questions: - Can they handle a more challenging role if promoted right now? - Do you think they can learn new skills for a higher role? - Have you seen them demonstrate leadership qualities? - Are they flexible when working on new projects? - Do they actively seek opportunities to learn new things? For performance evaluation, you could use your role expectation matrix. You can find a helpful open-source example from [CircleCI](https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0). Afterward, write a description for each of the boxes, you can use the one below as inspiration: #### High Potential/High Performance (STAR) These team members excel in a variety of tasks, demonstrating a strategic mindset, effective problem-solving skills, and high self-motivation, leading to positive outcomes. _Recommended Action: GROWTH Assign them new projects and responsibilities that challenge their strengths, and consider promoting them._ #### High Potential/Moderate Performance (RISING STAR) These team members not only excel in their current roles but also drive positive outcomes. Their motivation and dedication are key drivers for achieving even greater results, making them integral to our team's success. _Recommended Action: GROWTH Think about assigning more challenging projects, similar to STAR, to help them develop their strengths further. Also, consider a role that can help them grow. Provide regular feedback to enhance their performance._ #### High Potential/Low Performance (POTENTIAL STAR) These team members have the capability to take on new responsibilities but may face some challenges. They show a strong willingness to adapt and have key strengths. _Recommended Action: DEVELOPMENT Invest in coaching and training. Evaluate the potential for a Performance Improvement Plan (PIP)_ #### Moderate Potential/High Performance (KEY CONTRIBUTORS) These team members are valuable assets to the team, but there might be more potential to explore. _Recommended Action: DEVELOPMENT Consider implementing a long-term growth plan._ #### Moderate Potential/Moderate Performance (CORE MEMBER) These team members are doing well in their current role and have the potential for improvement over time. _Recommended Action: SUPPORT Think about giving them more responsibilities without making it stressful (no pressure). Use a Performance Improvement Plan (PIP) and offer coaching and guidance_ #### Moderate Potential/Low Performance (UNDERPERFORMER) These team members have the strengths to help improve their performance in their current roles. _Recommended Action: SUPPORT Invest in coaching and training. Focus on Performance Improvement Plan (PIP)._ #### Low Potential/High Performance (TRUSTED MEMBER) These team members are great role models as top performers who have used their strengths to the maximum. _Recommended Action: SUPPORT MOTIVATION Motivate them to stay engaged. Enhance communication with them and make sure they get fairly rewarded for their good work._ #### Low Potential/Moderate Performance (AVERAGE PERFORMER) These team members perform well and make contributions. They also appear happy with their current roles and what they do. _Recommended Action: ASSESS AND SUPPORT Consider a Performance Improvement Plan (PIP). Provide regular coaching and feedback._ #### Low Potential/Low Performance (RISKY MEMBER) These team members lack crucial skills and may be unresponsive to coaching. _Recommended Action: FOCUS ON PERFORMANCE Consider implementing a Performance Improvement Plan (PIP), with a focus on addressing low performance while ensuring it doesn't impact team morale_ ### Facilitate The First Round Before diving into the grid, it's important to have your leaders prepare to assess their team members. You might want to collect additional information, such as their time in their current role or when they last received a salary increase. I usually have each leader assess their immediate subordinates one by one, ensuring fair comparisons. Then, I compile all the names, organized by level, on a chart. Start with someone positioned at the top right corner, where they excel in performance and show high potential. Ask the team leader to explain their choice. Keep digging with _"why"_ questions and encourage others to share their thoughts. This initial evaluation can serve as a benchmark for the subsequent assessments. ### Development Strategies After those discussions, let's now jump into the development strategies for each category within the matrix: #### **“A” Category (High Potential):** - Strategies focus on further development and advancement. - Emphasis on challenging assignments, mentorship, and leadership exposure. - Encouragement for high potentials to take on new roles and responsibilities. - Efforts to retain and foster their potential for future leadership positions. #### **“B” Category (Good/**Moderate **Performance):** - Strategies cater to individuals with good or average performance. - Efforts directed toward development but may not necessarily involve immediate advancement. - Focus on assessing readiness for advancement, providing stretch opportunities, and acknowledging value. - Goal is to enhance performance from good to great or move from average to high potential. #### **“C” Category (Low Performance):** - Strategies are primarily centered on addressing performance issues. - Focus on diagnosing and improving performance problems. - May involve role transitions, support, and additional resources. - Potential for reassignment or dismissal if performance issues persist after reasonable attempts at improvement. Category A strategies aim to support high-potential individuals in their pursuit of leadership roles. Category B strategies focus on enhancing the performance of good to moderate performers. Category C strategies are designed to address and improve low performance.[1](#footnote-1) * * * > In conclusion, leveraging the Nine-Box Grid and these development strategies can empower organizations to fine-tune leadership development and adopt a more organized approach to evaluating and supporting team members' growth. [1](#footnote-anchor-1) _The strategies mentioned above draw inspiration from concepts by [Daniel McCarthy](https://greatleadershipbydan.com/), Dan is the owner of Great Leadership, specializing in leadership coaching, succession planning, and development consulting. He's a former leader at Paychex, Inc., and Eastman Kodak Company, known for his award-winning blog "Great Leadership."_ --- title: What “doing a good job” means as a Leader url: https://alexdimango.com/blog/getting-things-done-right/ date: 2023-10-20 tags: ai-adoption, hiring, measurement --- Every week, my team gets all our work done and introduces something new. Does this mean we're doing a good job? Have you ever thought about what “doing a good job” means as a leader? The truth is, whether a team is doing well or not depends on how you, as a leader, define what “doing well” is. Let's be clear about two important words: _efficiency_ and _effectiveness_. We often talk about them, and they have to do with getting things done, but they mean slightly different things. Efficiency is about doing things fast. Effectiveness is about doing the right things and getting the best outcome, not just doing things fast. So, what makes an effective engineering team? First, it's essential to realize that there isn't a single, one-size-fits-all definition for team effectiveness. Teams are unique, so it's crucial to pay attention to the signs that work best for your team. You can come across various models that can help you figure out how your team operates and how well it's doing. Today, I'd like to introduce one of these models - the [Lencioni](https://www.amazon.de/-/en/Five-dysfu-Nctions-Fable-team/dp/0787960756/ref=sr_1_1?crid=2OUC876UY4EFV&keywords=lencioni+5+dysfunktionen&qid=1697655562&sprefix=lencioni%252Caps%252C114&sr=8-1&_encoding=UTF8&tag=nojustbits-21&linkCode=ur2&linkId=d10fe770eb68fb34b64ed5ca3b17cc93&camp=1638&creative=6742) model, also known as the “Five Dysfunctions of a Team". This model helps teams tackle common problems that can make them less effective. It's like fixing parts of a car to make it run smoothly. The model lists five main issues/dysfunctions, and dealing with each one can make a team work better.
Generated with AI
Generated with AI
Here are these problems and how to solve them: 1. **Absence of Trust**: This is when team members don't believe in each other. They may hesitate to share their innovative ideas or admit mistakes because they lack trust in their coworkers. _**Example**: Consider a team developing a new app. Without trust, team members may hesitate to share their creative ideas. To tackle this issue, team-building exercises, discussions about individual strengths and weaknesses (e.g., using CliftonStrengths Team Activities), and sharing personal experiences can help build trust._ 2. **Fear of Conflict**: When there's trust in a team, people can have healthy arguments. It's like when friends can argue without being mad at each other. But when they're afraid of arguing, they don't talk about their differences, and that's not good for making decisions. _**Example**: Consider a team where team members are afraid to debate the best marketing strategy for their product launch because they're worried about offending their colleagues. To improve this situation, leaders can encourage open discussions, establish rules for healthy debates and feedbacks, and emphasize the value of diverse perspectives in making important decisions._ 3. **Lack of Commitment**: Team members may not fully commit to decisions and plans because they didn't have the opportunity to express their opinions and concerns during the decision-making process. _**Example**: In a tech company, team members might have trouble agreeing on the development timeline for a new product, causing delays. To address this challenge, teams should ensure that everyone has a chance to voice their opinions and express concerns. Make decisions through a clear, well-defined process and communicate them well._ 4. **Avoidance of Accountability**: If team members can't commit to decisions, it becomes challenging to hold them accountable for their responsibilities. This can result in missed goals and a lack of ownership. _**Example**: A team working on a new software project, if one team member keeps falling short of their tasks, it can negatively impact the entire project. To address this issue, leaders should establish clear expectations, monitor progress, and ensure team members own their roles._ 5. **Inattention to Results**: the main goal is achieving success. If team members prioritize their individual interests over the startup's success, it can hinder the overall progress. _Example: Imagine a team developing a new e-commerce platform. If one team member focuses solely on their part of the project and not the project's overall success, it might lead to problems. To address this, leaders should align team goals with the organization's objectives and create a culture where the team celebrates collective achievements._ While models like these may sometimes appear theoretical and not entirely reflective of real-life challenges, they offer valuable inspiration and a framework for improving team dynamics. To make the Lencioni Model work well, I suggest that teams should focus on solving each problem separately. These issues are related, and fixing one can help with the others. Regular communication, team-building activities, and creating a culture of trust, responsibility, and shared success are important for making the team better when using this model. * * * Now that we have a good starting point for improving team dynamics, I'd like to share something that can further enhance leaders' personal development. Many of the most effective leaders follow specific practices in their way of working (effectiveness can be learned), and I'd like to share some of these from a book I highly recommend to everyone: > 5 Habits for Becoming an Effective Executive. The book is called [The Effective Executive](https://www.amazon.de/-/en/dp/0062574345?psc=1&ref=ppx_yo2ov_dt_b_product_details&_encoding=UTF8&tag=nojustbits-21&linkCode=ur2&linkId=e21633455e1093a29ed95b36bdce6747&camp=1638&creative=6742) by Peter Drucker, may not be a recent publication, but my first coach recommended it to me, and it helped me focus on what matters most.
Image (02.png)
Drucker identifies 5 essential practices to be effective in business: 1. **Managing Time** 1. _Record_: see where your time is spent. 2. _Manage_: reduce things that waste your time. For example, with the many meetings on your schedule, could someone else handle some of them for you? 3. _Consolidate_ combine your free time into longer blocks. Why not work from home for a day each week and schedule dedicated focus time on your calendar? 2. **Choosing what to contribute to the organization** 1. _Communication_: Effective leaders ask their team members what they should be responsible for and expect from them. This makes communication easier because the team member knows what's expected of them. 2. _Teamwork_: Focusing on what each person contributes helps people work together well. They work together because it makes sense for the task, not just because they're told to. 3. _Self-development:_ Where can I contribute the most, and what skills, standards should I set for myself, and which strengths should I use? 4. _Development of others_: Leaders who focus on contributions inspire others to grow. They set high standards, encourage ambitious goals, and expect great work. 3. **Knowing where and how to mobilize strength for the best effect** 1. As a leader you need to focus on your strengths and the strengths of your team. Don't dwell on weaknesses. When building your team, choose people who are great at what they do. Don't hire well-rounded people just for the sake of it. Always look for what they can do exceptionally well. Overall, it's strengths that matter most in making your organization thrive. 2. Focus on areas where top performance leads to valuable outcomes. 3. Learn to understand what your manager needs. Most people are either readers or listeners. Talking to a reader is usually not helpful; they only pay attention after they've read. Similarly, giving a lengthy report to a listener isn't effective; they understand better when you speak. Some individuals prefer concise reports, while others want all the details. Figure out which type of person your manager is. 4. **Setting the right priorities** 1. Ask yourself, "If we weren't already doing this, would we decide to start it today?". You should always question if it's still a good idea to keep doing something. If it's not, it's time to stop so you can focus on the few things that make a big difference in your work or your organization's success. And, before you take on something new, make sure you get rid of something old. 5. **Knitting all of them together with effective decision-making** 1. Effective leaders make crucial decisions, focusing on a deep understanding and the bigger picture. When deciding, they follow these five elements: 1. Recognize common situations from exceptions. 2. Set clear decision goals. 3. Prioritize what's right over what's just okay. 4. Put the decision into action. 5. Incorporate feedback in the process. In the domain of making effective choices, decisions are about options, not just right versus wrong. Start with opinions, not just facts, and value diverse viewpoints. Determine what to measure, seek input before deciding, and don't hesitate to explore different perspectives (disagreement stimulates the imagination). * * * Models and books give you a starting point. But effectiveness is not something you read about once and understand. It shows up in the small things. How you spend your Tuesday morning. Whether your team can disagree without it becoming personal. Whether people know what they own and why it matters. If your team is busy but not moving forward, the problem is rarely effort. It is usually clarity. Clarity about what good looks like, who decides what, and where your time goes. Start there.