Peeling the Onion of Responsibility
When you are working on solving a problem, you become emotionally invested in the solution. It’s natural, it’s your baby, you love it, you brought it to life.
Unfortunately, sometimes we fall in love with the wrong solution. It’s no great failing, it’s just the inevitable consequences of being passionate about our work. Any time we create, we face the risk of falling in love with our creation, and sometimes that creation missed the mark.
The deeper we go into a discipline, the more likely this is to happen, especially in software. In order to trully solve a problem we need to understand it inside and out, and in the process of coming to greater understanding, we often forget how the world looks outside of that specific problem.
- The engineer working on a small feature becomes enamored with their UI widget.
- The team lead focused so much on the coding standards used to implement the widget they didn’t realize it really happened in the wrong layer of the application.
- The architect was so focused on the layout of the application, they neglected to recall that the user experience designer really wanted that feature in a completely different area of the application.
- The user experience designer was so concerned with the location of the feature, they neglected to note that the feature is much less important than another feature that is further behind schedule.
- The CTO was so concerned with the feature that was behind schedule that they neglected to notice that the feature is needed only for market that the CEO isn’t prepared to enter for 3 more quarters.
- In the meantime the CEO has been too busy play golf to notice any of this is going on…
Every individual is making the right decision for their area of responsibility (especially the CEO), but by focusing on the details, they’re missing the rest of the picture.
In a functioning organization, information flows the other way.
- CEO decides the strategic direction
- CTO figures out which team/organizational structure and development method will achieve the goals.
- Architects figure out the best technology to use to achieve the goals.
- Team managers figure out the best people to work on discrete pieces of the big picture.
- Team members figure out the best approach for their individual tasks.
Too much meddling across these boundaries and the team cohesion falls apart. If you don’t trust someone enough to let them work on their areas of responsibility you have a staffing problem, not a control problem.
Even if you don’t have enough employees to separate these out into discrete functions, each role needs to be played. Better entrepenuers will be able to fill multiple roles within their company.
The best team members are the ones that know other concerns need to influence their actions, and seek out input when they reach crossroads that could impact the responsibilties of others.
image via fcuardi