Changing young lives one line of code at a time


As the People Operations Manager at Global Kinetic, I am incredibly proud to share the success of our internship program. Over the past four years, we have achieved a remarkable milestone: offering each of our interns a permanent position within our company. By providing additional training and guidance, we are not only shaping their careers but also building a brighter future in an industry that desperately needs skilled and experienced professionals.

South Africa faces unique challenges

The 2022 JCSE-IITPSA ICT Skills Survey makes for depressing reading. South Africa continues to suffer a severe IT skills deficit with a widening skills gap across the sector, from data scientists and software developers to network analysts and security specialists.

But the South Africa skills challenge is a complex one. While we have some of the most talented and creative people on the planet, our education system is severely under-resourced with fewer and fewer young people interested in pursuing STEM (science, technology, engineering and mathematics) subjects. What’s more, those that do graduate and gain just a few year’s experience are quickly snapped up by global companies taking advantage of remote work and a favourable currency exchange. And it’s not just remote working that is exacerbating our skills shortage, the JCSE-IITPSA report quotes stats that show 53% of university graduates and 43% of those earning more than R20 000 a month are considering immigrating.

Recently, the practice of quiet hiring has gained momentum. The practice is when organisations acquire skills without actually hiring new staff. This could either be through hiring short-term contractors, or more commonly, moving team members into different departments where their skills are needed. An example could be a data analyst working in the marketing department being shifted to the business analytics team.

While this may address short-term requirements, it is far from ideal. Teams are disrupted and more often than not team members still have to perform their usual roles as well as their new responsibilities. This has the potential to lead to burn-out and resentment, neither of which is good for the stability or profitability of a company.

Investing in longer-term solutions

Global Kinetic has obviously been impacted by the IT skills deficit. But rather than looking for a stop-gap solution, we decided to invest in a long-term solution that would not only help us as an organisation, but that would also make a difference in our local communities.

Creating internships was the logical path for the company. There was a strong sense from management, as well as our teams, that it fitted neatly into two of our core values: “Care and Support” and “Be a good citizen of the universe”.

However, there are many stories of failed internship programmes and since we wanted to get it right from the start, we chose to work with an organisation called Life Choices.

Together, we designed a one year learnership programme. Our interns spend six months at Life Choices Academy learning theory. The following six months are spent at the company where we start the practical implementation and learning of the syllabus. After the practical element, each intern needs to complete a practical assessment and, once passed, we are confident enough to offer a permanent role within our software development teams.

Challenges aren’t insurmountable when you have the right people

Working in a high-pressure environment, like software engineering, means teams are constantly facing tight deadlines and expectations of excellence. This doesn’t naturally create a space where team members can easily give of their time to help with an intern’s training.

Fortunately, as an organisation we place significant emphasis on training and development and have nurtured a culture of continuous learning that extends from the most junior team members to our CEO. This sort of mindset has transcended naturally to the internship programme.

We are now in the fourth iteration of the programme and it has grown organically since its inception.

One of our biggest learnings has been to integrate all interns into our project teams almost immediately. They attend all ceremonies that take place over a sprint, and are required to do nothing other than listen, observe and ask questions.

We have also built our own curriculum that focuses on agile methodologies and principles, and for the first few months the focus is purely on theoretical work before actively working on the project. By giving them the space to really get to grips with what we do without any pressure, we build more confident individuals. At the end of the practical training and technical assessment the interns qualify as junior technologists and are then active members of their project teams.

Every year that goes by brings new learnings and, while there have been challenges along the way, the reward has gone far beyond 19 new, well-trained individuals. Our teams have also benefited from the experience. So much so that we aim to work with the Department of Education to try and get our programme NQF aligned and qualified. This will mean we can expand and grow the programme, allowing more talent to be uncovered and hopefully even inspire other companies to join us.

The Final Pillar: Designing for Cost


For the OCD readers of this post, defining cost as a pillar of good architecture seems like a poor choice of words as the picture below illustrates.

Cost is the most important aspect of any good architecture because it is cross-cutting across the other 4 pillars.  If you have enough money, you can build anything, but this is not always a good thing.  You can end up not making conscious decisions about where you spend your money and can end up over-engineering a solution to its detriment.  Most projects (and hence architectures) will almost certainly be constrained by budgets.  However, cost not only acts as a constraint on the architecture, conversely it can also help reinforce any of the other 4 pillars.

So how does one design for cost?

The most logical approach would be to apportion cost to each of the other 4 pillars equally and start from there.  But that may put you in a situation where you have overinvested in a certain pillar that is not a priority for the target solution.  For example, if you were building a solution that allows people to share cool cat photos you may not want to invest as heavily in the Security pillar as you would say in the Availability and Recoverability pillar.  On the other hand, if you were building a financial system you would want to invest heavily in the Security Pillar.

The key to determining this balance is by looking at the solution’s Non-functional Requirements.  At Global Kinetic, we group our NFRs into the following categories.

Some of the NFR categories above span multiple architectural pillars, like for example Operational Excellence spans the Performance and Scalability Pillar, the Availability and Recoverability Pillar and the Efficiency of Operations Pillar.  On the other hand, Security NFRs will be focused on the Security Pillar.

Another factor to consider is the stage at which your solution or product is in terms of the market or user base that the solution is targeting.  For example, if you are an early-stage startup, you may want to invest more heavily in Efficiency of Operations which will allow you to pivot and be more nimble in order to respond to changing customer/user demands while you get your product market ready, and invest more heavily later on in Performance and Scalability once your product or solution starts getting traction and the feature set starts to mature.

The most important thing to ensure is that you apportion at least some budget into each of the four pillars at the start so that you are making a conscious decision of which pillar has the highest priority and which has the lowest.  This budget and its apportionment to the 4 pillars must either meet the solution’s NFRs or come with a roadmap or plan of how meet the solution’s NFRs for the system over time.

And there you have it, the Five Pillars of good solution Architecture.  A final note is that a good architecture is one that can meet the demands of the product and market throughout the life cycle of the product without requiring a major redesign.  This means that a good architecture comes with a roadmap of when you will build each part of the architecture out to its full capability, because you can’t build everything up front and on day one.  I hope the blog series has been helpful, and if you need some help working through an architectural design for a new digital product that you are looking to take to market, you know where we are.

We are on the move again | Connect with us!


Are you ready to experience the future of tech, finance and commerce? The next few months are jam-packed with some of the most incredible events for the financial and digital industries, and we at Global Kinetic are excited to be a part of it.

First up, we have FinTech Nexus, the ultimate gathering of financial services professionals who want to learn, connect, and inspire one another. With over 70,000 unique executives attending each year, it's a hub for knowledge, connections, and inspiration for the entire financial services industry. And with our CEO, Martin Dippenaar, Global New Business Development lead, Pieter De Wet, and the CEO of FutureBank, Sergio Barbosa there, it's the perfect opportunity to chat with the movers and shakers of the fintech world.

Next, we're heading to the beautiful and bustling city of Dubai for Seamless Middle East, a multi-brand exhibition that brings together the brightest and most innovative minds across the payments, fintech, banking, retail, e-commerce, digital marketing, home delivery, cards, and identity industries. Pieter De Wet and Dan Meyer will be there to talk about the future of digital commerce and how Global Kinetic can help you navigate the ever-changing landscape of the industry.

And last but certainly not least, we'll be at Money2020 in Amsterdam, where Pieter, Dan, and Sergio will be discussing FututeBank, our embedded finance platform that powers innovative banks and fintechs. This event is a must-attend for anyone in the payments, fintech, and financial services industries who wants to be at the forefront of innovation and change.

We know that these events can be overwhelming with so many amazing speakers, exhibitors, and attendees, but we want to make it easy for you to connect with us. Martin, Sergio, Pieter, and Dan would love to meet up for a coffee or a beer at any of these events. So why not give them a call, pop them an email, or message them on LinkedIn and find out more about what Global Kinetic can offer you.

Don't miss out on the opportunity to network with the biggest names in fintech and learn about the latest technological innovations that are shaping the industry. We hope to see you there!

South Africa is losing billions to poor-quality software - TechCentral


South African businesses are losing billions of rands due to poor-quality software. And as the economy tightens and skills remain scarce, this is likely to get worse, forcing them to pay to fix avoidable problems and resulting in stalled growth. In an effort to save costs, local companies often fall for the low-quality code trap, writes Sergio Barbosa (CIO, Global Kinetic).

Sergio speaks further on this in the following TechCentral article.

View the PDF version of the article below:

[pdf-embedder url="https://globalkinetic.com/wp-content/uploads/South-Africa-is-losing-billions-to-poor-3.pdf" title="South Africa is losing billions to poor software"]

What makes a great API?

What makes a great API?

Global Kinetic Discovery Team


API design has more to do with user interface design than programming.

— Arnaud Lauret, The Design of Web APIs

 

From the wheel to the modernist skyscraper to the iPhone, the best designs are easy to grasp, simple to use, and never limited to a single use case… possibly excluding the toaster.

A couple of weeks ago, we wrote about the need to productize application programming interfaces (APIs). Today, we look at three related characteristics of a great API product: accessibility, simplicity, and standardization.  

Reliability and security are both non-negotiable too, but since our focus in this blog series is on API productization, you’ll forgive us if we concentrate on user experience instead of performance. SmartBear’s annual survey of the API community has found that API developers consistently rate performance as the top measure of an API’s success, while API consumers overwhelmingly choose ease of use, followed by accurate documentation.

Accessibility is an important characteristic of great APIs

How do we shorten the technical gap analysis phase for the prospective user and as such fast-track the buying decision?

Global Kinetic Discovery Team

 

Time is a critical factor in driving adoption and use of any API. Specifically, the time it takes for the prospective user to get their heads around the product: to experiment, understand, and find some early success. Some have put forward Time to First Call as an important key performance indicator.

 Malcolm Gladwell said it takes 10,000 hours of practice for just about anyone to master anything, but he wasn’t thinking about your API. Great APIs are intuitive and easy to use. Prospective customers don’t have to complete hours of training or read pages of technical documentation to get started. If they do, if it takes too long to get there (three minutes by some estimates!), they’ll probably move on. 

 Only the very largest organizations can afford to think that just by building it, users will come – or that, once they’re there, they’ll stay. There are 24,689 APIs listed on ProgrammableWeb’s API Directory. That’s a lot of competition. 

Start with documentation

How do you help prospective users get to know your API? Concise, well organized, and up to date documentation remains essential. This is one of the first places developers look to understand what a particular API does, whether or not it will meet their needs, and what the necessary inputs are. And users won’t appreciate formats that are difficult to search, bookmark, share, or copy and paste (sorry, that’s you, Mr PDF). 

 They’ll want to see typical usage scenarios, a list of available methods and accepted parameters, as well as code examples for all product features. As we mentioned above, accurate and detailed documentation follows only ease of use as the most important characteristic of an API in users’ minds. 

 For its 2021 State of Software Quality: API, SmartBear asked what their top five most important things were in API documentation itself. Examples were chosen by 65 percent of respondents, followed by status and errors (55 percent), authentications (54 percent), HTTP requests (47 percent), and parameters (46 percent). 

 Documentation should be approached as an integral part of the offering and product development lifecycle. There are many tools to generate accurate documentation in line with development. Global Kinetic’s API designers use Swagger together with our in-house documentation standards and style guide to produce consistently readable, navigable material.

Where possible, show rather than tell

How do we enable self-service integration and minimize the cost / time to revenue when onboarding new customers?

Global Kinetic Discovery Team

 

You know what though? Most developers will want to jump right in, and you want to make that as easy as possible for them to do. Just as good documentation rests on excellent structure, so do APIs benefit from well-considered design that adheres to predetermined design specifications and guidelines and conforms to widely adopted industry standards.

 Design-oriented developers aim to take maximum advantage of affordance – a term that shifts in meaning between disciplines, authors, and decades but is used in the design world for our perception of something’s possible use based on its perceived and actual properties. These are the clues designers put down to aid the discoverability of an object or element of an interface. In other words, to reduce the time it takes to get to know the product.

 “When affordances are taken advantage of, the user knows what to do just by looking: no picture, label, or instruction needed,” says Donald A. Norman in The Psychology of Everyday Things. Trails of clues like these ensure that APIs are easy to navigate simply by virtue of their design. But to craft an experience like that – to develop an API that is as independently consumable as possible – takes care and a deep understanding of the prospective customer’s context: their capabilities, experience, and goals. 

 If you’ve spent time gaining that knowledge before coding, your API will likely provide a superior user experience – and offer better performance, scalability, and security too. That’s why Global Kinetic takes a strictly design-first approach to API development.

Which brings us to the API sandbox

How do we ensure approachability through the design and implementation of developer portals with Day One access to a use-case–driven, full lifecycle developer sandbox?

Global Kinetic Discovery Team

 

API sandboxes emulate the behavior of production APIs. More than just demos, these testing environments are like a free trial and an essential part of any API product strategy. As any of the big names in e-commerce will tell you, a try-before-you-buy sales and marketing strategy helps build trust and ultimately drives sales. Allowing prospective customers to test your APIs before making a purchase, without risk or financial outlay, has the same effect.  

 Sandboxes’ benefits extend beyond onboarding too. Developers can continue to test integrations without the additional cost of “live” API requests and support calls, or the frustration of potential blocking/throttling of their API requests. At a deeper level, the independence that a sandbox affords them to experiment helps speed innovation and project progress.

The pursuit of simplicity is an element of all great APIs

It is important to emphasize the value of simplicity and elegance, for complexity has a way of compounding difficulties and as we have seen, creating mistakes. My definition of elegance is the achievement of a given functionality with a minimum of mechanism and a maximum of clarity.

— Fernando J. Corbató, “On Building Systems That Will Fail”, 1990 Turing Award presentation

 Your customer has a problem to solve and it shouldn’t be your API. They probably don’t have time to diligently explore its delicate and manifold mysteries, and there is no real reason that they should. It can be tempting to add more of everything in pursuit of greater utility, but users are frequently more appreciative of a pared down experience. That doesn’t mean you’ve stripped out useful functionality, but that you have consciously worked from the definition stage onwards to prune away the unnecessary and mask complexity.

 Ronnie Mistra, a co-founder of the API Academy and senior director of technology at Publicis Sapient, says that the API designer’s job is to manage complexity – and specifically to improve learnability, boost usability, and reduce confusion. It isn’t easy, and it again requires a laser sharp focus on the user’s problem. Donald A. Norman again:

“Complexity can be tamed, but it requires considerable effort to do it well. Decreasing the number of buttons and displays is not the solution. The solution is to understand the total system, to design it in a way that allows all the pieces fit nicely together, so that initial learning as well as usage are both optimal. Years ago, Larry Tesler, then a vice president of Apple, argued that the total complexity of a system is a constant: as you make the person's interaction simpler, the hidden complexity behind the scenes increases. Make one part of the system simpler, said Tesler, and the rest of the system gets more complex. This principle is known today as ‘Tesler’s law of the conservation of complexity’. Tesler described it as a tradeoff: making things easier for the user means making it more difficult for the designer or engineer.”

― Donald A. Norman, Living with Complexity

 Interrogate the need for anything. Cut the required number of user actions to the minimum. (“Try very hard to delete the part or process,” as Elon Musk has said.) Strive for modularity and composability. Automate what you can. Ensure that only essential data are exchanged. Patterns help make sense of complexity, and hence…

Great APIs are internally consistent and follow industry standards

A sure-fire way to turn user developers off is to diverge from industry best practices. Respondents to SmartBear’s latest survey gave standardization as the most important technology challenge in the API space (52 percent to security’s 40 percent and scalability’s 36 percent) – and previous years’ results suggest the sense of urgency in this regard is growing.

 System- and ecosystem-wide standardization and internal consistency make a huge difference in efficiency, security, and interoperability. They vastly improve the onboarding process and save time in development. We are all, by now, pretty good at finding our way around new user interfaces. They follow predictable patterns and use concepts and design elements with which we have become familiar. Ensuring that your API has a similarly predictable structure smooths the user journey. Consistency also goes a long way to ensuring backward compatibility when you update your API.

 Too few API portfolios demonstrate a fully consistent approach to naming, error messages, and code patterns. Many do not follow widely recognized global standards. Quality can be poor. There are reasons for this, many of them understandable. We discussed some a couple of weeks ago. In Europe, part of the problem is also that financial institutions – some of the leading users of APIs  – saw little value in developing quality APIs in the lead-up to PSD2. The regulation did not seem to most institutions to be in their commercial interests. (There was also no EU standard for how they should look, something that PSD3 is set to address.)

 That has changed, of course. Banks and other organizations of all shapes and sizes have come to recognize the benefits of data sharing and have launched API portals to manage API product development, security, as well as marketing. Many of them have worked with specialists to fast-track API productization, so that they can meet market needs faster and more reliably than they might have alone. 

 

Looking to build out your API strategy? Contact Global Kinetic – we can do this for you.

Effective autonomous teams all share these five things

Effective autonomous teams all share these five things

By Lorén Rose, COO, Global Kinetic

Lorén Rose is a co-founder and COO of Global Kinetic. Drawn to software engineering by its utility in solving complex problems, as well as its satisfying testability, she spent a decade and a half designing and developing enterprise software, primarily in financial services. Working with her future colleagues at Global Kinetic much of that time, she gradually shifted her attention to another kind of problem-solving: operational strategy. Today, Lorén’s focus is on building top-quality, highly motivated, and happy software delivery teams in support of a steadily growing business.

 

Why autonomous teams in the first place?

Why does Global Kinetic use autonomous teams? Is it because we don’t want to spend money on layers of expensive management? (We don’t.) Would Global Kinetic have a hard time finding middle managers that our super-bright, highly skilled people trust enough to direct their work? (Probably.) Or is it because we genuinely believe that autonomous teams deliver better results? (We do!)

Full ownership and accountability at team level are essential to building highly motivated, efficient, and happy software delivery teams. Global Kinetic relies on our engineers to solve the problems they encounter for themselves, to make their own decisions about the length of time projects will take and the paths they might follow to get the job done. In our experience, that freedom has a measurably beneficial impact on speed and code quality.

So, next question: Why have early enthusiasts like Spotify and Medium reverted to more traditional organizational models? For me, it comes down to this: many organizations have hoped to use autonomous teams to scale, but they scaled too fast. They put ever more people on the ground but without the necessary support. Their early teams may have been exceptional, but most people aren’t ready for self-organization. It’s a skill like any other, and you need time to hone it.

In today’s blog post, I list five important elements I believe you need in order to benefit from autonomous teams. Each element impacts the others directly. If you’re burning on one side of the pentagon, you’re going to feel it on every side before long.

First requirement for autonomous team success: Context


   If you want people to do something – and particularly clever people – you have to explain why.


In our industry, you see a lot of these feature factory teams, where they have product owners commanding engineers to “Build this feature! Build that one! Make them look exactly like this.” That’s not helpful. That’s 100 percent antithetical to any kind of autonomous team, well-functioning or not.

If you see the value in self-sufficiency, if you want to empower developers to make their own decisions, you have to ensure that they know, not only what they are building, but why they are building it. What are the problems the client hopes to solve? What are the benefits they hope to accrue? And since we are always indirectly building experiences for end users, we need to know who they are too and what they are wanting to do. Banks and other service providers can only benefit from having our engineers standing in their customers’ shoes.

Global Kinetic is strongly focused on quality, but our customer may also be looking for something else – prioritizing a rapid time to market, for instance. Let’s say that they have a limited budget: they need to launch fast, so that they can bring in new revenue and reinvest it in the software. That’s also important for a delivery team to understand. If they know that, they can determine today’s minimum viable product, taking into account the technical debt and planning how they will address any compromises tomorrow, when the money comes in.

I want our teams to make those decisions, which is why we are continually working to give them as much information as possible.

Second requirement for autonomous team success: Guidance



   You have to know what worked before and master that, then come back and alter it if necessary.


While context ensures that teams build the right thing (effectiveness), guidance ensures that that they build it the right way (efficiency). I am highly conscious of the fact that everything I do – everything our teams do – has to be maximally efficient and cost effective. For me to have a hundred people solving the same problems from scratch, learning the same lessons every time, that’s money down the drain.

We have 20 years of collective experience on how to deliver top-notch enterprise software in reasonable time frames. We have codified, I suppose you could say, the lessons we have learnt and the processes that have reliably worked to date. I really value that body of knowledge; whenever things go wrong, our engineers can rely it to guide them back to predictability.

We didn’t approach it as a set of rules. We don’t want to hem our engineers in with anything so doctrinaire or inflexible that it requires them to check with HQ every time they are forced to deviate from the script. We see them as recommendations providing support to the teams in the field. And, by giving teams context on why the guidelines exist and the problems they help solve, we empower them to make better decisions over when and how to apply them.

We don’t hire based on prior experience of autonomous teams. Our approach is unique; it’s a product of many years of incremental changes made against the backdrop of our history and core values. We hope all new people master it over time and contribute something of their own to its evolution and our continued alignment. It’s a living thing.

Third requirement for autonomous team success: Continuity


  Building winning teams starts with your pacesetters, but there’s no room for heroes.

You can put in the best sets of guidelines, all kinds of policies and procedures, but, if you don’t take the time to build out your delivery teams properly, your ambitious revenue targets will likely not be met. And it does take time. Identifying and developing your teams’ pacesetters can’t happen overnight, yet it’s vital that you have the right number of them embedded in your teams to provide direction and transfer tacit knowledge – the accumulated, mostly undocumented experience of seasoned staff.

I am highly reliant on skilled engineers who have mastered our processes and have the experience, confidence, and emotional intelligence to adapt them in the right way when necessary. Their availability to seed new teams, up-skill incoming staff, and provide day-to-day guidance constrains how fast I can scale.

In my last blog post, I wrote about how important work–life balance is in addressing employee churn. People do leave, however. When they do, as reliant as I may be on some of them, I want the impact contained.

“Key-person risk” describes the potential exposure of an organization to the sudden departure or incapacity of an important employee. Their loss could affect productivity, morale, client confidence, or brand perception. So, we work to mitigate this by always foregrounding team continuity in our considerations, ensuring that the team as a whole is the hero and their success is never tied to a single individual. As the African proverb says: “If you want to go fast, go alone. If you want to far, go together.”

How’s that translate into reality? Standardised ways of working, documentation and training, the organized transfer of project-specific know-how, mentorship, and the all-important informal sharing of tacit knowledge.

Fourth requirement for autonomous team success: Support


  Finding a balance between the needs of the company, its delivery teams, and individual employees takes structure and a caring culture

In any company, you have people working on the business (the strategic layer), people working in it (the operational layer), and a framework to keep the two layers in alignment. So, too, does it work with technical leadership.

Firstly, you need leadership working across delivery teams to drive collaboration and normalisation of standards and processes. Secondly, you need leadership working within teams to drive delivery and apply those standards judiciously, based on business and project context. That’s the only way you are going to be able to scale.

At Global Kinetic, while some people are focused on initiatives aimed at driving the business as a whole forward, others leverage those initiatives within the teams to ensure they develop in turn. Working at another level, the cross-team leadership inspires craftsmanship and mastery in the individual, while the in-team leadership provides guidance to individuals on how to apply their craft optimally.

This sort of matrix structure is difficult to get right, and, done badly, can be distinctly counter-productive. On the other hand, it can happen quite seamlessly, if you have a strong culture of caring and support. What’s best for the business may not always be what’s best for the team or the individual team member. With champions representing each layer, we are better able to devise a solution that meets the needs of all three. It’s a collaborative process that goes a long way to achieving business success, team continuity, and individual growth and fulfillment.

Fifth requirement for autonomous team success: Alignment

  
Knowledge sharing factors valuable new insights into our formal processes and counters the development of silos.

In his excellent critique of the Spotify model, Jeremiah Lee wrote, “Autonomy requires alignment”. As an aphorism out of context, it’s opaque, I grant you, but Lee was on the money writing that, while cross-team dependencies multiplied as Spotify scaled, the high degree of team autonomy there hindered broader communication and collaboration. Without a structure and a language for sharing their insights and experiences, teams drifted apart and the business suffered the consequences. The biblical Tower of Babel springs to mind.

Early implementations of autonomous teams, including at Spotify, frequently neglected business-level operational considerations, particularly in areas where hierarchy might offer a more workable solution than holacracy: negotiation, conflict resolution, and escalation; individual support and development; and collaboration on developing and improving shared resources.

Unshared knowledge is a waste. “Learnings” have limited impact if they aren’t transformed into “teachings”.  I don’t want teams working in parallel to answer the same questions, unaware of or unable to consume the others’ answers. Yes, their directive is to deliver on a project, but I want them to do so in a way that moves the whole organisation forward.

Alignment creates the context for achieving business goals: “What does success for the organisation look like and how do we align our team’s success to that goal?” Autonomy enables us to do that in an innovative, effective and efficient way.

Contact Global Kinetic to discover how we work together.