Categories
Leadership

Work the Problem

Technologists love solving problems, it’s one of the defining characteristics that pulls people into the world of high-tech. When this desire is put towards the right ends, then it’s a powerful force for good. There are some tools and techniques that can keep you on this path, and a few traps to watch out for.

First up, be clear what the true problem is you are trying to solve. Understand what the issue is, consider who is impacted now and what will change once it’s solved. Look at the value in the solution, the costs involved in solving it and the opportunity cost of targeting this vs something else.

Taking time to build this understanding gives a proper frame to the problem. It’ll prevent a couple of the traditional mistakes we can make, things like automating the existing bad process, or only providing benefit to the noisy stakeholders who are demanding a solution right now.

Now, step away from pure technical solutions. If you stay fully in the world of software and hardware, you’ll find you default to solving all problems by just writing code. The longer you do this, the easier it is to drift away from your customers, until all you care about is the minor version of the tech stack and wringing out another micro performance update. You’ll probably place too much weight on getting rid of old software just because it’s built in a slightly outdated way, rather than moving on because it’s no longer serving a purpose.

So, look over the problem again. If you aren’t selling enough of a widget, then don’t immediately jump on updating a feature. Maybe you are not marketing it to the right people, or your copy is out of date. Is it a complex product that has a sales funnel? Can you optimise that? Are people using it correctly or is it too complex? Maybe the right solution is taking away features rather than adding more?

When you look up beyond the purely technical, you increase the overall impact you are able to have. Work with the cross-functional experts in all the disciplines relevant to the problem and you’ll always come up with a better solution. You can be confident that when you break out the development environment and start cutting code that you’ve worked the problem and that a technical solution is the right one.

Categories
AWS Cloud Computing System Design

Architecture Qualifications

I was recently asked about Software Architecture qualifications by a reader to the blog, and I’m keen to share my advice a bit more widely.

They are an experienced developer, looking to take a step away from being an individual contributor, to become a design and system implementation influencer. They wanted to know my thoughts about TOGAF, and how useful the qualification had been in my own progression.

My advice assumes that you’ve already decided that a certification or formal course of study is the right way for you to go on your next learning step. If you are a proponent of the 70/20/10 model, then this is very much covering what you should do with your 10% time. So, without further ado, let’s get into the nitty-gritty of the possible options.

TOGAF was an interesting course of study, but I really feel it’s got a very narrow range of applications. I believe it’s only relevant for a very small number of extremely large organisations. It’s main focus was around the creation and maintenance of a large architecture practice in an enterprise, which is well away from the day to day of designing and developing systems.

If you are looking at a progression path from individual contributor to technical leader, then I’d strongly advise your favourite flavour of cloud certifications. I use AWS at the moment, and there’s a Solutions Architect track that’s really good. There are similar Microsoft paths for Azure, or Google ones for their cloud.

ITIL is possibly a useful direction, but that does tend more to hardware and processes, so might be less useful if you are aiming to design and create new systems, as opposed to running existing systems stably and efficiently.

If you are thinking modern companies, strong agile approaches and staying close to the day-to-day implementation of your designs, then the Cloud route is my number 1 suggestion, and there’s a lot of great supporting courses out there to aid your studies!

Categories
AWS Cloud Computing

AWS Cloud Practitioner

In a brief break from focusing on Leadership books, I’ve been brushing up my technical skills and reviewing some training material from AWS.

Amazon’s cloud offerings are many and varied, and they can be daunting for anyone unfamiliar with the basic concepts. The AWS Cloud Practitioner certification provides a grounding in these core concepts, and is suitable for anyone who has to interact with AWS in a professional capacity.

The AWS provided training consists of around 7 hours of content, covering the basic principles of the cloud, outlining some core AWS services and then covers security, design and pricing. It’s broken down into short videos with knowledge checks following each section. It’s easy to consume and easy to understand.

The certification is a single multiple choice exam, consisting of 60 questions with 90 minutes to complete. I also took the practice exam, which was 25 questions long, but I’d advise doing this a few days before your scheduled exam as the the results are not always ready immediately.

Once you’ve passed the exam, you get access to a digital badge┬áthat you can share to display your credentials.

As is often the case with these kinds of certifications, the value is in the initial training, which I would recommend for anyone who wants to learn the difference between EC2 and S3, and why either matters. The exam and certification are an additional extra, nice for hte validation but not fundamentally required.

This is a stepping stone for other more involved certifications, but I’d say it’s not required. An experienced developer could skip this and move straight to the associate level exams without missing much, whereas a product owner, scrum master or other non-technical person may really find benefit at the practitioner level.