When doing more means having done less

While no one likes working with negative productivity, sometimes we will find ourselves  not contributing in a constructive manner but detracting to the overall productivity.  This can/will be discouraging.  Becoming sour at oneself or any others in the team in whom one recognizes as a negative contributor is just adding to the madness, however.  I feel the best way to get over it is to take a closer look at what happened, to prevent recurrence, as much as possible.

What is negative work?

The idea of negative work is not readily acceptable.  Someone can deliver zero productivity by ‘not working’ at all.  How does negative work happen?

Let’s go through an example.  An awful team-member that once worked with me.  The person made roughly 3 significant changes to the work process and output over his 7-month time there.  The result first:  first 2 changes simply did not improve any part of team-work and broke other processes and capabilities.  The 3rd change was to revert everything back, explicitly.

So adding a couple, then subtracting to revert the previous 2 may look like it’s zero productivity.   The point is that that multiple people had to also follow his mistakes until it was resolved.  Don’t take me wrong – the person was not of ‘junior’ caliber.  I would not be fair to expect net-positive productivity from the get-go, especially for a person who needs mentoring and leadership.  Experience was there, as well as the ability to explain his work – the person also had the title ‘senior’.  Others not only had to track down why something wasn’t going as planned, but had to figure out whether the issues they were seeing were the result of their work or someone else’s.  Since it’s not often that the person with the mistaken sense of correctness is up to fixing whatever is supposedly done wrong, the whole team had to discuss fixing the issue. The team had to collectively determine that none of the 2 changes were worth fixing and that the team was better off reverting those changes.

Across the entire team, the result was that a lot of hours were wasted.  The one member did zero net-work and also reduced others’ productivity.  Again, I’m not saying this is a special case or that it is inconceivable.

The other kinds…

There are also many workers who can make changes that work, but end up with a large amount of confusion or lack of clarity – that others have to spend a larger amount of time trying to understand how & why those changes are necessary.  To be sure, understanding why a change is needed and how the changed process or item leads to improvement is not always necessary – and often outside scope of many mid-to-entry level workers.  And for those whose work-scope includes such an understanding, it can be time-consuming, regardless of the quality of work.  But the degree of difficulty in understanding something does matter.

Yet another sort of productivity killer is sticking to workflows that are eating up time.  I once worked at a different company where we were trying to decide on using a new way to integrate multiple developer’s work-product.  The reason:  the method we were using was taking hours of whole-team discussion, when only subsets of the team were needed for many of the integration sessions.  This was before modern integration practices (such as continuous integration, devOps, etc.) proliferated, so we did this twice a week.  Most of the team were convinced using the new method would have brought it down to under an hour.  It did not go well.  It took the team 6 months to put the new method in place, because one influential team-member didn’t want to change the existing process and was able to veto major changes.

3 hours x 2 times a week x 6 months x 4 weeks a month = 144 hours

1 hour x 2 times a week x 6 months x 4 weeks a month = 48 hours

Essentially, 96 hours were wasted.  But that is just for each member of the team.  Multiplying 96 for each member of the team would show even more egregious waste of time that could have been spent on other items.  (one excellent reason why things like BPR – business process re-engineering – is a clear need in some situations)

Negative work –> Low Morale

Most people work to feel a sense of accomplishment, aside from making their ends meet. They want to feel like their time was spent on something worthwhile. That means delivering results that bring value to the business. Wasted time prevents that.

Most of us also want to work with talented people.  Working with someone who is a burden on the team is an emotional drain.  Not only does that one person act as an obstacle to achieving success for a given item, the influence of such a person can also make us feel we bring less value as a team.

The job market is one way to solve this problem: find another job.  This is obviously an undesired outcome for a company.  When one team-member leaves, there is bound to be an emotional instability in the rest of the team.  

Entrance of the negative worker

How do such people get hired, when it is apparent that the cost of a negative worker is so high?  An interview process sorely in need of improvement can be blamed for this.  But succumbing to the temptation to lower standards or considering attitude less important than aptitude is most likely the less talked about part.  

Sometimes a lot of work needs to be done very quickly.  If there are not enough human resources in the company to accomplish that goal, then more need to be hired – either in-house or external contractual.  If the job market is strong for workers, it will take longer to make a good hire – and this is when the temptation to lower hiring standards is strong.  When there is a lot of work, some management start hiring in panic-mode.  They think having more bodies in the project can only contribute to more work getting done.

While such a mentality may have been valid in the traditional/manual manufacturing era, it is now far from the truth.  The informational and technological capability of this era ensures that quality matters more than quantity, when it comes to productivity.  10 positive, well-communicating contributors may actually bring more value to the workplace than 100 of the mix.  

Desperate hiring will not solve the problem of tight timelines in projects.  There is a good chance that it will make it worse.  Negative workers will not only slow the team down, but they can cause your great producers to leave the company or team.  Sadly, the project will now be even further behind schedule.

The flip side – a manager

From management perspective, a way to get a sense of productivity is to measure the decrease in administrative workload.  More often than not, if management tasks take less effort to carry out, with same or more level in project results, that means someone (or something) is helping to do more by allowing the management to do less.  One common mistake is to recognise ‘not having to know’ as a way to  determine whether productivity is increasing.

Management is often related to delegating work.  In a Forbes article about increasing productivity through delegation there is even  a mention of a book, “Work Less, Do More:  The 14-day Productivity Makeover”.  Single 14-day period is by no means a guaranteed time to overhaul any environment, but a basic goal is required.  A good starting point is to understand how to delegate.

Delegating work is not a ‘you know what to do, so I do not need to’ approach.  Rather, it is closer to a ‘set it and forget it’ approach.  One needs to:

• Choose the tasks to delegate
• Pick the person to delegate to
• Give clear assignments and expectations
• Set a date and ways to follow progress
• Delegate responsibility and authority, not just the task

A couple key factors in a management style that fosters team-building are:

• Trusting those who you delegate work to
• Giving credit publicly

People who micro-manage a team into decreased productivity are doing so, because they mistakenly believe that close scrutiny is same thing as attention to detail.  This failure to appreciate a team-member’s capability (potential or proven) is bi-directional, coming from lack of trust and fear of not getting credit for work done.

Now…

I recommend identifying characteristics in yourself first, that match the negative worker qualities.  Try to reduce the occurrence of exhibiting them.  Then determine how those efforts are paying off, all without involving anyone else.  When you are confident about a set of practices, or others commend you, that may be the right time to share the journey.

I would try to take the holistic approach – contemplate as both a delegator and the delegated.  Clarity in communication is always key, while committed responsibility is the path to walk.

I am interested in feedback and other ways of approach – for obvious reasons.

Advertisement

Emergent Architecture

I had wondered about what having an ’emergent’ architecture experience would be like.

To get the full experience, it took two different products and about three years of real time.

First year was about getting the proof-of-concept out the door, focused on the look-and-feel of the front-end component.

The POC was really a reincarnation of a failed project, the result of not adapting the original waterfall design to the changed technology landscape (cost-effective big-data products, for example) well, mostly ending-up in numerous pivot attempts by PM. PMO was unable to recognize the gift of gab. So now we moved to a new roadmap.

Having chosen a big-data database component, we moved to use the flashiest API tech, node.js. Here we hit a roadblock. Although the tech team wanted to validate the vision of continuous integration and delivery, we fell short on being able to execute BDD/TDD approach.

Dropping the test-driven requirement from the project, we moved to settle on an initial architecture that put data-flow and presentation on separate threads of work. Of course we would’ve preferred separate teams, but reality was that we really only had enough time to bring in couple front-end experts. The features were built by employing an approach that resembled Scrum, but modified to fit our company’s state and CMMI maturity level. (scrum-but?)

I decided to accept parts of the applications that seemed to violate my want of an API-centric architecture, because I wanted the POC to come to fruition more than having structure I like.

I struggled with it on a daily basis, but letting it go was better for our environment than enforcing some rules.

The end-result had the look, and the capability to handle most of the workload without too much issues. There were a myriad of issues, both functional and not. We knew going in that the application wouldn’t get much use this first year. We released it to two clients. It wasn’t much of a system, just an app backed by a prototype API. Even the data flow was not fully implemented, able to import a big portion of the datasets, but somewhat hacky and not exactly reproducible at the frequency we wanted. This is how the first year came to pass.

Second year was half spent in supporting the release, short-handed, as the team took some loss in resources – due to the death march prior to the release. But after a few initial months, there was opportunity to work on a new product, using the same system. Many months afterwards were spent in PMO planning.

Luckily, the previous release did not get much use, by the clients - taking less effort to maintain.

The spec came as a almost-a-CRM system that uses a rework of the previous product’s front-end component, inside a web-app. The spec also called for a near real-time customer feedback aggregation and charting -the ‘big data’ aspect of it.

Third year the team built the next version of the system, which uses the previous product as a basis to improve upon.

This it’s where it got interesting. With an actual due date for delivery already set, we had to work with a new data source as the primary data and the CRM aspect added on workload we had not worked on before. We were lucky to have a senior dev who had experience with a public-facing CRM – the work involved and how it may fail grotesquely, if not carefully carved-out.

After a month, it became clear we wouldn’t get the complete spec in time. The management called for vertical implementation of the features, in answer. However, this meant we had to adapt our architecture, as new features became clear enough to work on. So here is where the real meat of this post is.

Architecture that came with minimal pre-planning, answering minor challenges with grace, but doing our best to make sure no sweeping change will be needed. Going in without some core systems design would be opening ourselves to painful nights of haphazard changes and unnecessary risks.

 

Re-defining Software Architecture

The management made the call. Instead of continuing to work on the massive, RIA plug-in-based application, the multi-year project will now aim to deliver smaller/faster release cycles.

I rather welcome the decision. The previous project (a.k.a FRED) cost so much, in both infrastructure and ongoing development, it actually cost the VP his job in the company. (I won’t go into the details of that). The change actually fits Scrum well. Looking back, the FRED project felt like a BDUF. The design/architecture came from a third-party partner, it had modules that were logically separated-out, but it was completely based on a proprietary technology, instead of standards. Such approach was probably the result of a proper explanation of needs. So after more than a year of implementation, we were left with a brain-child product that did not fit the needs of the business.

Sound like any other requirements mismatch episode? I’m not denying it – in fact I accept that. The only thing that matters now is taking the heap and turning it into gold.

The good news is that, in FRED, we have a benchmark to compare ourselves to. The better news? We just released the first Vertical Slice Component – and it took less than half the budget of FRED, in half the time, to deliver a working product that performs well.

Turning the data we have into an asset and a facilitator of new insights into trends and patterns is the goal we have now, not just matching a spec that may “turn out not to be modular afterall”.

Release 2 is in the works. Sprint 19 comes next.