I have been thinking about the relationships we all experience to the work product we are responsible for. The degree of authority we express over some work product, the degree of autonomy we have over some work processes, and the degree of responsibility we are assigned for that work product dictate our role or relationship with that product, and potentially can affect our productivity and job satisfaction.Continue Reading
Posts Tagged with leadership
Development Anti-patterns
Fear Driven Development – When developers are under time pressure, and are more concerned about their reputation than their code base. They tend to deliver half baked code with all kinds of smells – to get it out the door on time – without thinking of the consequences. When their bad practices are called out by others re-working their work product – they deflect responsibility, blame others, and exhibit all manner of personality defects. The core of it is this:
“Fear turns non-competent learners into incompetent blamers.”
In order to invert this anti-pattern, we need to remove fear of reputational loss. This is necessary for healthy collaboration and learning. This could be accomplished by destroying the reputation publicly no reputation, no fear. This could be destructive, or constructive – but it works fast. This could also be accomplished by exposing a value system that displaces the fear. This is a longer road, and a more positive, happy road – but it requires a tremendous amount of thought and preparation.
Date Driven Development – When developers are incented by schedule alone, you will get all manner of bad behavior. Incomplete features swept under the carpet. Taking technical shortcuts designed to get us into production, but requiring a complete rewrite in 2 releases. Developers in this practice often collaborate well, but never expose to management just what shortcuts or compromises are taken. Often, you are lucky to get through acceptance testing before the software turns into a smoldering heap. The core of this is a management problem:
“Schedule is more important than cost or quality.”
In order to invert this anti-pattern, we need to understand the cost of the date in terms of re-work, and allow the management to make a different decision. They still could choose the date, knowing the cost – but you may actually get to do the re-write – instead of living with the steaming pile for 6 releases of hell.
Documentation Driven Development – When developers are responsible for documentation in a high ceremony, heavy software development life cycle, it often is the completion of documentation that is audited, rather than the code or the content. Developers forget that design is about making good decisions and choices and simply document the arbitrary compromises they made. The core of this anti-pattern is a world view:
“Process is more important than talent.”
In order to invert this, an infusion of talent is required. Talent values talent. Making project managers with limited development skills into team leaders or middle management, or allowing your software development methodology to become infected with regulatory documentation requirements being the two likely initiators of this anti-pattern. Go hire some serious talent, and let them hire some more talent. Listen to those talented developers tell you how you can do good design first, then figure out how to document that design sufficiently to pass an audit.
Die-Hard Driven Development – When developers are isolated and allowed to work “un-supervised” for extended periods of time, without integrating features or concepts together. It is hard to predict the result when you finally take a look at what has been built, but you can bet there will be booby traps, explosions and lots and lots of cursing. Often this is a result of attempting too much parallelism in an attempt to go fast. Sometimes it is experienced when the developers are very familiar with the business domain so they feel entitled to “code ahead” of requirements. The core of this methodology is process dependency inversion:
“We’ll start coding, while you gather requirements, ‘cuz we know what they want anyway.”
The way to invert this is to implement two common agile practices: 1) code swarming – rather than having 1 developer completing an entire feature – pile a bunch of developers on the feature in close collaboration. 2) walking skeleton – if the requirements are still squishy, and development has excess capacity, have them build a thin implementation of some core features, rather than building “final” versions of those features. Using these practices – drives core design concepts and implementation practices through the team together, rather than having each developer follow their own path (yippee ki yay mutha-f…). You get a small number of consistent working features soon, rather than a crap-ton of half baked inconsistent features later.
Demo Driven Development – When the process includes frequent demos to customer, it is customary right before a demo to quick-fix a bunch of defects in a cheap way to appear to have made more progress than you have. While it is somewhat disingenuous, it is hard to resist sweeping a bunch of stuff under the rug to impress your customer. The problem is when your dev’s do that without your knowledge and incur unmeasured technical debt. The essence of this anti-pattern is represented in this statement:
“We’ll keep polishing the turd, while you tell stories to the customer.”
One way to invert this anti-pattern is to implement peer code reviews. Having others review your code solves a number of problems – no programmer likes to look bad in front of an audience, even if it is their cube mate. It also helps good devs socialize better practices and new ideas.
Normalized Perspectives
As software professionals, our beliefs about what qualifies as “best practices” often depends on our experience and our expertise. This is one of the reasons that it is so very difficult to run the self-organizing software teams, frequently described in agile literature. The fact is, teams cannot be self-organizing, until the members share mental maps of both problem and solution domains. Until these maps are truly shared by the team, an external organizing force is required to ensure consistency and solidarity within different aspects of the solution.
I want to share some experience from a recent project, where I have been this “external organizing force”, and how I have observed these varying perspectives come into play, and the impact that they have had. My hope is that some among you will be able to learn from my experience, and be more prepared when you face similar challenges.Continue Reading
Stretch Role
Hiring has some words that we use to describe what we are looking for:
1) Been There, Done That – you want someone who can do this job with their eyes closed.
2) New Blood – you want someone who will never say, “that is not the way we do it here”.
3) Fresh Meat – you want someone who isn’t already burned out.
4) Youthful Optimism – you want someone who will not stop trying when things get ugly.
5) Hands – you want someone who cranks out work.
6) Brains – you want someone who can show us how to do it better.
7) Potential – you want someone who can become a star.
Hiring is difficult, because you don’t always know what you are getting. But it helps to know what you want. I like these words, because they informally signal what that I am seeking.
R.A.T.S. Delegation
In writing a recent post for my other blog
about planning and delegation, I fell into a set of 4 principles that define how to delegate successfully. The principles are Responsibility, Accountability, Trust, Success or RATS.
Here is the excerpt from that post:
But in reality, delegation in leadership is not about getting other people to do the work. It is about leadership development. It is about participatory ownership.
Delegation is not dumping the work on someone, and watching to see whether they succeed or fail. Delegation is assigning responsibility, developing accountability, building trust and engineering success…Continue Reading
What I Have Done
Recently I have had to look back on my career and remind myself what I have done. I am leading a challenging project, and at times it feels like I have team members and customers projecting their expectations for how the work will be executed. Sometimes amid the cacophony of voices, I have to remind myself that I am capable of bringing the team to consensus around strategic decisions. Continue Reading
Take Your Team to a Drag Race
One thing that I have noticed at the beginning of a project is that there almost always appears to be confusion. Confusion about mission. Confusion about terminology. Confusion about what is important. Confusion about roles and responsiblilities. It feels bad, it looks bad and it smells bad.
It’s like what drag racers do before a run. They used to pour bleach on the tires and spin the drive wheels, creating massive amounts of foul smelling smoke. The purpose of this exercise is to heat up the rubber, so on the actual run, the tire are already super sticky and get traction and the car launches like a “hole shot” down the strip. There is a science to this, but it feels, looks and smells bad.Continue Reading
Is It Me?
Occasionally – I will get into a conflict with someone, and I don’t know why. When I look back at the conversation, what I remember, it becomes apparent that either I baited someone into an argument, or vice versa.
Sometimes this happens because I attach connotative meaning to something someone says because I think I know what he or she means. Other times I have some history that comes to bear, so I project that history on top of something. In either case, the conversation becomes broken, and communication stops.
Inevitably, it turns out that I have tried to read meaning into something that someone didn’t intend, or maybe they did, but didn’t expect anyone to pick up on it, and so they are embarrassed that it was noticeable. Perhaps the best thing to do is to act as if everyone communicates superficially, and straight, and to simply communicate back at that level. To not read anything into other peoples statements and questions.
By ignoring perceived hidden agendas, ulterior motives, personal biases – my communication becomes straight; to the point. Not balled up in other peoples issues. As an analyst, I tend to try (too hard) to unwind this stuff and sometimes get wrapped around the axle in doing so. I react to my perceptions of others’ motive and agendas, rather than simply communicating facts and my opinions (when asked), I let my opinions of others interfere with communication.
Team Vs. Me
This week I have been reflecting on the relationship of ego to team, and how to deal with clashes of ego’s as teams form, and reform.
Over the last few months, I have watched a project that I am playing a key role on transform from an outsourced staff model to a hybrid staff model, to a staff aug model, to a hybrid aug model, and each transform has required changes in project leadership.Continue Reading
React or Reflect
I have been observing behavior patterns in leaders that I am around. Here is one observation:
Some leaders react to a situation, and others project the behavior that they want into the situation, so that others can reflect it back.
Sometimes this is positional. Leaders behave differently depending on the amount of automomy, or authority they have over the situation. So when leading from a position of authority they might react less, because they have the ability to directly impose change on the situation. The same leader, in a position of influence might react more, in order to generate a sense of urgency, because they have less authority. This behavior pattern may backfire, because it appears to others to be an attempt at overt maniipulation and reduces the leader’s influence, rather the opposite of the desired result.Continue Reading