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.
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.
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.
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.
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.
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.
You might not be able to pick them out, but we can, some are more obvious than others.
But all of them stick out like a thorn in my side that I can’t get past even though our new site is vastly better than our previous one.
For the last few months, I hummed and hawed over whether to take down the Under Construction sign and release or keep it up while trying to resolve these last few issues.
If I adjusted the time that we were delivering on, I knew it would push back the release even further as the list would never end.
We shipped last week, it’s not perfect, there are some kinks to work out (some fixed this week), but we’re happy with the result and the lessons it taught us.
We’ve re-structured our site to focus on our main core competencies – Development, Leading and Learning.
At our core, we deliver simple, scalable solutions. We work with a variety of Government Departments and Private Organizations to deliver solutions on the Office365, Dynamics 365 and Azure stacks focusing on Data Driven and Contact Centre oriented solutions.
If you aren’t sure where to start with your next project or have some questions, drop us a line.
We’re pleased to offer the general availability of our new Dynamics 365 Training programs. These programs are born from the custom training modules we have done for customers over the past few years and the questions we get asked most often.
All attendees will receive access to their own tenant for the week prior, during and two weeks after our course to they can complete any Labs and/or revisit material. In addition, we want to hear from you before your session starts to ensure you’re in the right program and the content we deliver will help you reach your goals.
Our training programs and content delivery have not gone anywhere and instead are now being offered as customized offerings. Whether you’re a Developer, Team Lead or Manager or Team – we can all use a kickstart to get going and become a more effective leader.
Our programs are a combination of mentoring and coaching designed to give you the jump you need to be a success.
We’re still tweaking things, but we’re looking forward to what we can deliver with you in 2019. If you’re interested in learning more, give us a call or email us.
Your first Team Meeting is your most important meeting you will ever hold.
It’s the meeting that will set the direction of your team for the coming days, weeks and months as you embark on your path as a new leader.
It’s not an easy meeting.
It’s not a “what’s everyone working on” meeting.
You probably have a number of items that you want to go over at your first team meeting.
Introduce you are
Walk through how you got here and what your accomplishments are
What are your expectations for the team
What goals do you want the team to accomplish
At the end of this you might then ask everyone for their viewpoints and suggestions on source control, coding standards or diagramming controls.
And just like that, you’ve lead your first team meeting in the worst way possible.
What did your Team Contribute to the Meeting?
We’ll get back to your part in a second, but what did your team contribute to this meeting? Answers to the least important questions that will not affect their development and growth but rather their tactical implementation on your team.
Who cares if they use GIT or TFS or whether they used tabs vs 2 spaces or where they put their brackets.
When it comes to overall team development, no one cares.
And these questions, these “worthy” questions, after you spent probably 15 – 20 minutes talking about what you have achieved, what you want your team to accomplish and what you expect from them?
The ideas are there, but it’s the execution that’s off.
By tweaking your message you show a different strategy, not necessarily in what you say (don’t worry, you’ll make mistakes) but in the order you place on discussing these items.
The Structure of your First Team Meeting
Who are you – Because everyone needs to know who you are before they here what’s next (I’ve forgotten to do this many times), but go light on your accomplishments. If they want to learn more, they can read up on you on LinkedIn.
What do people think we do – Lay it out for them, this is what everyone thinks we’re responsible for – this is a statement
Do we really do that? – This is the first ask, is that how we really ourselves? Is this what we really work on? Don’t talk, get their feedback on everything else that we do.
Where Can I help? – If there is a misalignment, how can you help fix that perception. If it sounds like they are overloaded, ask them how you can help, it could be simple (better test cases, clearer requirements, a water cooler, source control is garbage, etc). Put the onus on you, what can YOU do to help them.
At the end of the first meeting, the only action items coming out of it should be from you and for you. Your role is to help make their life easier. If you have questions for them, follow-up with them later in the week in a one-on-one basis, for those that are hesitant to speak up, this may be a preferred option.
If you were to compare those messages, which meeting would you rather be a part of?
Everyone wants to be in the second meeting because it is baked with adoption, ownership and leadership. The first meeting announces that you are the Manager, the second meeting sets the tones that you are the Leader (without dictating it) and you’re here to help wherever you can.
Once you get a handle on some of the quick fixes, next you can start talking to your team about expectations and goals for that quarter, year, etc. Take the same approach as we did with the second meeting so that the message your team is hearing is – jump in, help me lead this team, I need your ideas, lets own this together – that’s a message that no one wants to ignore.
When was the last time you asked your Team Lead, Manager, Director what the purpose of your team is?
What your end goal is?
What’s your raison d’etre?
It’s a hard question to ask (because it assumes someone doesn’t know) but it should be a simple question to answer.
“We are building X for our customers”
“We deliver X for the company”
“We are focused on”
“Our goal is to help our organization identify our next priorities…”
Any of the above answers are a great start because they establish the one thing that every team needs to survive.
Without a Direction, how do you know where you are going, why you are going there, and what you are going to do when you get there?
How often have you’ve been part of a team that was building a product that they didn’t know if the customer wanted?
Or didn’t know when they were delivering it?
Or didn’t know who was going to use it when it goes live?
A team without purpose is a team that will never deliver.
If you’re the Developer on a team where no purpose exists here are some things you can do to help figure it out;
Look at what you are doing, write it down – gather the data, draw the lines
Look outside your work, what are other people on your team doing?
What are your customers asking for? Does it jive with what you are working on?
From there, you can be the one to start the conversation with your Manager. Maybe they’ve been around for “so long” that they’ve always assumed what they are doing is their purpose, maybe they need a kick from you to really uncover what it is, or what they should be doing.
If you’re the Manager that is recognizing that your team’s purpose is lacking.
Look at all that you are delivering on your team.
Is this what you think they should be doing?
Is this what you want them to be doing?
It’s up to you now, establish their purpose, set their goals, get the team involved, have them own a part of it.
You can drive each approach, no one is saying no to you.
Many times, your team will not have a purpose, it will be an assumed function, a function that could be completely wrong and inherited from years of “okay, sounds good, we’re on it”.
You’re not there to keep the cycle running, you’re there to break it and implement the change necessary to turn your team around.
In both cases, whether you’re the developer or the manager, you don’t need to ask to find you’re purpose, but you do need to want to know the answer.
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.