I had a five hour offsite management meeting today. Having only had my new teams for a few weeks, I think I'd have been better served going out for a beer with my business unit. Or a bike ride, knowing one of them and our current amazing weather. But that's not the point. We were asked to list some pros and cons of the current organization. At least as much as we could speak to after a few weeks if we were new to our areas. I noted that one of my primary problems is that I have a team where 4 of the developers are contractors from different companies, my lead has left and I haven't filled the role yet. My tech coach has certain restrictions placed on him around his work day. I have one rotational developer who moves on in 7 months. And that leaves two company developers who are both looking for a promotion to lead a team. And a developer leaving because she couldn't get half the raise she was getting at her new company plus EB2 sponsorship (think a few years to green card instead of 20). I pointed out that it's incredibly difficult to create a culture with only two people, trying to really bring home that our current lack of competitive compensation (we move in the right direction, but as a big company it takes time) is a barrier, and that with three people they might argue and come to a consensus, but with two they just tenaciously hold on to their viewpoints. My point...we need to pay competitively (and offer compensation such as eb2) enough that we can gets more developers who actually work for us instead of contracting so we can have a team culture and stop worrying about bouncing up and down with capacity and forcing a discussion about resourcing and capacity with our business, as they should be somewhat oblivious to our resourcing issues and focusing on building something beautiful. I used the example that I had people on the opposite side of the fence when it came to TDD (test driven development).
The result? At least my interpretation of it.
I was told that perhaps I shouldn't be thinking about culture so much as forcing a decision on TDD and leading. I should be breaking the tie. That was hammered home by using me as the end of meeting example of someone who should put some thought to really leading his team.
I already have a cross-team meeting on Monday (scheduled over a week ago) to drive at TDD and create a laundry list of development topics to drive at including Javascript widget creation, Jquery, javascript in general, HTML5, and beyond. I don't have any problems leading. I have problems anchoring (e.g being the manager who makes your team follow a particular path when they might be able to organically generate a better path by discussing issues at a grassroots level - agilely) when teams are fully capable of determining a direction on their own. But they can't determine a direction when there are only two of them and they have dichotomous positions and the other two are momentarily distracted, fulfilling multiple roles, or too new.
I could take the developers from my one team, move them to the other team, and have a fully staffed in house team. Functional. Cohesive. Self-directive. And I could simply move 3 contractors over to the other team and have a team composed of nothing but contractors - if I pulled them from the same company, cohesive, functional. I might make that argument. I have a company who's offered a team.
But the point seemed to be that I don't know how to lead. In the end, I realized I was a talking point and that's sometimes that is just the way it goes. The truth is, I'm appreciating my new boss - he throws seriously technical issues my way and just says "go". This is good. And it makes me happy. I want to really dig into code with good developers and architects, or developers that could be very good if given a chance. If my boss' boss uses me to illustrate a point, I can live with that. My goal is to make life easier, more interesting, and more productive for developers. That was always why I became a manager. And in the end, that creates the culture and velocity that my business unit benefits from. But I have the inkling that perhaps that's not the right talking point when it comes to our current direction/vision.
It usually works out in the light of morning. Get good developers (including testers). Build good code. Collaborate with good business people and good customers. The noise always goes away in the end.
1 comment:
The majority of people in upper management positions know nothing about "leading", only how to "manage". More than likely, they had no idea what you were talking about - just some type of hippie-free-love garbage that makes them nervous. Hang on - perhaps someday you'll have that job and the departments will improve exponentially under your leadership.
Post a Comment