The Architect

[Tim Ottinger]

In companies of size, there are different issues. Most of them have to do with the "Law of the 2nd Floor" but there are some that are purely due to good reasons and history.

Most large orgs that switch to agile have a large number of really good people who have been promoted out of the development teams. They are often called "architect", "system engineer", "chief developer", "senior development", or the like.

The problem is loyalty. These people earned a position at the company with years of solid service and good judgment and peer respect. Most of them have storied careers, and are internally famous for their work.

Now they're all middle-management. 

Agile doesn't define a place for people whose job is no longer to tell the programmers how to design the code, to push assignments to the "best" individuals. It doesn't envision (and actually rejects) the idea of a master programmer surrounded by obedient minions.

But they earned their place. And they're good. Now what? 

This question comes up a lot, because a lot of my clients are huge. Before I give my solution, I would love to collect yours.

Tim

[Mark Levison]

Rotate them through the teams that do work? Try some of the Spotify Strategies? (see Henrik's paper).

Cheers

Mark (vy tired)

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Cheers
Mark Levison
Agile Pain Relief Consulting | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24

[George Dinwiddie]

Tim,

I had a client that promoted all their best developers to architect, and
it became a career-limiting move to touch code. So they became
powerpoint jockeys, and the best developers were mid-level. (I hear
they've improved since then, and architects can code again.)

My feeling is that architects quickly lose their edge when they live in
ivory towers. And they lose their influence. Their designs don't always
work in practice, and they're not always put into practice.

I advise architects who work on the teams, with day to day code. They
also have a collective responsibility to look after the long term and
across-the-enterprise issues, with the architects on other teams. And
they have a responsibility to mentor their team mates in architecture.

I've heard Rebecca Parsons speak on this topic, and Thoughtworks follows
a similar strategy.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Mike Bowler]

I agree with George although I'd word it a bit stronger.  I've never met an architect who kept his or her edge after they stopped writing code.  All the best ones continue to code, even if it's just in their spare time.

That means that many of these people who used to be phenomenal programmers will have lost that edge that had made them famous within the company.  Moving them back into a development role could be devastating if they are shown to now be not as good as the others.  Some will welcome that chance to return to active development and others won't.

This is a tricky question that doesn't have a single answer.  It really depends on the personality of the specific architects.

Having said all that, what we really want is a craftsmanship model where the very best work on the most challenging work.  The problem moving to this model is that many large companies have deliberately blunted the skills of their very best people so the skills balance is very lopsided.

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Mike Bowler

President, Gargoyle Software Inc.

Cell: 905 409-7052

Find me at LinkedIn, Google+, Facebook, Twitter, Flickr or SendOutCards

[Glenn Waters]

Some good replies already. Find a way to get them out of the business of telling others what to do through architecture and get them into the mode of mentoring, providing leadership in design discussions, and getting back into the code (even if only in a small way).

Glenn

[Yves Hanoulle]

For me the core issue is that most companies have no real carreer plan for developers.

- junior developer

- after 2 years ( really?) senior developer 

- architect (end if the line)

or manager: more options

Construx (the company of Steve Mc connel ) has on their website a developer carreer plan.

That might also help to let companies know, there are more options to promote people...

Y

Scrambled by my Yphone

[Tim Ottinger]

Still not tipping my hand just yet, but I don't see the need for a career path, really.

I want to increase in respect, autonomy, and compensation. If that comes without a path and no titles, and I'm not artificially constrained to a low wage because I'm a "mere coder" then I'm good. 

After all, Ward Cunningham is a "mere coder" (not hardly!) and he has well-deserved respect, autonomy, and lord-i-sure-hope compensation.

Career pathing tends to give an "up or out" mentality, which degrades and devalues technical people. It's not the lack of a career path, it's the stupid artificial celiings on respect, autonomy, and compensation that kill me.

But maybe we're saying the same thing. :-)

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileinaflash.com/
http://agileotter.blogspot.com/

[Mark Levison]

Tim - while I mostly agree I notice that your sig says you're a senior consultant. In addition titles often help people when they leave one company and move to another. They act as a sort of bona fide.

Cheers
Mark - human

[Peter Green]

Adobe has a path for "mere coders" that includes principle scientist (director equivalent), and Adobe Fellow (VP equivalent). Those titles help with the requisite responsibility, respect, and autonomy. 

---Peter

[George Dinwiddie]

Mark,

On 3/1/13 9:17 AM, Mark Levison wrote:
> Tim - while I mostly agree I notice that your sig says you're a senior
> consultant. In addition titles often help people when they leave one
> company and move to another. They act as a sort of bona fide.
>
> Cheers
> Mark - human
>
> On Mar 1, 2013 1:47 AM, "Tim Ottinger" <tott...@gmail.com

> <mailto:tott...@gmail.com>> wrote:
[snip]

> --
> Tim Ottinger, Sr. Consultant, Industrial Logic
> -------------------------------------
> http://www.industriallogic.com/
> http://agileinaflash.com/
> http://agileotter.blogspot.com/

Or maybe that's Senõr Consultant. ;-)

In this case, I suspect the title is more for the benefit of customers
and potential customers. For employees (at least those with the employee
mindset), I suspect that the customer is their employer, so these are
very related.

- George

[Yves Hanoulle]

Scrambled by my Yphone

Op 1-mrt.-2013 om 15:17 heeft Mark Levison <ma...@mlevison.com> het volgende geschreven:

Tim - while I mostly agree I notice that your sig says you're a senior consultant. In addition titles often help people when they leave one company and move to another. They act as a sort of bona fide.

Cheers
Mark - human

On Mar 1, 2013 1:47 AM, "Tim Ottinger" <tott...@gmail.com> wrote:

Still not tipping my hand just yet, but I don't see the need for a career path, really.

I want to increase in respect, autonomy, and compensation. If that comes without a path and no titles, and I'm not artificially constrained to a low wage because I'm a "mere coder" then I'm good. 

After all, Ward Cunningham is a "mere coder" (not hardly!) and he has well-deserved respect, autonomy, and lord-i-sure-hope compensation.

Which is also a carreer path:

No titles.

My first boss helped people grow, yet as he had a small company he felt that some people outgrow his company and he is actually happy when people leave and grow bigger then his company.

He won't hold on to people and limits their growth.which is cool as he hire a lot of people fresh out of school(which don't get a lot of options in other companies)

There is a carreer path to help grow, yet not hold on to them (which limits all parties...)

[Yves Hanoulle]

Scrambled by my Yphone

Op 1-mrt.-2013 om 15:17 heeft Mark Levison <ma...@mlevison.com> het volgende geschreven:

Tim - while I mostly agree I notice that your sig says you're a senior consultant. In addition titles often help people when they leave one company and move to another.

I actually think they limit my options.

Then I fit into a database of a recruiter who will only think of me as a xxx

 today I call myself: 

Creative collaboration agent.

[Jean-Charles Meyrignac]

The goal of managers is to provide satisfaction.

Their role is to satisfy the upper management, the workers and the clients.

This is less selfish than workers, who tend to satisfy themselves first.

Since they generally have plenty of technical experience, they should not rest on their laurels but extend their human skills (in my opinion, you cannot extend both your technical and your human skills at the same time, these are 2 different axes).

I would suggest that they act as mentors, because they can share their experience.

They should be able to describe the product's vision, because they know how to write the product and how to make it concrete (which is not the case of upper-management).

They also tend to understand the company better than anyone else.

Progressing in the hierarchy is not always the best option, see http://en.wikipedia.org/wiki/Peter_Principle

About intrinsic motivation, Dan Pink ( http://www.youtube.com/watch?v=u6XAPnuFjJc ) explains that they are basically:

 - autonomy
 - mastery (Peter Norvig explains that mastery takes 10 years: http://norvig.com/21-days.html )

 - purpose

It's true for workers, but not for managers.

Managers want to have responsibilities, because they already reached mastery.

In my opinion, everybody wants to:

1) show that he is able (mastery)

2) have fun with their work (when you have fun, you work effortlessly)

3) be recognized (money or sincere acknowledgment)

4) organize himself (autonomy, responsibility)

5) do things that matter (purpose)

Remove 3 of these motivators, and people will lose all motivation.

And the real reason to quit is:
http://www.alaisterlow.com/employees-leave-managers-not-companies/

Loyalty is not a problem because companies are rarely loyal to their employees.

JC

[Yves Hanoulle]

Scrambled by my Yphone

Op 1-mrt.-2013 om 17:46 heeft Jean-Charles Meyrignac <jcmey...@gmail.com> het volgende geschreven:

The goal of managers is to provide satisfaction.

Really?

Their role is to satisfy the upper management, the workers and the clients.

This is less selfish than workers, who tend to satisfy themselves first.

That is not my experience.

A lot of managers I know are going up the ladder because they care more about themselves then others.

Since they generally have plenty of technical experience, they should not rest on their laurels but extend their human skills (in my opinion, you cannot extend both your technical and your human skills at the same time, these are 2 different axes).

I would suggest that they act as mentors, because they can share their experience.

They should be able to describe the product's vision, because they know how to write the product and how to make it concrete (which is not the case of upper-management).

That depends on type of companies. A CEO who created the company might know more ten anyone else...

They also tend to understand the company better than anyone else.

Progressing in the hierarchy is not always the best option, see http://en.wikipedia.org/wiki/Peter_Principle

Agree.

About intrinsic motivation, Dan Pink ( http://www.youtube.com/watch?v=u6XAPnuFjJc ) explains that they are basically:

 - autonomy
 - mastery (Peter Norvig explains that mastery takes 10 years: http://norvig.com/21-days.html )

 - purpose

It's true for workers, but not for managers.

Managers want to have responsibilities, because they already reached mastery.

that is a bias. And one that most managers think, to me the Peter principle actually says its wrong

In my opinion, everybody wants to:

Yes and no. Some people don't want to do this at work.

1) show that he is able (mastery)

2) have fun with their work (when you have fun, you work effortlessly)

Depends on culture.

I have coached people who think it's bad to have fun.

3) be recognized (money or sincere acknowledgment)

Some Unsure people i know, Don't want that, they think they don't deserve it.

4) organize himself (autonomy, responsibility)

Just finished a workshop were people had to organize themselves and the biggest block was people that did not want to make choices. (Afraid to loose things)

They rather wanted me to make choices , so they could blame me when I made them :-)

I agree we ask want that, yet a lot of people don't realize they already have that. We can all at anytime walk away of everything in our life. Not doing that is autonomy. ( ok all is wrong, those in prison and hospitals can not )

5) do things that matter (purpose)

Yes, yet some don't want that at work.

Remove 3 of these motivators, and people will lose all motivation.

And the real reason to quit is:
http://www.alaisterlow.com/employees-leave-managers-not-companies/

Loyalty is not a problem because companies are rarely loyal to their employees.

There was a really interesting article that I read this. Week about a company with a "no fire rule "

Really really powerfull loyalty ( and all the consequences with it)

JC

[Jean-Charles Meyrignac]

On Fri, Mar 1, 2013 at 6:07 PM, Yves Hanoulle <yv...@hanoulle.be> wrote:

The goal of managers is to provide satisfaction.

Really?

In theory yes, in practice, you are totally right !

 

That is not my experience.

A lot of managers I know are going up the ladder because they care more about themselves then others.

Agree too. But this behavior exists mostly in large companies, where people crave for power. Greed is a powerful motivator, but in my opinion, it's the worst motivator, because it depends on the carrot. When the carrot disappears, motivation vanishes (and the motivation to quit increases).

That depends on type of companies. A CEO who created the company might know more ten anyone else...

In 30 years of software, I never met such a CEO. Software is younger and more difficult than other industries.

It's true for workers, but not for managers.

Managers want to have responsibilities, because they already reached mastery.

that is a bias. And one that most managers think, to me the Peter principle actually says its wrong

I recently wrote that "drags" tend to be assigned to management.
Since you cannot develop both your technical and your human skills simultaneously, they developed their human skills first (and thus are very bad at doing technical things).

In french, I call that "savoir faire" against "faire savoir".

 

1) show that he is able (mastery)

2) have fun with their work (when you have fun, you work effortlessly)

Depends on culture.

I have coached people who think it's bad to have fun.

I agree too, some people enjoy suffering, mostly because of their own beliefs.

 

3) be recognized (money or sincere acknowledgment)

Some Unsure people i know, Don't want that, they think they don't deserve it.

Yes, some people enjoy suffering.

I was in this case a few years ago ;-)

4) organize himself (autonomy, responsibility)

Just finished a workshop were people had to organize themselves and the biggest block was people that did not want to make choices. (Afraid to loose things)

They rather wanted me to make choices , so they could blame me when I made them :-)

I agree we ask want that, yet a lot of people don't realize they already have that. We can all at anytime walk away of everything in our life. Not doing that is autonomy. ( ok all is wrong, those in prison and hospitals can not )

From my experience, people behave like slaves because of their culture, but it's possible to make them realize that they can gain autonomy, especially when they realize that they are suffering uselessly.

5) do things that matter (purpose)

Yes, yet some don't want that at work.

Why do you try agile with these people ?

It appears to me that they like the way they work, agile (or any change) is just a bother to them.

As you cannot change anybody outside of yourself, you can just make them realize their own condition, in the hope that they'll be interested in your approach.
 

There was a really interesting article that I read this. Week about a company with a "no fire rule "

Really really powerfull loyalty ( and all the consequences with it)

I'm mitigated about loyalty.

Keeping people a long time in a company can be a great asset (because of the cumulated knowledge), but also a great impediment (for personal evolution: people like comfortable situations, even though their job is uninteresting).

I believe that new employees bring new ideas, because older employees dislike challenging their ideas/process.

But this is true with software, not with other industries.

JC

[Peter Green]

> Managers want to have responsibilities, because they already reached mastery.

Mastery is not a destination one reaches. Mastery is a mindset of seeking continual improvement.

---Peter

[Mike Pearce]

Hi,

We had a flat structure where I work, there were only developers, senior developers, an architect and me, the "manager". I tried to keep it this flat, but the feedback I had was that the company lacked career progression. My experience says that, you still need some kind of path for people to follow. Not everyone you employ will be interested in their future, or even know what it is they want to do. They just know that they've got to do something in order to succeed and a career path "feels" like the right thing.

It's about educating people that, it's not *just* about a career path, it's also about mastery and purpose (as Dan Pink says, cited by someone above). However, some people just don't get it, or don't want to get it - and that's OK too. I can't force people to care about their futures, I can only be there when they're ready to care.

As for an answer to Tims question - I would ask these middle managers what they wanted, where they thought they could provide the most value *and* enjoy the job they do, then help them attain that. From the way it's written, and other posts, I'd suspect it was about getting back to the coal-face and doing the things that got them promoted in the first place. Maybe a good starting point is some kind of internal incubator - get them cutting code for prototypes in a build-measure-learn loop with a view to integrating it back into the teams. Or maybe training is something that might work - coding katas and the like?

I'm interested to hear your solution Tim.

Cheers,

Mike

[Yves Hanoulle]

2013/3/1 Jean-Charles Meyrignac <jcmey...@gmail.com>

On Fri, Mar 1, 2013 at 6:07 PM, Yves Hanoulle <yv...@hanoulle.be> wrote:

The goal of managers is to provide satisfaction.

Really?

In theory yes, in practice, you are totally right !

 

That is not my experience.

A lot of managers I know are going up the ladder because they care more about themselves then others.

Agree too. But this behavior exists mostly in large companies, where people crave for power. Greed is a powerful motivator, but in my opinion, it's the worst motivator, because it depends on the carrot. When the carrot disappears, motivation vanishes (and the motivation to quit increases).

That depends on type of companies. A CEO who created the company might know more ten anyone else...

In 30 years of software, I never met such a CEO. Software is younger and more difficult than other industries.

sorry for you, I met a few.

I think that even Bill Gates & Steve Jobs had that in them for a long time.

The story goes that the first ten years of MS, no line of code left to a client without that Bill had seen it.

(we can discuss the micromanagement style, yet it's an example of such a CEO and closer to home I met a few of these in Belgium.

(agreed in my cases all small startups.)

I alos think that a more known is Michael from Target Process, I have the feeling he too is such a ceo. (I might be wrong as I only know michael from a distance)

 

It's true for workers, but not for managers.

Managers want to have responsibilities, because they already reached mastery.

that is a bias. And one that most managers think, to me the Peter principle actually says its wrong

I recently wrote that "drags" tend to be assigned to management.
Since you cannot develop both your technical and your human skills simultaneously,

do you have prove of that?

it looks correct, yet it's a hard statement that I find hard to prove

 

they developed their human skills first (and thus are very bad at doing technical things).

In french, I call that "savoir faire" against "faire savoir".

 

1) show that he is able (mastery)

2) have fun with their work (when you have fun, you work effortlessly)

Depends on culture.

I have coached people who think it's bad to have fun.

I agree too, some people enjoy suffering, mostly because of their own beliefs.

 

3) be recognized (money or sincere acknowledgment)

Some Unsure people i know, Don't want that, they think they don't deserve it.

Yes, some people enjoy suffering.

I was in this case a few years ago ;-)

4) organize himself (autonomy, responsibility)

Just finished a workshop were people had to organize themselves and the biggest block was people that did not want to make choices. (Afraid to loose things)

They rather wanted me to make choices , so they could blame me when I made them :-)

I agree we ask want that, yet a lot of people don't realize they already have that. We can all at anytime walk away of everything in our life. Not doing that is autonomy. ( ok all is wrong, those in prison and hospitals can not )

From my experience, people behave like slaves because of their culture, but it's possible to make them realize that they can gain autonomy, especially when they realize that they are suffering uselessly.

yes and some never recover :-( 

 

5) do things that matter (purpose)

Yes, yet some don't want that at work.

Why do you try agile with these people ?

these days, the innovators and the early adopters have already long time ago made the switch to agile.

when I am (and I assume most of us) are asked to coach a team, the chance is pretty high that we are talking about late majority or even laggards, who in my opnion (and yes that is a bias) have the kind of behaviro we are discussing here

the laggers don't look for purpose in work

I think so because the once who do look for purpose would have discovered agile earlier 

(yes it's a big bias, stll knowing it's a bias, does not help me from thinking it's wrong, so if you see a gap in my reasoning, please tell me)

I did not meant this gap ;-)

 

It appears to me that they like the way they work, agile (or any change) is just a bother to them.

As you cannot change anybody outside of yourself, you can just make them realize their own condition, in the hope that they'll be interested in your approach.

 

There was a really interesting article that I read this. Week about a company with a "no fire rule "

Really really powerfull loyalty ( and all the consequences with it)

I'm mitigated about loyalty.

Keeping people a long time in a company can be a great asset (because of the cumulated knowledge), but also a great impediment

I saw this in a team a few years back, that was teh first team I ever saw, wheer the team had been together without any change for a couple of years. that is so unique in IT, it took me a while to realize it was bad. 

yes it was an agile team. at one point they were the best team of teh company, when I cane, they had been passed by at least one ofther team (I had to compare, but that is what was the situation) and having me (as an external consultant helped, yet it was much harder as it was the first outside person and they thought I was theere to help the other teams and they did not need help...

;-)

 

(for personal evolution: people like comfortable situations, even though their job is uninteresting).

I believe that new employees bring new ideas, because older employees dislike challenging their ideas/process.

no fire rule <> not bringing in new people

 

But this is true with software, not with other industries.

I think it's true everyweher, because in software we change faster it's more true ;-)

[Jean-Charles Meyrignac]

Yves wrote:

I think that even Bill Gates & Steve Jobs had that in them for a long time.

The story goes that the first ten years of MS, no line of code left to a client without that Bill had seen it.

(we can discuss the micromanagement style, yet it's an example of such a CEO and closer to home I met a few of these in Belgium.

(agreed in my cases all small startups.)

I alos think that a more known is Michael from Target Process, I have the feeling he too is such a ceo. (I might be wrong as I only know michael from a distance)

I met a few CEO who were able to code, but they were psychopaths, and thus pretty bad at managing people, but their main job is to provide a vision of the company.

 

Since you cannot develop both your technical and your human skills simultaneously,

do you have prove of that?

it looks correct, yet it's a hard statement that I find hard to prove

I believe it comes from the brain's lateralization:
http://en.wikipedia.org/wiki/Cerebral_hemisphere

From my experience, the only thing that develops them simultaneously is meditation, in other words doing actively nothing ;-)

 

 

these days, the innovators and the early adopters have already long time ago made the switch to agile.

when I am (and I assume most of us) are asked to coach a team, the chance is pretty high that we are talking about late majority or even laggards, who in my opnion (and yes that is a bias) have the kind of behaviro we are discussing here

the laggers don't look for purpose in work

I think so because the once who do look for purpose would have discovered agile earlier 

(yes it's a big bias, stll knowing it's a bias, does not help me from thinking it's wrong, so if you see a gap in my reasoning, please tell me)

Very interesting, it seems pretty obvious.

 

Mike wrote:

As for an answer to Tims question - I would ask these middle managers what they wanted, where they thought they could provide the most value *and* enjoy the job they do, then help them attain that.

I have to retract what I said before: people do not seek fun, they seek pleasure and avoid pain, whatever that means for them.

What does "pleasure" and "pain" mean for them ?

 

From the way it's written, and other posts, I'd suspect it was about getting back to the coal-face and doing the things that got them promoted in the first place.

One paradox is that people want job's progression, but they still want to remain in their comfort zone.

For example, if I'm a coder and I was promoted to management, should I continue coding, or should I learn how to manage ?

And this is exactly why I explained that managers have to work for satisfaction.

If they keep coding, they don't develop their managing skills (and I believe that's what Peter Principle is about).

But when they start managing, they realize that they start from scratch, and that they are pretty incompetent at managing.

And I saw a lot of people in this case: they don't want to assume their new role, and it hurts everybody and also the company.

They were excellent coders, and they are now terrible managers and not so excellent coders.

 

Maybe a good starting point is some kind of internal incubator - get them cutting code for prototypes in a build-measure-learn loop with a view to integrating it back into the teams. Or maybe training is something that might work - coding katas and the like?

It seems that Google used the 20% to do that, but from what I heard, this practice tends to disappear.

If I had an entrepreneur's profile, why would I want to develop my idea at Google for their benefit, when I could seek for investment on my project ?

If I have no family, I can handle the risks alone.

If I have a family, I probably have other priorities.

JC

[Tim Ottinger]

Big corps have issues that small companies do not. 

Chief among them is the "respected middle" of people who have risen "above" the ranks of mere developers and testers, and now are qualified to control other people's work. They are the "masters" in the "masters and minions" game.

And then Agile happens. Now the teams don't need/want/use individual assignments and accountability to schedule. They don't need to be told what/how/when. They need to self-tutor and grow together. They don't want/need/use ranking.

So the thing to NOT do is make them bosses, and switch the title to SM ro PO, because that's not what SM or PO means. POs don't have anything to do with how the work is done process-wise, and SMs don't choose stories for the team or assign work to individuals. POs and SMs are hard servant leadership jobs.

Architects have it easier than middle managers. 

Teams need architectural support, but they don't need people to design their code for them. The "I tell you how to work" paradigm is gone, but the hard work of fitting the process to the platform goes on. Dictating architectural ideals from white towers? Dead. Helping the team to find the components and technologies that will make the project successful? Golden. Have trouble with builds, servers, parallelism, threading? An architect often has the savvy and connections to help you out with those, and with 3rd party integration problems. 

An architect can serve the team by doing highly technical supporting work.It still matters, and they still get to be a kind of wizard. The team can help test and improve the architect's theories, provided those theories support the functionality of the app and doesn't work at cross-purposes.

Also, the architect can take a different tack and be more of a systems integrator, ensuring that the various apps and components of a larger initiative (well beyond "story", "release" or even "epic" range) are integrated early and often, and resolving the issues that arise between the parts. Shepherding such an initiative to market takes a fairly deep amount of technical skill and a lot of dedication, but you end up having a huge impact on the market when the big initiative deploys cleanly and a kind of network effect boosts sales.

The problem, still, is that the architect has to give up a certain hierarchical status to do these things. He can't be boss, and can't "make people do what I say" anymore. He serves larger goals, even as a specialist.

The middle managers? They have a much harder problem. 

What do you do? 

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tim Ottinger]

I wasn't trying to stop the conversation. I really just wanted your opinions on what makes sense for architects as a supportive role, and do you think that makes more sense than the "master programmer who directs the minions."

I have witnessed a supportive architect at work. She is a rockstar. She's an unimposing, humble, thoughtful woman who just digs in to problems. She helped the team port from Windows to Linux, down to building the first cmake scripts and testing on both platforms. She helped choose a gui framework, and did the research so that she could do pairing and code review in that framework, and help drive best practices. She helped locate tools and libraries. She helps with memory leaks and integration problems. She's amazing. 

Another member of her team tells people what code to write, and explains to them that being an architect means "anything i say is right by default, unless you can prove otherwise" and has frequently derailed the team by dumping untested code on them and demanding that they integrate it (without regard to other features they've promised to deliver). He's actually a nice guy and smart, but his approach and image of the role doesn't work.

Hence: 

* An architect can serve the team by doing highly technical supporting work.

* Also, the architect can be more of a systems integrator

* Architects can shepherd multi-product/multi-component initiatives

And of course:

* He can't be "the boss"

* He can't make people do what he says.

[Jean-Charles Meyrignac]

On Thu, Mar 7, 2013 at 5:05 PM, Tim Ottinger <tott...@gmail.com> wrote:

I wasn't trying to stop the conversation. I really just wanted your opinions on what makes sense for architects as a supportive role, and do you think that makes more sense than the "master programmer who directs the minions."

In fact, there is no simple solution.

What you describe is about the maturity of a person.

Younger people are arrogant because they want to prove that they can do something worthy (look at me, see how I'm a nice guy and I know how to work).
Older people already know that they can do, so they don't have to prove anything.

Maturity comes from life, in general when people have a child older than 15 years (when the first conflicts appear).

Personally, I have no children, but I worked on my own self-restrictions, to remove them and discover what I am, instead of what I can do.

So in short, your problem is not about technical coaching, but about personality coaching.

Emotional Intelligence is probably the simplest approach to help these people progress, even though I prefer mindfulness over EI (but it's less "intellectual", and we are in an intellectual ecosystem).

The main idea is to stop them focusing on their comfort zone (which is usually technical), and help them improve their interpersonal skills (emotions, conflicts, spontaneity, ...).

Agility has nothing to do with this.
I encountered immature agile coaches, but in general, coaching makes them more mature.

This is why it's better to coach people than to boss them.

JC

[Yves Hanoulle]

Scrambled by my Yphone

Which brings for me the sentence: everyone can use a coach ,

yet this is preaching for the choir...

Mm, time to call mine...

[Peter Green]

I agree with what they need to focus on, but don't think it is about age, but maturity, two things which in my experience are only loosely correlated. 

---Peter

[Mark Kilby]

Jean-Charles:

Basically I agree that it's more personal than agile, but I know that the concept of "reflecting/retrospecting" had a tremendous impact on me many years ago.  

However, I don't think there is a direct correlation between age and maturity.  I've seen many that disprove that. ;)  I've also see young enginners/coaches/architects that practiced personal reflection and I would consider very "mature" (or "agile")

Tim:

I like the examples you provided and your list of "qualities" in the "agile architect" (if I can use that label):

: 

* An architect can serve the team by doing highly technical supporting work. (and probably invites others to collaborate on that work if they are willing)

* Also, the architect can be more of a systems integrator (maybe system facilitator?)

* Architects can shepherd multi-product/multi-component initiatives (+1 on the shepherding concept for an architect)

* He can't be "the boss" (probably doesn't feel the need)

* He can't make people do what he says. (he would rather hear everyone's perspective and ideas)

Maybe add to Tim's list as:

• willing to help the team through any thorny technical problem (but might wait when they ask for help)
• willing to laugh at themselves and their "solutions" why producing valid points and counter-points to other solutions

Maybe I'm referring to a humility test?

Mark Kilby

http://about.me/mckilby

“Our lives begin to end the day we become silent about things that matter.”

- Martin Luther King, Jr.

[Jean-Charles Meyrignac]

Mark:

Basically I agree that it's more personal than agile, but I know that the concept of "reflecting/retrospecting" had a tremendous impact on me many years ago.  

 

However, I don't think there is a direct correlation between age and maturity.  I've seen many that disprove that. ;)  I've also see young enginners/coaches/architects that practiced personal reflection and I would consider very "mature" (or "agile")

I agree with you, but I never said that maturity was coming with age.

In fact, maturity appears when you take full responsibility of your life, and this was what happened to me 4 years ago, since I had no other choice than to accept what I was living.

Most people want to avoid what they are living, even though they don't have the choice.

Agility and maturity are very different: maturity is an internal process, and agile is mostly an external process.

However, I don't believe about the reflection/retrospection process (though I believe in Aha!), and I have a nice example to corroborate my point of view: Woody Allen.

Woody Allen spent most of his life doing his psychoanalysis, so you cannot say that he's not self-reflecting on himself.
But the word "mature" does not qualify his personality, unless we don't have the same definition ;-)

JC

[Mark Kilby]

Interesting point Jean-Charles and sorry for the misinterpretation

For me, personal retrospection means that you will not only reflect, but you will also take action. Personally applying that agile concept (and applying Avery's Responsibility Process Model) is what helped me inspect and adapt.

It is my experience that the "humble rock stars" that Tim mentioned usually have a similar personal retrospection process and is one of the things I look for (or coach) in an agile architect/coach/Scrummaster/leader.

So for me, I see a connection between reflection-with-action and evolving maturity of the individual ... And I'm also willing to acknowledge there may be other perspectives.

Tim: We may be getting off track from your request. Did you get what you needed?

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Tim Ottinger]

Not really. I was hoping to have less abstract discussions about maturity and career pathing and a few more examples of what we've actually seen happen. 

I certainly appreciate how it's hard, and how people have to have affinity for work, and talent, and skills need to be current. 

I was reflecting on my big corporate clients of the past decade or so, and how many of them did not have architects gainfully employed *improving* and *easing* the burden of development, and how many had them doing "architectural ideal enforcement" and pontification. 

The best ones can offer so much, and maybe everyone squanders their wealth in the same ways. If so, I'm now more aware and less joyful.