Hello my name is

Dan Webb

As an advisor, this is familiar story: CEOs and CTOs are confused about why their engineering team has got slower as they've added engineers. "We've doubled the team but we're shipping less than we did with five people." The assumption is always that it's a people problem - wrong hires, bad process, too many meetings. It's not about tech debt, it's not about whether you've got a monorepo or microservices. It's simpler than that - nine times out of ten, your engineers are scared to change things.

The system that worked fine when you had three engineers deploying to 100 users is now a liability with fifteen engineers deploying to 10,000 users. You've scaled the team but the stakes have got much higher and your team's knowledge is much more scattered, and now everyone's afraid to knock over the house of cards.

The fear tax

When it's risky to make changes, teams slow down. Obviously. But it's not just the deploy process that gets slower - it's everything.

Every deploy gets batched up with loads of changes because deploys are painful. Which makes them scarier. Which makes teams batch up even more changes. A vicious cycle. The team gets bigger but ships slower. They avoid refactoring. Bold architectural changes get shelved. You have talented people being conservative because the cost of failure is too high.

I've seen this at companies growing fast - new engineers joining every week, user numbers exploding, everything feeling fragile. Brilliant people given access to systems where making changes is terrifying.

Breaking the cycle

What changes everything isn't hiring more carefully or adding more process. It's systematically removing the fear.

• Automate everything: if you want something done consistently, don't rely on checklists and documentation - make it happen automatically. This goes for tests, accessibility, security, everything you possiblity can.
• Detect when things are broken quickly: Engineering should be the first to know when something is wrong - if your customer happiness team or your CEO are telling you about problems then you've got work to do. Implement monitoring for all the vital signs, trigger alerts on anomalies, try canary deploys so you can detect issues early.
• Feature flags: Add feature flags so you can roll out your new features progressively and leave the flags in so you can dark mode functionality if its causing issues. Also, consider using feature flags to be able to disable (with reasonable fallbacks) calls to third party services or internal APIs if they are misbehaving.
• If you do make a mistake, make it easy to escape: Make sure your deploys are quick and you've got an automated roll forward/back strategy. If the above fails this can save your sanity/revenue/users.

Each safety catch you add means the team moves a little bit more confidently. Deployments go from nerve-wracking events to routine operations. This is a huge win for onboarding new starters and means you can successfully hire less experienced engineers. If it's hard to break things they won't nervously wait for senior engineers to help them, they'll just get busy and do stuff.

This is a solved problem

This isn't new - any engineer that's worked at a reasonably mature company knows what this looks like and there's huge ecosystems of tools to help. Companies like Netflix built their entire infrastructure around safe, fast rollbacks. Feature flag tools like LaunchDarkly, Unleash, and Flagsmith let you kill problematic features instantly. Static analysis tools like Semgrep and Snyk Code catch vulnerabilities before they ship. OWASP maintains a list of what these tools catch.

You'll see all of this at mature companies like Stripe, which processes 1,145 pull requests per day with minimal downtime.

Build the machine

So, if its so obvious, what's the point of this post? I want to tell you that you need to do this work early. You're a hungry startup so you want to ship feature after feature but what you really need to do is build the feature shipping machine. Then you can ship fast and keep shipping fast as the team scales. Do it now.

When you add AI agent based coding into the mix this becomes even more critical. This is exactly why Tom's work that I wrote about recently is so compelling. He built a complete safety system - tests, CI/CD, security scanning - that lets AI make bold changes because the guard rails catch problems early. Without that infrastructure you're going to vibe code yourself into a deep dark hole.

The same principle applies whether it's humans or AI writing the code. Safety isn't about preventing change, it's about enabling it.

When you get the safety infrastructure right, deployments become boring. And boring deployments are the dream. They mean you're moving fast, shipping confidently, and your team can focus on building great things instead of being paralysed by fear.

Safety isn't about being slow and careful. It's about being fast and confident.

Alright, everyone - I'm normally a hype train avoider and as such have avoided a) talking about AI and b) breathy enthusiasm on this blog. Well, that's about to change - this stuff has me hyped. Brace yourselves...

Recently, I've thinking lots about how AI will revolutionize the workflow of cross-functional product development teams. But most of the examples of products being developed so far are hypothetical simple prototypes built from scratch - interesting possibilities sure, but nothing that can proves out how these workflows can be used to build real living products.

Friend and fellow Tweep Tom Ashworth just published an incredible post on his Substack that changes that and it's left me incredibly gassed about the possibilities. It's a detailed breakdown of using Claude Code on a real project that's conveniently open sourced so the repo is full of useful working examples. The post does an amazing job of solidifying those hypotheticals into something that's could be effectively applied to product teams right now. This isn't just another "look what AI can do" tech demo. It's a living case study of AI iterating features on real production code with real users.

Beyond the prototype theatre

Here's what makes Tom's writeup different: this isn't throwaway prototype theatre. This is a production application with users, tests, CI/CD, security scanning, and all the boring infrastructure that makes software actually work. What he's outlining here is a complete sandbox and workflow that allows AI to take the reigns and ship big changes safely and with a human readable audit trail.

The stats are compelling: 250+ PRs in two months, with Claude shipping 130 commits directly with Tom working as a solo developer for much of this time. What Tom's demonstrated is something the industry desperately needs to see: AI working with legacy constraints, technical debt, and existing systems. Not building a todo app from scratch, but navigating the messy reality of maintaining software that already exists and must continue to work for users at all costs.

The cross-functional revolution

But here's the bit that really has me excited: non-technical team members shipping features directly. We're not talking about non-engineers vibe coding themselves into oblivion - Tom's sandbox turns this into a reliable process that actually empowers non-engineers without nuking the code base. Claude Code and it's integration with Github issues does the heavy lifting but it's the totally of the system he's put together that really brings it home.

Tom's brother Louis put it perfectly: "As a non-techy person with strong opinions, it blows my mind that I can put a set of instructions into GitHub and have Claude turn it into something."

The cool part about this is that alongside all the automation, there's a very familiar workflow that allows engineers to stay in the loop. Features still go through PRs, code review, and the normal safety checks - but the initial implementation can come from anyone on the team.

If your PM can describe a feature requirement and have it implemented directly? If your designer can specify interaction patterns and see them built immediately? That's not replacing engineers - that's augmenting the entire cross-functional team.

Things are about to get crazy

Tom's work is a preview of how product development is about to change. We're moving from a world where engineering is a bottleneck and a feature factory to one where engineers build the very engine that delivers product iteration.

But this is just the beginning. The same AI revolution that's enabling direct feature implementation will power reactive data insights, AI-generated experiments, self-diagnosing incident handling, and countless other workflow improvements. Modern cross-functional teams are about to be supercharged across every aspect of product development. Even small cross-functional teams are about to become incredibly potent.

The teams that figure this out first are going to have a massive advantage. Not because they'll have fewer engineers, but because they'll be able to turn ideas into reality quickly and iterate on those ideas safely at lightning speed.

Huge props to Tom for his post and the work he's done. It's been a real eye opener.

I first became an engineering manager while at Twitter. Like most new managers, I knew nothing about the role. Fortunately, Dick Costolo, CEO at the time, personally ran a class for new managers - and my god, I needed it.

One part that burned itself into my mind is regarding something that every manager dreads - delivering difficult messages. Whether it's a layoff, some difficult feedback, a disappointing performance review - this is where you can make or break relationships with your team. Dick's message:

Your job is to deliver the message, not to make them feel better in the moment.

Optimise for clarity.

This sounds blindingly obvious and is written about in mountains of management literature but still, in my experience, too many managers do the opposite. They care about their team (good!), and they want to soften the blow (understandable), that instinct often undermines your objective - that they've actually understood the message. That's categorically not showing care for that person.

Here’s how to do it properly:

DO:

• Deliver the message clearly. Fewer words are better. Ensure they understand the message.
• Own the decision and explain why this is happening.
• Answer questions about what it means for them. Ensure they know what happens next.
• Once you've done the above, end the meeting.

DON'T:

• Get drawn into litigating the decision.
• Pass the buck - you are delivering the message, it's your message now.
• Draw out the meeting by adding uneccessary commentary or platitudes.

Let them process. Give space. Follow up later—maybe with others—to support them through whatever happens next.

Most managers and tech leads consider an important part of their role is being the "shit umbrella" — standing in the storm, catching all the crap from the wider org so your team can “just focus.” It sounds noble but it's a huge mistake that's going to prevent your team from really excelling and growing in their careers.

That “shit” you’re shielding them from? It’s not always clean, coherent strategy. Sometimes it’s noise, politics, panic. But there’s always signal in there — priorities, objectives, context, product knowledge, user needs. And if you keep filtering it all out, your team never learns how to find that signal themselves.

You’re not protecting them — you’re holding them back.

Worse, you start building a little fortress. A loyal, tight-knit, insulated team who sees the rest of the org as them — irrational, chaotic, maybe even hostile. And sure, they love you, their heroic umbrella manager. But that kind of us-vs-them culture is a bug, not a feature. It quietly erodes trust, slows collaboration, and eventually poisons the org.

The ability to handle ambiguity, navigate conflict, and interpret messy context isn’t just a nice-to-have. It’s the difference between a senior/staff engineer and someone who tops out early. This is their growth path. Support them - don't protect them.

So stop being an umbrella. Be a conduit. Get them into the conversations. Help them ask sharper questions, see broader context, work across boundaries, handle conflicts and remove ambiguity.

This is how your team kicks more ass and gets promotions. Put the umbrella away.

The other day I found myself confronted with that image of Elon Musk walking into Twitter HQ carrying a sink, with the caption "let that sink in." It was a moment of peak tech CEO dickheadery which I really didn't want to be reminded of, but it got me thinking about a common mistake many of us make when joining a new company: bringing in the kitchen sink from our previous jobs.

The problem with transplanting processes

When you join a new company, it's tempting to immediately introduce the tools and processes that worked well in our previous roles. On the surface it makes sense - you've worked in teams like this and your old company has a load of processes and tools that work well - may as well just use those. It's not the easy win that we might think it is.

Bringing over processes without understanding the existing context can lead to several issues:

• Every team and culture is unique, and what works in one place may not work in another
• Less processes and less tools are always better - solve the problems you have, don't add the baggage of problems you might have in the future
• You'll likely create resistance from team members who feel their ways are being dismissed - we've all met the "when I was at Google/Meta/Microsoft..." bore

A better approach: Listen first, then solve

Instead of bringing in the sink, establish good feedback mechanisms first. If the team doesn't already have regular retrospectives, start there. These create a space for the team to identify their own problems. Get into a cadence of solving problems as they arise with solutions that are directly relevant to the current context. Maybe the best solution to one of those problems is something you've used from a previous role - I'm not saying that you need to reinvent the wheel - but now you are in a position where you can fit that solution to the current context.

The next time you join a new team, remember Elon and his stupid sink. Instead of letting your old solutions "sink in" take the time to understand your new environment, establish feedback loops, and only then introduce changes that address those specific needs. Your solutions will be more effective, and you'll build trust rather than resistance.

If you’ve even been glancing at the startup/tech community you will not have missed Paul Graham's recent essay, Founder Mode, and the enormous amounts of surrounding commentary. It makes some sharp observations about the challenges founders face as their companies grow. It’s a great read and, of course, the problems are real but I fear the message to founders reads too much like: you are the founder, you know best, you must micromanage for victory. So, here’s my steaming hot take * - enjoy.

Running a company is bloody hard, especially if it’s your first time

First, let’s put something pretty important out there: most founders have never led a large organization before. They’re learning on the job, often for the first time, with limited time and the stakes are HIGH. In an ideal world, the founder is able to communicate the company’s vision and goals perfectly, hire the right set of execs to enact that vision and be on exactly the same page as them so they make decisions perfectly in line with that vision. That doesn’t happen - and this is the source of the pain that Paul Graham describes.

Leading at the org level requires skills that even veteran execs struggle with—things like clearly articulating vision and goals, giving feedback, performance management, and understanding the health of your organization but founders are thrown into these challenges mostly without prior experience. And, understandably, many of them feel imposter syndrome hard.

To scale their influence and fill skill gaps, they often hire experienced execs but hiring senior leaders is a skill in itself, and one most founders haven’t mastered yet. Without the experience (or even time!) to assess candidates and onboard them in a way that aligns their goals with the founder’s vision—it’s easy for divergence to creep in. You may have hired the greatest CMO in the world and they may confidently believe they are crushing it but if they’ve got a different idea of success you’re going to hit the rocks if you treat that part of the business as a black box. So is the answer to just roll your sleeves up and do it yourself? That’s tempting - but how about another approach?

Founder mode is about the details

For me, founder mode isn’t about addressing this pain by wrestling the controls out of your team's hands and going full micromanager. It’s about embracing the fact that you are the only one that truly understands your vision and, while you develop the skills to communicate that vision well, you are going to need to find ways to scale the company while keeping it true to your vision and remaining in a position to observe and deal with tactical issues as they arise.

It’s a balancing act.

Trust your team - If you micromanage and run a low-trust organization, your team will never surprise you—and this is not a good thing. They’ll stick rigidly to your instructions, fear going out on a limb and the company will stall because you’re the bottleneck for every decision. But if you trust your team, they’ll feel safe to experiment, innovate, and bring ideas you’d never think of. This is where your organization becomes more than the sum of its parts. Facebook’s early success came from empowering many people in the organisation to go ahead and ship - today, Meta still feels like a loosely knit collection of startups which is pretty impressive given its size and org complexity.

…but never lose sight of the details - Trust doesn’t mean treating your business units like a black box. As a founder, you need to stay deeply connected to the details. Talk to the people working directly with customers and building the product. Ask questions. Not to micromanage, but to understand. Feed what you learn back into the organization to sharpen how you communicate your vision and goals. You don’t need to do everyone’s job—you just need to understand enough about their challenges to lead effectively.

Vision and goals can often get abstract if you approach them from a top down perspective but can be viscerally highlighted by a founder’s detailed observations of operations on the ground.

A great example of this kind of leader is Will Shu, co-founder and CEO of Deliveroo. Even as the company scaled, Will kept himself grounded in the details. He delivered orders, took support calls, chatted with restaurant staff on busy nights, riders on the street, and engineers in the office. By staying connected, he was able to keep refining and communicating his vision, ensuring the whole team moved in the same direction. However, fundamentally he trusted the team to deliver.

For instance, Will spending a night delivering orders would result in him chatting to our dispatch algorithms team and telling them about how our algorithm would send him up a giant hill but only give him 5 minutes to get to the restaurant before the food gets cold. This kind of feedback highlighted ways the team can greatly improve the experience for riders and for the end customer but the team ultimately owned the solutions. ** There’s a great interview with him here where he discusses his approach.

So, in conclusion, I agree with Paul - founder mode should not be standard exec manager mode. You have a unique viewpoint and role in the company - learn to use that wisely. However, as your business grows, you’ll need to scale your team and a team that scales well is a team that has your trust, so don’t mistake founder mode for micromanager mode - get down in the weeds and use that insight to keep your team on track and react quickly to challenges as they arise.

* I’m not a founder of a unicorn startup but I have worked with several. My word is not gospel but comes from what I believe is a valuable set of observations. Read the following with that in mind.

** This exact event may not have happened but this kind of feedback loop was common.

While digging around in my notes app I found this old essay from my time at Meta Reality Labs that was originally posted internally. We were right in the middle of a team wide planning cycle and, as always, things were getting tense. At the time, we were using the very popular P0, 1, 2, 3, 4 system for prioritisation and, in a way that's probably very familiar to you all, everything was P0...

Everything is P0

There are always way more things that we should/want to/need to do that we have time for on any project that is worth doing. In fact, if you are struggling to think of things to improve/fix on your project it’s a very good indication that it's dead. Picking the most impactful thing to spend your time on at any point in time is the most important decision we all make every day.

Do we work on this thing or that thing or split our time or put 50% of our time into both? The hard fact here is that this is a zero sum game - if you spend time/money/resources on one thing you are not spending on something else. Making decisions on what to focus on is really hard and there’s often lots of things that add noise to this process; comment from leadership on random Workplace thread, partner team loudly requesting help, you like working on a certain problem, the list goes on.

The tool we often use to make this decision is some notion of priority. Given we’re in an OKR driven org the definition of priority is pretty clear:

Priority is the amount of positive impact we expect a given item to have on reaching our objectives.

We’re going through org-wide planning right now and we’re all finding ourselves looking at a hell of a lot of P0s. To take a planning document that’s open in my browser at random (not picking on this in particular but I think this is representative) There are 342 P0s, 96 P1s, a single P2 and finally, 17 P?s. Here’s a handy pie chart of that to annoy [data scientist on the team who hates pie charts].

Here's a handy key:

• P0 - We think its valuable and would like to do it at some point in time period X
• P1 - We aren’t completely sure of its value yet and probably won’t do it in time period X
• P2+ - Dream on, dreamer.

This system does have some utility. It points out what a given team thinks is valuable and intends to do in the given time period but it’s got some big limitations.

It doesn’t help us make decisions as to which P0 to work on now

What to work on right now is, as I mentioned previously, the most important decision we’re all making day to day. If there’s more than one P0 (or ~75% of all things are P0!) then you’ve got no extra information to determine what to work on next and worse still, if everything is the same critical priority then you may feel compelled to work on many of them at once. Doing 10% of ten P0s is definitely less impactful than doing 100% of one P0. P0 can be a focus killer.

It lets us pretend that we’re not playing a zero sum game

If you are spending time on one thing then you are not spending time on another thing. If you are trying to do two things at once they will both end up 50% done (or less - context switching has a cost). However, we can add as many P0 as we like. How many P0s is too many P0s? We can’t know. The only question we can try to answer is what is the most impactful thing to do next.

Another situation which comes up is the tie breaker. For example, a dependency comes in from another team which would mean that we would spend less time on other team objectives so there’s some discussion as to whether it should get added to the roadmap. Eventually, these kind of tie breaker situations end up with leadership and we ask them “Is this dependency really a P0?” and the answer is normally effectively “Yes, it is P0 and put it on to the big pile of P0s”. We’re not putting them in a position to answer the question effectively. There’s no way for them to make a trade off when we don’t clearly present them with that data.

We need to give ourselves the right tools to figure out what the best thing to do next is.

So how might we fix that?

Ps out, lists in

For anything task related in our teams we should discard the Ps and use ordered lists. This should include objectives, task boards, roadmaps and everything else where we might spend resources on one thing rather than another.

Why?

It constantly reminds us that we are playing a zero sum game

You add a work item to a list. The other stuff moves down and maybe some stuff drops off the end. You can’t stop it, that’s how lists work. No, you can’t put two items on the same line of the list, you scamps :) This allows us to make very conscious trade-offs between work instead of deferring or even ignoring that thought process. A new dependency comes in - does it go above or below this other critical item? It forces us to ask the questions to make a real choice every time and helps us explain to others who might be championing a certain work item (eg. a team with a dependency or QA with a bug report) how we have prioritised it and gives them an opportunity to discuss that decision with us. In cases where a tie breaker is required it helps us offer a more crisp decision to leadership: do we work on this first or that first? We can add this item to our roadmap but it increases the chance that some of these other projects might slip this half, are you okay with that?

It tells us what to do next

Working with lists is simple. Take the work item on the top, “ask can I meaningfully contribute to this” if so, work on that, if not look at the next item on the list and repeat. There’s a lot of reasons why we might not be able to contribute to the top item. It might be blocked in some way, maybe there are enough people working on it already and you don’t think that you’d be able to help ship it faster, maybe you don’t have the skillset to contribute to it. That’s fine but the result is that we are broadly working to make sure that we put 100% effort into whatever item is at the top of the list at any point in time and if we’ve ordered correctly that means that we are always put maximum effort into the thing we think has the most impact. We’re no longer feeling compelled to put 10% effort into the 10 P0s on our roadmap at the same time.

When do we reorder, add or remove items? All the time.

We constantly learn new info that changes how we think about the impact of projects and (hopefully) we constantly think of good new ideas. The list should be living and constantly changing as we learn more.

So yeah, Ps out, ordered lists in. Who's with me?

One thing that isn't spoken about enough is that being an engineer at a startup is it's own unique discipline - it's almost completely unrelated to the kind of role you'd have in a company like Google or Meta. Before you accept a role at a seed or series A startup, it's worth knowing what you are in for and what it takes to really excell at it. Having been round this particular merry-go-round more times than is healthy, I thought I'd write a few notes which you might find useful:

Options > Salary

When it comes to rewards, make no mistake - you are here for the stock options (and the learning). Startups are extremely constrained by their cash burn so you'll struggle to get an amazing salary BUT what startups have a lot of is stock in the company. It's not uncommon for seed stage companies to be giving you well north of 1% of the company's equity in stock options. It's a big risk but if you believe in this company then you can walk away with a life changing amount of money. Negotiate hard on the options - it's good for you and the founders - you're all motivated to make this thing work.

Know the product and customers

It's blindingly obvious but the lifeblood of a startup is it's product and customers. It's so tempting, as an engineer, to get wrapped up in some sidequest (choosing the best framework, putting together a state of the art data pipeline etc etc). Get to know the product in detail, get to know your customers - spend time doing support, dig into the data, look at competitors, become a customer! - find a way to become obsessed with the product and if you really can't then consider finding another company.

You're the expert now - Act like it

One thing I've seen a lot is engineers joining startups having a huge crisis of confidence. You need to realise that this whole company is a group of people who are winging it for most of the things that they are doing - chances are they hired you because you know more than them about a lot of things so don't wait for reassurance and sign offs - just roll your sleeves up and and start shipping stuff.

Be scrappy, really really scrappy

A successful startup is constantly doing things that don't scale. Don't get caught up building some amazing architecture that encompasses all kinds of invented future possibilities. Fixate on what the company needs you to do to get to the next step and just work on that. Don't introduce any tools or processes unless they are solving a present problem. Don't solve problems you don't have. Put out the fire, then move onto the next thing.

Be a jack of all trades - but prioritise

You might be surprised to find that you might spend a large proportion of your time at a startup doing things that are not in your job description. If you are a front end engineer, you'll be writing back end code, but you might also end up being the adhoc network engineer or jumping in on customer support or organising the holiday party or collecting the milk or ... well, anything. Always protect your own time and energy so that you are working on the highest impact thing you can but sometimes that high impact acitivity will not be writiing code - go with it. Don't be a afraid to wing it, just get involved. On top of that, you'll learn a ton.

You are all in it together

When you join a startup, think of it as becoming one of the founders - you all own part of this company after all. The really exciting thing about this is that you can be a part of shaping everything about this company from the product to the culture and everything in between. Own the whole thing - if something is broken, don't wait for someone else to fix it or get all blamey - gather a crew and figure it out. The thing that always amazed me is, even in a huge company like Meta, the imprint of the early employees is still there - fundamental ways of working and thinking haven't just come from Zuck and the leadership.

I got a huge amount out of being part of startups, it's taught me enormous amounts, it's introduced me to amazing people and it's given me the opportunity to achieve some things I'm truely proud of. However, it's not for everyone. It's definitely going to hurt - stress, overwork, fear and uncertainty are all a thing. Hopefully, now you have an idea of what it takes to do it well and can dive in and make the most of it if you decide to take the plunge.

So, you’ve just got a new job as an engineering leader. Starting any new role can be massively nerve wracking but throw in the fact that you are going to be a bunch of these people’s manager and the stakes get really high. How do you turn up on the first day being the biggest noob in the company but somehow gain some credibility with your team, your peer leaders and everyone else in the company? YMMV but here’s a few things that have worked for me:

Pre-game

Make time to go for a few lunches/coffees with your new coworkers before you start. In priority order: your incoming directs, your product and design peers, your manager. Don’t talk shop, get to know each other. Keep it to no more than 3-4 of you rather than one of those long table new starter lunches where you can’t chat to everyone properly.

Really get to know the product

No matter what it is, become a customer of the product as much as you possibly can before day one. Post starting, dig into how the whole company works - doing some customer support is a good place to start, talk to someone from every team (not just the team leads), bust out your SQL skills and build some dashboards, **deeply understand the company’s key results **and how they are measured. You need to know why customers choose your product, what success looks like for the company and every step it takes internally to deliver that product successfully. That’s waaay higher priority than anything technical.

Tell your team what you plan to do for the first weeks and stick to it

Being a leader is weird because there’s very little precedent for what you actually do day to day. Even though the team might be cautious of their new manager they’ll probably add you to all possible meetings and expect you to take the reins on everything. Mitigate this by being really explicit about where you will be and what you will be doing. Most importantly, stick to it - we’ve all seen that old doozy when a new manager turns up and says “I’m just going to listen” then starts a re-org three days later - don’t be that person.

Actually shut up and listen

Talk to everyone 1:1, sit around the office in lots of different places and earwig, lurk in all the slack threads. Yes, go to meetings but be careful with that - especially if you are senior, your presence is a signal. Also, it’s easy to get dragged in to opinionating too early. Try to be the one asking most of the questions but you will be asked what you think about everything - you are in a unique position of having fresh eyes so your feedback is useful but hold those opinions loosely….and don’t, whatever you do, go on and on about your previous job/company. Everybody hates that.

Help out, accrue brownie points

After you’ve done a load of listening you’ll have heard of lots of frustrations, wants, needs etc. Pick something to help with and get it done. Don’t do anything that is at all controversial or requires some decision making/judgement on your part. Find something that someone wishes was a thing, and do it the way they want it doing. Fix a long standing annoying bug, make that tedious spreadsheet, chase that laptop upgrade for a team member, fix that annoyance that came up in a retro. At Twitter UK, I chased the table tennis table people wanted for the lunch room, at Deliveroo, I got everyone’s employment contracts updated so they had a more competitive number of PTO days - which also later helped recruiting. You get to learn a bit about how the company works while accruing some low key goodwill.

Don’t mess, even if it looks on fire

I hear of so many tales of leaders joining a company, telling the team they are “just listening”** **but then discover something that they believe is a fire and could be easily fixed and diving right in. Don’t do it. Every company and team is different - if it was easy they’d have probably fixed it already. Just listen, help out, but keep your greasy mits off the steering wheel for now.

Alright, hope that helps. I’ll likely follow up with a “what to do in the first few months” post soon.

I’ve had danwebb.net since 2000 and in the mid 2000s my old blog even got fairly popular amongst web developer types. In fact, it was a factor in me getting hired by Twitter back in 2010. Since then, like many early noughties personal blogs, it’s fallen silent as we all went to Twitter to shout into the void instead. This was all fun and games until the void started shouting back.

Fast forward to 2024 and I’ve been thinking the time is right to get it going again. I’m lucky enough to have a pretty varied professional life at the moment where I spend equal amounts of time as a startup founder, a polyglot programmer (jack of all trades, master of none, if I’m honest) and a technical leader. I’ve learnt from some amazing people, I’ve made some mistakes and learned from them and I’ve seen a whole load of crazy tech industry shit. This all adds up to a certain amount of wisdom/entertaining anecdotes.

Alongside building Existent and its team, I spend quite a bit of time advising startups who want to build outstanding engineering teams sometimes as an angel investor, sometimes for friends and sometimes as an independent advisor. It’s becoming clear to me that I repeat myself quite frequently so I’ve decided to commit some of this stuff to Markdown in the hope that someone might find it useful, at the very least, it’ll be useful to me.

So, the plan is, I’m going to write some bite size posts here on this blog and cross post them to Linkedin. There’s gonna be a lot of tech leadership, a little bit of technical stuff and a smidgen of startup waffle. If you like it, either follow me on linkedin or grab the feed and put it in your retro hipster feed reader of choice.