Problems In The Workspace
I am a software engineer that works for the US Government. That comment itself can bring up a lot of mumblings about "government workers", "inherent wasted process", and so forth. While I agree it can feel that way, understanding the difference between "Business Administration" and "Public Administration" has helped me reconcile why the government is the way it is and why you must never think of it as a business. But that isn't what this article is about.
This is a retrospective on some of the issues with my current organization that are driving me away, despite the fact that I love the mission and the work that is done in the organization. I've recently decided to change positions and wanted to reflect on some of the issues I've identified and ways to prevent them going forward. I've attempted to provide this in a positive resolution-ish context because the why and how everything got here is more of a book than a blog post.
Key Values
Before I begin, I think it would be good to define my ideal work environment. An ideal work environment is different for everyone, but to provide a bit of context, here are some key values (some of which I have previously identified in my key values post.)
- Continuous Feedback
- Creative + Innovative
- Open Communication
- Work/Life Balance
- Ideal For Parents
- Safe Environment
- Thoughtful Office Layout
- Agile Methodologies
- Promotes Within
- Internal Mobility
- Customer Comes First
- Remote OK
- Intrinsic Motivators
Problems
Like all organizations, the one I currently work in has a revolving door of issues that leadership is always attempting to mitigate. But there are a set of issues that I've not seen resolved for years now.
- Customer Relationship
- Toxic Personalities
- Ignored Process
- Security without Transparency
- Carrot and Stick Motivation
Customer Relationship
An ideal customer relationship for my current mission space would be one that feels like a member of the product development team. If there was a product being developed and there were periodic meetings to decide direction and priority of work (e.g. Sprint Planning, CCB), there would always be a representative of the customer at those meetings.
All to often I've seen overly ambitious engineers developing Concept of Operations, Requirements, and Design documents to their completion before asking for the customer's opinion. This is bad for several reasons:
- Extra work that the customer may not agree with provides negative value.
- The customer shouldn't feel the need to throw away your time and energy.
- If there is any part of product development a customer can be a part of, its the ConOp, Requirements, and Design!
Partial work products should be reviewed and contributed to by the customer. Instead of developing a complete set of Requirements for review, iteratively send requirements for review (especially incomplete requirements). We all have an idea of what needs to be written, but allowing the party that actually requires this software to feel like they can define what they want in the context you've provided will go miles in understanding the true desires of both organizations. This partial work product review process can be applied throughout the life cycle of the product development (i.e. requirements, development, and testing).
Aside from actually involving the customer in product life cycle, never consider the words written in the requirements as authoritative over the customer's true desires. When working in an organization, its almost a necessity to play the telephone game where "he said she said that he needed X." As everyone who has experienced this knows that the true intent of the request can be lost very quickly. Continuous feedback and communication with the customer is imperative for the successful development of a product with high value. Depending on requirements as if they were a contract is a recipe for spoiling the relationship with the customer and driving them away.
Toxic Personalities
7 warning signs a person is toxic states:
- You're left feeling emotionally exhausted after an encounter with them.
- They try to intimidate you to get their way.
- They try control you by guilt tripping.
- They are easily jealous.
- They constantly see themselves as a victim.
- They give backhanded compliments.
- They're overly defensive.
Yep, we all know who these people are in the office. If they provide clear value (through non-social strengths) to an organization, I can understand rewarding or promoting an individual with these attributes, but I would hope that they quickly reach their ceiling and learn that this behavior is unacceptable.
Nope, thats not how the world works. Unfortunately these types of individuals pollute the work environment at all levels. The line for me is when these types of individuals are given responsibility that others depend on. That action causes peers to have to work with the toxic personality. Without a strong morale in the office, this is likely to drive morale to the floor and ultimately cause an organization to lose its best people.
Although I've definitively clarified my position with these kinds of individuals, their treatment of my peers and direct reports hurts me personally, and I hold my leadership responsible for the delegation. One thing I've always tried to express to others is there is no point in fighting down to the toxic individual. It should be the individual that delegated the responsibility to the toxic personality that is held accountable for their actions.
Ignored Process
All mature organizations should have well defined processes. I find that most folks equate "well defined" with "quantity" and this simply isn't true. Well defined process is simply a process that isn't ill defined (or undefined). For example, you may have a certain way you like to make a sandwich. Simply making the sandwich is an ill-defined process. But once you write down the recipe for making the sandwich, it is now a well defined process.
Having a well defined process doesn't mean having to fit within a one size fits all set of constraints, it simply means writing down how you accomplish your work and how folks should interact with you. I heard a great idea the other day (from Hanselminutes) where all the members of an organization are asked to write a user manual for themselves. This is where you define how you want to work, (e.g office hours, private hours, process for scheduling a meeting, review request process, etc). From a set of documents like this for each individual, everyone can be on the same page and then work to compromise on a common culture.
When things go sour, its often due to:
- Process being instated or codified that has little to no buy-in from the workforce.
- A double standard where some projects are allowed to skip process while others are not given that luxury.
- Providing no observable value, for example ramping up process to mitigate lack of requirement understanding and test coverage, but then ignoring results as mitigation.
It is important to either enforce process or have a healthy habit of updating process to meet the current needs of an organization. Mandatory and mature retrospectives as part of an organizational process (and culture) help to facilitate keeping process fresh and the "right size".
Security without Transparency
I work in a secure environment. This means we have networks not connected to the internet and locked rooms that you can't be in without personal escorts. All of this is understandable to a degree. I understand the need to protect intellectual property and proprietary knowledge. But there should be complete transparency about what is being protected and why it is being protected.
Often I find leadership knee jerk reacting to some security incident and then suddenly they need to get everything behind locked doors without knowing what they are securing. More often then not, they end up decreasing the value of their processes by incurring a significant amount of undue burden on the engineers to work in unjustified constraints.
Furthermore, an organization that doesn't have a clear idea what they need to secure is less likely to allow for telework or remote work. This is due to the fact that any work done remotely is inherently less secure due to the potential for internet involvement and the lack of a fully qualified IT department at the individual's residence.
Carrot and Stick Motivation
Carrot and stick motivation is the idea that we can reward people for good things and reprimand them for bad behaviors and over time they'll perform better. Research has clearly shown that this is only applicable for mechanical or trivial tasks that are repeated often (e.g. an assembly line).
For more creative, innovative, and cognitively demanding work (often associated with engineering), you need a different approach. Research has shown repeatably that, assuming an individual has become comfortable with their wage and work environment (extrinsic motivators), the most effective way to further motivate workers is to ensure they have intrinsic motivators (mastery, purpose, and autonomy). Here are the primary intrinsic motivators as mentioned by Pink, D in his book called DRiVE:
- Mastery - Allow workers to improve themselves.
- Purpose - Everyone must know how the big picture doesn't work without them.
- Autonomy - Allow workers to accomplish their tasking in their own way.
Mastery is not about telling someone to do some training, its about allowing the worker to have the space to learn new skills and obtain new knowledge applicable to their job. Continuously tight deadlines and continuous priority one tasking prevents workers from feeling like they have space to master their trade.
Purpose is not about telling someone how their piece might contribute to the bigger picture. Its about telling the worker how the bigger picture depends on their piece. Strategic development, where we develop our own requirements, spits in the face of purpose. We can often sell it initially, but in the end it makes folks feel betrayed and empty due to the unused product and loss opportunity for the feeling of accomplishment.
Autonomy is not about allowing the worker to do whatever they want. Its about letting the worker do things differently than their peers to increase productivity and value output. Having an over bearing process that isn't prescriptive to the needs of the workers eliminates autonomy. Also, as a team lead, not allowing teams to develop their own cultural way of doing things internally goes against having autonomy as an intrinsic motivator.