• Home

  • Custom Ecommerce
  • Application Development
  • Database Consulting
  • Cloud Hosting
  • Systems Integration
  • Legacy Business Systems
  • Security & Compliance
  • GIS

  • Expertise

  • About Us
  • Our Team
  • Clients
  • Blog
  • Careers

  • VisionPort

  • Contact
  • Our Blog

    Ongoing observations by End Point Dev people

    On excellence

    Ethan Rowe

    By Ethan Rowe
    August 21, 2008

    The interwebular collective cup runneth over with blog articles addressing the subject of what makes good software engineers good. It is a topic about which many opinions are expressed. What is less commonly addressed, however, is the possibility that the very qualities that make for good software engineers may also make for good technical leaders, good managers, and just good coworkers, period.

    At End Point, we toss the term “ownership” around quite a lot, in a variety of contexts. When a particular task or responsibility goes from one person to another, we mention “ownership” when we need to communicate the significance and scope of the responsibility in question. The term may apply to a software engineering task, in which “owning” the problem means taking responsibility for all aspects of the engineering work, across the software stack, from prototyping to full development to deployment. It may also apply to a managerial or leadership role, for which “ownership” implies responsibility for all parties involved on a given project, task, or team, with the “soft” issues of human beings mattering at least as much—​and probably more—​as the “hard” issues of machines, software, etc.

    Ultimately, ownership comes down to this: taking complete personal responsibility for all aspects of the problem at hand.

    The owner does not wait helplessly for guidance from others; rather, the owner pushes things to a conclusion, and if guidance is truly necessary the owner pushes for it repeatedly until guidance is received. The owner does not put hard or potentially unpleasant things off, but instead embraces them and addresses them immediately. The owner does not limit him- or herself to a narrow comfort zone: he is not afraid to go to different parts of the software stack, she does not hesitate to call the business person to have difficult discussions about scope creep or design flaws or difficult tradeoff decisions. The owner never allows for the actions of others to serve as an excuse, and never regards any aspect of the task to be only somebody else’s problem. The owner treats the deliverable as a reflection of him- or herself. The owner looks objectively at the deliverable and does not shy away from criticism, instead embracing it for the learning opportunities that can come from reflection and analysis.

    In other words, to act with ownership is to act as if all aspects of the project or duty are important and are the owner’s responsibility. That does not mean acting with ownership requires personally doing everything; owners can and should delegate as appropriate. But delegation does not mean that the responsibility is now somebody else’s problem: the owner engages in regular communication with the involved parties, and keeps the task or project in question on track. The owner understands that it still ultimately belongs to him or her. Furthermore, the owner recognizes ownership in others, appreciates it for what it is, expresses gratitude and respect for it, and does not feel threatened by it.

    In our work, this kind of ownership is the root of excellence. The domain of ownership may vary wildly between individuals, but the degree of ownership exhibited directly correlates to the excellence the individual demonstrates within that domain. Ownership applies to everything, whether it means writing the most reliable, maintainable code possible, designing the most scalable systems, or ensuring that everybody on your team is productive and happy. If you are an owner, you understand this: there are no excuses, and it’s up to you. Furthermore, to make it happen, the owner also understands: at some point, the talking ends and the doing begins.

    Ownership for a given problem may be granted to a particular individual. With a team of people, formal identification of a problem’s owner is necessary for operational clarity. However, such ownership is ultimately little more than a formality: true ownership can only be taken, and never granted. This model is at the heart of any meritocracy, and is true to the general principles of free software development.

    Critically, ownership is part of an oral tradition, a cultural phenomenon. Ownership breeds excellence across teams. It spreads as people naturally admire it and emulate it when they encounter such excellence first-hand. It is never complete; no one individual with a full schedule will successfully display ownership across the board on all issues. We fall down sometimes. We overextend ourselves. We have to pick our battles. But part of ownership is recognizing mistakes so that we can do better.

    It is my distinct pleasure to have witnessed such ownership, on numerous occasions. I’ve seen a coworker leap into system-wide problems—​on systems this coworker ordinarily has little or nothing to do with—​and not rest until every aspect of the system is in order and all members of the team involved with the support of that system understand exactly what it is that needed to be done. I’ve seen another tackle fiendishly difficult technical problems involving complex data modeling or hairy lock management in Postgres, pushing through all the roadblocks until success was achieved, no matter how challenging the problem and no matter how much investigation and mental gymnastics were required. Yet I’ve seen the same people show the same dedication and caring for work done on much smaller systems, on less interesting problems, in less dramatic scenarios. This is a small sampling from countless examples.

    In my experience, the only proper response to such excellence is admiration, and it inspires a desire to emulate these fantastic coworkers to be similarly excellent and to earn their respect.

    Again: it’s a cultural phenomenon. People do not learn this by reading books. Reading about it, and talking about it, are essential for understanding. Ultimately, though, doing is all that matters.

    In the liner notes to his Live at the Blue Note box set, the great pianist Keith Jarrett thanks his illustrious colleagues (Jack DeJohnette and Gary Peacock) for reminding him that “the only standards worth having are the highest ones.” What more need be said?