What I love most about software is that it is excellent at doing exactly what you tell it to do, never veering from your instructions, never complaining, and doing it extremely quickly. These are not only excellent characteristics we can leverage for our own efficiency gains, but coincidentally things that humans like me are typically awful at. Finding a tool that does things you are bad at and does them well, quickly, and cheaply is so rare that we’d be remiss not to take full advantage of these quirks in its nature. In an attempt to leverage these powers for good, I’m sharing an in-progress project I’ve been working on called Robot Blocks.
For my own uses, Robot Blocks has been helpful to quickly build up a project with a backend data store in my preferred framework, .NET. Inverting the pattern we used at WAM, I took an Entity Framework code first approach that allowed me to organically design/build my data model and not worry too much about the backend details. I’d like to eventually make it a part of my build toolchain to update my backend as I develop. If I were building client facing apps, I’d longer term want to generate a simple front end admin tool for the database, and some simple tools to query/dump the data for BI purposes.
For art to be meaningful, I feel that it must be decontextualized. By this I mean that it should be removed from culture and personal history and instead related to a greater human truth, the kind which crosses all boundaries of culture, time, gender, or experience. If I were to be lifted from my body today and moved to the middle period of the Great Egyptian Dynasties or teleported into the halls of Ancient Greece, I should still be able to marvel and be touched by the art that they generated in their times, regardless of the oceans of time between my experiences and those of artists. Granted, this is perhaps too strict a definition of art as it eliminates a great deal of what can only otherwise be defined as art from today’s generally accepted definition, but I feel that those modern and more narrow expressions of self need to be recategorized and bucketed into a new word.
As a leader, you need to work hard to ensure that as your company’s goals change, they change with full transparency and buy in from everyone in the organization. Oftentimes, change can be perceived as a red flag for many of the people at your company. For them, the sacrifices, expended time, passion, energy, and more were all made in the name of achieving the goals that helped create and grow your organization, and any directional changes can demoralize and devalue those sacrifices.
Obviously, in business goals often need to change for the sake of staying alive and thriving in a constantly changing marketplace. However, it’s of the upmost importance that they shouldn’t leave a trail of destruction through your culture as they do so. Establishing early on what your culture stands for is the cornerstone of surviving change. Culture is not what you say, it’s what you do and what you value. When you allow your culture to change, it is due to your disassociation from your original values and from the work done daily that’s actually keeping the company alive, a disconnect on the leadership’s part to understand what the company actually does, and a sign that leadership and the rest of the company are working in two very different worlds. If you don’t experience the pain points, you cannot empathize with the difficulties you’re asking your team to deal with, especially when you need to nimbly shift your company’s business. Morale drops, further worsening culture from the inside out because it is no longer a culture lived organically by every person in the company but instead hardens from the bottom up. By the time it makes it up the proverbial ivory tower, it’s too late to react.
Informal check ins keep a clear path of communication open between you and the rest of the team. When you ask for candid feelings or thoughts, you’re more likely to get them when you’ve established a communication pathway that’s trusted and real rather than formal, stiff, and unnatural. Having a real relationship with people you work with actually reduces context switching, too, because you can very quickly interact with someone rather than setting up a meeting (which tend to suck out time and productivity) and formalizing the event. Who knew that being a real person had benefits in the workplace?
The bottom line is that the closer you are to your team as people, knowing what they’re thinking and when they’re in a good or a bad mood, the closer you are to working together to create a better workplace and get things done. You become more aware of the feelings and energy of the team producing work and are also that much more likely to correct issues earlier in the process. It’s like iterative development – you constantly check your work instead of all at once in the end, when it’s likely too late or too much effort to do anything about it.
Like lots of people who have been around technology for a while, I don’t have much of a classical business upbringing. This general ignorance of The Rules has helped create new styles of management and work environments that offer a whole lot of benefits over The Old Ways in my father’s days of computer-less desks, cigarette smoke heavy in the air, and not wearing a tie about as casual as a Friday got.
Still, when it comes to leadership, it’s good to be a little atavistic about watching what we say, and when we say it. Formality isn’t always a four letter word and can instead help to guard you about saying things that can’t be unsaid.
The greatest leaders have a strong ability to empathize with their team. Leadership is not task management nor is it riding people to perform the minute details you think they need to perform to achieve your vision. True leadership recognizes that you need the people following you much more than they need you – without an understanding of their motivations or abilities, you’ll likely be unable to relate your goals to theirs.
If you’ve spent any time at all developing software, you’ve – willingly or unwillingly – had to come to terms with the fact that a huge part of your job isn’t writing new code, but is instead about playing detective and recreating causes to problems so that you could fix them.
One of the principles I live by both in my professional as well as personal life is to appreciate what’s come before me. Recognizing that while there are often opportunities for improvement, decisions made before you were around are what allowed you the opportunity you have today to make things better.
It’s well known that a major component to a successful user experience is absolute consistency. Apple does this better than almost anyone, and as their desktop and mobile OS quickly merge it will become even more consistent than it already is today. For the most part Microsoft is a close second, and I say this even after factoring in the fact that the new Metro UI has a certaindisjointedfeel to it of something new bolted onto something old. In fact, their consistency has opened them up to criticism: Windows 7 wasn’t so different from Win95, after all.
While listening to a great interview over at This Developer’s Life, I started thinking about how I personally deal with stress and pressure. We’ve had our share of catastrophes at WAM, like everyone in the game of software development it comes with the territory whether it’s working on client projects or your own products. The scenarios are the same: something isn’t working the way it’s supposed to work, there’s a problem you never saw before, and someone is upset – worse: they’re looking at you to fix it.
Like so many times in life, you have two paths you can choose to follow in these situations, the way I see it. You can Panic or you can Relax.
I, being a child of the 80s, will always and forever listen to Frankie, and Frankie says “Relax”. In addition to being an amazing dance song, it’s also sound advice in almost any situation where it is an option.