Thanks for reading the blog and I’m glad you found it helpful.

Happy to forward my example to you, however, the most important part of the exercise are in these three steps:
1) identify the stakeholders you need to manage their expectations,
2) ask them for their expectations of you (PM) and of each other
3) identify and address any miss-matched expectations

#3 is where the most value is generated, as clarifying expectations early will prevent big problems downstream, however, #1 and #2 are valuable too as #1 requires you to think about the people you need to care about, and #2 builds engagement and trust.

Send email to me at rogerk@slalom.com and I’ll forward my example matrix.

Thanks again for reading.

Roger

I want to first thank the reader for posting the comment and allowing me the opportunity to respond.

To be clear, this should be thought of as a “and” approach and not an “or” concept. ‘Fostering joint accountability’ is not about replacing longstanding performance management and setting role expectations through performance measurement. Those are crucial to setting the right expectations with employees, ensuring that they are focused on the drivers to their contribution to the organizational objectives, and it’s how we manage out poor performers when they fail to deliver desired results. And yet, they are like guardrails on the freeway: great to have them to prevent a catastrophic event, like going over a cliff or into head-on traffic, however, there’s a lot of damage when you plow up against them.

There is a time and place to hold individuals accountable when their performance is below target, however, ‘fostering joint accountability’ is about setting expectations for the desired, positive behaviors when something goes wrong so individuals will start engaging in correcting mistakes before they are told or forced to. Which environment would most people want to work in: A) An environment where you and your coworkers attempt to hide mistakes and are punished or publically shamed when discovered, or B) one where mistakes are tolerated and people work together to resolve issues quickly and move on? Most of us will pick B, however, most of us don’t have individual performance metrics that create that type of environment.

Since most are not measured on contribution to solving problems and most Project Managers do not have authority over the individuals on their project, the Project Manager must rely on their ability to influence team members to “do the right thing,” especially when something goes wrong. ‘Fostering joint accountability’ is a proactive approach to creating a team shared value about tolerating mistakes and working individually and collaboratively on fixing those mistakes and moving on toward the desired objectives.

Thanks for reading.

Roger

�With your Scenario 2 I would rather impact my Reporting environment rather than my Line-of-Business environment.� And that is your prerogative. I have worked with several replication environments in which the Line-of-Business spans the Publisher and the Subscriber-not my design. And in those cases performance matters a great deal and is absolutely a reason for ensuring you select the correct model (Push or Pull) for the application. Extensive testing against both models has revealed this.

�Just by the extra RAM and be done with it.� This is assuming that: 1. The server(s) have capacity to do so. 2. Your client has budget for additional hardware purchases. 3. Adding RAM will actually solve the problem. For example, does Performance Monitor show that memory pressure exists? Could it be that an under-spec�d disk subsystem is a more likely culprit for performance issues?

�The �bottom-line� is that �performance� is probably the least important in a list of 3-5 considerations when choosing Pull versus Push replication models�� I disagree. Due to budgetary constraints you may have to work with older hardware that is not ideally suited for the demands of SQL Server. Application(s) may be poorly-written and inefficient in their use of database resources. Data consumers will have certain performance requirements. In these instances, to get the best performance with the situation you have been given, choosing the correct replication topology is highly important. Again, extensive testing has often revealed that one model (Push or Pull) is better suited for a specific environment. But as you mentioned, and I�ll agree with you on this, there are other factors, like security and high-availability, to consider. A discussion of those topics was simply beyond the scope of this particular blog post.

________________________________________

For example:
1. It doesn’t discuss security implications for pull versus push models
2. It doesn’t discuss impact on High-Availability architecture
3. It doesn’t discuss impact of where the Agents run

With your Scenario 2 I would rather impact my Reporting environment rather than my Line-of-Business environment.

Plus, you still have to deliver the transactions to the Subscriber in any case in real-time in Pull versus Push. (Which will potentially produce contention, etc.)

Performance “as you describe it” is hardly a reason to choose Pull versus Push model in most cases. Just buy the extra RAM and be done with it.

The “bottom-line” is that “performance” is probably the least important in a list of 3-5 considerations when choosing Pull versus Push replication models…