Deep Inside Facebook

Leave a comment

In this excellent Stanford ecorner episode, Director of Engineering Jocelyn Goldfein takes us on a trip inside the innovative culture of Facebook. In this illuminating conversation with STVP Executive Director Tina Seelig, Goldfein explains why code wins arguments, employees must have the right to take risks, and how Facebook strives to remain a hungry, yet humble, company.

The following is a semi-transcript of the parts of the interview I found most interesting.


Culture of Facebook

Interviewer: Can you paint a picture of the culture of Facebook?

You would experience unfinished ceilings.
Concrete floors.
Desks everywhere – no offices. Not even Mark has an office.
And writing all over the walls.
And posters.

And you would see company slogans like:

– This journey is 1% finished.
– Move fast and break things.
– Fail harder

And facebook was born out of disruption and out of trying things and seeing what happened. And trying again and trying harder. And never being daunted by failure. Doesn’t mean we set out to fail. It means we are not afraid of it. And we are willing to keep taking risks.

And the entire environment is meant to keep you from feeling complacent, or comfortable or we’ve won. We never want to feel like we have won. We are pretty hungry. And someone could come and eat our lunch tomorrow. Because somebody could. And we never want to take it for granted. It’s the most humble successful company I have ever known. It may sound strange to say that facebook is a humble company. But it really is.

We don’t take our success for granted. We think our users are choosing to be there and could just as easily choose not to be there if we don’t deliver a great service.

The Facebook workspace

Interviewer: What sort of things did people think about in creating the facebook workspace?

It’s very deliberate. It’s absolutely deliberate. You can not just think of the culture you want and then create it. Culture arises from so many small things. A professor of mine once said:

Culture is the behaviors you reward and punish.

At the end of the day, people look around, and mimic the behaviors that reward them, and avoid the ones that punish.

But you’ve also got to try and show people the behaviors you want. And the space is one of those things that sneaks under your radar as not being important. But it truly is.

When you walk on those concrete floors you know we are not finished.
We are not luxurious.
We are not taking it for granted.
We’re scrappy.

The openspace is another huge one. You know that if you program you need focused attention. You need flow time. And you know that even small interruptions takes a long time to get back into the stream of things.

And so the idea of having programmers set out in open space at open desks with desks all around with walking and conversation and foot traffic … that’s controversial. For many years it was the ‘gold standard’ in silicon valley to have offices. Engineers were housed in offices.

When we took over the campuses from Sun we told the contracts to start knocking down every wall that wasn’t structural. Got as big an empty space in the office as we could and we would fill it in from there.

And why? Why was it so important to us that we would even consider sacrificing our productivity. Which is what we are doing having everyone out in these open spaces.

It’s because one of the key values of facebook is to be open.

It’s what the product is for. It’s fundamental to our DNA as a culture too. We expect every individual to be informed and in the know about what is going on empowers you to make good decisions. And so sort of set the expectation that everything is out in the open. Everybody is plugged in and aware of what is going on.

And then we put headphones in the vending machines and try to create private spaces that way. Give everybody a laptop and have pretty loose rules about working from home policy. So we do everything we can to mitigate the productivity impact of that openness. But every time we have to choose we choose openness.

Onboarding at Facebook

We call it boot camp.
It is a six week on boarding program.
And everybody goes into it.

As the VP of Engineering at VMWare, I had not written code for 7 years and I went to facebook and they said:

Here’s your desk.
Here’s your laptop.
Here’s your unix account.
And here’s five bugs that are assigned to you to fix.

And you spend your first 6 weeks at Facebook fixing bugs and implementing small features all over the site. And attending lectures and you have a boot camp mentor who is a full time software engineer who’s job is to help you get code reviews, to help you figure out what tasks to work on. And at the end of the six weeks they will help you find a team.

I give facebooks introduction to culture for bootcampers. And one of the many great things boot camp does is build empathy. Before you identify with a particular team you fix code. Even if you want in determined to do back end services, we will make you fix some UI bugs. We will make you fix an issue on mobile. No matter what you are going to do we are going to at least give you the tools to inspect, investigate, to know, about what is going on in other parts of the world.

It really sends the message we want to send which is – engineers are connected to one another. The facebook employees is just another subset of the social graph.

And so in boot camp you hook up your social graph. With your first setup of co-workers who then spread out to the 4 corners of engineering and give you connections in every part of the company.

But you know a little bit about something of everything.

And that’s an incredible asset for a new hire.

Interviewing at Facebook

Interviewer: So what are you looking for when you interview at Facebook? I know the standards are incredibly high. How important are technical skills as well as creativity and being about to work on teams.

The number one thing we are looking for in hiring a software engineer is ability to write code. And the ability to reason, be analytical, find mistakes and fix them quickly, and to analyze the running time so later on you can demonstrate you have the potential to solve hard systems issues.

If you are a new grad, that is the primary thing.

We also want to make sure you are not a jerk. Want people at facebook who are nice. ut we want people how have enthusiasm. Have fire in their belly. Aren’t going to take no for an answer. People who are not afraid. Going to attack making software with gusto.

The reason you see so much writing on the walls at facebook is we want people to write and share things the see – good or bad.

Pop open the hood.
The cement is never dry.
You can mess with it.
You can change it.

One thing that made engineers really successful at facebook is they had really good intuition for what would be a really good feature.

The difference between good intuition and just working iteratively is that the person with good intuition will get there in three hops while the person without will take x10 tries. So we started interviewing specifically for intuition. Its something that distinguishes good from great software engineers.

Mark Zuckerberg

Interviewer: How involved is Mark in decision very granular decision making?

Mark will definitely give you advice about pixels. Mark has organized the company so he can spend the build of his time on product and product strategy. He has basically set up his calendar so that for each day of the week theres a theme, and on day the theme might be mobile, platform, and then there will be a block of 4 hours and teams just rotate through and present stuff to him and talk through it with him and it’s amazing because he is probably the most gifted product thinker in the company, and maybe in the valley, maybe in the world (that’s probably stretching it) but definitely in our space.

He so like having a half an hour of his time is just amazing. You do have to parse the advice he is giving you and know whether he has is CEO hat on, designer hat, or Product Manager hat because he can operate at some many levels of abstraction.

So, yes. He will be very involved and he has structured his time to be involved. But he can only pay attention to so many things at a time to. So if he is not paying attention, he expects you to run forward while he is not looking.

Advice for grads


Interviewer: Imagine you are flashing back in time and you are a student back here at Stanford again. What advice do you wish someone had given you?

Ah man. That’s a hard question… Um…

I think that umm… you know you hear this all the time but be brave. Like you really don’t have any bad choices you. You can’t go wrong. Now is the time in your life to take a lot of risks.

I think that ahh.. I would have said… don’t worry about what you are going to be when you grow up. Just be. It will come and find you.

I feel like, you know, when I was in highschool and college so many people were like follow your passion, follow your dream and I was like: “How do I find my passion. How do I find my dream.”

No one had particularly good advice for what to do. To figure out what you are passionate about. So I would say:

It’s OK not to know.

Just keep trying things and you will find stuff that you are passionate about and excited about.

I would have told myself not be afraid to code for a living. I was afraid to code. I was afraid that other people would be better at it than me. I was afraid that I would be buried in detail and not get to be strategic. And I learned over time that writing code is one of the most strategic things you can do. And every time I meet a college grad who wants to skip being a software engineer and move straight into Product Management I am like uh… you learn so much from writing code that the devil is truly in the details. Embrace it. Relish it. You may not end up doing it forever but every minute you spend coding will make you 1000x better at being a manager or product manager or anything else. Even if you decide you want to do something else, your time writing code will make you better for it. If you want any career in software. Any career.

This was a great interview. I highly recommend you download and listen to the audio.

Cheers – Jonathan

Examples of Microsoft not getting it right


Microsoft is in trouble. On so many levels.

This is a rant against some of Microsofts products. Apologies if it all sounds negative (Microsoft does do some excellent work – XBox isn’t bad for example).

But I am gathering anecdotal evidence towards why some people trust Microsoft software, while others don’t.

Here is a personal collection of some of the issues myself and others have had with their products, and why many of us have come to expect (rightly or wrongly) disappointment.

Snipping tool

Microsoft finally added in Windows 7 a tool for screen capture called ‘Snipping Tool’.

You run the program, click the mouse around the screen image you want to capture, and then save your picture.

And it works great. The first time.

The second time you take another picture and use the highlighter to mark up the page, it fails. Not always. But enough that you need to restart the program and capture the image all over again.

This is a simple repeatable bug that should never have happened (of could easily be patched). Argh!


I have seen the very mention of this tool send the hardest of developers diving for cover.

Never has one tool caused so much pain, suffering, and loss in terms of people’s life’s and productivity.

This tool is wrong on so many levels.

Merely installing it can corrupt your machine.
Deploying it is a bear.
It’s makes extensive use of the GAC.
It will silently fail without telling you why.

It’s just a plain old terrible product to use and work with (much like TFS).

Team Foundation Server

Name one source code repository system that:
– pessimistically locks files
– requires you to be online
– requires it’s own database,
– and takes something that is pure and simple and makes it overly complicated


This tool is terrible. When Martin Forwler asked his fellow ThoughtWorkers which version control systems they recommended to clients TFS finished near last.

Amazing how a company so steeped in software could get this so wrong.

One way to ensure you repel top talent for your .NET project is to insist on using BizTalk and TFS.

Do you have other examples?

Send me your favourites and I will credit you in an upcoming blog post about why we trust some companies software and not others.

EnterpriseZine writeup of Agile in a nutshell (Japanese)

Leave a comment

The kind folks at EnterpriseZine were kind enough to have a their star reporter Dai Fujihara write up tow of my presentations at Agile 2011:

  • Agile in a nutshell, and
  • The surprising science behind agile leadership

A big thanks to Dai and EnterpriseZine for the writeup.

You can find the original slide decks for these here and here.

Expecting failure


When building a system, you can either take the view that things are going to work, or that they are going to fail.

You need to be defensive when building systems, but you want to avoid overdoing it. When you get overly defensive, you get product out the door later and you raise your total cost of ownership by creating an overly complex, difficult-to-maintain system.

In this month’s column I want to tell you the story about how a team I was part of leaned too far in the defensiveness direction, and what we did to bring it back.

A Messaging System

The team had an architecture that looked something like this:

Messages would come in one end, and transformed messages for specific recipients would come out the other. Simple enough.

Not surprisingly the legacy system we were replacing had “issues” (mostly around things blowing up). So when it came to replacing it, there were strong opinions concerning error handling and logging. We started off expecting things to fail.

Well, it didn’t take long before we had so much error handling and logging that it became hard to see (and troubleshoot) what the system was actually doing. We were so afraid of failing that it felt like we forgot what we were building in the first place.

Why were we being so timid? Were we justified in our level of skepticism? Was all this support code and logic really necessary? It felt wrong and it felt strange. Yet we persisted.

Then one day, someone asked:

What if messages came in one end, and the correctly transformed message came out the other? What if we stopped expecting failure? Don’t accept any failures. Just make the bloody thing work. What would that mean to our approach to the system?

What a beautiful, simple, powerful question. Asking ourselves “What if it just worked?” got us looking at the system in a new light.

Instead of it expecting it to fail at every step, we now expected it to succeed.

We realized we could get rid of a lot of errors up front by simply not letting them into the system in the first place.

* What if we tightened up validation on messages coming in?
* What if we rejected all messages that didn’t conform and notified production operations instead of trying to handle it ourselves?

If we coded and tested the system right in the first place, we could fix a lot of the core problems that riddled the legacy system instead of expecting and handling them when they happened.

I know, it seems obvious now. It is obvious. But somehow it wasn’t so obvious at the time. Yet this simple, obvious shift in perspective profoundly changed how we looked at the system.

Instead of expecting failure, we started to expect success. This simplified and lightened our code base, while leaving just enough checking there to let us know if things went wrong.

No, not quite. Our systems are going to fail, and we need to handle those failures. All I am saying is that if we only focus on failure, we can really overengineer and overcomplicate things. That’s expensive, because then we need to carry the baggage of this overengineering around with us forever, making the system harder to maintain and to change.

It’s a balancing act. We do need to expect failure. We just don’t want to overengineer for it to the point where we lose sight of what we’re really doing. Which should be delivering valuable, working software to our customers.

Not wanting to leave you with just a story, I want to offer you two surefire ways I’ve seen teams harden their systems to ensure that they aren’t overly confident before rolling into production.

Work with Real Data

When you throw real, live production data at your system, good things start to happen.

1. You discover where the holes in your data model are.
2. You discover which of your assumptions are valid, and which are wrong.
3. You see what edge data cases you missed, and discover that French characters don’t always encode the way you’d expect them to.

There are few better things that you can do to see how your system is going to handle going live than to throw some real data at it. The other thing you can do is to get something into production.

Get Something into Production

You don’t have to flip the switch and really “go live” (though you obviously will at some point). What I am talking about is getting your system into production before it needs to be there.

This does a couple of things for you:

1. You can throw some of that data at it and see how it behaves.
2. You can work all the kinks out of your automated build and deploy scripts.
3. You can work out all the network and infrastructure issues.

But best of all, you get into the habit of releasing. The more you push to production, the less scary it is. Do it enough and it will soon be like breathing.

Context Is Everything

Take what I am saying here with a grain a salt. You still have to judge for yourself what level of error handling and defensiveness is right for your application.

But if you keeping things simple, and build things so that you expect them to work, you can keep yourself from overengineering a system that doesn’t need it, and while making your application easier and simpler to maintain.

Production Readiness


Something that doesn’t get talked about enough in agile development is production readiness—the practice of continuously having your code in a state where it could be deployed at a moment’s notice.

Everybody gets the importance of co-location. Most people understand the speed and efficiency that come from user stories. But rarely do I hear people talk about the importance (and challenge) of continuous production readiness.

In this article I want to get into what agile production readiness is, why it’s so important for you and your project, and what you can do to get there.

What is production readiness?

Production readiness is the practice of ensuring that your software is continuously in a state where it could be shipped at a moment’s notice.

It’s an attitude and a mindset in which the team treats the first iteration of their software as something that could potentially be shipped, and each iteration thereafter as simply updates to a live production system.

Yes. When we are not in production, there are a lot of things we don’t have to worry about.

  • We don’t have to worry about testing (can do that later).
  • We don’t have to fix bugs (can always do that before we go live).
  • We don’t have to demo our software (it’s still in development, after all).
  • And we don’t have to integrate everything together (it’s easier just to hook it all up in the end).

You can see where I am going with this.

These are exactly the kind of things that, as agile practitioners, we want to be doing early and often in our software. We can reduce a lot of risk by acting as if we had to release it every week. That doesn’t mean we do (there are probably a lot of really important features like security and validation that won’t be done in iteration one). But our attitude is we could if we had to.

What Does This Buy You?

There are a lot of benefits that come from treating your software with this kind of respect from day one.

You go faster

Maybe not initially, but once you get into the rhythm of regularly producing working software you spend less time:

  • fixing bugs
  • deploying emergency patches
  • re-writing broken features
  • explaining why your project is late and nothing works

And more time:

  • improving your customer experience
  • adding (or removing) new features
  • and wowing your customer in unexpected ways

These benefits don’t come free. You have to write tests, get feedback, and tackle tough problems early. But once you make these investments, you reap great dividends later on in terms of time and money.

It makes planning simpler

No need for shenanigans or tomfoolery with the schedule and plan. Features are either done or they are not. It removes any doubt with regard to where you are with the project, and how much you have left to do.

It reinforces the good

To regularly produce shippable code each week there are certain things you’ve got to be doing:

  • You’ve got to break big problems down into smaller, more manageable ones.
  • You’ve got to test from the start.
  • You’ve got to improve and evolve the design as you go.
  • You’ve got to get feedback from your customer.
  • You’ve got to stop and fix things when they come up (can’t just brush them under the carpet).
  • And you’ve got to get off your butt and talk to people.

All good things for any healthy, exciting project.

Going live becomes way less stressful

If you practice going live every couple of weeks, when the big day finally comes, it turns out to be a non-event:

  • You’ve automated just about everything you can.
  • You’ve hit and dealt with all the integration sore points.
  • You know who to talk to and what kind of coffee they like.
  • You’ve basically worked out all the kinks in the deployment process.
  • And it builds trust.

Not just between you and your customer. But between you and your team.

Once regularly producing shippable code becomes a habit to your team, it’ll just feel good. You are delivering something of value every week and your customer is seeing steady progress in a live system.

Note: This is not an excuse to stop thinking

And just to be clear, you can’t be dogmatic about this stuff.

You’ve got to look at your situation and context and decide what’s right for you, your team, and your project at that moment in time.

Pixar films don’t get finished. They just get released. – Pete Docter, the director of Monsters, Inc.

If I had to sum it up in one sentence: production readiness is doing enough work on a feature so you could release it into production if you had to.

And producing production ready code is hard

If I am making this sound all apple pie and puppy dog kisses, let me be the first to tell you—it isn’t. You’ve got a lot working against you.

First off, regularly producing shippable code changes how people and teams work. And not everyone is into change.

Secondly, you’ve got an industrial mindset (still alive and well in most companies) that believes that writing software is akin to ditch digging.

Then you’ve got unrealistic expectations, impossible schedules, and perverse incentives that all too regularly sacrifice the long term for the short.

But the good news is that it can be done, and lots of people (including your competitors) are already doing it. It just comes down to choice.

What You Need to Get There

Teams that regularly produce production-ready software usually have some combination of the following three things going for them.


In the heat of the battle, with all the dysfunction that comes with the work place, you are going to be tempted like never before to take the easy way out:

  • You are going to be tempted to not write that unit test.
  • You are going to be tempted to guess what the requirement is instead of talking to your customer.
  • You are going to be tempted to check in on top of that broken build (because you know your stuff works).

This is what separates you from everybody else. This is where the courage and discipline to do the right thing (often at your own personal expense) comes in.

Don’t expect much in the way of appreciation initially. You won’t get it.

What you will get is the begrudging respect of your peers (for having the courage to say “enough is enough”) and the self-respect that comes from knowing you produce quality work.

A Culture of Excellence

Some people aren’t used to an environment where excellence is expected. –Steve Jobs

Most people aren’t used to doing excellent work . The ironic thing is that most people want to do great work. It’s like they are waiting for someone to give them permission.

If this is you—permission granted.

You can create a culture of excellence by setting the bar high in the beginning and keeping it there for the duration of the project:

  • Don’t accept untested, poorly implemented features.
  • Don’t accept people abusing the build.
  • Don’t accept bugs—any.
  • Pair.

Setting the bar high in the beginning is way easier than trying to raise it later. Set it high at the start, lead by example, and keep it there for the duration of your project. Make excellence an assumption and it will soon become a habit.

People Who Really Care

I know you care about software. You are here, still with me at the end of this article, when you could be doing any of a thousand other fun things. It’s not you I am worried about. It’s everyone else.

You are going to need to find and track down more people like you—people who care about software, delivery, and excellence.

Finding, and attracting, people with this mindset for quality and craftsmanship is important, because when people care about what they’re doing the little things take care of themselves:

  • You don’t need a lot of rules.
  • You don’t need to write everything down.
  • You don’t need to be afraid.

Because the good people don’t need to be told what to do. They take initiative and do the right thing because they can’t help it—that’s just the way they are built.

Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior. –Dee Hock, founder of Visa

This is the Start

There’s a lot more we could say about production readiness. We haven’t even gotten into the software delivery practices that help us get there. But if you are still here at the end, chances are that’s not going to stop you from finding out what they are.

If your team isn’t thinking like the next iteration’s worth of work needs to be ready for battle, start fostering that culture now. It will pay big dividends later on in terms of time and cash.

And if you’re already there—good for you! Now be vigilant. Don’t get cocky. And show others how to do it. It’s a fun way to work and the more people we can get working this way the more fun it’s going to be for you and me.

Why you may find your software lacking

1 Comment

On my drive to work this morning I was listening to the excellent Pragmatic Podcast interview with Miles Forrest interviewing Uncle Bob when Miles asked Bob:

Why is it that sites like Facebook can support so many features and can be so easy to use and yet the vast majority of software systems are so ridiculously complicated and can only support a few thousand concurrent users.

“This is a very good question.” chuckled Uncle Bob.

Uncle Bob went on to explain that when you bring the people building the software closer to the people needing it good things tend to happen. Basically, agile.

And while I wholeheartedly agree with Uncle Bob’s answer, I have a few other ideas why companies like Facebook, Google, and Amazon get software right while the vast majority of us (companies) seem to get it wrong.

1. Most companies don’t live and die by their software.

For the vast majority of companies out there software is a necessary evil.

Given the choice most would rather buy their software then have to build it themselves. This attitude and lack of software expertise means most companies don’t put their heart and souls into the quality of their software and system the way say Google would.

Because these companies don’t see their software as a competitive advantage, they treat it like a deprecating asset, and let it decay over time.

2. Too many rely on QA departments.

Did you know every engineer at Facebook supports 1.2M (that’s million) users on average and they do it all without a formal QA department?

They don’t wait for someone from QA to submit a bug. Every engineer takes direct responsibility for the code they produce and works closely with operations to ensure that what they ship works, and they to support it quickly when things go wrong.

Amazon does something similar. They call it the two pizza rule.

I am not saying most companies shouldn’t have QA departments (it’s probably a good idea for the vast majority of them to be there). What I am saying is that until they start thinking about how to write software such that they aren’t needed in the first place, they are going to continue to build lousy software.

3. Too many ship their org charts.

I once worked at a start-up that had no less then six segmented, vertically sliced silos of teams each responsible for a different portion of their application. Six teams for one product.

Shipping your org chart is natural for most companies. It means you don’t have to coordinate and talk to others. You are the master of your own little silo. And your bonus certainly isn’t contingent on someone else meeting their goals.

Microsoft is currently falling prey to this. As Ray Ozzie recently pointed out in his farewell address to the company, Microsoft runs the risk of being left behind unless they can get their act together and start shipping integrated products beyond the PC. The have to stop shipping their org chart.

4. Most don’t see the value of software talent.

I know this sounds obvious but the quality of your product is directly proportional to the talent of the people you have building it. This cliche is compounded x10 when it comes to software.

Contrary to popular belief software is more then just typing.

You don’t have to explain this to companies like Microsoft, Google, and Facebook. They are currently locked in a waging war for talent. Anyone doubting the impact a single developer can have should ask Google where GMail, Googletalk, and Googlenews came from.

Google Making Extraordinary Counteroffers To Stop Flow Of Employees To Facebook

So that next time someone asks you how Google can organize the worlds data, and your company can’t seem to push a single release of their software live, check the size of your companies QA department, see if your company is shipping their org chart, and ask yourself if you truly live and die by the quality of your software.

The Indispensable Developer

Leave a comment

We’d all like to be indispensable. Unfortunately, for most of us that means being really good at more than one thing.

To see what it takes to be an indispensable developer, check out this article I just published in the June Edition of the Pragmatic Programmers Magazine.

Horizontal vs Vertical slicing


I recently started playing a bit of a release manager role for some projects at work, and one of the interesting conversations I’ve been having with people are the merits of slicing projects horizontally vs vertically.

Horizontal slicing

With horizontal slicing, projects are broken up roughly along architectural lines. That is there would be one team for UI, one team for business logic and services (SOA), and another team for data.


One advantage of slicing your application horizontally, is you get good communication and consistency within each slice. Everyone does things the same way.

The downside of slicing your projects this way, is that until you integrate every thing together, you really haven’t delivered anything of value.

Your customer can’t go into production with screens, services, or well normalized database schemas.

Only when all the layers are hooked up do they offer any value.

That’s why agile is so big on slicing projects vertically.

Vertical slicing

Agile is very big on the concept of one team. There is no UI, SOA, or data team. There is only one team, focused on delivering a suite of features for the customer.


The other advantage of slicing vertically is you are more efficient. You don’t have the overhead, and effort that comes from trying to coordinate activities across multiple teams. No need to negotiate for resources. You’re all on the same team.


No. Not always.

Whenever you have legacy systems (mainframes), core business entities consumed by many across the enterprise, or anything where the technology dictates how the application needs to be built, you may be better off slicing that body of work horizontally.

That doesn’t mean you can’t work with them in an agile fashion. More that they will have a certain way of doing things, and you will have to adapt.

So go vertical when you can. And horizontal when you have too.

Thanks to John Kordyback for sharing his thoughts on this subject.

Not all pain is bad

1 Comment

Driving home from the lake today, it occurred to me that not all forms of pain on a project are bad. In fact some are pretty good.

Take bug tracking for instance.

Do you want a tool that makes tracking bugs nice, friendly, and easy to use?

Or do you want something that is slow, cumbersome, laborious, and so painful, your team would rather fix the bug than report it.

A painful bug tracker may be a great pain to have on your project.

Let me know if you can think of any others.

Deliver something of value every week


Stuck in a rut? Can’t seem to ship?

Try delivering something of value every week.

Doing this will require you and your team to do certain things.

You have to break big problems down into smaller ones


A week is a relatively short period of time. You can’t possibly do everything in a week!

To get anything done in a week, you have to break big, scary, complex problems down into smaller, simpler, more manageable ones.

At first this can appear daunting.

But once you crack it, you will find the big problems aren’t as bad as you thought; and that you can deliver a lot of value in one week’s time.

You are forced to focus on things that are valuable to your customer


How do you know what’s valuable to your customer? You ask.

When you look at a software project through your customer’s eyes, it’s easy to see how little of what is traditionally offered has little or no value.

Sure you need documentation. Sure you need plans.

But they are only in support of one thing—working software.

By delivering something of value every week, you are forced to get lean and ignore anything that doesn’t add value.

As a result, you travel lighter and only take what you need.

You have to make sure that what you are delivering works

Delivering something of value every week implies that what you deliver had better work.

That means testing—lots of it, early and often.

Testing isn’t something you be slough off till the end of the project.

It’s not something you can delegate.
The buck stops with you.

When you deliver something of value every week, testing will become a part of your daily life.

You are forced to get feedback

How do you know whether you’ve hit the target if you don’t regularly engage and ask your customer how you are doing?

Feedback is the flashlight that cuts through the fog and keeps you on the road as you’re barreling down the highway at a 100 miles per hour.

Without it, your customer loses the ability to steer. And you end up taking a lot of wrong turns.

You have to adapt


Stuff happens on projects. Things change.

What is really important one week can be de-scoped the next.

If you create a plan and follow it blindly, you won’t be able to react to the curve balls.

That’s why when reality messes with your plan, you change your plan – not reality.

You have to be accountable

When you promise to deliver something of value every week, you become accountable.

That means owning quality.
Owning the schedule.
Setting expectations.
And spending the money as if it were your own.

Because, at the end of the day, it is you, your team, and the expectations you set, that will determine whether your project succeeds or fails.

You can’t delegate this. Nor would you want to.

Warning! Not everyone likes working this way

Delivering something of value every week is not for the faint of heart.

It puts the spotlight on you like never before.
There is no place to hide.
Every week you sit down with your customer, and show them how you’ve spent their money.

Some people don’t like this level of visibility.
They don’t want it.

But for a team struggling for direction, and not knowing where to begin, it’s an awfully good place to start.

So if you find yourself in a bit of a rut, or your team is struggling to get something out the door, hit the pause button. Take a step back. Ask yourself what it would take to deliver something of value every week.

Then trust your instincts, and do what needs to be done.

Older Entries

%d bloggers like this: