Author: Steve Padraig

One of the most difficult things for leaders to do is trust its software engineers to do what they do best – often because they don’t understand software engineering and always think the wool is being pulled over their eyes. They get a little knowledge and micro-manage.

We need to let the software engineers do what they do best. Software engineering as an art and a science. Have you ever noticed how you slow down and make mistakes when someone is looking over your shoulder? Artists make mistakes, they erase things, and begin again. Scientists make and break things, they use and refine calculations until they get perfection. That is also how software engineers work.

My course on Software Development Management will give you the Knowledge & experience to promote Teams that are:

• self-managing
• self-organizing

I can provide you the knowledge to be a Leader of high performing organized Software Development Teams using traditional or agile methods to:

• trust to make decisions
• value their opinion and expertise
• listen more and talk less to value their expertise
• give them breathing space to make mistakes – that is how people learn.
• be efficient without compromising quality.
• reduce costs through automation, reusability, & efficiency.
• be subject matter experts in the evolutionary control of software using tools, processes, & methodology.

I teach you to understand so the wool cannot be pulled over your eyes – and your team will know that. They will value you, and you will value them. You will know how to recruit, retain, and develop the best team possible.

When hiring I focus on software engineering & mindset which is 90% of the job & cannot be captured by ATS or tests. Discussion with experts will. Language & qualification are secondary. I created this guide to write my job descriptions, scan resumes, & interview to capture what the ATS cannot.

1. Developer codes single objects. Engineers systems of multiple reusable objects.
2. Smaller projects a jack-of-all-trades. Larger a specialist in each area.
3. Qualification alone is no use. Real experience is. Academics can solve tests but not necessarily real problems. Experienced people solve problems but not necessarily tests.
4. Domain specific know one industry. Others bring new ideas to the table from a variety of domains.
5. With tools, processes, and technology zealots are fanatical & uncompromising, pragmatists are practical, evangelists seek to convert others to their ideals.
6. Optimists assume code never fails so reduce tests. Skeptics assume code will fail and increase tests.
7. Great engineers’ question & constructively criticize. Others do whatever is said without question.
8. Many love to write new code – but few to debug. Fewer will debug someone else’s.

A while ago, I did a root cause analysis for a Toronto client. They had problems with a software engineering team having the most trivial of tasks always missing deadlines. We found the root cause in recruitment not Software Engineering.

Job descriptions listed academic certifications as must-have. ATS found academic certification but could not convert to equivalent experience. Candidates then subjected to academic tests by HR which were assessed using a third-party. The Software Development Manager was out the loop until HR and ATS had filtered out the experienced. The team was 100% academic and needlessly over complicating solutions.

• Academics can pass tests but have little if any experience to solve real life problems. Theoretical knowledge often is irrelevant in the workplace.
• Experienced people have real-life experience and may find tests suited to academics harder – but in the real-world flourish.
• Academics focus on theoretical perfection even if it doesn’t make a difference.
• Experienced people focus on what makes a difference to the business.
• Academics over complicate to prove a theory whereas the experienced simplify to make it economical and efficient.

The solution was the Software Development Manager scanning resume’s after the ATS and HR had their duties reduced to within their capabilities.

I’ve been asked to do an independent root cause analysis for a client on a software engineering project. It was a leading question as they indicated lack of testing.

In my opinion lack of testing is never the root cause but the penultimate symptom – but the sequence of events that led to a leadership decision for lack of testing is. That is normally buried in the culture and environment – the people, processes, and technology. Lack of testing was the last item to test the other items that failed.

A root cause analysis is often the beginning of a change to a culture or environment. They are often met with resistance that employee’s do not feel comfortable presenting, or feel pressured to lean one way or the other for fear of offending someone. They often default to “lack of testing” as the root cause . As an independent with no “internal politics” to deal with I am free to gather findings without prejudice.

Preventative actions are often training, mentoring, and coaching – oh and sometimes patience because technology when done right can’t be rushed.

Without doubt the two most common features that I find whilst performing a root cause analysis are not lack of testing but:

• pressure from non-technologists to implement change to fast and scheduling change without first understanding the impact and risk
• inability of technologists to explain and non-technologists to understand the intricate nature of Software Development Management

Where are all the Software Development Managers?

Many of the Software Development Manager positions posted today in Greater Toronto Area have been posted consistently since I arrived here some 6 years ago. A similar story is told worldwide. It seems some get filled but 3 or 6 months later the same posting is back. One thing that can help fix that is proper training, mentoring, and coaching by an experienced hand.

Qualification alone is not useful unless we have real experiences is a concept widely expressed by great writers but time and time again we see qualification as the main criteria for selection. The Software Development Manager training combines your qualification with my experience. Qualification tells us someone has the knowledge to do something, experience is proof someone can do it.

You want how young and how much experience?

You want to develop new talent, Generation #, or the Millennial’s but you also want the experience of an expert with 30 years of software development management and software development life cycle (SDLC) experience. It could be that you have a “Women in Leadership”, “Women in Tech”, or “Young Person in Leadership” initiative but to get things moving now you need an expert Software Development Manager regardless of identity to train or mentor them. I’ve seen so many job advertisements asking for just these types of candidates. You can’t have your cake and eat it was my first thought and that is why I reinvented myself as a trainer, mentor, and coach after 30 years in Software Development Management. Now you can have your cake and eat it – but you will have to partner with this boomer to do it.

There is an old Irish proverb that says:-

Wisdom makes a poor man king,
a foolish man reasonable,
and a good generation of a bad one

Delivery Methods

I train, mentor, coach groups or individuals using a variety of delivery methods depending on whether you are local or in the Greater Toronto Area – face-to-face, telephone video conferences, online meetings etc. You can buy a complete course or by the hour consultancy. We can also agree for an amount of time that we I provide further support after the course is completed.

Do you need a shadow?

I can also work as a Consultant Software Development Manager, Director, or VP and work alongside you to train, coach, and mentor you into the position – as a shadow. I will work with you to accomplish everything to do with the Software Development Manager, Director, and/or VP role. Together we will lead high performing organized Software Development Teams using traditional or agile methods.

What else do I offer?

1. Root Cause Analysis & Expert Witness
2. Speaking and Writing Engagements
3. Review and Audit your Software Development Management and SDLC
4. Provide Professional Opinion and References

Who do I work with?

I can help anyone involved with Software Development Projects – not just the Software Development Manager. This is not about writing code but managing it, answering the why’s, knowing the potential problems and the solutions, how to build teams and get them working, and how to communicate between technologists and non-technologists:

1. Executives
2. Entrepreneurs
3. VP’s
4. Directors
5. Managers
6. Software Engineers and Developers
7. Sales and Marketing
8. Anyone involved with Software Development

Prepare for 2020

Get ready for 2020 and kick start you, your employee’s, and your organisations future in Software Development Management. Contact me through LinkedIn or software-development-manager.com and/or send a connection request to get latest updates and mark me for future reference.