This year we built a workflow around our coding agent: a set of commands and agents that scope a ticket, plan the delivery and hand the work back for review. In the first few weeks of introducing it, one of our senior developers was handed a well-formed plan through it. We expected to see something within a few days. After more than a week we were still at the “it’s coming together” stage, and we were starting to ask why.

So I had a catch-up with them, and it was clear that while they were following the plan, they were still doing everything manually. They were very open about it. They were struggling with the idea of forming the plan and delegating to agents, so they had reverted to writing the code by hand.

This wasn’t a discipline problem. The developer had a plan written to be delegated, and they executed it the way a good individual contributor executes a plan: themselves, by hand. What they needed was someone to sit with them, so we did some pair teaching on how to use the workflow, and restarted the ticket from the beginning.

That catch-up is what resistance to agents has looked like on my team. Nobody refused, and nobody argued about job security. Seniors wanted to feel in control of the process, so they quietly ignored the workflow and the tools and carried on working the way they always had. When one of them said it out loud, it sounded like “I don’t see why we need to change our process, I’ve been doing it this way for years and it’s worked fine.”

People who have managed humans find this natural

The gap I saw in that catch-up is one I recognised, because I had to learn the same thing about 15 years ago.

My first delegation began when I started to hire developers at CookiesHQ, the agency I co-founded. It was a learning experience, delegating things to other people. Most delegation fails, in my opinion, because of a lack of understanding. The person delegating assumes the person receiving the plan will make certain decisions, so those decisions are never surfaced: use this code pattern, achieve X this way. When the person receives the task and implements it, they don’t have that context, so they make their own decisions. Most of the time, that creates divergence between what was asked for and what was produced.

With a human colleague, at least some of those missing decisions get asked about. Someone walks over and says “did you mean this or that?” With an agent, they get made silently, and you find out at review, if you find out at all.

Learning to surface those decisions before you hand over is the skill, and it’s why the distinction worth drawing has little to do with seniority. A senior individual contributor has led code, sometimes for decades, but has never led people. Someone who has handed work to another human and lived with the result is a different animal, whatever their title. The seniors on my team who quietly resisted were the first kind. The CTOs I see taking to coding agents without much fuss are mostly the second.

What the second group has learned is to formalise a plan and hand it over to other team members to execute. They have learned to trust their team to make decisions and take ownership of the work. And most importantly, they have learned to smell the right touch points, and to know when to step in and when to step back.

They don’t delegate by saying “AI, do this for me.” Delegation has two halves: a plan someone else can run, and checking what comes back at the right moments. A developer who has never handed work to a person has practised neither.

Why developers don’t have it

Developers were trained to do. They were trained to write code, implement features and fix bugs, and they were proud of their ability to produce something tangible. Until a certain level, nobody trained them to delegate.

They were formalising a plan before, but only to be consumed by themselves. Most likely it was a rough outline of the steps to follow, in their head or in a few bullet points, not something detailed enough to hand to someone else.

I can see that pattern in how we worked before the workflow. We knew what we wanted to build, but we didn’t have a granular plan in place. The developers would start building, and as they went along they would hit new challenges that caused the plan to change. That led to confusion and delays, because the team was constantly adjusting its approach and reworking parts of the codebase. It cost us time.

For a lot of developers, building is the fun part, and delegating isn’t. It comes out of a desire to create, and handing that over to someone else works against it. Delegation is learned through experience, often too late in a career, and the best way to learn it is to be forced to.

Same tool, opposite experience

On 20 September a developer posting as v0xium wrote a thread on X that had about 7 million views by the time I read it two days later. He was half a month into a new role at a big company. “The specs, code, tests, PRDs, tickets, resolution of those tickets, reports”, all of it was being made by Claude Code. “Everyone, literally everyone, from an L1 to an L7 engineer here is doing the same thing.” “People are working 12 to 13 hours a day just to press enter.” The line most people quoted was “In reality, nobody is thinking anymore.”

I can’t say anything about his experience, really. I don’t work there. His own diagnosis pointed at management measuring the team on sprint velocity, PR count and features shipped, without giving engineers time to review the generated code or understand the architecture underneath it.

This is everything I’m trying my hardest to not introduce in my team. It’s a management decision. The difference I can speak to is what I asked for: a plan before the agents start, and time to check what comes back.

The CTOs I mentioned earlier have the delegation habit and can’t see that it is a habit. So they encourage everyone to jump on the AI bandwagon and then struggle to understand why their teams aren’t as productive as they expected. Their developers were on the receiving end of instructions for their whole career, and were never asked to delegate.

Button-pushers are made, not hired.

If your team is pressing enter 13 hours a day, you handed them a subordinate and never taught them to manage one.

On my own team the pressure runs the other way. My role as a CTO is to look forward, and my bet (and I accept I can be wrong) is that writing code by hand is a skill that will be less and less valuable, so I want the workflow used. But the last thing I want is a team of button-pushers, mindlessly approving what the AI suggests without being able to explain it. It’s a fine line between the two.

What we do instead

The way we walk it is to build the delegation into the steps, so a developer can’t skip it even when they would rather build.

It starts with a scope. A team lead or I will write a ticket scope: what this ticket introduces, for whom, the problem we want to solve and how we envisage solving it, followed by a series of user acceptance criteria. That’s what the developer receives, and we introduce it in a catch-up meeting to make sure of three things: that the problem understanding is clear, that the outcome understanding is clear, and that we are aligned on the plan forward. That meeting is where the decisions I would otherwise assume get surfaced, which is the failure I described at CookiesHQ.

Then the developer runs a command we call /dev-plan on the issue. It requires the developer to explain how they would approach the task, in which order, the gotchas, the things not to miss, and which patterns or libraries they might decide to use. Its job is to encode the developer’s thinking before anything is passed to the agents that build. This is the plan written for someone else, the thing an individual contributor never had to produce.

The build then happens in phases. When the agents finish one phase of the plan, they stop and ask the developer to review the code, and they won’t progress without approval. This is where the developer steers the shape of the feature, phase by phase. It’s also the checking half of delegation, the touch points, built in as a stop rather than left to whoever has the time. In the final part, one agent runs a visual QA of the implementation and asks the developer to check it as well.

We use the tools, but we don’t delegate the decision-making to them. The workflow is designed to force some thinking time and input from the person on the ticket. I wrote about the result in the last post: 50-odd tickets built through it with a low rejection rate, and the seniors who resisted at first saying they are doing a better job with it.

The fair pushback on all of this is that plenty of developers can plan fine, and the button-pusher is made when nobody budgets time to check what came back. That was v0xium’s point too. I agree, which is why I said delegation has two halves. The phase stops are our version of the checking half, and the right side of the workflow, QA and release, is what we are building now.

The second pushback is that the problem in that thread is the 13-hour day, not a missing plan. Management has to be responsible for the workloads and their impact on the team. If management is demanding a 13-hour day, it indicates a deeper issue with how work is being assigned and prioritised. The workflow is our management decision about where the saved time goes. At Amba, the time we’ve saved on writing code is going back into planning what we write and checking what comes back, not into more tickets and not into longer days.

And yes, this is what seniors always did. I took that one on in the last post and won’t re-argue it here.

We’re soon getting two new developers on the team, so we will see what teaching this from day one looks like. In the past it was easy: you would give them some small, light tickets you knew would touch a broad surface of the app, let them loose and let them discover. I have no idea what that looks like today.

What followed was seven months of figuring it out.

What we tried first

The first four months were open exploration. Two months where people could try the tools they wanted, then two months to decide which one would be our primary tool and apply, at the very least, proper security measures to it.

I assumed, and I was wrong, that the finding was going to be about which tool won. Pick the winner between the four coding agents we were trialling, then go along with it “naked”.

The output depended a lot on the developer using the tool. Some were extremely sharp with them and doing an OK job. Some trusted the tools too much and sent back mountains of code we had to reject.

Reviewing all that output is when we realised the naked approach was going to be the problem for us. These tools are good at writing code, but they had no idea how we wanted them to work.

So we spent the next couple of months building a workflow around the agent: a set of structured commands and agents that told it how to scope a ticket, plan delivery, write code to our standards, and hand work back for review. I approached it almost as if I was documenting for a team of new project managers, business analysts, developers and QA who were about to join us, explaining to each of them how we wanted them to work with us.

Where the gain actually sits

Here’s what tickets looked like before the workflow. The team needed to integrate a new sensor for data already in our catalogue. The ticket would be “Integrate with Sensor X”, a link to the API documentation, and five or ten lines on what we knew about the integration and the data ingestion that should happen. That was about it.

The assumption was that a couple of conversations with the developer, plus the fact that we already had the data points in our catalogue, was enough to make all the decisions. We don’t have a dedicated product manager, so this was how tickets got written.

The reality, and we knew it, was that developers were often confused midway through because there were unexpected decisions to make. QA had no clear acceptance criteria and no context on what the sensor was doing. And more importantly, we were probably skipping the part that would have pushed us to think about what this integration meant for the product as a whole.

Today, if we tell the workflow we need to integrate with this sensor, here’s the documentation and here’s the blurb about what we know, the flow reads the full documentation with our code as context. It builds a multi-card epic: connecting the sensor to the platform, then data ingestion, then data rendering. It writes user stories for every sub-ticket and QA acceptance criteria to go with them.

Then it helps the developer turn that scope into a locked-in delivery plan, ticket by ticket.

Not one line of that is code. All of it is the work that used to get done badly, or not at all, before anyone opened an editor. The workflow does what good ticket-writing would always have done, except now it’s the default rather than something you get when someone has the time.

What better looks like

A few months in, just as the workflow was becoming stable, we had our first real test. We’d had a hunch about one of our partner sensors: its token refresh logic would sometimes leave a token dead, and the only fix was to regenerate a new one manually. Within the same week, support came to us with the same problem. There was a race condition between token generation and consumption, silent because the sensor kept sending data. What we lost was access to the deeper data through the API, which is the kind of thing nobody notices until someone goes looking.

I used our workflow to expose the issue. I gave it the API endpoints we needed to integrate, and together we traced the problem and decided on a plan of attack: fix the race condition as far as we could, and give support an option in the app to regenerate the token if it ever happened again.

The agent wrote all of the code. I shaped the solution and traced the issue with it.

The irony is that the fix is solid, and the regenerate option has, so far, never been used.

The build was quick once the plan was set. But the value was in the tracing and the deciding, and the fact that a silent bug got fixed properly rather than patched around. That’s the kind of ticket I want us pushing.

The question everyone asks

When I came back to Stuart with results, he half-joked: “Oh, so now each developer can be a 10x developer and produce more?”

Stuart is sharp, an ex-engineer, and he obviously knew the 10x thing is an internet joke. But the productivity question is his job as CEO, and it was fair.

My answer was the oddest thing for a CTO to say about a tool everyone sells on speed.

I told him I wasn’t interested in 10x. Maybe 1.25, maybe 1.5, because we now had autonomous agents dealing with smaller items. The number I cared about was precision: how well we solved problems for our customers.

I didn’t want us to push more tickets. I wanted us to spend more relative time on a ticket, and when a ticket was pushed, for it to be solving more and better.

The feedback from the team backed this up. It came at different times and in different moments, all from senior developers, and I don’t remember it word for word. But every single developer, including the ones who resisted the introduction because they liked to “feel in control”, said after a few months that they saw real benefits.

The part I hold on to is that they feel they’re doing a better job with it, and that they haven’t lost ownership of what gets built.

That last point matters to me. I wrote in January that if you can’t explain the code, AI isn’t helping you. That was about the individual developer. This is what it looks like when you try to make it true for a whole team.

Yes, this is what seniors always did

The fair pushback is that I’ve been writing software for 30 years, 15 of them as a CTO, so of course shaping is where I add value. For a mid-level developer, the speed of code generation is the win, and I’m just describing what senior engineers have always done and calling it an AI workflow.

Yes. That’s right. And that’s the whole point.

Writing code entirely by hand is becoming less prevalent as a developer, at least while AI is around. Being able to understand a problem and translate it into a clear plan was a very desirable skill in a developer before. It’s now mandatory if they want to be productive with AI.

Scoping is my job. Delivery planning is the developer’s job, and that’s exactly where the workflow changed how they behave, because it forces the planning conversation whether or not the developer would have had it on their own.

The harder pushback is that I’ve swapped a bad metric for no metric. That one lands.

I don’t have clear metrics yet, only what’s in front of me day to day: the 50-odd tickets we’ve built with the workflow and the low rejection rate that came with them, and a clear sense from the wider team that we’re doing a good job. We’re working on embedding those metrics into the workflow now.

Until then, what I see is enough to know the direction is right, and the time we’ve saved on writing code is going back into planning what we write.

Where we are now

The workflow is out of beta and used by the whole development team. It’s going through small refinements as we find ways to improve it, but we’re out of the “improve it all the time” phase and into the stable one.

We can pair with it in attended mode, and we can dispatch autonomous tasks to it straight from our GitHub board, so it does everything we want for the moment.

What’s left is a human problem: us getting more proficient with it.

And since we’ve reopened the hiring process and will soon have new developers joining, my next step is working out how to introduce a new developer to a team that works this way.

Not because I stopped thinking. I stopped publishing. Life happened. A company acquisition, some personal stuff. I went heads down and rebuilt things.

Meanwhile, AI pulled software into a new phase. Now I watch people talk about it in a way that bothers me. They’re missing the real change.

AI isn’t a new tool in the toolbox. It changes what the toolbox is worth.

Output got cheap

AI made output cheap. Code, tests, docs, first drafts of features. Whole chunks of product, sometimes.

When output gets cheap, output stops being a strong signal. “I shipped a lot this week” doesn’t mean what it used to. Anyone can ship a lot when a machine drafts the work.

That’s the shift. Not “developers are doomed”. Not “we’re all ten times faster”. Value just moved somewhere else.

Here’s what I think: if you can’t explain the code, AI is not helping you.

It might feel like help. You moved faster. The diff is bigger. But if you can’t explain what you just shipped, you didn’t gain leverage. You lost ownership.

So what does “explain” actually mean? I’m not talking about describing the folder structure.

What “explain” actually means

I mean you can answer basic questions without hesitating:

• What does this code do?
• What does it depend on?
• What assumptions does it make?
• What could break it?
• How would you notice?
• What would you do about it?

That’s the bar. That’s engineering with the theatre cut out.

For most of my career, nobody asked these questions. Or at least, not consistently. The industry rewarded something else.

The old deal

For a long time, teams rewarded implementation speed. Take a ticket, make it real, move on. That made sense when implementation was the bottleneck.

Even average implementation had value because it took time, focus, effort. A lot of careers were built on being the person who reliably turns requirements into working code. I know because I hired those people for eleven years. Good people. Solid people.

That deal is changing. Worth being specific about which parts AI actually touches.

What AI replaces

AI can automate much of the drafting and pattern matching that used to consume engineering time.

It replaces the loop of “search, paste, tweak until it compiles”. It replaces writing the boring parts. It replaces the first version of almost everything.

That’s not bad. It’s progress. But it wipes out work that used to separate “productive” from “stuck”. So the market re-prices that work.

Here’s where people get confused. They see AI writing code and assume it’s doing the whole job. It’s not. Not even close.

What AI doesn’t replace

AI doesn’t replace responsibility.

You can feed it the context of your system’s history, but it won’t maintain that context, judge what matters, or own the consequences. It doesn’t feel the pain of a production incident at 2am. It doesn’t own the trade-offs when a quick fix creates a long-term mess.

It generates implementations. It doesn’t decide what matters.

That decision is where value moved.

This sounds abstract. Here’s a real example.

Verification debt

Here’s what people miss.

AI makes confident-looking code cheap. It compiles. It reads well. It sounds like a strong engineer wrote it. Teams lower their guard because the output looks professional.

But real systems fail in places you don’t see in a clean demo. Weird data shapes. Partial outages at 3am. Retry logic nobody tested under load.

If you ship AI-assisted code you can’t explain, you create verification debt. You borrow certainty now. You pay later in bugs, rework, incidents. Slow loss of trust in the codebase. Slow loss of trust in the team.

AI lets you generate that debt faster than most teams are ready for.

I watched a team ship an AI-generated authentication flow last month. It looked clean. Passed code review. Two weeks later, a race condition in the session handling took down their checkout for six hours.

Nobody on the team could explain why the code handled token refresh that way. Because nobody had decided it should. They’d accepted what the machine offered. Seemed reasonable at the time.

Now, there’s a different concern I hear from developers. Not about debt or quality. About identity.

“But is it even my code?”

This question keeps coming up.

Developers feel weird about using AI. Feels like cheating. If Claude generates the implementation, if Cursor writes the tests, if the AI drafts most of the file… what did you actually contribute?

I get it. I’ve felt it too. But it’s the wrong question.

The director problem

Nobody debates whether a Spielberg film is “his”. He doesn’t operate the camera. Doesn’t build the sets. Doesn’t edit the footage.

Yet you can feel his fingerprints everywhere. In what the film focuses on. What it cuts. What the scene refuses to waste time on.

The camera operator executes with technical skill. Spielberg decides what to point the camera at. When to cut. What the scene needs to achieve.

That’s authorship. Nobody questions it belongs to him.

What this means for your code

When I use AI to build a feature, AI might write most of the code.

But the architecture is mine. The constraints are mine. The boundaries are mine.

The spec that told AI what to build came from twenty years of watching things go wrong. The judgment about why this approach fits our team, our codebase, our risks? Mine.

AI is the camera crew. I’m the director.

The code is mine because the decisions are mine. The trade-offs are mine. The responsibility when it breaks? That’s on me.

If you can explain those decisions, the code is yours. If you can’t, you’re not the director. You’re hoping the camera crew guessed what scene you needed.

So what does this mean for your career? What actually makes a developer valuable now?

What valuable looks like now

A valuable developer isn’t “the fastest typist”. Never really was, honestly. We just measured output because output was easy to count.

Now? It’s the person who can own outcomes. Someone who turns vague requirements into a clear problem. Who decides what matters before anyone asks. Who spots risk before it ships.

Someone who can explain what they built. Why it won’t fall over under real pressure. Why this approach and not another.

AI doesn’t remove that person. It makes them more dangerous.

The line

AI didn’t kill developer value. It moved it.

If you can’t explain the code, AI is not helping you. It’s hiding the gap until production finds it.

If you can explain it, AI becomes leverage. You keep authorship. You ship faster without guessing.

That’s the line.

I’m Nic Alpi. After 20 years in tech and building a consultancy to £1M+ revenue before acquisition, I’m now a working CTO writing field notes on attention, judgement, and leading engineering teams in the AI era. One field-tested practice every fortnight — what worked, what failed, and what I’m changing next.

I’ll wrap up the previous year, think about everything I want to achieve, make them all SMART, plan out a whole “new year, new me” roadmap—and it’ll feel amazing… until about the end of January. Then life kicks in, my shiny new plan goes to shit, and my notebook of goals starts collecting dust. Obviously, I feel guilty as hell about it—because if I’m going to fail, I might as well marinate in guilt too, right?

2024: A Different Story

But 2024 was different. It was full of big personal changes, and somehow, I managed to build a brand-new identity. The catch? I didn’t set any rigid goals last January. I just had a couple of “things I wanted to do” or intentions.

I stuck to those intentions. No elaborate, perfect plan—just a desire to make a few changes, experiment, and see what happened. And it fucking worked!

In 2024, I lost a solid amount of weight, tackled my emotional relationship with food, and basically turned “healthy” into a big part of my identity.

Reflecting back, it’s clear this transformation didn’t happen overnight. I had my share of slip-ups, mistakes, and moments where I pushed too far. Still, each time I messed up, I just got back on track—and that compounding effect really did its job over time.

What Actually Changed?

Why did not setting a huge, precise goal—like “I’m gonna lose X kilos by this date, in exactly this way”—work out so much better for me? And more importantly, how can I replicate that process in other parts of my life?

Experimentation Over Rigid Goals

Turns out, without even realising it, I was doing a year of experimentation. It reminds me of something I used to do back when I ran a software agency in my previous life.

We’d set the next year’s financial goals around March or April. Then I’d have the time between that and the 1st of September to basically try things out: new sales methods, new marketing channels, different types of content—just experiment without getting too attached.

By the time August/September rolled around, I’d look at what worked, what felt good, what was actually fun—and double down on that. Everything else? I’d let it go. This simple system helped us grow year over year for 11 years.

That’s pretty much what happened with my health in 2024. I had the freedom to dip my toes into a bunch of different health approaches because I wasn’t locked into a strict plan. I just knew I wanted to be healthier and make it a lasting lifestyle change, so there was no point forcing myself to do something I hated.

I tried almost every form of exercise, gently, between January and March. The aim wasn’t to progress at anything but to try things out, see what I liked, and find my routine.

Then, from March onwards, it became clear that I enjoyed lifting heavy things, running, and swimming the most. So I concentrated, for the remainder of the year, on getting better at those, with a focus on “listening to my body”. And what my body told me was that trying to cram too much into the same week would leave me exhausted, with everything in my life suffering as a result. So I looked inward again and decided that weightlifting and running were “my thing”, and swimming would only happen when I really felt like it.

Intention

Now, onto this year’s theme: Intention.

After looking back on 2024, I’ve decided to keep going with this “no big plan” philosophy, but do it all with clear intentions. What do I want to change or improve in 2025? And what am I leaving behind for good?

I plan to focus on just a small handful of things, experiment my arse off, and keep only what works—and what genuinely feels good.

It sounds fun: designing a life around the freedom to explore, and bringing intention to every part of it. I’m definitely excited to share more about it as the year goes on.

The Three Pillars of My Life

Right now, I have three main areas:

• Health
• Work
• Personal Life

It’s all too easy to let one area consume the others—like when I obsess over work and completely forget I have a body that needs exercise or a personal life that needs attention. But I’ve realised that happiness is all about striking some kind of balance.

This year, I want to approach all three pillars with genuine intention—making sure I get things done without sacrificing everything else. It might require some planning, and I’ll probably have to let go of a few “it would be nice if…” ideas.

But you know what? I’m actually looking forward to it.

Looking Ahead to 2025

I’m ready to embrace this new way of living: setting intentions, giving myself the freedom to screw up, learning from those fuck-ups, and carrying on anyway. I don’t have a big laundry list of “goals”—just a few core desires and a lot of excitement to see how these experiments shake out.

Because honestly, if the process is fun, if I’m learning and growing, if I’m living more authentically—who the hell needs a perfect plan?

Looking back, I realise I’ve been running on autopilot for much of this time, trying to numb myself from emotions I wasn’t ready to face. It wasn’t the wisest approach, but it was survival mode kicking in.

Recently, though, those emotions caught up with me. It felt like I had a constant, invisible weight pressing down on my mind, a sense that something was wrong, but I couldn’t pinpoint what. I was trying to keep it together outwardly, but internally, it was a different story.

Then, as often happens, a shift came when I least expected it. After a long sleep and a long walk in nature—no phone, just a notebook and pen—I sat down in a coffee shop and started writing. I wrote everything that came to mind, not filtering anything.

And there it was, on paper: I felt like a failure.

Not just in one area of my life, but across the board.

Strangely, seeing those words didn’t send me deeper into despair.

In fact, it was the opposite—it was freeing.

Acknowledge the feeling

Now that I could acknowledge what was really going on in my head, I could start to work on it.

So, I did what I do best: I made lists.

I wrote down all the areas of my life that were contributing to this overwhelming sense of failure—failed personal goals, unfinished projects, and the many things I’d let slide.

Some things, like the past, I couldn’t change. But for the most part, how I felt today and how I’m deciding to feel in the future, I knew I could do something about it.

It wasn’t easy, but it was necessary.

Gratefulness shit

Next, I decided to take a moment to write down what I was grateful for.

This is usually a struggle for me—I’ve always found the “what are you grateful for” exercises to be a bit fluffy, to stay polite. But I gave it a shot.

I started with the obvious—my kids, who, by the way, are objectively the best kids on the planet. From there, I acknowledged the things I was grateful for from my past and the opportunities I have now. Slowly but surely, my mood started to lift.

With a clearer head and a long list of thoughts, I had to ask myself the big question: What now? What was I going to do about it?

Taking actions

One thing became clear: I needed to take action towards my goals.

But this time, I had to approach things differently. In the past, I would get bursts of motivation and dive headfirst into my goals, trying to do everything at once. Inevitably, I’d burn out, lose momentum, and feel like I’d failed again.

This year taught me something important: Consistency beats perfection every time. No matter how small the effort, showing up every day matters.

I learned this lesson while working on my health. When I first started, I went all in—exercising twice a day, pushing myself hard, and aiming for quick results.

Unsurprisingly, I burned out quickly. But instead of quitting, I took a step back and re-evaluated my approach. I shifted my focus from the numbers on the scale to simply making sure I moved my body every day.

Some days it was heavy lifting, other days intense cardio, and sometimes just a leisurely walk. It didn’t matter as long as I kept moving daily. That simple change in mindset completely transformed my relationship with fitness.

The weight loss and better health became by-products of daily actions rather than the end goal.

And that’s the key. I’m applying the same mindset to the rest of my life now. I want to work on what I enjoy, spend time with my kids, and create—whether that’s through building an app, writing more, or experimenting with video creation. These aren’t just goals; they are things that support my larger vision of a fulfilling life.

For a long time, my actions didn’t match my ambitions. I’d have bursts of energy and excitement, but I struggled to maintain them. And like yo-yo dieting, that inconsistency led to frustration and feeling like a failure.

But here’s the thing: Feeling like a failure is deeply personal, and it’s easy to let that feeling consume you. But I’ve realised that failure isn’t a life sentence—it’s just a moment, and I have the power to choose what comes next. I’m choosing to leave the past behind, to show up every day, and to focus on the things that give my life meaning and purpose.

The next 3 months trial

For the next three months, I’m committing to daily, consistent action. First, by making sure that my day job time is completely shielded and I’m giving my 100% to my team when they need me.

Next, I’ll focus on daily small actions that will move the needle towards my goals:

• I’ll work on my app for no more than an hour each day
• spend 30 minutes writing
• And finally chip away at overcoming my camera stage fright for my YouTube idea.

But, it doesn’t matter anymore if any of these are ever published, I’m not focused on the outcome. I’m focused on showing up.

The process is what matters. No matter what comes out of it, I’ll grow.

This year might have been complicated, and I might have felt like a failure, but I’m choosing to leave that behind and focus on building a future I can be proud of.

The Hoodie: Staying in Touch with Development and Innovation

The first essential in a CTO’s wardrobe is the hoodie, a symbol of our roots in development and the need to stay grounded in the tech world. Despite the executive title, a CTO must remain deeply connected to the ever-evolving landscape of technology.

Staying Updated with Industry Trends

To keep pace with rapid advancements, a CTO must immerse themselves in the latest industry trends. This involves more than just passive reading; it means actively participating in tech communities, attending conferences, and engaging with thought leaders. Platforms like GitHub, Stack Overflow, and Twitter are invaluable resources for staying informed about new programming languages, frameworks, and tools.

Fostering Innovation

Innovation isn’t just about keeping up; it’s about leading the way. A CTO should encourage a culture of experimentation and creativity within the development team. This can be achieved by implementing regular hacking/twinkering sessions, encouraging continuous learning, and promoting a fail-fast, learn-fast mentality. It’s crucial to allocate time for the team to explore new ideas and technologies that could benefit the company.

Balancing Management and Technical Involvement

While it’s important for a CTO to have a strong technical foundation, balancing this with management responsibilities is key. This means knowing when to dive into code and when to step back to provide strategic oversight. Effective delegation, trust in the team’s capabilities, and clear communication are essential to maintain this balance.

The Smart Casual Shirt: Representing the Company

Next up is the smart casual shirt, perfect for those times when the CTO needs to step out of the coding cave and into the spotlight, representing the company to various external parties.

Clear Communication and Relationship Building

A CTO often acts as a bridge between the technical team and external stakeholders, including customers, clients, partners, and potential new employees. This requires the ability to translate complex technical concepts into accessible language that resonates with a non-technical audience. Building strong relationships is crucial, as these interactions can lead to new business opportunities, partnerships, and a positive company image.

Balancing Technical and Business Perspectives

When engaging with external parties, a CTO needs to balance technical knowledge with business acumen. This means understanding the market landscape, recognising the needs of the stakeholders, and aligning technical strategies with business goals. It’s a delicate dance between showcasing technical prowess and highlighting the tangible benefits to the business.

The Crispy White Shirt: Presenting to the Board

Finally, we have the crispy white shirt, reserved for those high-stakes board meetings where the CTO must represent the technical team and articulate the company’s technological vision to investors and executives.

Preparing for Board Meetings

Preparation is key when it comes to board meetings. A CTO must present complex technical information in a clear, concise manner that board members can easily understand. This involves creating detailed reports, visual aids, and being ready to answer tough questions about the company’s tech strategy and its alignment with overall business objectives.

Clear and Concise Presentations

Board members are often more interested in the impact of technology on the business rather than the technical details themselves. Therefore, a CTO must be adept at summarising key points and focusing on the strategic implications. Highlighting how technological advancements will drive growth, improve efficiency, or create new revenue streams is crucial.

Professionalism and Clarity

In these high-stakes environments, professionalism is paramount. This means being punctual, dressing appropriately, and communicating with confidence and clarity. The ability to present a calm and collected demeanour, even when faced with challenging questions, reflects well on the CTO and the technical team as a whole.

Conclusion

Being a CTO means wearing many tops, each representing a different facet of the role. From the hoodie that keeps us grounded in the world of development and innovation, to the smart casual shirt for external engagements, and the crisp white shirt for boardroom presentations, each top is a reminder of the diverse responsibilities we juggle. Embracing these roles with a sense of humour and adaptability is key to thriving as a CTO.

So, while I may not have a hat head, I certainly have a wardrobe full of tops ready for any occasion.

Later, you discover that many team members were confused but didn’t speak up. Sound familiar? If so, you’re not alone.

In fact, over my 15+ years managing amazing people, it happened more often than I would like to admit.

Even worse, I’ve seen many of them take a convoluted journey to avoid saying, “I don’t know” or “I don’t understand this”.

Inevitably, when you ask them why they didn’t make it clear sooner, they will answer something like, “I didn’t want to appear stupid”.

What I’ve learned is that, as a manager, this is a red flag. Not on the individual, but on the fact that you haven’t made it clear that to grow, and for your team/company to succeed, everyone should be free to ask the most stupid question if they need to.

If something is not clear, it’s not the individual fault. The delivery of the message may not be clear enough.

This blog post is for every manager who’s ever wondered why their team hesitates to ask questions and what can be done to change that culture, as well as a team member who needs the courage to speak up.

The Science Behind the Fear of Looking Stupid

What is it that makes us “fear to feel stupid”. In fact, even when the team culture encourages people to speak up and ask questions, you’ll find that some individuals still need to be more comfortable with this exercise.

As you can imagine, this is actually a well-researched part of the human psychology and, strangely enough, physiology.

1. Social Psychology and Group Dynamics: The fear of looking stupid in a group setting isn’t just a personal quirk; it’s deeply rooted in social psychology. Solomon Asch’s conformity experiments in the 1950s demonstrated how powerful the need to conform can be. This phenomenon is known as “conformity pressure” and it can make individuals reluctant to ask questions that might set them apart from the group.

2. Cognitive Biases: Our brains are wired with cognitive biases that influence our behaviour, often without realising it. One such bias is the “Spotlight Effect,” which makes us believe we’re being noticed more than we actually are.

3. Imposter Syndrome: This term was first coined by psychologists Pauline Rose Clance and Suzanne Imes in 1978. They found that high-achieving individuals often doubt their accomplishments and fear being exposed as a “fraud.” This syndrome can make team members hesitant to ask questions, as they may feel that doing so would expose their perceived inadequacies.

4. The Need to Belong: Evolutionarily wired to prioritise social connections, our brains associate the perceived risk of looking foolish with tangible threats. Historically, exclusion from our tribe could mean the difference between life and death.

5. Physical pain: Social ridicule or embarrassment triggers the same areas in our brain as physical pain. So, the fear of looking stupid isn’t just psychological. It’s biological.

What have we learned

So far, the deck is stacked against us. We seem to be wired to not make waves, to run away from the embarrassment of ‘not knowing’.

Let’s now explore how we can change this, both at a personal level as well as a team culture level.

5 Top Tips for Team Members

There’s so much a team culture can do before you, as a person, will have to still make the effort. These tips will be more powerful if you work in a team that embraces the “speaking up culture”. But before you dismiss your team as incompatible, give them a shot.

• Embrace your inner voice: Nobody knows everything. You, me, your boss, and certainly not your coworker, who seems to have all the answers. And guess what? That’s perfectly OK! It’s how we grow.

• Do your homework: Before your next meeting or one-on-one, write down what’s puzzling you. You should even rehearse it a bit. You’ll walk in feeling more confident and ready to engage.

• Timing is Everything: Only some questions need an audience. If you’re worried about asking something in front of the whole team, find a moment to pull someone aside later.

• Find Your Question Buddy: Find someone you’re comfortable with on your team and make a pact to back each other up in meetings. There’s strength in numbers.

• Understand that it’s OK to be the ‘stupidest’ in the room: In fact, sometimes it’s the best position to be in. By asking questions, answers will benefit everyone in the room. If it’s good enough for Simon Sinek, it’s good enough for me.

10 Top Tips for Managers

Right now, onto the exciting part. How you, as a manager can foster a culture that makes people feel confident in asking questions.

1. Lead by Example: If you have to do one thing, it would be this one. Next time you’re in a meeting, be the first to say, “I don’t know. Can someone explain that to me?” You’ll be amazed at how this simple act can open doors. Force yourself to ask questions, even if you know you can find the answers by yourself.

2. Create a Safe Space: Remember that time you asked a question and got shot down? Yeah, nobody wants to feel that way. Make it clear that your team’s meetings are a judgment-free zone.

3. Encourage Open Dialogue: Take your time with agenda items in meetings. Pause and ask, “Does anyone have questions or thoughts they’d like to share?” And then—this is crucial—wait.

4. No Such Thing as a Stupid Question: You’ve heard it a million times, but it bears repeating. Make this your team’s mantra.

5. Anonymous Channels: Some questions can be sensitive. Create an anonymous channel where team members can ask questions without fear of judgment.

6. Reward Curiosity: Remember that team member who asked a great question in the last meeting? Could you give them a shout-out?

7. Be Approachable: Have you ever had a boss who seemed too busy or substantial to talk to? Don’t be that person.

8. Train Managers: If you’re a manager of managers, this one’s especially for you. Make sure your leadership team is trained in fostering an open culture.

9. Regular Check-ins: Do not underestimate the power of a one-on-one. These private conversations can be the perfect setting for questions that team members might hesitate to ask in public.

10. Feedback Loop: Last but not least, always follow up. If someone asks a question, ensure it gets answered—even if you have to look up the answer yourself.

The last and most important point

More often than not, questions arise when something is not clear.

So when questions are asked, make a note of them. And when different people ask the same question multiple times, you know that you have something to improve on.

Document, train, and change delivery style. Try a different approach, but if something is unclear enough that multiple people question it, you have something to improve on.

Remember, not everyone will have the courage to speak up, so you only hear from the tip of the iceberg.

But let me tell you, the adventure didn’t stop there. Just when we were to embark on our next growth journey with our team, life threw not one but two acquisition offers our way. One came from another agency in our field that wanted to scale rapidly and the other? It was an unexpected counteroffer from one of our favourite and most respected customers. We weren’t even actively looking to sell, yet we took a leap of faith and decided to embrace something new, joining forces with our customer to bring Amba, an exciting product in the age tech space, to life.

Fast forward almost two years, and I am settling into my new full-time CTO role. But I’ve kept the conversations alive with fellow agency leaders. And I’ve realised that sharing our journey, the ups, downs, and everything in between, could be valuable for the younger entrepreneurs starting their own (crazy) agency-building adventures.

This series of posts will possibly be a long and therapeutic exercise where I will look back at almost 15 years of my entrepreneurial life and recount experiences and insights gained through that journey. Having been quiet for the past two years, I hope to have some insights to share with the younger entrepreneurs who are starting their (fascinating) journey of building and growing an agency.

From freelancer to entrepreneur

I’ve always known, from my teenage years, that I would have some entrepreneurial drive. Unlike the familiar story of the entrepreneurial kid making his first few dollars at the lemon stand, my motivation wasn’t money but freedom.

I’ve always been driven by building software and achieving some level of freedom. This is why, when I was a pothead 15 years old, I dreamed of myself as an open-source developer, living on a remote farm in the Alps mountain.

Even if my life changed, and instead of owning a farm in the Alps, I own a suburban house around Bristol, the mindset is still relatively similar. A certain level of freedom drives every decision I take in life. In my early 20s and 30s, freedom materialised by having enough money to live the life I wanted. These days, freedom means I can be a great dad to my kids and spend as much quality time as possible with them.

When in France ….

I grew up in France, and in my early 20s, rather than going to university or following the engineering school path, I decided to build a business instead.

Technically, I was freelancing, but since this was over 20 years ago in France, freelancing wasn’t to be trusted. I’m sure my website at the time was filled with “we” and “our team”, but it was me in my bedroom.

It was the burgeoning era of the web, and I was a webmaster. I was mainly building the first dynamic websites for small local businesses (think little shops/estate agents etc.) in the pre-WordPress/Magento era.

But I sucked at business. I was too cheap. I would spend too much time on each client, and while I was making decent money for my young age, I would burn it all in nonsense items like any young chap with a bit of money would do.

After a few years of this freelance life, I got headhunted by a medical software company and became a full-time developer.

Moving to a new country

After a year together with Nathalie, her studies bought her to the UK for an internship, and I decided to follow her. We settled around Bristol, and I found a software developer job at Hewlett and Packard (HP). Fast forward a year in the country, and I was missing the freedom again in this new role. We’re now circa 2009; I’ve been crafting things in Ruby on Rails and enjoyed the framework. So I set out to be a Ruby on Rails freelancer.

But this time, I would treat it differently than my early attempt in France. I would have a reasonable day rate, monitor my time and focus on building good case studies.

But I didn’t have a network here. I needed people to get to know me. So I became more active online, running my little events (meet-ups about Ruby on Rails) and attending many other people’s events in my niche (entrepreneurs, startup founders).

I rapidly became known as “the Frenchman who works with startups” around Bristol (my thick accent was finally useful at something).

Strangely enough, this was also when I was introduced to a person called Stuart. I built a project for him and enjoyed working with him. He was both extremely smart and driven while being incredibly humble and friendly. Never would I have thought that, through the next 11 years:

• we would build another 4 projects
• he would end up acquiring my company
• we would build something new together.

After two years of freelance work, I had a good run and was working on exciting projects. It was also the time when Nathalie (who was about to become my wife) was looking for a new role. She is trained in international marketing and’s the actual brain of everything we do.

We then decided to team up, building a company that would sell software development and marketing to early-stage startups.

It was the beginning of our grown-up entrepreneurial journey. And by working together, we would be (at least we thought) in control of our destiny and freedom. So, in 2011 we decided to incorporate our agency, get married and conceive our first child. It’s a make-or-break year.

But when I think about it with more insight, this decision set our mindset for the next ten years. We were young, in a new country and without any safety net. Failure wasn’t a luxury that we could afford.

What’s next?

As I started writing this post, I realised there’s a lot I want to say. I’ve decided to split the content into a series of posts. This chapter is simply setting the tone, and I hope it has given you a little more insight into my mindset.

Later this week, we will look at Navigating the Entrepreneurial Landscape: What starting a business looks like, the mistakes we made in our initial market research, how we decided to position ourselves and why we voluntarily limited our growth.

Instead of recreating yet another easy-to-write, easy-to-forget blog, let’s explore why it’s currently difficult to find a job as a junior Ruby on Rails developer.

What can you do about it, hopefully giving you ammo on getting those first conversations?

What are those tips?

Before anything else, let’s make a quick list of the common tips you’ll find if you’re looking at getting your first junior developer job:

• Be on time: I know this seems ridiculous to state, but you wouldn’t believe the number of people that are late for their interview and are not warning you. While shit can happen, and any interviewer will understand it, they can also smell bullshit excuses rather quickly. My view is either to be on time or cancel the interview altogether and try to rearrange it. Starting an interview late is a bad sign as you’ll both be under pressure for lost time.

• Work for free: Again, another controversial point, but let me explore that for a second. I’m not advocating you work for free as a developer in a company. This should not be banned and not exists. But, if your circumstances allow you to do, you should spend time crafting things. Make your little todo app and deploy it on Heroku, for example. Or learn a new something about Rails you haven’t seen before and publish some little code on Github. The truth is, one of the first things a recruiter will do is search your name on google. They will look briefly at your social media feeds and look a little more closely at your GitHub account. And there, it’s pretty simple. Someone with more activity will, more often than not, be favourited against someone else. So commit small and push often. A less controversial way to label this would be “create your portfolio”.

• Be humble: Yes, you have done a bootcamp, and some may want you to think that when you leave them, you’re almost a mid-dev after three months. This is not true. You’ll have a ton to learn that is not taught in bootcamp. So understand what you’re missing, where the holes are, and state them clearly.

• Be ready and ask questions: Again, another one that seems like a no-brainer, but you would be surprised how many interviews I did where the person in front of me didn’t even bother looking at our company website, who we were and what we were doing. As a recruiter, this is very frustrating. And, if you spend minimal time looking at what the company is doing, you’ll hopefully get some questions. In fact, the more questions you have prepared, the merrier.

See, I told you, those tips are not groundbreaking. Again, I wouldn’t be surprised if you were to find those on every blog post about junior tips to get your first job.

Right, but why do I struggle to get the interview then?

Now we’re entering the actual subject. You’re ready. You’re prepared. You’ve got a small portfolio of little projects, but somehow, no jobs are coming your way. Why the hell is that?

It’s not you. It’s Rails

Unfortunately, at the moment, Ruby on Rails seems to be a double-edged sword. Ruby on Rails allows anyone and any team to write web applications productively. To achieve the same results, you then need fewer people. And needing fewer people is then having a direct effect on the recruitment rounds and most notably the juniors.

See, some recruitment manager or some teams only see in bringing juniors to their team the productivity impact this will cause (either because of the time they will take away from more senior folks, or because they could have hired a mid-level/senior instead).

Now, on this point, realistically, there’s nothing you can do to change their mind. It’s a difficult decision to reason because one side of the equation is true (yes, taking a junior in a team will have an impact on productivity), but the other side is entirely narrow minded.

So, yes, it’s not you. It’s Rails. But, the community is becoming more aware of the issue. Most of us have a deep sense of pride and attachment to Rails as a framework but also realise that we need to solve this issue for Rails to strive in its renaissance. For Ruby on Rails to continue its journey, we need to get more people (juniors) to experience it.

It’s not you. It’s the (more) seniors developers

While this point is valid for Rails, it’s also true for any other language and framework.

Sometimes seniors might be excellent developers, but they can be terrible mentors.

A junior developer will inevitably need a mentor to grow and strive in his journey, and this mentor should, more often than not, be found in the team he spends his day with.

But when the seniors in the team don’t have that mindset, they sometimes can be blockers into bringing Junior folks into the team.

Unfortunately, this might be due to the strange progression expectations of our industry.

You see, I have more than 20 years of experience as a developer, and sometimes I struggle to call myself a senior developer. I’m still part of a specific journey, and I’m still learning.

But it’s not rare to see someone rise from Junior to Senior or sometimes even CTO in a very short (less than five years) career span.

This is something I find incredibly unsettling about our industry. Why are we looking to move so quickly to those senior positions? Yes, pay compensations and responsibilities are one part of the equation. Still, the reality is that when you get senior developers with five years of experience, they might not have the time to develop some of the soft skills needed to succeed as well-rounded developers. Mentoring/training is undoubtedly part of it.

It’s not you. It’s us

While (some) Senior developers have a role to play in the current situation, founders / recruiting managers should also look at themselves.

Based on what we said so far, we know that:

1. It’s difficult to recruit
2. Rails is a productive tool and will allow anyone to work faster with it
3. Some seniors are not keen or ready to become a mentor

Taking all this in consideration, it’s easier to see why some of the people in charge will revert to the mid/senior roles only.

This is a false good idea.

By doing so, the team exposes itself to a various series of issues.

• Churn for pay: In a world where it’s easier to change jobs to get a 30% pay rise versus staying in place and getting 5% extra per year, mid to senior people will churn rapidly.

• No mentoring: A team not mentoring its mentors will never change. If the people in the seniority position are not ready to take onto their wings some newer folks and nobody is helping them, they will never change and do it.

• Possible lack of diversity: Not only in terms of gender or skin colour but also in terms of problems’ approach and background. Juniors tend to come from various backgrounds, bringing a fresh new perspective on the product or problem a team is trying to solve.

Hiring juniors well could combat all these points. Hiring juniors will give seniors an extra sense of achievement that will sometimes retain them in the current team for longer (as long as they are well supported in their mentoring journey). Juniors will bring a fresh new perspective and, if treated well, will stay loyal to the team that gave them a chance in the first place.

But don’t despair. Things are moving

While this is painting a pretty gloomy picture of the whole situation, some voices in the community are starting to emerge and are raising the same concerns I present in this article.

It will change, I’m sure. Things have to move as, without giving a chance to folks who want to join our community, Ruby on Rails might be the best framework in the world to build products, but it will then lack the talents to write the code.

We’re literally shooting ourselves in the foot if we are not welcoming and training the next round of talents.

Ok, so how do I get my first interview?

Right, that was quite a lot of introduction to the problem. But you might wonder what difference it makes to you and how you’ll get that first interview.

Well, the job as a developer is about solving problems, and you trying to get a job is currently your first problem to solve. It’s going to be time to be creative.

And to solve a problem, you need to understand your users. You need to understand and reflect on what they are experiencing, how they are currently solving their problem, and the possible solutions you can bring to the table.

In that scenario:

• your users are your future team or the next hiring manager
• their problem is that they need new people joining their team
• they are currently solving it by hiring people more senior than you

Great, now that we’ve assessed the problem and, if you’ve read the rest of the post, you should understand more about the various mindsets at play. We must concentrate on the few tactics that will separate you from the pack.

Select passionately

If you’re struggling to find your first job, it’s tempting to “spread and pray” your CV to every recruiter and respond to every job application.

Unfortunately, this is doing more harm than good. The difference between a generic email and a personal one is night and day.

A personal approach is a lot more effective. They can’t blast these emails (even if you can reuse a lot from one email to another). They seem to have taken a bit more time and careful consideration on who to apply with.

As a person in charge of recruitment, I receive at least a dozen generic emails a week when we say we’re hiring.

I don’t often receive personal ones, but when I do, I look at them differently and will give them a stronger consideration.

Have something to show

I know what you think. How can I possibly have something meaningful or worthwhile to show if I’m just a junior?

But, having “something to show” doesn’t mean something crazy and super innovative to show.

It means be prepared to share one or two examples of codes you’re proud of.

When we look at this code, our aim is not to judge the “cleverness” of the code. We (or at least I) will be looking mainly at:

1. The fact that you’ve taken the time to master your craft
2. The general structure of the code
3. If you wrote any tests for it

Don’t be scared to apply

That’s typically when I hear an “easier said than done, Nic!”. But trust me.

While it’s difficult to tentatively apply to companies that are not hiring right now, if you “select passionately”, it should reduce the scope of those companies.

Secondly, if you see some that have open positions for a more qualified role (like the dreaded minimum three years of experience), I would urge you still apply.

But, don’t apply by sending a generic three lines email. Take the time to craft that first intro email showing them you’ve put some careful consideration about applying there.

Agency / Consultancy / Products

The kind of companies you will be applying to will most likely fit one of those three categories—each with its pros and cons.

Agencies build products for other people. They are paid to write code for a client, usually for a fixed amount of time. Agency work is great for junior developers because you will see a lot of different products as well as a lot of different codebases and possible coding styles.

Consultancies are still paid to write code for other people, but this time they are not writing a new product but improving an existing one. Because consultancies are hired for their brain and expertise, it will be difficult, as a junior, to find your way in.

Products is a vast title. Unlike agency work, product work tends to be less stressful. Deadlines still exist, but they are fixed internally and tend to be less dramatic.

Closing words

Sorry, I didn’t intend to write something that long, but if you’re still there, it is probably worthwhile.

I know that some of these points go against what people would like to read or even how our industry should work, but they are the reality for the moment.

Don’t get discouraged if you are looking for a (Ruby on Rails) junior position.

Our industry needs you.

But more importantly, when you’ve found your position and grown in seniority, don’t forget, at some point, to give their chance to that younger, hungrier you. You could be surprised by who they become.

This is not the first time I was going to publish something on the internet. For the past 15 years, I have been publishing articles, videos, and podcasts but primarily for CookiesHQ, my then software consultancy.

Publishing was a way for us to grow, recruit, share our expertise, and make new connections, but also a way to give something back to the community and help others.

I’ve always enjoyed the web as a space; it’s the idea that everyone can own their little part of this vast space. You don’t need to be/want to be famous, and you’re sometimes simply using it as a cathartic or therapeutic experience.

Toughs, words, pixels on a screen and this act of creating something and hitting publish.

So, following our acquisition, I needed to get back to this idea of personal writing.

Surely, after 20 years of developing software professionally, 5 years of freelance and 10 years of growing an agency, recruiting, managing a team, growing our revenue to 7 figures, launching more than 30 different projects for our clients, working with startups, scale up, non profit organisations and finally going though an acquisition process and now building a new SAAS product, I would have a few interesting things to share.

So I started to list what I wanted to write and talk about. What subjects, I think, I can bring value on?

And after buying this domain name, I decided that I would write about what I know the most about:

• Tips about building and maintaining Ruby on Rails applications.
• New and shiny features of Ruby on Rails and how to use them.
• Sharing some updates on a personal project of mine.
• Thought about our industry, service businesses, the web and startups.

Easy enough, these are subjects I can talk about for hours with my team. How difficult could it be for me to write about this?

So I bought the domain name, inevitably played with every tool under the sun, and then decided to wire up a little WordPress site, and off I will publish a new article each week.

At least that’s what I thought was going to happen. Week after week, I would tell myself that next week would be the one. I will start next week to write something.

Surely enough, the next week passed, and that first draft was still an empty page.

Maybe it’s because I don’t have the time right now? After all, a lot was going on in Amba, and we were building the foundation of a new company.

Ok, let’s give it a month and come back to back.

Then, month after month, my desire to write and publish something was there, but my actions were not matching my desires.

After nearly a year, what was happening became pretty clear.

I was scared to start. I feared hitting publish.

Maybe that was ego getting in the way, perhaps that’s the so-called imposter syndrome, perhaps it’s the fear of talking non sense.

For as much I’ve done in the past 10 or 20 years, I know that I’m now starting again at the bottom. My space on the internet, this domain name, is empty and will need to be filled up. And I know this is going to be difficult.

While a lot of people will tell you to write for yourself, don’t worry if nobody reads it, let’s face it, no one wants to spend time doing anything for it to go completely unnoticed.

I want to share my experiences to be able to help some people.

I want to create new connections.

I want people to disagree with me so we all can enter a conversation and learn from each other. (If the Internet can still be such a place)

But all this, I know, is very difficult. Things take time. I’ve been there before.

So here I am, writing again for the first time and kickstarting my journey by sharing my fears with people to keep myself accountable.

Yes, I’m scared that this corner of the internet will become yet another dusty space where nothing more gets published. Yes, I fear hitting publish even if I’ve done it 100 times before. Yes, I fear that nobody will read this.

But, I will not let my fear get in the way. I’m going to hit publish now.