Contribution 3 - Revision history

Rmonson at 13:39, 6 July 2008

2008-07-06T13:39:57Z

Mark.ramm at 14:38, 3 July 2008

2008-07-03T14:38:30Z

←Older revision		Revision as of 14:38, 3 July 2008
Line 1:		Line 1:
	== Chances are your biggest problem isn't technical at all ==		== Chances are your biggest problem isn't technical at all ==
-

	Right now someone's running a failing project to build a payroll system. Probably more than one someone.		Right now someone's running a failing project to build a payroll system. Probably more than one someone.
Line 8:		Line 7:
	Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.		Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.

-	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is not technology; you need to solve your problem is ~~very old and well~~ established ~~indeed~~. ~~What you need is~~ a ''conversation.''	+	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is not technology; you need to solve your problem is significantly older better established than any of the other technologies in your project. I'm talking about having a good ''conversation.''
		+
		+	Learning to how to approach difficult conversations about important issues, well is one of the core skills that turn a smart architect into an ''effective'' architect.
		+
		+	A couple of things I've learned along the way that improved my effectiveness:

-	~~Learning to treat people with respect, give them the benefit of the doubt, and handle~~ these conversations ~~well is one of the core skills that turn a smart architect into one an effective architect~~.	+	1) Approach these events as conversations -- not confrontations.

-	~~A couple of~~ ~~small bits of~~ advice that ~~can improve your effectiveness:~~	+	If you assume the best about people and treat this as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive. I once heard some advice that has changed my life. Stop treating resistance as something to overcome, think of it instead as a signal that you've got something to learn about the situation. People generally resist for a reason.

-	1) Approach these ~~events as~~ conversations ~~-- not confrontations~~. ~~If you assume the best about people and treat this as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive.~~	+	2) Approach these conversations only after you've got your attitude right.

-	~~2) Approach these conversations only after you've got your attitude right.~~ If you're angry, frustrated, annoyed, or otherwise flustered its very likely that the other person will interpret ~~you~~ non-verbals as indicating that you're on the attack.	+	If you're angry, frustrated, annoyed, or otherwise flustered its very likely that the other person will interpret your non-verbals as indicating that you're on the attack. This will trigger instinctive defensive behavior, at which point you'll push more, and that's all kinds of bad.

-	3) Use these as opportunities to set mutually agreed upon goals. Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people's participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.	+	3) Use these as opportunities to set mutually agreed upon goals.

-	~~If you start with~~ a ~~shared purpose, treat people "problems" as an opportunity~~ to ~~learn, and manage your own emotions~~, you'~~ll not only become~~ more ~~effective~~, you~~'ll also learn a lot~~.	+	Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people's participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.

		+	I've found that if I start with a shared purpose, treat people "problems" as an opportunity to learn, and manage your own emotions, I'm not only more effective, I also learn a lot of new and useful things. Oh, and people like me more. Those ''conversation'' things are surprisingly effective technology.

Rmonson at 17:13, 2 July 2008

2008-07-02T17:13:46Z

←Older revision		Revision as of 17:13, 2 July 2008
Line 4:		Line 4:
	Right now someone's running a failing project to build a payroll system. Probably more than one someone.		Right now someone's running a failing project to build a payroll system. Probably more than one someone.

-	Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn't up the the task?	+	Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java/C++/C#/Smalltalk/Python/etc. wasn't up the the task?

	Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.		Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.

-	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is technology you need to solve your problem is very old and well established indeed. What you need is a ''conversation.''	+	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is not technology; you need to solve your problem is very old and well established indeed. What you need is a ''conversation.''

	Learning to treat people with respect, give them the benefit of the doubt, and handle these conversations well is one of the core skills that turn a smart architect into one an effective architect.		Learning to treat people with respect, give them the benefit of the doubt, and handle these conversations well is one of the core skills that turn a smart architect into one an effective architect.

Mark.ramm: A bit more data

2008-05-14T01:37:07Z

A bit more data

←Older revision		Revision as of 01:37, 14 May 2008
Line 4:		Line 4:
	Right now someone's running a failing project to build a payroll system. Probably more than one someone.		Right now someone's running a failing project to build a payroll system. Probably more than one someone.

-	Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose ~~windows~~ when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn't up the the task?	+	Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn't up the the task?

	Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.		Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.

	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is technology you need to solve your problem is very old and well established indeed. What you need is a ''conversation.''		Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is technology you need to solve your problem is very old and well established indeed. What you need is a ''conversation.''
		+
		+	Learning to treat people with respect, give them the benefit of the doubt, and handle these conversations well is one of the core skills that turn a smart architect into one an effective architect.
		+
		+	A couple of small bits of advice that can improve your effectiveness:
		+
		+	1) Approach these events as conversations -- not confrontations. If you assume the best about people and treat this as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive.
		+
		+	2) Approach these conversations only after you've got your attitude right. If you're angry, frustrated, annoyed, or otherwise flustered its very likely that the other person will interpret you non-verbals as indicating that you're on the attack.
		+
		+	3) Use these as opportunities to set mutually agreed upon goals. Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people's participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.
		+
		+	If you start with a shared purpose, treat people "problems" as an opportunity to learn, and manage your own emotions, you'll not only become more effective, you'll also learn a lot.
		+

Rmonson at 14:10, 13 May 2008

2008-05-13T14:10:25Z

←Older revision		Revision as of 14:10, 13 May 2008
Line 15:		Line 15:
	This work is licensed under a		This work is licensed under a
	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+	Back to [[97 Things Every Software Architect Should Know]] home page

Mark.ramm at 14:15, 10 May 2008

2008-05-10T14:15:41Z

←Older revision		Revision as of 14:15, 10 May 2008
Line 6:		Line 6:
	Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn't up the the task?		Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn't up the the task?

-	Most projects are built by people, and those people are the foundation for success and failure.	+	Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.
		+
		+	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is technology you need to solve your problem is very old and well established indeed. What you need is a ''conversation.''

Mark.ramm: Chances are your biggest problem isn't technical at all

2008-05-10T14:06:49Z

Chances are your biggest problem isn't technical at all

New page

== Chances are your biggest problem isn't technical at all ==

Right now someone's running a failing project to build a payroll system. Probably more than one someone.

Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn't up the the task?

Most projects are built by people, and those people are the foundation for success and failure.

By [[Mark Ramm]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

←Older revision		Revision as of 13:39, 6 July 2008
Line 1:		Line 1:
	== Chances are your biggest problem isn't technical at all ==		== Chances are your biggest problem isn't technical at all ==

-	Right now someone's running a failing project to build a payroll system. Probably more than one someone.	+	Right now someone's running a failing project to build a payroll system. Probably more than one someone.

-	Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java/C++/C#/Smalltalk/Python/etc. wasn't up ~~the~~ the task?	+	Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java/C++/C#/Smalltalk/Python/etc. wasn't up the task?

-	Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.	+	Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about building systems that help make those people successful.

-	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is not technology; ~~you need to solve~~ your problem is significantly older better established than any of the ~~other~~ technologies in your project. I'm talking about having a good ''conversation.''	+	Equally, there's a good chance that there's someone who's "just not doing it right" and is undermining the project. In these cases, the solution is not technology; your problem is significantly older better established than any of the technologies in your project. I'm talking about having a good conversation.

-	Learning to how to approach difficult conversations about important issues, ~~well~~ is one of the core skills that turn a smart architect into an ''effective'' architect.	+	Learning how to approach difficult conversations about important issues, is one of the core skills that turn a smart architect into an effective architect.

-	A couple of things I've learned along the way that improved my effectiveness:	+	A couple of things I've learned along the way that improved my effectiveness:

-	1) Approach these events as conversations -- not confrontations.	+	1) Approach these events as conversations -- not confrontations.

-	If you assume the best about people and treat ~~this~~ as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive. I once heard some advice that ~~has~~ changed my life. Stop treating resistance as something to overcome, think of it instead as a signal that you've got something to learn about the situation. People generally resist for a reason.	+	If you assume the best about people and treat the conversation as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive. I once heard some advice that changed my life. Stop treating resistance as something to overcome, think of it instead as a signal that you've got something to learn about the situation. People generally resist for a reason.

-	2) Approach these conversations only after you've got your attitude right.	+	2) Approach these conversations only after you've got your attitude right.

-	If you're angry, frustrated, annoyed, or otherwise flustered ~~its~~ very likely that the other person will interpret your non-verbals as indicating that you're on the attack. This will trigger instinctive defensive behavior, at which point you'll push more, and that's all kinds of bad.	+	If you're angry, frustrated, annoyed, or otherwise flustered it’s very likely that the other person will interpret your non-verbals as indicating that you're on the attack. This will trigger instinctive defensive behavior, at which point you'll push more, and that's all kinds of bad.

-	3) Use these as opportunities to set mutually agreed upon goals.	+	3) Use these as opportunities to set mutually agreed upon goals.

-	Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people's participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.	+	Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people's participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.

-	I've found that if I start with a shared purpose, treat people "problems" as an opportunity to learn, and manage your own emotions, I'm not only more effective, I also learn a lot of new and useful things. Oh, and people like me more. Those ''conversation'' things are surprisingly effective technology.	+	I've found that if I start with a shared purpose, treat people "problems" as an opportunity to learn, and manage your own emotions, I'm not only more effective, I also learn a lot of new and useful things. Oh, and people like me more. Those conversation things are surprisingly effective technology.
		+