1
We Create Great Outcomes
Start with the end in mind.
It’s not just about code.
A common misconception among new hires is that our job here is to write code. That is false. Clients hire us to create an outcome. That outcome is our job and our measuring stick. Just as a carpenter is not measured by how smoothly he swings a hammer but by the quality of the house he builds, we are measured by how well our work performs in the wild.
Even if you’re really good at writing code.
Early in my career, I was tasked with onboarding a new programmer. This particular programmer had an extremely impressive resume including being listed on multiple patents. She came to me one day and told me that she was finished with the project I had given her, but it did not run. She was perfectly satisfied with this outcome and felt her job was done.
This illustrates a dangerous misconception. Writing code is useless unless that code creates the desired outcome. Until the problem is solved, we are not finished, no matter how much code has been written.
“It has to work” is always the first business rule.
Documentation is a good and necessary thing. No human being can hold in his or her mind, forever, all of the goals, priorities and details necessary to make a great outcome. So, we think about them piece by piece and document them so we don’t have to re-figure it all out every time we sit down to work on the project. It also allows us to make sure that a group of people working together can make a cohesive whole. This is the proper use of documentation.
What happens in some organizations is that the documentation becomes an excuse to avoid the messy business of taking responsibility for the end result. People turn off their brains and just doggedly follow checklist item after checklist item, not thinking about the big picture. Worse, I’ve even seen it become a game where the developers try to find every possible thing that might not be listed in the scope document and avoid doing those things because it wasn’t on the list. That attitude is not tolerated here. We all agree that the documentation is an outline to help us build the best outcome possible.
Your mind is the biggest hammer of all.
The blueprint (in our case, a scope document) is a guide and a tool. Just as code has bugs, scope documents are created by inherently flawed human beings. Every step that happens after the creation of the scope document should serve as another brain actively engaged to make sure that the details of the project are still serving that desired outcome. We don’t turn off our brains. They are our biggest hammers, and the things that allow us to be not just coders but developers.
“We are creators of great outcomes. We commit to the end result and every action we take contributes to that end result: a delighted client and a successful project. We use all of the tools in our arsenal, but most of all our problem solving abilities and our creativity, to accomplish this outcome. We are all in it together. Nothing is above or beneath our job description as long as it contributes to that end goal. ”