Delegating Responsibility in a Culture of Continuous Deployment

Problem

"The engineers on the front-lines–the ones doing the actual building of code and product–are the ones most equipped with information. They face the real constraints of the problem domain and existing code base; they have the best insights into how we can be most economical with their time; they have the capacity to see all the options before us."

"They have the best insights into how we can be most economical with their time."

I have a duty, as manager, to lead my engineers to the point of being individually responsible for their work and ship whenever they have something ready to show the world.

Actions taken

• Whenever I do an introductory phone call with an engineering candidate, I make sure to explain my management style and how my approach directs our team's process.
• Our process is Agile, but not completely adherent to its methodology. Instead, it's delegated responsibility in a culture of continuous deployment. I delegate the responsibility of something important to an employee–usually in the form of a significant feature–and let them take it from concept through implementation to deployment.
• I make sure I am there to help them sift through that information when needed and to be that supportive coach, but my goal is for them to be carrying us forward. I manage, but I am to lead, not to micromanage.

Lessons learned

• Delegated responsibility is a very common and efficient practice in the business world. However, the practice has largely been abandoned in the software industry by practices and processes that shift responsibility onto a team of replaceable cogs. The team is expected to churn through a backlog of dozens of insignificantly small bits of larger features, which often lack foresight into the constraints that will be discovered and the interdependencies between smaller bits that result in developer deadlock. On top of this, a generalized backlog of small pieces creates room for misinterpretation by omitting full context around features or results in excessive communication overhead (see The Mythical Man Month).
• I always discuss my model of delegated responsibility with potential hires beforehand in order to see how they feel about it. I do this because I realize some candidates would much rather be working on a team with equally-shared responsibility, collective code ownership, and continuous pair programming.
• Those who do thrive with delegated responsibility take ownership, require little to no management or direction, make the right decisions, take pride in what they have built with their own two hands, and are extremely productive. Not surprisingly, others understand their code. It integrates well with the code base. They avoid the dangers that formal methodologies try to curtail. Often they are or are becoming, that 10x developer. They are liberated, thrilled, and at their best working in this environment. It's a joy to provide it to them.

"Those who do thrive with delegated responsibility take ownership, require little to no management or direction, make the right decisions, take pride in what they have built with their own two hands, and are extremely productive."