Choosing between the Rewrite or Fix It

It’s easier to rewrite something than to figure out what is going wrong.

It’s easier to start from scratch, ignore the history and do it your way.

It’s easier to ignore, then engage.

The decision to rewrite versus fixing a code problem is always rooted in emotion and not the code.

We Can Do It Better

If it’s someone new to the team, their first instinct when this discussion is being raised is to lean towards rewriting it.

Why?

Because they don’t need to learn the old code, they don’t need to figure out what is breaking and where and most importantly they don’t need to understand what decisions were taken and why.

In short, hubris has reared it’s ugly head, they’ve scoffed and they know – “I Can do it Better”.

However, in most cases they can’t, they think they can, but once they get into the weeds of it all, they’ll start to hit the same roadblocks that you’ve encountered in building it up.

We Can Do It Better is a path based on pride and over-confidence.

The Technology Factor

Software platforms and frameworks are being updated an increasingly exponential rate. Every day code is changing. What you write today, could be written better 4 – 6 months from now.

Will you be rewriting your code base every 4 – 6 months to take advantage of these new features?

Doubtful.

If the reason for your rewrite is to “be on the latest framework” or “take advantage of new patterns” that do not result in significant performance improvements with maintenance time staying the same or (hopefully) decreasing, then there is no value on being on the latest and greatest software.

Creating a Make Work Project

Everyone hits a slow period in their daily grind. Some go on longer than others, but it’s there. And when it happens, the first project to come up is code that “needs” to be rewritten and made better.

If this discussion is coming out of left field with no pre-dating factors associated to it, then you are now part of a “Make Work” project and you do not want to be part of a “Make Work” projects. As the name implies, someone has decided that this is a good idea (but it’s not) and as such they are trying to make work happen in order to look busy.

Make work projects never work, they are never completed, they are never good enough and if you suspect one is happening, you should dump it and focus on finding a Do Work project. Do Work Projects matter, they are needed and are value driven.

There are valid examples of when a code base needs to be written, but this number is much smaller than you think (and the success rate even smaller). If you’re being faced with a decision to rewrite versus fix, take a hard look at the decisions and reasons being used to justify the rewrite – are they emotion based or are they based on delivery and technology patterns.

Moving to the Cloud? That’s a solid reason for a rewrite.

Platform being discontinued? It’s a no-brainer, rewrite it.

Trying to fix a few bugs that are “tricky”?

Take a second look, fixing those 5 bugs will have a much greater ROI (Return on Investment) than rewriting your app.

And if you’re looking for the leadership take on this, apply the above logic to your team – is it better to blow up the team and start from scratch or fix the problem and move on?

Lead them in the Middle

Your First Team Meeting is critical to getting things underway with either a new team or project.

How you start will set the tone for how the project will kick-off and where your team will look to focus their energies.

In the beginning, like the song, “Everything Is Awesome” in the beginning, simple because it’s all new, emotions are at a newfound level of excitement, goals have been set.

You’ve set the groundwork, the plan, the direction, the path to go down, but apart from that – but you haven’t started yet.

Nothing has been done, so everyone is happy with the dream.

Fast Forward to the end of the project, the team has come together, they’ve gone through the final pushes of people coming in early, working late, sweating more then they usually do, doing whatever they can to get this project/product out the door and make it a success.

The team has done in so again, emotions are all happy because the release has gone out the door.

If you haven’t realized it – this is where you many of the great team quotes originate from – how the team came together to become a success, how they fought through adversity and change to deliver, how they never gave up.

There is enough literature on how to start and finish any project to keep you reading well into the afterlife.

But what about the middle?

What’s happening in the middle?

What’s going on when all that code churn is happening?

When the team is having to up their growth quotient by learning on the fly and still delivering?

When frustrations over not hitting performance targets are starting to set in?

When the team is feeling worn out and knowing that they have much more work to put in?

This is where Leadership matters, this is where Good Leadership matters – Leading in the Middle.

  • Leading when things aren’t perfect.
  • Leading when everyone is complaining.
  • Motivating those around you to keep going.
  • Keeping your head when things don’t go right.
  • Knowing when your team needs a break or they will be broken.
  • Understanding what minor things manner in the grand scheme of the whole project.
  • Giving your team leeway to try new ideas and let them fail.
  • Insulate that failure and not blaming it on them.

If you can do all those things, then you are already on the right path to Leading your Team in the Middle.

The most successful teams are those that were able lead well in the middle when things became murky or the team started to struggle because that’s what every team goes through.

The middle is never perfect, it’s never clear, it’s never straight forward, how you lead in the middle does not define how you will finish, but rather who wants to start with you again on the next project.

Will they come back for more?

In the calm moment of reflection that happens after the delivery of any project, will they go back there with you?

When lead correctly, in the middle, the team is ready to jump onto the next challenge, they are sold before the project is even announced, it’s not a question of If the project will start but When.

If you start off with the right objectives, lead well in the middle, the end will take care of itself.  If you start off strong, mess up in the middle, the end will eventually take care of itself, but not as well as it could have and you probably won’t get another opportunity to start again.

 

 

The Leadership Change Goal

If you think you can change your team’s behavior, direction, and course in thirty days and have them executing on that change – you need to reset your goals.

Leadership is a long game, the more members on your team, the harder it becomes to implement the change you know that the team needs but that the team cannot reliably implement because there are more variables in the mix.

Coming in with a list of demands for behavior and direction change will only serve to confuse your team.

You need to start small and focus on incremental growth and adjustment.  If the team is not delivering, your efforts should be focused on the behaviors and attitudes that shape that delivery.

Are there internal or external threats that are preventing them from being successful?

If so, what small investments can you make that can yield larger gains in the next thirty days to precipitate those bigger changes?

If your Goal is for the Team to “Deliver Better” the first step is to work with the team to identify what delivering betters means to them and everyone on the team.

At that initial discussion, there should be zero discussion on the solution to that goal.

Why?

Because this is the first time you are discussing it with your team.  The first opportunity they have to respond, to come up with a suggestion or ideas on how that problem can be solved.

You need to hear what they have to say because this will affect the solution that together you will implement.

In holding that first meeting, you will have accomplished the goal towards getting your team to understand the problem and begin the task of owning it.

If done right, over the coming week while you are working with your team on potential solutions, team members should be coming to you with additional questions on the final goal – i.e., can we do this as well?

You want this, you want their involvement, you want their ownership.

While fielding these questions, this is an excellent opportunity to bounce ideas off of your team members on how to solve your team’s problem and what steps you can take to get there.

When you circle back with your team the goal of that second session should not be about timelines it should be about the steps needed to be taken to achieve the goal.  This is key to the success of your plan as not everyone will understand the steps that go into achieving a goal and the timelines will be dictated by that understanding.

Once enunciated to your team, the path that you and your team are going to take will then be clear, who will be responsible for what and how the final goal will be achieved – the conversation can now switch to how you and your team will achieve this goal and on a what schedule.

We are constantly bombarded with news and information that teams need to keep changing now and to meet that demand as quickly as possible.

Even during the development of a short-term project, say four to seven months, the pressure is just as great to “produce results” and “show change”.

History has always proven that the team that manages by Ownership and Adoption and treat Change as a marathon are more likely to succeed in that endeavour.

Don’t be the Leader that “hopes” the change gets implemented, be the Leader that knows when it will be implemented.

Hiring the Right Person for the Wrong Job

Hiring people is the hardest part of any organization’s growth. You have this perfect symbiosis of people working together in your environment, your customers and market share are growing and now you need to add to it.

You need to add to it for all the right reasons – they are overworked, you need more specialized skills and you’re starting to think about what happens if someone gets hit by a bus on the way to work.

You needed to grow the team and you needed to do it yesterday.

But you can’t because you’re worried you might hire the wrong person that doesn’t fit into your culture, that doesn’t jive with everyone else, that breaks the symbiosis that you have going on now.

That culture that you are so fond of, is going to change no matter who you hire, that culture you have is what got you to where you are but now, just like your team and your organization, it needs to evolve, it will evolve, it will grow.

Fixing a bad culture fit is an easy fix – let them go, fire them, drop them. You can feel out a bad fit after a few months, take correction action and move on and if anything this will strengthen the culuture you have in place.

The harder problem to solve is when you’ve hired someone that fits in great with the team, has great skills where they contributiong but when you take a step back to look at what your organization needs to level up, it’s not them.

Maybe you didn’t realize it until they started (and the real issue was exposed)?

Maybe you had an inkling of what you needed but wanted to hire with what you knew and that was easier.

Maybe you hoped this hire would be a Jack of All Trades and lessen some of the impact on the team in that area.

Whatever the reason – you have a great new resources not doing the job you need to have done to ensure your organization’s future growth.

You hired a Developer, you really need a Product Manager.

You hired a QA Lead, you really needed someone someone onsite with customer running through Beta trials.

What do you do?

Do you shoehorn them into something they don’t want to do and see where it goes?

Are you upfront with them about the mistake that was made and see if they want to make a career switch of move on?

Do nothing and hope it all works out and that piece that you really need gets done at some point in time?

I’m sure there are other solutions that you can think of but all these solutions revolve around that new team member when you need to be thinking about your organization and the current team you have in place. Your current team is looking to you to make the tough calls on how to direct the company and keep people from burning out, your team is looking for you to be focused on where they should be in the next six to twelve months and line them up for success and your team needs you to know when to change course with what’s best for them.

When you’ve hired the wrong person for the job, the problem will not fix itself unless that new team member is looking for a complete 180 career switch but even then they’ll be starting at ground zero with none of the experience and knowledge that goes along with it – translation – you still lose.

Hiring the right person for the wrong job is only acceptable when you’ve got the funds for it, when you’re cycling towards mass growth, you don’t have the time or the funds for it so make sure you know what you need before you bring them on.

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.

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”

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”

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”

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.

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.