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.
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:
|The Full Monty|