As my career has progressed, I’ve realized that the majority of my work involves being a valve on my team. What that means to me is that essentially, most of my value is in deciding when I should block or unblock something or someone.
This manifests in many different ways in my day to day work, but typically I will start my mornings performing code reviews. The code review process is probably one of the most valuable and powerful ways to not only increase visibility across teams in how something works, but also an excellent source of knowledge and learning that can very quickly ramp up new engineers and expose them to best practices in a much more effective way than documentation — which most people do not write well nor reference as often as they should. As a valve, during code review I do my best to ensure that I am not unnecessarily blocking progress by not reviewing in a timely manner, but I also often block progress at this step to ensure that designs are being implemented as expected, standards remain high, and that everyone understands how or why things work the way do.
After code review, I tend to view our team’s input queue to ensure that again we are blocking or unblocking as needed on feature requests, tickets, or general questions on how systems work. Not only does this help external teams but also ensures that the company as a whole is moving efficiently. I also know that it improves standards all the way around and that when I’m on the other side of someone else’s input queue, we too will get better service as a result.
Our daily standup is the next opportunity I have to play the valve — I tend to keep my updates short and focused on answering three main questions:
What progress have I made since yesterday?
What am I doing today?
What issues am I facing that may jeopardize my progress today or in the near future?
Each of those questions help define how the flow of work is proceeding — whether things are flowing smoothly and progressing or whether they are or need to be paused to allow for some other flow to cross or merge into the main flow.
Though it’s a simple concept, viewing myself in this way has helped me very quickly make decisions in the face of constant ambiguity. My gut feeling about whether I need more information or need to influence someone to do something other than what they think let’s me answer questions quickly, set expectations appropriately, and continue to improve the quality of work we do as a team.
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.