Monthly Archives: May 2010

Career Paths for Technical Folks

[From the Archive: Originally posted at May 11, 2010]

In my previous Amplify entry, “Do Managers need deep technical skills?“, I suggested that folks with technical knowledge were perhaps not automatically the best choice for management positions in technical teams.

Marc Johnson then asked about my view on career development for technical folks. So here it is:

I have long thought it unfortunate that most organisations seem to have an implicit mental model of career development that assumes that to “get ahead”, folks have to get on to the general-management ladder and begin climbing.

It’s been my experience that many highly talented technical folks have little interest in swapping their technical role for a management one, but often feel that a change into management is the only way they can advance their careers.

Sun Microsystems (R.I.P.) used to have a somewhat novel take on this issue: They provided twin career ladders all the way up into the high echelons of the business, one ladder for technical folks and one for the general management folks. For a business predicated on technical excellence, this seemed to make some kind of sense.

In the more general case, I take comfort from the continuing evolution of business in general, and the role of management in particular, that suggests to me that the issue may become moot at some point in the future. Not least because I see the role of management changing (unrecognisably), and modern management skills becoming just one more skill-set of the multi-skilled worker.

Aside: By “modern” management skills I mean things like Systems Thinking, Theory of Constraints, Lean, appreciation of e.g. customer value, value streams, folks’ needs, and fellowship;. These in contrast with the more traditional emphasis on amorphous “people skills”, command-and-control, etc.

So, for technical folks in organisations that essentially require one to abandon one’s technical career to get ahead, the old saw remains true: “Change your organisation, or change your organisation.” :}

Amplifyd from

– Bob

Do Managers Need Deep Technical Skills?

[From the Archive: Originally posted at May 7, 2010]

Jurgen Appelo asked me yesterday to clarify my (tweeted) position that requiring managers of technical team to have deep technical knowledge (within the same technologies as the team) is “senseless” (i.e. not very clever).

So here’s my response:

There are some (few) advantages to a manager possessing deep technical knowledge in those technologies being used by the team. However, these advantages are significantly outweighed by the concomitant disadvantages.


  • Easier to win the (early) respect of the team.
  • Fount of knowledge on hand when the team get stuck on technical issues.
  • Better early inter-personal communication, as the manager and the team have a more congruent understanding, vocabulary, etc.
  • Technical skills imply, at least, that the manager in question may have an engineering perspective and understand the software development (e.g. coding) mind-set.


  • Superior knowledge makes for less effective coaching, as the “expert” is often sorely tempted to provide a quick answer to move the work along, rather than allow the team to stumble and thereby learn and grow their skills. Aka “micro-management”.
  • People coming from a technical background do not often have the coordination and interpersonal skills necessary to help the team achieve a highly-effective state. Consider the perspective of Deming et al: “The Team works in a System. The job of the manager is to work on the system to improve that system with the help of the team”. (Personally, I’d describe it the other way around: The team owns and improves the way the work works (the system) with the help and support of the manager).
  • People with a deep technical knowledge have generally acquired that knowledge by dint of love of technology and long hours spent practising their art. Many such folks find it very difficult to set this love and these skills to one side on those occasions when the exigencies of the situation demand more focus on the development and application of their coordination and interpersonal skills.

To recap: Whereas the advantages listed above are more numerous, they are, in my opinion, far outweighed in significance by the stated disadvantages.

Personally, I would generally exclude people with deep technical knowledge from consideration for management positions, as both a favour to them, a favour to the team, and a favour to the work and its customers. Of course, there are rare exceptions. 😉

Amplifyd from [original source no longer available]

  • Jurgen Appelo jurgenappelo
    @flowchainsensei I would welcome an explanation why our policy is “senseless” 5:21 PM May 6th via Twitter for Android in reply to flowchainsensei

– Bob


[Mar 2, 2012]

Lest anyone slip into the notion that I favour non-technical managers over technically-skilled managers, please note that in the bigger picture (i.e. of organisational effectiveness), we would not have managers at all. The issue then becomes moot.

Commitment to Sprint Delivery vs Time-boxing

[From the Archive: Originally posted at May 1, 2010]

This post is my amplification of a point being discussed on Twitter the other day.


The thread of discussion was kicked-off by my response to this tweet: “with time-boxed iterations, you commit to implementing all [stories] within a given period of time”

My initial response was: “No, not commit, just select”

Some folks seem to have taken exception to this (and probably with some cause, given its brevity), so here’s a little more of my perspective on twin subjects which are close to my heart, and receives less attention than perhaps they warrant: Commitment, and time-boxing.

Note: The subject of time-boxing mostly applies to agile approaches with fixed-length iterations, such as Scrum, although I would suggest that there is merit in considering time-boxing for e.g. individual cards / tasks / deliverables in Kanban, also.


For me, timeboxing means setting a fixed end-date (for e.g. an iteration), and not ever allowing work to overrun that date. Not contentious so far, I hope.

Given a fixed end-date, then, the question must sometimes arise as to what happens when that date is reached and not everything planned for delivery on that date is “feature-complete”. I have generally thought it best to anticipate this situation, and have a project management pattern named “Constant State of Ship”. This pattern proposes that work items within a sprint should ALWAYS be “shippable” (at, say, 10 mins notice, max), at every point in their evolution, from “not started” to “feature-complete”.

Wikipedia says (of time-boxing): “If the team exceeds the date, the work is considered a failure and is cancelled or rescheduled”. I prefer to say “All work is shipped at the end of the timebox, some of it may not be feature-complete”.

Put another way, a time-box, for me, means allocating a fixed amount of time to work on a thing, and shipping that thing as soon as time is up.

Aside: In the past, I have worked with some project teams where we timeboxed the individual tasks / work-items / deliverables on the sprint plan, not just the sprint as a whole.

Commitment to Delivery

Given the above take on timeboxing, hopefully my comment on commitment takes on a little more clarity.

Commitment, then, involves the team as a whole asking its members to sign up to working on the planned tasks / work-items / deliverables for a fixed amount of time per item.

Aside: To improve the chances of that fixed amount of time being sufficient to reach “feature complete”, I encourage new teams, as part of sprint planning, to provide a “percentage likelihood of reaching feature-complete in the committed time”, for each item. Estimates below 80% trigger a re- evaluation of the allocated time / people, and most likely some re-planning. More mature teams can forego this step.


In summary then, time-boxing, as described above, means that teams – and individuals – don’t commit to shipping everything as “feature complete” in each sprint, but commit to doing their best to get as close to feature-complete, for each item, as they possibly can in the time they have allocated themselves.

I leave it as an exercise for the reader to consider the implications of this strategy, with regard to motivation, teamwork, and customer (product owner) satisfaction.

– Bob

%d bloggers like this: