How Technology Teams Actually Work

In the last session we looked at the cast of characters – engineers, designers, product managers, QA testers, data scientists. Interesting people, but left floating like pieces on a chessboard with no game in play.

Today we’ll put them in motion. This is the **Software Development Lifecycle** – or SDLC if you want to sound clever. It’s the plumbing that turns bright ideas into working software. It’s messy, political, and faintly absurd, but it’s how the sausage gets made.

The Process

This is where product managers, designers, and researchers try to figure out what problem is worth solving. They interview users, draw journey maps, and invent acronyms. The aim is to make cheap mistakes early, rather than ruinously expensive mistakes later.

Why it Matters

Because guessing is expensive. Discovery stops companies from building brilliant things that nobody wanted. It prevents the kind of spectacular, multi-million-pound failure that is so delightful to witness in others.

Day in the Life (PM in Discovery)

• 9am: Join a video call with three customers. Each one describes your product as “confusing.” Your soul shrivels a little.

• 11am: Workshop with designers: move boxes on a whiteboard until everyone nods. Progress is measured in centimeters of marker.

• 2pm: Write a ‘user story’ about a fictitious customer called ‘Sally’ who is somehow both 23 and 59. She needs to buy a cat flap but finds the font uninspiring.

• 4pm: Present findings to execs. Execs ignore them and ask about the color of the cat flap instead.

The Process

Designers build wireframes and prototypes – fake versions that trick users into giving useful feedback. They argue over fonts and button positions. These prototypes are inevitably thrown away, but the learning survives. This is a crucial distinction, as it is a deeply satisfying way to spend time while creating nothing tangible.

Why it Matters

It’s a fundamental law of the universe that it is cheaper to move pixels than to rewrite code. Good design reduces confusion, bad design creates support tickets and an inordinate amount of existential dread for the support staff.

Day in the Life (Designer in Prototyping)

• 10am: Open Figma, rearrange the same five screens for the seventh time this week. Stare into the void.

• 1pm: Run a user test: watch someone ignore the giant ‘Next’ button and click the logo instead. You wonder if humanity is a failed experiment.

• 3pm: Debate whether a shade of blue is ‘friendly’ or ‘corporate.’ The fate of the entire project hangs in the balance.

• 5pm: Hand off mockups to engineers, who immediately ask “but how does this work?” Your soul shrivels a little more.

Engineers take the prototypes and build them for real. This is where the magic happens, which is to say, a lot of shouting and swearing. The process is never quite as elegant as it looks in a PowerPoint presentation. Different approaches, or methodologies, have been invented over the years, each one a reaction to the painful shortcomings of the one that came before.

Methodology 1: The Waterfall Method

This is the classic approach. It’s linear, rigid, and sequential. You spend months (or years) meticulously planning and documenting every single detail of the final product, then you build it all at once, in a grand, final act of defiant hope. It is a monument to human hubris.

The "Why"

In the long, dark history of human bureaucracy, planning everything in advance has always sounded like a sensible idea, despite all evidence to the contrary. It provides a comforting illusion of control and is a great way to justify a massive budget upfront.

The Pros (and Cons)

It's wonderful for projects where the requirements never, ever change (i.e., projects that exist only in the fever dreams of project managers). It’s also very easy to explain to executives who believe a good plan is a finished plan. The catastrophic drawback is that the world, and your customers, will change while you're building, rendering the final product an expensive, beautifully-designed digital dinosaur.

Methodology 2: Agile

Agile is the chaotic, messy, and infinitely more sensible reaction to Waterfall's spectacular failures. It’s a process of building and releasing in small “sprints” of a few weeks at a time. It’s less a plan and more a series of controlled explosions, punctuated by a lot of frantic communication.

The "Why"

Because customers don't know what they want until you give them something they don't want. The core philosophy is "fail fast, learn faster," which is a noble but often terrifying sentiment. It's about course-correcting at light speed before you've sunk too much money into a bad idea.

The Pros (and Cons)

It's magnificently flexible. It adapts to change. It produces working software more often, so you can start making mistakes and learning from them almost immediately. On the other hand, without strict discipline, it can devolve into a confusing, frantic mess. The term "Agile" is often used to justify a complete lack of planning, resulting in teams that run very fast in circles while screaming things like "sprint velocity" and "daily standup."

Methodology 3: DevOps

DevOps is the elegant, automated offspring of Agile and a deep-seated hatred of manual labor. It's about bridging the gap between developers (who write the code) and operations (who run the servers) so that the code can be shipped instantly, continuously, and with minimal human interaction.

The "Why"

Because humans are a profoundly unreliable species. They make mistakes, they need to sleep, and they resent doing the same thing twice. DevOps is a philosophical argument against human error, and a technological crusade against boredom.

The Pros (and Cons)

It offers blinding speed, unprecedented reliability, and the profound satisfaction of knowing that a new feature can be live on a server in less time than it takes to make a cup of tea. It is, however, a complex, baffling system to set up, and when it breaks, it breaks in a new and spectacular way every time. And there's still a human at the beginning who has to write the first line of code, so the risk of failure is never truly eliminated.

Day in the Life (Engineer in a Sprint)

• 9:30am: Stand-up meeting. Everyone says what they did yesterday. Everyone lies. The meeting ends, and a collective sigh of relief can be heard across the office.

• 10am: Pair programming: spend 30 minutes arguing about variable names. This is what we call "team building."

• 1pm: Fix a bug that only appears on the CEO’s iPad. It is a bug that you are sure you fixed a week ago. You contemplate an easier career, like lion taming.

• 3pm: Review a teammate’s code. Spot a clever trick. Quietly steal it. This is how we all learn.

• 6pm: Finally get your feature working. Realise QA will break it tomorrow. Go home and enjoy a well-deserved glass of something strong.

The Process

QA testers and automation engineers write tests, click everything, and try to break the system before customers do. They assume everything is broken until proven otherwise. A truly noble and deeply unsettling way to live.

Why it Matters

Because users are chaos embodied. Someone will inevitably paste an emoji into a postcode field and crash the system. QA ensures that doesn’t happen. They are the guardians of digital sanity.

Day in the Life (QA Tester)

• 9am: Kick off 2,000 automated tests. 37 fail. Panic ensues. You are filled with a strange sense of vindication.

• 11am: Manually test the new checkout flow. Discover it charges £0.00 for everything. You have a quiet moment of existential dread.

• 2pm: File a bug report so detailed it could double as a novella. You are a chronicler of digital failure.

• 4pm: Developers insist “it works on my machine.” You resist the urge to scream. You know it is a lie.

The Process

Getting code live is its own science. Modern ops uses:

• Continuous Integration: test every change as it’s written. A sort of digital sentry.

• Continuous Delivery: ship automatically and often. A continuous, nerve-wracking process of pushing the machine to its limit.

• Blue/Green Deployments: two versions live at once, so you can instantly flip back when it breaks. A bit like having a spare set of underwear ready for when the inevitable happens.

Why it Matters

Downtime costs money. A single hour of outage can cost millions. And investors, as you know, dislike millions evaporating into the digital ether. It's considered bad form.

Day in the Life (DevOps Engineer)

• 8am: Pager goes off. Something is down. Coffee is not optional. You feel a familiar, cold dread.

• 10am: Automate yesterday’s deployment steps so humans never repeat them. You are a tireless machine dedicated to making other machines work.

• 2pm: Run a chaos test: deliberately crash a server just to check resilience. A fun game of "let's see what happens."

• 4pm: Watch dashboards. Everything green. Relax… until 4:05 when it all goes red again. You are a prophet of digital disaster.

The Process

Security engineers play the role of burglars. They run penetration tests, patch vulnerabilities, and lecture developers about not storing passwords in plain text. A thankless task, as they are paid to assume that everyone is out to get them.

Why it Matters

Because one breach can kill a company faster than slow sales ever could. Regulators and lawyers are merciless. And the news cycle is even worse.

Day in the Life (Security Engineer)

• 9am: Run vulnerability scans. 57 warnings appear. Only 2 matter. You sigh with the weary resignation of a person who knows the world is a dangerous place.

• 12pm: Try to hack into your own system. Fail. Succeed. Fail again. A constant, existential struggle against the machine.

• 3pm: Train developers on secure coding. They nod politely, then ignore it. You are a prophet without a following.

• 5pm: Read news of a competitor’s data breach. Quietly enjoy schadenfreude. It is a small and simple pleasure in a world of complex and terrifying problems.

The Process

Once live, the system emits endless data. Data engineers build the plumbing, analysts make dashboards, data scientists build models, and AI engineers create chatbots and recommendations. A truly baffling and exhausting process.

Why it Matters

Data tells you what actually happened. Without it, product is flying blind. It’s like trying to navigate the cosmos with no more than a vague sense of direction and a strong belief that you are going the right way.

Day in the Life (Data Scientist)

• 10am: Pull sales data. Discover half the rows are missing. You contemplate a career in bricklaying.

• 12pm: Train a churn model. Accuracy: 53%. Useless. You realize the machine is as baffled by human behavior as you are.

• 2pm: Tune hyperparameters until accuracy rises to 84%. Champagne corks pop. You are a god among men. For a fleeting moment.

• 4pm: Present findings to execs. Execs ask “but what does it mean in pounds?” You are a prophet without a currency converter.

The Process

Product reviews the data, redesigns the roadmap, and the cycle begins again. Discovery → design → build → test → release → measure → back to discovery. A never-ending, beautifully chaotic dance.

Why it Matters

Because no plan survives contact with customers. Iteration is survival. It is the fundamental law of the digital universe that the thing you thought would work will not, and the thing you thought would fail will be a resounding success.

Day in the Life (Product Manager in Iteration)

• 9am: Review dashboard: nobody uses the feature you fought for last month. Your soul shrivels a little more.

• 11am: Call engineers to ask for a pivot. Hear deep sighs. You are a conductor of a very tired and very grumpy orchestra.

• 2pm: Draft a new roadmap. Everyone pretends to agree. A sacred ritual of polite avoidance.

• 5pm: Investors ask “when will this start making money?” You pretend to have an answer. You do not have an answer.

And that is the SDLC – the messy, looping journey from a vague idea to a working product, with plenty of detours through disaster. It is a bizarre and beautiful process, a testament to the sheer ingenuity and endless capacity for human absurdity.

Why should you care? Because this is what separates valuable companies from worthless ones. If the cycle is tight – good discovery, disciplined design, steady engineering, brutal QA, resilient ops, and useful data – then every pound spent turns into value. If the cycle is broken, you get wasted millions, angry customers, and frantic excuses. Which, conveniently, is exactly what people like me get paid to spot.