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 actually 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

I built an open-source framework for this. The 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.

Then during your first VC pitch they ask how you track your sales pipeline. Your tech co-founder wants to know if customers are actually 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.

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.

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 actually 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 Optimisers.

• Optimisers 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 done quickly, 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.

On compensation, this is not the place to optimise 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 clearly.

• 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 truly 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

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 quickly the surface is shifting.

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 actually 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 most clearly 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.

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

• People learn how hard prioritisation 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.

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

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 quickly can humans act on them?

• Learning loops → are people and models improving together?

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.

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 actually 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 actually need to know:

Are people still getting what they came for?

If not, nothing else matters.

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.

Subscribe now

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

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/

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.

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 rapidly 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 or Hotjar can support A/B testing and user behavior analysis, helping teams test ideas quickly and refine based on results.

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 quickly. Use AI where it helps. That’s how teams move forward with clarity and confidence.

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 – 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 (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 really 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, 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 actively involved when problems are being discussed. Some ways to get involved:

1. Attend customer interviews to hear pain points firsthand. Tools like Chattermill 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 actively involved in discovery don’t just build features—they shape better products. By prioritizing Tech Wealth, rapid prototyping (leveraging 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.

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

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.

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 realise value quickly.

• 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. Clearly 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 prioritise effectively to avoid distractions and achieve meaningful progress.

A good place to start? Use the Eisenhower Matrix. This framework helps you categorise tasks and initiatives based on urgency and importance, making it easier to prioritise, 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.

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​

Setting target dates lets teams prioritise 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.

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

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, licences, 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 quickly 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 quickly?

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.

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

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 recognise that while custom software development may seem attractive, it can quickly consume 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 favour 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.

See It in Action

Watch the Loom demo to see how this app was built using prompts and AI. It’s a new way of getting things done faster.

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

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 quickly extend functionality. 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 effectively.

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

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 Effectively

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

When to Use the RFC Process

An RFC should be written when planning to make substantial changes that impact the entire organisation. 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 quickly 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 prioritised 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 quickly, 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 prioritise 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 organisation's needs, you can foster a more collaborative, transparent, and efficient decision-making environment, ultimately driving better outcomes for your tech team.

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 significantly reduces bandwidth consumption. This is directly tied to cost savings and environmental sustainability

Netflix invested over $1 billion in developing Open Connect, their own content delivery network, which they offer for free to ISPs.

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.

At its core, continuous delivery is about ensuring that all types of changes, including new features, bug fixes, and infrastructure updates, can be safely and quickly introduced into production. 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 rapidly (as we have clearly 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.

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 significantly 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 a very large 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

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 fundamentally altered 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.

In the past, I found using a simple matrix to prioritize todos based on impact/effort and risk very useful, 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 really 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.

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

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

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

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

• Why We Redesigned Our Engineering Career Framework at CircleCI

• Development Framework at Blinkist

• Career Progression at CharlyHR

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.

Paul's journey is one many of us can relate to. After 30 years in the tech startup scene, grappling with stress, sleepless nights, and health setbacks, he made a life-changing pivot. Embracing the disciplines of sleep, nutrition, and stress management, Paul transformed his health, proving it's never too late for a turnaround.

Now, through sonno.ai, Paul extends his expertise to startup founders seeking success without the burnout. He focuses on practical, impactful areas like stress management and quality sleep, leading to improved decision-making, energy levels, and overall well-being.

The Critical Connection Between Sleep and Leadership

Understanding the vital role of sleep is crucial, not just for our personal lives but also for our professional effectiveness, particularly in leadership roles. Sleep is more than just downtime—it can significantly influence our mental health and capacity to lead effectively.

Consider sleep as a nightly reset for your brain, a critical time when your mind undertakes the essential task of processing the day’s experiences, consolidating memories, and rejuvenating. It’s during these quiet hours that our brain engages in intricate processes crucial for mental health. Neglecting sleep doesn’t just leave us feeling tired; it diminishes our ability to handle stress, clouds our decision-making abilities, and impacts our emotional equilibrium.

The Workday Benefits of a Restful Night

The benefits of a good night’s sleep extend far into our workday. With adequate rest, our cognitive functions—like memory, attention, and creativity—are at their peak. This heightened state of mental clarity transforms our work experience, making tasks feel more manageable and decision-making more effortless. However, the absence of quality sleep often translates into a day filled with mental fog, where every decision feels like an uphill battle, and staying focused becomes a constant struggle.

Leadership and the Sleep Factor

For leaders, the importance of sleep is magnified. Well-rested leaders resemble skilful captains effortlessly navigating their ships. They exude calmness, inspire confidence, and display an ability to make thoughtful, well-considered decisions. In contrast, a leader deprived of sleep is often less effective, more likely to react impulsively, and less capable of inspiring their team. Sleep deeply influences our emotional intelligence – an essential trait for effective leadership. It affects our ability to empathize, maintain patience, and stay composed under pressure. Leaders who prioritize sleep often find themselves better equipped to understand and manage not just their emotions but also those of their team members, fostering a more positive and productive work environment.

Challenging the ‘Always-On’ Work Culture

Today’s fast-paced, ‘always-on’ work culture often undermines the importance of rest. The pressure to stay connected and the glorification of ‘busyness’ can make it challenging to prioritize sleep. Yet, it’s essential for leaders to model healthy sleep habits, demonstrating to their teams that rest is not just accepted, but encouraged.

Practical Tips for Enhancing Sleep Quality

Improving sleep quality often requires simple, practical changes. Creating a regular sleep schedule, ensuring a sleep-friendly environment, and establishing a pre-sleep routine can significantly enhance sleep quality. Avoiding caffeine late in the day, limiting exposure to screens before bedtime, and engaging in relaxing activities like reading or meditation can also be beneficial.

The Organizational Impact of a Leader’s Sleep

The ripple effects of a leader’s sleep habits extend beyond individual performance, influencing the overall health of the organization. A well-rested leader sets a positive example, promoting a culture where balance and well-being are valued. This approach not only enhances productivity but also contributes to a more engaged and satisfied workforce.

Conclusion: Embracing Sleep as a Leadership Tool

Sleep is a critical yet often overlooked component of mental well-being, work performance, and effective leadership. By recognizing and prioritizing the need for quality rest, we empower ourselves to be better professionals and leaders. Embracing better sleep habits is an investment in our health, our careers, and our ability to lead and inspire those around us.