Software Built On Trust

To build great software you only need two things – trust and honesty. If you have that, you can build anything, absolutely anything.

It might sound cliched or overdone, but it’s the absolute truth. I have worked with the good and the bad of software teams and what sets both apart in both cases are these two things – trust and honesty – in all facets of delivery.

Trust within the Team

As Software Managers, we all know when we’ve shipped a good release, one we are proud of, one that checked all the boxes not just for the customer but one that saw our team come together and grow. That’s the real delivery to any Software Manager – how did the team do, how did they grow, and are they ready for what is next.

The ability for a team to come together and align themselves to working together to achieve a common goal is the greatest success factor in any release. And all of this starts with every member of the team having trust and faith in each other. This, of course, is not to be confused with delegation, delegation is the assignment of tasks, trust is the better half of delegation which removes the need for it.

There is always going to be a mad sprint to get the finish line, it’s a relay race, one person can’t do it all. If one person can’t get the baton to the other and trust and believe that the next person is going to run just as hard as they just did, you will fail, always.

Here are some examples of teams that are implementing Software Built on Trust;

  • The team doesn’t need to be asked to look at bugs, they are already doing it.
  • Team members who finish their work early, jump on the bug pile and start taking from those that are overloaded.
  • Everyone understands the problem we are trying to solve and the value to the customer that is behind it, these become our guiding principles.
  • The team is not hidden from the customer, but is encouraged to go and meet with them, as much as they want – feel their pain, experience their joy.
  • Honesty is paramount – did we screw up? Yes, great, let’s admit it and move on.
  • We don’t muddy the waters – a feature is a feature, a story is a story, everyone follows the same sprint – if multiple teams are involved, they are all on the same path.
  • When the product manager asks how it’s going we don’t say “fine” – we give them the lowdown, the good, the bad, the ugly.
  • Extra time will invariably be needed, somehow, somewhere – whether it’s pushing out the release or working early/later – the key is we make this decision as a team.
  • We plan to set the team up for success. If it’s a highly research-focused project, we give them the time to make mistakes, to fail, to learn, and to grow – because next time they will come back even better. 

Some of this might seem obvious, others are easier to write, harder to implement (i.e., who wants to tell Sales that we had to cut their favorite feature). But if we let Sales keep thinking there is hope for that feature to make it into the release, when there probably isn’t, we’re not giving them time to adapt, change and come back to us with suggestions for what we are able to do.

 Software Built on Trust starts with Development but it permeates it’s way through Product Management, Sales, Finance, everywhere the organization depends on that delivery.

Actions that Build Trust

When we think of this work, we think it’s complex, we can’t do it, it requires too much change, but it comes down to making and introducing a few simple changes into your organization and making them the key to your continued delivery and growth.

Honesty – we always need to be honest with each other and everyone we interact with

Ownership – we own it, no one else, so let’s act like we own it and treat it like your favorite thing

Accountability – this isn’t about making estimates that are off and working insanely to make them come to bear. This is about being upfront at discussions on progress and giving the bad news along with the good

Leadership – everyone leads, not the manager, not the senior developer, everyone, everyone plays this role – everyone can make a decision in the best interests of the project

Retrospection – a constant effort to always be questioning, what you are doing, what we are delivering, is it the best thing, do we need to pivot, what comes next. This isn’t about sprint retrospects, this is the daily, weekly questions that you are constantly asking yourself and others.

When you have those five traits at play in your delivery of software, where everyone comes back to them at the end of each release, build, trial, discussion, design session, and meeting, you’ve created a foundation of trust amongst you and your team. It doesn’t matter how larger or how small the team is if everyone is on board if everyone puts those traits into practice if everyone is consistently living and breathing these traits when talking with customers or any other group.

Trust within the Leadership

I left this to the end, because it’s the most important, presumably your team has a manager or a leader that has been entrusted with guiding your team. You report to them, look to them for coaching, support and guidance. They are there for you if you have a problem. If you need to discuss issues of a personal nature with them – they are there to help you.

But if you don’t trust them (and conversely if they don’t trust you), you will never achieve building Software on Trust, you will never get there. You will never achieve that goal and it will always remain elusive.

Software Built on Trust is not an element of cadence or principle that you turn on and enable. It is more than that, it is a path, a practice, a direction that you, the leader, must take and hold onto. It’s one that is defined by you the manager that permeats to the team, it’s the behaviour that you want to see happen that can only happen when you are willing to take the hard steps to show your team what it looks like.

Lead with Trust.

Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US). Follow us on Twitter @Codeyourwayup and find out more about our Software Leadership Programs here.

Understanding Software Developer Growth

That’s how it looks, a bunch of erratic lines, one overlapping the other where you are supposed to be doing each and every one all the time and excelling at each and every one all the time.

No matter your skill level or where you are at in your career – Junior, Intermediate, Senior, Team Lead, Tech Lead, Manager, Director, etc, etc (the list goes on) – what doesn’t change are the things you need to do in those roles as a leader in Software.

I want to emphasize leader because I honestly believe that every Developer is a leader in their own right. We assume that leadership is always about people, how many you manage when in fact it can be about code, frameworks, initiatives, customers, programs, research, etc, etc (again this list keeps going on).\

Why have we tried to pigeon hole all of these amazing great people into a corner for all of their careers I will never understand. Organizational policies that have it baked into their culture that the next progression in your career (and hence leadership opportunities) can only be attained by giving people a team are missing out on so many great opportunities that it is baffling to watch unfold.

What does Growth look like?

It looks like the above diagram. Ask anyone how they got to where they are and they will tell you all the paths they took, nothing was linear and very little worked out how they said it would. It was one big, off road adventure that relied on their previous skills to get them to the next stage.

Nowhere is this truer than with Software Developer – you can start with a book, a blog, school, a website, a computer and Nodepad and start learning and growing. And all the way you are leading, you, yourself, the Army of One, in how you are going to get there and what you are going to accomplish.

The beauty of the attached diagram, is that it is different for everyone involved, we all have different journies and we all go through different experiences where we code more, lead less, research more, design less. If you fundamentally boil everything you are doing down to a few simple characteristic traits – you are always going to be Driving, Delivering, Leading and taking the Initiative – always.

Look at those bugs on your plate – you’re delivering and if you’re taking someone else’s, you’re taking the inititiave.

Look at the junior developer struggling on your team – you’re leading them and helping them out.

Is no one building the UI standard that your team desparately needs – looks like someone driving the solution to the end.

What Matters to you?

Want to know where you need to go and where you should be focusing your energy? Take a look at those traits, what matters most to you? Where do you excel? What interests you? Where do you want to go? You probably already know and if you do, take a moment and draw those circles or lines a little bigger on the ones that speak to you. On the ones you want to do more with but aren’t great now, make the lines all jagged so you can visually see the work you have to do.

What you can’t do, is exclude them, you can’t have four perfect little circles all standing apart from one another because this is where you will fail. Everything, Drive, Delivery, Leadership and Inititiave – all overlap and they all contribute to your growth. You can’t have one without the other.

Don’t make the mistake of sacrificing one and only doing the other three – because that’s not growth (not good growth anyway).

Real growth, powerful growth, scary good growth, growth that will make you a great leader in Software Development comes when you embrace all four – no matter your path.

Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US). Follow us on Twitter @Codeyourwayup and find out more about our Software Leadership Programs here.

The Leadership Exit

Making the decision to leave is never easy.

It’s easily doubled when you’re the Leader of a team because not only are you now leaving an organization, you’re now leaving a group of people that you have invested an incredible amount of energy into their own personal and team growth and development that to leave feels like betrayal.

They bought into the story.

They listened to everything you had to say.

They jumped higher than you asked.

They believed.

And now you are leaving them. Or rather that’s what you’re made to feel like when you make this hard decision to do so.

“You’re abandoning us”

“You’re leaving us behind”

“Why aren’t you taking us with you”

“How could you?”

There are many emotions at play here when you decide to leave and most are coming at you.

Let’s dissect a few of the most prominent ones here.

You’re Not Leaving Your Team

It’s time for you to move on to new challenges and opportunities. Leading a team is like being a parent, there is a moment when you know it’s time to let your kids go, spread their wings and start leading themselves.

Every Leader knows when they’ve hit this point with a team – “I’ve done enough here and what comes next will only be incremental. You need more, you need a different approach, you need someone else.”. This isn’t an easy realization for a leader to come to, but it’s one that is realized from the view that they want their team to continue to grow, become stronger, better and share that wisdom with others.

When the Leader’s involvement is only going to result in incremental returns, it’s time for them to make the exit.

It’s Not a Betrayal

And if your team thinks it is, then you should have left much sooner. Your team is now dependent on you for more than you had originally hoped and they are fearful that without you, they will fall apart.

Fear is a powerful emotion and a Leader should never stay if the team is fearful they cannot survive without them (the Leader). If this is the case, then you haven’t done the proper work in preparing your exit strategy and ensuring they are setup for success for when you leave. A well organized team should be able to survive in the short-term without their Leader and keep things going through what has been taught to them.

Don’t fall into the trap of being made to feel you are disloyal or have betrayed your team, you are giving them the opportunity to grow and develop.

The Bought Into You

Great.

Fantastic.

Your team bought into your plan, they executed and delivered on what you asked them to do, what you inspired and motivated them to do, what they raised up their own games to do.

This isn’t a bait and switch or a pulling of the rug from underneath their feet, this is your team trusting you to lead them, you leading them and no matter where you are in the delivery of your plan, they are being successful and continue and will continue to be successful.

What everyone tends to forget when you are leading a team or a project is that this IS THE ONLY  team and/or project that you will EVER lead.

But it isn’t and will never be and for you to continue growing, you will need to work with different people, validate different approaches with a new group of people.

In the end, you might end up working with some or all of these people and that is the best experience because not only did they buy into you at this moment, but they are ready to do it again, this time without having to go through all the Interviewing and Identifying and get right to Delivering.

Don’t fall into the trap of changing your mind about leaving because your team doesn’t want you to leave.

Focus your energies on setting them up to take over from you with the remaining time that you are working them. Over that period of time, their emotions will subside and will turn to being happy, excited and proud of the tough decision you’ve made. You’ll inevitably have many one-on-one conversations that will turn out to be some of the most encouraging conversations you or they have had during your tenure, enjoy them and know that you’re making the right decision.

But don’t change your mind, over time you will resent the decision you made and depending on your team, their attitudes might change or shift as they realize you will always be there to catch them if anything goes wrong and they’ll slowly start to question what your level of commitment truly is when faced with tough decisions.

 

How do you Measure your Team?

When you think of the work your team does, what metrics are important to you?

  • How often they are in the office?
  • How many bugs originate from code they are writing?
  • What their overall contribution to releases are?
  • What their bug return rate from QA is?
  • How many unit tests they create with their code?
  • How many customer cases they close?

These are all quantitative metrics that are easy to measure.  We have systems that can help us do this and churn out a dashboard on who’s our best performer simply by refreshing the browser.

But are they good metrics?  Do they tell the story of how your team is doing?  Do they give you the “finger” on the pulse that you are yearning for?  Do they leave you to feel satisfied the growth and development of your team?

The failure in the above traditional metrics is that they rooted in counts with little context to show from them.  Translation – they are pretty to look at but little value should be associated with them.

The following are metrics that would stop and make you think how you collect data on them, what steps you need to undertake to ensure they are not subjective and give you the context to know how your team is doing when compared quarter over quarter, year over year.

The problem is, they require much more involvement, from you the leader to collect, summarize and deliver to properly understand.

  • The number of times people on your team stood up and volunteered to help out a customer or someone on their immediate or another team?
  • What training they took this year and what did they get out of it?  How much of this training were they empowered to put into practice?  Did any of this learning make it to the prototype stage?
  • How often do they challenge the status quo and look to try something else?
  • When did they last suggest a new library or framework to improve on the product?  If they haven’t, why not?
  • What goes on when you are not there?
  • How efficiently are they at working remotely vs having to be in the office?

The list can go on (I hope it can) yet the purpose is singular in nature.  These are difficult metrics to use to measure the output and growth of your team.  Most will be derived manually, some will involve talking directly with your team to get the answers out of them you need and conversely ask them the tough questions that you need answers to.

But measuring the growth and output of your team is not meant to be a checkbox or survey results session discussed in the boardroom, it’s meant to be much more.  The secret to every leader using these metrics is that your team is dying for you to start asking these questions so real growth can begin to take place.

Collaboration’s Biggest Challenge

A few years ago, SLACK was the messaging darling, enabling quick, simplified messaging with minimal setup and management for administrators.  In addition, it boasted a robust API/Integration framework which let it do what so many collaboration applications to date had struggled with – get inside everything you work with.

Or rather, you get inside SLACK with everything you work with.

Fast forward to today and there are not only a number of challengers to SLACK but also SLACK has been hit by a few complaints about being “too much”, “always on”, “never able to get away”, etc, etc, the list goes on.

This isn’t a SLACK problem though, this problem has been in existence since the first iteration of that green jellybean icon came to represent your availability – you are here, you are available, let’s get to work.  That little icon came to represent not only your availability to get work done but also an indicator of when you are available to get work done (read: how much work are you putting in, how later are you up).

Collaboration’s biggest challenge to autonomy and not micromanaging your team has always been that little green icon.

How do I know where they are if it’s not green?

They’ve been away for so long, they must be doing something else?

Why aren’t they answering when they are green?

It’s the perceived notification that someone is available and ready to do work for you – that’s how it is interpreted but what it was never meant to show.

Want to know how pervasive the colour schemes are in messaging tools?  Look no further than them all using similar schemes – green – available, yellow – maybe, red – busy – they flow between different systems so we don’t need to relearn anything.  And just like a traffic light, they mean exactly the same things to a user.

But the question for the traffic light – Would you leave it on green all day long? – probably not, because eventually, it’d burn out.

When email took on the collaboration challenge it did so without presence, asynchronous communication – “I’ll get back to you when I can because I could get busy” – which unfortunately turned into the simplest of messaging protocols that allowed and enabled people to SPAM us with updates on everything and anything.

As much as we want to make it, Collaboration’s biggest challenge will never be the technology, the protocols, the AI to reduce message flow, where it’s hosted, whose hosting it, etc, etc, etc.  It will be the trust we put in each other around presence and messaging to ensure that those boundaries are preserved and supported.

Think that’s an easy way out?  Then here’s a question for you – What is your company’s collaboration policy and does everyone know what it is and how it works?

Doubtful, if you do fantastic and if you do, that means this post wasn’t meant for you, it’s for the rest of us that are working against that little green jellybean trying to find the right way out.

 

Finding your Non-Leadership Style

Leadership Styles are a tricky conversation primarily because no one wants to be pigeonholed being “that” type of Leader (when no one cares for having “that” type of Leader in their organization).

But it gets worse, as you start to work with other leaders (maybe you have a group of Team Leads you are mentoring) they want to understand what style you teach and employ because this is more important than the results you create.

To be a Great Leader, you don’t need to have a Leadership style. 

If you want to be better then having a particular style, I would urge you instead to focus on having a Non-Leadership style which essentially says – who you aren’t.

Having a Non-Leadership Style is what keeps you open to changes in the industry and lets you build your toolbox with a variety of tools, adding new ones, replacing old ones.  It prevents the conversation from with team members from going down a path of – “oh okay, so today we’re doing this?”

When you have a Non-Leadership Style you KNOW who you DON’T want to be, what you DON’T want to do and what you DON’T want to teach others.

You won’t find Non-Leadership Styles in a powerpoint deck because there are too many and only you can be the judge for what works for you and what doesn’t from your experience at trying them.

Non-Leadership Styles are typically unstructured and not driven by processes or perfect diagrams.  Instead they are composed of guiding concepts and goals that hold the leader to their path and direction but let them choose the route to get there.

Non-Leadership Styles are not for everyone – there is no handbook (except the one written by the leader) that says – “when this, do that, then do this, followed by that” which can frustrate those that are looking for a step-by-step manual to leadership.  They are free-flowing, evolving and natural in their development, growth, and escalation as they are implemented, tweaked and twisted.  They are the leadership styles that we come to admire for these exact qualities of flexibility and growth.

The next time you get asked what’s your Leadership Style, flip the conversation and start by saying what your Leadership style isn’t.  In that instant, the conversation will change as people here what you will not do and when you start doing what you set out to do they will not be fearful for what comes but instead be relaxed in knowing what it will not be.

 

Bad Renovations in Software

Recently, while doing some work in my basement, I had to remove a vertical bulkhead.  Actually, I didn’t have to remove but wanted to see what was behind it after staring at it for so many years.

When I opened it up, it was empty, there was nothing of use behind it – no vents, no water lines, no electrical, nothing – just empty space.

Well, not just empty space, it was filled with scraps from when it was first built, leftover pieces of drywall, wood and whatever else could fill in that cavity.

It was Technical Debt in all its physical glory.

Code that we have pushed to the side because no one’s ever going to see it.

Code that’s so bad, we don’t even try to hide what it is, we just add it to the pile.

Code that serves no other purpose, except to make work for the next person that comes along.

How many times have you had to go into a project that was rife with bad code that was pure bad debt that now you had to fix?

Bad Debt, if you think back to the mortgage and housing crisis of 2008 and watch the movie “The Short” you know what Technical Debt truly is, bad code, hidden within even more bad code, hidden within even more bad code that somehow works so we call it great and leave it for later or until it blows up.

Good Leaders know when to take on Debt, they take on the good debt, debt that will help their company and team grow.  And they don’t leave it behind, in the next release, the next beta, three sprints down the line when everyone is happy with the results, they go back and do it right, make it better and fix it so the next person that comes along isn’t saddled with a gargantuan problem that blows their project out of the water.

The Good Leaders fix Technical Debt but working on it.  If it’s going to add two weeks to their delivery timeline, they figure out a way to do it and make it happen.  If the team is overloaded and can’t spare the week involved in testing thereafter, they find a way to coordinate with QA and get it done.

We only have Technical Debt because we let it get there, but we all know the answer to fixing it.

You don’t have to be the one to put your hand up and announce you’re going to tackle it and get it done, you need to be the one to start doing it.

Conference Season is Upon Us

We’re in the thick of it now – Conference aka “Drinking from the Firehose” Season is upon us.

From now until October, the conversation around the water cooler and SLACK channel’s are going to be focused on one thing.

What conference are you going to this year?

And if you didn’t get your first pick or your choice was assigned to you – the follow-up questions might include…

Where is it?

Is there anything to do there?

Who are you going with?

I don’t have anything against Conferences, as a means to disseminate large amounts of information to a group of individuals they are great.  They are the firehoses of communication to get an idea out to as many people as possible and try to do it in an intimate way as possible.

They are meant to get you excited about doing work when you leave the conference, when you come back to the office with this new found information and want to try something new, change the world, put a dent it, etc, etc.

But.

How many times have you done that?

How many times have you watched all the sessions you missed?

How many times have you implemented what you saw in a conference into a shipping product for release in the next few months?

With the above questions in mind, if Conferences are your primary source of training and you’re not implementing what you have learned into your work in the next 2 – 3 weeks from when you’ve returned from the conference then what value has it brought to your growth.

(I emphasize growth and learning here because I know conference trips serve other values such as team bonding and enjoyment).

If you were to take the funds to be used on you attending that conference what would you do differently to ensure you apply them to your growth path?

Buy twenty Udemy courses?

Register for a year-long Plural Sight subscription.

Sign up for a developer cloud account with all the cool features on it (not only the three ones).

Integrate that decaying “customer required” app into your main code base and get a feel for what it truly does?

The options are endless, I’m sure with half the funds available to you, you invariably take a different approach to your learning.

Conferences are about mass consumption where the other niche training options above are about learning.

Am I looking for Training or Mass Consumption?

What you hope to get out of each is vastly different and applying one goal (I want to learn) to the wrong implementation (firehose) will leave you feeling discouraged in the end.

Know what you want, ignore the hype and figure out the path you need to take to get there and make it happen.

But know that you have the power to make the right choice for your growth.

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.