What tools do you have at your disposal as a manager to promote a way of thinking

Question

This question goes beoynd just programming, but I'd like to get some input on this, if that's okay with the community. Preferably from people that do a lot of coding themselves but also manage other people coding.

My problem is this. We have all these ideas that we know is good for the overall strategy of the company and the problem is not figuring out what to do, it's to come about this change. Just telling someone to do things differently isn't enough and it's hard to promote a mind set that is shared within all of the company, (this will take time). If I could jump forward I'd like it if we could create a very nurturing company culture that promotes these ideals cross all areas but I'm not sure what tools to use. And by tools I mean anything I'm legally permitted to do.

e.g. we could talk about, we could arrange traning sessions, we could spend more time in meeting (talk about it more), we could spend more time designing, we could spend more time pair-programming, we could add/remove incentive or we could encurage more play. Ultimately if we did all of these things what will be the recurring theme that ties this together. I'd like to be able to answer the question -- why should we do things like this? -- and come up with an answer that explains how important it is to think about our ideals from begining to end.

I've puposly avoided to talk about or specifics of the situtation becuase I believe that it narrows things down too much. But I guess, by know you either know how to answer this question or you're as confused as I am ;)

I'd love to hear from people who had to bring about a change in order to go from chaos to order, or fix something in the organization which wasn't working. And I'd like to hear it from the perspective of the developer and designer.

-- or --

You could simply weigh in on what are the most important qualities in an organization encurage or stimulate rigid fun development cycle from start to finish?

Answer 1

I don't think that it is legitimate (I make no comment on legality) for a manager to expect to change the way the managed think. It is legitimate for the manager to expect to change the way the managed behave, ie what they do and how they do it.

Especially in our business of software development I think you are much better engaged in focusing on products and processes than trying to overtly manage the personal growth of your staff. Agree what needs to be done (creating software, implementing processes to support creating software) and who needs to do it, then get on with it. It's very simple.

Yes, some of what needs to be done is training and some of that training will focus on working with others whether as colleague or manager, but you ought to be trying to build an effective team, not one in which everyone's monthly cycle harmonises and you all cry together when a post-commit test fails. And yes, it is an absolute requirement that everyone in the team be able to work effectively with everyone else, but that doesn't mean that everyone has to share views, friendships, attitudes, and so on.

Reading your post suggests that you are more concerned about making work a nice warm and cuddly place to be than you are about getting stuff done. Ask your team how much more time they would like to spend in meetings, especially meetings in which you propose to invite them to share their feelings about work.

If I was exposed to a very nurturing company culture I'd back out carefully and never come back. I, and I suspect many other SOers, want to get intimate with silicon-based life forms not the carbon-based life forms which clutter up our podspace. And your mention of a rigid fun development cycle makes my trigger-finger itch.

Answer 2

I think that a well managed scrum is the right answer. It is iterative, the team learns from the experience, you have summary\ retrospective meetings which, when the people are cooperative, very very helpful, you can easily track your product needs and get customers feedback very early. Both from professional\ personal aspects. From a quite long term view (I work in a scrum team for ~13 months) - to my opinion, it does bring changes in mind set. (In addition to other benefits you have from the scrum methodology - ask who does it!)

Answer 3

The tool is called work contract. You have no right to change how your manmaged people think - but you have ANY right to enforce that their actions follow your determined policy. Whether they like it or not - it if their job to do as you said. This is what you and them get paid for.

I have been often in companies with idiotic policies (as a contractor). I can point them out in a four eye meeting with the respective manager. But working at them it is my duty to do as they want, think their way and in general follow their policies. Non-negotiable.

I expect the same from any employee. Whether he likes it or not is not my problem - if he does not follow policy, he has no right to work in my teams.

If you think this is harsh - the military is known to shoot people not following orders in times of war, and will gladly throw them out (after prosecution) in non-war-times for not following orders.

Answer 4

While I agree with the other commenters that making not following procedure / policy could just be a disciplinary matter, I think it's far far better to engage people and get their buy in and agreement with a methodology.

In my team we've recently been trying out different approaches, like different ways of doing code reviews. Historically we've done them in a particular way, none of us have enjoyed them and they've become a chore to be avoided rather than a useful tool. So, we've started trying different ways of doing them, and after each session we break down what worked well and what didn't. Hopefully at the end of the trials we'll have a set of processes that we know work for us as a team, and no-one will feel like they're being forced into doing anything they don't want to because everyone will have seen first hand the benefits of doing things in whichever particular way.

Answer 5

I strongly disagree with many of the posters here - I think it IS the task of a good manager to care about the mind-set of your employees and to get them to embrace what you're - all together - trying to achieve as a team (or for the company). I'd go even further: if you "force" your software engineers to do as they are told because you have the means to do so (quoting "The tool is called work contract"), you will - at best - get avarage results. You need to motivate your people to get the best out of them (and real motivation is usually not fear of losing a job, but I guess that's old news ;-).

I'm also managing a team of developers, and I usually aproach them on a "personal needs" basis - some guys need to talk a whole lot about new ideas, not necessarily in meetings which most developers do not like (I have more good exeriences concerning coffee-break or after-work beer talks than with official meeting), others need a simple short one-time talk, still other want you to "hold their hand" and simply be there for all the questions that arise during a change, and still others continue to be skeptical for a long time (you usually can get them with persistance, patience and some humor).

Maybe my viewpoint is very European, but I (and my company) highly value employees who question the things they are told to do and not blindly follow the policies.

So, to sum it up: the "tools" I use are mainly communication, and encouraging people to "let's try something new" (which usually works out if you react to the concerns arising) - it also helps to get the mayor players on your train first, because others with less strong opinion then usually tend to follow ("if our guru xy is doing that, it can't be such a bad idea"). Very important: just be there when people have doubts or questions, and hear them out & offer solutions (or really explain why you do not consider their point).

Many things turn up only once you're on your way to changing something (e.g we're currently transitioning from the waterfall model to a scrum model that will fit our development structure), and don't be afraid to try things as long as you're able and willing to explain them.