Are you a technical person?
I am often asked that question. Why? Does the answer matter?
I believe most are curious and ask simply to understand how to communicate with me. Or, perhaps the person is trying to figure out which box to tick next to my name. I get that. But, really, aren’t we all technical people? Does the fact that an individual who is not a software developer, and whose work is focused on the business side, make them non-technical by default? Is the divide between these two groups, the business “non-technical” side and the software “technical” side so great we can never bridge this and accomplish great things together? Absolutely not.
Developing software, writing books, and writing blog posts is not easy. If these things are done well, they can have a tremendous effect on many people. Although I am not currently a programmer or architect, I have been involved in numerous successful software projects, as well as editing books and blog posts. Could I have written the code? Not currently. Could I have written the technical books and blog posts? No. Did I make them better? You bet!
So, what is my background? Yes, I have programmed. (In APL in case you are interested.) I have tested software; written requirements; trained personnel in using software I helped develop; proven to developers how a bug is in their code and no one else’s; worked as a UX/UI designer and developer, and as an information architect; been a frustrated consumer of software that forces me to do things its way when I clearly know a much better, simpler way; attended numerous conferences, trade shows and talks where my eyes glaze over as the speaker dives into super-techie stuff. (Yawn)
What about DDD? Do I know what a Domain Event is? Sure, I have multiple of those in a day 🙂 Of course I know what messages are! Yes, I have learned the concepts of Domain-Driven Design and used them in projects.
Am I a techie? You decide. What I do know is I don’t refer to myself as a technical person. I like being a business person. That excites me! Could there be others on your projects, just like me, who have a lot to contribute, and who understand the business? If given the opportunity to have meaningful dialogue with those techies in your company, they could be part of the catalyst that changes the culture of your development team and the outcome of your projects to the good of the business. All too often I have seen such opportunities brushed aside. Yet, I have also seen it work when the opportunities are seized. The latter is obviously my preference, and it should be yours as well.
Diverse, Diverse, Diverse!
The buzzwords and trends of our society are an interesting phenomenon to observe. Being diverse is all the rage these days. Being autonomous is celebrated. Fantastic! At the end of the day, how does this translate to the business of running a business?
It is collaboration of diverse, autonomous, individuals that makes projects successful. Our team at Kalele is diverse and we all have a mind of our own. Just ask us! Each of us brings multiple decades of hard-won experience to the table. Our clients, whom we respectfully maintain private, are in all sectors of industry. Insurance, Medical, Fintech, Apparel, Logistics, Energy, Pharmaceutical, and Aviation are just some of the industries that come to mind. In startups, Fortune 500, Fortune 100, Global 500, national and international firms we have affected change. Not because we are rock-stars, but because we listen, we teach, we motivate, we roll up our sleeves, and we use all of our combined experience to help you succeed in doing the hard things. What are those hard things?
Getting the business to talk to developers and developers to talk to the business is a very hard thing. People have all kinds of preconceived ideas of what each group is like and how they behave. Yes, it is true these ideas come from real life experiences, but they also are stereotypes that hem both groups in and isolate them from each other. None of that is good for the business. And if it isn’t good for the business it will eventually not be good for either group.
Doing the hard things—breaking out of the existing mold and freeing both the business and developers to communicate and solve problems together—is what we at Kalele do. That is where the magic happens! We have seen it so many times. That is the juice that keeps us going and working hard. Is it easy to accomplish? No. Will it be painful? Sometimes, but not often. The transformation that occurs when all take the step forward together is real and not hype, which makes any business cultural adjustments well worth the effort.
Let us help you implement Domain-Driven Design in your business. We want you to succeed in projects that acknowledge your business’ competitive edge and autonomy. We help you renew and transform from Big Ball of Mud legacy systems to well modularized Monoliths, and to Microservices, where appropriate, in a clean and orderly way. We also make Reactive architecture and development a simple and straightforward reality. Drop us an email and let’s discuss how we can collaborate and move your team forward.
Email: info@kalele.io
