X Theory Management

Suspicion

I was recently given an account from a friend that reminded me of an article I read by Esther Derby on Bully Bosses.  Esther’s article paints a very grim of some of the worse-case situations employees might find themselves in: abusive, yelling, coercive or threatening managers who for whatever reason feel they need to exert authority and control over their staff.

The case I heard differed considerably from these extremes – which I’ve had the good fortune to have never experienced – but still fits into the Bully Boss category: the defensive manager.

Conservative Defensive Management

Defensive Management is a style coined by Tim Lister and Tom DeMarco in their very excellent book, “Peopleware – Productive Projects and Teams” (Dorset House, 2nd ed. 1999), which assumes that your staff are generally incompetent or mistake-prone.  Staff can’t be trusted to make the right decisions and their errors will reflect on you.  Only your judgement is competent; anyone else’s is supect.  Therefore you should vet and approve any and all important decisions before they are put in place.

Conservative Management is a style I’ve seen particularly prevalently in the public sector and in the finance sector.  These industries are by nature very risk and change averse and prefer to stick to well-established historical practices regardless of what might be happening in today’s market.  The management of these companies is often of a similar vein, with a career upbringing in strict heirarchy and an habitual acquiescence to upper management decisions.  An old-school management style of “if I say to you that the walls might look better painted green, you say ‘What shade?’”.  I could be wrong, but this type of disciplined management style is generally only found today in the armed forces.

Put these two together and you have a manager who expects all staff to conform to his way of thinking and agree unquestioningly with his decisions, who doesn’t trust his staff with any meaningful autonomy or authority and who needs to be involved in every decision.  This type of manager can be even harder to work under if he is prone to dark moods or creation of arbitrary deadlines that must be delivered.  This is a form of micro-management, but done in an intimidating way such that staff are afraid (or at least reluctant) to speak up or disagree.

As DeMarco and Lister argue,

the only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded.

Staff who feel untrusted, coerced and insignificant are less inclined to form together and work well as a team and are less likely to feel motivated at their work generally.  Productivity can only inevitably suffer as does innovation and growth.

This type of Bully Boss is something of a unique variety because he may be cheerful and approachable for much of the time, but as soon as something happens that doesn’t fit with his expectations, he can become grumpy and condescending, asserting his view of the way things should have been done and making people feel small and guilty.  Employees who have this type of manager typically adopt one of two coping mechanisms: they tolerate the behaviour and just try to get on with each work day, or they leave.  Esther’s article (above) lists other effects including stress, information hiding and a lack of engagement (a signficant one in my view).

Read Esther’s article (or better – subscribe to her blog!) and consider some of the coping strategies she suggests.  Have you had your own experience with a particular personality type in your direct management?  Tell me about it.

Opening New Doors

At the end of this month I’ll be leaving my current job to start at a new company in a new town.  I’ll be taking up a position of Technical Lead for a finance company in Dunedin, New Zealand and will also be tasked with providing strategic technical input to the company’s service offerings.

This is the first time I’ve actually had the word “Lead” written into the role, which to many people might be quite alarming.  Why hasn’t this job function been formally recognised before?  The answer is that in all my previous roles, I have built a new team from scratch as a senior developer and the job description has never really adapted to reflect the broadened job functions.  This time I’m going into an established team and therefore a pre-defined recognised position.

Given that my job function will now require me to actively manage my team of developers (as opposed to the implicit “develop first, workload management second” expectation of my previous role), I feel I have finally reached a point where I need to place considerably more focus on my management skills.  This will be a challenge because, like many technical team leaders, I’ve had very limited chances to observe really good management in action.  Much of my line manager’s day-to-day activity has happened “behind closed doors”; precluding me from learning the tasks and challenges I need to understand.  To quote Esther Derby and Johanna Rothman, “poor managers create the illusion of productivity through busyness”.  Fairly or unfairly, my line managers’ productivity has often seemed illusory because it was actively hidden through unshared calendars, high levels of unavailability through absence and a lack of communication.  I should point out here that I am not suggesting my managers have always been unproductive.  Merely that I have not been given an opportunity to understand how they structure their workload to create an effective management style.

So I have elected to seek out an alternative source of management training in an excellent book called “Behind Closed Doors” by Esther Derby and Johanna Rothman.  As I progress through my new role, I will be writing here about my experiences in learning about the people and the work, building the team and its capabilities and identifying areas where my team can add real value to the business overall.  I’ll look at how the development team’s commitments and capacity are placed and how I can strengthen the team’s processes and throughput.

My next post (due at the end of June) will look at my first week on the job and the challenges I face in learning a new company’s products and services, my team’s role in facilitating those and how I ease myself and my team through the processes of Forming, Storming, Norming and Performing.

My hope is that these regular posts provide some valuable insight for others in similar situations.  I would be very surprised if I was the only one who found himself faced with these new challenges and hopefully I can pass on some experience and useful ideas to you along the way.

On becoming a Team Lead

Team leadership

I’m a bit stuck.  After having held the position of Technical Team Lead in my last three jobs, I’ve lately come to a point where I’ve started to do some reflection on my qualifications and experience and question what exactly it is that the role of Team Lead means.

The thing is I’ve only been in this development game for about six years. I finished college in 2002 where I’d majored in programming (VB6 was standard at the time) and project management and took up a job in the capital as a security administrator for just under a year before landing a job in a software shop as a helpdesk operator. 18 months after bagging and tagging calls, I finally managed to negotiate (or at times, even force) my way into a role supporting the company’s smaller ASP applications.

Not having ever worked on websites before, this was a considerable amount of learning for me. I then moved on to ASP.Net and started teaching myself C#. Over the following two or three years I built up a team of (typically) graduate developers to help me as the workload grew. Being the incumbent, I was informally given the title of Team Lead.

Now having moved on to a new job at a financial institution, I find myself again with this informal title of Technical Team Lead. I believe that – again – it’s not because I’m the most proficient, knowledgeable or even necessarily competent person on the team; simply that I’m the guy who said “yes” when the manager asked if I’d like to head up its formation.

So here I am after two years in the role and finding that in reality, I’m not actually that well-versed in the basics. I’m having to remind myself what the point of interfaces are and how abstract classes work at a fairly rudimentary level. I don’t really know how to apply design patterns to my code or even what many design patterns are, for that matter. I blurted out to one of my team that I didn’t know what Domain-Driven Design was today. I now feel I must learn and understand it.

The problem – for lack of a better term – is that I’ve risen to the position of Team Lead quite quickly. I haven’t built up my core knowledge and experience as thoroughly as my peers because I’ve often been concentrating on a broader range of responsibilities. In my roles I’ve been responsible for reporting, invoicing, timesheet approval, documentation, design, architecture, customer meetings, requirements gathering… all manner of things that aren’t related at all to actually writing code.

So does this mean I am right to be concerned about my qualifications to lead a team? Well, yes and no.

The first point to note is that, at least in my experience, the role of Team Lead is one in name only and is rarely recognised formally by the organisation. All the company wants is a senior developer (typically with 5 or more years experience) who is prepared to sacrifice some of his involvement in the core development process for the administrative and project coordination tasks that are effectively outside a “regular” manager’s field of expertise. The Team Lead will be able to see the tradeoffs between the various technical aspects of a project while being able to clearly communicate relevant information to the business or client in non-geekspeak. In other words, leading a team is not entirely about having the highest level of technical skill out of all the other members; it requires equal measures of people, communication, writing, and time management skills as part of the day-to-day routine.

The second point is that I’ve risen from a support desk analyst to senior developer in a fairly short space of time – about 6½ years – which (I like to think) is some reflection on my abilities. However I do recognise that this has come at the cost of not having obtained some of the core experience that might otherwise be expected of someone at this level. Still – a key part of solving a problem is recognising that the problem exists in the first place and being willing to act on it. That is where I find myself today: identifying gaps in my knowledge and creating a set of personal plans and goals to correct those gaps.

So over the course of this blog, I am going to chart my thoughts, challenges and personal lessons in my capacity of Technical Team Lead / Self-Doubting Developer. I’ll look at how I started in the team lead capacity by growing my own job function, growing a team around me and what sorts of events and capacities I’ve worked through since.