In my last couple of jobs, I’ve had to define technology leadership. And, in particular, how it relates to code.
The motivation in one job was that the engineers and management had passed the accountability buck to the process. The motivation in another job was to codify well-understood practices.
Each slide deck was different. And had specifics, and so I can’t share the deck’s as is, and I figured other people might be interested to know how I think about it.
When working on accountability and responsibility, the first problem is defining the terms. Here’s the definition I used that I borrowed heavily from several RACI websites.
To me, the fundamental intuition is that the accountable party makes the call, and the responsible party owns making sure that it’s the right call.
The next question is, what is technology leadership, and why is it important.
The key points are that technology leadership is about building great products, and great products are a function of product management, great technologies, great teams, and great sales and that technology leaders are responsible for all of those.
One thing that gets lost in discussions about technology leadership is the role of management. Managers are a vital player in this party. And in many ways, I view managers and technology leaders as separate actors.
You’ll notice managers are accountable for planning and team quality and execution, and technology leaders are accountable for technology and quality and the quality of the artifacts produced. And they are, in turn, responsible for what the other guys are accountable for.
If your technology leader and manager are the same, my experience is that you either get a better quality product with missed dates or get worse quality on time.
And this creates tension, especially on the dates.
The point is that the technology leader and manager should not see this tension as a winner takes all battle, and instead view this as a conflict whose purpose is to force a compromise that delights the customer. A poorly architected product is as big a failure but that ships on time is as big a failure as well-architected product that ships late.
And the conflict is desired. It’s not an accident. You create the tension to force the compromise. And the compromise is a good thing if it produces an outcome that is aligned with delighting our customers.
Leave a Reply