Category Archives: Soft Skills

Agile in Distributed Team Setups

“Conference Call Bingo” – Source: https://imgur.com/gallery/rfnve

Working in distributed team setups has a bad reputation – for good reasons. I remember many frustrating and useless telcos, so how can this kind of collaboration possibly work out in an agile team setup?
Spoiler alert: if you allow people to do home office you already have a distributed team setup.

After I had blogged about this some weeks ago, I was lucky to give a presentation on this topic at the ProductPeople conference in Cologne in May of 2019. You can find the slides on SlideShare: https://de.slideshare.net/AndreasCzakaj/agile-in-distributed-team-setups

How to deal with boring tasks

Source: pixabay, https://pixabay.com/photos/person-little-boy-kid-child-731165/

Over the years I’ve had some conversations with people in my teams about them feeling bored with their tasks.

In my early days as a manager my natural reaction was something along the lines of “that’s why it’s called a job, not the fun-hobby-zone”, sometimes just in my head, sometimes spoken out loud.

Fun fact: this does not help.

First, as a manager you should always be happy when one of the people you are responsible for approaches you. They are the few that speak their minds, while many others don’t and will potentially vote with their feet and quit the company.
Ever heard someone say in a job interview “I left my previous company in order to learn new things/become more experienced/felt stuck and wanted to progress”? Yeah, that’s boredom their former managers ignored.
That’s why I’m always glad when people approach me with any of their problems and I always take them seriously.

Second, empathy.
Let’s be honest, we’ve all been there. Everybody has had to work on things they found boring. It’s a real thing. The subsequent content is based on what I found useful for myself first.

When someone tells me they feel bored I reply in 2 ways:

1 – Intrinsic View – Set yourself a challenge

It’s in your head
No task is boring per se. “Boring” is just your own interpretation of a task that should best be called “repetitive“.
Look at it this way: It probably wasn’t boring to you when you did it for the 1st time.
Automate it
If it’s a repetitive task that you understand well, how could you automate it?
For instance, if you have to copy data from one place to the other, then how about writing a script?
Many great inventions were driven by boredom or laziness.
Check out “jobs-to-be-done” for example. Everything that feels annoying to a large enough number of people is a hidden business opportunity that’s waiting to be picked up.
Vary
I’ve programmed a ton of pretty common functionalities in my days like login forms, registration forms, deployment scripts etc. How about trying something new while you do it, leveraging your experience?
Maybe try to validate the data with a different and more elegant approach, avoid conditions and favor stateless functions? Get to 100% code coverage this time, try data driven or mutation testing? Try a different set of libraries or framework? Increase security, e.g. using a Captcha, honey pots, or try to hack yourself with a fuzzy logic attack script?
#TimTowtdi (There is more than one way to do it)
Abstract it & teach it
Everyone who is an expert in anything was at a crucial point in their career: “OK, I understand it now. I could move on to the next thing – or I could dive deeper into it, abstract it, teach it to others”. See also the “Feynman Technique“.
Repetition is a core element of becoming an expert.
Improve it
If you’re really familiar with a task because you’ve done it a bunch of times, then you could think about how its execution can be improved so everyone benefits from it.
Your experience is a chance to make a difference.
Delegate it
Last but not least: repetitive tasks are good candidates for things you can delegate to more Junior staffers. This implies that you have to explain the task to that person, see “Abstract it & teach it”.

2 – Mix it up

Common sense tells us that having the same people do the same things for as long as possible should yield efficient results. We can assume that they have become true experts by now.

In my experience this has proven to be a fallacy in many cases:

If people do the same things over and over again they do not necessarily get to the point of “Vary” and “Improve it”. I’ve seen teams being stuck with tools and practices like ant scripts and Subversion while the world has moved on to Ansible, Docker and git.
This is partly the reason why people go from bored to fearful about their careers when they feel that they might not be up-to-date with the job market’s demands and then, eventually, quit.
Even worse, work might be so “optimized” that it’s very hard to change anything later on. And there will always be the need for change some time.
A process designed for maximum efficiency is a common antipode of agility.
Assuming a “steady-state universe” is dangerous because there will always be fluctuation in your teams to some degree, be it attrition, parental leaves, promotions, sabbaticals, retirement – you name it.
You should have a plan for how to retain knowledge when people leave and how to onboard new people.

That’s why I recommend mixing up teams every once in a while so people get to know other tasks as well – and to ensure back-pressure against a “steady-state universe” attitude.

From a business perspective, if you do it to early then the invest of time for onboarding might not have paid off yet. If you do it too late then people might leave or work might have become “rusty”, see above. Find the sweet spot.

From a people management perspective, some people are bored faster that others. Get to know everyone well enough to know their personality and ambitions so you can identify when it’s time to shake assignments up.

Agree?
Leave your comment, like and share.

The managing n3rd, part I

Source: https://pixabay.com/en/pen-glasses-study-planning-project-2504607/, CC0 Creative Commons

When you write software, let’s say with a code base of 100,000 lines of code, and you screw up only 1 thing then the consequence might be that the program won’t work. You forget to close 1 parenthesis or 1 line is missing the semicolon at the end – as a result it won’t compile.

When you do sales, let’s say you contact 10 potential clients, and 1 of them eventually signs a 6-figure contract then you’re actually pretty successful.

When the software you wrote does not work properly then the reason MIGHT be because of a flaw in the operating system, some bug in a library you use or even cosmic rays – but in 99% of cases it’s just your own fault. The good news, though, is that it’s also you yourself who can fix it.

When you deal with people, e.g. in sales, line management or simply finding a mate, then your strategies need adjustment.
As a coder you’ve been successful by being critical and especially self-critical. If you apply the same attitude to people related situations you’ll fail.

In management, success is not having it right 100,000 out of 100,000 times. Not even close.

In people situations, failure does not necessarily demand diligent analysis. This can lead to over-thinking and making you feel bad about yourself. Failure does not necessarily demand ignoring it either.

Sometimes it’s best NOT to assume it’s your duty to fix something you messed up. Being smart but still just listening to others, showing empathy for the other instead of mainly trying to fix things – that’s the challenge.

Just as you keep learning new programming paradigms, patterns and languages you can also learn new and different ways to deal with people situations and, as a result, advance in your career to a management position.

I know it’s hard for nerds but we’re smart, creative and friggin’ hardcore. You can do it!

Agree? Leave your comment, like and share.

XLS Management vs. People Management

Source: https://pixabay.com/en/business-businessman-male-work-2879465/, CC0 Creative Commons

As a manager, how do you make decisions?

Do you mainly base them on spreadsheets and then just pick the lowest or highest value, e.g. the cheapest product or the highest profit opportunity?

Well, tough news for you: that’s what a machine can do and, boy, can it do it better than you!

If you have no empathy, no understanding of values like trust, courage and integrity or any other skill that a machine does not have (yet) then get ready to be replaced soon.

You screwed up. Now what? 8 things professionals should do next.

1. Listen

First, listen to the person who is complaining to you.
Don’t defend yourself, deny it, wipe it off, ignore it or pull an excuse.

Be open.
Mind your body language: avoid crossed arms, aggressive, exasperated or amused facial expressions.

Listen calmly, even if the other one speaks emotionally.
Showing this kind of respect and interest is the first step to restore your integrity.

You needn’t be mute all the time, though.
Ask questions: “what happened?”, “when did it happen?”, “who was involved?”.
Ask for facts – but don’t ask “why did it happen?”. It will only blur the facts and might lead to premature bias. Plus, it’s actually your job to find out the reasons.

2. Show you understand

Listening is good but you should also assert the other person that you’re not just play “the nodding game”.
Paraphrase what you have just learned.
Show you understand the impact, the problem that the other one is facing now.

3. Be grateful and show it

Always – really: always – say “thank you for telling me that”.
You may not always fully share the other one’s opinion but he/she talked to you – and that’s great.

Why?

Criticizing someone is tough. It makes people feel uncomfortable when they do it. Some folks go to lengths in order to avoid criticizing someone else to the face.
Anonymously? “Oh sure, no problem. Let’s post something on the internet…”
By email? “Yeah, and I’ll send it out late so the addressee can’t call me back today.”

But those people who criticize you do give you direct feedback although it may make them just as uncomfortable as you if you were in their position.
Ultimately, this means they care about you, especially if the criticism was face to face.

Be grateful for it and say so.
It will be the first step to restore the relationship between you and the other one.

4. Apologize

Say you’re sorry.
What exactly you are sorry about depends on the situation:

If you know you screwed up personally then say “sorry I screwed up”.

If you’ve just learned about the issue for the first time or you’d like to investigate some more before you “confess” then there’s still something you should always show empathy for:
Someone (who obviously cares about you) is having a problem, so say
“I’m sorry that you’re in this mess now”.

This way you avoid a premature confession but you still continue restoring the relationship between you and the other one.

(If you later find out you or someone else you are accountable for really did cause the problem then don’t hesitate to apologize for screwing up.)

5. Take responsibility

If you are personally accountable then say so.
Continue by promising you will take measures to prevent the problem in the future.

If you are not personally accountable or not sure if you are or who is to blame in the first place then, at least, say:
“I’ll take care of it”.

It’s important to show the other person that the time, emotional strain and courage talking to you were not in vain:
You’ll take care of it, albeit just delivering the information to the people you know are really responsible and will take it from here.

Even more importantly, this step should be the turning point.
So far you have been the “receiver” of information, the more passive partner of the conversation.
Now it’s time to become active.

You can start by saying that what happened is clearly not how you / your team / your company usually work. Continue by explaining what should have happened instead.
Say “I’ll take care of it” and start being the active partner. Assert the other person of your skills and your drive to fix and improve things in his/her interest.

6. Fix it, help fixing it

The most important task should be to fix the problem.

If you can’t fix it yourself at least ask the other one if there’s anything you can help with.

Restoring your integrity and the relationship is selfish if you don’t focus on the problem resolution first.

7. Learn your lesson

It feels strange saying this, and it might upset people who had to criticize me but screwing up is the best driver for learning.

Embrace it.

A lot of the things I know today, maybe even most of them, I know because I learned from having screwed up or being criticized for.

Analyze the problem, drill down to the root cause, research potential solutions, evaluate, implement… this is how I learned about estimations, deployments, hiring, quality assurance, project management, Oracle’s bizarre licensing terms and many more.

Also, use this step to make sure you don’t run into the same mistake or a similar problem for the same reason again. The first time it’s a tragedy, the second time it’s a farce. If you keep screwing up eventually you will lose credibility.

8. Follow up

You said you’d take care of it, so get back to the person who criticized you and show what you’ve taken care of so far, e.g.

The fix. And ask if it worked.
Show you care: ask if the other person’s problem has been resolved or at least mitigated.
You will most likely have new, updated or revised information. Share it.
Show you’ve worked hard.
Show your lessons learned and the measures you have taken to prevent the same thing from happening again.
…

What do you think?
How do you handle negative feedback?
Please leave a comment and let me know.

If you like this post then please share it.

Happy hacking!

The REAL reason why developers need Soft Skills

Leave a reply

Developers like to code.
All day, sometimes all night, too.

Developers like playing around with things.
New frameworks, yeah. New tools, whoopie.
We like to see a one-liner have big effects, or a small piece of configuration dramatically change the behavior of a program.
We look for that Arthur C. Clarke moment when “Any sufficiently advanced technology is indistinguishable from magic”.

When it comes to Soft Skills, well, that can wait for later when none of the IMPORTANT stuff is left.
Right?

Picture a new development project.

You do some analysis, some solution design and you get a rough idea about how much effort it will take.

Let’s say the effort needed is 2,100 person days.
So if 1 person does all the work, and we assume 21 work days per month then this 1 person will need 100 months to finish the project.

That’s 8 years.

The processes will be super-efficient, though, – no overhead whatsoever!
But you’ll need to wait 8 years before anyone can use the software.
Just think of the major versions of your favorite programming languages, application servers, operating systems, tools, libraries etc 8 years ago and you know how outdated the software will have become by the time it’s done.

And what about that poor guy or girl hacking code on the same project for 8 years using stuff that has become outdated years ago?
Unless you find a way to legalize slavery, odds are that this developer will quit at some point during the project.

OK, new idea.
Let’s have 100 developers work on the project.
This should make the project get done in only 1 month!
Right?
I guess you already know that this is a fallacy. Planning, coordination, integration, QA, communication paths etc, well, overhead will explode instead.
And how many of those 100 people did you have in mind when you estimated the 2,100 days?
Probably you were thinking about the effort it takes to design, implement and test the software but chances are you weren’t thinking about all the additional overhead needed to make 100 people work together.
I’m, of course, referring to “The mythical man-month” by Fred Brooks.

So what is the ideal number of people to work on such a project?
Well, it’s more than 1 and less than 100, this much we know by now.
As a matter of fact, our industry is too young to know that number for sure, based on hardcore scientific research at least.

There’s one rule-of-thumb, though, that I stumbled upon some years ago and I like to use in such situations. (I think it originates from the works of Brooks, Rausch-Schott and Retschitzegger but I can’t find the reference, sorry).

The math goes like this:
${ideal number of people on the team} := square root of ${number of person months}
In our scenario the effort was 100 months, i.e. √100 yields 10 people.*
If that was my project I might suggest setting up a team of 10 and let them work for something like 1 year. (Actually, I prefer slightly smaller teams.)

When 10 people work closely together for 1 year straight then they’d better know how to get along with each other.
They’ll need commitment, empathy, respect, reliability, team spirit, collective ownership and focus on the domain. They’ll need the ability to help, criticize and take criticism, make rules and follow them and most importantly:
They need the willingness and the skills to communicate about the project every day. Well. A lot. Even face-to-face.
That’s the Soft Skills required for such projects.

What if you don’t have these skills?
Well, according to the rule of thumb you will be able to work only on projects that can be done by 1 person.
Do the the math, allow some rounding and you’ll get 2 months max. (√2 months => ~ 1.4 people)

So if you don’t take Soft Skills seriously you will be limited to projects that require up to 2 months effort. Maybe 3 months; it’s a rule-of-thumb after all.
But still, if you like to evolve into more complex challenges, well, there aren’t that many projects that are complex, challenging and take just 2, maybe 3 months to get done.

Frameworks, tools, libraries come and go but good communication and team skills will permanently add to your profile. They are the really important stuff you need for complex tasks.

What do you think?
Please leave a comment and let me know.