Eight to Late

Sensemaking and Analytics for Organizations

Conflicts over identity: on the relationship between software developers and project managers

with 19 comments


The relationship between software developers and project managers is often fraught with  conflict.  Yet they have to get along professionally:  the success of a software project depends to a large extent on whether or not they can work together. A paper entitled Stop whining, start doing! Identity conflict in project-managed software production, published in the May 2009 issue of Ephemera, delves into this issue by looking at how the two parties view themselves in relation to each other.  This post is a summary and review of the paper.

A quick word or two before diving into the paper. First, identity conflict occurs when a person or a group feels that their  sense of self (i.e. their identity) is threatened or denied legitimacy and respect. Second,  although the title of the paper suggests that  it deals with identity conflict in project-managed software production, the authors’ focus is considerably narrower: the analysis presented in the paper is based on selected Slashdot discussion threads involving software developers and project managers.  In effect, the authors draw their conclusions about identity conflict in software production based on  opinions expressed online forums.   It is, I think,  stretch to read too much into such exchanges. I’ll have more to say about this in the final section of this post.

The authors of the paper, Peter Case and Erik Pineiro, begin their analysis by noting that although project managers are usually above programmers in the organizational hierarchy, the relationship is complicated by two factors:

  1. Project managers usually do not need (and often lack) the educational qualifications possessed by programmers.
  2. Project managers usually do not have the depth of technical knowledge that programmers have.

These two conditions often lead to the view amongst programmers that they (the programmers) have a higher organizational status (or matter more) than project managers do.

The authors end their introduction with the observation that the skills of programmers are necessary for the creation of software, but equally necessary is the need to direct software building efforts using some form of project management. This observation underlines the symbiotic relationship between developers and project managers. On the other hand the differences between the two disciplines is also a source of conflict between the two parties. The main aim of the paper is to highlight how this conflict plays out  in online discussions involving developers and project managers.

Research Methodology

Case and Pineiro base their research on an analysis of contributions to online discussions on Slashdot. A large number of Slashdot contributors are programmers. The discussions cover a range of topics of interest to coders – from the merits of particular technologies, to outsourcing, aesthetics and personal philosophies of  programming. The authors use two ideas (or, more accurately, lenses) to interpret the data, the data being individual contributions to discussions.

First, the authors contend that contributors to Slashdot are:

… bringing about  social effects through their displays of technical bravado, expressions of aesthetic preference and espousals of dissent, resistance and subversion.

In particular, when discussing the relationship between programmer and project managers, contributors – through the discussion – are creating (or confirming) a certain view of the relationship between the two parties.  In doing so, they are enacting their own identities (as members of a particular guild). They do so in opposition to the other party – i.e. by setting themselves apart by negating the  skills, knowledge and work of the other.

Second, the work that programmers do has a certain value in the marketplace – i.e it is created because of its (direct or indirect) commercial value. This has two consequences:

  1. Programmers feel that they have to compromise on quality (or aesthetics) because of time pressures and, on the other hand, project managers feel that programmers do not understand the commercial imperative to move the project forward.
  2. Both sides feel that their own specialized area of knowledge – technical or managerial – is the truly important one  as far as the commercial aspects of the project are concerned.

The authors use excerpts from Slashdot discussions to highlight these two dynamics at work.

Data analysis and discussion

The programmers’ perspective

In Slashdot discussions, Case and Pineiro find that programmers articulate different identities depending on the audience. In some situations they express an interest in (or agree with the importance of) meeting deadlines, getting the product to market etc. Whereas, in other situations, particularly when responding to (or comparing themselves to) project managers, they might express an interest in code aesthetics – i.e. the importance of writing good, even beautiful, code. Several examples of the latter can be found in a discussion thread on software aesthetics. Many of the contributions to the discussion assert that (good) programmers have the following traits:

  • Are passionate about their work
  • Care deeply about quality.
  • Understand of the importance of good code.

Several contributors make these points in opposition to the work-related traits of managers. That is, they set up a stereotypical manager – who doesn’t care about code quality etc. – as a foil for their rhetorical arguments.

Technical knowledge is another important way in which programmers set themselves apart from project managers. The contention here is that managers cannot really understand what a software system is because they don’t have the required knowledge; an implication being that they are not qualified to manage its construction. Case and Pineiro mention how this issue can really raise emotions when it comes to the issue of outsourcing (see this discussion thread for example).

The project manager’s perspective

Although the Slashdot community is dominated by programmers, the authors were able to find a few contributions that gave the project managers’ viewpoint. For example, a discussion on project management for programmers, gave some project managers an opportunity to articulate their views. In the discussion, project managers tended to focus on two aspects – performance (i.e. completing the project on time) and project management knowledge – both of which (they implied) programmers do not understand. See this comment for an example of the former and this one or this one for examples of the latter.

Project managers thus set themselves apart (i.e. construct their identities) as distinct from programmers. They are concerned with driving the project to successful completion and they have specialized knowledge and training to do this; both of which programmers do not possess.

The authors’ conclusions

From their analysis of selected Slashdot discussions, Pineiro and Case conclude the following:

  1. Software developers and project managers tend to construct their identities in opposition to each other – i.e. by setting themselves (their skills, motivations and concerns) as being different from the other. On the other hand, business imperatives require that they collaborate, so there is a symbiotic aspect to their relationship.
  2. Despite project managers being marginally higher up than programmers in organizational hierarchy, there is little difference in the status of the two. The reasons for this are: 1) Project managers lack the specialized technical knowledge needed to understand programmers’ work and 2) Software project managers’ are dependent on programmers – perhaps more so than project managers in other disciplines. As a consequence, the difference in status might rankle with programmers. Thus the hierarchical proximity of the two parties might also be one of the reasons for the conflict between the two.
  3. Both parties generally claim to have the same goal – produce quality software in reasonable time. They differ, however, in the means to achieve the goal. Programmers believe the focus should be on producing high quality code whereas project managers tend to emphasise the optimization of resources and time, whilst meeting the system requirements.

Wrapping up

The paper isn’t an easy read because of the wide use of sociological jargon,  but then it is a research paper. The central idea –  that online discussions can serve to construct or reinforce programmer and project manager identities – is an intriguing one.  If true, it implies that one’s self (and projected) image influences,   and is influenced by,   how one describes oneself to others in speech or writing.   For instance, does my claim that I’m a “seasoned database architect” and “experienced project manager”  reinforce my professional identity? Also interesting is the idea that developer and project manager identities are often constructed in opposition to each other. That is,  both parties appear to build their identities by casting the other in a negative light.

However, as interesting as  all this is,  I believe it misses a crucial point:  that programmers and project managers, for the most part, play out roles which are defined and enforced  by the organisations they work for. If organisational rules and norms require programmers (or project managers) to behave in dysfunctional ways,  then that’s exactly what most of them will do.  On the other hand, if  an organisation encourages behaviour that fosters good working relationships between the two parties, things would be different:  those working in such environments  would have more positive experiences to to relate (this comment taken from one of threads analysed by the authors is a case in point). It is surprising that the authors chose not to include such (positive) comments in their analysis.

In brief:  the paper  presents an interesting perspective on the relationship between programmers and project managers.  Even though the authors’ focus is somewhat limited, the paper  is of potential interest to researchers and practitioners interested in work relationships in project environments.

Written by K

March 4, 2010 at 9:38 pm

19 Responses

Subscribe to comments with RSS.

  1. I’ve always found this age-old conflict interesting because from my perspective it’s pretty unnecessary. Programmers are absolutely within their rights to be unhappy with imposed deadlines and compromised code. As with any profession, the quality of their work is an expression of who they are. Identity conflict is a fabulous concept which I need to read more about.

    It is not the programmers’ job to set project boundaries or otherwise establish constraints. That’s up to the project manager. The scope of the project is also the PMs responsibility. If the PM has blithely said “yes, sure you can have that” to their stakeholders without consulting with the programmers on how feasible that scope is to accomplish within the budget and schedule constraints, then why should the programmers not be upset?

    It’s an unfortunate truth that the project manager has a very difficult job creating the playing field for the project, but difficult or not, that is the PMs job (which they should know when they sign up). If the job isn’t done well, people will be unhappy. Quality as a deliverable attribute falls under “done well”.

    To be fair: it is not always up to the project manager to define project constraints. Sometimes salespeople for a vendor organization do a fantastic job over-promising, which creates many problems downstream. In those cases, it comes down to negotiation with stakeholders AND programmers to find where that happy point will be. If the PM takes the time to get the programmers’ buy-in under those conditions at the start (instead of ramming it down the programmers’ throats), there should be no conflict.

    Incidentally, I’m a project manager–not a programmer. 🙂

    Thanks so much for this post!


    Geoff Crane

    March 10, 2010 at 7:59 am

  2. Geoff,

    Thank you for taking the time to write a detailed comment. You’re absolutely right, the conflict is largely unnecessary and quite pointless. In my opinion, the fault does not lie entirely with PMs and programmers: adversarial relationships between programmers and project managers are often a consequence of a toxic organisational culture (see this post for more on the relationship between organisational culture and project success).

    Thanks again!





    March 10, 2010 at 9:16 pm

  3. Geoff and K,

    How did programmers come to the notion that the business aspects of software based products is somehow beneath.
    Deadlines – imposed or not – are usually driven by business needs. Granted poorly developed deadlines have the same effect on programmers as they do on asphalt paving companies doing road work for the city.

    In other industries where software intensive systems are developed – space and defense is where I work – we don’t have these notion of “the privilege of specialization,” that seems to have emerged in the software development community where “mission fulfillment” is not the primary driver.

    The very software intensive world for Guidance, navigation and Control has HARD deadlines, changing requirements, and variable budgets, but we don’t seem to confuse management’s role with the developers role.

    “ramming things down programmer throats” is juts bad management. Stop doing that. The answer is not to invert the relationship, the answer is to find another place that understands good management along with good engineering practices.

    Geoff’s got the answer – it should be a “natural selection process,” don’t have good management, go out of business.

    But don’t invert the roles, programmers probably won’t make good managers either in a toxic environment. But this notion of privilege of expertise doesn’t add value to the business either. I’ve seen it too often and it always fails.


    Glen B Alleman

    March 11, 2011 at 5:53 am

  4. After reading the paper, I’ve concluded that the view of programmers on SlashDot is possibly representative of that community, but very narrow in the world of software intensive systems.

    They need to come to a pulverized coal boiler in a refinery with a fault tolerant process control system containing 100’s of 1,000’s of line of code. Stand under the flame box, with air rushing by strong enough to pull up hard hat off. Then ask how “special” the role is off programmers when they speak in terms reflective in the paper.

    The missing element I see in domains where privilege of expertize over comes the management of that expertise is there is no overwhelming mission for the software. Development of the software has become an end unto it’s self. Programmers speaking on SlashDot appear to make themselves the end rather than the means for business success.

    We actually took new developers under that boiler in LA (California) and explained that the software system they were going to work on controlled megawatts of thermal energy and if our fault tolerant emergency shutdown system failed to work as specified that boiler would be a smoking hole in the ground. We had them stand there for a few minutes in the roar of air and flame. A few decided not to take the job of “programmer.”


    Glen B Alleman

    March 11, 2011 at 6:30 am

  5. Glen,

    Thanks for your insightful comments. You are right: conflict often arises because folks (be they programmers, or even managers and business sponsors) do not understand the rationale for their project – why it is being done, and its importance and significance for their organisations. There is, I think, not enough attention paid to developing a shared understanding of project rationale in the early stages of projects.

    That said, it is also true that there are situations in which project teams are put in impossible situations. This is sometimes (often?) a consequence of a top-down approach to management coupled with a poor organisational culture. Perhaps the cynicism displayed by some of the slashdot participants is a symptom of of this dysfunction. I believe the solution to this, too, lies in the developing a shared understanding via open dialogue. Granted, such dialogue can be hard to foster in some organisations, but I do believe this is the way out. I’ve written a bit about this in a few of my recent posts – see this post for example. Though the concept seems somewhat idealistic, I reckon it can be made to work in practice.

    Thanks again for taking the time to read the post and comment.





    March 11, 2011 at 9:54 pm

  6. K,

    My experience has been that the problem comes when the “roles” themselves are confused. The failure starts with there is no RAM (responsibility assignment matrix) actually an accountability rather than responsible.

    I say this from experience with large complex groups with many multiples of subcontractors on software intensive programs.

    The developers are “assigned” deliverables, with measures of effectiveness (customer view of DONE) and measures of performance (developer view of performance), project management has similar MoE and MoP measures.

    In this way there is a clear and concise definition – at least on paper – of what role a person plays, what they are accountable for, the description of that deliverable and where that deliverable fit into the over scheme of deliverables (the product architecture has to be in place). This architecture approach is now part of more mature agile paradigm. Duh!!! Scott Ambler now speaks to this. The notion that architectures emerge is nonsense in all by the trivialest of projects.

    Then when the is grousing starts, walk over the RAM hanging on the wall. The Big Visible Chart that many agilest want to take credit for was hanging in the hallway of Build O6, TRW, One Space park, Redondo Beach, 1978. When we came in on Monday and had the Anheuser Flu, you looked at your badge and you looked on the chart for the same name and remember what you were supposed to be working on.


    Glen B Alleman

    March 12, 2011 at 3:16 am

  7. Glen,

    This is a very interesting discussion, one that goes to the heart of the many of the dysfunctions seen on projects.

    I think the seeds of confusion about roles (or even project objectives) are sown at the very start – at the so-called front-end of projects (see the paper by Samset and Williams or my review of it). As you mention, it has to do with the notion of understanding the objectives of the project – i.e. defining what we mean by “done”. “Done” is easier to define on some projects than others. To clarify this point it is helpful to make a distinction between technical and social complexity. The best way to explain the difference is through an example related to me by Paul Culmsee:

    “Putting a man on the moon is a technically complex project (perhaps the most technically complex project there ever was), but there was little ambiguity regarding the goal. On the other hand, implementing a collaborative platform (such as SharePoint – which is Paul’s technical specialty) in an organisation is technically much simpler than a space program, but nailing down “done” can be much harder because different stakeholders have different views on what “done” means.”

    The point is: only after the goal is articulated and understood by all stakeholders in the same way can begin to talk about roles and accountability.

    As you are probably aware, Horst Rittel coined a great term to describe socially complex issues: he called them Wicked Problems. Most problems involving diverse stakeholder groups are wicked. Issues pertaining to city/town planning are paradigmatical examples – indeed Rittel used these in his seminal paper published in 1973.

    More recently, Mary Poppendieck argued that software development projects have elements of wickedness (see this post). She uses this to argue for agile/adaptive methodologies, but that is neither here nor there. Like you, I think the debate about which project management methodology one should use is a big, fat red herring. Once you define “done” which methodology you use should not matter – they will all work (if used correctly).

    So the question remains: how do we define “done” when we have diverse and conflicting interests. Often these issues are resolved arbitrarily – by management fiat or developer assumptions. Both approaches generally end in tears and recriminations.

    Since it is relevant to this discussion, I hope you don’t mind my indulging in a bit of self-promotion: Paul and I are currently writing a book about managing wicked problems (if you are interested, see this post on Eight to Late and this one on Paul’s blog for a bit about the book). The book is based on academic research in the field of sense-making, project management and organisational theory complemented by field experiences drawn from Paul’s consultancy work and my own (admittedly more limited) project work. From a practical point of view, the book is essentially a compendium of techniques that can help achieve consensus on contentious issues. One of these is dialogue mapping, which I have discussed at length in several prior posts. We present a bunch of other techniques as well.

    Finally, as I mentioned in my previous response, one of the obvious ways to get people on the same page is through open dialogue. This, however, is idealistic because politics, power games and hidden agendas will always trump openness. The problem then boils down to the following: how can one encourage – or even push – folks to be open.? One of the ways to do this is by ensuring risk is shared rather than apportioned to specific parties (in many cases the party bearing most of the risk being the vendor or contractor). Risk needs to be shared in keeping with the principle that if one party loses, everyone loses. In the book we elaborate on how this can be done, as well as other methods to achieve a shared understanding.

    I’d better stop here as I’ve rambled on a bit – do let me know if you’d like me to elaborate on any of the points I’ve made.

    Thanks again for an excellent discussion!





    March 12, 2011 at 10:57 pm

  8. K,

    Thanks for further materials. I’m in the middle of re-reading Making the Impossible Possible. Here are the 4 levers for project success has described in that book.

    Vision, Innovation, and Symbolic Leadership – Articulation and reinforcement of a motivating vision

    Stability, Discipline, and Process Control – Detailed planning and processes in the organization

    Collaboration, Engagement, and Participative Leadership – The internal dynamic of human capital needed for success

    Politics, Incentives, and Rigorous Performance Standards – The external dynamics of culture, collaboration, credibility and trust.

    The referenced papers move the discussion from the “big fat red herrings” (I love that phrase) and toward academically sound assessment of how to organize projects for success. The notion of a “wicked problem” is mis-used by Mary in light of these materials. The reason – and I’ve posted to her on this – for classifying them as wicked, is because they (not she per se) fail to do the ground work to get the project bounded in the first place. The Terry Williams states this clearly. The core principles of project management are not applied and guess what? The project goes wicked.

    Here’s a view of those Immutable Principles that are ignored in most projects classified as “wicked” in the software world.


    Glen B Alleman

    March 13, 2011 at 3:38 am

  9. Love your work Glen. You are exactly right and I really don’t have too much to add except that I love this thread of discussion.

    In my experience, participative leadership is key and thats how a vision is defined. For this reason I really like what Ron Heifetz has to say in his adaptive leadership books on this topic.

    With regards to wickedness and agile, I described agile principles and a day in the life of a scrum member to one of my PM mentors (who used to manage megastructures) and he said “I have been doing that sort of shit for 30 years – there is nothing new here”.

    I then had the opportunity to work with him on a number of projects ourside of IT and he was completely right. The principles you list from the “Making the Impossible Possible” are strived for in certain industries and project types. When you examine the path they took to get to where they are, it becoms very clear that IT still has a long ways to go.

    Since then, we have distilled those above principles further, but thats for the book. But now I find that I can mess with agile/scrum fanboys quite easily, by asking them the question that if I could create an environment with all of the hallmarks of what you listed in your reply to Kailasg, would I still need scrum?

    This also lets me subsequently ask “well, maybe you are attacking the problem in the wrong place, or just one facet of it?”

    All interesting stuff this…


    Paul Culmsee

    March 13, 2011 at 10:37 am

  10. Also Glen, here is a memetic take on the identity crisis that every discipline has. This is a representation of the writing style in the book..



    Paul Culmsee

    March 13, 2011 at 10:42 am

  11. Glen,

    Great presentation – the immutable principles you mention are indeed the core of successful project management. To summarise for others following this thread, Glen summarises the essence of PM in the following 5 questions:

    1. Where are we going?

    2. How do we get there?

    3. Do we have what we need to get there?

    4. What are the obstacles along the way.

    5. How do we know we are making progress?

    Glen, after reading your comment and the presentation, I realise that our positions are very similar. You are right that wickedness can arise if the first step isn’t dealt with in a rigorous and honest manner – this happens quite often in corporate IT projects, and hence the conflicts mentioned in my post. However, some projects are inherently wicked in that the issues are socially complex. Town planning projects are a good example, with social complexity arising from differences in world-views of stakeholders (residents, planners, government bodies and property developers). Paul has done some nice work in this area – see this project case-study on his company website for more. We present a detailed analysis of that project in our book.

    In short, PMs first need to focus on the knotty problem of aligning diverse stakeholders who hold apparently irreconciliable views. Only once this is done can one sensibly tackle other issues.

    Thanks again for taking the time to contribute – this is a very useful discussion.





    March 13, 2011 at 12:27 pm

  12. K,

    I did a quick read of that paper and I’ll look up the others as I get some time.

    The conflict between goals between developers and management is, as the authors note, longstanding. In my experience, this is often compounded by a failure by bot sides to recognize
    1) the other’s legitimate goals
    2) the best way (or at least a pretty good way) to actually complete the project

    Given the nature of software development, there will be a knowledge gap between developers and management. The solution is not to invert the relationship, but to place proper goals and responsibility on the developers.

    Developers should have credible plans that satisfy management’s goals. A manager who simply demands something will get what he deserves, as H. L. Mencken wrote “good and hard” . The wise manager will ask “show me how you can do this”, not “prove you cannot”, or “do it anyway”.

    This involves a large measure of trust and transparency on both sides. Organizations must build this environment.


    Bill Nichols

    March 18, 2011 at 1:56 am

  13. Bill,

    Thanks for your comments. You are absolutely right – both sides need to recognise and understand each others rationale and goals. As I see it, the main role of management in the early stages of projects is to do just this – i.e. to get everyone on the same page. This involves developing a shared understanding of what is required (project goals) why it is being done (project rationale / business case) and how it will be achieved (design / plan). Once this is done, both managers and developers know what is reasonable and what isn’t: shared understanding dissolves conflict.

    As you mention, this requires that organisations create an environment that fosters trust and transparency. This is hard to do in many situations and cultures – highly hierarchical organisations, for example. Fortunately, there is an increasing recognition of the importance of an open organisational culture. There is hope yet!

    I’m fascinated by this topic, so please do let me know if you come across any interesting papers.

    Thanks again for taking the time to comment.





    March 18, 2011 at 5:12 pm

  14. K,

    I wrote an admittedly biased review of Watts Humphrey’s last book. While it is very focused on Team Software Process, Watts addresses why trust is so important in the knowledge work environment and how workers and managers can change their behaviors.



    Bill Nichols

    March 19, 2011 at 6:35 am

  15. Bill,

    Thanks – after reading your review I wanted to know more about TSP. I’ve had a look at the SEI site and have downloaded the TSP BOK. Are there any other papers/references that you would recommend?





    March 20, 2011 at 10:13 pm

  16. K,

    The BOK is rather dense and is designed as a reference guide for training. Far more accessible are available.

    The coach mentor guidebook has some useful information, including a coach job skills analysis.

    Click to access 10sr016.pdf

    Gene Miluk did a webinar with an introduction to TSP and how it relates to CMMI

    Click to access webinar20100727.pdf

    But I recommend presentations from the users. They not only describe their success but also they are honest about the hard parts.

    From Intuit (quickbooks)

    Chen, Christine; Chong, Elaine; Collins, Roger; Tingey, Karen; & Zhang, Michelle. ?”Taking Ownership and Adapting TSP Successfully Over Time”. Proceedings of the TSP Symposium (September 2007). http://www.sei.cmu.edu/tspsymposium , http://www.sei.cmu.edu/tspsymposium/past-proceedings/2007/Day%201%20930AM.ppt

    Fagan, Eileen, & Seriampalayam, Rajan “TSP Works… Let’s Roll it out”, Proceedings of the TSP Symposium (September 2007), http://www.sei.cmu.edu/tspsymposium/


    and Adobe

    Click to access TSPatAdobe.pdf

    Click to access DAY%201%201115%20AM%20Davis%20Spencer.pdf

    Experiences in the video game industry include very complex multidisciplinary projects.

    Bala, Karthik & Bala, Guha. “Game On! An Industry’s Journey”. Proceedings of the TSP Symposium (September 2007), http://www.sei.cmu.edu/tspsymposium

    Wall, Dan “Using TSP in a Systems Engineering Environment”, TSP Symposium 2007, http://www.sei.cmu.edu/tspsymposium/2009/2006/seenviron.pdf

    Northrop Grumman Doesn’t mention TSP specifically, they implemented PSP in a team environment

    Brady, Steve and Sherri Turner, “The Proof is in the Project”,Northrop Grumman Corporation, SEPG, 2004 http://www.sei.cmu.edu/library/assets/proof.pdf

    Watts has books for coaching and leading teams.
    [Humphrey, Watts S.: TSP – Leading a Development Team. Addison Wesley 2005

    Judging from some of your recent posts, you have an analytic bent that would fit with the rich data TSP and PSP provide.


    Bill Nichols

    March 21, 2011 at 2:33 am

  17. Bill,
    Thanks for all the links. In the context of the current agile movement, the Adobe papers are a nice “safe harbor.”


    Glen B Alleman

    March 21, 2011 at 6:52 am

  18. Glen,

    I don’t think we ever got a direct quote, but Ken Shwaber also looked at either the Adobe or Intuit teams, some of the same people were involved so I get them confused. He described the SCRUM/TSP teams as among the best SCRUM teams he’d ever seen. The point is that Agile requires discipline

    I also argue the right measurement enables enhanced feedback. The end of the sprint has too much lag and is too far removed from some important activities.


    Bill Nichols

    March 21, 2011 at 10:47 am

  19. Bill,

    Thanks for the links…plenty of reading to do.





    March 21, 2011 at 7:01 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: