Category: Opinion

Where are the recruiters who help their network “advance” a career? Or shift across disciplines?

No one stays in the same role forever. Especially in the tech sector.

I had to leave “employed” life to break free from being “just a programmer”, and still, I continue to get pinged for what I consider mid-level programming roles.
I’ve been programming for 20 years. I’m not interested. Was a recruiter ever going to ask what else I want to do?
(Well, sorry, too late. I’ve done it already, on my own. In the last 12 months I’ve now architected a business web-application platform, co-run a business and lead/manage/mentor overseas staff.)

If you’re a recruiter and want to stand out, help people move “up” or “sideways”, not just into the next dead-end, same-old-same-old job.

But then, that would require “cultivating” a network, getting to know people and staying in touch.

These are my views and approaches on leading software development teams and managing people in general. They come from the culmination of a few years of on-and-off leadership, and a lifetime of observation (plus a share of suffering under poor regimes along the way).

In no particular order:

Work for your team.

Protect your team.

Never pass problems down the line.

Don’t talk about money with the team. They don’t need to know if the project is running over budget. They don’t even need to know the budget. That’s a management concern, not a worker’s concern.
(Definitely, don’t use budget issues as a motivator to make the team work more.)

Push back on upper management if their requests and expectations are unreasonable.

Realise that almost every single software delivery deadline set by business is arbitrary. And will slip. And people will burn out and get angry pushing to deliver for a deadline that slips anyway.

Agile “story points” only work in true agile projects that don’t have time-based deadlines. Those projects are rarer than hen’s teeth.

If you’re going to hold a team to story point velocity, you’re doing it wrong (and everyone better be very clear from day one what the real effort of a point is).

You have smart, capable people in your team. Let them think and contribute.

Team discussion is good, healthy, and expected.

After the discussion, the decision at the end of the day is yours. That’s part of your responsibility.

Don’t dictate to people. Direct and guide.

Good leaders realise they have a team of smarter people or capable people, and enable the team to do good work. That’s the job of a leader – enabling.

Don’t allow or make people feel guilty about mistakes.

Understand the hurdles people face. Understand their problems. Understand the blockers.

Understand what’s slowing people down. It’s not about working people like slaves but making sure the natural pace is not slowed down (e.g. by inadequate equipment, poor process, lack of understanding, stress bubbling from management).

Don’t push people like slaves.

People are people, not resources. Never call a person a resource.

Praise goes to the team. Blame stops with leaders (never pass blame down to the team). A leader’s reward for a job well done is internal satisfaction.

Software developers need time to breath, take a break, and refresh during the day. And during the week. And periodically over a long, hard project.

Software coders should not be in front of their computer coding 8 hours per day. If they’re doing that then something is wrong.

Working software developers hard for long periods will lead to burn-out and discontent.

I don’t believe a rewards or hall-of-fame type system should exist for people who do extra work (hours) or produce extra stuff. That a) is the encouragement of overtime and, b) isolates the 90% of good people just getting their job done.

Don’t ask for overtime. Ever. (Unless you can absolutely guarantee a time-off-in-lieu soon after the reason for overtime has passed). Overtime just means fuck-up somewhere up the management or sales chain that software developers are going to pay for by fixing it.

Ask what people enjoy doing and want to do. What motivates people? What are their interests?

Give people training.

Give people support in career progression.

Don’t presume you know everything as a leader/manager – you don’t. Don’t presume you have all the answers – you don’t. That’s not your job.

Leaders don’t need to know everything. That’s why you have a team.

A leader’s job is to have enough knowledge and experience to ask the right questions, trust their staff, do research and make good decisions.

Draw the best knowledge, experience and ability out of people in the team.

A leader needs to be “people” person. They need good social and communication skills. They need empathy and reflection. They need patience and a thick skin.
Managers also need at least some of this.

Never assume a team member has a certain level of knowledge, especially in software languages, technology and tooling. For example, don’t assume everyone has the same level of Git knowledge (I recently made that mistake and had to correct it). Keep asking questions – basic questions – to understand everyone’s knowledge and comfort levels.

Listen.

Don’t talk “at” people.

Don’t talk over people.

Don’t micromanage your team, even those who are slow or make mistakes. Micromanaging is just a band-aid. If there’s a problem, work at finding and resolving the root cause – whether it’s a change of process, education or allowing someone time to learn and practice a new way of thinking and working.
Often a problem one person is having is a [silent] common problem across a team.
A soldier needs to learn to shoot a rifle on their own. Different soldiers need different paths to reach proficiency. A leader’s job is to help each person on their own path, so when the time comes to use the rifle each soldier can do it on their own without a leader on their shoulder telling them what to do.

Never stop thinking about how to improve processes, information, and team conditions.

Never bring your ego.

Finally:

Don’t elevate a good senior technical person to a lead role that they’re not prepared for, wanting to do, or able to do.
I’ve seen too many good “senior developers” with poor people skills placed in a lead role that end up hurting teams (at worst the team and project becomes toxic).
Leave technical people in technical roles.

I was sitting at my computer typing status updates for my team when my wife walked into my office. So I looked at her, smiling, and kept typing to finish the sentence as she was reading what I was typing.

When I finished she looked at me and says: “you’re typing and not even looking.”

It was then I realised for the first time in a long time I have a rather useful skill: I can touch type.

In fact, I can touch type on both a conventional keyboard and, depending on the device/operating system, on a phone.

I may be wrong, but based on much observation of others, I believe that may now be a relatively rare and valuable skill.

But I can tell you one thing for sure: it’s a skill that’s taken many, many, many hours and years of practice to master.

One instance was in relation to registering scores for the CrossFit Open. The second time relating to storing passwords on Post-It Notes.

Sure, it’s easy to say the person was stupid. They should have read the instructions. They should have understood the rules. They should know better.

But let’s understand 2 things:

Every single one of us is guilty of being a “stupid user”.

People simply take the easiest path to completing a task. It’s not their fault the path is wrong or insecure according to someone else’s standards – they just want to complete their task and get on with the day.

So no, I don’t believe there is such a thing as a stupid user.

In every instance, it’s a case of a poorly constructed interface or system, bad policy, or lack of good tooling that allows poor users to select the wrong easy path to completion.

Looking over some developer blogs of Pluralsight authors I was seeing their course titles and I realised something:

When a course has “advanced” in the title does that usually mean the subject matter is more complicated than it should be?

For example, “Advanced Dependency Injection”. Surely Dependency Injection is something we want to keep simple (though to be fair I argue everything should be kept as simple as possible)?
Can’t we just wire it up then get on with the real job at hand? What make’s it so complex there must be an “advanced” component?

It leads me to wonder why we even need a sliding scale of “easy” to “advanced” topics in software development?
What causes such complexity in a subject?
Is the topic truly large and complex?
Or are we, the developers, so lazy in our approach to implementation – or teaching – that we over complicate it (almost certainly unintentionally)?

We are now entering the age where anyone who was born in the last 10 years will be looking at the possibility of having their entire life recorded online for all to scrutinise, the good and the bad, without their choice, and they will never be able to undo that fact.

Why? Because parents chose to post the life of their children for the world to see. Because friends can record any moment they want and share as they choose.

And what goes online stays online, always available for someone to find.

We now live in an age of pervasive recording, where anything we do and say may be captured by anyone with a smartphone and shared for the world to see.