Office Environments and Children’s TV – A Lesson

Any parent of young children will tell you that your TV viewing habits change rather dramatically in the early years.  While the programming is not typically the most cerebral stuff on the airwaves, it nonetheless has its place and occasionally – very occasionally – it can make you think.

I had one of those moments this week while overhearing part of an episode of Engie Benjy.  In it, two vehicles were having a race.  They were both trying their absolute best but eventually tied.  The vehicle owners cheered and congratulated both vehicles saying, “Well done you two. You’re both winners!”.

Ordinarily I’m not a big fan of that sentiment; it’s so desperately overused on childrens’ TV programming that, as an adult, one can become very cynical about the idea.  It makes me cringe.  The real world doesn’t operate that way and that message, in my view, sets up an unrealistic expectation in children of how things work.  In school sports, exams or employment opportunities for example, we don’t all get to be winners.  Someone comes in first place and others miss out.  That’s just how life is.

But what about the office environment and corporate culture?  Is it reasonable to expect that there should be one winner and one or more losers?  Do we have to accept that office politics and judicious use of communication is just a fact of life in business?  I would argue that in a company (or at least on a team) there is an over-arching common goal that is shared among all staff.  While it might sound idealistic, working together towards a shared goal not only means that goal has the greatest chance of success, but ultimately will ensure everyone involved comes away a winner.

Corporate Culture and Office Politics

It should be noted that not all office politics is bad.  The process of building a community; making it healthy, cohesive and satisfying for its participants can be as much a political feat as that associated with negative connotations.  The difference between pathological and healthy, constructive politics is an important distinction to make.  To quote DeMarco and Lister:

An organization that succeeds in building a satisfying community tends to keep its people. When the sense of community is strong enough, no one wants to leave. The investment made in human capital is thus retained, and upper management finds itself willing to invest more. When the company invests more in its people, the people perform better and feel better about themselves and about their company. This makes them still less likely to move on. The positive reinforcement here is all to the good.

Individuals and teams alike are motivated and catalysed by the feeling of accomplishment; that delivering a quality product or result is worthwhile.  You can take pride in the workmanship or style in which that result was achieved.  If the sense of achievement and common purpose is removed through pathological politics, everyone very quickly begins to see that hard work and dedication – while being a nice organisational virtue – is not as important as butt-covering and protectionism.

If a team is assured that extra hours at the office will be well-rewarded and recognised if it means that a product can be delivered on or ahead of schedule they will likely put in the effort needed to achieve that goal.  This will be at the expense of time at home with the kids, out with friends or doing the sorts of things that give people respite in their own personal time and allow them to “recharge the batteries”.  Now assume that, having delivered the aforementioned product, the team is told that the recognition or appreciation promised won’t actually be in the form of a bonus, or won’t be an elevated pay rate for the additional hours, or will be merely remembered when the next round of performance reviews are due.  The motivation, enthusiasm and dedication of that team is immediately stripped and replaced with resentment.

If a senior manager is concerned that the team will collectively argue their case for, say, a promised day off or bonus, and decides to take each individual aside and explain that “we didn’t actually give specific assurances and you can either take what we’re offering or leave it”, politics come into full play.  Each individual on the team feels pressured and intimidated without any support from his peers.  People aren’t stupid.  They can see the divide-and-conquer approach being taken in the relative privacy of the manager’s office and react by becoming defensive, resentful, angry and disloyal.

People are by nature reasonably perceptive creatures and will interpret what they view as being unfair, unilateral or otherwise negative changes or initiatives (rightly or wrongly) as deliberate acts; thereby reinforcing a feeling that they need to guard or actively work against that person or their efforts.

Successful change comes from open and honest communication, genuine attempts to share responsibility and credit and by allowing each person on the team to make equal, worthwhile contributions to that team’s success.  A manager’s role is to motivate change, create vision and develop political support (getting the team’s “buy-in”) even before any transition occurs.  If a team feels excluded or disempowered, the task becomes an “us-and-them” issue and no matter how well-intentioned any project, idea or goal is, it will at best be a struggle to achieve as individuals work to achieve their own needs; or at worst actively work against the goal becauses they feel so removed from the decision-making process that affected them.

Office Politics is totally unavoidable in the workplace, but it can be a force for good so that everyone wins if all members of the team – at all levels of the hierarchy – recognise the contribution they each make and actively work together to achieve those goals.  Maybe my reaction to that children’s TV show was just me projecting my resentment that life wasn’t so optimistic and inclusive in more companies, in which case maybe I need to take steps to see if the relationships and communication within my wider team is improved to the point where everyone’s main goal is to help each other succeed above all else.  Ultimately, isn’t that the best option to make sure we’re all winners?

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.

Overlooked Software Waste: Obsolete Code

Lean Software Management is an excellent approach for development teams who need to become more efficient and – more importantly – more mindful of their work system.  Even if you aren’t very familiar with Lean concepts, the underlying key principle is very simple: Eliminate Waste.  Waste, to use a simple definition is anything – anything – that is not adding value for customers.

Within this waste category are seven subcategories:

• Partially done work
• Extra processes
• Extra features
• Task switching
• Waiting
• Motion
• Defects

Partially done work, to quote Mary & Tom Poppendieck’s book, Lean Software Development: An Agile Toolkit:

Partially done software development has a tendency to become obsolete, and it gets in the way of other development that might need to be done.  [It] ties up resources in investments that have yet to yield results.

If the partially done work never makes it into production, that effort is effectively written off, which carries a significant financial impact.

But what about software that’s already obsolete?

Without citing chapter and verse about TQM and Quality Assurance processes, software carries an implicit total cost of ownership.  So often, we see a business or client who, on receipt of the product, smiles thankfully and never touches it again.  But software is like a house: it needs maintenance or it deteriorates.  The longer it is left to languish, the more holes begin appearing as time or technologies move on and extra features are gradually added over time, reducing its stability while increasing complexity.

So does obsolete code fall under the “partially done work” category?  In my view, close but it’s not quite a fit.  What about defects?

According to the aforementioned book:

The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected.

This is probably a better fit for out-of-date code, but still doesn’t quite grasp at the insidious effect age has on software.  Even if no actual defects are encountered in a 6 or 7 year life span, the real implications aren’t felt until it’s time to upgrade the hardware or add that one last feature that requires a full rewrite.

I don’t believe it is any one person’s responsibility to ensure that software is regularly maintained and updated.  However as the team lead / development manager, you have a responsibility to clearly illustrate the costs and risks of aging code to the executive, client and any other decision makers.  Chances are this is the sort of topic that has been given approving nods and murmurs of agreement, followed by “we’ll definitely put that on our list of things to do… right after we finish the current backlog of work for this other project”.  Putting it off till tomorrow is a guaranteed way to ensure that it gets put off indefinitely.

Typically cost is another reason why investment is not made in existing applications or sites.  Too often the perception that “we just don’t have the budget for that right now” is an acceptable final word on software maintenance.  And that may well be true, but what is also left unappreciated is the rising cost to ultimately make the decision to upgrade.  The longer this is left, the harder to carry out it is.  Code ages, environments and operating systems come and go and complexity (or worse, convolutedness) increases as different developers come and go, adding their own style to the code base.  Saving a little money now neither does the developer, the client or the company any favours in the long term.

There are two (well, there are plenty but I’m picking on two) solutions to addressing obsolete software: push for (demand, even) a commitment from upper management to invest back into their software to ensure that the application doesn’t cost more to maintain (or even completely rewrite) in future.  Alternatively, just get on and start upgrading.  Explain that no more major enhancements can be facilitated until the code base is in a more stable and maintainable state.  One of these will probably meet more resistance than the other.  In my experience, it is often the former.  If a business has neglected an application to the point where it should almost be condemned, it also means they probably aren’t paying much attention to their software assets generally and are therefore either unwilling or unable to make good, cost and risk-based decisions.

Because ultimately, what is the alternative to fixing now or fixing later?  If your company is prepared to let its developers spend twice as much time (or more) adding new features or fixing bugs than they have to, perhaps it’s not the sort of company that has the sort of sustainable culture that allows a developer to thrive anyway.

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.

Managing Your Software Mortgage

Technical Debt

Every developer has at one time or another faced the situation where the client asks for a “minor change” to the stated requirements.  Often this might be wording, layout or styling.  Other times it could be a functional change that appears to be a minor tweak but has far-reaching impacts that cause your household appliances to eat your pets.

The difficulty (at least for me) arises when the client says something like

It’s just a small change, isn’t it?  It should only take you an hour at most

This always makes me uncomfortable because I want to do what the client’s asking (I like to please people) and from their point of view, they’re quite right that the change they’re asking for appears to be a very simple one.  However, I also know from experience that since they’re asking for this change during our release phase (i.e. we’ve done testing, UAT and pre-production) and it Just Can’t Wait it’s extremely risky and means that the testing I’ve done will effectively be rendered invalid and my version control will no longer reflect what’s being released into production.

So what are some good counter-arguments to clients who simply have to get that one last JavaScript animation on that text block?

Your Software Mortgage

Your Software Mortgage is the technical debt you incur whenever you have to “just get it done” at the expense of code quality or attention to process.  This might mean you don’t comment anything and just throw it together quick and dirty in time to meet your deadline or you don’t document this part for your handover & support notes.  The upshot is of course that you’ll have to go back and do it right at some point.  The cost of having to do this instead of concentrating on your next iteration is your technical debt.

It’s not a 1:1 relationship either.  To get your code back to an acceptable standard (“paying your mortgage off”), you have to forego spending time on your next set of deliverables.  This means that not only is the client paying for deliverables that can’t be started yet, they’re also paying again for work that has already been delivered.  In order to make your debt repayments, you either need to deliver the next set of requirements early (ideally without incurring more debt) or negotiate a reduction in scope for the next release.

In order to evaluate the cost of technical debt against cost of lost business opportunities, the client usually benefits from seeing the impacts in dollar terms.  This is would be easy if it was actual money being discussed, but technical debt is a more abstract concept and therefore difficult to quantify.

Quantifying Your Liquidity

Liquidity determines your ability to pay your bills

Being able to put an actual figure on your liquidity gives you more leverage to negotiate paying off your existing debt or avoid taking on new debt.

If your liquidity ratio is high (i.e. you have a high capacity to take on new debt), borrowing against your software quality will likely be less of a risk and you may feel more comfortable taking a quick and dirty approach in order to meet a deadline.  However if you have low liquidity (i.e. you’ve already taken on a lot of debt) there is considerably more risk in falling further behind on your mortgage payments.  As already mentioned, your code base must be maintained to keep a minimum standard of quality and supportability or you risk Software Decay:

[Software Decay is] …code decayed to the point in which fixing anything in a hazardous proposition – every fix is likely to break something else.

So how do you calculate your liquidity?  Accounting has a number of different approaches, but most are more complex than the abstract idea of software management allows.  However, the current ratio, which is the simplest measure and is calculated by dividing the total current assets by the total current liabilities can be loosely applied to code.

Depending on how granular you wanted to get with your reporting, you could either measure Lines of Code (LoC) or discrete functional blocks for a broader view.  Let’s assume you have exactly 100 separate methods that made up your application.  If your latest release required that 10 of these methods were rushed through and needed work, your current ratio would be 100 ÷ 10 which (obviously) equals 10; or – to put it another way – a ratio of 9:1 (i.e. for every code block needing refactored, you have 9 others that are considered optimal).

Deciding what constitutes an acceptable ratio depends a lot on your application’s complexity and size, but a general guide might be that a ratio of 3:1 (i.e. 25% of your code needs refactored) should be considered to be the maximum sustainable leverage your code base can afford and anything over 2:1 should be setting off alarm bells.

In short, keeping your unintended debt down gives you more room to intentionally take on debt when it’s useful to do so.

Risk Ratio

The later through the development / deployment process a change is submitted, the greater the risk associated with it becomes and the higher the cost to fix the consequences of that risk is.  If the client is asking for a change to be made after all testing phases are complete and the release is being deployed, it stands to reason that there is a much higher risk of introducing new problems than if the change had been done in the design phase.  This Risk Ratio is the proportional increase in the amount of work required to fix something relative to when it goes wrong.

The Risk Ratio is an extremely valuable bargaining chip that quantifies the potential cost to the client of their requested change.  It forces them to consider the financial impacts of the change from a cost/benefit perspective.  An example Risk Matrix that has risk weightings from a scale of 1 – 10 looks like this:

	Requirements Analysis	Requirements Review	Design	Build	Functional Testing	User Acceptance Testing	Deployment Testing	Release
Typographic (spelling / punctuation)	1	1	2	2	3	4	5	6
Copy (text / wording)	1	2	2	3	4	5	6	7
Cosmetic (styles / layout)	2	2	3	4	5	6	7	8
Functional (client-side)	2	3	4	5	6	7	8	9
Functional (server-side)	3	4	5	6	7	8	9	10

This matrix provides a quantifiable measure of how serious a change is based on the iteration’s progress.  You could use this as the basis of a calculation to determine the potential cost in dollar terms for any adverse impacts resulting from an unplanned change.  For example, if the client requested an existing style to be changed on your web application during your UAT phase and that style affected the layout for three pages, then you are tell the client that based on experience, there is a 60% chance that introducing a change at this point will cause a problem further down the line.  Given those odds of just under 1 in 3, there’s an extremely good chance that one of the three pages affected will suffer.

Alternatively, you can use this matrix to argue that any change being made at this point will require 6 times more effort to fix than if it had been raised during the outset of the project.  This is not an outrageous claim when you consider that the requirement might need to be formally documented, approved, developed, unit tested and acceptance tested again.

Technical Inflation

Technical Inflation could be viewed as the ground lost when the current level of technology surpasses that of the foundation of your product to the extent that it begins losing compatibility with the industry. Examples of this would be falling behind in versions of a language to the point where your code is no longer compatible with main stream compilers.

Managing your technical debt and inflation requires you to have a very clear understanding of how your debt is distributed.  Documenting candidates for refactoring is the best way to get a clear idea of the scope of work required to keep your application well-maintained.  This might be done using a source control system such as Microsoft TFS, where tasks, bugs and other work items can be recorded against a particular change or section of code; or using third-party tools such as AgileZen.  Think of this as your Application Balance Sheet where your assets and liabilities can be easily reported on.

Technical Inflation is a direct product of sustained low liquidity and software decay.  The longer you leave something before fixing it, the more expensive it becomes to fix.

Ensure you have a clear idea of how much debt your application currently has so that you can make informed and reasoned arguments against adding any more work to an otherwise hard-to-see pile.  If you need to push back on a client’s demands so that you can ensure the sustainability of the client’s application, you will need evidence of why.  Having your books in order is a critical piece.

Further Reading

Don’t Enron Your Software Project

Monetizing the Technical Debt

Following By Example: The Role of Effective Leadership

There are any number of things that can work against a TTL‘s ability to perform his or her job effectively. These might relate to infrastructural limitations (i.e. availability or connectivity constraints), restrictive policies (e.g. information restriction, defensive internet / website policing), environmental inhibitors (e.g. fragmentation of time, noisy or interruptive work area, physical separation) or inter-personal difficulties (e.g. siloed specialist teams, dependence on (groups of) individuals with other priorities or skill sets, availability of key personnel).

As the TTL, it is typically your role to ensure that team members are shielded as much as possible from counter-productive working conditions; minimising their effects where possible and trying to effect some change where practicable. However trying to achieve this on your own can be taxing at best and near-impossible usually. This is where your own line manager comes in. Just as it is your job to work on clearing the path for your team to work at their best capacity, so it is your manager’s responsibility to enable the same for you. Having an effective and actively engaged manager is a – regrettably – often rare privilege.

Engage with the team and understand their project

Having an active interest in the project helps ensure the development team feel recognised, appreciated and valued.  This doesn’t mean taking an active hand in the running of the team, micro-management or making decisions on the team’s behalf, but just having a physical presence adds a great deal from a psychological point of view.  The TTL will generally feel that their work has visibility and adds value, the fact that management aren’t interfering but still taking an interest sends the message that they are on the right path and the TTL will feel that issues or problems will be taken seriously and can be addressed easily because the manager is readily available for those types of discussions.

Support your Team Lead and back their decisions up

Typically the TTL role has only implied authority but no formalised line management, financial responsibility or personnel (hiring) authority.  Therefore, when the TTL makes a strategic decision or delivers a communication around a particular issue, it is reasonable to expect that such an act is well-informed and well-intentioned.  In these cases, the TTL needs to know that their line manager has faith in their ability and will support their decisions.  If  the manager just sits on the fence or tries too hard to please everyone, then the risk arises of an implicit message, “You have no autonomy or authority and I will undermine your decisions if they don’t fit my personal style”.

This form of Defensive Management is destructive and shows that the manager doesn’t trust his / her own people.  People who feel untrusted have little inclination to feel engaged in their company or to bond together as a team.

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

Respond to TTL communications and proposals in a timely fashion

It’s to be expected and quite understandable that managers are typically busy people and are often away from their desk. The usual approach to this is for the TTL to send an email asking for a response or an approval for a particular action. Not responding (or – at a minimum – agreeing to respond by a certain date) sends a dual message of “Not only am I not physically present when you need my input, but I don’t view your communications as being important”.

This point relates to the previous in that a development team, and the TTL in particular, rely on the reassurance that the team is headed in the right direction.  Think of it as the “I told her I loved her when I married her” style of management.  If management aren’t treating issues, communications and requests for action with an audible degree of urgency (even if the response is, “let me think about it and get back to you by…”), then the team members are left to fill in the blanks to their own detriment: “my manager doesn’t respect this team”, “this company doesn’t care whether this team performs or not”, “I only hear back from my manager when something goes wrong”.

An effective leader is one who doesn’t need to interfere, audit or control the operations of a development team, but is available for discussion, makes a physical effort to show their presence on a regular basis and acts quickly on communications sent by the TTL or team members.  He or she will give the TTL freedom to act in the best interests of the team they are leading and the freedom to be wrong in the manager’s eyes.  In short, they act in a way that sends the implicit message that the team’s efforts are valued, respected and visible to those outside of the immediate project.

Recognising a team’s work and their efforts regularly demonstrates tacit approval, encouragement and respect.