Development Team Leadership : First Steps Part 6

Pragmatism – Take your time

I’m sure you’ll have heard the saying :

Rome wasn’t built in a day…

…and it’s fair to say that 99% of the time, neither will your app be. Be realistic regarding what you can achieve and by when. Everything about the Agile methodology points to being able to work sustainably, and getting better at doing so along the way. There’s many articles about picking a vertical stripe or horizontal stripes through your architecture and delivering a concise set of functionality. My advice would be, don’t let your chosen stripe get too fat. If you can’t hit an imposed deadline, be honest and say ‘no’.

If you take on too much, you’ll spread yourself and your team too thin, the quality of the app will suffer, maintainability and unit testing will get skimmed and the technical debt will grow and continue to be shelved for a rainy day, which we all know will most likely never come (metaphorically of course, I’m English). There’s a fine line, as always while dealing with customer demands, but be pragmatic; tell it how it is, outline the risks in forging ahead, and if you need to, ‘raise the alarm’.

Performance Development

Take performance development seriously throughout the year and your annual review will become a lot less painful.

Keep a log of anything notable you have done or achieved. Keep any notable praise received from clients, or peers, etc. ready to present and the case for a pay rise or a promotion instantly becomes a lot stronger.

Look at this from both sides:

as a manager you want your staff to succeed, the easier it is for them to provide evidence and key points, the more likely it is that their career will progress, and the process will be a lot slicker;

as a ‘managee’ you want to be able to provide everything that happened, it’s very easy for a lot of the good work you have done in a year to be forgotten about, particularly with the short lived iterative nature of Agile and ‘living in the now’ mentality.

Keep track of everything; I use a folder with scrap paper in, a page for each target noting anything I’ve done towards it and a set of pages for anything else worth mentioning. It doesn’t have to be a technical solution, don’t go wild, it just needs to serve it’s purpose.

Tooling

The day Visual Studio 2015 came out I was asked the question “can we upgrade to 2015?”. My response was “Yes, when Stack Overflow isn’t dominated by people asking why their project won’t open”. Perhaps exaggerating slightly there, (I use it, it’s really good), but you get the picture.

Everyone wants to use the latest and greatest, but at certain points in a delivery it won’t be practical to either manage the transition, or deal with the mop up of any potential fallout or change required. This fits for IDE’s, libraries, whatever the latest JavaScript framework happens to be, and so on.

For example, with the initial release of Visual Studio 2012 support for MSI’s was dropped meaning certain elements of the app I was working on at the time had a dependency on Visual Studio 2010, we couldn’t wholesale make the leap, meaning additional thought and effort was required to push things forward. Slightly outdated now, but the sentiment remains.

Be responsible, you’ll be the one answering the questions when a deadline isn’t met because you needed tostart using Angular 2.0.

Don’t be afraid to be the bad guy…

…as for most things, there’s a right time, you absolutely should be looking ahead, but as above, be pragmatic and take your time.

What do you think?

Does the above ring true for you? Let me know what you think or share some leadership tips of your own in the comments section.