Drive: The Peopleware of this Generation?

imageThe 70’s and 80’s had The Mythical Man-Month. The 90’s had Peopleware. These works helped software managers understand and communicate to non-software people the dynamics involved in effectively managing software teams. The management models that got cars and TVs built at ever cheaper costs didn’t work on software projects. Brooks, Lister, and DeMarco helped thoughtful software managers figure out how to best manage professionals who must bring a challenging combination of creativity and technical rigor to their work.   

In Drive: The Surprising Truth About What Motivates Us, Dan Pink provides the same kind or resource for a more general audience. He argues that the models for understanding human motivation that worked in the past are outdated and don’t apply to today’s knowledge workers.

Pink contrasts internal and external motivation. Our internal motivation is driven by three needs: autonomy, mastery, and purpose.

Autonomy: We need more than “buy in” or even independence. We crave true self-direction.  To provide meaningful autonomy to our teams, we need to give our people choice over:

  • Task – What they do
  • Time – When they do it
  • Team – Who they do it with
  • Technique – How they do it

Mastery: We are driven to grow, improve, and be increasingly capable of solving more and more complex problems.

  • Mastery is a mindset: It requires the capacity to see your abilities not as finite, but as infinitely improvable. Internally motivated people tend to have an incremental theory of intelligence, prize learning goals over performance goals, and welcome effort as a way to improve at something that matters.
  • Mastery is pain: It demands effort, grit and deliberate practice. The path to mastery – becoming ever better at something you care about – is a difficult process over a long period of time.
  • Mastery is asymptotic: It’s impossible to fully realize, which makes it simultaneously frustrating and alluring.

Purpose: The old models for understanding motivation assumed that we are primarily motivated by money. Today we see money as a necessary but not sufficient reward of our work.  We want to know that what we do makes a difference in the world.

Much of Drive is derivative of the research done in cognitive psychology and behavioral economics, but Pink brings it all together in an engaging and practical way that will allow managers to put these ideas into action. I highly recommend it to anyone who oversees the work of anyone else.

For a small taste of the ideas in the book, check out this presentation.

Comeback-a-thon

hackathonIt’s only two days before the Marathon Data Systems sponsored Jersey Shore Comeback-a-thon, a 24-hour hackathon with a theme of bringing business back to the Jersey Shore in the first season after hurricane Sandy.

Many businesses along the Shore have worked very hard and made great investments to rebuild, clean up, and claw their way back into business in time for the summer season. Unfortunately, the images of devastation of the storm have left many would-be visitors thinking there is no beach to vacation to this year.

The $1000 grand prize will be awarded to the individual or team that comes up with the best application, system, or other creative use of technology to help bring business back to the Shore.  There will also be two $300 runner up prizes.

We’ve had good coverage from patch.com, njbiz.com, and triCity News. Get more details here.

Hashtag: #combackathon

Attributes of a Good Team Room

As we look at new office space, I had to think about what we would want in new team rooms. Here is what I came up with, with the help of my team…

  • Four walls (ideally with at least one being glass or lots of windows)
    • high enough to provide a sound barrier
    • lots of white-board space
    • wall of offices or conference rooms is OK as long as the doors can be closed
  • At least 5 feet of desk space per person
  • Ability to run HDMI to a large, shared monitor (probably on a rolling stand)
  • 8 – 10 people per room (ideally with removable wall to combine two rooms)
  • Private space nearby
  • Manager’s office nearby

Confusion Over Structs

I was recently perusing an article called C# developer interview questions and answers. I do a lot of interviews of developers with C# experience; so, I like to see what others think are good questions. The article was generally good, but there was this…

image

Good question. Good first sentence. Then things start to go down-hill.

First let’s look at the claim that “Structs are passed by value and not by reference.” This is technically true, but betrays a superficial understanding of the language. In C#, all parameters are are passed by value. It just so happens that the value of a reference type is in fact a reference. If that doesn’t make sense, read this article by Jon Skeet. A better way to state the point would be: “Structs are value types, while classes are reference types.” This would also cover the part about not being able to inherit from structs because all value types are sealed.

Next we have “Structs are stored on the stack not heap.” This is false. Look at this code:

image

Where will the Point inside the Shape be stored? Clearly on the heap. It is true that value types declared as local variables, even though they may be newed up, are still allocated on the executing thread’s stack space…

image

Now we get to the best of all… “The result is better performance with Structs.” If it were that simple we would always use structs and wouldn’t even need classes. The reality is that some objects are better modeled as classes and some are better modeled as structs. Discussing what kinds of objects are best modeled as structs would be a great question.

Looking for Agile Software Developer in Central NJ

Are you a software craftsman? Do you value growing your skills as you simultaneously learn from and teach the other members of your team? Want to help us build the world’s best cross-platform mobile solutions for field service workers?

The folks that fix your A/C when it’s 100 degrees and keep your toilet from backing up into your living room deserve the best software technology can provide, and we need your help. We are looking for a key addition to our Agile/Scrum/XP team that is building a highly scalable, event-driven, mobile-enabled platform. This person will be test-driven and team-focused. He or she will be a mentor to team members new to TDD and some of the other XP practices.

Must haves:

  • At least two years of test-driven development experience with the .NET platform (C#) on a collaborative team (Scrum, CI, TDD/BDD, Paired-Programming, Collective Code Ownership, Refactoring, Iterative & Incremental Development)
  • Strong foundation in Object-Oriented Design and Programming (Design Patterns, SOLID principles, etc.)
  • Strong desire to learn and teach others

Highly valued:

  • Domain-Driven Design experience
    SOA and/or SaaS experience (especially with NServiceBus or any ESB)
  • Entity Framework Code-first or other ORM experience (especially with RavenDB, MongoDB, or other document databases)
  • Significant JavaScript experience (especially with Sencha Touch, CoffeeScript, or any JavaScript TDD/BDD framework)
  • Mobility experience (iOS, Android, or Web)

Voted as one of the Top 30 Places to Work in NJ, Marathon develops supports and sells SaaS software and marketing solutions to the SMBs in pest control, landscaping, HVAC and other service verticals. Comprehensive benefits package including vacation, insurance, and company sponsored profit sharing plan. Contact me at efarr@marathondata.com or @efarr.

Recruiting: Where to Start

There is no more leveraged activity in building an effective software team than recruiting. The hours or days spent choosing people to add to the team will have a disproportionally large impact on your team’s effectiveness.

If you haven’t already read Joel Spolsky on hiring, you must. Now. The two big ideas I learned from Joel are still the most important ideas in all of my recruiting success…

Joel Big Idea #1

If you cannot answer the “Should we hire this candidate?” question with an enthusiastic “yes,” then it’s a no-hire. There are no “maybes.” The reasoning is simple—a mistaken hire is much more costly than a mistaken no-hire.

I find this principle easy to agree with but difficult to follow. Great developer are always hard to find. The pressure “be reasonable” and hire a maybe candidate has caused me ignore this principle. I’ve regretted it every time.

Joel Big Idea #2

There is a simple rule of thumb to hiring any developer on any team. You are looking for two things: the candidate…

  1. is smart, and
  2. gets things done.

Look at the following grid.

image

You would never intentionally hire Useless, but lets look at two easy hiring mistakes.

Tinkerer: Someone who is smart, but doesn’t get stuff done. This mistake is easy to make because he gives good answers to typical interview questions. However, once you hire him (or her) you find that nothing actually ships. Our industry is full of smart people who are content to learn and write code, but don’t want to commit to finishing something. They never have to deal with customers or operations or any of those messy details because they are always almost done.

Mess Maker: Someone who is not smart, but gets stuff done. This mistake is easy to make because he can tell you all about the projects he has completed. However, once you hire him, you will find that he leaves a trail of messy, fragile code behind him. You will spend more time trying to fix the messes than you gained by having him create them.

The effective developer is the one who is smart enough to appreciate the competing factors and trade-offs that come into play when creating software and is driven to see his solutions solving problems for actual users.

Identifying the smart developers who get things done is no easy task. I’ll have more to say about that in future posts.

Who Needs Vision?

image

I admit it—I don’t like Successories, the pretty pictures with inspiring sayings that don the walls of corporate America. In fact, my first purchase to decorate my team’s new space was the poster-sized Demotivator Calendar from despair.com. I (and virtually every good developer I’ve ever met) love these spoofs on the ever-present corporate décor.

You might think I enjoy mocking Successories because I believe the words they portray like Values, Vision, and Mission are meaningless corporate-speak meant to manipulate shallow-thinking cubical jockeys. If that is what you conclude from a “demotivator” on my wall, you would be dead-wrong. image

I despise Successories for just the opposite reason. I believe the concepts these pretty posters are meant to inspire employees with are vitally important–way too important to trivialize with a one-size-fits-all platitude and poster.

Over the years, I’ve seen so many leaders (in both the social and commercial sectors) that struggle with communicating concepts like values, vision, mission, and strategy. So, it’s no wonder that so many people have completely written off the words themselves. They now associate a word like vision with the vapid trivialization that is the meaningless poster. This is tragic.

What to Do About It

I have found that the confusion starts when we fail to define our terms. How does mission differ from vision, and is either really any different from strategy? What do we mean by values? If we cannot define the terms, we cannot think clearly about them, and we certainly cannot communicate them to our teams. We’re left simply resorting to something like “We are a company with an obligation to shareholders to make money. Bottom line: we need to make money.” While this is completely true, our people hear this as “We do anything for money.” We have some unpleasant names for people with this mission statement. No one wants to sign up for that. We must do better.

Defining Terms

Let’s start with some definitions…

Values articulate the core things we care about. Our values inspire our vision.

Vision is our picture of how the world could and should be. Our vision defines the end we strive for.

Mission is what we do every day. Mission is executable and it doesn’t change lightly.

Strategy lays out a plan for executing on our mission.

Goals are surfaced by our strategy.

Objectives are framed by our goals.

Tactics are driven by our objectives and determine how we spend our time and energy.

I see these concepts as layers of foundation, each one flowing from and building off of the lower layers. The lower layers are more abstract, simple, and unchanging. The upper layers are more concrete, detailed, and subject to changing circumstances.

Vision

Values

I believe much of our values are universal. We all have a drive to leave our mark on the world, to give more than we take, and to be competent. Software people add to this a strong desire to create. We find it deeply satisfying to solve real problems with elegant models formed in our imaginations and elegantly crafted in code. I am sure it is the same rush a painter gets as he translates the scene in his mind onto canvas to the delight of his audience. He comes to love the smell of paint the same way we come to love the sight of clean code.

Vision

Vision is seeing what isn’t, but could be. Vision isn’t about what we do, it’s about how we want things to to be. Vision creates an anticipation of a better future. That anticipation motivates. It overcomes the apprehension that comes with change and drives us out of our comfort zone.

SmallerEinstein

Having, believing, and communicating a compelling vision for my team is the most important thing I do as a leader. Everything else flows from it.

Lewis Carrol’s famous “If you don’t know where you are going, any road will get you there.” has become cliché, but only because it expresses “common sense” that we often miss.

My team creates solutions for service businesses with field workers, like HVAC install and repair, plumbing, pest control, cleaning services, and others. The work these companies do is critical to the quality of life we all enjoy. We believe the tools these people currently have to run these businesses could be so much better. We burn untold gallons of fossil fuels routing drivers inefficiently. So many hours are wasted annually because, not only are we scheduling, but the entire process is unpredictable.

Our vision is of a transformed service industry—quicker response times, tighter scheduling windows, more customers served, and less fuel consumed. In order for us to accomplish this, our solutions must be highly scalable and allow for high levels of developer productivity.

Mission

If values and vision answer the why question, mission answers the what question. My team’s mission is to deliver software solutions that bring about the transformation of field service business we envision. We can only accomplish this mission if we have simple yet scalable architectures and clean code.

Strategy

If vision answers why and mission answers what, then strategy answers how. My team is executing on its mission through several high-level strategies.

  • We use iterative development cycles and the other agile techniques to ensure that we are always working on the highest value features for our market.
  • We are building a distributed system of event-driven services that each follow the Single Responsibility Principle so we can scale the application as well as the development team(s).
  • We are always striving to improve our skill in writing clean code.
  • We follow test-driven development to keep our designs clean and our code reliable.

Goals, objectives, and tactics each successively further flesh out the details of how we plan to make our vision a reality. Maybe more on those in another article.

Conclusion

image

Putting Successories on the wall is a substitute for vision like a Lunchables is a substitute for a fine steak dinner.

image

The Effective Software Team

image

I’ve spent the last five years immersed in trying to answer two questions: how to build scalable software systems and how to get teams to perform at a high level and build those great systems that exceed expectations.

Over those years, I’ve learned from varied sources: blogs, books, podcasts, colleagues, and my own experience. I will be cataloging my favorite ideas and resources for building, nurturing, facilitating, and leading effective software teams. High level topics will include:

  • Hiring
  • Training
  • Leading
  • Processes
  • Collaboration
  • Self-organization

I will post at least one article per week for the the next year (or more). I will address topics as they hit me. I’ll catalog and index them later.