Home » Articles posted by Technically Leader (Page 2)

Eating the elephant

Had a talk with the contractor who’s been responsible for the development of the websites for which I’m going to be responsible starting Monday. Websites that will be going live Any Week Now.

Productive discussion and a brief crash course in the software upon which these sites are built.

But what I also learned is some not wholly unexpected but difficult facts about the environment into which I’m headed. And it’s an environment pretty familiar to me — in many respects, it’s very much like the environment of my current job was the day I arrived.

One of the things I’ve learned through multiple jobs in my career is that most startup companies which have a core web services platform have a point I call Development Adolescence, a period analogous to true adolescence where one transitions from carefree childhood to responsible adulthood. And that transition is a period of difficulty, awkwardness, and often self-created pain and angst.

Development childhood is the period where a new company is initially creating and growing its web services. It needs to grow fast, and it doesn’t usually have a very detailed idea of what it needs its web services to be. So the web services tend to grow organically, rapidly, without a very clear picture of its destination. There are either no clearly defined business owners of the platform, meaning too many people drive the business process of its development and not enough people (outside the developer or developers themselves) have any accountability for that development. The application grows, it becomes harder to maintain because the code has no overall structure for its growth, requirements documentation is sparse to nonexistent and process flow documentation doubly so. “Technical debt”, meaning structural defects in the application that slow new development or require time invested to maintain the existing services, builds up. Developers start fearing the most onerous parts of the codebase and know that the entire system is brittle and can break in unexpected and non-obvious ways by any modification.

The tipping point is reached when either business needs outgrow the capacity of the existing platform to meet them, or the accumulated technical debt renders the platform so unstable or development so painful that the dev team cries out for relief. The business becomes aware that the current path is unsustainable, and that the development process must mature. And thus begins Development Adolescence.

Adolescence is the process of the development team leadership (by which I mean me) establishing a sustainable development framework for both stable growth in the web services platform and for controlling and prioritizing the flow of new change requests coming for the business. This process usually takes place in the context of either a major overhaul or wholesale replacement of the web services platform, transforming it into something that has a much better chance of serving the needs of the business in the medium to long term.

This isn’t awkward in and of itself, but the awkwardness ensues when the business, which has reached the point of understanding that the development process needs to greatly change, doesn’t yet understand that the business process must change too. When adolescence is reached, the business has become accustomed to how they do things — usually, they tell Dev to do something and Dev does it. There is no gatekeeper who prioritizes task, no real requirements gathering, no business owner to agree to the specific changelist, no placing the requirements in the context of the long-term business goals, nothing. And they are resistant to changing how they do things, because what they’ve done so far has worked, for them.

And so it is incumbent upon the development team leadership, along with the senior management responsible for the dev team (usually, the CTO/CIO), to bring the business to understand and buy into the value of changing their processes to work with the new business processes. And this is no easy task. Myself, I favor a top-down approach: Work with the CTO/CIO to get buy in from the CEO and/or the rest of the senior leadership team of the company, who then champion the business process changes with the rest of the business, who in turn adapt to change, slowly, step by step.

The problem with that path is that there’s always the chance you don’t get buy-in from the CEO/SLT. And that makes adolescence far more difficult to get through.

The other viable path is to try to convince the business more holistically by putting processes in place step by step and showing the business the benefits that are reaped by demonstration. This is an even slower, more incremental, far more painful process to adulthood.

Whichever path is taken, the question of how the business will emerge from adolescence is largely a question of how well the business adapts to change (er, okay, that and how well the development team imposes the process upon itself and how closely it adheres to that process, but I’m talking about the business here). And I’ve personally seen this go well, and go poorly, in my own work history.

The company I’m leaving is one where it’s gone poorly. The business adapted to some of the processes, but did a very bad job of bearing the pain of transition and began to slip into the mode of “panic-driven-development”, where the dev group was repeatedly directed to redirect its entire effort to whichever issue was causing the business the most pain at the moment. This results in lots of projects being left half-done, “to be finished later”, as the new greatest pain point becomes the new focus. Over. And Over. And Over Again.

TL’s Second Rule Of Development: Change to development processes is painful. If you’re going to commit to the change, commit to bear the pain, or you will fail.

I don’t know how well my new company will adjust to the change, nor how resistant it will be to changing at all. But I am fairly competent that the CTO, the new BA and I are all of one mind that we need to bring change to the company to usher it through its adolescence. And it will require an enormous, sustained, united effort to do this. It is a monumental task.

But how do you eat an elephant? One bite at a time.

Orientation

First, a side note: There was massive snowfall yesterday and this morning. The drive to the central office of my new employer is about 40 miles from home. It was orientation, so I felt it important to go anyway. This was a mistake. I came very close to destroying my car and possibly myself via collision with snowplows, and only a well-timed swerve when braking proved impossible kept me from being a snowplow sandwich. It is NOT worth braving dangerous driving weather, even for a very important work meeting.

That said, I did go to the new job, and I did get some orientation. I took notes. Lots of notes.

I got to meet the CEO face to face. He’s a younger guy, five or so years younger than I am, but very ambitious and very likeable. He also doesn’t try to hide it when things aren’t being done as well as they could, and he listens to criticism.

I got to meet a couple other new hires. One’s in IT and seems to be a likely ally, which I will need, as the laptop they assigned me is locked down and I can’t install my own software on it without IT administrator access. This is not an acceptable situation to any self-respecting developer. The new IT person, whom I’ll call 80’s Hair, understood and appreciated this.

The other new hire is the BA-slash-PM-slash-QA expert. She’s going to be wearing three hats, which I suppose is tenable for now, but that role needs to be broken apart. She and I are working on building a good rapport, as we’ll be working closely together in the months to come.

It was also “monthly meeting” day, which meant a group lunch. This was a chili cookoff. And me without my special homemade chili. (I’m quite a foodie, I admit.) But the chili I sampled was plenty tasty and I had time to get to meet more of the people in the main office.

But the big thing today was what we term ‘drinking from the fire hose.’ The concept is being flooded with more information than I can possibly absorb at once, and all I can do is try to take in all I can.

This particular firehose was learning about business processes, specifically order fulfillment and customer service. The former is the basic result of the e-commerce sites which I’ll be responsible for; the latter is the basic conduit of feedback from the customers. The OF guy spent about 90 minutes illustrating his process to us. He showed us how it began with the output from the existing e-commerce site, printing out packing slips, distributing them into bins, filling the bins from inventory, bringing them to the packing area, and packing the orders in bubble envelopes or boxes, labeling them and marking them in the e-commerce site as shipped. I learned about the basic pain points, the basic points of failure, how those points are caught, and the time invested in the process of catching them.

On the other end, the customer service manager and workers had much input from their customers, and that information doesn’t seem to have a distinct process for getting back to development to be incorporated into future development requirements. Both the new BA and I are keenly interested in remedying that situation.

After that, I was exhausted and packed up my new work-assigned laptop for home on the (now much better plowed) long road. I was requested by the CTO to call him to go over some stuff. So, I did. I was tired, but CTO and I talked and planned out the next couple weeks. I also confirmed with him what earlier conversations with the CEO and document review made me suspect: The nearly-complete current development of the core website was done without a clear requirements document — which made its development go badly up until now. CTO’s high priority for when he is in town the next two weeks, and therefore my high priority for the next two weeks, is to define those requirements tightly. Once that’s done, BA can develop a test plan, and I can evaluate the current state of the project against those requirements, and identify the difference between the two. From there I can plan out development and estimate a time to completion — and then release.

Once that’s done then CTO and I can ensure that all future development will be done against a clear set of requirements, and a business owner of those requirements.

TL’s First Rule Of Development: Without clearly defined and accepted requirements, there is no effective way to know when development is complete, nor even to know what exactly needs to be developed.

Sure with vague requirements like “Make it work like that thing worked” you can get a decent idea of what you’re trying to develop, but it’ll never be clear, and whoever the business owner is will be able to push scope creep into your process with nigh-impunity — other than crashing your sprints and breaking your deadline commitments.

A gathering

My former project manager, Smiley, hosted a gathering of mostly current and former employees of my company. Sparky, Red, Phoenix, Kabob and Harley were there — Sparky, Phoenix and Kabob being current along with myself; Red, Smiley and Harley being the ex-employees.

The conversations that were had are not mine to detail — what happens at Smiley’s stays at Smiley’s. But for me, the content of the conversations, including my personal detailing of some of the reasons for my departure and my very candid advice to my team going forward, was part of my process of letting go.

One thing I do when I find a place I like to work is bond with people. And where I work now is no exception. And it’s hard to let go. But this gathering (which was coincidental to my departure) was a good opportunity for me to take a step down that process.

I wonder what the new company will bring me — if I’ll find the people I can bond with, if I find something there worth bonding to.

T minus eight days until I can start finding out.

Well, not counting Tuesday, when I take the day off from Old Job and head to New Job orientation.

Passing the baton

At the workplace I’m leaving, the development group is split into two teams: Development and Production Support. I’m the Development lead — meaning I head the team that builds product enhancements and new features. Cupcake is the Production Support lead; his team handles the day-to-day technological help the rest of the business needs in using the central products, maintains the existing code base, troubleshoots production bugs, et cetera.

Now, apart from Cupcake, there’s really one other guy in the group who has the skillset to be the lead of the dev team — New Kid (who is actually the guy with the longest tenure; I’m second). But unfortunately, much to my surprise, New Kid turned in his notice the day before I did. This means Cupcake’s really the only one on the team who’s got the skills and experience to be the lead of either team.

So, assuming Cupcake would be running double duty if Sparky didn’t fill my role himself, I took the time to give Cupcake some tips about handling the personalities of my team. My team has three developers: Phoenix, the most skilled developer; Kabob, who’s a fairly green developer; and Hockey, a UI designer and the junior member of the whole group.

Phoenix is a great developer but he knows he’s a great developer. He also isn’t particularly skilled with interpersonal relations, mostly because he doesn’t seem to value the benefits of such things as diplomacy and communication. He regards them, often, as distractions from doing his job, which he sees as writing code. So I told Cupcake that Phoenix needs to be encouraged to understand the necessity of communication and how it benefits the team, and how using a little tact doesn’t mean he can’t be honest, and that it helps to work more closely with QA (and our QA guy has certainly been frustrated with Phoenix’s brusqueness in the past).

Kabob is a more junior developer and needs more direction. He also doesn’t want to need more direction and feels like he needs to pretend he’s better than he is in order to fit in with a group of largely senior developers. But he’s willing to take direction and when he does, he succeeds. He also has a communication style that creates friction against Sparky’s. Sparky hates being interrupted. Kabob is more stream-of-consciousness and wants to interject his thoughts in the middle of someone else’s conversation. He also really wants to be heard, and doesn’t trust that he will be heard if he waits until the other guy’s done talking to speak. So the friction is obvious. I’ve worked on making their communication go more smoothly (mostly by explicitly stating to both of them the things that cause friction, and playing referee when either Sparky or Kabob starts getting agitated), and encouraged Cupcake to continue to do so.

Hockey is actually not someone I’ve had a lot of time to get to know, but from a management standpoint, he’s been easy. He gets his job done fast and well, he’e easygoing, and he’s self-directed, but asks for assistance when he needs it. Basically,  I didn’t have any suggestions for Cupcake because I never felt like Hockey needed any special management.

At first I felt like I was kinda being mean by telling Cupcake the bad points of Phoenix and Kabob. But then I concluded that, well, no, I’m doing both of them a favor. Because Cupcake is a good guy and naturally has all the soft skills required to be an effective lead (many of which I’m still developing). And he will, with the knowledge I’m giving him, be positioned to help my team continue to succeed at their jobs.

And to me, ensuring the success of each member of my team is the first responsibility of being a lead.

Planning Ahead

Today Sparky invited me out of the office to talk.

Sparky told me that my future boss, the CTO of my new company, called and talked to him about me, to gain Sparky’s insights about me and my strengths and where I could use the most help. Sparky spoke very well of me, of course; he’s good that way. But the conversation between him and me branched out to two important topics: The insights Sparky gained from CTO, and his advice to me as I go forth to, essentially, take on Sparky’s role at my new company.

The first part of the conversation was shorter. CTO is principally concerned with my ability to balance keeping on task with accepting new tasks and scope changes (and Sparky thought my abilities to do such were very strong), and also with my ability to accurately estimate tasks (which I never thought I was very good at, but Sparky seemed to think I’m better than I think). So being good at these two tasks will be important to my success.

The second, much longer part of the conversation was a very welcome discussion of his tips to me for success. And I wish I had taken notes, but I think I remember all the important points. In no particular order, here they are:

  • Never show up at a meeting without a pen and a notebook. Not a notepad; a bound, leather-clad notebook. Take notes about everything, particularly about any commitments I make, or any commitments or assurances made to me. Make it very clear I’m recording everything I can; this helps to create an air of authority and of seriousness, but warns people trying to BS me.
  • Get familiar with the industry. Not just my new company’s business, but in e-commerce and online marketing in general. If the company has a social media presence, get to know about social media, and social media return-on-investment metrics in particular. There are local meetup groups involved in such.
  • Consider a subscription to Safari Books Online — they have lots of reference materials that I’d benefit from reading. It’s 20 bucks a month but can be written off my taxes, and I might be able to convince my new company to expense it.
  • Get familiar with all aspects of the product development life cycle, including things where I’m not the most competent, like project management. Project management may not be what I’m called upon to do, but I should know the details of what a project manager does.
  • Get in sync with CTO. This means, partly, being willing and able to carry his vision to my team and to my peers, but it also means bringing my own ideas to the table that help implement his vision, or even to enhance and improve it.
  • Try to establish a mentoring relationship with CTO. This is a suggestion Sparky gave CTO in their conversation but he impressed it upon me too. CTO has been there and done that, and I will benefit from his experience and expertise.
  • Establish relationships with key people throughout the company. Not necessarily CTO’s peers, but their assistants, the lower level managers, my peers throughout the company. Also establish relationships with my peers. Never eat lunch alone if I can help it. If I’m not eating with the CTO, or peers, I should be eating with my team. Sparky thinks I have a very gregarious personality and this works to my advantage. But, don’t establish these relationships just to gain a career advantage — let it be a happy side effect.
  • Establish a reputation as a serious, knowledgable member of the team who is the go-to guy when it comes to questions about technology. This means my natural tendency to be the company cut-up, cracking jokes and making people laugh, needs to be, well, managed. It’s not that I can’t make jokes any more, but I need to be sure that I’m serious when I need to be serious, when the conversations are important.
  • Learn to manage vendors. Ask them the right questions. Don’t lay all my cards on the table. Give them high level issues and ask them how they can address them. Let them fill in the blanks. Don’t let them craft their responses to promise me pie in the sky to meet all my needs. Ask to see samples. Ask to see documentation. Ask to talk to other customers. Ask for access to their technical people, if applicable. And don’t call them out or create a hostile relationship if it’s not necessary, and ESPECIALLY if I don’t have an alternative to them. If they have a proverbial gun to my head, never let them know it.
  • Learn to manage up. This means establishing a good relationship with CTO, but also to other members of the senior leadership team. It also means setting and managing expectations, and communicating the needs of my team to facilitate meeting the company’s objectives.

Sparky has said I can call on him for advice and counsel in the weeks and months to come. Which is a relief to me. Not only is he the most brilliant developer with whom I’ve ever worked, but he’s a genuinely decent, kind-hearted guy with whom I hope to continue to keep in contact.

I also plan to seek the frequent counsel of Red, who’s about 90 days ahead of me in moving into a similar role. She, too, is a brilliant developer and architect, and I expect her experience growing into her role will give her some important insights that will help me grow into mine. She’s already recommended a book to me — “The First 90 Days” — which I need to find, buy and start reading as soon as I can.

The story so far

Last Friday, I turned in my notice.

I have been given a great new opportunity at a new company. I am being hired on as the team lead.  Only without a team. There’s no team, yet. Among my first tasks will be building the team I’m going to be leading. And then working with the CTO, my new boss, to establish the development environment, methodology, and structure moving forward — both internally and externally.

Needless to say, this is a very exciting opportunity for a guy who’s been a senior developer for years but a lead only for a few months. I’ve been serving since December as the development lead at my current company, since “Red”, the last team lead, departed to a job analogous to the one I’m moving into.

I’ve learned a lot in the last couple months about being a lead; not just the informal mentoring, architecting and collaboration things I’ve been doing for years, but also the formal planning and interaction with the project managers and business leaders, the encouraging my team to look to me for direction and support, and the surprising number of large and small things that come with the job.

Throughout it all, I’ve had the unwavering support of my boss, “Sparky”, the development manager. He’s been fantastic and I’m going to deeply miss working under him. But I’ve seen the frustration he’s been laboring under, the inexplicable, ADD-like business decisions, the rapid increase of bloat in product management, and especially the strongly combative nature of “Exidor”, my company’s CTO, which has pushed so many good people, some of the finest developers with whom I’ve ever worked in my fourteen years in development (including and especially “Red”), out the door in search of greener pastures.

It has been clear for a while that it’s time for me to move on. It’s just serendipity that this opportunity presented itself and that it proved to be so enticing.

So now I begin my journey of wrapping up my current job (and doing right by the people I leave behind) and transitioning to my new one (and doing right by my new company, my future team, and my own career).

I have little doubt I’ll make a lot of mistakes, big and small, along the way. But I’m going to learn from each of them, and also from my successes, to be the best lead I can be.

First comes defining what “the best lead I can be” is. Second comes charting a path to the goal of becoming that lead.