what I've done, and when, and for whom

Software engineering deals with the behavior of machines.  A program is a piece of machine behavior.

Leading or managing the tribes of engineering people who build programs is not easy.  I know, I've done it: sometimes happily, sometimes unhappily.

I deal with problems in managing software development.

There are two main reasons why someone might engage a consultant like myself to help with something.  One is to help start something new.  The other is to fix something broken.  I do both.

It is more fun, generally, to start something new, like a new way of doing things, or a new engineering tribe, or a new piece of software.  I do all of those.

It is more common to have to fix something broken, like a project or a tribe or a development schedule.

If your software projects are in fine shape, you don't need me.  If they are not, I will tell you that, and if it's your fault, I will tell you that too.

Maybe you aren't sure whether they are in fine shape or not.  I will look into them, and if they are in fine shape, I will tell you so, and then you won't need me for anything else unless you want to start something new and I can help you with that.

In my promotional materials, such as this page, I do not use jargon or buzzwords.  I especially abstain from management cliches.  You may be interested in knowing how I got this way.  There are clues in the resumes: