The Leadership Wake

Everything is going well until it’s not.

But all the signs were there from the beginning…

  • Jack and Sara were always butting heads over syntax and format but everyone thought it was harmless banter until they started yelling at each other in a meeting.
  • Jeff never complained about having to write test cases when the product, but now that the product has grown he can’t keep up, quality is dropping and everyone is blaming him.
  • The development team is working to be as agile as they can, but requirements are changing a few days before the sprint is over.
  • At the daily scrums, everyone shows up, but no one really discusses their issues.  It’s more motions than action.

Does any of this sound familiar?

Continue reading “The Leadership Wake”

Where CTO/F needs to be in Early Stage Development

In the early stages of a company’s growth, the Founder (assuming they are of a technical acumen) and/or if not CTO (Chief Technology Officer) needs to be focused on Product Delivery (we’ll call them the CTO/F for short).

To accomplish this goal, it’s important for the CTO/F to recognize and understand not only what they need to be doing at the product delivery stages but also all of the supporting aspects which will directly impact future growth.  What is important to understand is what work needs to be accomplished at each stage in delivery, how long your organization exists in that stage is up to you.

Continue reading “Where CTO/F needs to be in Early Stage Development”

Announcing our New Leadership Programs

We are pleased to announce the release of two new Leadership programs aimed at helping Software Developers become great leaders, mentors, and coaches for their teams and organizations.

Leadership Leapfrog Program

The Software Leadership LeapFrog program is designed for individuals on that are looking for a leadership program with principles geared specifically towards the software industry.

Features of this program include;
  • A sprint-based approach to leadership development focused on setting objectives and delivering them.
  • Establishing your Value Proposition and Leadership style
  • Identify strategies for Leading Up
  • Growing your Circle of Influence
  • Establishing yourself as a Leader
  • Establishing your brand of Software Leadership

Team Leadership KickStart Program

The Team Leadership KickStart program is designed to align your software team(s) value proposition with the organization’s goals as they scale through growth.

The solution to giving your team the KickStart they need to go from Good to Great doesn’t start with adding more people to the problem or implementing more process.
It starts by
  • Ensuring your teams are engaged and delivering
  • Developing a Motivating Team Culture.
  • Reduce Turnover by building leaders from within
  • Identify and implement a strategic direction for growth
  • Team Leadership training
  • Identify and overcome weaknesses within the team

As with all of our program offerings, you can schedule Introductory and initial consultative sessions (at no charge) to find out more about our program offerings and how we can help you and your team.

The Organizational Chart You Need

Companies invest an insurmountable time in their Organizational Charts.  They are a badge of honour showing who reports to who and how the order of things come to be.

As soon as we start our careers, the goal becomes a game of trying to get from the bottom to the top.

Or so we’re told.

But the org charts have it all wrong, everyone “above” you, all those “channels” of communication, are not what you need to progress, they are what others need you to follow so they can progress.

Not sure what I mean?

Grab your current org chart, take note of the names of the people, but forget their titles.

Now take this org chart below and write in the names of the people that correspond to that skill set.

TheRealOrgChart.PNG

Now compare.

They’re different, aren’t they?

The people that are doing all the Informal Leading, Early Morning Problem Grinding, Creating and Doing all that needs to be done don’t line up with what’s being present to you.  Your current Manager might not be someone who is a great Leader and the person that handles all the support calls is the one who really has their finger on the pulse of what customers need today and in the future while you the developer, you’re constantly trying out new APIs and SDKs to make the product better – because that’s what you do – you’re a Maker.

All of this is okay.  Organizational charts aren’t built around the skills and potential, they are built around titles (solely built on titles).  But now you know who these people are and now the onus is on you to seek them out, establish a relationship with them, learn from them because these are the people that are going to help you grow, help you develop and help you become the person your team needs you to be.

 

 

 

Big. Bad. Meetings.

Meetings get a bad rap for the singular reason that we don’t always get what we want out of them.

That’s a big reason and a strong justification for what is wrong with them.

I’ve attended meetings in person, via bridge, conference calls, airports, taxis, backywards, McDonalds, restaurants, and on and on (as I’m sure many of you have).

And in attending (and holding) so many meetings I started to realize that it really comes to one person that defines the success or failure of that meeting – You.

Yes, you, more so as a presenter but still as an attendee.

I’m a strong believer that the success of meetings are not influenced by their duration, recurrence, whether they arestand-ups, technology involved or people that are on the call.

The ones that were successful were driven by a need to accomplish something.

Take a moment and think back to when you were a smaller team and your meetings were the most efficient thing since sliced bread.  But over time the denigrated into something less than amazing.

This isn’t because the team grew or you now have more toys to play with.

But it is because you went into Meeting Autopilot whilst trying to be Productive.

There’s a way out of this purgatory, it’s here, it’s 60 slides, I swear though if you take your time you can be done in 5 – 10 minutes.

Five to Ten minutes to get 10 – 15 hours back a week.

Seems like a fair trade to me.

Here it is – Big. Bad. Meetings. – share your thoughts.

Automating Team Growth and Development

If you’re leading a team, the growth and development of each member of your team are going to be at the top of that big TODO list you have that lists out everything you want to accomplish with your team.

But this doesn’t mean you need to run with all of it.

Although it might sound weird to “Automate” your team’s growth, really what you are trying to accomplish is have a system in place that enables constant growth and development that does not require your constant intervention (but still yield the results you’d like to see).

To this end, there are a few strategies that you can employ that can help you achieve your goals.

Empowering Team Members

As the Team Lead or Manager, you make a ton of decisions every day, but you don’t need to.  If you were to take a look back at the decisions you had to make in a day, how many did you really need to be a part of and how many could you have skipped out on.  An easy way to embolden your team to handle the little things on their own is to ask what they would and have them go along with that (as long as it’s not burning down the office).  Whether it works or doesn’t work, you gave them the opportunity to make a decision and grow.  Now that they know you support them this will only spur them to take more ownership in what they do.

Encourage the Team to Resolve Issues

There are always the little issues between teams and team members that crop up.  Whether they are architectural or personal, the goal is for the team to work through the issues, come to you with a resolution that you can sign off on and move forward with.  They might get the resolution wrong the first few times but that is why you are there as the final decision maker on how they should proceed but allowing them to define the process and outcome as they work through it.

Team Activities

I eschew the word events in this context because everyone thinks an Event is a big thing that requires massive organization.  Activities are different, they are the team lunches, the going out for a drink after work, the playing ping pong for a quick 15 minutes, etc.  These are the events that strengthen a team’s bond when working together.  Take a second and think of any of your favourite sports team.  These teams spend an inordinate amount of time together between games and practices so they get to better know each other’s quirks and strengths – there is value to that knowledge when it comes to growth and development which is why activities are so important.

But you don’t need to organize them all and having everyone shoulder this load (and know that everyone owns a bit of it), is a great way to ensure that these activities keep happening when you get busy or someone else gets busy and doesn’t rest with one person.

Again, I used the word “Automation”, another word might be auto-pilot, but these words only apply to the Leader and not the rest of the team.  By encouraging your team to share in this workload to keep your team developing and growing you are emboldening each person with skills in Leadership, Ownership, Accountability, Responsibility where each one of they shares in the collective growth of the team, contributing in their own way to ensure that regardless of someone’s schedule, the team is always developing.

From the outside, others might see it as you offloading these tasks onto your team, but what you are really doing is training them to run their own teams so they are ready for it when the time comes.

The Proximity to Success Fallacy

Does the proximity of your team members to one another (i.e., how close they are, if they are remote) determine the success of your project?

No.

Does our success change if we sit close to each other?

No.

Does it have any impact on it?

Only in our heads.

If you were to go back as little as 5 – 7 years ago, many of us were working on projects with a team that we sat right beside.  It was akin to a college atmosphere where everything you needed was in elbow reach of your own desk and if you really wanted to get everyone’s attention, you’d raise your voice.  If you wanted to call a meeting, stand up and tell everyone to come over.

But things have changed, now teams are distributed, many of us work remotely from a variety of locations wearing the “I work in a coffee shop” badge with high esteem while others prefer the sanctity of their home and others still prefer the hustle, bustle and social interactions that come from working in an office.

Interacting with teams over IM, SLACK and ZOOM calls are no longer the minority of your interactions with people, they are the majority as we seek to find the best people to work with to deliver our projects.

With all that to say, the only barrier to working remotely with teams (and how they contribute to the successful completion of our project) resides in our heads and our ability to change.

And nothing more.

We all have the same tools, we all speak the same languages, we are all committed to the same outcome and we all want to be successful in our careers.

If you are currently working a team to break through the Proximity Fallacy to Success, there are few techniques that you can employ with your team to break down these internal barriers.

  1. Have them outline why they don’t think the project will be successful?  It could be there is another issue underlying the need for proximity that is being overlooked that needs to be addressed.
  2. Ask them what the difference would be if the exact same project team was beside them right now?  In some cases, the issue might not be the distributed environment but a specific team member that they are worried about.
  3. Ask them what they would change and why?  The onus is now on them.  If they had all the time and resources what would they do and why?

In all of these questions, but especially #3, I have to emphasize the Why because this forces your team to justify the reasons for making a change to how you operate and deliver projects.  Not only will this help you understand what they are experiencing but also allow them to speak the problem out loud so both of you can work through it.

Even though Proximity to Success is a fallacy, it is right now a concern to a member of your team that is sitting in front of you.  Your role is to recognize and work with them through this, helping them get past these barriers so they are able to continue delivering their projects successfully in the future.

And this is where you shine, in breaking down these fallacies.

Identifying and Overcoming Stagnation in your Team’s Growth

“We used to deliver more when we were smaller”

No matter who you are or where you are in the team, this hurts. It hits you hard in the gut and triggers the introspection that forces you to look at the why in how you got to where you are today.

In working with software teams over the years I’ve generally found it boils down to a few inconsistent “growth strategies” that inevitably serve to stagnate growth rather than encourage when applied incorrectly.

Continue reading “Identifying and Overcoming Stagnation in your Team’s Growth”

Overcoming the Hiring Problem

Great People = Great Products.

And right now, you have that incredible product offering put together by an amazingly talented group of people from here, there and everywhere. The team is executing and delivering on all facets in building the next iteration or branching out into something different.

And now your customer base is growing and that age old problem is starting to creep to the forefront as the team struggles to keep pace.

Continue reading “Overcoming the Hiring Problem”

Making Remote Meetings Work

When you have a dispersed team separated by geographic boundaries and time zones it can get a little complicated to ensure that the right messages are being received at the right time by everyone on the team. This problem is further compounded if you are a fast growing team and don’t have the necessary time to get to know and understand everyone’s idiosyncrasies, instead needing to put more emphasis on product delivery before team understanding.

Continue reading “Making Remote Meetings Work”