Part of the recent re-org at Sun was a new role for Greg – or rather, a de jure codification of what should have been the de facto all along. As Jonathan blogged:
Now as you may have heard, I gave Greg a new title recently. In addition to being Sun’s CTO, he’s now Executive Vice President of Research and Development. Why’s that important?
[…]
So as a part of this change, the product group CTO’s, the sentinels supporting the line executives who run our businesses, will also report to Greg. In the world of human resources, that’s known as a “dual hard line” reporting structure.
So what exactly do these “sentinels” do? Or, perhaps more important, what should they do? Here’s what I wrote to a colleague a few months ago:
Back in the mid-90s, Hal Jespersen and I were co-CTOs in the Network Software Group under Terry Keeley and then John McFarlane. We found that the job involved both inward and outward facing activities, as you’d imagine. The outward included:
- Customer facing work, both tactical and strategic. Familiar stuff.
- Other business-related stuff: analysts meetings, press, etc.
- M&A [merger & acquisition] up to the point of acquisition (due diligence, selection, etc.).
- Strategic partnering (remember the various strategic alignments attempted with XXX,YYY etc.?).
These are fairly straightforward. They are business-critical, usually interrupt-driven, with no obvious tempo. By contrast, there are a number of inward facing activities for which it is important to develop a predictable process, a cadence:
- Portfolio planning and MRP [Medium Range Planning – Sun’s budget process].
- Technical reviews of projects – regular, in person, with [at least] the tech leads, every 3-6 months.
- Business reviews of programs, supplying an independent voice on the state of the technology.
- M&A from the date of acquisition until effective assimilation
- Setting technical “big rules” if absolutely necessary
- Taking care of the engineering community, from a retention, skills inventory, and development perspective
- Coordination with CTOs in other business units
(In addition, the CTO *may* be responsible for AD [Advanced Development] within the BU [Business Unit], in order to shield the budget for this from being traded off at the project level. Where AD belongs – within each program, at BU CTO level, or in the Labs – is something that needs to be worked out carefully.)
All of these roles are vital, of course. 🙂 The one that should not be skimped on is the regular technical project reviews. VPs and directors in charge of programs will routinely fudge (lie about) the technical state of their projects; that’s just the way things are, no big deal. The CTO has to understand the technical status of the programs, has to be in a position to identify gaps, overlaps, and duplications across the portfolio.
Obviously one person can’t do all of this: you need a strong, outgoing leader with a small staff of experienced engineers and process people. (The “co-CTO” approach that Hal and I used in NSG was a good “in the small” example of this.) Above all, you need someone who is respected and trusted by the BU EVP but relatively independent of him or her. That’s the value of the dual reporting relationship that Jonathan described.
Of course this only works if all of the BUs have CTOs….