> - They're brilliant, I mean very smart people (in an almost academic way?) That's good, though sometimes the "academic way" can be a problem when the aim is

> - They're brilliant, I mean very smart people (in an almost academic way?) That's good, though sometimes the "academic way" can be a problem when the aim is to build a commercial product: the engineering vs research dichotomy. > - They have a big appetite for adding complexity to systems That's not good. One way to influence is to promote simplicity on the grounds of testing and maintenance. If you mandate unit tests and a minimum level of code coverage, for instance, which is useful but which developers tend to hate doing, it may nudge people into thinking about simplicity. There's also the good practice of not doing more than currently necessary. At some point it's down the the person of authority to accept or reject change proposals and to promote/enforce good practices. > - They also have a big appetite for adding work to their own plates That's good as long as they can consistently deliver and they don't overwhelm themselves . > - Their code has no consistent style That's usually sorted by having a formally described (in a document) coding style and conducting code reviews. People will quickly closely follow the prescribed style in only just to avoid having their code rejected in code review on style grounds.