‘A’ Level Software Development Leads

‘A’-level software development leads aren’t the people who write the best code.

That’s an ‘A’-level senior software developer.

No, the best development lead is someone who can take mediocre or junior developers and have them perform at a level that takes minimal effort, produces easy results and makes everyone look good.

How do you do that?

  • Automation: Automate everything you can, whether is through programmatic scripts or documented procedures and processes.
  • Documentation: Documentation is king. It’s how developers know those procedures and processes, and how to find solutions to problems that have come before. It’s hated by those who have to write it but loved by those who need it. But it’s not enough just to write – you have to write the documentation well (it’s usability for words).
  • Time and effort: It takes both to do the work to automate and document. It takes both to learn the people you need to lead and manage.
  • Mentoring: Everyone – everyone – needs at least one mentor to help them learn, understand and grow. If you can mentor those you lead then you’re not a leader.
  • Dedication: If you’re not dedicated to the task then you will never get the most out of those you lead.
  • Understand, acceptance, patience, empathy and reflection: These are not things you do, but they are things you need within yourself to be a leader. These allow you to grow as a leader and allow you to get inside the mind of those you are leading.

There are no shortcuts to either leadership or the ‘A’-level. If you’re not prepared to commit completely you will never be an ‘A’-level leader.

 

(The astute may notice something seems missing from this is: anything to do with coding and technical understanding. Those aren’t required by an ‘A’-level software development leader. They are required, but in the same way as reading and writing and breathing are required. Which is to say, they are not even worth mentioning.)

The State of Websites as We End 2018

In a word: fucked.

Have you noticed that just about every website you visit nowadays shows a popup that either asks for your location or wants to push notifications at you?

Or you see an article in the Google suggestions feed only to find it’s behind a paywall?

That’s on top of the 5 million ads embedded in the page or popping over what you’re reading because you moved your mouse or it hit a timer.

I long for the 1990s when the worst you had to worry about was a page visitor counter and/or a subtle “guestbook” icon at the bottom of a page, and good old <blink> and <marquee> text just sitting there quietly doing its thing.

Hey recruiters. Networking. NET-WORK-ING!

Stop freaking spamming me on LinkedIn because your keyword search said: “I look like a good match”.
I’m NOT!
I’m a consultant and business owner. Look at my full profile! I’m not at all interested in the permanent full-time programmer positions that you think “I’m a good fit for”.
I’m so sick of this crap!

Either figure out how to do your job of actually connecting with people or go back to serving coffee at Starbucks or McDonald’s or whatever minimum-wage job you were in before you decided to become a database-keyword-searching monkey.
Because day-on-day that’s all you sell yourself to be. That’s all I see in the messages from you.

I struggle to have ANY respect for people in the recruitment industry today. You’re doing yourselves a disservice in every interaction.

I’m a business owner, and employer, ramping up and wanting to employ more people in the coming years – and I won’t be going to any of you.

Instead, I’ll continue to develop my own networks – through the “old-fashioned” way of actually talking to people.
At least I know I’ll find people who are an actual fit for me, not just a keyword match.

LinkedIn

As 2018 comes to a close, the only conclusion I can come to about LinkedIn is:

It’s like Instagram, for professionals.

Which is to say, it’s trash.

 

Update, 29 March 2109: That’s why I deleted my account a few months ago. And I don’t feel like I’m going to lose any valuable opportunities through it.

Where is the recruiter help?

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.

Stereotypes exist for a reason

A stereotype is just a label we apply to something – more appropriately, someone – we see that fits a well-known set of attributes of that label.

“Stereotype” is no different to other words like “classification”, “categorisation” or “breed” (for cats and dogs).

The only different is stereotypes generally apply to humans.

Attributes of a person’s stereotype might include how a person presents and defines themselves (clothing, skin colour, skin adornment, hair, speech, presentation of wealth, etc.), where they live, what they do for work, interests, activities they undertake, and so on.

Come to think of it, don’t these attributes also apply to “demographics”?

So I wonder, are stereotypes any different to demographics?

 

The problem with stereotypes is we often take it to be [and use it as] a negative connotation.

But negativity is just an opinion.

We’re don’t complain about demographics.

And we generally don’t complain that the likes of Facebook apply these same attributes to people for ad targeting?

Yet we don’t want to be stereotyped?

We are a fickle species.

Recruiters don’t help their network advance in a career

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.

Father’s Day

It was Dad’s Day in some places in the world recently.
And it’s going to be Dad’s Day here in a couple of months too.

But I’m never going to be a dad.
And my wife will never me a mum.

And as much as I love the mum and dad’s of the world and celebrate them too because they are just so awesome…

I feel a bit sad.

Because there’s nothing I’ll ever be celebrated for. Or my wife.

Because we’re just people. We work hard. We support others. We celebrate others. We act as surrogate “aunts” and “uncles”.
And we do our bit without being recognised as “something”.

And really, my wife and I don’t want recognition.

But with all the recognition to everyone else for everything – for “just being” – …
It’s kind of hard not to feel bad because we just do our bit in the background without ever asking or being noticed.

I find Father’s Day to be sad, really.

Views on Software Development Team Leadership & People Management

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.
  • Give the team the tools they need to do their job.
  • Don’t be cheap on tools and equipment. Supply computers with appropriate specifications, decent chairs, multiple monitors.
  • Give the team the information they need to do their job.
  • Give the team the support they need to do their job.
  • Be patient.
  • Don’t reprimand people. Be a “guide” for team members not performing to your standards.
  • Be very clear about standards and KPIs if you’re going to hold people to them.
  • If someone is not performing to a standard you expect, talk with them, work with them, help them be better. Raise the issue and talk to them early (don’t wait until the annual performance review).
  • Leadership and management will mean tough, icky conversations. If you don’t have the stomach for that, don’t do the job. Skirting tough conversations is dangerous for the team and work outcomes.
  • Don’t set estimates when you already have a deadline in mind. Just say the deadline and work with the team to figure out how to deliver.
  • Don’t ask for estimates then hold people to it (Dr Evil style). It’s called an estimate for a reason.
  • Software estimation is hard. Really hard. Really, very hard. Always remember that.
  • Be clear about deadlines. And why the deadline was set.
  • 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.
  • Keep processes simple.
    Keep simple checklists.
    Keep help easy to find.
    Think like soldiers and pilots.
  • Document. Document. Review. Document.
  • 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.

Skills Take Time

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.